Open jcguu95 opened 2 years ago
Hello! Thanks for your kind words. I just pushed a fix that is somewhat primitive, but also flexible, and might satisfy the spartan-but-somehow-elegant philosophy of SBCLI:
$ sbcli
Veit's REPL for SBCL version 0.1.3
Press CTRL-D or type :q to exit
sbcl> (+ 1 "hi")
Evaluation error: The value
"hi"
is not of type
NUMBER
when binding SB-KERNEL::Y
=> NIL
sbcl> *error*
=> #<TYPE-ERROR expected-type: NUMBER datum: "hi">
sbcl> (invoke-debugger *error*)
debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {1000560083}>:
The value
"hi"
is not of type
NUMBER
when binding SB-KERNEL::Y
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [RETRY ] Retry EVAL of current toplevel form.
1: [CONTINUE] Ignore error and continue loading file "/home/veit/./repl.lisp".
2: [ABORT ] Abort loading file "/home/veit/./repl.lisp".
3: Abort script, exiting lisp.
(INVOKE-DEBUGGER #<TYPE-ERROR expected-type: NUMBER datum: "hi">)
0]
How does that look to you?
Thanks for your prompt fix! Two issues:
> (+ 1 a)
The variable A is unbound.
=> NIL
sbcl> *error*
=> NIL
In the following example, I select "RETRY", but lisp quits immediately
sbcl> (+ 1 "a")
Evaluation error: The value
"a"
is not of type
NUMBER
when binding SB-KERNEL::Y
=> NIL
sbcl> (invoke-debugger *error*)
debugger invoked on a TYPE-ERROR in thread
#<THREAD "main thread" RUNNING {1000510083}>:
The value
"a"
is not of type
NUMBER
when binding SB-KERNEL::Y
Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.
restarts (invokable by number or by possibly-abbreviated name):
0: [RETRY ] Retry EVAL of current toplevel form.
1: [CONTINUE] Ignore error and continue loading file "/home/jin/sbcli/./repl.lisp".
2: [ABORT ] Abort loading file "/home/jin/sbcli/./repl.lisp".
3: Abort script, exiting lisp.
(INVOKE-DEBUGGER #<TYPE-ERROR expected-type: NUMBER datum: "a">)
0] 0
[sbcli]$
Hello! Thanks again for the feedback. The first item is trivial to fix.
As I learned, however, the second item, which is much more severe, is not that easy to fix; it seems as if we’d have to implement our own debugger interactions to make this work. That’s not at all impossible, just a chunk of work that I can’t tackle at the moment. At best, I’ll be able to take another look over the weekend. At worst, this will be the state of things for an undeterminable while. Sorry about that!
Have you looked into this? It doesn't have documentation though.. I'm not sure what it's doing at the time. But it claims to provide an interface between sbcl and GNU readline.
Thanks for the input! I don’t think I explained the problem very well.
We are already using cl-readline to have readline functionality; what we need is an interface to the debugger, i.e. something that actually implements the actions offered by the debugger interface, or potentially a wholly different interface altogether, since that one comes from the stock SBCL REPL and doesn’t play nicely with us.
@jcguu95 Did you look at other terminal REPLs? notably cl-repl and Lem (which can be started as a Lisp REPL) both have a simple interactive debugger. This project doesn't (and it's a feature, IMO).
Thanks for recommending cl-repl! I didn't know about that before :) Lem doesn't seem to provide a terminal repl though. Please correct me if I'm wrong.
Thanks for recommending cl-repl! I didn't know about that before :) Lem doesn't seem to provide a terminal repl though. Please correct me if I'm wrong.
yes it does. Inside Lem, call M-x start-lisp-repl
or start it with a REPL:
alias ilem='lem --eval "(lem-lisp-mode:start-lisp-repl t)"'
Just as a record, there's another lisp repl with GNU readline https://github.com/fukamachi/mondo
Thanks for writing this wonderful thing!
I wonder if it's possible to interact with the debugger as in the usual sbcl. For now, by default, it seems that whenever an error (or a condition) occurs,
sbcli
prints the message to screen but does not let us choose what to do (e.g. ignore, accept, abort.. etc).