Currently eql5 has a tendency to deadlock when encountering errors,
especially when executing scripts. The problem is that si_safe_eval
when called without a return flag expects to have errors handled in a
debugger, which does not exist in this case. As a result the lisp
runtime dies, while the code moves on to starting the Qt event loop
with nothing to control it.
This change introduces three flags to control the error handling
behaviour for eval:
- DebugOnError expects a debugger to be there, which is the old
behaviour. It can be restored by passing -debug-on-error to eql5
- LogOnError will log about the error, but does not handle it. This is
mainly a placeholder for better error handling in the future -
without error handling this also results in a deadlock.
- DieOnError is the new default, which logs the code leading to the
error, and exits with an error code.
Another patch should expose those flags to the Lisp runtime, and make
the error behaviour configurable both at initializing EQL from C++ and
later on during runtime.
A drawback of this change that we only get to see the the expression
triggering the error, not the actual error - that one is thrown away
by safe-eval:
#'(lambda (condition)
(declare (ignore condition))
(return-from safe-eval err-value))
I still feel for working with eql5 this is an overall
improvement. Next steps on this issue should include:
- either provide debugger hooks, or override invoke-debugger to behave
more sensibly
- possibly override/provide a custom variant of safe-eval to print the
error before returning
- check a few locations to set more sensible defaults, i.e. if
somebody just runl eql5 without a script they'd probably want to end
up in the debugger on errors.
Current implementation only passes in the first element of argv,
breaking command line argument parsing in scripts executed by eql5.
The eql5 binary now passes all arguments, while custom code can chose
the old or new behaviour, depending on which ini form is used.
