Despair has things locked down such that running qfcc during a build fails
due to lack of read access to /usr/local/lib. This is actually a good
thing as accidentally hitting old includes/libs (when a file gets deleted
in the tree) hides bugs. Thus, --no-default-paths to turn off default
search paths.
An #if 0'ed out implementation of the -description method, which currently
returns a Quake string containing whatever the contained objects return
from -description, between parens and separated by commas (just like plist
format). Ideally, we'd have string objects interchangeable with primitive
strings, but having string objects (which are being worked on) should help.
With this, ruamoko/lib almost compiles (though no object files are output).
Just some bogus "redeclared" errors and an improperly implemented
statement that produces an ice.
I'm not sure why this is happening now when it didn't in the old qfcc,
but this will take care of the warning for now until I can get around to
fixing it.
#if 0 out the "normal" implementation, so that it doesn't hurt. When it
becomes possible to have the private Array methods separate, remove them
from the main file and remove the #if 0 block from Array+Private.r.
This version is a bit more useful, and we should be able to get rid of the
Stack class. Also, the Ruamoko parts of the autorelease system should be
almost ready now.
This is an extension "wrapper" (no such C function). This allows ruamoko
programs to read property lists without worrying about the memory required
to store the string for the property list being read.
Much more testing is required (oh, but for qc-valgrind), but there is now
a ~945kB block of free data in the menu progs heap :).
Also, correct the printed size of the memory block to not include the
block header size.
It's probably nowhere near right, but probably ok for now (I need to study
the GNUStep code). I'm unhappy with the menu code hook, but it will have
to do for now.
The plist code was written long before I thought of resource handles, and
then it was forgotten. This is much nicer and safer than storing C
pointers in progs memory space (*shudder*).
