On Tue, Dec 20, 2016 at 9:55 AM Alessio Stalla <alessiostalla@gmail.com> wrote:
Hmm, I wasn't actually expecting that :P maybe try updating SLIME... or perhaps this rings a bell for someone using ABCL on Windows regularly.

This was with latest slime (of November 9).  I'll ask on the Slime list


Il 20 dic 2016 14:32, "Mirko Vukovic" <mirko.vukovic@gmail.com> ha scritto:


On Tue, Dec 20, 2016 at 8:25 AM Alessio Stalla <alessiostalla@gmail.com> wrote:
You could try without SLIME, from the bare REPL. Not that SLIME breaks anything, but maybe you'll get a more understandable stack trace.

Brilliant!  Vecto loads in the Command Window (see below).  What now?

CL-USER(1): (asdf:load-system :vecto)
; Compiling C:/Users/977315/quicklisp/dists/quicklisp/software/vecto-1.4.10/package.lisp ...
; (DEFPACKAGE #:VECTO ...)
; Wrote C:/Users/977315/AppData/Local/cache/common-lisp/abcl-1.4.0-fasl42-win-x86/C/Users/977315/quicklisp/dists/quicklisp/software/vecto-1.4.10/package-tmpKHDC356G.abcl (0.036 seconds)
; Compiling C:/Users/977315/quicklisp/dists/quicklisp/software/vecto-1.4.10/utils.lisp ...
; (IN-PACKAGE #:VECTO)
; (DEFUN CLAMP-RANGE ...)
; (DEFUN FLOAT-OCTET ...)
; (DEFUN OCTET-FLOAT ...)
; (DEFVAR *HYPERDOC-BASE-URI* ...)
; (LET (#) ...)
 

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
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

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