Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
Ok, so this still doesn't quite work yet, but it builds, and,
moreover, it can build all the contribs successfully.
Attached are a patch [well, no, the patch is in a separate email] and
some explanatory notes.
Unfortunately, the tests don't all work yet and, in particular, the
gc tests seem to be causing trouble. Perhaps there are issues in the
way we are blocking/unblocking signals (or possibly deferred signaling).
Turns out there was a nasty issue in the way the debugger walks the
stack frame and the heuristic to decide if a call frame is a lisp
call frame or a C call frame gets confused. It looks right in front
of the frame pointer and sees the remnants of a local variable on the
stack, which pointed to the stack, and before that the remnants of a
local variable that points to the SAP (which points to the context)
in dynamic space and it thinks it has found a lisp frame.
Unfortunately, it's not and this blows up. We've worked around this
problem by malloc'ing the context, but it would be nice to fix the
debugger so that this can't happen.
but if any macos users want to kick the tires, at least it compiles
and runs (FSVO runs) now. And it shouldn't trigger the crashreporter
and you can use gdb with it.
Thanks to Alastair Bridgewater who did much of the dirty work of
call_c_function_in_context and signal_emulation_handler, along with
figuring out what the hell was going with the debugger and countless