On 12/14/16 14:54, Mirko Vukovic 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.

[…]

...

8: (SWANK:EVAL-FOR-EMACS (SWANK-REPL:LISTENER-EVAL "(asdf:load-system :vecto) ") "COMMON-LISP-USER" 9)

[…]

I don't think that SLIME is the culprit from that stack frame, which is merely the act of SLIME eval'ing the ASDF:LOAD-SYSTEM form.

Unfortunately, I can't replicate your problem. I don't have access to Windows 10, but for my closest version of Java7

CL-USER(5): (lisp-implementation-version) (lisp-implementation-version) "1.4.0" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_111-b01" "amd64-FreeBSD-11.0-RELEASE-p1"

The form

(ql:quickload :vecto)

succeeds for me with

CL-USER(1): (ql:quickload :vecto) (ql:quickload :vecto) To load "vecto": Install 5 Quicklisp releases: cl-vectors salza2 vecto zpb-ttf zpng ; Fetching #<QL-HTTP:URL "http://beta.quicklisp.org/archive/salza2/2013-07-20/salza2-2.0.9.tgz%22%3E ; 15.16KB ================================================== 15,525 bytes in 0.0 seconds (1684.57KB/sec) ; Fetching #<QL-HTTP:URL "http://beta.quicklisp.org/archive/zpng/2015-04-07/zpng-1.2.2.tgz%22%3E ; 39.20KB ================================================== 40,141 bytes in 0.00 seconds (13066.73KB/sec) ; Fetching #<QL-HTTP:URL "http://beta.quicklisp.org/archive/zpb-ttf/2013-07-20/zpb-ttf-1.0.3.tgz%22%3E ; 43.82KB ================================================== 44,869 bytes in 0.00 seconds (14605.79KB/sec) ; Fetching #<QL-HTTP:URL "http://beta.quicklisp.org/archive/cl-vectors/2015-04-07/cl-vectors-20150407-... ; 30.70KB ================================================== 31,440 bytes in 0.17 seconds (180.61KB/sec) ; Fetching #<QL-HTTP:URL "http://beta.quicklisp.org/archive/vecto/2014-11-06/vecto-1.4.10.tgz%22%3E ; 62.84KB ================================================== 64,346 bytes in 0.27 seconds (235.35KB/sec) ; Loading "vecto" [package net.tuxee.aa]............................ [package net.tuxee.aa-bin]........................ [package net.tuxee.paths]......................... [package net.tuxee.vectors]....................... [package salza2].................................. [package zpng].................................... [package zpb-ttf]......; Note: deleting unused local function FLET QUIETLY-CLOSE ; in (DEFUN ARRANGE-FINALIZATION ...)

; Caught STYLE-WARNING: ; The variable OBJECT is defined but never used.

; Caught STYLE-WARNING: ; The variable STREAM is defined but never used.

; in (DEFUN OPEN-FONT-LOADER-FROM-STREAM ...)

; Caught STYLE-WARNING: ; The variable CHECKSUM is defined but never used.

; Caught COMPILE-WARNED-WARNING: ; Lisp compilation had style-warnings while compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "zpb-ttf" "font-loader-interface">

........................... [package vecto].. ; in (DEFUN DRAW-ARC-CURVES ...)

; Caught STYLE-WARNING: ; The variable X1 is defined but never used.

; Caught STYLE-WARNING: ; The variable Y1 is defined but never used.

. ; Caught COMPILE-WARNED-WARNING: ; Lisp compilation had style-warnings while compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "vecto" "user-drawing">

; Compilation unit finished ; Caught 2 WARNING conditions ; Caught 5 STYLE-WARNING conditions ; The following functions were used but not defined: ; NET.TUXEE.AA::COPY-CELL

(:VECTO)

Have you tried just loading VECTOR (and its declared Quicklisp dependendencies) to eliminate other code as the source of the error?

You may want to try with Java8 to see if that makes any difference.

P.S. Unless you are subscribed to https://mailman.common-lisp.net/listinfo/armedbear-devel, someone (me, usually) needs to approve your messages to the mailing list manually, so there will be a delay in your messages.

Could it be some path-related problem (e.g. spaces in the path, a very long path, unusual characters in the path, ...)?

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

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