I think I wasn't sure at the time whether the simple variable was
required for pthread_cond_wait (and friends) to work properly, but it
is: the time between the target posting the debug event and the target
waiting on the condition variable turns out to sometimes be enough for
the debugger to handle the event and signal the target to continue,
resulting in the target waiting on a signal that will never come because
another debug event will not be sent by the target until AFTER it has
exited from the debug handler.
Pressing F8 (or n) while the debug target was running would cause it to
stop at that point. While it's certainly desirable to stop a runaway
target on demand, that should be with a different input. Now, commands
that start the target running are ignored while the target is running.
No commands for when the target is running have been implemented yet,
but the provision is there.
Same issue as for the menus. But now I know why PR_LoadProgsFile is used
instead of PR_LoadProgs (at least for qwaq): avoidance of the gamedir
restriction (however, the menus are supposed to be restricted).
There's still some cleanup to do, but everything seems to be working
nicely: `make -j` works, `make distcheck` passes. There is probably
plenty of bitrot in the package directories (RPM, debian), though.
The vc project files have been removed since those versions are way out
of date and quakeforge is pretty much dependent on gcc now anyway.
Most of the old Makefile.am files are now Makemodule.am. This should
allow for new Makefile.am files that allow local building (to be added
on an as-needed bases). The current remaining Makefile.am files are for
standalone sub-projects.a
The installable bins are currently built in the top-level build
directory. This may change if the clutter gets to be too much.
While this does make a noticeable difference in build times, the main
reason for the switch was to take care of the growing dependency issues:
now it's possible to build tools for code generation (eg, using qfcc and
ruamoko programs for code-gen).
I decided that stopping in between function calls that are on the same
line is a good thing as it gives a chance to skip over the first but
step into the second.
This allows a debugger to do any symbol lookups and other preparations
between loading progs and the first code execution. .ctors are called as
per normal if debug_handler is not set.
While this does answer the question of how I'll go about restarting the
target progs (when I get to that point), it was required just to start
full-on ruamoko progs because .ctor was getting run in the main thread
and blocking due to trace.
In testing variable fw/precision in PR_Sprintf, I got a nasty reminder
of the limitations of the current progs ABI: passing @args to another QC
function does not work because the args list gets trampled but the
called function's locals. Thus, the need for a va_copy. It's not quite
the same as C's as it returns the destination args instead of copying
like memcpy, but it does copy the list from the source args to a
temporary buffer that is freed when the calling function returns.
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).
