Hi there,
I am just trying to use ECL for a little project of mine, but I have a problem.
Immediately after installation, things seem to work fine. I can run things, produce executables, etc.
However, the second time I load ECL I get the error listed below.
Deleting .cache/common-lisp/ecl-16.1.3 removes the error, but of course the world gets recompiled every time I load something.
And then again the next time I load ECL after that I get the error again.
I am using Ubuntu 19.10. I have tried compiling the development branch from gitlab (wouldn't be the first time Ubuntu ships with a buggy package when upstream is fine) but I get the same behaviour.
I did try using restart 1. to increase the stack size, but I just keep getting the error until I get an error about being unable to increase the stack size anymore.
The error is the same that Zhou Qianliang reported in January, but I'm not doing anything odd, just trying to start ecl for a second time.
https://mailman.common-lisp.net/pipermail/ecl-devel/2020-January/011473.html
I have searched for the error message but not come up with anything much more than the above mailing list message.
Error message:
;; Loading #P"/usr/local/lib/ecl-16.1.3/asdf.fas" An error occurred during initialization: The slot ASDF/PLAN::STAMP in the object #<action-status
Condition of type: STACK-OVERFLOW BINDING-STACK overflow at size 10240. Stack can probably be resized. Proceed with caution. Available restarts:
1. (CONTINUE) Extend stack size 2. (RETRY) Retry ASDF operation. 3. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the configuration. 4. (RETRY) Retry completing compilation for #<package-inferred-system "asdf">. 5. (ACCEPT) Continue, treating completing compilation for #<package-inferred-system "asdf"> as having been successful. 6. (RETRY) Retry ASDF operation. 7. (CLEAR-CONFIGURATION-AND-RETRY) Retry ASDF operation after resetting the configuration. 8. (CONTINUE) Ignore initialization errors and continue. 9. (ABORT) Quit ECL unsafely, ignoring all existing threads.
Top level in: #<process TOP-LEVEL 0x55b73cdd2f80>.
Thanks for any help you can give me. I'm looking forward to using ECL, seems like a nice platform!
--querent.
Hey querent,
could it be, that you have two ASDF versions loaded on top of each other? i.e asdf.lisp in your ~/common-lisp/ directory or something in this spirit.
Best regards, Daniel
Aha!
A locate asdf.lisp tells me of an asdf.lisp in ~/.local/share/ which according to the comment is version 2.26, which having read the documentation I understand to be quite old!
I also removed the cl-asdf Ubuntu package. One of them was the culprit.
OK, now to figure out how to use asdf and asdf:make-build (I haven't produced a *useful* executable so far). I may be back with more questions...
thanks so much for the quick response!
-querent.
27.02.2020, 23:03, "Daniel Kochmański" daniel@turtleware.eu:
Hey querent,
could it be, that you have two ASDF versions loaded on top of each other? i.e asdf.lisp in your ~/common-lisp/ directory or something in this spirit.
Best regards, Daniel
-- Daniel Kochmański ;; aka jackdaniel | Przemyśl, Poland TurtleWare - Daniel Kochmański | www.turtleware.eu
"Be the change that you wish to see in the world." - Mahatma Gandhi
You have another ASDF somewhere, like ~/common-lisp/asdf. When you load some system it first checks for newer ASDF and loads it. For some reason it fails with unbound slot STAMP in ACTION-STATUS object. When trying to print that object stack blows up.
I have actually reproduced this. All works fine if you recompile this external ASDF, but when you try to load it again this error happens.
I guess the simplest workaround is to lock ASDF: (require "asdf") ; Loads built-in ASDF (asdf:register-immutable-system "asdf") ; Prevents ASDF from reloading
Not sure if this is the right way to go, but it should work. Of course, removing external ASDF (or excluding it from the source registry) should also help.
-
Daniel Kochmański -
lsxvdqe -
querent