armedbear-devel

armedbear-devel@common-lisp.net

1199 discussions

Re: stack overflow error on library load
by Alessio Stalla 20 Dec '16

20 Dec '16

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. Il 20 dic 2016 14:32, "Mirko Vukovic" <mirko.vukovic(a)gmail.com> ha scritto: > > > On Tue, Dec 20, 2016 at 8:25 AM Alessio Stalla <alessiostalla(a)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(a)gmail.com> >> wrote: >> >> >> >> On Tue, Dec 20, 2016 at 6:17 AM Alessio Stalla <alessiostalla(a)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(a)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(a)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(a)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(a)gmail.com> >> wrote: >> >> See below: >> >> On Tue, Dec 13, 2016 at 10:45 PM Mirko Vukovic <mirko.vukovic(a)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 >> >> >> >>

2 1

stack overflow error on library load
by Mirko Vukovic 20 Dec '16

20 Dec '16

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

3 6

quicklisp not finding systems in local-projects
by Mike Maul 25 Nov '16

25 Nov '16

Tried in version 1.4 and also built from source.

2 3

[HEADS UP] Fasl bump needed for working on TRUNK for recording SYS:SOURCE information
by Mark Evenson 24 Nov '16

24 Nov '16

HEADS-UP: the fasl version has been bumped on TRUNK for those of you following along at home. Alan Ruttenberg's [enhancements to record source information][415] have now been merged. [415]: http://abcl.org/trac/ticket/415 The interface to recording information on the SYS:%SOURCE plist for a symbol is now deprecated and will be removed with abcl-1.7. Source information for ABCL is now recorded on the SYS:SOURCE property. The appropiate information for type is recorded by the SYS:RECORD-SOURCE-INFORMATION-BY-TYPE function Now we just have to change SLIME… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Java-9 support
by Mark Evenson 22 Nov '16

22 Nov '16

Curious about what exactly our situation running on Java 9 would be, I took a stab at compiling/running ABCL under: "1.5.0-dev" "Java_HotSpot(TM)_64-Bit_Server_VM-Oracle_Corporation-9-ea+145" "x86_64-Mac_OS_X-10.12.1" The good news is that setting the javac source/target to "1.6" seems to be fine, so the assertion that the compiler will continue to work, albeit inefficiently as noted by Alessio, seems to be born out. The bad news is that due to the changes for "Project Jigsaw" aka [modular-runtime-images][], ABCL can no longer load ABCL-CONTRIB and therefore prevents ASDF from working. The root problem stems from Java 9 no longer using jar archives for system classes, which means that the boot classloader is no longer a descendant of URLClassloader which our current code relies on. Ticket [424][] tracks this issue, containing a patch that at least gets ABCL compiled/running the base ANSI system under Java 9. [423]: http://abcl.org/trac/ticket/423 [modular-runtime-images] https://bugs.openjdk.java.net/browse/JDK-8061971 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Re: SYS:RUN-PROGRAM does not work on pre-Java7 JVMs (was Re: abcl-1.4.0 released)
by Mark Evenson 22 Nov '16

22 Nov '16

