|
From: rif <ri...@MI...> - 2003-11-25 22:03:07
|
OK, I've spent a bunch of time looking at things, and I've somewhat isolated the problem. My problem is NOT a CMUCL version skew problem. This problem occurs with a brand-new out-of-the-CVS ILISP, which contains no .x86f files whatsoever. ILISP, at startup time, tries to load the files ilisp-pkg, cl-ilisp, cmulisp, and find-src. For each file, it loads a .x86f if one is available (which could perhaps lead to version skew problems if one changes CMUCL versions), and if not, a .lisp file. The problem directly relates to the fact that recent versions of CMUCL (including at least Snapshot 2003-11 and post-18e CVS 2003-08-15) cannot successfully load the file find-src.lisp in the ILISP distribution. If the file is compiled, the resulting find-src.x86f can be loaded normally. I have sent mail to the CMUCL help mailing list about this. Therefore, one (currently my only) workaround is to go into a CMUCL from the shell (NOT from ILISP), and compile find-src.lisp there (after loading the other three in either .lisp or .x86f form). This at least gets ILISP working --- we should really come up with something better, or at least publicize this workaround so newbies don't get caught up in it for too long. M-x ilisp-compile-inits tries to compile all of these files, if they are not compiled. For reasons I'm unclear on, this does not work, regardless of whether or not the workaround above has been applied. In particular, all attempts to compile cl-ilisp inside an ILISP buffer yield 67 errors, which seem to all be of the form "blah is not of type KERNEL::STRUCTURE-CLASS" (same problem we face if we try to load find-src.lisp.) Note, however, that if I start a CMUCL from the shell, I can load ilisp-pkg.[lisp|x86f] and then compile cl-ilisp no problem. So this seems to be some weird interaction between ILISP and CMUCL, rather than strictly a CMUCL problem. I'm not sure what else to say. I'm willing to poke at this some more if anyone has some good ideas or suggestions. Cheers, rif |