You could try without SLIME, from the bare REPL. Not that SLIME breaks anything, but maybe you'll get a more understandable stack trace.
On 20 December 2016 at 14:14, Mirko Vukovic mirko.vukovic@gmail.com wrote:
On Tue, Dec 20, 2016 at 6:17 AM Alessio Stalla alessiostalla@gmail.com wrote:
Could it be some path-related problem (e.g. spaces in the path, a very long path, unusual characters in the path, ...)?
On my system the path to vecto is c:\Users\977314\quicklisp... There are not spaces in the path.
vecto depends on cl-vectors, zpng, zpb-ttf. I can load all of them without problem.
Example of paths:
; SLIME 2.18 CL-USER> (asdf:system-source-directory :cl-vectors) #P"C:/Users/977315/quicklisp/dists/quicklisp/software/cl- vectors-20150407-git/" CL-USER> (asdf:system-source-directory :vecto) #P"C:/Users/977315/quicklisp/dists/quicklisp/software/vecto-1.4.10/" CL-USER>
If vecto.asd contains dependencies to those three libraries, the asd will load. Once I add a file to the list of components, it fails.
Mirko
On 18 December 2016 at 23:23, Mirko Vukovic mirko.vukovic@gmail.com wrote:
Hello again,
I have joined the mailing list, and also seen Mark Evenson's reply https://mailman.common-lisp.net/pipermail/armedbear-devel/ 2016-December/003759.html. It is encouraging that he can load Vecto.
A few more details on my environment and more probing results
Implementation details:
CL-USER> (lisp-implementation-version) "1.4.0" "Java_HotSpot(TM)_Client_VM-Oracle_Corporation-1.7.0_51-b13" "x86-Windows_8-6.2"
Does the above look OK? Version wise, it is close to what Mark has, except that he has JDK, and I have Java_HotSpot.
ASDF Version:
I was wondering if the issue had to do with ASDF's looking for libraries and files, i.e., whether I was hit by an ASDF bug. So I installed the latest ASDF moving from 3.1.7, to 3.1.7.43, (which is a release candidate for asdf 3.2)
The stack overflow remains.
Manual loading of dependencies (libraries and files):
I verified that I can manually load all the libraries vecto depends on, and also manually compile and load all of its component files.
Isolate bug by dividing up the ASDF file:
To investigate further, I started commenting out parts of Vecto's asdf file. As long as the components list is empty, asdf will load Vecto. (asdf:defsystem #:vecto :depends-on (#:cl-vectors #:zpng #:zpb-ttf) :version "1.4.10" :author "Zach Beane xach@xach.com" :description "Create vector graphics in PNG files." :license "BSD" :components ())
But adding a file to the components list will cause stack overflow. For example this will cause stack overflow:
(asdf:defsystem #:vecto :depends-on (#:cl-vectors #:zpng #:zpb-ttf) :version "1.4.10" :author "Zach Beane xach@xach.com" :description "Create vector graphics in PNG files." :license "BSD" :components ((:file "package")))
On Wed, Dec 14, 2016 at 8:54 AM Mirko Vukovic mirko.vukovic@gmail.com wrote:
See below:
On Tue, Dec 13, 2016 at 10:45 PM Mirko Vukovic mirko.vukovic@gmail.com wrote:
Hello,
I have installed ABCL 1.4 on Windows 10 and Java 1.7.
When loading some libraries, I get a stack overflow error.
For example loading vecto fails
vecto passes the cl-test-grid on linux (see https://common-lisp.net/project/cl-test-grid/library/vecto.html)
I did a bit more probing to try and isolate the cause of the overflow:
- ASDF file manually loads and compiles
- I could manually load all the pre-requisite libraries
- I could manually compile and load all the lisp files
Looking at the error message in frame 8 (see below), the cause may be in the slime/swank interaction with abcl.
I may take this up at the slime mailing list.
Running (asdf:load-system :vecto)
Gives: Stack overflow. [Condition of type STORAGE-CONDITION]
Restarts: 0: [*ABORT] Return to SLIME's top level. 1: [ABORT] Abort thread.
Backtrace: 0: (#<FUNCTION {BEB670}> #<STORAGE-CONDITION {14AA1B6}> #<FUNCTION {BEB670}>) 1: (APPLY #<FUNCTION {BEB670}> (#<STORAGE-CONDITION {14AA1B6}> #<FUNCTION {BEB670}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<STORAGE-CONDITION {14AA1B6}> #<FUNCTION {BEB670}>) 3: (INVOKE-DEBUGGER #<STORAGE-CONDITION {14AA1B6}>) 4: org.armedbear.lisp.Lisp.stackError(Lisp.java:388) 5: org.armedbear.lisp.swank_513.execute(swank.lisp:1677) 6: org.armedbear.lisp.LispThread.execute(LispThread.java:851) 7: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2800) 8: (SWANK:EVAL-FOR-EMACS (SWANK-REPL:LISTENER-EVAL "(asdf:load-system :vecto) ") "COMMON-LISP-USER" 9) etc