SBCL Error Messages: Any way to improve?

Question

I've been developing with Common Lisp for almost a year now, and this is really starting to get on my nerves. I started programming CL using CLISP, but I later switched over to SBCL for speed. I do a lot of rather low-level stuff, so I need to interface with a lot of C code. I really like the incremental development aspect of CL (I don't use Emacs however - I'm running SLIMV in Vim), but I find myself developing more slowly than I would in Python, Perl, C, or even NASM. The root of the problem lies in SBCL's error messages. I once was forced to search through almost 500 lines of code because SBCL decided to give me an ERROR: Invalid number of arguments on foreign function #< some memory address >. No designation of what function was called, no line number, nothing. More recently, I've had the delight of getting The loaded code expects an incompatible layout for class SB-PRETTY:PRETTY-STREAM. randomly. The code runs FINE on CLISP, but just fails with obscure errors on SBCL. Is there any way to make these messages somewhat more informative? I've been writing C and assembly for almost 6 years now, and even they will give you a line number. The only halfway reasonable SBCL errors I've seen have been reader errors, which are almost useless because they usually amount to a missing parenthesis. Again, is there any declaration/command line switch that can be used to change this? I'd even be okay with writing my own error printer at this point.

EDIT: An example, with (sb-ext:restrict-compiler-policy 'debug 3) in my ~/.sbclrc (using --load rather than --script so .sbclrc is loaded)

debugger invoked on a SB-INT:SIMPLE-PROGRAM-ERROR in thread
#<THREAD "main thread" RUNNING {AB09931}>:
  invalid number of arguments: 0

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(SB-KERNEL::INVALID-ARG-COUNT-ERROR-HANDLER
 #<unavailable argument>
 #.(SB-SYS:INT-SAP #XB78CDAE0)
 #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB78CD7DC :TYPE (*
                                                         (STRUCT
                                                          SB-VM::OS-CONTEXT-T-STRUCT))>
 (79))
0] print
(SB-KERNEL::INVALID-ARG-COUNT-ERROR-HANDLER
    #<unavailable argument>
    #.(SB-SYS:INT-SAP #XB78CDAE0)
    #<SB-ALIEN-INTERNALS:ALIEN-VALUE :SAP #XB78CD7DC :TYPE (*
                                                            (STRUCT
                                                             SB-VM::OS-CONTEXT-T-STRUCT))>
    (79))
0] down
(SB-KERNEL:INTERNAL-ERROR
    #.(SB-SYS:INT-SAP #XB78CD7DC)
    #<unavailable argument>)
1] down
("foreign function: #x805FCBB")
2] down

Bottom of stack.

Not exactly informative.

Bustamante

Such questions are best asked on the SBCL mailing list. With example code, when possible. People who are maintaining the SBCL compiler are listening there. – Whorish

Have you tried Clozure and their Objective C bridge? I haven't had too much of an issue with the error messages generated in that lisp implementation when communicating with Objective C routines. Which I know isn't C, but you might find inspiration there. – Exile

Also, with slimv, you are getting the debugger buffer yes, that shows the backtrace, that you can navigate around and see variable state, etc.? – Exile

Answer 1

This is a common problem with distributions that "customise" the build script; Arch Linux is a regular offender. Installing binaries from sbcl.org is the most reliable method. It's fairly easy to then build from source if one wants the latest and greatest.

Uniat

Answer 2

I think you're looking for: (sb-ext:restrict-compiler-policy 'debug 3)

You can put it into your ~/.sbclrc or into your REPL, and SBCL's debugger (especially in SLIME) will produce much more useful results.

Selfstyled

Answer 3

One more thing I've learned recently, and this may be useful in your situation:

1. Make sure to compile everything with sufficient debug level.
2. Wrap the code you suspect into (step ...) form. From there you can follow restarts, which you will recognize as being very similar to GDB and other step-debuggers (you can step-next, step-into, step-out and step-countinue) from there. It may be a bit tedious to get to the function you need, if you absolutely have no clue as to where it is coming from, but if you use it as a methodology, and test smaller pieces of code, it helps.

More info: http://www.sbcl.org/manual/#Single-Stepping

Massacre

Answer 4

I'm almost 7 years late, but I will add some helpful advice. After getting sick of seeing errors in slime and only knowing what function they were in, but no line number or anything, I found this stack overflow question. This didn't help too much so I finally read the slime manual. https://common-lisp.net/project/slime/#documentation

Not sure if it would have helped the original poster, but when an error pops up and you are in the slime debugger, hitting 'v' (in emacs, not sure about vim) will show you the source code where the error is being raised. You can also browse down to other entries in the stack trace and hit 'v'.

There's other helpful tips in the slime manual in the debugging section. It's really nice to be able to evaluate expressions in the same stack frame where the error originated.

Damian

Answer 5

If you get a run-time error (I suspect the invalid number of arguments falls in that category), you should drop into a debugger (unless you've explicitly disabled that) and a back-trace would, probably, show you exactly where the call was made.

The loaded code expects a different layout... indicates you are looking at two pieces of compiled code, compiled at different point in time, or code that is hooking a bit too deeply into the internals. First, force a recompilation of all your code and see if the warning goes away.

Ferrigno

Yes, it drops me in a debugger, but the problem is that the invalid number of arguments is in a foreign function call, so the callstack is only 3 deep, the lowest of which is <foreign function whatever>. – Bustamante