From: rif <rif@MIT.EDU> - 2003-11-24 21:47:50
|
A while back, Nicolas Neuss posted a bug trying to make a new CMUCL run with the CVS ILISP. In particular, this is CMUCL post-18e CVS 2003-08-15, and I downloaded ILISP today (24 Nov 2003). I'm getting exactly the same error Nicolas described (see http://sourceforge.net/mailarchive/forum.php?thread_id=3281533&forum_id=5778), although for Nicolas, the problem eventually seemed to go away on its own, and for me it's not. Any ideas or suggestions? Cheers, rif ps. Will someone PLEASE change line 171 of ilisp.emacs so that the referenced file is Map_Sym.txt, rather than Map_Sym.Txt? Map_Sym.Txt is not part of the hyperspec and this leads to hard to find bugs that have cost at least me and someone else a lot of time hunting down. |
From: Bob R. <rog...@rg...> - 2003-11-25 02:16:29
|
From: rif <rif@MIT.EDU> Date: Mon, 24 Nov 2003 16:47:47 -0500 A while back, Nicolas Neuss posted a bug trying to make a new CMUCL run with the CVS ILISP. In particular, this is CMUCL post-18e CVS 2003-08-15, and I downloaded ILISP today (24 Nov 2003). I'm getting exactly the same error Nicolas described (see http://sourceforge.net/mailarchive/forum.php?thread_id=3281533&forum_id=5778), although for Nicolas, the problem eventually seemed to go away on its own, and for me it's not. Any ideas or suggestions? Cheers, rif Sorry; I didn't see the original post, though I'm not sure why. Probably trying to read too fast. Anyway, I had what appears to be the same problem with ilisp CVS and the CMUCL November snapshot, and I think the solution was to blow away all of the *.x86f files before starting cmucl under ilisp, then do M-x ilisp-compile-inits. If that doesn't work, try invoking CMUCL from a shell and compiling the relevant files manually (ilisp-pkg.lisp, cl-ilisp.lisp, cmulisp.lisp, and find-src.lisp, in that order), loading the new binary after each compile. One of these solutions worked with CMUCL, and the other worked with SBCL 0.8.4, but I'm afraid I don't remember which was which. HTH, -- Bob Rogers http://rgrjr.dyndns.org/ |
From: Nicolas N. <Nic...@iw...> - 2003-11-25 09:20:09
|
Bob Rogers <rog...@rg...> writes: > From: rif <rif@MIT.EDU> > Date: Mon, 24 Nov 2003 16:47:47 -0500 > > A while back, Nicolas Neuss posted a bug trying to make a new CMUCL > run with the CVS ILISP. In particular, this is CMUCL post-18e CVS > 2003-08-15, and I downloaded ILISP today (24 Nov 2003). I'm getting > exactly the same error Nicolas described (see > http://sourceforge.net/mailarchive/forum.php?thread_id=3281533&forum_id=5778), > although for Nicolas, the problem eventually seemed to go away on its > own, and for me it's not. > > Any ideas or suggestions? > > Cheers, > > rif > > Sorry; I didn't see the original post, though I'm not sure why. > Probably trying to read too fast. > > Anyway, I had what appears to be the same problem with ilisp CVS and > the CMUCL November snapshot, and I think the solution was to blow away > all of the *.x86f files before starting cmucl under ilisp, then do M-x > ilisp-compile-inits. If that doesn't work, try invoking CMUCL from a > shell and compiling the relevant files manually (ilisp-pkg.lisp, > cl-ilisp.lisp, cmulisp.lisp, and find-src.lisp, in that order), loading > the new binary after each compile. > > One of these solutions worked with CMUCL, and the other worked with > SBCL 0.8.4, but I'm afraid I don't remember which was which. > > HTH, > > -- Bob Rogers > http://rgrjr.dyndns.org/ For me the solution was also something like this. If this does not work, maybe the following helps. I also had problems because ilisp used some site-wide initialization files which were compiled for an older Ilisp and older CMUCL. These existed because I once had installed Debian ilisp and "apt-get remove ilisp" did not do its clean up properly. Nicolas. |
From: Thomas F. B. <tfb@OCF.Berkeley.EDU> - 2003-11-25 18:29:31
|
I had this problem a couple times too. If the ILISP maintainers put something like this: (eval-when (:load-toplevel) (assert (string= #.(lisp-implementation-version) (lisp-implementation-version)) () "This file was compiled with CMUCL version ~A but is being loaded into version ~A" #.(lisp-implementation-version) (lisp-implementation-version))) at the top of the cmulisp.lisp, it would probably help a lot. -- /|_ .-----------------------. ,' .\ / | No to Imperialist war | ,--' _,' | Wage class war! | / / `-----------------------' ( -. | | ) | (`-. '--.) `. )----' |
From: rif <rif@MIT.EDU> - 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 |
From: Bob R. <rog...@rg...> - 2003-11-26 03:13:57
|
From: rif <rif@MIT.EDU> Date: Tue, 25 Nov 2003 17:01:23 -0500 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. Then this needs to be fixed, no question. 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. . . . Then it's almost certainly a CMUCL compiler issue. I wonder if this is related to the CLX compilation issue that was recently discussed on the cmucl-imp list? The solution was to bind conditions::*make-condition-accessor-methods* to T, but I just tried something similar, with no luck. 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 Other than the speculation I made above, I'm clueless. Since find-src.lisp is mostly my code, I figure the ball is in my court, but if you can think of a way to pin it down, I'd greatly appreciate the help. Good thing Thursday is a holiday . . . -- Bob |