Leo wrote:
> Try this:
> go_lisp()
> (cmd)
>
> cmd is any non existing commands.
..
> unhandled condition in --disable-debugger mode, quitting
> Returning to Maxima
This is due to Fedora's use of 'sbcl --disable-debugger' for building maxima
in our buildsystem (to avoid hangs on sbcl's interactive debugger).
Turns out I now can't get maxima to build *at all* without
using --disable-debugger, and get's stuck near the end (I'll post again a
little later with some more build.log details).
Now, sbcl's manpage says this:
--disable-debugger
This is equivalent to --eval '(sb-ext:disable-debugger)'. By default, a
Common Lisp system tries to ask the programmer for help when it gets in
trouble (by printing a debug prompt, then listening, on *DEBUG-IO*).
However, this is not useful behavior for a system running with no
programmer available, and this option tries to set up more appropriate
behavior for that situation. This is implemented by redefining
INVOKE-DEBUGGER so that any call exits the process with a failure code
after printing a backtrace. (Note that because it is implemented by
modifying special variables and FDEFINITIONs, its effects persist in .core
files created by SB-EXT:SAVE-LISP-AND-DIE. If you want to undo its
effects, e.g. if you build a system unattended and then want to operate a
derived system interactively, see the SB-EXT:ENABLE-DEBUGGER command.)
any hints on using this SB-EXT:ENABLE-DEBUGGER trick with maxima?
-- Rex