On 11/18/16 18:25, Scott Burson wrote: > It's not a miracle at all. JVMs have always been backward-compatible with > older classfiles. The big Java app I work on for my day job is mostly > compiled for 1.8, but ships with libraries compiled for earlier targets. > We've never had the slightest trouble as a result. You only need to > generate a newer bytecode version if you want to use a new feature (like > InvokeDynamic -- wasn't Alessio working on that?). I now accept Scott's reasoning on this: ORCL will probably have to maintain bytecode compatibility for a long time, otherwise there would be chaos with existing libraries that are available binary-only. In practice, most of the libraries are distributed by Maven are effectively binary-only, as the steps to build from source are not always clear or documented. Plus many commercial vendors distribute applications as jars. When we compile our Java, we do get the following warnings: abcl.compile.java: Compiling 1 source file to /Users/evenson/work/abcl/build/classes warning: [options] bootstrap class path not set in conjunction with -source 1.5 warning: [options] source value 1.5 is obsolete and will be removed in a future release warning: [options] target value 1.5 is obsolete and will be removed in a future release warning: [options] To suppress warnings about obsolete options, use -Xlint:-options. which indicates to me that at some point in the future, JDK-N (where N is greater than 9) will not compile to JDK5 bytecode anymore. Can anyone point to a statement of what ORCL intends here for obsolescence? --- As for the compatiblity problems with SYS:RUN-PROGRAM, my current propose is from <http://abcl.org/trac/ticket/422#comment:1>: 1. Un-deprecate SYS:RUN-SHELL-COMMAND. Use the pre Java 7 APIs as best we can to support invoking programs, which essentially boils down to being able to take a string, attempt to invoke it, and return its stdout as a string. 2. Re-code the SYS:RUN-PROGRAM Java callsite linkages so that ABCL may be compiled on pre-Java7 JDKs. Produce an intelligible error if it is invoked on a pre-Java7 JVM. 3. Create an API to determine runtime JVM version. Wrap UIOP/RUN-PROGRAM invocation in some sort of handler that will "fall back" to using SYS:RUN-SHELL-COMMAND if it has compatible behavior via specified args. This will potentially be fairly ugly code ASDF-side so we might provide a shim that UIOP/RUN-PROGRAM invokes that contains the logic outside the ASDF code base. Any objections to this path forward? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

5 6

abcl-1.4.0 released
by Mark Evenson 18 Nov '16

18 Nov '16

With a decided chill noticeable in the Northern Hemisphere, the Bear has finally sloughed off a long-needed release of ABCL. With abcl-1.4.0, CFFI now works reliably allowing cross-platform linkage to native libraries to be initiated dynamically at runtime. Examples of using CL-CUDA to follow as their authors have time to publish. Considerable work and testing led by Elias Pipping with contributions Olof-Joachim Frahm has led to a reasonable basis for UIOP/RUN-PROGRAM compatibility. We have taken the time to learn enough of Maven to publish binary artifacts for both abcl.jar and abcl-contrib.jar that allow developers everywhere to more easily incorporate the Bear into their local Java build tool chains. And we have tentatively surrendered to the current fashion by establishing GIT bridges to the ABCL source at and to more easily facilitate Version 1.4.0 ============= http://abcl.org/svn/tags/1.4.0/ http://abcl.org/trac/changeset/14892 08-OCT-2016 Enhancements ============ * Consolidated RUN-PROGRAM fixes (ferada, pipping) * Upstream consolidated patchset (ferada) ** [r14857] Support `FILE-POSITION` on string streams. ** [r14859] Add multiple disassembler selector. ** [r14860] Add EXTERNAL-ONLY option to APROPOS. ** [r14861] Fix nested classes from JARs not visible with JSS. * [r14840-2] (Scott L. Burson) Introduced "time of time" semantics for {encode,decode}-universal time. * EXTENSIONS:MAKE-TEMP-FILE now takes keyword arguments to specify values of the prefix and suffix strings to the underlying JVM implementation of java.io.File.createTempFile(). * [r14849] EXT:OS-{UNIX,WINDOWS}-P now provide a pre-ASDF runtime check on hosting platform Fixes ----- * [r14863] RandomCharacterFile et. al. * [r14839] (JSS) Ensure the interpolation of Java symbol names as strings (alan ruttenberg) * [r14889] Fix ANSI-TEST SXHASH.8 (dmiles) Updates ------ * asdf-3.1.7.26 * jna-4.2.2 Removed ------- * [r14885] ASDF-INSTALL was removed -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 10

Mucking around with compilation
by Alan Ruttenberg 17 Nov '16

17 Nov '16

I got curious about how I might generate better code for JSS. The JSS reader macro generates a lambda, so the typical pattern one sees is: (#"matches" 'integer ".*a" ) -> ((LAMBDA (#:|#"matches"-first| &REST #:|#"matches"-rest|) (JSS:INVOKE-RESTARGS "matches" #:|#"matches"-first| #:|#"matches"-rest| NIL)) 'INTEGER ".*a") (yes I know this will generate an error at runtime) Right now the compiled code for one such call goes through 3 functions: (JSTATIC "matches" #<java class java.lang.Integer {3BBD30F}> ".*a") (APPLY #<JSTATIC {41D16045}> "matches" #<java class java.lang.Integer {3BBD30F}> (".*a")) (INVOKE-RESTARGS "matches" INTEGER (".*a") NIL) Really we only need: (JSTATIC "matches" #<java class java.lang.Integer {3BBD30F}> ".*a") and we know enough at compile time to generate that form. If only I could figure out where the right hook would be. The only place I could figure to do this is in precompile-function-call [1] With a hook in place, i define the hook as [2] After checking if the function call is one of the JSS ones, the hook transforms ((lambda(a b ) (jss::invoke-restargs-experimental method a b raw?) c d) to (jss::invoke-restargs-experimental method c '(d) raw? t) jss::invoke-restargs-experimental is macro that does the transformation I want. [3] The question is: Is there a more elegant way to do this, or a hook already built that I could use instead of redefining precompile-function-call If not, would it be reasonable to add a hook in the ABCL source so I don't need to patch it to do the optimization. Thanks, Alan [1] (defun precompile-function-call (form) (let ((op (car form))) (when (and (consp op) (eq (%car op) 'LAMBDA)) (return-from precompile-function-call I added this line --- (or (jss-fix-precompile op (mapcar #'precompile1 (cdr form))) --- (cons (precompile-lambda op) (mapcar #'precompile1 (cdr form)))))) (when (or (not *in-jvm-compile*) (notinline-p op)) (return-from precompile-function-call (precompile-cons form))) (when (source-transform op) (let ((new-form (expand-source-transform form))) (when (neq new-form form) (return-from precompile-function-call (precompile1 new-form))))) (when *enable-inline-expansion* (let ((expansion (inline-expansion op))) (when expansion (let ((explain *explain*)) (when (and explain (memq :calls explain)) (format t "; inlining call to ~S~%" op))) (return-from precompile-function-call (precompile1 (expand-inline form expansion)))))) (cons op (mapcar #'precompile1 (cdr form))))) [2] (defun jss-fix-precompile (op args) "Check if this is one of mine, and do the rewrite, otherwise pass" (ignore-errors (let ((body (cddr op))) (if (and (= (length body) 1) (consp (car body)) (eq (caar body) 'jss::invoke-restargs-experimental)) (precompile-function-call `(jss::invoke-restargs-experimental ,(second (car body)) ,(car args) ,(cdr args) ,(fifth (car body)) t)) nil)))) [3] (defmacro invoke-restargs-experimental (&whole form method object args &optional (raw? nil) (precompile nil)) "If I'm precompiling then I can do the transformation. If not I revert to the original method" (if precompile (if (and (consp object) (eq (car object) 'quote)) (let ((object (eval object))) (let* ((object-as-class-name (if (symbolp object) (maybe-resolve-class-against-imports object) )) (object-as-class (if object-as-class-name (find-java-class object-as-class-name)))) (cl-user::print-db object object-as-class-name object-as-class) (if raw? `(jstatic-raw ,method ,object-as-class ,@args) `(jstatic ,method ,object-as-class ,@args)))) (if raw? `(if (symbolp ,object) (jstatic-raw ,method (find-java-class ,object) ,@args) (jcall-raw ,method ,object ,@args)) `(if (symbolp ,object) (jstatic ,method (find-java-class ,object) ,@args) (jcall ,method ,object ,@args)))) `(invoke-restargs ,method ,object ,args ,raw?)))

4 12

10th European Lisp Symposium, April 3-4 2017, Brussels, Belgium
by Didier Verna 07 Nov '16

07 Nov '16

ELS'17 - 10th European Lisp Symposium VUB - Vrije Universiteit Brussel Belgium April 3-4, 2017 In co-location with <Programming> 2017 http://www.european-lisp-symposium.org/ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 10th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. The conference proceedings will be published in the ACM Digital Library. Important dates: - 30 Jan 2017 Submission deadline - 27 Feb 2017 Notification of acceptance - 20 Mar 2017 Final papers due - 03-04 Apr 2017 Symposium Programme chair: Alberto Riva, University of Florida, USA Programme committee: tba Search Keywords: #els2017, ELS 2017, ELS '17, European Lisp Symposium 2017, European Lisp Symposium '17, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2017, European Lisp Conference '17 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Created github armedbear group
by Mark Evenson 28 Oct '16

28 Oct '16

I have transferred the repository formally known as <https://github.com/easye/abcl/> to the new "armedbear" Github group <https://github.com/armedbear/abcl/> (unfortunately the shorter group "abcl" was taken). This Git repository is maintained as a two-way bridge from the official [ABCL history in SVN][svn] [svn]: http://abcl.org/svn Issues were being filed against the github account, so I wanted to at least rename their URIs to something that would be sustainable in the future. I intend to maintain the [Trac issue][1]/[github issue][2] correspondence until I can figure out a migration strategy that makes sense with the resources I have. It is important to me to maintain the existing URIs which refer to aspects of ABCL development as live links, so my plan is to somehow redirect everything that has been published and indexed by crawlers via some sort of mediating redirect service as the underlying technologies change and I get the resources to maintain things. [1]: http://abcl.org/trac/ticket/414 [2]: https://github.com/armedbear/abcl/issues/3 For the possible contributors to abcl, the process for use of Git is quite simple: just use the Github ABCL repository as you would any other open source project, contributing code via pull requests on Github. We'll take care of the release engineering, ensuring that everything gets consolidated into a reasonable release branch. happy hacking, Mark P.S. Anyone who wants to provide me with a github id to be a member of the Armedbear group via out-of-band means is welcome. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel