Putting it in Editor worked as a proof of concept, but it seems those
always turn out to need tweaking like this because the concept proves
itself to be generally worthwhile :P
Leaking memory. And worse, it wasn't drawing its buttons (group wasn't
setting view contexts) and then the buttons were in the wrong place, so
had to add a backing buffer for the buttons.
This puts a print command (to Sys_Printf) into the queue making it
easier to check command sequences since regular printf is asynchronous
with the stream.
It currently dies when single stepping or exiting due to EditBuffer's
retain count not getting incremented when initialized. This is because
EditBuffer is initialized in C and thus does not call Object's -init.
While trying to build a view without deriving from it was a neat idea,
it doesn't work so well because a view really needs to know how to draw
itself. This even fixes the segfault when stepping past the end of the
program.
For now it just manages type encodings via their encoding string,
ensuring types are fetched from the target only once, if at all (may
already have the type due to it being common).
Things were getting rather cluttered with everything being qwaq-* and
all in one directory. Now most have lost the qwaq- prefix and have been
moved into subdirectories (non-recursive make).
Because type aliases need to be unaliased, the type pointers in the type
encodings need to be correct when it comes to linking defs and
functions. This fixes the linking errors in ruamoko/game.
I was very uncertain about the validity of messing with the old type
encoding that way, but adding the check to ensure the type has been
processed never fired, so it seems ok. And the comments help me a lot :)
When aliasing a type that already has aliases, the top node needs to be
replaced if it is unnamed, or the alias-free branch of the new node
needs to reach around to the alias-free branch of the existing node.
This fixes the bogus param counts in qwaq.
This fixes the typelinker test, but not the linking error in
ruamoko/game that it was supposed to represent. I guess there's
something more going on (maybe type encoding relocation issues).
Fixes#6
It turned out that the problem with @zero was caused by initial type
chaining occurring before the structures had been initialized and thus
the linker's @zero type encoding string was incorrect: {?=} instead of
{tag @zero-}, thus when the actual type encoding supplied by an object
file came along (with the correct encoding string), it wasn't found.
