Hi, I think you're right that the problem seems to stem from try-to-accept-all-commands not being tail-call optimized.
I started glancing through the CMUCL manual (which is very nice, btw) and it seems like the problem might be that *package* is being bound outside the tail call. When I move the recursive call outside of the let, I get a noticeably different disassemble output, and the program seems to be working. At any rate, I will try with my whole data set, but I think this seems like a good fix. :) Thanks for all your help on this, Alex and Ray! Jared On Wed, Oct 28, 2009 at 9:48 PM, Raymond Toy <toy.raym...@gmail.com> wrote: > Jared C. Davis wrote: >> Hi, >> >> I have been hitting the following error in CMUCL 19f (and I think 20a) >> when my program calls extensions::save-lisp: >> >> [Doing purification: GC invariant lost! File >> "../../src/lisp/purify.c", line 510 >> >> And I am then sent to LDB. I seem to run into this same problem on >> 32- and 64-bit Linux, and on Darwin. I'm a fairly novice user of >> CMUCL, and am not sure how to proceed w.r.t. debugging this. >> > Ok. I tried out the test. Room shows that the stack is 58K bytes. > Curiously, there are 1800 recursive calls to > try-to-accept-all-commands. I don't know why the compiler did tail-call > that. Perhaps because of the defun-comp macro to compile it function, > instead of file-compiling the whole file. > > Anyway, if I increase that array size from 1024 to 10*1024, cmucl can > save lisp. > > I didn't try it, but it would be interesting to see if file-compiling > milawa.lisp would allow tail-calling try-to-accept-all-commands. That > would probably take care of the purify problem. > > Ray > > -- Jared C. Davis <ja...@cs.utexas.edu> 11410 Windermere Meadows Austin, TX 78759 http://www.cs.utexas.edu/users/jared/