This is probably a beginner question, but I don't see any obviously
visible hints...
I was trying to get cells to compile, with (say) sbcl (I also tried
cmucl, with very similar results). So I edited build.lisp to set the
path, and then tried to load it. And got a backtrace indicating an
error, somewhere.
What seems frustrating was that the backtrace didn't seem to show
where in the source the problem was (or even a best guess). And when
I did the same using the excellent slime, things were no better, even
though slime backtraces have special features for showing the source
of stack frames.
Of course, I now realise that I should have expected this: the
compiler is written in lisp, so when it crashes, the debugger is going
to try to help me to debug the compiler. Presumably the position in
the source files I'm interested in are in there somewhere as local
variables and function parameters, if I only knew where.
So what's the trick for getting useful information about where
compilation errors happen? slime offers me things like
slime-compile-file which look wonderful for my own code (it apparently
annotates the source buffer with the errors), but that doesn't look
immediately useful for the common case where you get a package like
cells, cl-pdf or whatever, and you want to try to fix minor
compilation errors, but basically compile the thing using asdf (or, as
in this case loading a file)? After all, in this case I'm not even
sure which file has a problem.
From: ·········@random-state.net
Subject: Re: How do I deal with code that doesn't compile?
Date:
Message-ID: <ceccl6$4ehk4$1@midnight.cs.hut.fi>
Bruce Stephens <············@cenderis.demon.co.uk> wrote:
> What seems frustrating was that the backtrace didn't seem to show
> where in the source the problem was (or even a best guess). And when
Try M-. on a backtrace frame. You may be surprised. ;-)
> So what's the trick for getting useful information about where
> compilation errors happen? slime offers me things like
Another useful trick is
(setf *break-on-signals* 'warning) ; or 'error, or whathaveyou
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
·········@random-state.net writes:
> Bruce Stephens <············@cenderis.demon.co.uk> wrote:
>
>> What seems frustrating was that the backtrace didn't seem to show
>> where in the source the problem was (or even a best guess). And when
>
> Try M-. on a backtrace frame. You may be surprised. ;-)
But not pleasantly.
>> So what's the trick for getting useful information about where
>> compilation errors happen? slime offers me things like
>
> Another useful trick is
>
> (setf *break-on-signals* 'warning) ; or 'error, or whathaveyou
Those are potentially useful tricks, but not for this, I suspect.
Here are the sources:
<http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/build.lisp?rev=1.2&cvsroot=cells&content-type=text>
and
<http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/build-sys.lisp?rev=1.1&cvsroot=cells&content-type=text>.
And here's what I get when I load build.lisp:
Function called with odd number of keyword arguments.
[Condition of type KERNEL:SIMPLE-PROGRAM-ERROR]
Restarts:
0: [CONTINUE] Return NIL from load of "build.lisp".
1: [ABORT] Abort handling SLIME request.
2: [ABORT] Return to Top-Level.
Backtrace:
0: (C::%ODD-KEYWORD-ARGUMENTS-ERROR)
1: (NIL :FORCE (T :SOURCE-DIRECTORY "/opt/cells/cells/") 3)[:OPTIONAL]
2: ("Top-Level Form")[:TOP-LEVEL]
3: (LISP::SLOLOAD #<Stream for file "/opt/cells/cells/build.lisp">)
4: (LISP::INTERNAL-LOAD #p"build.lisp" #p"/opt/cells/cells/build.lisp" :ERROR :SOURCE)
5: (LISP::INTERNAL-LOAD #p"build.lisp" #p"/opt/cells/cells/build.lisp" :ERROR NIL)
6: (LOAD "build.lisp" :VERBOSE NIL :PRINT ...)
So the two lines I'd like to be pointed at, somehow, are line 58 of
build.lisp (the attempted call of cells-build-package::build-sys) and
28 of build-sys-lisp, the definition.