On 05 Mar 2005 23:58:28 +0100, Luke Gorrie luke@synap.se wrote:
I have narrowed the test case down far enough to take slime out of the picture:
$ rm *.x86f $ lisp
- (asdf:oos 'asdf:load-op :foo)
- (let ((*read-suppress* t)) (with-open-file (s "foo1.lisp") (dotimes (i 4) (read s))))
...hits the error...
Same here.
i.e. it looks like a bug where clsql's reader syntax doesn't work with *READ-SUPPRESS* but just looking at the code I don't see why this is so.
I think I've found the answer:
Usually, LISP::TOKEN-DELIMITERP returns NIL for #[, but after CLSQL has modified the readtable this macro returns T:
edi@vmware:/tmp$ cmucl ; Loading #p"/home/edi/.cmucl-init". CMU Common Lisp CVS release-19a 19a-release-20040728 + minimal debian patches, running on vmware With core: /usr/lib/cmucl/lisp.core Dumped on: Thu, 2005-02-10 19:05:48+01:00 on vmware For support see http://www.cons.org/cmucl/support.html Send bug reports to the debian BTS. or to pvaneynd@debian.org type (help) for help, (quit) to exit, and (demo) to see the demos
Loaded subsystems: Python 1.1, target Intel x86 CLOS based on Gerd's PCL 2004/04/14 03:32:47 * (asdf:oos 'asdf:load-op :clsql)
; [blabla]
NIL * (lisp::token-delimiterp #[)
NIL * (clsql:locally-enable-sql-reader-syntax)
* (lisp::token-delimiterp #[)
T
Now, when *READ-SUPPRESS* is true then CMUCL's LISP::READ-TOKEN will call LISP::INTERNAL-READ-EXTENDED-TOKEN which in this case (i.e. when looking at #[) will unread the character from the stream and return immediately. At that point the reader is stuck and will try indefinitely to get past the opening bracket.
Something like that...
NB: I want buffer-local syntax as much as the next guy but I think this clsql #.(hack-read-syntax) ... #.(unhack-read-syntax) trick is a bit fragile -- I don't think that tools like SLIME or the CMUCL debugger can really do the right thing with it.
Yep, everything works fine if I use EVAL-WHEN and a copy of the readtable instead so the case is closed for me. Thanks for your help!
BTW, on my machine it also hangs Emacs but that's just due to swappage as the lisp heap expands. I don't have much ram though.
Get more RAM, it's fun... :)
Cheers, Edi.