For now, just bsearch (normal and fuzzy), qsort, and prefixsum (not in
C's stdlib that I know of, but I think having native implementations of
float and int prefix sums will be useful.
While qfcc will always align double values to 8 bytes (really, two
global words) regardless of the underlying hardware, gcc does not:
doubles are only 4-byte aligned on 32-bit hardware.
This fixes the invalid debug target handle when running on i686.
QF now uses its own configuration file (quakeforge.cfg for now) rather
than overwriting config.cfg so that people trying out QF in their normal
quake installs don't trash their config.cfg for other quake clients. If
quakeforge.cfg is present, all other config files are ignored except
that quake.rc is scanned for a startdemos command and that is executed.
While this caused some trouble for pr_strings and configurable strftime
(evil hacks abound), it's the result of discovering an ancient (from
maybe as early as 2004, definitely before 2012) bug in qwaq's printing
that somehow got past months of trial-by-fire testing (origin understood
thanks to the warning finding it).
I never liked that some of the macros needed the type as a parameter
(yay typeof and __auto_type) or those that returned a value hid the
return statement so they couldn't be used in assignments.
This is the first step towards component-based entities.
There's still some transform-related stuff in the struct that needs to
be moved, but it's all entirely client related (rather than renderer)
and will probably go into a "client" component. Also, the current
components are directly included structs rather than references as I
didn't want to deal with the object management at this stage.
As part of the process (because transforms use simd) this also starts
the process of moving QF to using simd for vectors and matrices. There's
now a mess of simd and sisd code mixed together, but it works
surprisingly well together.
It now takes a context pointer (opaque data) that holds the buffers it
uses for the temporary strings. If the context pointer is null, a static
context is used (making those uses of va NOT thread-safe). Most calls to
va use the static context, but all such calls have been formatted
consistently so they are easy to find when it comes time to do a full
audit.
I can't say that I like what's there even now, but at least PLItem can
be used without a lot of casting. Really, Ruamoko needs dictionary and
string classes so reading a property list can build more natural object
trees rather than this mess from when I knew too little.
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).
Returning a string was a bad idea as it makes str_str difficult to use
with str_mid. (actually, iirc, it was the only reason I moved all
strings into progs memory... hmm).
It never really helped sort out the path issues when using build
directories. It worked well enough for single directory projects, but
things got messy very quickly, especially when mixing ruamoko libs with
external progs. A better method based on dwarf is coming.
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).
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).
When a type is aliased, the alias has two type chains: the simple type
chain with all other aliases stripped, and the full type chain. There
are still plenty of bugs in it, but having the clean type chain takes
care of the major issue that was in the previous attempt as only the
head of the type-chain needs to be skipped for type comparison.
Most of the bugs are in finding the locations where the head needs to be
skipped.
The view is recorded as having focus but is not given focus until the
parent view is actually in focus. This fixes the locals view not having
focus at startup and thus blocking F7.
Changing str_free's return type highlighted that I'd missed an edit when
I did the big ruamoko build cleanup.
Also silence the sed/mv noise now that things are working nicely.
And rename prd_exit to prd_terminate (the idea is the host will
terminate the VM). This makes it possible for the debugger to pause the
VM before any code, even a builtin function, is executed. Breaks the
debugger source window, but only because it's not updating on file
change (I think).
I decided I want events for VM enter/exit but enter needs to somehow
pass the function which will be executed (even if a builtin). A generic
void * param seemed the best idea, which meant the error string could be
passed via the param instead of a "global" string in the progs struct.
After a lot of thought, I have come to the conclusion that the weird
crash the other day was caused by a race while the command ring buffer
had just been emptied: the command submission code opened up space for
writing, threads switched, and command processing saw the available data
and pounced on it before the submit code could write valid data. Thus
include the while header in the lock, and move the loop-end release
outside the lock. It may be a little confusing, but it seems to work.
They take a pointer to a free-list used for hashlinks so the hashlink
pools can be per-thread. However, hash tables that are not updated are
always thread-safe, so this affects only updates. progs_t has been set
up such that it is easy for multiple progs within one thread can share
hashlinks.
That... worked nicely. Program exit needs some work because exiting
terminates the thread and the debugger has no clue about it, but I was
able to single-step through gcd.r quite nicely.
This will allow for easy expansion of editor functionality without
messing with the editor itself. In particularly, an editor normally
doesn't need to know anything about debugger hot keys.
progs_t is very much most definitely NOT thread-safe (ie, two threads
using the same progs_t). It was actually rather funny when I figured out
what was going on to cause qwaq's universe to explode.
I got really weird error (invalid panel passed to top_panel) when there
was no such call, so I guess there was some memory corruption.
formatLine is the only suspect, but when I put in the guard, the error
wasn't reproduced (just scrolling through qwaq's makefile in a big
window).
With this, windows can be resized using any of the corners or the three
sides other than top (top side is move-only, otherwise moving a window
without resizing would be impossible).
It's a fairly high-level wrapper for TextBuffer in that it implements
file ops (load/save), searching, navigation, and formatting (simple
line-oriented with tab stops (currently at 4 spaces)).
While the key escape sequences are xterm-specific, they are only the
default and preliminary provision has been made for overriding them.
However, no override mechanism has been implemented beyond using dynamic
table lookup.
I'd left qwaq-curses running overnight and found it locked up: both
threads were looping because pthread_cond_timedwait was returning
EINVAL. Thus bail if anything other than 0 is returned, and try to
ensure tv_nsec is in the range 0..999999999
This doesn't fix the problem of lost events: that seems to be inside
ncurses. I've done some investigations, and it seems xterm sends
separate events for motion and pre/release (which have current coords),
in both 1003 and 1006 modes. No idea what ncurses is doing (does it even
handle 1003 properly?), and it requires the use of xterm-1006 for it to
use 1006 mode (which is nice in that it disambiguates button releases
and allows for huge terminals (not that I would use such normally)).
Guess I've got some side-work cut out for me :P
While writing the code I suspected this would be necessary, but it's
nice to know. Now the window seems to be correctly fetched, but
get_event locks up.
I realized that with dynamic thread creation the arrays resizing could
cause them to move around in memory which would be bad for anything
holding a pointer to the data, and even using indices wouldn't help that
much as the array would need to be mutex protected.
If none are specified, default to qwaq-app.dat (for now, anyway). For
each progs file, an optional args set can be specified in the same order
(separated by --). Missing sets default to empty, excess sets are
ignored.
The sets are separated by --, and the first set is passed to
getopt_long which currently recognizes only --qargs and non-options. The
--qargs options parses out a set (to -- or end of args) that is passed
to the qargs sub-system for standard qf command line parsing. Set 0 is
for the main qwaq application. Any additional sets (excluding --qargs)
will be used to spawn additional threads when that's working.
