Could be a stupid question: Cmucl failing to compile
Marcin Tustin
cmucl complains about end-of-file in the middle of the file. On trying to
load, it complains about unmatched close parentheses, but I'm (fairly) sure
this isn't so. Any ideas?
(I'd post the file, but it's a bit large to post (~300 lines))
Kaz Kylheku
>I've got a file which did compile, but since I added material at the end,
>cmucl complains about end-of-file in the middle of the file. On trying to
>load, it complains about unmatched close parentheses, but I'm (fairly) sure
>this isn't so. Any ideas?
Some text editors get confused by parentheses playing alternate roles,
for example the Lisp notation #\) representing the ) character, in which
case they become less than helpful.
>(I'd post the file, but it's a bit large to post (~300 lines))
Can you throw it on an HTTP or FTP server, and then cite the location?
Okay, that's a good warmup, now hit the source file. ;)
Marcin Tustin
Kaz Kylheku <k...@ashi.footprints.net> wrote in message
news:Bejd7.48470$B37.1...@news1.rdc1.bc.home.com...
Cheers man. I've broken up the file to the first part
(http://www.ecs.soton.ac.uk/~mt500/wrapper.lsp) and the part starting just
before the stream error (http://www.ecs.soton.ac.uk/~mt500/wrapperpt2.lsp).
I still don't think that it's the brackets, but I'd be happy to be proved
wrong.
Jochen Schmidt
> Cheers man. I've broken up the file to the first part
> (http://www.ecs.soton.ac.uk/~mt500/wrapper.lsp) and the part starting just
> before the stream error
> (http://www.ecs.soton.ac.uk/~mt500/wrapperpt2.lsp). I still don't think
> that it's the brackets, but I'd be happy to be proved wrong.
The method SCAN misses a paren at the end.
Note that I've not tried to compile the code and I do not know it that
fixes the problem - but this is definitely an error.
ciao
Jochen
Jochen Schmidt
There are multiple parens missing at the end of SCAN...
ciao,
Jochen
Marcin Tustin
Jochen Schmidt <j...@dataheaven.de> wrote in message
news:9l5s1h$4bd$2...@rznews2.rrze.uni-erlangen.de...
Kaz Kylheku
>Jochen Schmidt <j...@dataheaven.de> wrote in message
>Ah, the sheer prophecy of my subject line.
Note that this can be found in seconds with vi. I started matching
parens of the top-level forms in your second file one by one
using the % command and hit upon the scan method, which is the
second item.
Erik Naggum
> Note that this can be found in seconds with vi. I started matching
> parens of the top-level forms in your second file one by one
> using the % command and hit upon the scan method, which is the
> second item.
There are two efficient ways in Emacs to do this that might be worth
investigating for those who still think vi is a suitable editor. :)
At the start of a buffer, lean on M-C-f. Depending on the capacity of
your keyboard's autorepeat feature, you will soon either hit the end of
the buffer, or get an error very close to the position of the beginning
of a form that has no terminating parenthesis. It should not be a
problem figuring out what is wrong. This uses forward parsing, which is
always a good idea in Lisp.
Alternatively, at the end of the buffer, type M-C-u. You will get an
error if all the parentheses match, but will be positioned at the last
unmatched parenthesis if there is one. This used backward parsing, which
has some serious drawbacks and may lead to false positives and negatives.
I note in passing that Allegro CL's Emacs Lisp modes warn the user about
unmatched parentheses before a buffer is saved. This is a nice feature.
///
Kaz Kylheku
>* k...@ashi.footprints.net (Kaz Kylheku)
>> Note that this can be found in seconds with vi. I started matching
>> parens of the top-level forms in your second file one by one
>> using the % command and hit upon the scan method, which is the
>> second item.
>
> There are two efficient ways in Emacs to do this that might be worth
> investigating for those who still think vi is a suitable editor. :)
I only wanted to show that even minimal support for parenthesis matching
can be of help, not to advocate any implementation. ;)