- armedbear-devel - mailman3.common-lisp.net

bug: compiled function behaves differently than interpreted
by samuel.edwin.ward＠gmail.com 13 Dec '24

13 Dec '24

I initially discovered this in 1.9.2 with slime and all that, but I reproduced this on a build of d0a525323b640223bacfb17cde59db995f43cce9 from GitHub with ./abcl --noinit. I don't have a completely minimized case, but it's pretty small. uname -a: Darwin sew-MBA.local 24.1.0 Darwin Kernel Version 24.1.0: Thu Oct 10 21:05:14 PDT 2024; root:xnu-11215.41.3~2/RELEASE_ARM64_T8103 arm64 Reproduction: Armed Bear Common Lisp 1.9.3-dev Java 23.0.1 Homebrew OpenJDK 64-Bit Server VM Low-level initialization completed in 0.158 seconds. Startup completed in 0.698 seconds. Type ":help" for a list of available commands. CL-USER(1): (setq class (jcall "arrayType" (jstatic "forPrimitiveName" "java.lang.Class" "float"))) #<java.lang.Class class [F {6290834B}> CL-USER(2): (defun represent (class) (cond ((jcall "isPrimitive" class) (intern (string-upcase (jcall "getName" class)) "KEYWORD")) ((jcall "isArray" class) (list :array (represent (jcall "componentType" class)))) (t (jcall "getName" class)))) REPRESENT CL-USER(3): (represent class) (:ARRAY :FLOAT) CL-USER(4): (compile 'represent) REPRESENT NIL NIL CL-USER(5): (represent class) :FLOAT :EXTERNAL CL-USER(6): I think the interpreted result is correct, but either way it seems like a bug that they're different. My story gets stranger. I tried to reproduce it with DRIBBLE (for this email) and I couldn't: COMMON-LISP-USER> (setq class (jcall "arrayType" (jstatic "forPrimitiveName" "java.lang.Class" "float"))) #<java.lang.Class class [F {194B1E17}> COMMON-LISP-USER> (defun represent (class) (cond ((jcall "isPrimitive" class) (intern (string-upcase (jcall "getName" class)) "KEYWORD")) ((jcall "isArray" class) (list :array (represent (jcall "componentType" class)))) (t (jcall "getName" class)))) REPRESENT COMMON-LISP-USER> (represent class) (:ARRAY :FLOAT) COMMON-LISP-USER> (compile 'represent) REPRESENT COMMON-LISP-USER> (represent class) (:ARRAY :FLOAT) COMMON-LISP-USER> (dribble) If it's any help, I tried re-implementing the function a number of ways, and this was the first one I found that didn't exhibit the problem: (defun represent (class) (if (jcall "isArray" class) (let*((component (jcall "componentType" class)) (mangled (represent component))) (list :array mangled)) (let ((classname (jcall "getName" class))) (if (jcall "isPrimitive" class) (alexandria:make-keyword (string-upcase classname)) (jcall "getName" class))))) Thanks all!

1 0

[CfP] ELS'25, 18th European Lisp Symposium, May 19-20, Zurich
by Didier Verna 10 Dec '24

10 Dec '24

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 18th European Lisp Symposium Call for Papers May 19-20 2025 SGH, Zurich, Switzerland https://www.european-lisp-symposium.org/2025 Sponsered by SGH ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Special Focus ~~~~~~~~~~~~~ This year, we suggest a special focus on artifical intelligence, and meta-programming beyond macros. Invited Speakers ~~~~~~~~~~~~~~~~ Anurag Mendhekar Joerg Gutknecht Important Dates ~~~~~~~~~~~~~~~ - Registration opens: Dec 10 2024 - Submission deadline: Mar 02 2025 - Author notification: Mar 30 2025 - Final papers due: Apr 13 2025 - Early Registration: May 04 2025 - Symposium: May 19-20 2025 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation, and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 Technical Program ~~~~~~~~~~~~~~~~~ We invite submissions in the following forms. Papers and experience reports must not overlap significantly with the authors’ previously published work in a peer reviewed publication, and must not be under review on another journal or conference. Also, authors must agree with our publication ethics and malpractice statement (cf. https://european-lisp-symposium.org/pepms.html). * Papers: technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. * Experience reports: papers of up to 6 pages describing a successful use of a Lisp dialect and/or analyzing obstacles that have kept it from working in practice. * Tutorials: abstracts of up to 4 pages for in-depth presentations about topics of special interest. * Demonstrations: abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. For information on the submission format, please refer to the "Submission" section at https://www.european-lisp-symposium.org/2025. Submissions should be uploaded to Easy Chair at the following link: http://www.easychair.org/conferences/?conf=els2025. Note: to help us with the review process please indicate the type of submission in the title field in the submission form. Programme Chair ~~~~~~~~~~~~~~~ François-René Rideau Đặng-Vũ Bân, MuKn, USA Organizing Chair ~~~~~~~~~~~~~~~~ Didier Verna, EPITA / LRE, France Programme Committee ~~~~~~~~~~~~~~~~~~~ Conrad Barski, USA Marc Battyani, Enfabrica, USA Dave Cooper, Genworks, USA Ryan Culpepper, University of Massachusetts Boston, USA Eitaro Fukamachi, Japan Robert Goldman, SIFT, USA Gavin Gray, Brown University, USA Jason Hemann, Seton Hall University, USA Kristopher Micinski, Syracuse University, USA Marco Morazan, Seton Hall University, USA Michael Raskin, LaBRI, France Masatoshi Sano, Nayuta, Japan Dimitris Vyzovitis, Mighty Gerbils Local Chair ~~~~~~~~~~~ Yukari Hafner, Shirakumo.org, Switzerland Virtualization Team ~~~~~~~~~~~~~~~~~~~ Georgiy Tugai, Configura, Sweden Yukari Hafner, Shirakumo.org, Switzerland -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Problem linking ABCL code into a larger Java program
by Robert Goldman 14 Nov '24

14 Nov '24

I've been trying to resuscitate some old code that used some functions I wrote in ABCL into a larger Java system (if anyone cares, the PRISM probabilistic model checker). I'm getting the following error message: ``` ; Compiling jar:file:///Users/rpg/projects/matrics/prism/prism/lib/abcl-contrib.jar!/asdf-jar/package.lisp ... ; (DEFPACKAGE #:ASDF-JAR ...) ; Wrote /Users/rpg/.cache/common-lisp/abcl-1.9.2-fasl43-macosx-arm64/Users/rpg/projects/matrics/prism/prism/lib/abcl-contrib.jar/asdf-jar/package-tmp1FUW82KK.abcl (0.022 seconds) ; Compiling jar:file:///Users/rpg/projects/matrics/prism/prism/lib/abcl-contrib.jar!/asdf-jar/asdf-jar.lisp ... ; (IN-PACKAGE #:ASDF-JAR) ; (DEFUN ADD-SYSTEM-FILES-TO-MAPPING! ...) ; (DEFUN SYSTEMS->HASH-TABLE ...) ; (DEFUN PACKAGE ...) ; (DEFUN ALL-FILES ...) ; (DEFUN RESOLVE-SYSTEM-OR-FEATURE ...) ; (DEFUN DEPENDENT-SYSTEMS ...) ; (DEFUN ARCHIVE-RELATIVE-PATH ...) ; (DEFUN TMPDIR ...) ; (DEFUN ADD-TO-ASDF ...) ; (DEFUN PREPARE-FOR-WAR ...) ; Wrote /Users/rpg/.cache/common-lisp/abcl-1.9.2-fasl43-macosx-arm64/Users/rpg/projects/matrics/prism/prism/lib/abcl-contrib.jar/asdf-jar/asdf-jar-tmpLI46SF5K.abcl (0.206 seconds) #<THREAD "main" native {753AACF}>: Debugger invoked on condition of type TYPE-ERROR The value #<jdk.internal.loader.ClassLoaders$AppClassLoader jdk.internal.loader.ClassLoaders.... {6470078D}> is not of type LIST. [1] CL-USER(1): Exception trying to start ABCL PRISM! ``` backtrace: [gist here](https://gist.github.com/rpgoldman/c50f2d371386d13d4a98e2fe84a86be5") This is Java 23, and I suspect I should be trying an earlier version, but I'm not sure what one. I'm really barely literate in Java, which is why I wrote the code in question in ABCL instead of Java, so I apologize if this question is just plain stupid. Thanks for any clues

1 0

ABCL in a multi-threading environment
by Blake McBride 19 Sep '24

19 Sep '24

Hello, I have a multi-threading Java application (like a web server). ABCL is already added to it but is not used too much. I have a particular need within that application that I think ABCL would be well suited for, but I first need to better understand how ABCL functions in a multithreading environment. What I need is as follows. I have some Lisp code and data that will be defined both by .lisp files and from within Java. This code and data will be used by a multi-threading Java application in a read-only way. However, the Java threads themselves need to be able to introduce Lisp data that must be unique to each thread and gets deleted when the thread ends (presumably by the GC). Is there a way to do this with ABCL? Thank you! Blake McBride

3 5

CDR for Package-Local Nicknames [Feedback Request]
by Alexander Fedorov 06 Jul '24

06 Jul '24

Dear all, Over 10 years ago, SBCL implemented the Package-Local Nicknames (PLNs) extension. Since then, PLNs have also been adopted by multiple implementations (ABCL, CCL, ECL, Clasp, Allegro CL and LispWorks) and are now widely used in many projects. However, PLNs are still considered experimental, as stated in the SBCL manual, since there is no formal specification for them, and each implementation interprets various corner cases differently. While the need for a specification has been previously discussed, I was unable to find any publicly accessible draft for one. Therefore, I have drafted a specification intended to become a CDR document. I initially wrote this draft about a year ago and have recently revised it. You can find the latest version here: https://gleefre.github.io/cdr-package-local-nicknames/index.html. There are currently nine unresolved standardization issues, each with at least one proposed resolution. Input on those issues would be particularly helpful, but any feedback is welcome! P.S. I am sharing this link across multiple platforms to reach as many lispers as possible. This includes various mailing lists (Lisp Pro, CDR-discuss and -devel for various CL implementations); IRC channels (#commonlisp and implementation-specific ones); the Lisp Discord server; several Telegram groups; and a post on Reddit. If you have any suggestions for additional places to share the link, please let me know. My apologies to those receiving this message multiple times. Best regards, Alexander Fedorov.

1 0

[Last CfP] 17th European Lisp Symposium, May 6-7 2024, Vienna
by Didier Verna 18 Feb '24

18 Feb '24

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 17th European Lisp Symposium Call for Papers May 6-7 2024 Federal Computing Center, Vienna, Austria https://www.european-lisp-symposium.org/2024 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: Feb. 25 2024 ** EXTENDED ** - Author notification: Mar. 24 2024 - Final papers due: Apr. 14 2024 - Symposium: May 6-7 2024 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation, and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 This year, we suggest an emphasis on best practices, approaches, and technologies for building highly recursive and self-adapting architectures, in particular for AI, ML, tool integration and instruction generation, using dynamic programming languages. Technical Program ~~~~~~~~~~~~~~~~~ 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. * Experience reports: papers of up to 6 pages describing a successful use of a Lisp dialect and/or analyzing obstacles that have kept it from working in practice. * Tutorials: abstracts of up to 4 pages for in-depth presentations about topics of special interest. * Demonstrations: abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following link http://www.easychair.org/conferences/?conf=els2024. Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Giuseppe Attardi, University of Pisa, Italy Organizing Chair ~~~~~~~~~~~~~~~~ Didier Verna, EPITA, France Programme Committee ~~~~~~~~~~~~~~~~~~~ Ambrose Bonnaire-Sergeant, Untypable LLC Frederic Peschanski, UPMC/LIP6 Jay McCarthy, UMass Lowell Jim Newton, EPITA Research Lab Kai Selgrad, OTH Regensburg Mark Evenson, not.org Michael Raskin, LaBRI/CNRS UMR 5800, University of Bordeaux Robert Smith, HRL Laboratories LLC Robert P. Goldman, SIFT LLC Stefan Monnier, Université de Montréal Local Chair ~~~~~~~~~~~ Philipp Marek, BRZ, Vienna, Austria Virtualization Team ~~~~~~~~~~~~~~~~~~~ Georgiy Tugai, Configura, Sweden Michal Herda, Poland Yukari Hafner, Shirakumo.org, Switzerland -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info

1 0

[CfP] 17th European Lisp Symposium, May 6-7 2024, Vienna, Austria
by Didier Verna 19 Jan '24

19 Jan '24

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 17th European Lisp Symposium Call for Papers May 6-7 2024 Federal Computing Center, Vienna, Austria https://www.european-lisp-symposium.org/2024 Sponsored by EPITA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: Feb. 18 2024 - Author notification: Mar. 24 2024 - Final papers due: Apr. 14 2024 - Symposium: May 6-7 2024 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation, and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 This year, we suggest an emphasis on best practices, approaches, and technologies for building highly recursive and self-adapting architectures, in particular for AI, ML, tool integration and instruction generation, using dynamic programming languages. Technical Program ~~~~~~~~~~~~~~~~~ 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. * Experience reports: papers of up to 6 pages describing a successful use of a Lisp dialect and/or analyzing obstacles that have kept it from working in practice. * Tutorials: abstracts of up to 4 pages for in-depth presentations about topics of special interest. * Demonstrations: abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following link http://www.easychair.org/conferences/?conf=els2024. Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Giuseppe Attardi, University of Pisa, Italy Programme Committee ~~~~~~~~~~~~~~~~~~~ Ambrose Bonnaire-Sergeant, Untypable LLC Frederic Peschanski, UPMC/LIP6 Jay McCarthy, UMass Lowell Jim Newton, EPITA Research Lab Kai Selgrad, OTH Regensburg Mark Evenson, not.org Michael Raskin, LaBRI/CNRS UMR 5800, University of Bordeaux Robert Smith, HRL Laboratories LLC Robert P. Goldman, SIFT LLC Stefan Monnier, Université de Montréal Local Chair ~~~~~~~~~~~ Philipp Marek, BRZ, Vienna, Austria Virtualization Team ~~~~~~~~~~~~~~~~~~~ Georgiy Tugai, Configura, Sweden Michał Herda, Poland Yukari Hafner, Shirakumo.org, Switzerland -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info

1 0

abcl.org/trac/* being spidered by multiple bots
by Erik Huelsmann 10 Jan '24

10 Jan '24

Hi Mark, Last night a number of disruptions in cliki.net availability were reported, a happens regularly lately -- and definitely during the weekly backup. So I checked the server this morning. The server had a load of 50 (>15 per cpu); 80% of that was going to Trac, however the access log trac.common-lisp.net_access.log was silent. Turns out all the traffic was on abcl.org. It was being spidered like crazy. Trac - or our server setup (or both) - really isn't up to that task, which is why there is only limited spidering allowed on trac.common-lisp.net. (Enough to spider "current" trunk of projects and their issues.) To restrict spidering, I've changed the robots.txt file at /project/armedbear/public_html/robots.txt. Could you please commit that robots.txt (or an even stricter one) to the repository that the site is being synced from? Thanks! Regards, Erik.

3 2

Unwrapping Java Character to char
by Robert Dodier 05 Jan '24

05 Jan '24

Hi, is there a way to unwrap a Java boxed value to get the Java primitive value inside it? In particular I am interested in obtaining the char inside a Character, in order to supply the char to a method which requires a char. Thanks for any info, Robert

3 8

Fwd: armedbear-devel@common-lisp.net post from ale2014.zamora@gmail.com requires approval
by Mark Evenson 04 Jan '24

04 Jan '24

[Attached find Alejandro’s reply for completeness. I need to redo my credentials to the admin dashboard to forward cleanly which is going to take an unknown amount of time] > Begin forwarded message: > > From: armedbear-devel-owner(a)common-lisp.net > Subject: armedbear-devel(a)common-lisp.net post from ale2014.zamora(a)gmail.com requires approval > Date: January 3, 2024 at 21:25:42 GMT+1 > To: armedbear-devel-owner(a)common-lisp.net > > As list administrator, your authorization is requested for the > following mailing list posting: > > List: armedbear-devel(a)common-lisp.net > From: ale2014.zamora(a)gmail.com > Subject: Re: Associating names with characters for named Unicode characters > > The message is being held because: > > The message is larger than the 40 KB maximum size > > At your convenience, visit your dashboard to approve or deny the > request. > > From: Alejandro Zamora Fonseca <ale2014.zamora(a)gmail.com> > Subject: Re: Associating names with characters for named Unicode characters > Date: January 3, 2024 at 21:25:21 GMT+1 > To: Robert Dodier <robert.dodier(a)gmail.com> > Cc: Armed Bear <armedbear-devel(a)common-lisp.net> > > > Hi Robert > > Probably not completely related but I made a small library to handle with Unicode details with ABCL https://github.com/alejandrozf/abcl-utils > > Maybe that might help you in the association you want to make. > > > Best, > > Alejandro > > El mié, 3 ene 2024 a las 16:51, Robert Dodier (<robert.dodier(a)gmail.com <mailto:robert.dodier@gmail.com>>) escribió: >> Hi, I wonder if there is a way to associate a name with a character at >> run time in ABCL. >> >> I am interested in working with Unicode characters which have names, >> e.g. BOX DRAWINGS LIGHT HORIZONTAL and others listed in the document >> at: https://www.unicode.org/charts/PDF/U2500.pdf >> >> I am thinking it would be great if I could refer to such characters by >> name, e.g.: #\BOX_DRAWINGS_LIGHT_HORIZONTAL. It appears that such >> names are not defined in ABCL; I'm looking for a way to define them at >> run time. >> >> >From looking at the source code, maybe it's possible via the >> setCharName static method in org.armedbear.lisp.LispCharacter. >> However, when I try to get a reference to setCharName, I get an error: >> >> CL-USER(10): (java:jstatic "setCharName" "org.armedbear.lisp.LispCharacter") >> #<THREAD "interpreter" native {48616CA1}>: Debugger invoked on >> condition of type ERROR >> No such static method: org.armedbear.lisp.LispCharacter.setCharName() >> >> I thought maybe the problem there is that setCharName isn't declared >> public, but I tried the same operation with a declared public static >> method and I get the same error: >> >> CL-USER(12): (java:jstatic "getInstance" "org.armedbear.lisp.LispCharacter") >> #<THREAD "interpreter" native {48616CA1}>: Debugger invoked on >> condition of type ERROR >> No such static method: org.armedbear.lisp.LispCharacter.getInstance() >> >> so maybe I am not going about that correctly. >> >> setCharName modifies the lookup table >> org.armedbear.lisp.LispCharacter.lispChars -- I'm sure it's not >> recommended, but maybe I can put new entries into it directly; can >> someone give me a hint as to the appropriate incantation in Lisp? >> lispChars is declared public static so it seems like it should be >> possible, if I can craft the appropriate method call to >> org.armedbear.lisp.CharHashMap.put. >> >> Thanks for any info, >> >> Robert > > > > > > -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

Re: Associating names with characters for named Unicode characters
by Robert Dodier 03 Jan '24

03 Jan '24

Alejandro, thanks a lot for your reply. Is there a way, in abcl-utils, to inform the Lisp reader to recognize named characters such as #\BOX_DRAWINGS_LIGHT_HORIZONTAL in source code? That is the ultimate goal I am seeking. best, Robert

2 2

Associating names with characters for named Unicode characters
by Robert Dodier 03 Jan '24

03 Jan '24

Hi, I wonder if there is a way to associate a name with a character at run time in ABCL. I am interested in working with Unicode characters which have names, e.g. BOX DRAWINGS LIGHT HORIZONTAL and others listed in the document at: https://www.unicode.org/charts/PDF/U2500.pdf I am thinking it would be great if I could refer to such characters by name, e.g.: #\BOX_DRAWINGS_LIGHT_HORIZONTAL. It appears that such names are not defined in ABCL; I'm looking for a way to define them at run time. From looking at the source code, maybe it's possible via the setCharName static method in org.armedbear.lisp.LispCharacter. However, when I try to get a reference to setCharName, I get an error: CL-USER(10): (java:jstatic "setCharName" "org.armedbear.lisp.LispCharacter") #<THREAD "interpreter" native {48616CA1}>: Debugger invoked on condition of type ERROR No such static method: org.armedbear.lisp.LispCharacter.setCharName() I thought maybe the problem there is that setCharName isn't declared public, but I tried the same operation with a declared public static method and I get the same error: CL-USER(12): (java:jstatic "getInstance" "org.armedbear.lisp.LispCharacter") #<THREAD "interpreter" native {48616CA1}>: Debugger invoked on condition of type ERROR No such static method: org.armedbear.lisp.LispCharacter.getInstance() so maybe I am not going about that correctly. setCharName modifies the lookup table org.armedbear.lisp.LispCharacter.lispChars -- I'm sure it's not recommended, but maybe I can put new entries into it directly; can someone give me a hint as to the appropriate incantation in Lisp? lispChars is declared public static so it seems like it should be possible, if I can craft the appropriate method call to org.armedbear.lisp.CharHashMap.put. Thanks for any info, Robert

1 0

BUG: stack inconsistency during compilation
by Eric Marsden 23 Nov '23

23 Nov '23

Hi, Armed Bear Common Lisp 1.9.3-dev Java 17.0.9 Debian OpenJDK 64-Bit Server VM Low-level initialization completed in 0.151 seconds. Startup completed in 0.876 seconds. Type ":help" for a list of available commands. CL-USER(1): (defvar *s*) *S* CL-USER(2): (defun foo () (princ-to-string (progv '(*s*) '(1) (catch 'ct *s*)))) FOO CL-USER(3): (compile 'foo) ; Caught ERROR: ; Stack inconsistency detected in <unknown> at index 44: found 3, expected 1. ; Compilation unit finished ; Caught 1 ERROR condition

1 0

Pluggable external UI for abcl-stepper
by Alejandro Zamora Fonseca 18 Nov '23

18 Nov '23

Hi ABCL-ers :) I just sent a PR https://github.com/armedbear/abcl/pull/635 that allows to optionally define different UIs for the visualize and control stepping process of abcl-stepper. I also made an initial implementation to be used as a guide for more UI if someone else is interested https://gitlab.com/cl-projects/abcl-visual-stepper. This version uses HTMX <http://htmx.org> and websockets. The UI is not quite beautiful and it is still a work in progress allowing syntax highlighting in the browser and other little niceties to the stepper user. Probably someone with more UI/UX experience can make a better UI and can do it by using the generic functions defined in the stepper code and defining his own protocol. I believe this idea could be also generalized for other components of the system (inspector, debugger, REPL, etc) Any feedback is appreciated, Thanks Alejandro

1 0

ABCL working with openjdk21
by Mark Evenson 19 Oct '23

19 Oct '23

Greetings, Bear fans. It seems that ABCL [works well with JDK21][1] without needing any changes. [1]: https://github.com/armedbear/abcl/actions/runs/6576709219/job/17866716581?p… -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

verifiyng the ABCL packages
by cage 21 Aug '23

21 Aug '23

Hi! Sorry if this question sounds trivial (likely it is) but how can I verify the packages downloaded on the ABCL website? I am able to download the signature file (*.asc) but I do not know how to find the public key to match the signature. ---------------- $ gpg --verify abcl-bin-1.9.2.tar.gz.asc gpg: assuming signed data in 'abcl-bin-1.9.2.tar.gz' gpg: Signature made Wed Jun 21 10:01:48 2023 CEST gpg: using DSA key 5491D207FF9ECDE0BEA277772A9641104DB1773D [...] gpg: Can't check signature: No public key ---------------- ^^^^^^^^^^^^^ Thanks in advance! C.

2 1

Question about wild-pathnames
by Robert Goldman 06 Jul '23

06 Jul '23

In SBCL and Allegro, it's possible for UIOP to create a pathname for a file whose name is "*" and then we can find a file with such a(n odd) pathname. On ABCL, though, this gives me an error: (truename (ensure-pathname "*")) ``` (truename (uiop:ensure-pathname "*")) #<THREAD "interpreter" native {21C91F12}>: Debugger invoked on condition of type FILE-ERROR Cannot find the TRUENAME for a wild pathname. ``` But actually, I don't think this *is* a wild pathname: ``` CL-USER(4): (describe (uiop:ensure-pathname "*")) #P"*" is an object of type PATHNAME: HOST NIL DEVICE NIL DIRECTORY NIL NAME "*" TYPE :UNSPECIFIC VERSION NIL ``` *this* is a wild pathname: ``` CL-USER(5): (describe (parse-namestring "*")) #P"*" is an object of type PATHNAME: HOST NIL DEVICE NIL DIRECTORY NIL NAME :WILD TYPE NIL VERSION NIL ``` Is this an ABCL bug, since it means ABCL cannot address a file whose name is "*"? The interested may refer to [this ASDF issue](https://gitlab.common-lisp.net/asdf/asdf/-/issues/140) and the corresponding merge request. Thanks!

3 2

ABCL 1.9.2
by Mark Evenson 21 Jun '23

21 Jun '23

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ ABCL 1.9.2 FOR MIDSUMMER'S EVE ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ On the threshold of the Northern Hemisphere's Midsummer's Eve, we unveil the second revision of the Tenth Edition of the Armed Bear Common Lisp implementation, viz. abcl-1.9.2. Most notably, we are pleased to present the fruits of Alejandro Zamora Fonseca's labors on an interpreted implementation of CL:STEP with the first release of the ABCL-STEPPER contrib. See <https://abcl.org/svn/tags/1.9.2/contrib/abcl-stepper/README.markdown> for more details. This implementation was the subject of his demonstration <https://zenodo.org/record/7815887> as this year's European Lisp Symposium. The POSIX-SYSCALLS contrib now provides the ability to set environment variables under UNIX systems <https://abcl.org/trac/changeset/15700>, as well as providing an example of how best to add abstract additional functionality to the core implementation. This release also features a substantially re-worked Gray Stream implementation which fixes enough our implementation to be a first class citizen of SLIME's usage. With the next release of SLIME, one will have to use abcl-1.9.2 in order to use the slime-repl. See <https://github.com/slime/slime/pull/765> for more details. The ASDF-JAR contrib has been restored to a usable functionality, which includes re-packaging of ASDF systems from within jar files as well as better abstraction for finding non-source artifacts. Please refer to <https://gitlab.common-lisp.net/abcl/abcl/-/blob/master/contrib/asdf-jar/REA…> for a refresher on what facilities ASDF-JAR provides for the aspiring ASDF packager. A complete list of changes may be viewed at <https://abcl.org/svn/tags/1.9.2/CHANGES>. The release itself is available at <https://abcl.org/releases/1.9.2/>. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

Setting environment variables
by Scott L. Burson 25 May '23

25 May '23

Hi, I've been away from ABCL for some time, so I ask your indulgence in case I'm revisiting a familiar issue. I tried (SETF (UIOP:GETENV "foo") "value") and got Not (currently) implemented on ABCL: (SETF UIOP/OS:GETENV) On investigation, I see that the JVM doesn't normally support setting environment variables, but there are known ways to jimmy it into doing so: https://stackoverflow.com/questions/318239/how-do-i-set-environment-variabl… Would a PR to add such a hack to ABCL be welcome, or should I just make it a local mod? Or is there another, recommended way of doing this? -- Scott

4 8

Final Call for Participation - ELS 2023, 16th European Lisp Symoisium
by Didier Verna 06 Apr '23

06 Apr '23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16th European Lisp Symposium In-Cooperation-With: ACM SIGLAN Call for Participation April 24-25, 2023 Startup Village, Amsterdam, Nederlands https://www.european-lisp-symposium.org/2023 Sponsored by EPITA, DIRO, MLPrograms, Franz Inc., and SISCOG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Recent News ~~~~~~~~~~~ Registrer now. Early bird discount closing soon! Keynote details now available. Important Dates ~~~~~~~~~~~~~~~ - Final papers due: April 9, 2023 - Early registration deadline: April 9, 2023 - Symposium: April 24-25, 2023 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation, and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 Keynotes ~~~~~~~~ ##### Artificial Intelligence: a Problem of Plumbing? -- Gerald J. Sussman, MIT CSAIL, USA We have made amazing progress in the construction and deployment of systems that do work originally thought to require human-like intelligence. On the symbolic side we have world-champion Chess-playing and Go-playing systems. We have deductive systems and algebraic manipulation systems that exceed the capabilities of human mathematicians. We are now observing the rise of connectionist mechanisms that appear to see and hear pretty well, and chatbots that appear to have some impressive linguistic ability. But there is a serious problem. The mechanisms that can distinguish pictures of cats from pictures of dogs have no idea what a cat or a dog is. The chatbots have no idea what they are talking about. The algebraic systems do not understand anything about the real physical world. And no deontic logic system has any idea about feelings and morality. So what is the problem? We generally do not know how to combine systems so that a system that knows how to solve problems of class A and another system that knows how to solve problems of class B can be combined to solve not just problems of class A or class B but can solve problems that require both skills that are needed for problems of class A and skills that are needed for problems of class B. Perhaps this is partly a problem of plumbing. We do not have linguistic structures that facilitate discovering and building combinations. This is a fundamental challenge for the programming-language community. We need appropriate ideas for abstract plumbing fittings that enable this kind of cooperation among disparate mechanisms. For example, why is the amazingly powerful tree exploration mechanism that is used for games not also available, in the same system, to a deductive engine that is being applied to a social interaction problem? I will attempt to elucidate this problem and perhaps point at avenues of attack that we may work on together. ##### Hedy: Gradual, Multi-Lingual, and Teacher-Centric Programming Education -- Felienne Hermans, Vrije Universiteit Amsterdam, Nederlands When kids learn to program they often use either a visual language like Scratch, or a textual language like Python. While visual languages are great for the first steps, children and educators often want to move on to textual languages. However, early on, a textual language and its error messages can be scary. Hedy aims to bridge this gap with a programming language that is gradual, using different language levels. In level 1, there is hardly any syntax at all; printing is done with: print hello! At every level, new syntax and concepts are added, so learners do not have to master everything at once. Hedy builds up to a subset of Python including conditions, loops, variables, and lists. To make learning as accessible as possible, Hedy also allows for the use of localized keywords, f.e in Spanish: imprimir Hello! Hedy (www.hedy.org) was launched in early 2020 and over 5 million Hedy progams have been created to date, and has been translated into 46 languages. ##### A Language-Based Approach to Programming with Serialized Data -- Michael Vollmer, School of Computing, University of Kent, UK It is common for software running today to use object representations fixed by the language runtime system; both the Java and Haskell runtimes dictate an object layout, and the compiler must stick to it for all programs. And yet when humans optimize a program, one of their primary levers on performance is changing data representation. For example, an HPC programmer knows how to pack a regular tree into a byte array for more efficient access. Unfortunately, this is error-prone, making it an undesirable way to achieve performance optimization at the expense of safety and readability. Furthermore, whenever a program receives data from the network or disk, rigid insistence on a particular heap layout causes an impedance mismatch we know as deserialization. Data represented in memory has pointers and arbitrary, sparse layout, while data on disk is packed contiguously, so data must be transformed from one form to another and back. Programming with serialized data is a technique for unifying the in-memory and on-disk representations of data, where the serialized form is used both on-disk and in-memory. This technique allows data processing programs to skip the deserialization/reserialization steps by operating directly on the data in its serialized form. It also represents a principled approach to optimizing programs by compacting data representations, which increases locality and minimizes indirection. In this talk, I will present a programming language, LoCal, for programming with serialized data. I will also describe Gibbon, an experimental compiler that automatically transforms functional programs to operate on serialized data. ##### Run-Time Verification of Communication Protocols in Clojure -- Sung-Shik Jongmans, Open Universiteit, Nederlands To simplify shared-memory concurrent programming, languages have started to offer core support for high-level communications primitives, in the form of message passing though channels, in addition to lower-level synchronization primitives. Yet, a growing body of evidence suggests that channel-based programming abstractions also have their issues. The Discourje project aims to help programmers cope with channels and concurrency bugs in Clojure programs, based on dynamic analysis. The idea is that programmers write not only implementations of communication protocols in their Clojure programs, but also specifications. Discourje then offers a run-time verification library to ensure that channel actions in implementations are safe relative to specifications. Programme Chair ~~~~~~~~~~~~~~~ Stefan Monnier, DIRO, Université de Montréal, Canada Programme Committee ~~~~~~~~~~~~~~~~~~~ Mark Evenson, not.org, Austria Marco Heisig, Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany Ioanna Dimitriou, Igalia S.L., Germany Robert Smith, HRL Laboratories Mattias Engdegård Marc Feeley, Université de Montréal, Canada Marc Battyani, FractalConcept Alan Ruttenberg, National Center for Ontological Research, USA Nick Levine, RavenPack, Spain Ludovic Courtès, Inria, France Matthew Flatt, University of Utah, USA Irène Durand, Université Bordeaux 1, France Jay McCarthy, Brigham Young University, USA Ambrose Bonnaire-Sergeant, Cisco Christopher League, Long Island University, NY, USA Pascal Costanza, Intel, Belgium Christian Queinnec Local Chair ~~~~~~~~~~~ Breanndán Ó Nualláin, Machine Learning Programs, Nederlands -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Test
by Marco Antoniotti 26 Mar '23

26 Mar '23

Just ignore... Sorry :) MA -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY CSCE 2023 - csce2023.lakecomoschool.org

1 0

Was ABCL 1.9.1's source tarball re-uploaded?
by Ruoyu Zhong 22 Mar '23

22 Mar '23

Dear ABCL maintainers, I am a maintainer for the Homebrew package manager. Recently we noticed that the checksum of ABCL 1.9.1’s source tarball, downloaded from https://abcl.org/releases/1.9.1/abcl-src-1.9.1.tar.gz, has changed from 9dc2fb0886e97be1906e6d0a96671ef9d0f52b9f91817e4c64741cd18bf8e0d1 (as of 2023-02-20 10:19 UTC) to a5bc677c9441f4a833c20a541bddd16fff9264846691de9a1daf6699f8ff11e2. May I confirm if the source tarball was updated? Thanks! Regards, Ruoyu

2 2

[CfPart] 16th European Lisp Symposium, April 24-25, Amsterdam
by Didier Verna 09 Mar '23

09 Mar '23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16th European Lisp Symposium In-Cooperation-With: ACM SIGLAN Call for Participation April 24-25, 2023 Startup Village, Amsterdam, Nederlands https://www.european-lisp-symposium.org/2023 Sponsored by EPITA, DIRO, MLPrograms, Franz Inc., and SISCOG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Recent News ~~~~~~~~~~~ Registrations are now open (early bird deadline: April 9) Keynote speakers announced (see below) Important Dates ~~~~~~~~~~~~~~~ - Author notification: March 26, 2023 - Final papers due: April 9, 2023 - Early registration deadline: April 9, 2023 - Symposium: April 24-25, 2023 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation, and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 Keynotes ~~~~~~~~ ##### Artificial Intelligence: a Problem of Plumbing? -- Gerald J. Sussman, MIT CSAIL, USA We have made amazing progress in the construction and deployment of systems that do work originally thought to require human-like intelligence. On the symbolic side we have world-champion Chess-playing and Go-playing systems. We have deductive systems and algebraic manipulation systems that exceed the capabilities of human mathematicians. We are now observing the rise of connectionist mechanisms that appear to see and hear pretty well, and chatbots that appear to have some impressive linguistic ability. But there is a serious problem. The mechanisms that can distinguish pictures of cats from pictures of dogs have no idea what a cat or a dog is. The chatbots have no idea what they are talking about. The algebraic systems do not understand anything about the real physical world. And no deontic logic system has any idea about feelings and morality. So what is the problem? We generally do not know how to combine systems so that a system that knows how to solve problems of class A and another system that knows how to solve problems of class B can be combined to solve not just problems of class A or class B but can solve problems that require both skills that are needed for problems of class A and skills that are needed for problems of class B. Perhaps this is partly a problem of plumbing. We do not have linguistic structures that facilitate discovering and building combinations. This is a fundamental challenge for the programming-language community. We need appropriate ideas for abstract plumbing fittings that enable this kind of cooperation among disparate mechanisms. For example, why is the amazingly powerful tree exploration mechanism that is used for games not also available, in the same system, to a deductive engine that is being applied to a social interaction problem? I will attempt to elucidate this problem and perhaps point at avenues of attack that we may work on together. ##### Gradual, Multi-Lingual, and Teacher-Centric Programming Education -- Felienne Hermans, Vrije Universiteit Amsterdam, Nederlands (tba) Programme Chair ~~~~~~~~~~~~~~~ Stefan Monnier, DIRO, Université de Montréal, Canada Programme Committee ~~~~~~~~~~~~~~~~~~~ Mark Evenson, not.org, Austria Marco Heisig, Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany Ioanna Dimitriou, Igalia S.L., Germany Robert Smith, HRL Laboratories Mattias Engdegård Marc Feeley, Université de Montréal, Canada Marc Battyani, FractalConcept Alan Ruttenberg, National Center for Ontological Research, USA Nick Levine, Ravenbrook Ltd, UK Ludovic Courtès, Inria, France Matthew Flatt, University of Utah, USA Irène Durand, Université Bordeaux 1, France Jay McCarthy, Brigham Young University, USA Ambrose Bonnaire-Sergeant, Cisco Christopher League, Long Island University, NY, USA Pascal Costanza, Intel, Belgium Christian Queinnec Local Chair ~~~~~~~~~~~ Breanndán Ó Nualláin, Machine Learning Programs, Nederlands -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

abcl-1.9.1 released
by Mark Evenson 03 Mar '23

03 Mar '23

━━━━━━━━━━━━━━━━━━━━━ ABCL 1.9.1 RELEASED Mark Evenson ━━━━━━━━━━━━━━━━━━━━━ Table of Contents ───────────────── 1. abcl-1.9.1 .. 1. News ..... 1. CFFI compatibility ..... 2. (Alan Ruttenberg) Ability to discriminate generic function execution on sub-types of MOP:SPECIALIZER ..... 3. Overhauled relationship to later openjdk threading models ..... 4. (Uthar) Implement array types for JAVA:JNEW-RUNTIME-CLASS ..... 5. (Alejandrozf) Compiler uses of signals to fallback to interpreted form ..... 6. (Alejandrozf) Further fixes to COMPILE-FILE-PATHNAME ..... 7. (Tarn W. Burton) Avoid NIL in simple LOOP from CL:FORMAT directives ..... 8. Broad testing and tweaks across Java Long Term Support (LTS) binaries 2. Fuller details 1 abcl-1.9.1 ════════════ If one has been hesitating about using the latest ABCL because one "never uses a dot oh release", we have now sloughed off abcl-1.9.1 for your appraisal from the depths of a Bear's long winter nap. Now one can use the somewhat less buggy version of the Tenth Edition of Armed Bear Common Lisp, available, as usual, at <https://abcl.org/releases/1.9.1/> or via Maven <https://search.maven.org/artifact/org.abcl/abcl/1.9.1/jar>. 1.1 News ──────── N.b. that when running on openjdk17 and later runtimes, there is quite a bit of necessary fiddling with command line arguments to "open" various modules to the Bear's introspective gaze. For example, see <https://abcl.org/svn/tags/1.9.1/ci/create-abcl-properties.bash> for the switches necessary to use CFFI to successfully run the CL+SSL test suite. As a reward for your patience, we mention the following notable improvements: 1.1.1 CFFI compatibility ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ We improved the compiler to use wide indices for stack frame locals for the ALOAD, ASTORE, ILOAD, ISTORE, LLOAD, and LSTORE opcodes, which among other goodness, allows CFFI-TESTS to compile again. In addition, we have updated the jar artifact used by CFFI to jna-5.12.1 which includes support for native linkage on the Apple Silicon and other exotic architectures. 1.1.2 (Alan Ruttenberg) Ability to discriminate generic function execution on sub-types of MOP:SPECIALIZER ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Following SBCL, CCL, and ECL, the Bear now accepts subtypes of MOP:SPECIALIZER as a generic function discriminator. 1.1.3 Overhauled relationship to later openjdk threading models ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Going back to the future of the original green thread models, recent openjdk releases have started offering lightweight threading implementations. For the Bear, the ability to spawn virtual threads is indicated by the presence of :VIRTUAL-THREADS in CL:*FEATURES*. Setting the special THREADS:*THREADING-MODEL* to :VIRTUAL results in THREADS:MAKE-THREADS spawning virtual threads. On some openjdks one may have to pass a command-line switch the JVM to enable virtual threading. 1.1.4 (Uthar) Implement array types for JAVA:JNEW-RUNTIME-CLASS ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Support for creating synthetic Java classes at runtime via JAVA:JNEW-RUNTIME-CLASS has been improved by introducing machinery for dealing with array types. 1.1.5 (Alejandrozf) Compiler uses of signals to fallback to interpreted form ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ We fall back to use an interpreted form for compilation results larger than 65535 bytes, which fixes the loading of the FirCAS computer algebra system. 1.1.6 (Alejandrozf) Further fixes to COMPILE-FILE-PATHNAME ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ We have restored the ability to compile Maxima by hopefully untangling the last kinks in the reworking of our COMPILE-FILE-PATHNAME logic. 1.1.7 (Tarn W. Burton) Avoid NIL in simple LOOP from CL:FORMAT directives ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Simplify simple CL:LOOP requires only compound forms, in the place where returning NIL is neither permitted nor desired. 1.1.8 Broad testing and tweaks across Java Long Term Support (LTS) binaries ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ We have extensively tested against recent openjdk8, openjdk11, openjdk17, and openjdk19 binaries. Unfortunately, for openjdk17+ runtimes one needs to pass additional runtime command line switches to the hosting JVM which "open" Java modules to reflective actions. 2 Fuller details ════════════════ More details can be found in <https://abcl.org/svn/tags/1.9.1/CHANGES>. Enjoy, and please CONS responsibly… -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 2

Setting different class loader
by Steven Nunez 06 Feb '23

06 Feb '23

Greetings all, I have what I think is a problem with the ABCL class loader. I am working with a 'big data' library, Spark, but run into an issue on line 2 of the programming guide example. I am able to load the JARs from Maven with the ASDF system definition: (asdf:defsystem #:spark :description "Wrapper for Spark 3.0" :serial t :defsystem-depends-on (abcl-asdf) :depends-on (#:jss #:javaparser) :components ((:mvn "org.apache.spark/spark-core_2.12" :version "3.0.0") (:file "package") (:file "spark"))) and can create a SparkConf object: (defvar *spark-conf* #1"new SparkConf() .setAppName("abcl-app") .setMaster("local")" ) But when I try to create a 'context' (defvar *sc* (new 'JavaSparkContext *spark-conf*)) I get an error in the initialisation: Java exception 'java.lang.NoClassDefFoundError: Could not initialize class org.apache.spark.package$'. There isn't much on this except from the Jenkins guys, who have attempted to put Spark and Spark applications into a CI system. They seem to think that it's related to a call to get a properties file in the package class and on a StackOverflow discussion suggested that "you should make sure that you set the classloader that Spark was loaded through using the Thread.currentThread().setContextClassLoader(myCustomLoader) call". I've verified with (java:dump-classpath) that the JAR is on the ABCL classpath, and the JAR file does contain the spark-version-info.properties file. I've also tried getting the file myself with: (defvar rs #1"Thread.currentThread() .getContextClassLoader() .getResourceAsStream("spark-version-info.properties")" ) which returns nil, so their theory may be correct. Messing around with class loaders is a bit beyond my 20 year old Java knowledge so I thought I'd ask here if anyone has any ideas on how I can load Spark in way to use the default Java class loader. Alternatively it occurs to me to ask why the ABCL class loader isn't able to find the properties file if the JAR is on the classpath and then to correct whatever that problem is. Cheers, Steve

3 6

[CfP] 16th European Lisp Symposium, April 24-25, Amsterdam
by Didier Verna 02 Feb '23

02 Feb '23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16th European Lisp Symposium Call for Papers April 24-25, 2023 Startup Village, Amsterdam, Nederlands https://www.european-lisp-symposium.org/2023 Sponsored by EPITA, DIRO, MLPrograms, Franz Inc., and SISCOG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Recent News ~~~~~~~~~~~ First keynote speaker announced: Gerald Jay Sussman, MIT, MA, USA Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: February 26, 2023 - Author notification: March 26, 2023 - Final papers due: April 9, 2023 - Symposium: April 24-25, 2023 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation, and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 Technical Program ~~~~~~~~~~~~~~~~~ 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. * Experience reports: papers of up to 6 pages describing a successful use of a Lisp dialect and/or analyzing obstacles that have kept it from working in practice. * Tutorials: abstracts of up to 4 pages for in-depth presentations about topics of special interest. * Demonstrations: abstracts of up to 4 pages for demonstrations of tools, libraries, and applications. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following link http://www.easychair.org/conferences/?conf=els2023. Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Stefan Monnier, DIRO, Université de Montréal, Canada Programme Committee ~~~~~~~~~~~~~~~~~~~ Stefan Monnier, Université de Montréal, Canada Mark Evenson, RavenPack Marco Heisig, Friedrich-Alexander-Universität Erlangen-Nürnberg, Germany Ioanna Dimitriou, Igalia S.L., Spain, Germany Robert Smith Mattias Engdegård Marc Feeley, Université de Montréal, Canada Marc Battyani, FractalConcept Alan Ruttenberg, National Center for Ontological Research, USA Nick Levine, Ravenbrook Ltd, UK Ludovic Courtès, Inria, France Matthew Flatt, University of Utah, USA Irène Durand, Université Bordeaux 1, France Jay McCarthy, Brigham Young University, USA Ambrose Bonnaire-Sergeant, Cisco Christopher League, Long Island University, NY, USA Local Chair ~~~~~~~~~~~ Breanndán Ó Nualláin, Machine Learning Programs, Nederlands -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

[CfP] ELS 2023, 16th European Lisp Symposium, April 24-25, Amsterdam
by Didier Verna 06 Dec '22

06 Dec '22

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 16th European Lisp Symposium Call for Papers April 24-25, 2023 Startup Village, Amsterdam, Nederlands https://www.european-lisp-symposium.org/2023 Sponsored by EPITA and DIRO ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: February 26, 2023 - Author notification: March 26, 2023 - Final papers due: April 9, 2023 - Symposium: April 24-25, 2023 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 Technical Program ~~~~~~~~~~~~~~~~~ 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 4 pages for demonstrations of tools, libraries, and applications. * Tutorials: abstracts of up to 4 pages for in-depth presentations about topics of special interest. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following link http://www.easychair.org/conferences/?conf=els2023. Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Stefan Monnier, DIRO, Université de Montréal Canada Programme Committee ~~~~~~~~~~~~~~~~~~~ TBA Local Chair ~~~~~~~~~~~ Breanndán Ó Nualláin, Machine Learning Programs, Nederlands -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Stack trace from condition
by Garrett Dangerfield 17 Nov '22

17 Nov '22

(handler-case (error "hi") (error (e) ;; print stack trace here )) How do I get the stack trace for the error? Thanks, Garrett Dangerfield.

2 1

File I/O Metrics
by Garrett Dangerfield 05 Nov '22

05 Nov '22

I don't want to cause a firestore here but I was doing some simple benchmarks on file i/o between Java, ABCL, and SBCL and I'm a bit shocked, honestly. Reading a 2.5M file in 16M chunks in (using iso-8859-1): - abcl takes a tad over 1 second - sbcl takes 0.04 seconds Reading a 5.8G file in 16M chunks in (using iso-8859-1 for Lisp, for Java it's just bytes): - abcl takes...too long, I gave up - sbcl takes between 20 and 21 seconds - Java takes 1.5 seconds These are all run on the same computer using the same files, etc. What's up with this? Thoughts? I'd heard that SBCL should be as fast as C under at least some circumstances. I'd wager that C is at least as fast as Java (probably faster). Thanks, Garrett Dangerfield. (he/him/his) P.S. Don't get me wrong, I *LOVE* Lisp, I'm trying to get away from Java as fast as I can (the syntax is killing me slowly). I've used ABCL in projects before (it was wonderful, Java doesn't handle XML well). Lisp code: (with-open-file (stream "/media/danger/OS/temp/jars.txt" :external-format :iso-8859-1) ; great_expectations.iso (let ((size (file-length stream)) (buffer-size (* 16 1024 1024)) ; 16M ) (time (loop with buffer = (make-array buffer-size :element-type 'character) for n-characters = (read-sequence buffer stream) while (< 0 n-characters))) ))) Java code: private static final int BUFFER_SIZE = 16 * 1024 * 1024; try (InputStream in = new FileInputStream("/media/danger/OS/temp/great_expectations.iso"); ) { byte[] buff = new byte[BUFFER_SIZE]; int chunkLen = -1; long start = System.currentTimeMillis(); while ((chunkLen = in.read(buff)) != -1) { System.out.println("chunkLen = " + chunkLen); } double duration = System.currentTimeMillis() - start; duration /= 1000; System.out.println(String.format("it took %,2f secs", duration)); } catch (Exception e) { e.printStackTrace(System.out); } finally { System.out.println("Done."); }

7 10

Constructing a java lambda expression?
by Alan Ruttenberg 25 Aug '22

25 Aug '22

There's a library I want to use that takes a lambda as an argument. Anyone know how to construct one in ABCL? Thanks, Alan

3 11

ASDF 3.3.6 is released
by Robert Goldman 07 Aug '22

07 Aug '22

Dear Lisp Implementation Developers and Maintainers, Today we release ASDF 3.3.6, the sixth bugfix release for the 3.3 release series, and -- it is devoutly to be hoped -- the final one. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 through 3.3.5 -- to upgrade to 3.3.6 at their earliest convenience. As maintainer, my primary role continues to be coordination and some limited quality control. The real work for this release has been done by many contributors and bug-reporters, to whom the Common Lisp community owes a tremendous vote of thanks. Their names are listed on the Changelog, appended below. An extra special thanks is due to my co-maintainer, Eric Timmons, who has provided many fixes and also has overhauled and much improved our regression testing. We *hope* that the next release will be 3.4, introducing new functionality but which, as the numbering suggests, will be backward compatible. Best, Robert * Fix bug loading ASDF system definitions from jar files on ABCL. See !190 * Fix bug with version numbering after reload. See !194 and #94. Thanks to Eric Timmons. * Fix bug in return value of UPGRADE-ASDF. See !195. Again, thanks to Eric Timmons. * Multiple improvements to documentation and tests. Thanks to Nathan Ringo and Phoebe Goldman. * Add clasp support for uiop/launch program. Thanks to Christian Schafmeister. * Miscellaneous minor bug fixes and tweaks. * Don't let *package* binding leak into ASDF compile operations. Thanks to Phoebe Goldman.

1 0

Unbound slot location bug
by Pascal Costanza 20 Jul '22

20 Jul '22

Hi, I’m running the Closer to MOP tests, and see at least one bug. (With the limited time I have available, I can only do one bug at a time, step by step, so there might be more.) Armed Bear Common Lisp 1.9.0 Java 17.0.3 Azul Systems, Inc. OpenJDK 64-Bit Server VM Low-level initialization completed in 0.095 seconds. Startup completed in 0.469 seconds. Loading /Users/costanza/.abclrc completed in 3.554 seconds. Type ":help" for a list of available commands. CL-USER(1): (use-package :mop) (defclass my-effective-slot-definition (standard-effective-slot-definition) ()) (defclass my-class (standard-class) ()) (defmethod validate-superclass ((class my-class) (superclass standard-class)) t) (defmethod effective-slot-definition-class ((class my-class) &rest initargs) (declare (ignore initargs)) (find-class 'my-effective-slot-definition)) (defclass my-object () ((my-slot :allocation :class)) (:metaclass my-class)) T CL-USER(2): CL-USER(2): #<STANDARD-CLASS MY-EFFECTIVE-SLOT-DEFINITION {731A05FD}> CL-USER(3): CL-USER(3): #<STANDARD-CLASS MY-CLASS {42C6245B}> CL-USER(4): CL-USER(4): #<STANDARD-METHOD VALIDATE-SUPERCLASS (MY-CLASS STANDARD-CLASS) {4959790F}> CL-USER(5): CL-USER(5): #<STANDARD-METHOD EFFECTIVE-SLOT-DEFINITION-CLASS (MY-CLASS) {2AAA2CBF}> CL-USER(6): CL-USER(6): #<THREAD "interpreter" {25793D3C}>: Debugger invoked on condition of type UNBOUND-SLOT The slot LOCATION is unbound in the object #<MY-EFFECTIVE-SLOT-DEFINITION {32EB5C37}>. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(7): Best, Pascal

2 1

Why can't defstructs be redefined?
by Alan Ruttenberg 14 Jul '22

14 Jul '22

Anyone know this area of the compiler? It's very frustrating during development. Seems we ought to, at least, be able to blow away all traces of the defstruct, ignoring existing structures and redefine it. My attempt to do that the obvious way - removing the system::structure-definition property from the symbol plist of the struct name - allows the redefinition but sometimes errors out when I use the new structure. Anyways, I'd like to fix this, and any info would give me a head start. Thanks, Alan

6 11

abcl-1.9.0 plans
by Mark Evenson 15 May '22

15 May '22

Greetings Bear fans, On the road in Amsterdam, I judge it time to stabilize the implementation for openjdk{8,11,17}. I don’t think we can do terrabyte heaps with openjdk8, so might as well skip openjdk11 to go for openjdk17 as abcl-2.0.0. Thanks to all who have provided material and spiritual support for the Armed Bear Common Lisp release engineering. Have a nice Northern Hemisphere Spring! One week call for patches for abcl-1.9.0 please. yours in the CONS, Mark -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

3 8

error loading stmx with abcl 1.9.0
by Massimiliano Ghilardi 09 May '22

09 May '22

Hi everybody, I just tried loading my library "stmx" with abcl-1.9.0, and it produces the following error: $ abcl Armed Bear Common Lisp 1.9.0 Java 18.0.1-ea Debian OpenJDK 64-Bit Server VM Low-level initialization completed in 0.122 seconds. Startup completed in 0.536 seconds. Loading /home/max/.abclrc completed in 7.901 seconds. Type ":help" for a list of available commands. CL-USER(1): (ql:quickload "stmx") To load "stmx": Load 1 ASDF system: stmx; Loading "stmx" [package alexandria].............................. ;; more lines omitted... [package stmx.lang]............................... [package stmx].................................... [package stmx.util]........................ Error loading /home/max/.cache/common-lisp/abcl-1.9.0-fasl43-linux-x64/home/max/my/common-lisp/stmx/util/tcell.abcl at line 14 (offset 935) The slot TRANSACTIONAL is unbound in the object #<TRANSACTIONAL-DIRECT-SLOT {2D9B58FE}>. [Condition of type UNBOUND-SLOT] Restarts: 0: [TRY-RECOMPILING] Recompile tcell and try loading it again 1: [RETRY] Retry loading FASL for #<ASDF/LISP-ACTION:CL-SOURCE-FILE "stmx" "util" "tcell">. 2: [ACCEPT] Continue, treating loading FASL for #<ASDF/LISP-ACTION:CL-SOURCE-FILE "stmx" "util" "tcell"> as having been successful. 3: [RETRY] Retry ASDF operation. 4: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration. 5: [ABORT] Give up on "stmx" 6: [RETRY] Retry SLIME REPL evaluation request. 7: [*ABORT] Return to SLIME's top level. 8: [ABORT] Abort thread. Backtrace: 0: (SYSTEM:BACKTRACE) 1: (#<FUNCTION #<FUNCTION {25F0C5DA}> {25F0C5DA}> #<UNBOUND-SLOT {50DED6EF}> #<FUNCTION #<FUNCTION {25F0C5DA}> {25F0C5DA}>) 2: (APPLY #<FUNCTION #<FUNCTION {25F0C5DA}> {25F0C5DA}> (#<UNBOUND-SLOT {50DED6EF}> #<FUNCTION #<FUNCTION {25F0C5DA}> {25F0C5DA}>)) 3: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<UNBOUND-SLOT {50DED6EF}> #<FUNCTION #<FUNCTION {25F0C5DA}> {25F0C5DA}>) 4: (INVOKE-DEBUGGER #<UNBOUND-SLOT {50DED6EF}>) 5: (ERROR UNBOUND-SLOT :INSTANCE #<STMX::TRANSACTIONAL-DIRECT-SLOT {2D9B58FE}> :NAME STMX:TRANSACTIONAL) 6: (#<FUNCTION #<FUNCTION {2BE435C1}> {2BE435C1}> (#<STANDARD-CLASS STMX::TRANSACTIONAL-DIRECT-SLOT {3ECE7861}> #<STMX::TRANSACTIONAL-DIRECT-SLOT {2D9B58FE}> STMX:TRANSACTIONAL)) 7: (#<FUNCTION #<FUNCTION {D2BE7FC}> {D2BE7FC}> (#<STMX::TRANSACTIONAL-DIRECT-SLOT {2D9B58FE}>)) 8: (#<FUNCTION #<FUNCTION {7A80120F}> {7A80120F}> (#<STMX:TRANSACTIONAL-CLASS STMX.UTIL:TCELL {597DC690}> STMX.UTIL::VALUE (#<STMX::TRANSACTIONAL-DIRECT-SLOT {2D9B58FE}>))) 9: (#<STANDARD-GENERIC-FUNCTION MOP:COMPUTE-EFFECTIVE-SLOT-DEFINITION {6F61B180}> #<STMX:TRANSACTIONAL-CLASS STMX.UTIL:TCELL {597DC690}> STMX.UTIL::VALUE (#<STMX::TRANSACTIONAL-DIRECT-SLOT {2D9B58FE}>)) 10: (#<FUNCTION #<FUNCTION {53BDAA43}> {53BDAA43}> STMX.UTIL::VALUE) 11: (MOP::STD-COMPUTE-SLOTS #<STMX:TRANSACTIONAL-CLASS STMX.UTIL:TCELL {597DC690}>) 12: (#<STANDARD-GENERIC-FUNCTION MOP:COMPUTE-SLOTS {1125EE25}> #<STMX:TRANSACTIONAL-CLASS STMX.UTIL:TCELL {597DC690}>) 13: (MOP::STD-FINALIZE-INHERITANCE #<STMX:TRANSACTIONAL-CLASS STMX.UTIL:TCELL {597DC690}>) 14: (MOP:FINALIZE-INHERITANCE #<STMX:TRANSACTIONAL-CLASS STMX.UTIL:TCELL {597DC690}>) 15: (MOP::MAYBE-FINALIZE-CLASS-SUBTREE #<STMX:TRANSACTIONAL-CLASS STMX.UTIL:TCELL {597DC690}>) 16: (MOP::STD-AFTER-INITIALIZATION-FOR-CLASSES #<STMX:TRANSACTIONAL-CLASS STMX.UTIL:TCELL {597DC690}> :NAME STMX.UTIL:TCELL :DIRECT-SUPERCLASSES (#<STMX:TRANSACTIONAL-CLASS STMX:TRANSACTIONAL-OBJECT {1FBB.. 17: (APPLY #<FUNCTION #<STD-AFTER-INITIALIZATION-FOR-CLASSES {733841D0}> {733841D0}> #<STMX:TRANSACTIONAL-CLASS STMX.UTIL:TCELL {597DC690}> (:NAME STMX.UTIL:TCELL :DIRECT-SUPERCLASSES ..)) 18: (#<FUNCTION #<FUNCTION {4C6FD921}> {4C6FD921}> #<STMX:TRANSACTIONAL-CLASS STMX.UTIL:TCELL {597DC690}> :NAME STMX.UTIL:TCELL :DIRECT-SUPERCLASSES (#<STMX:TRANSACTIONAL-CLASS STMX:TRANSACTIONAL-OBJECT {.. 19: (APPLY #<FUNCTION #<FUNCTION {4C6FD921}> {4C6FD921}> (#<STMX:TRANSACTIONAL-CLASS STMX.UTIL:TCELL {597DC690}> :NAME STMX.UTIL:TCELL :DIRECT-SUPERCLASSES ..)) 20: (#<STANDARD-GENERIC-FUNCTION INITIALIZE-INSTANCE {5F0C5228}> #<STMX:TRANSACTIONAL-CLASS STMX.UTIL:TCELL {597DC690}> :NAME STMX.UTIL:TCELL :DIRECT-SUPERCLASSES (#<STMX:TRANSACTIONAL-CLASS STMX:TRANSACT.. 21: (APPLY #<STANDARD-GENERIC-FUNCTION INITIALIZE-INSTANCE {5F0C5228}> #<STMX:TRANSACTIONAL-CLASS STMX.UTIL:TCELL {597DC690}> (:NAME STMX.UTIL:TCELL :DIRECT-SUPERCLASSES ..)) 22: (#<FUNCTION #<FUNCTION {723E9D5D}> {723E9D5D}> #<STANDARD-CLASS STMX:TRANSACTIONAL-CLASS {40AB239E}> :NAME STMX.UTIL:TCELL :DIRECT-SUPERCLASSES (#<STMX:TRANSACTIONAL-CLASS STMX:TRANSACTIONAL-OBJECT {1.. 23: (APPLY #<FUNCTION #<FUNCTION {723E9D5D}> {723E9D5D}> (#<STANDARD-CLASS STMX:TRANSACTIONAL-CLASS {40AB239E}> :NAME STMX.UTIL:TCELL :DIRECT-SUPERCLASSES ..)) 24: (#<STANDARD-GENERIC-FUNCTION MAKE-INSTANCE {2577139A}> #<STANDARD-CLASS STMX:TRANSACTIONAL-CLASS {40AB239E}> :NAME STMX.UTIL:TCELL :DIRECT-SUPERCLASSES (#<STMX:TRANSACTIONAL-CLASS STMX:TRANSACTIONAL-O.. 25: (APPLY #<STANDARD-GENERIC-FUNCTION MAKE-INSTANCE {2577139A}> #<STANDARD-CLASS STMX:TRANSACTIONAL-CLASS {40AB239E}> :NAME STMX.UTIL:TCELL :DIRECT-SUPERCLASSES (#<STMX:TRANSACTIONAL-CLASS STMX:TRANSACTI.. 26: (#<FUNCTION #<FUNCTION {2E873D1E}> {2E873D1E}> NIL STMX.UTIL:TCELL :DIRECT-SUPERCLASSES (#<STMX:TRANSACTIONAL-CLASS STMX:TRANSACTIONAL-OBJECT {1FBB3CF}>) :DIRECT-SLOTS ((:NAME STMX.UTIL::VALUE ..)) :M.. 27: (APPLY #<FUNCTION #<FUNCTION {2E873D1E}> {2E873D1E}> (NIL STMX.UTIL:TCELL :DIRECT-SUPERCLASSES (#<STMX:TRANSACTIONAL-CLASS STMX:TRANSACTIONAL-OBJECT {1FBB3CF}>) :DIRECT-SLOTS ..)) 28: (#<STANDARD-GENERIC-FUNCTION MOP:ENSURE-CLASS-USING-CLASS {145D6FB6}> NIL STMX.UTIL:TCELL :DIRECT-SUPERCLASSES (#<STMX:TRANSACTIONAL-CLASS STMX:TRANSACTIONAL-OBJECT {1FBB3CF}>) :DIRECT-SLOTS ((:NAME ... 29: (APPLY #<STANDARD-GENERIC-FUNCTION MOP:ENSURE-CLASS-USING-CLASS {145D6FB6}> NIL STMX.UTIL:TCELL (:DIRECT-SUPERCLASSES (#<STMX:TRANSACTIONAL-CLASS STMX:TRANSACTIONAL-OBJECT {1FBB3CF}>) ..)) 30: (MOP:ENSURE-CLASS STMX.UTIL:TCELL :DIRECT-SUPERCLASSES (#<STMX:TRANSACTIONAL-CLASS STMX:TRANSACTIONAL-OBJECT {1FBB3CF}>) :DIRECT-SLOTS ((:NAME STMX.UTIL::VALUE :INITFORM STMX.UTIL::+EMPTY-TCELL+ ..)) .. 31: (#<COMPILED-FUNCTION #<FUNCTION (LAMBDA ()) {5BAF143A}> {5BAF143A}>) 32: (FUNCALL #<COMPILED-FUNCTION #<FUNCTION (LAMBDA ()) {5BAF143A}> {5BAF143A}>) 33: (SYSTEM:INIT-FASL :VERSION 43) 34: (SYSTEM::%LOAD #P"/home/max/.cache/common-lisp/abcl-1.9.0-fasl43-linux-x64/home/max/my/common-lisp/stmx/util/tcell.abcl" NIL NIL T :DEFAULT) 35: (LOAD #P"/home/max/.cache/common-lisp/abcl-1.9.0-fasl43-linux-x64/home/max/my/common-lisp/stmx/util/tcell.abcl") 36: (APPLY LOAD #P"/home/max/.cache/common-lisp/abcl-1.9.0-fasl43-linux-x64/home/max/my/common-lisp/stmx/util/tcell.abcl" NIL) 37: (#<FUNCTION #<FUNCTION {69BB78BF}> {69BB78BF}>) 38: (UIOP/UTILITY:CALL-WITH-MUFFLED-CONDITIONS #<FUNCTION #<FUNCTION {69BB78BF}> {69BB78BF}> ("Overwriting already existing readtable ~S." #(#:FINALIZERS-OFF-WARNING :ASDF-FINALIZERS))) 39: (UIOP/LISP-BUILD:CALL-WITH-MUFFLED-LOADER-CONDITIONS #<FUNCTION #<FUNCTION {69BB78BF}> {69BB78BF}>) 40: (UIOP/LISP-BUILD:LOAD* #P"/home/max/.cache/common-lisp/abcl-1.9.0-fasl43-linux-x64/home/max/my/common-lisp/stmx/util/tcell.abcl") ; ... Any idea what could be the reason? The same code works with sbcl, and used to work also with abcl <= 1.7.1. Also, it's not clear to me how the TRANSACTIONAL slot in question can be unbound, as it has an initform: (defclass transactional-direct-slot (standard-direct-slot-definition) ((transactional :type boolean :initform t :initarg :transactional :accessor transactional-slot?)) (:documentation "The class for direct slots of transactional classes. [...])) Thanks in advance for any advice/suggestion. Massimiliano Ghilardi

2 2

Which repo SVN or GIT?
by Blake McBride 30 Apr '22

30 Apr '22

Greetings, I am pretty sure we are keeping two parallel repos for ABCL, one in subversion and the other in GIT. I thought two things: 1. They were kept in sync 2. The subversion repo was preferred I recently compared the two repos and discovered that: 1. They are not in sync 2. The GIT repo has the latest changes Personally, I prefer subversion. However, I feel strongly that we should drop one of the repos so that this out-of-sync situation no longer arises. Thanks! Blake McBride

2 4

Why is build using Java 11?
by Blake McBride 13 Apr '22

13 Apr '22

Greetings, I am building the latest SVN version of ABCL on a Linux box. Here is what I am seeing: $ java -version openjdk version "1.8.0_322" OpenJDK Runtime Environment (build 1.8.0_322-b06) OpenJDK 64-Bit Server VM (build 25.322-b06, mixed mode) $ javac -version javac 1.8.0_322 $ env |grep JAVA $ ant [...] abcl.init: [echo] java.version: 11.0.14.1 [...] $ Why is the build using Java 11? Thanks! Blake McBride

2 3

Interrupting repl in Slime
by Alan Ruttenberg 12 Apr '22

12 Apr '22

Hi folks, Maybe someone has a feel for how interrupts work in ABCL? Doing an interrupt in ABCL from Slime doesn't interrupt until the end of a function or sleep or wait is called. This means whenever I accidentally have a too long or infinite loop by mistake the only thing I can do is quit lisp and start over. This is probably THE most irritating problem I have with ABCL. It doesn't happen often but when it does it completely disrupts work. Slime handles an interrupt by calling interrupt-thread. Interrupt-thread saves the function and sets a flag. When the interrupted process next checks the flag it will call the interrupt function. At first I thought lisp wasn't checking for an interrupt often enough, but that's not the problem. If I compile (loop for i = 1) I get public final LispObject execute() { ; do { ; if (!Lisp.interrupted) { ; continue; ; } ; Lisp.handleInterrupt(); ; } while (true); ; } So why doesn't the interrupt work? Well it seems there are two paths to interrupt. One is via interrupt-thread. Here is the code that sets the flag. final synchronized void interrupt(LispObject function, LispObject args) { pending = new Cons(args, pending); pending = new Cons(function, pending); threadInterrupted = true; javaThread.interrupt(); } Note that it is setting thread.threadInterrupted rather than Lisp.interrupted. In fact, the only way to set Lisp.interrupted is via Lisp.setInterrupted() and the only function that calls that is ext:interrupt-lisp. Nothing calls ext:interrupt-lisp. So that nice check within the loop is checking for a signal that currently never arrives. The javathread.interrupt is only periodically detected by an explicit call or via an InterruptedException that Java will throw when the thread yields or via a check of thread.isInterrupted. The latter is checked in one place, inside a catch, which afaik isn't executed unless there's an error in the thread - it's the "Ignoring uncaught exception" path. Now, if I call ext:interrupt-lisp from the *inferior-lisp* a break comes up during the infinite loop and I can kill it! This is the desired behavior. The problem is, I can't figure out where to call (ext:interrupt-lisp) within slime. I tried to put it right after interrupt-thread when that is called in swank::queue-thread-interrupt, which is what is eventually called when you hit C-c in the repl. But that causes an error and kills the slime session. And emacs, for that matter, which needs to be force quit. I'm thinking that in the case of a control-c we should not use thread-interrupt but rather lisp interrupted. threadInterrupted is thread local and Lisp.interrupted is a global. So technically the control c might not go to the right thread, since all threads are checking the global. But in the situation where it's locked in an infinite loop, there's no other thread doing anything, so the right thing happens. In any case I think that's probably easy to fix by setting another volatile to the thread to be interrupted. In general one would have to worry about a race condition if there were several places that might call interrupt-lisp, but in this case it would only be called with an explicit Control-c and perhaps on a request to kill a thread from the slime threads buffer. It's an open question as to whether interrupt-thread should take advantage of this as well, but that would require more care to avoid a race condition. Any help on sorting this would be much appreciated. Thanks, Alan

3 13

ABCL manual
by Jonathan L Cunningham 07 Apr '22

07 Apr '22

Hi, The link in the Bibliography [Rho09] appears to have moved, and gives a 403 error. This, similar but different, link appears to be correct: https://research.gold.ac.uk/id/eprint/2344/1/sequences-20070301.pdf Regards, Jonathan

2 1

ABCL v1.8.0 | Hash table size is set to 11 despite :size being set to lower number
by Johnny Ruiz 30 Mar '22

30 Mar '22

2 2

[CfPart] ELS 2022, 15th European Lisp Symposium, March 21-22, Porto.
by Didier Verna 10 Mar '22

10 Mar '22

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 15th European Lisp Symposium Call for Participation March 21-22, 2022 FEUP, Porto, Portugal & Online In cooperation with ACM SIGPLAN https://www.european-lisp-symposium.org/2022 Sponsored by EPITA, Franz Inc., and SISCOG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important News ~~~~~~~~~~~~~~~ - Full programme now online - Invited speakers below - Registrations are open Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 Invited talks ~~~~~~~~~~~~~ Building SICMUtils, the Atelier of Abstractions -- Sam Ritchie SICMUtils is a Clojure library designed for interactive exploration of mathematical physics. It is simultaneously a work of persuasive writing, a collection of essays on functional pearls and computational ideas, a stable of workhorse functional abstractions, and a practical place to work and visualize algorithms and physical systems, on a server or in the browser. How do you build a library like this? This talk will go through the architecture of SICMUtils, based on many of the ideas of "additive programming" from Gerald Sussman and Chris Hanson's latest book, Software Design for Flexibility. We'll look at surprising examples of the system becoming easier to extend over time. Clojure's embrace of its host platform lets us use the best modern work in Javascript for visualization, while keeping the horsepower of our servers for real work. Lisp's particular elegance will shine throughout. Creating a Common Lisp Implementation -- Robert Strandh Being dissatisfied with the way current Common Lisp implementations are written, and with the duplication of system code between different implementations, we started the SICL project in 2008. The initial idea was to create modules that the creators of Common Lisp implementations could use to create a complete system from an initial minimal core. But this idea was unsatisfactory because it required each module to be written in a subset of Common Lisp. So instead, we decided to use the full language to implement these modules, effectively making them useless to an implementation using traditional bootstrapping techniques. We therefore decided to also create a new Common Lisp implementation (also named SICL), that could use those modules. A crucial element is a bootstrapping technique that can handle these modules. In this spirit, we have developed several modules, including an implementation of CLOS which is also an important element of bootstrapping. Lately, we have increased our level of ambition in that we want to extract those modules as separate (and separately maintained) repositories, which requires us to deal with code during bootstrapping that was not specifically written for SICL. In our talk, we describe this evolution of ambition, and its consequences to bootstrapping, in more detail. We also give an overview of several new techniques we created, some of which have been published (at ICL and ELS) and some of which have not. Finally, we discuss the future of the project, and other projects for which we imagine SICL to be a base. Lisp as Renaissance Workshop: A Lispy Tour through Mathematical Physics -- Sam Ritchie Lisp is an exquisite medium for the communication of computational ideas. From our most accurate observations of physical reality up through chemistry, biology, and cognition, the universe seems to be computing itself; modeling and simulating these systems in machines has led to incredible technological wealth. Deep principles and beautiful abstractions seem to drive these systems, but they have always been hard to discover; and we are floundering at the computational frontiers of intelligence, synthetic biology and control systems for our climate. The only way to push forward is to build powerful tools that can communicate and teach. This talk will take a tour through SICMUtils, a Lisp system designed as a workshop for conducting serious work in mathematical physics and sharing those explorations in a deeply interactive, multiplayer way. The library’s growth parallels our human scientific history; hopefully tools like this will help us write the next chapter. Programme Chair ~~~~~~~~~~~~~~~ Jim Newton - EPITA Research Lab (LRDE), France Programme Committee ~~~~~~~~~~~~~~~~~~~ Philipp Meier, Nubank Ioanna M. Dimitriou H., Igalia Mikhail Raskin, Technical University of Munich Nick Levine, RavenPack Adrien Pommellet, LRDE, EPITA Marco Heisig, Friedrich-Alexander-Universität Erlangen Alberto Riva, Bioinformatics Core, ICBR, University of Florida Marco Antoniotti, DISCo, Università degli Studi di Milano-Bicocca Nicolas Neuss, Friedrich-Alexander-Universität Erlangen Christophe Rhodes, Google UK Irène Anne Durand, LaBRI, University of Bordeaux Ralf Moeller Breanndán Ó Nualláino, University of Amsterdam Marc Battyani, Fractal Concept Pascal Costanza, Intel Sky Hester, Private Consultant -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

[Extended Deadline] 15th European Lisp Symposium
by Didier Verna 24 Jan '22

24 Jan '22

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 15th European Lisp Symposium Call for Papers March 21-22, 2022 FEUP, Porto, Portugal & Online In co-location with <Programming> https://www.european-lisp-symposium.org/2022 Sponsored by EPITA and Franz Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~ - Submission deadline ***EXTENDED***: January 30, 2022 - Author notification: February 21, 2022 - Final papers due: March 7, 2022 - Symposium: March 21-22, 2022 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 Technical Program ~~~~~~~~~~~~~~~~~ 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 4 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. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following link http://www.easychair.org/conferences/?conf=els2022. Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Jim Newton - EPITA Research Lab (LRDE), France Programme Committee ~~~~~~~~~~~~~~~~~~~ Philipp Meier, Nubank Ioanna M. Dimitriou H., Igalia Mikhail Raskin, Technical University of Munich Nick Levine, RavenPack Adrien Pommellet, LRDE, EPITA Marco Heisig, FAU Erlangen-Nürnberg Alberto Riva, Bioinformatics Core, ICBR, University of Florida Marco Antoniotti, DISCo, Università degli Studi di Milano-Bicocca Nicolas Neuss, Friedrich-Alexander-Universität Erlangen Christophe Rhodes, Google Irène Anne Durand, LaBRI, University of Bordeaux Ralf Moeller Breanndán Ó Nualláino, University of Amsterdam Marc Battyani, Fractal Concept Pascal Costanza, Intel -- Didier Verna <didier(a)elsaa.org> ELS Steering Committee

1 0

[Last CfP] 15th European Lisp Symposium, March 21-22 2022, Porto
by Didier Verna 11 Jan '22

11 Jan '22

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 15th European Lisp Symposium Call for Papers March 21-22, 2022 FEUP, Porto, Portugal & Online In co-location with <Programming> https://www.european-lisp-symposium.org/2022 Sponsored by EPITA and Franz Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: January 23, 2022 - Author notification: February 21, 2022 - Final papers due: March 7, 2022 - Symposium: March 21-22, 2022 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 Technical Program ~~~~~~~~~~~~~~~~~ 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 4 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. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following link http://www.easychair.org/conferences/?conf=els2021. Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Jim Newton - EPITA Research Lab, France Programme Committee ~~~~~~~~~~~~~~~~~~~ Philipp Meier, Nubank Ioanna M. Dimitriou H., Igalia Mikhail Raskin, Technical University of Munich Nick Levine, RavenPack Adrien Pommellet, EPITA Research Lab Marco Heisig, FAU Erlangen-Nürnberg Alberto Riva, Bioinformatics Core, ICBR, University of Florida Marco Antoniotti, DISCo, Università degli Studi di Milano-Bicocca Nicolas Neuss, Friedrich-Alexander-Universität Erlangen Christophe Rhodes, Google Irène Anne Durand, LaBRI University of Bordeaux Ralf Moeller Breanndán Ó Nualláin Marc Battyani, Fractal Concept Pascal Costanza, Intel, Belgium -- Didier Verna

1 0

Considering resignation as maintainer
by Robert Goldman 10 Jan '22

10 Jan '22

I have discovered that Stas Bokuraev is continuing to refuse to update Edi packages to modern ASDF system-naming. This would not be bad in and of itself, because these are open source systems, and they can be forked. What *is* bad is that he has publicly stated that he is doing this hoping that the resulting warnings will break people's systems and thus cause them to get angry and complain to me about ASDF checking system names. What is even worse is that the CL community tacitly accepts this as normal behavior. I would like to see the CL open source community pause and consider what constitutes a healthy community. I don't believe that someone trying to break things in order to pressure a volunteer maintainer of infrastructure is something that a healthy community should accept. If the community prefers a more rough-and-tumble approach, I can accept that, but if so it's time for the community to find an ASDF maintainer who is more in harmony with the values it (at least implicitly) espouses.

2 1

(rationalize) works differently in ABCL
by Andrew Sengul 27 Nov '21

27 Nov '21

I've been doing operations that require me to rationalize floats, and I've found that (rationalize 2.3d0)gives very different output in ABCL compared SBCL and CCL. Floats can have any number of valid rational conversions but I'd expect a good algorithm for this conversion to find 23/10 rather than the huge numerators and denominators that get produced. It appears that the (rationalize) in ABCL is using the same algorithm as (rational) does in other CLs. Does (rationalize) just pass through to (rational) in ABCL? Would it make sense for ABCL to adopt the implementation of this function used by other CLs? Thanks. Andrew

1 0

One more question - compiling large code
by Andrew Sengul 23 Nov '21

23 Nov '21

I was just trying to compile a system containing macros that generate a large amount of code. I got this error: Compiled function can't be loaded: org.armedbear.lisp.demo_tmpHVF0FTR3_246 from org.armedbear.lisp.Pathname@2a31c2ec Does anyone know the likely reason for this? The code I'm compiling works with all other CL implementations I've tried. Is it just a matter of the code size? Thanks, Andrew

3 3

Problem - can't set environment variables when starting ABCL via Slime
by Andrew Sengul 21 Nov '21

21 Nov '21

Hello, I'm using ABCL through Emacs with Slime and I'm having trouble setting bash environment variables needed for Maven to work. Here's what I have in my ~/.emacs file: (setq slime-lisp-implementations '((abcl ("/usr/bin/java" "-jar" "/path/to/abcl-bin-1.8.0/abcl.jar" "/path/to/abcl-bin-1.8.0/abcl-contrib.jar" "-Xmx6g") :coding-system utf-8-unix :env ("JAVA_HOME=/path/to/jdk-12/" "PATH=/opt/apache-maven-3.8.3/bin:$PATH")))) Problem is, the $JAVA_HOME and $PATH variables are not set for the ABCL process despite putting them here. The environment variables do work with other CL implementations. When I set them in SBCL, for example, I can run (uiop:run-program "echo $PATH" ...) and see the extension added to the path. This doesn't work in ABCL, and I need those extra environment variables set in order for Maven to work. Does anyone know a way to fix this? It works for other CLs, so I'm guessing something particular about ABCL is preventing the variables from being set. Thanks, Andrew

1 0

[CfP] 15th European Lisp Symposium, March 21-22 2022, Porto, Portugal
by Didier Verna 20 Oct '21

20 Oct '21

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 15th European Lisp Symposium Call for Papers March 21-22, 2022 FEUP, Porto, Portugal & Online In co-location with <Programming> http://www.european-lisp-symposium.org/2022 Sponsored by EPITA ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: January 23, 2022 - Author notification: February 21, 2022 - Final papers due: March 7, 2022 - Symposium: March 21-22, 2022 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The 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 Technical Program ~~~~~~~~~~~~~~~~~ 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 4 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. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following http://www.easychair.org/conferences/?conf=els2021 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Jim Newton - EPITA Research Lab (LRDE), France Programme Committee ~~~~~~~~~~~~~~~~~~~ tba -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Error building 'babel' on ABCL 1.8.0 on Windows 10
by mortemeur 16 Sep '21

16 Sep '21

First of all, I assume this is my fault, but I do not know what I screwed up. I am sure I am accidentally leaving out important information, but if you ask me for it I would be happy to include it in a reply. I am trying to learn about Common Lisp and decided to use ABCL on Windows 10, I ran into this error while going through Xach's tutorial ( https://xach.livejournal.com/278047.html). Specifically, I ran: (quickproject:make-project "~/src/lisp/swatchblade/" :depends-on '(vecto hunchentoot)) The error I received is: Error while trying to load definition for system jna from pathname jar:file:///C:/abcl/abcl-contrib.jar!/mvn/jna.asd: Java exception 'java.lang.reflect.InaccessibleObjectException: Unable to make public java.lang.String java.util.jar.JarFile$JarFileEntry.getName() accessible: module java.base does not "opens java.util.jar" to unnamed module @6baeb178'. [Condition of type ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR] Restarts: 0: [TRY-RECOMPILING] Recompile invoke and try loading it again 1: [RETRY] Retry loading FASL for #<ASDF/LISP-ACTION:CL-SOURCE-FILE "jss" "base" "invoke">. 2: [ACCEPT] Continue, treating loading FASL for #<ASDF/LISP-ACTION:CL-SOURCE-FILE "jss" "base" "invoke"> as having been successful. 3: [RETRY] Retry #<ASDF/FIND-SYSTEM:DEFINE-OP > on #<ASDF/SYSTEM:UNDEFINED-SYSTEM "jna">. 4: [ACCEPT] Continue, treating #<ASDF/FIND-SYSTEM:DEFINE-OP > on #<ASDF/SYSTEM:UNDEFINED-SYSTEM "jna"> as having been successful. 5: [RETRY] Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl">. --more-- Backtrace: 0: (#<FUNCTION {16BC9E4C}> #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {73C52693}> #<FUNCTION {16BC9E4C}>) 1: (APPLY #<FUNCTION {16BC9E4C}> (#<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {73C52693}> #<FUNCTION {16BC9E4C}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {73C52693}> #<FUNCTION {16BC9E4C}>) 3: (INVOKE-DEBUGGER #<ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR {73C52693}>) 4: (ERROR ASDF/FIND-SYSTEM:LOAD-SYSTEM-DEFINITION-ERROR :NAME "jna" :PATHNAME #P"jar:file:///C:/abcl/abcl-contrib.jar!/mvn/jna.asd" ...) 5: (#<FUNCTION {34FA17C0}> #<JAVA-EXCEPTION {64C63DA9}>) 6: (SIGNAL #<JAVA-EXCEPTION {64C63DA9}>) 7: org.armedbear.lisp.Lisp.error(Lisp.java:382) 8: org.armedbear.lisp.Java.jcall(Java.java:946) 9: org.armedbear.lisp.Java$pf_jcall.execute(Java.java:790) 10: org.armedbear.lisp.Primitive.execute(Primitive.java:135) 11: (JCALL #<java.lang.reflect.Method public void java.lang.reflect.Ac.... {4EBBA1A7}> #<java.lang.reflect.Method public java.lang.String java.uti.... {1410F75D}> #<java.lang.Boolean true {41EEBB03}>) 12: (JSS::INVOKE-FIND-METHOD "getName" #<java.util.jar.JarFile$JarFileEntry META-INF/ {254EE0E9}> NIL) 13: (JSS::GET-ALL-JAR-CLASSNAMES #P"c:/abcl/abcl.jar") 14: (JSS:JAR-IMPORT #P"c:/abcl/abcl.jar") 15: (JSS::DO-AUTO-IMPORTS) 16: (#<FUNCTION (LAMBDA ()) {36EBDB7E}>) 17: (FUNCALL #<FUNCTION (LAMBDA ()) {36EBDB7E}>) 18: (SYSTEM:INIT-FASL :VERSION 43) 19: (SYSTEM::%LOAD #P"C:/Users/morte/AppData/Local/cache/common-lisp/abcl-1.8.0-fasl43-win-x64/C/abcl/abcl-contrib.jar/jss/invoke.abcl" NIL NIL T :DEFAULT) --more--

1 1

Issue running minimal example with jss: module java.base does not "opens java.util.jar" to unnamed module
by Phil Eaton 03 Aug '21

03 Aug '21

Hey folks, I've got a minimal program I'm trying to run: (require 'abcl-contrib) (require 'jss) (setf jss:*muffle-warnings* nil) (add-to-classpath #P"~/.m2/repository/io/javalin/javalin/3.13.10/") (jss:jar-import "javalin-3.13.10.jar") (let* ((port 8080) (app (#"start" (#"create" 'Javalin) port))) (begin (#"get" app (lambda (ctx) (#"result" ctx "Hello World"))))) When I run it: abcl --batch --noinform --load main.lisp I get the following exception when requiring jss I think. jssASDF could not load because Java exception 'java.lang.reflect.InaccessibleObjectException: Unable to make public java.lang.String java.util.jar .JarFile$JarFileEntry.getName() accessible: module java.base does not "opens java.util.jar" to unnamed module @1ece4432'.. Error loading /home/phil/.cache/common-lisp/abcl-1.8.0-fasl43-linux-x64/home/phil/vendor/abcl-bin-1.8.0/abcl-contrib.jar/jss/invoke.abcl at line 17 3 (offset 14319) #<THREAD "interpreter" {14B117F6}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'java.lang.reflect.InaccessibleObjectException: Unable to make public java.lang.String java.util.jar.JarFile$JarFileEntry.getName( ) accessible: module java.base does not "opens java.util.jar" to unnamed module @1ece4432'. Any suggestions for getting this (require :jss) working? Thank you! Phil

1 0

ASDF 3.3.5 is released
by Robert Goldman 03 Jul '21

03 Jul '21

Please consider upgrading the version you are distributing with your implementation. Note that this is strictly a bug fix release so should not cause issues in upgrading. But "should" -- software is unpredictable. Announcement email follows. Best, R

1 0

jnew-runtime-class
by phiroc＠free.fr 08 Jun '21

08 Jun '21

Hello, can anyone provide an example of using jnew-runtime-class? Here's the definition I found in the documentation: (CLASS-NAME &REST ; ARGS ; &KEY ; (SUPERCLASS java.lang.Object) ; INTERFACES ; CONSTRUCTORS ; METHODS ; FIELDS ; (ACCESS-FLAGS '(PUBLIC)) ; ANNOTATIONS ; (CLASS-LOADER (MAKE-MEMORY-CLASS-LOADER))) Many thanks. Best regards, Philippe

1 0

Bug # 391
by Don Morrison 27 May '21

27 May '21

I don’t think I have the ability to comment on bugs in the issue tracker, or, if I do, I’ve not figured out how to do it. I hope sending mail to this list for the purpose is acceptable; apologies if not. I note that #391 was opened six years ago, but remains unfixed, and, apart from apparently being pushed off from release to release, seems not to have received any love for four years. I just wanted to add a note to it that it is still being encountered in the wild, and is, at least in one user’s case, causing some pain. File names containing asterisks may not be a good idea, but sometimes we have no control over the names of files we are given. It also means at least one (uiop:subdirectories), and probably many, UIOP functions sometimes fail in what can appear to be mysterious ways on ABCL, but not other implementations. Thanks! -- Don Morrison <dfm(a)ringing.org> “There have been many triumphs of justice which are mockeries of law.” — Thomas Hardy, /The Return of the Native/

1 0

[Reminder CfP] ELS 2021, 14th European Lisp Symposium, May 3-4
by Didier Verna 25 Feb '21

25 Feb '21

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 14th European Lisp Symposium Call for Papers May 3 - May 4, 2021 Online / Everywhere http://www.european-lisp-symposium.org/2021 Sponsored by EPITA and RavenPack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Invited Speakers ~~~~~~~~~~~~~~~~ Nada Amin - Harvard SEAS others tba Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: March 7, 2021 - Author notification: April 6, 2021 - Final papers due: April 19, 2021 - Symposium: May 3 - May 4, 2021 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2021 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 Technical Program ~~~~~~~~~~~~~~~~~ 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 4 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. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following http://www.easychair.org/conferences/?conf=els2021 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Marco Heisig - FAU Erlangen-Nürnberg, Germany Local Chairs ~~~~~~~~~~~~ Michał Herda Mark Evenson - RavenPack Programme Committee ~~~~~~~~~~~~~~~~~~~ Ioanna Dimitriou - Igalia Irène Durand - LaBRI University of Bordeaux R. Matthew Emerson - thoughtstuff LLC Matthew Flatt - University of Utah Jonathan Godbout - Google Paulo Matos - Linki Tools David McClain - SpectroDynamics, LLC Stefan Monnier - University of Montreal Jim Newton - EPITA Research Lab Kent Pitman - HyperMeta Inc. Christophe Rhodes - Google Kai Selgrad - OTH Regensburg Olin Shivers - Northeastern University Robert Smith - Rigetti Quantum Computing Michael Sperber - DeinProgramm Evrim Ulu - Middle East Technical University Breanndán Ó Nualláin - Machine Learning Programs -- Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

[CfP] ELS'21, 14th European Lisp Symposium, online, May 3-4 2021
by Didier Verna 23 Dec '20

23 Dec '20

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 14th European Lisp Symposium Call for Papers May 3 - May 4, 2021 Online / Everywhere http://www.european-lisp-symposium.org/2021 Sponsored by EPITA and RavenPack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Invited Speakers ~~~~~~~~~~~~~~~~ tba Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: March 7, 2021 - Author notification: April 6, 2021 - Final papers due: April 19, 2021 - Symposium: May 3 - May 4, 2021 Scope ~~~~~ The European Lisp Symposium is a premier forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, SKILL, Hy, Shen, Carp, Janet, uLisp, Picolisp, Gamelisp, TXR, and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2021 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 Technical Program ~~~~~~~~~~~~~~~~~ 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 4 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. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following http://www.easychair.org/conferences/?conf=els2021 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Marco Heisig - FAU Erlangen-Nürnberg, Germany Local Chairs ~~~~~~~~~~~~ Michał Herda Mark Evenson - RavenPack Programme Committee ~~~~~~~~~~~~~~~~~~~ tba -- Didier Verna

1 0

Failed assertion about JVM:OFFSET trying to load something
by Robert Dodier 23 Dec '20

23 Dec '20

Hi, I know it may be hard to see what's going on but, I'm trying to load a lisp file into Maxima compiled with ABCL, and I get the error shown below: The assertion (<= -32768 JVM::OFFSET 32767) failed. I've also included a stack trace if that helps. I can supply more info if you tell me what to look for. Thanks so much for your help, Robert Dodier PS. This is in a Maxima session after compiling and launching Maxima. (%i1) :lisp (load "../share/odepack/load-dlsode.lisp") ; (IN-PACKAGE "ODEPACK") ; (LET (# # ...) ...) Error loading /Users/dodier/tmp/maxima-code/share/odepack/load-dlsode.lisp at line 25 (offset 770) #<THREAD "interpreter" {19E01A93}>: Debugger invoked on condition of type SIMPLE-ERROR The assertion (<= -32768 JVM::OFFSET 32767) failed. Restarts: 0: CONTINUE Retry assertion. 1: MACSYMA-QUIT Maxima top-level 2: TOP-LEVEL Return to top level. [1] ODEPACK(5): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<SIMPLE-ERROR {6789AA04}>) 2: (ERROR #<SIMPLE-ERROR {6789AA04}>) 3: (SYSTEM::ASSERT-ERROR (<= -32768 JVM::OFFSET 32767) NIL NIL) 4: (JVM::CODE-BYTES #<(VECTOR T 18397) {4783535E}>) 5: (JVM::FINALIZE-CODE-ATTRIBUTE #<JVM::CODE-ATTRIBUTE {43CBA720}> NIL #<JVM::ABCL-CLASS-FILE {67BB799A}>) 6: (JVM::FINALIZE-ATTRIBUTES (#<JVM::CODE-ATTRIBUTE {43CBA720}>) NIL #<JVM::ABCL-CLASS-FILE {67BB799A}>) 7: (JVM::FINALIZE-METHOD #<JVM::JVM-METHOD {72946D27}> #<JVM::ABCL-CLASS-FILE {67BB799A}>)

2 2

CI switched to GitHub Actions
by Mark Evenson 08 Dec '20

08 Dec '20

A quick note that I have switched the [GitHub hosted CI from Travis to GitHub Actions][1], which is important with news today that Travis seems to have unexpectedly [completely abandoned open source CI][2]. GitHub Actions seems to provide reasonable support for testing things under Windows, which I haven’t fully explored, so there are even more reasons for this change. For developers, forking the GitHub repository from another GitHub account should give you access to the CI pretty much automatically. You just need to look at the results under the “Actions” tab when viewing your copy of the repository. [1]: <https://github.com/armedbear/abcl/blob/master/.github/workflows/abcl-test.y…> [2]: <https://news.ycombinator.com/item?id=25338983> -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

CLOS MOP bug in 1.8.0
by Pascal Costanza 28 Nov '20

28 Nov '20

Hi, I have encountered a bug in 1.8.0 when doing my regular Closer to MOP checks. This must be a new bug, because 1.7.1 was fine. Here is the case that triggers the problem: (use-package :mop) (defclass test-direct-slot-definition (standard-direct-slot-definition) ()) (defclass test-effective-slot-definition (standard-effective-slot-definition) ()) (defclass test-class (standard-class) ()) (defmethod validate-superclass ((class test-class) (superclass standard-class)) t) (defmethod direct-slot-definition-class ((class test-class) &rest initargs) (declare (ignore initargs)) (find-class 'test-direct-slot-definition)) (defmethod effective-slot-definition-class ((class test-class) &rest initargs) (declare (ignore initargs)) (find-class 'test-effective-slot-definition)) (defclass test-object () ((some-slot :accessor some-slot :initarg :some-slot :initform 'some-slot :type symbol :allocation :class :documentation "a slot")) (:metaclass test-class)) (unless (class-finalized-p (find-class 'test-object)) (finalize-inheritance (find-class 'test-object))) Armed Bear Common Lisp 1.8.0 Java 15.0.1 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.134 seconds. Startup completed in 0.65 seconds. Loading /Users/costanza/.abclrc completed in 6.061 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "test.lisp") Error loading /Users/costanza/Temp/test.lisp at line 36 (offset 943) #<THREAD "interpreter" {1970D65C}>: Debugger invoked on condition of type UNBOUND-SLOT The slot LOCATION is unbound in the object #<TEST-EFFECTIVE-SLOT-DEFINITION {556F331F}>. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNBOUND-SLOT {67D22A29}>) 2: (ERROR UNBOUND-SLOT :INSTANCE #<TEST-EFFECTIVE-SLOT-DEFINITION {556F331F}> :NAME SYSTEM::LOCATION) 3: (#<FUNCTION #<FUNCTION {22446549}> {22446549}> (#<STANDARD-CLASS TEST-EFFECTIVE-SLOT-DEFINITION {6670307A}> #<TEST-EFFECTIVE-SLOT-DEFINITION {556F331F}> SYSTEM::LOCATION)) 4: (SLOT-VALUE #<TEST-EFFECTIVE-SLOT-DEFINITION {556F331F}> SYSTEM::LOCATION) 5: (SLOT-DEFINITION-LOCATION #<TEST-EFFECTIVE-SLOT-DEFINITION {556F331F}>) 6: (MOP::STD-FINALIZE-INHERITANCE #<TEST-CLASS TEST-OBJECT {67510DAF}>) 7: (#<FUNCTION #<FUNCTION {2C5408FE}> {2C5408FE}> (#<TEST-CLASS TEST-OBJECT {67510DAF}>)) I believe the bug is triggered by find-class or class-finalized-p, but not sure. Pascal -- Pascal Costanza

2 1

Feature request: command-line option to disable debugger
by Robert Munyer 27 Nov '20

27 Nov '20

Many Lisp implementations (including CCL, CLISP and SBCL) have a command-line option that causes unhandled errors to terminate the Lisp process instead of invoking the debugger. This option is useful for programs that don't have irreplaceable valuable state in the heap, and that have users whose reaction upon seeing a debug REPL would be "How do I get out of this!?". Also, a few days ago someone on IRC mentioned having the problem that "if there is an error in the expression" the server thread "gets locked in the ABCL repl". I think his or her use-case might also benefit from a debugger-disabling switch. Happy Thanksgiving!

2 1

Bug report: COMPILE-FILE not doing minimal compilation in DEFCONSTANT/DEFPARAMETER/DEFVAR
by Robert Munyer 16 Nov '20

16 Nov '20

COMPILE-FILE is supposed to expand all macros in such a way that they will not be expanded again when the compiled file is loaded. (3.2.2.2) The file below has 4 output lines that start with "*** Expanding macro". None of those lines should be printed when the compiled file is loaded. ------- begin test-min-compilation.lisp ------- (macrolet ((m1 () (format t "~&*** Expanding macro 1.~%") '(format t "~&Output of macro 1.~%"))) (m1)) (defconstant +dc+ (macrolet ((m2 () (format t "~&*** Expanding macro 2 inside DEFCONSTANT.~%") '(format t "~&Output of macro 2.~%"))) (m2))) (defparameter *dp* (macrolet ((m3 () (format t "~&*** Expanding macro 3 inside DEFPARAMETER.~%") '(format t "~&Output of macro 3.~%"))) (m3))) (defvar *dv* (macrolet ((m4 () (format t "~&*** Expanding macro 4 inside DEFVAR.~%") '(format t "~&Output of macro 4.~%"))) (m4))) ------- end test-min-compilation.lisp ------- CCL, CLISP, ECL and SBCL print none of the 4, ABCL prints 3 of the 4. This one might be relatively easy, because ABCL is already handling #1 correctly, and just needs to handle #2/3/4 in the same way as #1. The rest of this message is the transcript. $ java -jar abcl-344b4f66.jar Armed Bear Common Lisp 1.8.1-dev Java 1.8.0_272 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.183 seconds. Startup completed in 0.837 seconds. Type ":help" for a list of available commands. CL-USER(1): (compile-file "test-min-compilation.lisp") ; Compiling /tmp/foo/test-min-compilation.lisp ... ; (M1) *** Expanding macro 1. ; (DEFCONSTANT +DC+ ...) *** Expanding macro 2 inside DEFCONSTANT. Output of macro 2. ; (DEFPARAMETER *DP* ...) ; (DEFVAR *DV* ...) ; Wrote /tmp/foo/test-min-compilation.abcl (0.163 seconds) #P"/tmp/foo/test-min-compilation.abcl" NIL NIL CL-USER(2): (load "test-min-compilation.abcl") Output of macro 1. *** Expanding macro 2 inside DEFCONSTANT. Output of macro 2. *** Expanding macro 3 inside DEFPARAMETER. Output of macro 3. *** Expanding macro 4 inside DEFVAR. Output of macro 4. T CL-USER(3):

2 1

Bug report: Loading a FASL into a package which doesn't import SETQ
by Robert Munyer 16 Nov '20

16 Nov '20

The code below works in CCL, CLISP and SBCL, but not in ABCL. $ echo '(cl:format cl:t "~&I am in package ~s.~%" cl:*package*)' > foo.lisp $ java -jar abcl-1.7.1.jar Armed Bear Common Lisp 1.7.1 Java 1.8.0_265 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.236 seconds. Startup completed in 0.931 seconds. Type ":help" for a list of available commands. CL-USER(1): (defpackage "BAR" (:use)) #<PACKAGE BAR> CL-USER(2): (let ((*package* (find-package "BAR"))) (load (compile-file "foo"))) ; Compiling /tmp/foo/abcl-bin-1.7.1/foo.lisp ... ; (COMMON-LISP:FORMAT COMMON-LISP:T ...) ; Wrote /tmp/foo/abcl-bin-1.7.1/foo.abcl (0.036 seconds) Error loading /tmp/foo/abcl-bin-1.7.1/foo.abcl at line 4 (offset 125) #<THREAD "interpreter" {1B31C40C}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function BAR::SETQ is undefined. Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to SETQ. 3: TOP-LEVEL Return to top level. [1] BAR(3):

4 16

ABCL Docker Images
by Eric Timmons 12 Nov '20

12 Nov '20

Hello fans of the Armed Bear, As you've probably noticed, Docker and similar technologies are extremely popular these days. Additionally, there is unfortunately no Common Lisp representation in Docker's Official Images program (the Docker standard library, if you will). I'd like to change that and ABCL seems like a good candidate to start with because it's both relatively simple to Dockerize and Mark is supportive of getting CL representation in that program. I've been maintaining some Common Lisp related Docker images in my personal namespace (daewok) for several years now. I recently moved the repos to a gitlab.common-lisp.net group (mirrored to Github) and have cleaned up/gotten ABCL's repos into a state where I believe they adhere to all of the Official Image program's guidelines and are ready for inclusion. I wanted to reach out to 1) get any feedback from ABCL devs and users to make sure the images are useful and 2) get consent from the ABCL devs to submit to the program. First, the code: The Dockerfiles themselves are located at https://gitlab.common-lisp.net/cl-docker-images/abcl The manifest for inclusion in the Official Images program is at https://gitlab.common-lisp.net/cl-docker-images/official-images/-/blob/abcl… The documentation for inclusion on Docker Hub is at https://gitlab.common-lisp.net/cl-docker-images/docs/-/tree/abcl/abcl All of these are also mirrored to the cl-docker-images org on Github. The images are built for the cross product of {buster, windowsservercore-1809, windowsservercore-ltsc2016} x {jdk8, jdk11, jdk15} x {arm64, amd64} (except for all combos containing jdk8 and arm64). The current versions of the images are located at https://hub.docker.com/r/daewok/abcl if you would like to check them out. I am planning that only the latest version of ABCL will be "supported". The initial request would also backfill 1.7.1. Once a version becomes unsupported it would not be removed from Docker hub, it just receives no more base image updates. Next, some info about Docker Official Images: Documentation on the program is located at https://docs.docker.com/docker-hub/official_images/ and https://github.com/docker-library/official-images In summary, every image in the program is reviewed by a team for best practices and security, built by that team, and is available for pulling without specifying a namespace (e.g., `docker pull abcl:latest`). This helps give users confidence in the code they're running, as opposed to pulling from random personal namespaces. Even the Official Images team admits that "Official Images" is not a great name as it can imply that the upstream of the software contained in the image maintains the images when that is frequently not the case. As I'm not an ABCL dev myself, the image would be considered community maintained and the description on Docker Hub would clearly point to the cl-docker-images/abcl repo as where to file issues with the images. But it is very conceivable that random users may show up on this list asking for help. I am subscribed to this list and will do my best to redirect/answer any of those types of emails that come in. Thoughts, questions, concerns? -Eric

3 4

Bug report: COMPILE-FILE, COMPILE-FILE-PATHNAME disagree on output dir
by Robert Munyer 11 Nov '20

11 Nov '20

COMPILE-FILE-PATHNAME is supposed to return "the pathname that COMPILE-FILE would write into, if given the same arguments" but in the example below, COMPILE-FILE-PATHNAME returns "src/obj/foo.abcl" while the file that is actually written into is "obj/foo.abcl". Looking at the spec, my opinion is that COMPILE-FILE is doing the right thing, and COMPILE-FILE-PATHNAME should be changed to match it. I suppose some might disagree with me about which behavior is correct, but no one can disagree that the two functions' behavior should match. $ mkdir src obj $ echo '(format t "~&Hello, world!~%")' > src/foo.lisp $ java -jar abcl-1.7.1.jar Armed Bear Common Lisp 1.7.1 Java 1.8.0_272 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.179 seconds. Startup completed in 0.828 seconds. Type ":help" for a list of available commands. CL-USER(1): (defvar *infile* (make-pathname :directory '(:relative "src") :name "foo" :type "lisp")) *INFILE* CL-USER(2): (defvar *outfile* (make-pathname :directory '(:relative "obj") :type "abcl" :defaults *infile*)) *OUTFILE* CL-USER(3): (compile-file *infile* :output-file *outfile*) ; Compiling /tmp/foo/src/foo.lisp ... ; (FORMAT T ...) ; Wrote /tmp/foo/obj/foo.abcl (0.014 seconds) #P"/tmp/foo/obj/foo.abcl" NIL NIL CL-USER(4): (compile-file-pathname *infile* :output-file *outfile*) #P"/tmp/foo/src/obj/foo.abcl" CL-USER(5):

2 5

ABCL 1.8.0
by Mark Evenson 01 Nov '20

01 Nov '20

ABCL 1.8.0 Under the gathering storms of the Fall 2020, we are pleased to release ABCL 1.8.0 as the Ninth major revision of the implementation. This Ninth Edition of the implementation now supports building and running on the recently released openjdk15 platform. This release is intended as the last major release to support the openjdk6, openjdk7, and openjdk8 platforms, for with abcl-2.0.0 we intend to move the minimum platform to openjdk11 or better in order to efficiently [implement atomic memory compare and swap operations][github/issues/92]. With this release, the implementation of the EXT:JAR-PATHNAME and EXT:URL-PATHNAME subtypes of cl:PATHNAME has been fixed to the point that arbitrary references to ZIP archives within archives now work for read-only stream operations (CL:PROBE-FILE, CL:TRUENAME, CL:OPEN, CL:LOAD, CL:FILE-WRITE-DATE, CL:DIRECTORY, and CL:MERGE-PATHNAMES). The previous versions of the implementation relied on the ability for java.net.URL to open streams of an archive within an archive, behavior that was silently dropped after Java 5, and consequently hasn't worked on common platforms supported by the Bear in a long time. The overhaul of the implementation restores the feasibility of accessing fasls from within jar files. Interested parties may examine the ASDF-JAR contrib for a recipe for packaging and accessing such artifacts. Please consult the ["Beyond ANSI: Pathnames" Section 4.2 of the User Manual][manual] for further details for how namestrings and components of PATHNAME objects have been revised. A more comprehensive list of [CHANGES][] is available with the source. [1.8.0]: https://abcl.org/releases/1.8.0/ [asdf-jar]: https://abcl.org/svn/trunk/abcl/contrib/asdf-jar/README.markdown [github/issues/92]: https://github.com/armedbear/abcl/issues/92 [manual]: https://abcl.org/releases/1.8.0/abcl-1.8.0.pdf [CHANGES]: https://abcl.org/svn/tags/1.8.0/CHANGES -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

5 9

Bug report: Wrong file type returned by COMPILE-FILE-PATHNAME
by Robert Munyer 27 Oct '20

27 Oct '20

The code below returns "lx64fsl" in CCL, "fas" in CLISP, and "fasl" in SBCL, but returns "lisp" in ABCL. I think it should return "abcl" in ABCL. $ java -jar abcl-1.7.1.jar Armed Bear Common Lisp 1.7.1 Java 1.8.0_272 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.586 seconds. Startup completed in 1.336 seconds. Type ":help" for a list of available commands. CL-USER(1): (pathname-type (compile-file-pathname (make-pathname :name "foo" :type "lisp") :output-file (make-pathname :name "bar"))) "lisp" CL-USER(2):

2 1

Possible that abcl-2.0.0 will not support openjdk8
by Mark Evenson 06 Oct '20

06 Oct '20

A question for all Bear fans: would you be severly impacted if abcl-2.0.0 dropped support for openjdk8, just supporting openjdk11 and up? In order to realistically get ABCL to implement Compare and Swap at all efficiently, I think we need to require that the JVM memory access model conforms to the fixes identified by Doug Lea et. al. as codified in the [VarHandle interface first introduced in openjdk9][varhandle]. abcl-1.8.0 would be the last release supporting openjdk8. Comments with this policy? Please yell early if you absolutely could not migrate an existing use of ABCL to openjdk11. [cas]: https://github.com/armedbear/abcl/issues/92 [varhandle]: https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/invo… -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 1

Bug report: Regression, immediately invoked function expressions
by Robert Munyer 01 Oct '20

01 Oct '20

The function below works in CCL, CLISP, SBCL and ABCL 1.4.0, but not in ABCL 1.7.1. $ java -jar abcl-1.7.1.jar Armed Bear Common Lisp 1.7.1 Java 1.8.0_265 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.188 seconds. Startup completed in 0.869 seconds. Type ":help" for a list of available commands. CL-USER(1): (defun add3 (foo) ((lambda (bar) ((lambda (baz) (1+ baz)) (1+ bar))) (1+ foo))) #<THREAD "interpreter" {32B46F86}>: Debugger invoked on condition of type TYPE-ERROR The value (LAMBDA (BAZ) (1+ BAZ)) is not of type SYMBOL. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2):

3 5

Bug report: IllegalStateException, when reading after rewinding
by Robert Munyer 01 Oct '20

01 Oct '20

The code below works in CCL, CLISP and SBCL, but not in ABCL. $ echo hello > hello.text $ java -jar abcl-1.7.1.jar Armed Bear Common Lisp 1.7.1 Java 1.8.0_265 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.181 seconds. Startup completed in 0.945 seconds. Type ":help" for a list of available commands. CL-USER(1): (with-open-file (in "hello.text") (list (read in) (read in nil) (file-position in :start) (read in))) java.lang.IllegalStateException: Current state = CODING_END, new state = CODING at java.nio.charset.CharsetDecoder.throwIllegalStateException(CharsetDecoder.java:992) at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:572) at org.armedbear.lisp.util.RandomAccessCharacterFile.read(RandomAccessCharacterFile.java:392) [ many stack frames elided ] at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:748) #<THREAD "interpreter" {2CD58E2}>: Debugger invoked on condition of type ERROR Caught java.lang.IllegalStateException: Current state = CODING_END, new state = CODING. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2):

2 2

The road to ABCL 2.0.0
by Mark Evenson 19 Sep '20

19 Sep '20

Greetings Armed Bear fans, Since, I've been able to get our favorite Bear to run on [openjdk15][6], which has now replaced openjdk14 in our CI test regime, an update is in order about the release schedule of [ABCL 2.0][3] for those of you following along at home, and let’s face it: only the homeless aren’t at home these days. ** Either abcl-1.8.0, or abcl-2.0.0 or both will be released by 10.10.2020 ** [abcl-1.8.0][1] will be the last release support openjdk6 and openjdk7 runtimes. [abcl-2.0.0][2] will require openjdk8, and will run on openjdk11, openjdk13, openjdk14, and openjdk15. We will fix compatibility with previous versions of the implementation by incompletely and inefficiently re-implement the use of CL:PATHNAME-DEVICE to "paper over” the use of nested jar references. The ability to access nested jar entries via CL:PATHNAME references has been broken since the openjdk support for nested references to jar files dropped for their creation. Nobody seemed to notice this problem, accept for customers of the [ASDF-JAR][4] contrib which is currently unable to load classes Since either openjdk5 or openjdk6, references like #p"jar:jar:file:/var/tmp/cl-ppcre-2.1.1.jar!/cl-ppcre/packages.abcl!/__loader__._” while syntactically valid cannot actually address the contents on zip files withing zip files. Since we would like such nested jar entries for use by strategies like ABCL All-in-Once (AiO), with [abcl-1.8.0][2] will allow an arbitrary PATHNAME-DEVICE component designating a sequence of nested archive entries. With openjdk8, we can use abstractions to make the caching efficient, but the current strategy (will) just reference everything by a weak reference to allow the implementation to garbage collect if it finds itself under memory pressure. In an era of the available of cheap gibibyte heaps, potentially retaining references to the bytes of artifacts accessed via CL:LOAD will be a viable strategy for at least the core implementation which is only ~ 11 mebibyte. ABCL-2.0.0 will use all of the ABCL-1.8.0 code in additional to an implementation of multi-threaded sensitive atomic operations supporting ubiquitous contemporary ANSI CL compare and swap for memory. The presence of a new compiler for ABCL-2.0.0 is no longer a release driver as it currently stands, but I would love some help if it shows up. Once I get things working well under openjdk8, I will start to work on the new compiler infrastructure. Comments, patches, criticisms welcome! yours, Mark [1]: <https://github.com/armedbear/abcl/blob/05e4b396658d7ba4bd074a8e4f627deec3b7…> [2]: <https://abcl.org/trac/milestone/1.8.0> [3]: <https://abcl.org/trac/milestone/2.0.0> [4]: <https://gitlab.common-lisp.net/abcl/abcl/-/blob/master/contrib/abcl-asdf/RE…> [5]: <https://gitlab.common-lisp.net/abcl/abcl/-/commit/0ba7dea278a474efe0a8e7550…> [6]: <https://travis-ci.org/github/armedbear/abcl/jobs/728128870> -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

Challenge with ABCL on a commercial project: Licensing
by Steven Nunez 07 Sep '20

07 Sep '20

Gents, I nearly had ABCL into an upcoming project, until I checked the license. I should have looked at this before I embarked down this path, but for some reason assumed that since ABCL is a relatively young implementation it was using Apache/MIT/BSD or something similar. Here's the opensource clause from the contract: 1.1 OPEN SOURCE SOFTWARE. To the extent that the Company develops orprovides any software to <Customer> under this Agreement, without <Customer’s> priorwritten consent, that <Customer> may grant or withhold in its sole discretion, nosuch deliverable shall incorporate, link to or call upon any Open SourceSoftware. “Open Source Software” means any software that is generally availableto the public in source code form under (i) licenses substantially similar tothose approved by the Open Source Initiative and listed athttp://www.opensource.org/licenses, or (ii) any copyleft license (including aReciprocal License), or (iii) any other license that contains terms thatrequire, whether or not conditionally, disclosure of any source code. This clause, or one very much like it, has been in every contract for the last 10 years or so, or at least since the BusyBox debacle. Most of the time companies have a list of pre-approved licenses, with MIT/Apache/BSD almost always being on it. Note the specific exclusion "any copyleft license" and any license in any form that might cause disclosure of source code. Reading the ABCL FAQ and web page, it seems the intention is to avoid compelling a company from releasing their source code: The use of Armed Bear Common Lisp (ABCL) is covered by the GNU General Public License with Classpath exception, meaning that you can use ABCL in your application without the requirement to open the sources to your application. However there's a few problem with this: - It has the words "GNU General Public License", which rings loud alarm bells with corporate lawyers (and is disqualified by clauses ii/iii anyway) - Whilst the intention is to allow ABCL to be mixed with proprietary code, the IP equivalent of ambulance chasing lawyers may still see it as an opportunity for profit. It's worth reading the BusyBox saga if you're not familiar with it. - It's never been tested in court The last point is worth elaborating on. I once cornered a friendly corporate lawyer at one of our company drinks functions and showed him the LLGPL and asked what he thought. His response put it all in perspective. He said: "It looks fine to me, but it's never been tested in court. Would you take an open source project and deploy it to production and bet the company's livelihood on it, without testing it first?" I guess I can't blame them really. Would you want stick your neck out for something with potentially catastrophic consequences, when there's plenty of alternatives? Lisp has enough of an uphill climb just on the technology front, this is the nail in the coffin. Questions: - Would the current maintainers of ABCL consider relicensing it under a MIT, BSD or Apache license? - If so, do we have a list of all the contributors? - If so, how many are there and are they contactable?

6 9

Test
by Steven Nunez 08 Aug '20

08 Aug '20

Testing. I sent out a message last night but haven't seen it yet; neither in my mailbox nor the archives.

1 0

Am I at a dead-end?
by Steven Nunez 07 Aug '20

07 Aug '20

I've been looking at a few other ways to accomplish wrapping Spark, and none look good. I could generate Java functions, which seem to be inherently serialisable, but that defeats the point of using ABCL. I also considered an approach using Java to call into ABCL, but then I've got to ensure that the ABCL functions are distributed to each node, defeating the point of using Spark. @Alessio Stalla, your most recent github commit suggests that things might have moved along to the point that function and closure serialisation is working. Are things stable enough to give it a try? Not this week, but perhaps on Monday? I'm happy to debug anything that I turn up. There's a new project on the horizon and I'd like to use the Java compatibility angle to try and get Lisp into it. If I'm lucky, I may not even have to mention lisp, depending on how/if the contract terms work out.

2 3

Regarding Steps Towards ABCL STEP Functionality
by loveleague 03 Aug '20

03 Aug '20

Hello, While reading through the release manual, I came across the realization -- from section 1.1.2 -- that ABCL still needs an implementation of the STEP function. I would like to look into the details of the hurdles one might need to overcome to bring STEP functionality to ABCL. I imagine there may be some additional challenges from dealing with the JVM, but I'm not well versed as of yet on the topic of debuggers or JVM internals. If it would be possible to share some details on where one would get started in trying to approach this, that would be appreciated. - Luke

4 3

run-program issues with OpenJDK 11
by Eric Timmons 30 Jul '20

30 Jul '20

It appears that java.lang.UNIXProcess was removed in OpenJDK 9 or thereabouts, assuming I'm interpreting https://github.com/openjdk/jdk/commit/aa6b19f38ee4dc69cac664d1211bff0e69b31… correctly (/definitely/ not a Java developer here...). This seems to make run-program unusable when using prebuilt jars on recent JREs. Using the prebuilt 1.7.0 release and OpenJDK 11, I get the errors shown in prebuilt-openjdk11.txt (attached). If compiling using OpenJDK 11, run-program seems usable, but any attempt to get the PID of a process gives the error in from-source-openjdk11.txt (attached). -Eric VM settings: Max. Heap Size (Estimated): 7.79G Using VM: OpenJDK 64-Bit Server VM Armed Bear Common Lisp 1.7.0 Java 11.0.7 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.198 seconds. Startup completed in 1.107 seconds. Type ":help" for a list of available commands. CL-USER(1): (sys:run-program "ls" nil) Error loading jar:file:/home/abcl/work/abcl/dist/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 278 (offset 19142) #<THREAD "interpreter" {5C1AE0C4}>: Debugger invoked on condition of type ERROR Class not found: java.lang.UNIXProcess Restarts: 0: TOP-LEVEL Return to top level. [1] SYS(2): 0 java.lang.ExceptionInInitializerError at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) at java.base/java.lang.Class.newInstance(Class.java:584) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Load.loadSystemFile(Load.java:255) at org.armedbear.lisp.Autoload.effectiveLoad(Autoload.java:110) at org.armedbear.lisp.Autoload.load(Autoload.java:147) at org.armedbear.lisp.Lisp.eval(Lisp.java:537) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3743) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:285) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.top_level_47.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.top_level_48.execute(top-level.lisp:415) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Interpreter.run(Interpreter.java:361) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: org.armedbear.lisp.Go Error loading jar:file:/home/abcl/work/abcl/dist/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 278 (offset 19142) #<THREAD "interpreter" {5C1AE0C4}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.run_program_60 from org.armedbear.lisp.Pathname@49bd2fd0 Restarts: 0: TOP-LEVEL Return to top level. [1] SYS(3): 0 CL-USER(4): (exit) VM settings: Max. Heap Size (Estimated): 7.79G Using VM: OpenJDK 64-Bit Server VM Armed Bear Common Lisp 1.7.1-dev Java 11.0.7 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.205 seconds. Startup completed in 1.224 seconds. Type ":help" for a list of available commands. CL-USER(1): (sys:run-program "ls" nil :wait nil) #S(SYSTEM:PROCESS :JPROCESS #<java.lang.ProcessImpl Process[pid=125, exitValue=0] {1E464845}> :%INPUT #S(SYSTEM::SYSTEM-STREAM) :%OUTPUT #S(SYSTEM::SYSTEM-STREAM) :%ERROR #S(SYSTEM::SYSTEM-STREAM)) CL-USER(2): (sys:process-pid *) #<THREAD "interpreter" {7278E1D6}>: Debugger invoked on condition of type ERROR Class not found: java.lang.UNIXProcess Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): 0 CL-USER(4): (exit)

3 8

java:jinterface-implementation: multiple interfaces?
by Steven Nunez 30 Jul '20

30 Jul '20

Is there a way to implement multiple interfaces on a single Java proxy? This code almost works: (java:jinterface-implementation "org.apache.spark.api.java.function.Function" "call" (lambda (s) (length s))) except that the proxy also needs to implement Serializable. The jproxy code in java.lisp seems to suggest that multiple implementations are allowed: (defgeneric jmake-proxy (interface implementation &optional lisp-this) (:documentation "Returns a proxy Java object implementing the provided interface(s)... but I can't see adding multiple implementations in the code. I see there's a few jmake-proxy methods in there though: are there any documentation or examples for their usage? Lsw2 doesn't use this at all and I can't find any other good examples of using ABCL. Multiple interfaces from the jinterface-implementation function would be ideal, as the above code could then be wrapped with a macro to produce a 'spark-lambda' and be used nearly like the regular ABCL lambda.

3 12

JDK8 Style Lambda Functions and ABCL
by Steven Nunez 30 Jul '20

30 Jul '20

Greetings all, I'm trying to convert the following Java code in the "Basics" section of the Spark Programming Guide to ABCL: JavaRDD<Integer> lineLengths = lines.map(s -> s.length()); I know that "s -> s.length" is a JDK8 style lambda function with one parameter, returning the result of calling length() on 's'. What I'd like to be able to do is write: (let ((line-lengths (#"map" *lines* (lambda (s) (#"length" s))))) but this isn't getting me anywhere, with Java saying there is no applicable method 'map' on *lines* (an instance of JavaRDD). There is such a method (if it matters, it is inherited by JavaRDD from interface JavaRDDLike). Investigating that map method a bit further, it seems to want an org.apache.spark.api.java.function. Here's a clip from the Spark description: Spark’s API relies heavily on passing functions in the driver program to run on the cluster. In Java, functions are represented by classes implementing the interfaces in the org.apache.spark.api.java.function package. There are two ways to create such functions: - Implement the Function interfaces in your own class, either as an anonymous inner class or a named one, and pass an instance of it to Spark. - Use lambda expressions to concisely define an implementation. I think what I'm getting from the ABCL lambda expression is a java.util.function: SPARK> (describe (lambda (s) #"length" s))#<FUNCTION #<FUNCTION (LAMBDA (S)) {70B82AD0}> {70B82AD0}> is an object of type FUNCTION.The function's lambda list is: (S) I do wonder though how the Java lambda "s -> s.length()" manages to produce the correct result, so this theory may not be correct. The Spark guide goes on to say: While much of this guide uses lambda syntax for conciseness, it is easy to use all the same APIs in long-form. For example, we could have written our code above as follows: JavaRDD<String> lines = sc.textFile("data.txt"); JavaRDD<Integer> lineLengths = lines.map(new Function<String, Integer>() { public Integer call(String s) { return s.length(); } }); int totalLength = lineLengths.reduce(new Function2<Integer, Integer, Integer>() { public Integer call(Integer a, Integer b) { return a + b; } }); Or, if writing the functions inline is unwieldy: class GetLength implements Function<String, Integer> { public Integer call(String s) { return s.length(); } } class Sum implements Function2<Integer, Integer, Integer> { public Integer call(Integer a, Integer b) { return a + b; } } JavaRDD<String> lines = sc.textFile("data.txt"); JavaRDD<Integer> lineLengths = lines.map(new GetLength()); int totalLength = lineLengths.reduce(new Sum()); To me, both of those examples look unwieldy. There was a stack overflow discussion on creating Java classes with ABCL from 9 years ago, and I've read the java interface examples on abcl.org, but both of those techniques look like they will produce code just as unwieldy as the Java syntax above. Is there any way to use a lisp-style lambda syntax to produce a function that will satisfy Spark's requirement to implement the org.apache.spark.api.java.function interface? If not, the obvious route would be some macrology to create a defsparkfun, defsparkfun2, etc. that wrap the ABCL function I want to use with something that implements 'call' in the org.apache.spark.api.java.function interface. I'm hoping there's a better way.

2 3

Third Brick Wall
by Steven Nunez 27 Jul '20

27 Jul '20

OK, I'm on lines 4 and 5 of 'hello world' and ran into yet another brick wall. Trying to convert the following two lines into ABCL: List<Integer> data = Arrays.asList(1, 2, 3, 4, 5); JavaRDD<Integer> distData = sc.parallelize(data); it looks like it should be easy. Heck, I can do that in one line: (#"parallelize" *sc* '(1 2 3 4 5)) ; *sc* defined yesterday and known to be correct But no, it claims "no applicable method named parallelize found on JavaSparkContext" (but there is!). Reading through section 3.1.1 of the documentation, it appears that this is probably because '(1 2 3...) is a LispObject and not a Java object (why no automatic conversion?). Let's try to convert it: (#"parallelize" *sc* (#"copytoArray" '(1 2 3 4 5))) No instance method named copytoArray found for type org.armedbear.lisp.Cons' And the same with using an array, e.g. (#"parallelize" *sc* (#"copytoArray" #(1 2 3 4 5))) Sigh It's been a week and my intention was to have a working prototype by now and present ABCL as a viable alternative to use in a project. I haven't got past line 5 in 'hello world'. This doesn't bode well. I've been reading about ABCL for years, and it's impressive. Full MOP, extensible sequences, nearly 100% ANSI compliance, and the ability to deploy on the JVM are major achievements. However, as a not-inexperienced Lisp programmer, I find the barrier to entry remarkably high and the documentation and examples sparse and insufficient to surmount the hurdles I encountered. Please take these comments in the way they are intended: constructive feedback from someone who is a fan of the project and would love to be able to use it. It's nearly impossible to get Lisp introduced into enterprise environments, and ABCL provides a wedge into those types of projects, ticking the boxes on deployment and ability to work with legacy Java code. Perhaps it makes more sense to someone approaching Lisp from the Java side, but coming from the Lisp side to Java, there's a high barrier to entry. I know that no volunteer wants to write documentation, but more and clearer docs are sorely needed here. This is probably not news, but sometimes it helps to be reminded of the obvious. I hate giving up, so this will be a personal background project in the hopes that at the next opportunity things will have improved to the point where we can consider introducing ABCL, so if anyone has any pointers, generally (though I think I would have found any docs or examples (lsw2) by now) and explaining this problem in particular, it would be greatly appreciated. @easye, you mentioned your ember project. If you're going to continue with that, please message me. A Spark wrapper would be useful, serve as a good exemplar for using ABCL to wrap a large library and, with a companion tutorial, help others overcome the kind of obstacles I've encountered. I'd be happy to contribute.

4 9

Create instance of generic class at runtime, supplying specializer?
by Alan Ruttenberg 21 Jul '20

21 Jul '20

For instance in http://owlcs.github.io/owlapi/apidocs_4/org/semanticweb/owlapi/util/Inferre… It says: Type Parameters:A - the axiom type Question is: how do I supply the axiom type when creating an instance. Thanks ALan

3 5

abcl-1.7.1 released
by Mark Evenson 18 Jul '20

18 Jul '20

With gentle prodding, we have released ABCL 1.7.1, a decidedly minor release correcting a few bugs resulting from the overhaul of arrays specialized on unsigned byte types. The brief list of CHANGES is a available for your perusal. <https://abcl.org/releases/1.7.1/> <https://abcl.org/svn/tags/1.7.1/CHANGES>. "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

ABCL-1.7.0 released
by Mark Evenson 05 Jun '20

05 Jun '20

We are pleased to announce the immediate availablity of the [ABCL 1.7.0 release][]. After consuming a steady diet of java.nio.ByteBuffer objects over the past month, the Bear has managed to incorporate the use of these abstractions for arrays specialized on the commonly used unsigned-byte types (or (unsigned-byte 8) (unsigned-byte 16) (unsigned-byte 32)). This replacement of the use arrays of primitive bytes is denoted by the presence of the :NIO keyword in CL:*FEATURES*. With this :NIO overhaul, we have extended our implementation of ANSI Common Lisp [CL:MAKE-ARRAY][] with two additional keywords, viz. :NIO-BUFFER and :NIO-DIRECT. The :NIO-BUFFER keyword argument allows one to construct a vector directly utilizing the contents of an already allocated java.nio.ByteBuffer object. When combined with the ability of JNA to allocate memory on the heap via a malloc() system call, we implemented shareable byte vectors in [CFFI-SYS:MAKE-SHAREABLE-BYTE-VECTOR][]. (let* ((length 16) (byte-buffer (java:jstatic "allocate" "java.nio.ByteBuffer" length))) (make-array length :element-type ’(unsigned-byte 8) :nio-buffer byte-buffer)) When the :NIO-DIRECT keyword argument is called with a non-NIL value, the implementation creates a byte vector with a "directly allocated" java.nio.ByteBuffer object. Such direct buffers typically have somewhat higher allocation and deallocation costs than non-direct buffers. The contents of direct buffers may reside outside of the normal garbage-collected heap, and so their impact upon the memory footprint of an application might not be obvious. It is therefore recommended that direct buffers be allocated primarily for large, long-lived buffers that are subject to the underlying system’s native I/O operations. In general it is best to allocate direct buffers only when they yield a measureable gain in program performance. In the near future, we intend to exploring the performance gains available CL:LOAD by accessing direct buffers memory mapped to our on-disk fasl representation. Our fasls, as zipped archives, currently require a new seek() from the beginning of the fasl for each component they contain. With a memory mapped direct buffer we should be able to simply read from the appropiate byte offset for each component. A complete overview of the accumulated fixes and changes since the previous release may be viewed in [CHANGES][]. [ABCL 1.7.0 release]: https://abcl.org/releases/1.7.0/ [java.nio.ByteBuffer]: https://www.doc.ic.ac.uk/csg-old/java/jdk6docs/api/java/nio/ByteBuffer.html [CFFI-SYS:MAKE-SHAREABLE-BYTE-VECTOR]: https://github.com/cffi/cffi/commit/47136ad9a97c2df98dbcd13a068e14489ced5b03 [CHANGES]: https://abcl.org/svn/tags/1.7.0/CHANGES [CL:MAKE-ARRAY]: https://github.com/armedbear/abcl/commit/6c4b7f3c11b2c8151f4599c9bddf5c0991… -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

3 3

Re: armedbear-devel Digest, Vol 64, Issue 4
by Stephen Varey 20 May '20

20 May '20

I have also tried powerloom with Allegro common lisp which works fine. It works with LispWorks if you change one option to do with a the latin-1 char set. On Wed, May 20, 2020 at 2:00 PM <armedbear-devel-request(a)common-lisp.net> wrote: > Send armedbear-devel mailing list submissions to > armedbear-devel(a)common-lisp.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.common-lisp.net/listinfo/armedbear-devel > or, via email, send a message with subject or body 'help' to > armedbear-devel-request(a)common-lisp.net > > You can reach the person managing the list at > armedbear-devel-owner(a)common-lisp.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of armedbear-devel digest..." > > > Today's Topics: > > 1. Re: help with verify error (Mark Evenson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 19 May 2020 22:19:00 +0200 > From: Mark Evenson <evenson(a)panix.com> > To: abcl-dev <armedbear-devel(a)common-lisp.net> > Cc: Stephen Varey <srvarey(a)gmail.com> > Subject: Re: help with verify error > Message-ID: <C407C514-EE3B-4651-A4A0-1105B2651A7C(a)panix.com> > Content-Type: text/plain; charset=utf-8 > > > > > On May 18, 2020, at 18:42, Stephen Varey <srvarey(a)gmail.com> wrote: > > > > I am trying to load powerloom into abcl. > > > > If you download powerloom ( > https://www.isi.edu/isd/LOOM/PowerLoom/download.html#PowerLoom) > > > > start abcl and then (load "~/powerloom-4.0.10/load-powerloom.lisp") ;;; > assuming downloaded into home directory > > > > It fails with the following stacktrace. > > > > Can you help? > > This code expresses a bug in the compiler. Due to the ISI codebase doing > what > would be considered nowawdays real hacks around compilation, it will take > a bit > of effort to isolate the exact problem in the compiler, but it gives a > practical problem to improve the disassembly tools. > > The ISI codebase hasn’t been updated since 2010. It works under CCL, but > not > SBCL so ABCL isn’t the only implementation with problems here. > > I’ve filed [an issue][186][467]. > > [186]: https://github.com/armedbear/abcl/issues/186 > [467]: https://abcl.org/trac/ticket/467 > > Thanks for trying out the Bear; we’ll see what we can do to get your code > running, as it is a great example of a substantial application. > > > > > STELLA 3.5.35 loaded. > > Type `(in-package "STELLA")' to execute STELLA commands.Making required > system logic > > java.lang.VerifyError: (class: org/armedbear/lisp/pl_kernel_kb_2, > method: <clinit> signature: ()V) Bad type in putfield/putstatic > > at java.lang.Class.getDeclaredConstructors0(Native Method) > > at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) > > at java.lang.Class.getConstructor0(Class.java:3075) > > at java.lang.Class.newInstance(Class.java:412) > > at > org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) > […] > > at java.lang.Thread.run(Thread.java:745) > > Error loading > /home/srv/powerloom-4.0.10/native/lisp/bin/lisp/logic/pl-kernel-kb.sabcl at > line 44 (offset 3242) > > #<THREAD "interpreter" {5B983350}>: Debugger invoked on condition of > type ERROR > > Compiled function can't be loaded: org.armedbear.lisp.pl_kernel_kb_2 > from org.armedbear.lisp.Pathname@54789d54 > > Restarts: > > 0: TOP-LEVEL Return to top level. > > [1] STELLA(2): > > -- > "A screaming comes across the sky. It has happened before but there is > nothing > to compare to it now." > > > > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > armedbear-devel mailing list > armedbear-devel(a)common-lisp.net > https://mailman.common-lisp.net/listinfo/armedbear-devel > > > ------------------------------ > > End of armedbear-devel Digest, Vol 64, Issue 4 > ********************************************** >

1 0

help with verify error
by Stephen Varey 19 May '20

19 May '20

I am trying to load powerloom into abcl. If you download powerloom ( https://www.isi.edu/isd/LOOM/PowerLoom/download.html#PowerLoom) start abcl and then (load "~/powerloom-4.0.10/load-powerloom.lisp") ;;; assuming downloaded into home directory It fails with the following stacktrace. Can you help? CL-USER(1): ; Caught STYLE-WARNING: ; redefining STELLA::GET-SGT in #P"/home/srv/powerloom-4.0.10/native/lisp/stella/symbols.slisp" (previously defined in #P"/home/srv/powerloom-4.0.10/native/lisp/stella/cl-lib/cl-setup.slisp") ; Caught STYLE-WARNING: ; redefining STELLA::/STELLA/DEFMODULE in #P"/home/srv/powerloom-4.0.10/native/lisp/stella/cl-lib/stella-to-cl.slisp" (previously defined in #P"/home/srv/powerloom-4.0.10/native/lisp/stella/modules.slisp") ; Caught STYLE-WARNING: ; redefining STELLA::/STELLA/DEFDEMON in #P"/home/srv/powerloom-4.0.10/native/lisp/stella/cl-lib/stella-to-cl.slisp" (previously defined in #P"/home/srv/powerloom-4.0.10/native/lisp/stella/demons.slisp") ; Compilation unit finished ; Caught 3 STYLE-WARNING conditions *** This Stella image uses CL-structs instead of CLOS instances *** STELLA 3.5.35 loaded. Type `(in-package "STELLA")' to execute STELLA commands.Making required system logic java.lang.VerifyError: (class: org/armedbear/lisp/pl_kernel_kb_2, method: <clinit> signature: ()V) Bad type in putfield/putstatic at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) at java.lang.Class.getConstructor0(Class.java:3075) at java.lang.Class.newInstance(Class.java:412) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.load(Load.java:224) at org.armedbear.lisp.Load.load(Load.java:745) at org.armedbear.lisp.Load$_load.execute(Load.java:693) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.cl_translate_file_22.execute(cl-translate-file.slisp:357) at org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7511) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.cl_translate_file_21.execute(cl-translate-file.slisp:357) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.systems_67.execute(systems.slisp:1266) at org.armedbear.lisp.Symbol.execute(Symbol.java:826) at org.armedbear.lisp.systems_63.execute(systems.slisp:1192) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.systems_51.execute(systems.slisp:922) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.systems_40.execute(systems.slisp:692) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.systems_41.execute(systems.slisp:755) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.systems_42.execute(systems.slisp:782) at org.armedbear.lisp.walk_401.execute(walk.slisp:6703) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.walk_395.execute(walk.slisp:6641) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.systems_33.execute(systems.slisp:561) at org.armedbear.lisp.Symbol.execute(Symbol.java:814) at org.armedbear.lisp.systems_34.execute(systems.slisp:611) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.systems_45.execute(systems.slisp:813) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.systems_51.execute(systems.slisp:922) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.eval(Lisp.java:533) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_unless.execute(Primitives.java:867) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.load(Load.java:224) at org.armedbear.lisp.Load.load(Load.java:745) at org.armedbear.lisp.Load$_load.execute(Load.java:693) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.eval(Lisp.java:538) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3743) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:285) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.top_level_47.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.top_level_48.execute(top-level.lisp:415) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Interpreter.run(Interpreter.java:361) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:745) Error loading /home/srv/powerloom-4.0.10/native/lisp/bin/lisp/logic/pl-kernel-kb.sabcl at line 44 (offset 3242) #<THREAD "interpreter" {5B983350}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.pl_kernel_kb_2 from org.armedbear.lisp.Pathname@54789d54 Restarts: 0: TOP-LEVEL Return to top level. [1] STELLA(2):

2 1

Re: Bug with lambda expressions (ABCL 1.6.1)
by Mark Evenson 07 May '20

07 May '20

> On May 7, 2020, at 23:14, Alan Ruttenberg <alanruttenberg(a)gmail.com> wrote: > > Nice catches! > Tests for both compiler bugs added via PROVE as <https://github.com/armedbear/abcl/pull/175>. […] -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

Bug with lambda expressions (ABCL 1.6.1)
by Paul Dietz 07 May '20

07 May '20

(compile nil '(lambda () ((lambda () ((lambda () 0)))))) => The value (LAMBDA NIL 0) is not of type SYMBOL. [Condition of type TYPE-ERROR] Restarts: 0: [TOP-LEVEL] Return to top level. Backtrace: 0: (#<FUNCTION {6495CFA3}> #<TYPE-ERROR {FAD3C52}> #<FUNCTION {6495CFA3}>) 1: (APPLY #<FUNCTION {6495CFA3}> (#<TYPE-ERROR {FAD3C52}> #<FUNCTION {6495CFA3}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<TYPE-ERROR {FAD3C52}> #<FUNCTION {6495CFA3}>) 3: (INVOKE-DEBUGGER #<TYPE-ERROR {FAD3C52}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Lisp.type_error(Lisp.java:435) 6: org.armedbear.lisp.Lisp.checkSymbol(Lisp.java:1097) 7: org.armedbear.lisp.Lisp.get(Lisp.java:1973) 8: org.armedbear.lisp.precompiler_53.execute(precompiler.lisp:402) 9: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 10: org.armedbear.lisp.LispThread.execute(LispThread.java:832) 11: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 12: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 13: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 14: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 15: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 16: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 17: org.armedbear.lisp.precompiler_73.execute(precompiler.lisp:643) 18: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 19: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 20: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 21: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 22: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 23: org.armedbear.lisp.precompiler_104.execute(precompiler.lisp:988) 24: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) 25: org.armedbear.lisp.Symbol.execute(Symbol.java:826) 26: org.armedbear.lisp.compiler_pass2_362.execute(compiler-pass2.lisp:7436) 27: org.armedbear.lisp.Symbol.execute(Symbol.java:867) 28: org.armedbear.lisp.compiler_pass2_387.execute(compiler-pass2.lisp:7556) 29: org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7511) 30: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 31: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 32: org.armedbear.lisp.compiler_pass2_386.execute(compiler-pass2.lisp:7556) 33: org.armedbear.lisp.Symbol.execute(Symbol.java:838) 34: org.armedbear.lisp.compiler_pass2_388.execute(compiler-pass2.lisp:7580) 35: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) 36: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 37: org.armedbear.lisp.compiler_pass2_392.execute(compiler-pass2.lisp:7650) 38: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:109) 39: org.armedbear.lisp.LispThread.execute(LispThread.java:832) 40: org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) 41: org.armedbear.lisp.Lisp.eval(Lisp.java:540) 42: org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) 43: (PRECOMPILER::PRECOMPILE-FUNCTION-POSITION-LAMBDA (LAMBDA NIL ((LAMBDA NIL 0))) NIL) 44: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL ((LAMBDA NIL (#)))) 45: (PRECOMPILER::PRECOMPILE1 ((LAMBDA NIL (#)))) 46: (PRECOMPILER::PRECOMPILE-LAMBDA (LAMBDA NIL ((LAMBDA NIL #)))) 47: (PRECOMPILER::PRECOMPILE1 (LAMBDA NIL ((LAMBDA NIL #)))) 48: (COMPILE NIL (LAMBDA NIL ((LAMBDA NIL #)))) 49: (SYSTEM::%EVAL (COMPILE NIL '(LAMBDA NIL (#)))) 50: (EVAL (COMPILE NIL '(LAMBDA NIL (#)))) 51: (SYSTEM:INTERACTIVE-EVAL (COMPILE NIL '(LAMBDA NIL (#)))) 52: (TOP-LEVEL::REPL) 53: (TOP-LEVEL::TOP-LEVEL-LOOP) ________________________________ The information contained in this e-mail and any attachments from GrammaTech, Inc may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.

2 1

Manually allowed your non-subscription address to post to armedbear-devel
by Mark Evenson 07 May '20

07 May '20

Paul, I’ve taken the liberty of manually allowing your recent messages to the <armedbear-devel@…> mailing list to propagate in spite of this address bot being subscribed to the list. [1]: https://mailman.common-lisp.net/pipermail/armedbear-devel/2020-May/004054.h… [2]: https://mailman.common-lisp.net/pipermail/armedbear-devel/2020-May/004055.h… If you wish your messages to go through without needing administrative approval, please consider subscribing to the list Happy to have your questions about ABCL: without the ANSI-TEST suite, we would be a much poorer Bear. sincerely, Mark -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

Bug with CATCH w. constant form
by Paul Dietz 07 May '20

07 May '20

(compile nil '(lambda () (dotimes (i 1 2) (catch 'c 3)))) ==> COMPILE-TAGBODY: tag not found: 3 [Condition of type SIMPLE-ERROR] Restarts: 0: [TOP-LEVEL] Return to top level. Backtrace: 0: (#<FUNCTION {6495CFA3}> #<SIMPLE-ERROR {74889B81}> #<FUNCTION {6495CFA3}>) 1: (APPLY #<FUNCTION {6495CFA3}> (#<SIMPLE-ERROR {74889B81}> #<FUNCTION {6495CFA3}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<SIMPLE-ERROR {74889B81}> #<FUNCTION {6495CFA3}>) 3: (INVOKE-DEBUGGER #<SIMPLE-ERROR {74889B81}>) 4: (COMPILE NIL (LAMBDA NIL (DOTIMES (I 1 2) (CATCH 'C 3)))) 5: (SYSTEM::%EVAL (COMPILE NIL '(LAMBDA NIL (DOTIMES # #)))) 6: (EVAL (COMPILE NIL '(LAMBDA NIL (DOTIMES # #)))) 7: (SYSTEM:INTERACTIVE-EVAL (COMPILE NIL '(LAMBDA NIL (DOTIMES # #)))) 8: (TOP-LEVEL::REPL) 9: (TOP-LEVEL::TOP-LEVEL-LOOP) ________________________________ The information contained in this e-mail and any attachments from GrammaTech, Inc may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.

1 0

Problems compiling abcl-1.6.1
by Mark Evenson 28 Apr '20

28 Apr '20

[For some reason Greg’s message wasn’t delivered via email, so I am replying “out of band” without the proper SMTP headers.] > I am an ABCL user, but by no means an expert. I just unpacked the source > zip file and tried to compile it without success. I am using Java 14.0.1 > and Ant 1.9.6. The resulting output is attached. buildfile: C:\Users\baryza\__Library\Armed_Bear_Lisp\abcl-src-1.6.1\build.xml […] abcl.compile.java: [javac] Compiling 271 source files to C:\Users\baryza\__Library\Armed_Bear_Lisp\abcl-src-1.6.1\build\classes [javac] warning: [options] bootstrap class path not set in conjunction with -source 6 [javac] error: Source option 6 is no longer supported. Use 7 or later. [javac] error: Target option 6 is no longer supported. Use 7 or later. For Java 14, we need to tell the compiler to target the right source compatibility. There is a script in `ci/create-abcl-properties.bash` that works with Bash to do configuration, but I see from your logs that you are running under Windows. So do the steps manually: 1. copy `abcl.properties.in` to `abcl.properties` 2. Change the line with `abcl.javac.source` to read abcl.javac.source=1.8 Then you should be able to compile (or at least get past this error). Not sure what is going on with the mailing list… -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 1

Release 1.6.1
by Gregory Baryza 28 Apr '20

28 Apr '20

Hello: I am an ABCL user, but by no means an expert. I just unpacked the source zip file and tried to compile it without success. I am using Java 14.0.1 and Ant 1.9.6. The resulting output is attached. Advice is appreciated. Greg Baryza

1 0

ABCL-1.6.1 Springs Forth
by Mark Evenson 28 Apr '20

28 Apr '20

As augured, the Bear is pleased to join fellow open ANSI Common Lisp implementations [CCL][], [ECL][], and [SBCL][] in publishing a new release around the online advent of the thirteenth European Lisp Symposium, [ELS2020][]. The [ABCL 1.6.1 binaries and signatures][1.6.1] are now available with their associated [CHANGES][]. Thanks to everyone involved in continuing to further the progress of our implementation. [CCL]: https://github.com/Clozure/ccl/releases/tag/v1.12 [ECL]: https://common-lisp.net/project/ecl/posts/ECL-20424-release.html [SBCL]: http://sbcl.org/news.html#2.0.4 [ELS2020]: https://european-lisp-symposium.org/2020/index.html [1.6.1] https://abcl.org/releases/1.6.1/ [CHANGES]: https://abcl.org/svn/tags/1.6.1/CHANGES -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

abcl-1.6.1 release candidate for ELS2020 rc0
by Mark Evenson 24 Apr '20

24 Apr '20

Rejoice! for the Bear has emerged from its Lair to slough off a release candidate for abcl-1.6.1 <urn:abcl/1.6.1#rc0> Currently, the release candidate rc-0 committed to cloud builds; we will be rendezvousing with the cryptographic signatures to do the actual public release on Monday, live "at" ELS 2020. Please get any outstanding github pull requests in before April 27, 2020 to be included in the release. We should now be able to accept pull requests while preserving your github identity if you are so inclined. Otherwise pseudo-anonymous patches are still solicited via this mailing list. [ABCL-BUILD]: https://github.com/easye/abcl/blob/abcl/1.6.1/ci/release.lisp [abcl.1.6.1]: https://github.com/armedbear/abcl/pull/172 [els2020]: https://european-lisp-symposium.org/2020/index.html [CHANGES]: https://github.com/easye/abcl/blob/abcl/1.6.1/CHANGES [elsconf]: https://twitter.com/elsconf stay tuned bear fans, -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

[CfPart] 13th European Lisp Symposium, happening online, free of charge!
by Didier Verna 14 Apr '20

14 Apr '20

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13th European Lisp Symposium Special Focus on Compilers In cooperation with: ACM SIGPLAN Call for participation April 27 - April 28, 2020 Sponsored by EPITA, Igalia S.L., and RavenPack ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #COVID19 important information ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the context of the current pandemic, the symposium has been turned into an online event, and will be open to anyone, free of charge! Connection instructions will be posted on the website when available. Invited Speakers ~~~~~~~~~~~~~~~~ Andrew W. Keep (Cisco Systems, Inc.), on the Nanopass Framework. Daniel Kochmański (Turtleware), on ECL, the Embeddable Common Lisp. Scope ~~~~~ 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 dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, ECMAScript, SKILL and so on. We encourage everyone interested in Lisp to participate. This year's focus is directed towards "Compilers". Programme Chair ~~~~~~~~~~~~~~~ Ioanna M. Dimitriou H. - Igalia, Spain/Germany Local Chair ~~~~~~~~~~~ Nicolas Hafner - Shinmera, Switzerland Programme Committee ~~~~~~~~~~~~~~~~~~~ Andy Wingo - Igalia, Spain/France Asumu Takikawa - Igalia, Spain/USA Charlotte Herzeel - Imec, ExaScience Lab, Belgium Christophe Rhodes - Google, UK Irène Durand - Université Bordeaux 1, France Jim Newton - EPITA Research Lab, France Kent Pitman - HyperMeta, USA Leonie Dreschler-Fischer - University of Hamburg, Germany Marco Heisig - FAU Erlangen-Nürnberg, Germany Mark Evenson - not.org, Austria Max Rottenkolber - Interstellar Ventures, Germany Metin Evrim Ulu - Middle East Technical University, Turkey Paulo Matos - Igalia, Spain/Germany Robert Goldman - SIFT, USA Robert Strandh - Université Bordeaux 1, France Sky Hester - consultant, USA -- Resistance is futile. You will be jazzimilated. Jazz site: http://www.didierverna.com Other sites: http://www.didierverna.info

1 0

Could not transfer artifact net.java.dev.jna:jna:pom:5.5.0 from/to central (http://repo1.maven.org/maven2/): Transfer failed for http://repo1.maven.org/maven2/net/java/dev/jna/jna/5.5.0/jna-5.5.0.pom 501 HTTPS Required
by Anton Vodonosov 14 Mar '20

14 Mar '20

The following error started to happen recently (in my case in Travis CI runs of a library, which includes ABCL as one of the lisps): jnaASDF could not load because Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:5.5.0'.. Could not transfer artifact net.java.dev.jna:jna:pom:5.5.0 from/to central (http://repo1.maven.org/maven2/): Transfer failed for http://repo1.maven.org/maven2/net/java/dev/jna/jna/5.5.0/jna-5.5.0.pom 501 HTTPS Required It must be caused by the following change in the maven central repo: https://support.sonatype.com/hc/en-us/articles/360041287334-Central-501-HTT… What is the best way to solve this? In other words, how to make sure ABCL uses the HTTPS versions of the central repo URLs? Best regards, - Anton

2 2

Regression from 1.5.0 in compiling SBCL on Haiku
by Alexandru Popa 02 Mar '20

02 Mar '20

Currently, ABCL is the only way to run Common Lisp on Haiku (https://www.haiku-os.org/). I try to bootstrap SBCL on Haiku usinbg ABCL. Previously, bootstrap (first stage of compilation) was possible with ABCL 1.5.0. Now with ABCL 1.6.0 the compilation fails with the attached Java error. This is a regression fomr 1.5.0.

2 3

ASDF 3.3.4 released today
by Robert Goldman 14 Feb '20

14 Feb '20

Dear Lisp Maintainers, Here is the announcement of today's bug fix release, version 3.3.4, of ASDF. This will not change the API, and fixes some issues, so it should be low-risk inclusion into your distributions. Best regards, Robert ---- In honor of Valentine's Day, and more honestly, just because it's overdue, today we release ASDF 3.3.4, the fourth bugfix release for the 3.3 release series. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 or 3.3.1 -- to upgrade to 3.3.4 at their earliest convenience. This is especially true for SBCL, for which 3.3.4 fixes a bug preventing ASDF upgrade from working smoothly. Immense thanks, as always, to Faré Rideau. Also thanks to the many bug reporters and patch submitters including (alphabetically): * Rommel Martinez * Jan Moringen * Karsten Poeck * François-René Rideau * Martin Simmons * Eric Timmons * Guillaume Le Vaillant

1 0

coerce a number to a short
by Brad Knotwell 12 Feb '20

12 Feb '20

I've been using ABCL to get access to a Java library and it's worked generally well. I have run into one problem I haven't been able to workaround. I need to make a call to a method that takes a short as an argument. I'm passing in a value--10--that fits in a short but ABCL can't find the method (presumedly due to a type issue). I've tried using jcoerce but it's not doing what I expect. What's the right way to do this? Thx. --Brad

3 10

Maven artifacts no longer available via non-TLS which breaks ABCL-ASDF
by Mark Evenson 06 Feb '20

06 Feb '20

Sometime in the last month, the Maven central repository has stopped serving non-TLS content. This change badly borks ABCL-ASDF’s use of Maven which has utilized the non-TLS version of the Maven central repository since its inception, which means that previous versions of ABCL will mysteriously stop working without one having changed any code. The error reported by ABCL is obscure, as the actual error reported by the Maven Aether class is not present anywhere in the thrown exception but rather only written to the file-system under the <file:~/.m2/> hierarchy. Initially, the error reported by ABCL resembled ones in the past which involved incompatible releases of the Maven Aether interfaces which caused me a fair amount of confusion in diagnosing this problem. Solutions: 1) One may build ABCL from source with the [required patch][1][2] 2) The bug only affects downloading artifacts, not using the local cache present under <file:~/.m2/>, so as long as one doesn’t “go to the network”, one can use locally present artifacts without problems. One could use the `mvn` command-line interface to download artifacts for ABCL to use. 3) One may patch an instance of ABCL without recompilation via the following code at the REPL or placed in <file:~/.abclrc> (require :abcl-contrib) (asdf:load-system :abcl-asdf) (setf abcl-asdf::*default-repository* "https://repo1.maven.org/maven2/“) [1]: https://github.com/armedbear/abcl/commit/42abe93f4170ee30c92ba2507780cfba06… [2]: https://abcl.org/trac/changeset/15229 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

[CfP] Reminder: 13rd European Lisp Symposium, April 27-28, Zürich
by Didier Verna 22 Jan '20

22 Jan '20

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13th European Lisp Symposium Special Focus on Compilers In cooperation with: ACM SIGPLAN Call for papers April 27 - April 28, 2020 GZ Riesbach Zürich, Switzerland http://www.european-lisp-symposium.org/2020 Sponsored by EPITA, Igalia S.L. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Invited Speakers ~~~~~~~~~~~~~~~~ Andrew W. Keep (Cisco Systems, Inc.), on the Nanopass Framework. Daniel Kochmański (Turtleware), on ECL, the Embeddable Common Lisp. Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: February 13, 2020 - Author notification: March 16, 2020 - Final papers due: April 6, 2020 - Symposium: April 27 - 28, 2020 Scope ~~~~~ 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 dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, ECMAScript, SKILL and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2020 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. This year's focus will be directed towards "Compilers". We especially invite submissions in the following areas: - Compiler techniques - Compiler passes - Compiler compilers - Showcasing of industrial or experimental compilers - Code generation - Compiler verification - Compiler optimizations - JIT compilers Contributions are also welcome in other areas, including but 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 Technical Program ~~~~~~~~~~~~~~~~~ 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 4 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. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following http://www.easychair.org/conferences/?conf=els2020 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Ioanna M. Dimitriou H. - Igalia, Spain/Germany Local Chair ~~~~~~~~~~~ Nicolas Hafner - Shinmera, Switzerland Programme Committee ~~~~~~~~~~~~~~~~~~~ Andy Wingo - Igalia, Spain/France Asumu Takikawa - Igalia, Spain/USA Charlotte Herzeel - Imec, ExaScience Lab, Belgium Christophe Rhodes - Google, UK Irène Durand - Université Bordeaux 1, France Jim Newton - EPITA Research Lab, France Kent Pitman - HyperMeta, USA Leonie Dreschler-Fischer - University of Hamburg, Germany Marco Heisig - FAU Erlangen-Nürnberg, Germany Mark Evenson - not.org, Austria Max Rottenkolber - Interstellar Ventures, Germany Paulo Matos - Igalia, Spain/Germany Robert Goldman - SIFT, USA Robert Strandh - Université Bordeaux 1, France Sky Hester - consultant, USA -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

java.lang.VerifyError with PROGN
by Eric Marsden 19 Dec '19

19 Dec '19

Hi, Compiling the loading the code below (a simplified extract of SBCL's codebase, found attempting to crossbuild SBCL with ABCL) results in a VerifyError, possibly related to the implementation of PROGN. Using 1.6.1-dev-svn-15217. java.lang.VerifyError: (class: org/armedbear/lisp/foo_1, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find object/array on stack at java.base/java.lang.Class.getDeclaredConstructors0(Native Method) at java.base/java.lang.Class.privateGetDeclaredConstructors(Class.java:3137) at java.base/java.lang.Class.getConstructor0(Class.java:3342) at java.base/java.lang.Class.newInstance(Class.java:556) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.SpecialOperators$sf_progn.execute(SpecialOperators.java:273) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) --- (in-package :cl-user) (progn (defvar*sxhash-crosscheck* nil) (defun sxhash (x) (let ((answer (if (string= x "NIL") (ash 1343225879 (- 1))))) (push (cons x answer)*sxhash-crosscheck*) answer))) -- Eric Marsden https://risk-engineering.org/

5 10

[CfP] ELS 2020, 13th European Lisp Symposium, April 27-28, Zurich
by Didier Verna 06 Dec '19

06 Dec '19

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 13th European Lisp Symposium Special Focus on Compilers Call for papers April 27 - April 28, 2020 GZ Riesbach Zürich, Switzerland http://www.european-lisp-symposium.org/2020 Sponsored by EPITA, Igalia S.L. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Invited Speakers ~~~~~~~~~~~~~~~~ Andrew W. Keep (Cisco Systems, Inc.), on the Nanopass Framework. Daniel Kochmański (Turtleware), on ECL, the Embeddable Common Lisp. Important Dates ~~~~~~~~~~~~~~~ - Submission deadline: February 13, 2020 - Author notification: March 16, 2020 - Final papers due: April 6, 2020 - Symposium: April 27 - 28, 2020 Scope ~~~~~ 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 dialects, including Common Lisp, Scheme, Emacs Lisp, Clojure, Racket, ACL2, AutoLisp, ISLISP, Dylan, ECMAScript, SKILL and so on. We encourage everyone interested in Lisp to participate. The European Lisp Symposium 2020 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. This year's focus will be directed towards "Compilers". We especially invite submissions in the following areas: - Compiler techniques - Compiler passes - Compiler compilers - Showcasing of industrial or experimental compilers - Code generation - Compiler verification - Compiler optimizations - JIT compilers Contributions are also welcome in other areas, including but 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 Technical Program ~~~~~~~~~~~~~~~~~ We invite submissions in the following forms: * Papers: Technical papers of up to 15 pages that describe original results or explain known ideas in new and elegant ways. * Demonstrations: Abstracts of up to 4 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. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following http://www.easychair.org/conferences/?conf=els2020 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Programme Chair ~~~~~~~~~~~~~~~ Ioanna M. Dimitriou H. - Igalia, Spain/Germany Local Chair ~~~~~~~~~~~ Nicolas Hafner - Shinmera, Switzerland Programme Committee ~~~~~~~~~~~~~~~~~~~ Andy Wingo - Igalia, Spain/France Asumu Takikawa - Igalia, Spain/USA Charlotte Herzeel - IMEC, Intel Exascience Lab, Belgium Christophe Rhodes - Google, UK Iréne Durand - Université Bordeaux 1, France Jim Newton - EPITA Research Lab, France Kent Pitman - HyperMeta, USA Leonie Dreschler-Fischer - University of Hamburg, Germany Marco Heisig - FAU Erlangen-Nürnberg, Germany Mark Evenson - not.org, Austria Max Rottenkolber - Interstellar Ventures, Germany Paulo Matos - Igalia, Spain/Germany Robert Goldman - SIFT, USA Robert Strandh - Université Bordeaux 1, France (more PC members to be announced) -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

On preparations to turn the Bear past 11
by Mark Evenson 02 Dec '19

02 Dec '19

Dear long-suffering fans of the Bear, Rejoice! for preparations for the release of abcl-1.6.0 to support openjdk{6,7,8,11} and beyond near completion. We have managed to get a [Continuous Integration (CI)][travis-builds] build mostly working via Travis CI integration with the Github repository. Anyone who forks us on Github with suitable monkeying around can get automated build and test results for their commits to their fork. The [current version of the tests][.travis.yml] attempt to run in environments that are the cross product of macOS/Linux with openjdk8/openjdk11. This isn't quite completely working yet as I haven't apparently figured out how to use jenv in Travis to specify the correct openjdk to invoke, but I'm close. For now, we at least getting test coverage for openjdk11 under Linux, and I hope to iron out the remaining kinks real soon now. It should be theoretically possible to [add Windows builds][windows-builds] as well, but I am planning on to tackling that in the near future. The CI tests have given me the confidence to next attempt to release abcl-1.6.0 via existing release engineering process in spite of the following problems: 1. While they seemingly pass in the CI, the CFFI linkages to CL+SSL libraries often fail in a spectacularly segmentation fault in practical use. With judicious refinement, I think we can figure out what is going but for now we should just accept this. 2. [A major regression from abcl-1.5.0][pathname-problems] concerning the use of CL:PATHNAME to refer to objects within a jar/zip archive has been discovered, but curiously it is seemingly not fatal to anything other than the execution of ABCL test suite. In analyzing the problems, I realized that we can considerably clean up our abstraction for a CL:PATHNAME which denotes an entry in an archive by allowing nested archives using the CL:PATHNAME-DEVICE component. To do this in a reasonably clean manner means a fair amount of modification on the Java side of our implementation by reflecting the various types of a CL:PATHNAME in that Java hierarchy as Erik Hülsmann suggested many years ago. While I have some promising preliminary patches towards this, due to the amount of outstanding effort, I feel we should get abcl-1.6.0 out first. Please holler loudly real soon if anyone has problems with releasing as things currently stand. I intend follow up with abcl-1.6.1 within a month to hopefully address the two major blockers in addition to any errata. [travis-builds]: https://travis-ci.org/armedbear/abcl/builds [.travis.yml]: https://github.com/armedbear/abcl/blob/master/.travis.yml [windows-builds]: https://twitter.com/ArmedBear/status/1197538417678192645 [cl+ssl-problems]: https://abcl.org/trac/ticket/464 [pathname-problems]: https://github.com/armedbear/abcl/commit/e962be5e0dd86335cc66415a0a417f9e4b… yers, Mark <evenson(a)panix.com> -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

3 2

ABCL 1.6.0 unleashed
by Mark Evenson 23 Nov '19

23 Nov '19

Against the falling canvas of 2019, the Bear has freely thrust [ABCL 1.6.0][abcl.org/releases] onto the [world stage][github]. This release fully supports building and running on Java 6, 7, 8, and 11 via the [openjdk runtimes][adoptjdk]. By [building from our source][source-build], it is [rumored that the User may utilize additional hosting platforms such as Java 13][sfp-mail]. Support for Microsoft Windows platforms has not been thoroughly tested at this point but we intend to add it our automatic cloud based build in the process of releasing a [stablizing ABCL 1.6.1][1.6.1] build due by the end of this year. Thanks to all past, present, and future contributors to the Bear; here's to [hackin' our way out of the prison of the Java language][jss] for over a decade. [github]: https://github.com/armedbear/abcl [abcl.org/releases]: https://abcl.org/releases/1.6.0 [1.6.1]: https://abcl.org/trac/milestone/1.6.1 [source-build]: https://gitlab.common-lisp.net/abcl/abcl/tree/master/contrib/abcl-build [adoptjdk]: https://adoptopenjdk.net/ [sfp-mail]: https://mailman.common-lisp.net/pipermail/armedbear-devel/2019-November/004… -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 2

Patch for a couple of stack inconsistency bugs
by somewhat-functional-programmer 19 Nov '19

19 Nov '19

Hello list, Lately I have been starting to dive deeper into Common Lisp and have started to use ABCL more than SBCL or CCL lately. It is a very impressive project. I want to post a patch for review/comments and hopefully have it be worthwhile to eventually include it in ABCL. The patch attempts to fix a couple of stack inconsistency bugs in the compiler. I came across the stack inconsistency issue in one of my projects and started to try to find the root cause of the problem based on a nice minimal reproduction of the bug found in https://github.com/armedbear/abcl/issues/69. However, my particular bug was slightly different. It had to do with using a return-from in the cleanup form of an unwind-protect. The following two forms also result in a stack inconsistency problem (and are a more minimal reproduction of the bug my code introduced): (defun two-arg-fn (one two) (format t "Two args: ~S and ~S~%" one two)) (let ((fn (compile nil '(lambda () (two-arg-fn (block test-block (unwind-protect 30 (return-from test-block 8))) -1))))) (funcall fn)) My patch handles both the github issue and the stack inconsistency in the form above. It also fixes jvm::print-code to print string representations of values from the constant pool which I found useful in debugging the output. Anyhow, let me attempt to quickly summarize the stack inconsistency problem in general: - Certain common lisp control flow forms (tagbody/go/unwind-protect/block/return-from/throw/catch) require the use of JVM exceptions to implement in bytecode - When the JVM throws an exception, the operand stack is cleared and the exception is pushed onto the operand stack (see jvms8, 6.5/athrow, p378) - Therefore, any form which pushes values onto the operand stack for further use is confounded when these control flow forms are child forms - To properly handle these alternate control flows we need to save the result of the control flow form to a local variable in the stack frame (distinct from the operand stack, and not destroyed by an exception (well at least not until the exception passes /out/ of the method) and then reload for use by the parent form to push on the operand stack Take the case of the ash function (from the github issue). Bytecode for ash is emitted from jvm::p2-ash. It compiles its arguments to the operand stack, and is therefore vulnerable to the problem discussed above. Other low level functions (like + for example in p2-plus) use the following forms to overcome this issue: jvm::with-operand-accumulation and jvm::compile-operand. These forms save the results of "unsafe" forms (opstack unsafe) to "registers" (local variables in the stack frame). This technique allows for these complicated control flow forms to be a child form of + with no issues, but not the ash function (which does not do this). See my patch for how I added these already present with-operand-accumulation and compile-operand forms to ash so it is no longer vulnerable to stack inconsistency bugs. Generally, function calls in ABCL are not vulnerable to these stack inconsistency bugs. Function arguments are processed in jvm::process-args, and in this function, the opstack safety of child forms is checked, and values are saved to "registers" when a form is known to be unsafe. My case (the return-from in the cleanup form of an unwind-protect) simply wasn't properly being marked as opstack unsafe. I modified jvm::p1-unwind-protect to mark all direct children of the unwind-protect as opstack unsafe, which eliminated my problem. I believe there may have been confusion here in the code (speculation of course on my part) of 'protected' form referring to the form actually protected by the unwind-protect (which is totally different than being unsafe or needing opstack /protection/) (or I'm misinterpreting this function and potentially causing additional bugs!). The only other item in my patch is fixing how bytecode is printed for debugging. Basically, most items in a class constant pool are referenced with a 2 byte index, but one (ldc) uses a one byte index). This has been accounted for in the new function jvm::constant-pool-index. Let me know what you think, and again please review, there aren't many lines changed but I am new to the internals of the project. I think I ran all tests (ant abcl.test) but while the ant task completed successfully, my output complained of a missing dependency and I'm not sure what actually ran. -Mark The attached patch was produced against b3cfee6617e0c2c380d8675f3383d81e7758f358 from https://github.com/easye/abcl (latest master branch). [jvms8] https://docs.oracle.com/javase/specs/jvms/se8/jvms8.pdf

2 3

format ~$ may need consider -0.0
by dingd 16 Nov '19

16 Nov '19

this is what sbcl does * (format nil "~$" -0.0) "-0.00"

2 1

On the Bear turning to Java 11
by Mark Evenson 16 Nov '19

16 Nov '19

As the leaves fall in the Northern hemisphere, thoughts of the Bear turn to a rumored permanent slumber, and a complete absence of the possibility of new updates. The Bear [accepts][trac] [all][gitab] patches][github], so if you don't like the current implementation, please get out and push. Or pull? Or fast forward? The Bear is seemingly always confused with Git… As previously rumored, [patches for getting the Armed Bear Common Lisp implementation running on Java 11][github-with-java11] have landed in the [trunk][trunk-with-java11]. Unless anyone objects strongly, we will release [ABCL 1.6.0][abcl-1.6.0] as soon as possible with the intention to support the openjdk{6,7,8,11} runtimes. After stabilizing the 1.6 branch with the inevitable necessary and unknown updates, we can turn our attention to the [2.0 branch][abcl-2.0.0] which will introduce support for additional runtimes but drop support for emitting openjdk6 or openjdk7 compatible byte-code. As always, everyone's desires are welcome to be expressed. yers in CONS, Mark <evenson.not.org(a)gmail.com> [trunk-with-java11]: https://abcl.org/trac/changeset/15133 [github-with-java11]: https://github.com/armedbear/abcl/commit/a628e961a1dc33e1f225191a19494701d7… [github]: https://github.com/armedbear/abcl/ [trac]: https://abcl.org/trac/ [gitlab]: https://common-lisp.net/abcl/abcl/ [svn]: svn://abcl.org/svn/ [mailing-list]: <mailto:armedbear-devel@common-lisp.net> [abcl-1.6.0]: https://abcl.org/trac/milestone/1.6.0 [abcl-2.0.0]: https://abcl.org/trac/milestone/2.0.0 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 1

Moving the Bear past Java 11
by Mark Evenson 14 Nov '19

14 Nov '19

As the leaves fall in the Northern hemisphere, thoughts of the Bear turn to a rumored permanent slumber, and a complete absence of the possibility of new updates. The Bear [accepts][trac] [all][gitab] patches][github], so if you don't like the current implementation, please get out and push. Or pull? Or fast forward? The Bear is seemingly always confused with Git… As previously rumored, [patches for getting the Armed Bear Common Lisp implementation running on Java 11][github-with-java11] have landed in the [trunk][trunk-with-java11]. Unless anyone objects strongly, we will release [ABCL 1.6.0][abcl-1.6.0] as soon as possible with the intention to support the openjdk{6,7,8,11} runtimes. After stabilizing the 1.6 branch with the inevitable necessary and unknown updates, we can turn our attention to the [2.0 branch][abcl-2.0.0] which will introduce support for additional runtimes but drop support for emitting openjdk6 or openjdk7 compatible byte-code. As always, everyone's desires are welcome to be expressed. yers in CONS, Mark <evenson.not.org(a)gmail.com> [trunk-with-java11]: https://abcl.org/trac/changeset/15133 [github-with-java11]: https://github.com/armedbear/abcl/commit/a628e961a1dc33e1f225191a19494701d7… [github]: https://github.com/armedbear/abcl/ [trac]: https://abcl.org/trac/ [gitlab]: https://gitlab.common-lisp.net/abcl/abcl/ [svn]: svn://abcl.org/svn/ [mailing-list]: <mailto:armedbear-devel@common-lisp.net> [abcl-1.6.0]: https://abcl.org/trac/milestone/1.6.0 [abcl-2.0.0]: https://abcl.org/trac/milestone/2.0.0 -- "No, this is not a disentanglement, but a progressive /knotting-into/."

1 0

Directory handling
by Marco Antoniotti 13 Jun '19

13 Jun '19

Dear all, I have been looking at the ABCL manual and packages and I was not able (my fault!) to find functions like CURRENT-DIRECTORY and/or CHANGE-DIRECTORY (or CHDIR). Could you tell me how to get to this functionality? Also, what is the set of features that ABCL uses to identify the platform? On a Mac OSX I see (at a minimum): CL-USER> (dolist (f *features*) (print f)) :SWANK :X86-64 :UNIX :DARWIN :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :CDR6 :MOP :PACKAGE-LOCAL-NICKNAMES NIL Thanks -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please check: http://cdac2019.lakecomoschool.org Please check: http://troncopackage.org Please check: https://www.frontiersin.org/research-topics/7394/network-bioscience Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first (cum grano salis).

4 10

Repositories of ABCL-specific code? / Kill runaway ABCL function and return to REPL?
by Elliott, Clark 12 Jun '19

12 Jun '19

Dear ABCL experts, I am working on AI system development in LISP. I like using ABCL because of its easy portability to Windows, Mac, and Linux and its direct access to Java. I am running ABCL in emacs shells, often as several processes at once, communicating via sockets. The LISP is working very well indeed. Great job! I've slogged through getting things like sockets and threads running--mostly using apropos and guessing--but it takes a lot of time. I STRONGLY prefer to work from examples of running code. I would dearly love some tips on the following: 1. Are there repositories of ABCL-specific running code, small programs, utility applications and etc. showing the actual running of ABCL implementation-specific functions? Native ABCL networking? ABCL tricks? Examples of running programs using the native threads? Examples of small systems using Java-to-LISP and LISP-to-Java (beyond the given short examples)? 2. How can I stop a runaway ABCL LISP function and return to top-level LISP without having to blow away the emacs buffer, and thus my entire current LISP context? In other LISPs I've had some kind of control key sequence, but can't find one for ABCL. E.g.: (defun runaway () (let ((n 0)) (loop while (< (incf n) 10) ;; Pretend this ran away. How do I kill it in ABCL REPL? do (sleep 1)))) Thanks in advance for any help. Best, Clark

3 2

Running Lisp tests
by Alessio Stalla 12 Jun '19

12 Jun '19

Greetings, I have trouble running ABCL's Lisp test suites: $ ant abcl.test ...lots of output... [java] Caught :ASDF/FIND-COMPONENT:MISSING-DEPENDENCY while processing --eval option "(asdf:test-system :abcl/test/ansi/compiled)": [java] #<MISSING-DEPENDENCY {1337E679}> [java] Java Result: 2 ...etc... Do you have any idea? Thanks Alessio

5 10

Re: ABCL functionality
by Marco Antoniotti 07 Jun '19

07 Jun '19

Thanks Elliott, but no. These are REPL conveniences. How is the “cd” command implemented? I know I should dig in the ABCL code, but I am one of the laziest lispers around :) :) :) All the best Marco > On Jun 6, 2019, at 04:28 , Elliott, Clark <elliott(a)depaul.edu> wrote: > > Hi Marco, > > I’m not sure if this is what you are looking for, but it took me a long time to find these interactive commands: > > CL-USER(6): :help > > COMMAND ABBR DESCRIPTION > apropos ap apropos > bt backtrace n stack frames (default 8) > cd change default directory > cf compile file(s) > cload cl compile and load file(s) > continue cont invoke restart n > describe de describe an object > error err print the current error message > exit ex exit lisp > frame fr set the value of cl:* to be frame n (default 0) > help he print this help > inspect in inspect an object > istep i navigate within inspection of an object > ld load a file > ls list directory > macroexpand ma macroexpand an expression > package pa change *PACKAGE* > pwd pw print current directory > reset res return to top level > rq require a module > trace tr trace function(s) > untrace untr untrace function(s) > > Commands must be prefixed by the command character, which is ':' by default. > > Best, > > Clark Elliott -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please check: http://cdac2019.lakecomoschool.org Please check: http://troncopackage.org Please check: https://www.frontiersin.org/research-topics/7394/network-bioscience Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first (cum grano salis).

2 1

ABCL starting to work under Java11
by Mark Evenson 11 Apr '19

11 Apr '19

It turns out that if we pretend that Java 9 and Java 10 never existed, we can run a lightly modified version of [ABCL on Java11][11]. Once I get something stable, that mostly works across both openjdk8 and openjdk11, I think I would like to fork an abcl-2.0.0 while maintaining support for openjdk[678] via the abcl-1.m.n series, Our CL:PATHNAME stuff needs to be adapted because Java11 stops referring to classes in `jar:file` location in favor of a synthetic reference to a `jrt:` path, but I think I may be able to easuly paper over this problem by tightening the isomorphism between a URI and the namestrings for ABCL’s implementation. [11]: https://github.com/armedbear/abcl/pull/96 Surprisingly, the compiler seems to work fine, so the implementation is certainly not intolerably slow under Java 11. JSS certainly does not work but the ABCL-CONTRIB works for implementations with access to a filesystem on which CL:DIRECTORY can work. This patch reworks ABCL-CONTRIB strategy to introspect the value of the the Java system property "java.class.path". This may not be sufficient to find the contribs under all possible ways that the implementation may be hosted. To provide some background to the issues here, ABCL-CONTRIB is deliberately packaged separately from the contents of abcl.jar in order to: • Keep the base ANSI implementation plus the included ASDF version in a single artifact with no other dependencies. • Push the decision to potentially infringe on licenses explicitly to the user. The knowledgable User may use the build-time option for the inclusion of code in system.lisp and the AIO packaging mechanism to create an unified "All-in-one" artifact. Since ASDF is always included as part of the base abcl.jar, we may rely on its presence to find additional artifacts to add as additional code to abcl, aka. "the abcl contribs". Currently, this is achieved by the following strategies, tried sequentially until one is found to be successful: • Introspecting for an implementation of "org.abcl-contrib" as declared in the system jar manifest. • Attempting to locate a jar file named abcl-contrib{MUMBLE}.jar on the filesystem by searching directories referenced on the class path. • Replacing the occurance of 'abcl' with 'abcl-contrib' in the the name of the system jar pathname, and then introspecting the contents. It would probably be helpful to add the following strategies to find members of ABCL-CONTRIB: • Locating an abcl-contrib.asd artifact via the usual ASDF conventions. • Retrieving the contents of ABCL-CONTRIB from the network via a "cool URI". • (Java 11) Appropiate use of Java modules to describe graphs of loadable ABCL artifacts. -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

4 5

Re: problems in compiler
by Mark Evenson 30 Mar '19

30 Mar '19

[Posting reply to mailing list so our conversation gets archived for posterity.] > On Mar 30, 2019, at 05:10, Don Cohen <don-abcl(a)isis.cs3-inc.com> wrote: > > Mark Evenson writes: > >> It took a little while to approach the AP5 code, but I managed to >> hack together the attached patch for ABCL which allows the AP5 >> build strategy to succeed. […] >> The attached patch contains a provisional hack to the ABCL compiler >> which computes the alist form from the vector form rather than >> signalling an error, so in order to use ABCL with AP5, you will >> have to build ABCL from source. > > Thank you! > > But is there any reason it won't suffice to simply redefine this > function in a running image before compiling? Patching the compiler in the running image will work just fine. >> To truly fix this one would have to understand the AP5 compilation >> strategy better, and then probably adjust the compiler's use of >> specials. > > I think I understand the compilation strategy - it's not that > complicated. But I don't see what that has to do with this > problem. The patch suggests that the real question is how > *fasl-uninterned-symbols* got to be a vector in the first place. > Would it help if I avoided uninterned symbols? Replace calls to > gensym with gentemp? The reason I suspect AP5’s "compilation strategy” (more like “need for recompiling and loading as it goes”) is twofold: 1) In my attempt at reproduction of the problem, I encountered no problems with a toy fasl containing references to uninterned symbols with any combination of CL:LOAD and CL:COMPILE-FILE. Absence of evidence is not evidence of absence and all that, but the ABCL compiler works with many systems in Quicklisp defined using ASDF without problems. 2) From the stack trace, it seems clear that the error stems from the compiler being invoked (see ’59:’ ff.) in the process of the loading the fasl itself (’70:’ ff.): […] 57: (JVM::SERIALIZE-OBJECT (#:A77910 #:A77911)) 58: (JVM::EMIT-CONSTRUCTOR-LAMBDA-LIST (#:A77910 #:A77911)) 59: (COMPILE AP5::|Test-RELADDER| (LAMBDA (#:A77910 #:A77911) (AP5:WITHREADACCESS (LET ((#:G77912 #:A77910) (#:G77913 #:A77911)) (LET ((AP5::CXVALUE (AP5::VALUEINCURRENTCX (AP5:THEAP5RELATION AP5:RELADDER) #:G77912 #:G77913))) (COND ((NOT (EQ AP5::CXVALUE 'AP5::INHERIT)) AP5::CXVALUE) (T (NOT (NOT ((LAMBDA (AP5::REL &REST AP5::TUPLE) (AP5::FMEMB3 AP5::TUPLE (AP5::GETBASEDATA AP5::REL) )))))))))))) […] 64: (AP5::NEED-TESTER ) 65: (AP5::GET-UPDATE-SOURCE T ) 66: (AP5::GET-UPDATE T ) 67: (#<COMPILED-FUNCTION #<FUNCTION (LAMBDA ()) {6992BE4}> {6992BE4}>) 68: (FUNCALL #<COMPILED-FUNCTION #<FUNCTION (LAMBDA ()) {6992BE4}> {6992BE4}>) 69: (SYSTEM:INIT-FASL :VERSION 43) 70: (SYSTEM::%LOAD #P"/Users/evenson/work/ap5/bin-abcl1.5.0-MT/relation.fas" T NIL T :DEFAULT) 71: (LOAD #P"/Users/evenson/work/ap5/bin-abcl1.5.0-MT/relation.fas”) ABCL fasls are zip files that contain two things: a loader consisting of CL source forms, and JVM classes emitted by the compiler. In loading, the loader forms are interpreted which make the necessary modifications to the environment as well as loading the compiled JVM classes. Each JVM class emitted by the compiler has a piece of initialization code (known in the JVM as static initializers) which performs additional housekeeping in the environment. In the above stack trace, the INIT-FASL call at ’69:’ is evaluating the forms in the loader. The loading of the JVM class which is causing the stack trace which seemingly corresponds to the error is on line 392 of “relation.lsp”, namely the line which adds a tester: (++ RelTester 'StructProp ‘StructPropTester) But I can’t “seemingly" figure out how this line expands into the call to AP5::GETUPDATE, so maybe my reasoning is somehow faulty here, but I at least wanted to record how far I have gotten. The only strategy I can currently suggest for AP5 which might be friendlier to ABCL is to not invoke CL:COMPILE at fasl load time if this is indeed what is occuring. Maybe I can craft a simple example to test that theory. Off to pack and travel to the European Lisp Symposium, Mark -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 1

problems in compiler
by don-abcl＠isis.cs3-inc.com 29 Mar '19

29 Mar '19

--text follows this line-- The version of ap5 from 2009 supposedly was able to build in the abcl of that time. I'm now trying to make a more recent ap5 (but not very much changed) build in current abcl. I've put the current source at http://ap5.com/ under ap5-2019.zip so that others who are willing to help can reproduce the problem. Unfortunately I don't have a small example, only a large one. If you retrieve and unzip the source, you'll find a file abcl-build.lsp which I'm trying to get to build ap5. In order to use it you have to change this line: (defvar *top* "/tmp1/ap5-2017/") to be the directory where you've put the ap5 source subdirectory. That is, the file /whatever/source/abcl-build.lsp should contain (defvar *top* "/whatever/") I then do the following: java -jar abcl-bin-1.5.0/abcl.jar then load that file - in my case (load "/tmp1/ap5-2017/source/abcl-build.lisp") This ends with the following error: Error loading /home/tmp1/ap5-2017/bin-abcl1.5.0-MT/relation.fas at line 210 (offset 12978) #<THREAD "interpreter" {5E5D5718}>: Debugger invoked on condition of type TYPE-ERROR The value #(#:A63056 #:G63088 #:A63337 #:A63338 #:A63324 #:A63325 #:G63450 #:G63451 #:A63559 #:A63560 #:A63546 #:A63547 #:G63674 #:G63675 #:A63797 #:A63798 #:G63898 #:G63899 #:A64007 #:A64008 #:G64039 #:G64040 #:A64134 #:G64160 #:G64256 #:G64356 #:G64357 #:G64454 #:A64602 #:G64628 #:WHOLE-65572 #:ENVIRONMENT-65573) is not of type LIST. Restarts: 0: TOP-LEVEL Return to top level. [1] AP5(2): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<TYPE-ERROR {16575712}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:382) 3: org.armedbear.lisp.Lisp.type_error(Lisp.java:435) 4: org.armedbear.lisp.LispObject.car(LispObject.java:161) 5: org.armedbear.lisp.assql.execute(assql.java:51) 6: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 7: org.armedbear.lisp.LispThread.execute(LispThread.java:832) [1] AP5(3): It's difficult for me to figure out what's causing the error since I don't know much about interpreting java compiler output. However I hope a little background and some experimental evidence will help. First, the build process loads certain files before it compiles them and then later attempts to load the compiled versions. The error is coming from trying to load the compiled version of the first of these, relations.lsp. The build process actually loads and compiles several files before it tries to load the compiled versions, but in order to reproduce the error it's enough to load relations.lsp, compile it, then try to load the compiled version. In order to figure out which form in the file was causing the problem I tried a number of initial subsets of the relations.lsp file and found that if I stop at line 836, after : (++ reldeleter (relationp 'relation) '(lambda (&rest ignore) (declare (ignore ignore)) 'deleterel)) I can - load relations.lsp (I do this in order to return to a state that does not depend on the part of the compiled file that was loaded) - compile the initial segment - load the compiled version of the initial segment without error. However if I add the next form, (defun deleterel (ignore rel) (declare (ignore ignore)) (loop for a s.t. (relationarity rel a) do (-- relationarity rel a)) (insist "supposed to delete it" not (relation rel))) the load of the compiled file generates an error similar to above: Error loading /tmp/test1.abcl at line 198 (offset 11994) #<THREAD "interpreter" {2040734F}>: Debugger invoked on condition of type TYPE-ERROR The value #(#:G292048) is not of type LIST. On the other hand, if I put the defun deleterel into a separate file, I can - load relations.lsp - compile the initial segment ending with ++ reldeleter - load the compiled version of the initial segment - compile the file containing defun deleterel - load that file without error. The fact that the error from this test contains what appears to be a vector of only one object whereas the original contains a longer vector suggests to me that the compiler is combining multiple forms into a vector, and the defun deleterel is just the first one. Of course that doesn't explain why some other code expects a list instead of a vector. I'm hoping that someone will know immediately what causes the error I'm seeing and what I can do to avoid it. This reminded me of something -- you might notice in the file relations.lsp and other files the following incantation: (buffer-break) which is defined in sys-depe.lsp: ; The purpose of buffer-break is to prevent compile-file from ; putting two forms together when the first one has to be evaluated ; before the second can successfully read, e.g., if the first defines ; relation R and the second contains something like #,(relationp R). #+(or lispworks (and lucid sparc)) (defmacro buffer-break () '(eval-when (:load-toplevel :execute) nil)) #-(or lispworks (and lucid sparc)) (defmacro buffer-break () nil) If I change the first of those forms to #+(or abcl lispworks (and lucid sparc)) I still get the same error at the same place, but I wonder whether the underlying problem is similar to the one that caused buffer-break to be invented.

2 1

ASDF 3.3.3 is Released
by Robert Goldman 27 Mar '19

27 Mar '19

In honor of the impending 2019 European Lisp Symposium, today we release ASDF 3.3.3, the third bugfix release for the 3.3 release series. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 or 3.3.1 -- to upgrade to 3.3.3 at their earliest convenience. Immense thanks, as always, to Faré Rideau. Also thanks to the many bug reporters and patch submitters including (alphabetically): * Marius Gerbershagen * Hugo Ishimaru * Attila Lendvai * Jan Moringen * P. Neidhardt * François-René Rideau * Eric Timmons * Didier Verna * "privet-kitty" The Changelog: ``` Bug fix release: * Dependency tracking: fix bugs in handling misnamed secondary systems. We now distinguish between "syntactic" and "semantic" primariness, properly warn in case a secondary system is misnamed, yet properly recompile or avoid spurious recompilation depending on whether there or not is a conflict or redefinition. Similarly handle package-inferred-system (thanks to Eric Timmons). Better warning in a fishy case of compute-action-stamp. * UIOP: Fix loading, allow the user to specify UIOP location from which to load. * SBCL compatibility: Fix issue with deferred warnings on SBCL. * Allegro compatibility: Fix issue detecting "modern" lisp. * Genera compatibility: Fix minor issues. Not fully tested. * ECL compatibility: Bundling fixes. * Fiveam-ASDF: Added to contrib/ example system for integrating FiveAM tests with ASDF's test-op. * Miscellaneous fixes: Avoid an infinite loop parsing :perform options, quash warnings for known bad system names that won't be fixed. * Documentation: Multiple user-contributed documentation fixes. * Tests: Miscellaneous improvements. -- Francois-Rene Rideau <fare(a)tunes.org> Wed, 27 Mar 2019 17:33:42 -0400 ```

1 0

user manual code example race condition
by dingd 17 Mar '19

17 Mar '19

this is recommended in the manual, it contains a race condition. Interpreter interpreter = Interpreter.getInstance (); if ( interpreter == null ) { interpreter = Interpreter.createInstance (); } getInstance and createInstance should be swapped.

5 10

cffi doesn't load on ABCl 1.5 and 1.4 (but works on 1.3 and odler)
by Anton Vodonosov 08 Mar '19

08 Mar '19

1.5 fails with NullPointerException 1.4 with org.armedbear.lisp.Go Best regards, - Anton (ql:quickload :cffi) Java exception 'java.lang.NullPointerException'. [Condition of type JAVA-EXCEPTION] Restarts: 0: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {9B7F44}> #<JAVA-EXCEPTION {4A3C4C}> #<FUNCTION {9B7F44}>) 1: (APPLY #<FUNCTION {9B7F44}> (#<JAVA-EXCEPTION {4A3C4C}> #<FUNCTION {9B7F44}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<JAVA-EXCEPTION {4A3C4C}> #<FUNCTION {9B7F44}$ 3: (INVOKE-DEBUGGER #<JAVA-EXCEPTION {4A3C4C}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Java.jcall(Java.java:911) 6: org.armedbear.lisp.Java$pf_jcall.execute(Java.java:755) 7: org.armedbear.lisp.Primitive.execute(Primitive.java:123) 8: (JCALL "toString" NIL) 9: (SYSTEM::TO-FILE #S(SYSTEM::SYSTEM-STREAM) NIL :APPEND NIL) 10: (#<FUNCTION {12471FB}>) 11: (THREADS::THREAD-FUNCTION-WRAPPER #<FUNCTION {12471FB}>)

2 4

simple hello world fails - can't find LISP_HOME
by Stephen Varey 17 Jan '19

17 Jan '19

I have built abcl from source Then went to write my first simple hello world.... public class Tester { void simple() { Interpreter interpreter = Interpreter.createInstance(); LispObject result = interpreter.eval("(format t \"Hello, world!~%\")"); System.out.println(result); } public static void main(String[] args) { new Tester().simple(); } } The execution fails with the following. ant -f C:\\git\\abcl -Djavac.includes=org/armedbear/lisp/util/Tester.java - Dnb.internal.action.name=run.single -Drun.class=org.armedbear.lisp.util.Tester run-single init: Deleting: C:\git\abcl\build\built-jar.properties deps-jar: Updating property file: C:\git\abcl\build\built-jar.properties Compiling 1 source file to C:\git\abcl\build\classes compile-single: run-single: LISP_HOME C:\git\abcl\src\org\armedbear\lisp\ java.lang.ClassNotFoundException: org.armedbear.lisp.SpecialOperators at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at org.armedbear.lisp.Lisp.loadClass(Lisp.java:2791) at org.armedbear.lisp.Lisp.<clinit>(Lisp.java:2802) at org.armedbear.lisp.Function$pf_function_class_bytes.<init>(Function.java:225) at org.armedbear.lisp.Function.<clinit>(Function.java:222) at org.armedbear.lisp.Interpreter.<clinit>(Interpreter.java:532) at org.armedbear.lisp.util.Tester.simple(Tester.java:34) at org.armedbear.lisp.util.Tester.main(Tester.java:50) java.lang.ClassNotFoundException: org.armedbear.lisp.AutoloadGeneralizedReference at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at org.armedbear.lisp.Lisp.loadClass(Lisp.java:2791) at org.armedbear.lisp.Lisp.<clinit>(Lisp.java:2807) at org.armedbear.lisp.Function$pf_function_class_bytes.<init>(Function.java:225) at org.armedbear.lisp.Function.<clinit>(Function.java:222) at org.armedbear.lisp.Interpreter.<clinit>(Interpreter.java:532) at org.armedbear.lisp.util.Tester.simple(Tester.java:34) at org.armedbear.lisp.util.Tester.main(Tester.java:50) java.lang.ClassNotFoundException: org.armedbear.lisp.cxr at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at org.armedbear.lisp.Lisp.loadClass(Lisp.java:2791) at org.armedbear.lisp.Lisp.<clinit>(Lisp.java:2808) at org.armedbear.lisp.Function$pf_function_class_bytes.<init>(Function.java:225) at org.armedbear.lisp.Function.<clinit>(Function.java:222) at org.armedbear.lisp.Interpreter.<clinit>(Interpreter.java:532) at org.armedbear.lisp.util.Tester.simple(Tester.java:34) at org.armedbear.lisp.util.Tester.main(Tester.java:50) java.lang.ClassNotFoundException: org.armedbear.lisp.Do at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at org.armedbear.lisp.Lisp.loadClass(Lisp.java:2791) at org.armedbear.lisp.Lisp.<clinit>(Lisp.java:2809) at org.armedbear.lisp.Function$pf_function_class_bytes.<init>(Function.java:225) at org.armedbear.lisp.Function.<clinit>(Function.java:222) at org.armedbear.lisp.Interpreter.<clinit>(Interpreter.java:532) at org.armedbear.lisp.util.Tester.simple(Tester.java:34) at org.armedbear.lisp.util.Tester.main(Tester.java:50) java.lang.ClassNotFoundException: org.armedbear.lisp.dolist at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at org.armedbear.lisp.Lisp.loadClass(Lisp.java:2791) at org.armedbear.lisp.Lisp.<clinit>(Lisp.java:2810) at org.armedbear.lisp.Function$pf_function_class_bytes.<init>(Function.java:225) at org.armedbear.lisp.Function.<clinit>(Function.java:222) at org.armedbear.lisp.Interpreter.<clinit>(Interpreter.java:532) at org.armedbear.lisp.util.Tester.simple(Tester.java:34) at org.armedbear.lisp.util.Tester.main(Tester.java:50) java.lang.ClassNotFoundException: org.armedbear.lisp.dotimes at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at org.armedbear.lisp.Lisp.loadClass(Lisp.java:2791) at org.armedbear.lisp.Lisp.<clinit>(Lisp.java:2811) at org.armedbear.lisp.Function$pf_function_class_bytes.<init>(Function.java:225) at org.armedbear.lisp.Function.<clinit>(Function.java:222) at org.armedbear.lisp.Interpreter.<clinit>(Interpreter.java:532) at org.armedbear.lisp.util.Tester.simple(Tester.java:34) at org.armedbear.lisp.util.Tester.main(Tester.java:50) java.lang.ClassNotFoundException: org.armedbear.lisp.ash at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at org.armedbear.lisp.Lisp.loadClass(Lisp.java:2791) at org.armedbear.lisp.Lisp.<clinit>(Lisp.java:2816) at org.armedbear.lisp.Function$pf_function_class_bytes.<init>(Function.java:225) at org.armedbear.lisp.Function.<clinit>(Function.java:222) at org.armedbear.lisp.Interpreter.<clinit>(Interpreter.java:532) at org.armedbear.lisp.util.Tester.simple(Tester.java:34) at org.armedbear.lisp.util.Tester.main(Tester.java:50) java.lang.ClassNotFoundException: org.armedbear.lisp.PackageFunctions at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at org.armedbear.lisp.Lisp.loadClass(Lisp.java:2791) at org.armedbear.lisp.Lisp.<clinit>(Lisp.java:2818) at org.armedbear.lisp.Function$pf_function_class_bytes.<init>(Function.java:225) at org.armedbear.lisp.Function.<clinit>(Function.java:222) at org.armedbear.lisp.Interpreter.<clinit>(Interpreter.java:532) at org.armedbear.lisp.util.Tester.simple(Tester.java:34) at org.armedbear.lisp.util.Tester.main(Tester.java:50) Unable to determine LISP_HOME. Unable to determine LISP_HOME. org.armedbear.lisp.IntegrityError ERROR placeholder called with arguments: at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) Failed to find loadable system file 'boot.lisp' in boot classpath. at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) Failed to find loadable system file 'boot.lisp' in boot classpath. at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) at org.armedbear.lisp.util.Tester.simple(Tester.java:34) at org.armedbear.lisp.util.Tester.main(Tester.java:50) Exception in thread "main" org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) at org.armedbear.lisp.util.Tester.simple(Tester.java:34) at org.armedbear.lisp.util.Tester.main(Tester.java:50) C:\git\abcl\nbproject\build-impl.xml:1339: The following error occurred while executing this line: C:\git\abcl\nbproject\build-impl.xml:980: Java returned: 1 BUILD FAILED (total time: 0 seconds)

2 1

Resolved: ABCL doesn't current work beyond Java 8 (was Re: build failure)
by Mark Evenson 17 Jan '19

17 Jan '19

> > On Jan 15, 2019, at 16:14, Stephen Varey <srvarey(a)gmail.com> wrote: > > > > Hi > > > > I downloaded the source and built in netbeans where i get this error > > > > JAVA-EXCEPTION: Java exception 'java.lang.NoSuchMethodException: No applicable method named getURLs found in java.lang.ClassLoader or jdk.internal.loader.ClassLoaders$AppClassLoader'. > > C:\git\abcl\etc\ant\netbeans-build.xml:15: The following error occurred while executing this line: > > C:\git\abcl\build.xml:280: The following error occurred while executing this line: > > C:\git\abcl\build.xml:299: Java returned: -1 > > BUILD FAILED (total time: 13 seconds) > > > > Can you help? > > > > Thanks > > stephen > > > On Jan 16, 2019, at 10:23, Stephen Varey <srvarey(a)gmail.com> wrote: > > Hi > Thanks for replying > I just this minute found a thread saying there was a problem with java 10 - which is the default for netbeans. > Just finished compiling with java 8 and that was ok That the ABCL build mechanism doesn’t emit a meaningful diagnostic (or better works beyond Java 8) has been [filed as a ticket][1]. [1]: https://abcl.org/trac/ticket/46 -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

1 0

Re: armedbear-devel Digest, Vol 52, Issue 2
by Stephen Varey 16 Jan '19

16 Jan '19

I have joined the mailing list as requested if you could just help me with this last thing I would so appreciated it I can build now - so thats ok just my hello world give this error ant -f C:\\git\\abcl -Djavac.includes=org/armedbear/lisp/util/Tester.java - Dnb.internal.action.name=run.single -Drun.class=org.armedbear.lisp.util.Tester run-single init: Deleting: C:\git\abcl\build\built-jar.properties deps-jar: Updating property file: C:\git\abcl\build\built-jar.properties Compiling 1 source file to C:\git\abcl\build\classes compile-single: run-single: Hello java.lang.ClassNotFoundException: org.armedbear.lisp.SpecialOperators java.lang.ClassNotFoundException: org.armedbear.lisp.AutoloadGeneralizedReference java.lang.ClassNotFoundException: org.armedbear.lisp.cxr java.lang.ClassNotFoundException: org.armedbear.lisp.Do java.lang.ClassNotFoundException: org.armedbear.lisp.dolist java.lang.ClassNotFoundException: org.armedbear.lisp.dotimes java.lang.ClassNotFoundException: org.armedbear.lisp.ash java.lang.ClassNotFoundException: org.armedbear.lisp.PackageFunctions at org.armedbear.lisp.util.Tester.main(Tester.java:57) Unable to determine LISP_HOME. Unable to determine LISP_HOME. ERROR placeholder called with arguments: org.armedbear.lisp.IntegrityError at org.armedbear.lisp.util.Tester.main(Tester.java:57) C:\git\abcl\nbproject\build-impl.xml:1339: The following error occurred while executing this line: C:\git\abcl\nbproject\build-impl.xml:980: Java returned: 1 BUILD FAILED (total time: 1 second) On Wed, Jan 16, 2019 at 1:00 PM <armedbear-devel-request(a)common-lisp.net> wrote: > Send armedbear-devel mailing list submissions to > armedbear-devel(a)common-lisp.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.common-lisp.net/listinfo/armedbear-devel > or, via email, send a message with subject or body 'help' to > armedbear-devel-request(a)common-lisp.net > > You can reach the person managing the list at > armedbear-devel-owner(a)common-lisp.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of armedbear-devel digest..." > > > Today's Topics: > > 1. build failure (Stephen Varey) > 2. Re: build failure (Mark Evenson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 15 Jan 2019 16:14:04 +0100 > From: Stephen Varey <srvarey(a)gmail.com> > To: armedbear-devel(a)common-lisp.net > Subject: build failure > Message-ID: > < > CAMkLg7taP0nVFiAYL7pfKpdObj6r26xzUHU48BhfHOySQbA4rQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi > > I downloaded the source and built in netbeans where i get this error > > JAVA-EXCEPTION: Java exception 'java.lang.NoSuchMethodException: No > applicable method named getURLs found in java.lang.ClassLoader or > jdk.internal.loader.ClassLoaders$AppClassLoader'. > C:\git\abcl\etc\ant\netbeans-build.xml:15: The following error occurred > while executing this line: > C:\git\abcl\build.xml:280: The following error occurred while executing > this line: > C:\git\abcl\build.xml:299: Java returned: -1 > BUILD FAILED (total time: 13 seconds) > > Can you help? > > Thanks > stephen >

1 0

build failure
by Stephen Varey 16 Jan '19

16 Jan '19

Hi I downloaded the source and built in netbeans where i get this error JAVA-EXCEPTION: Java exception 'java.lang.NoSuchMethodException: No applicable method named getURLs found in java.lang.ClassLoader or jdk.internal.loader.ClassLoaders$AppClassLoader'. C:\git\abcl\etc\ant\netbeans-build.xml:15: The following error occurred while executing this line: C:\git\abcl\build.xml:280: The following error occurred while executing this line: C:\git\abcl\build.xml:299: Java returned: -1 BUILD FAILED (total time: 13 seconds) Can you help? Thanks stephen

2 1

[Reminder CfP] ELS 2019, 12th European Lisp Symposium, April 1-2, Genova
by Didier Verna 12 Jan '19

12 Jan '19

ELS'19 - 12th European Lisp Symposium Hotel Bristol Palace Genova, Italy April 1-2 2019 In cooperation with: ACM SIGPLAN In co-location with <Programming> 2019 Sponsored by EPITA http://www.european-lisp-symposium.org/ Recent news: - Keynote by Stefan Monnier on Emacs Lisp - Keynote by Christophe Rhodes on SBCL - Guest appearance by Matthew Flatt on Racket 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 12th 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 Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els2019 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Important dates: - 01 Feb 2019 Submission deadline - 01 Mar 2019 Notification of acceptance - 18 Mar 2019 Final papers due - 01-02 Apr 2019 Symposium Programme chair: Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Programme committee: Marco Antoniotti, Universita Milano Bicocca, Italy Marc Battyani, FractalConcept, France Pascal Costanza, IMEC, ExaScience Life Lab, Leuven, Belgium Leonie Dreschler-Fischer, University of Hamburg, Germany R. Matthew Emerson, thoughtstuff LLC, USA Marco Heisig, FAU, Erlangen-Nuremberg, Germany Charlotte Herzeel, IMEC, ExaScience Life Lab, Leuven, Belgium Pierre R. Mai, PMSF IT Consulting, Germany Breanndán Ó Nualláin, University of Amsterdam, Netherlands François-René Rideau, Google, USA Alberto Riva, Unversity of Florida, USA Alessio Stalla, ManyDesigns Srl, Italy Patrick Krusenotto, Deutsche Welle, Germany Philipp Marek, Austria Sacha Chua, Living an Awesome Life, Canada Search Keywords: #els2019, ELS 2019, ELS '19, European Lisp Symposium 2019, European Lisp Symposium '19, 12th ELS, 12th European Lisp Symposium, European Lisp Conference 2019, European Lisp Conference '19 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Problem with build-from-lisp.bash
by Pascal Bourguignon 11 Dec '18

11 Dec '18

Hi! The lisp commands to build abcl in the build-from-lisp.bash script have a problem: they’re mere progn forms. When an error occurs, the lisp implementations will enter into the debugger and expect an interactive debugging. This prevents building abcl in automatic scripts, such as: function install_abcl_from_sources(){ # Assume ccl is available. cd "${PREFIX}"/src/ local url='http://abcl.org/releases/1.4.0/abcl-src-1.4.0.tar.gz' local tarball;tarball="$(basename "${url}")" local dir;dir="$(basename "${tarball}" .tar.gz)" local jdkhome;jdkhome="$(java_home)" local logbase;logbase="$(pwd)/${dir}" export JAVA_HOME="${jdkhome}" if [[ ! -e "${tarball}" ]] ; then download "${url}" fi unarchive "${tarball}" "${dir}" cd "${dir}" case "$(uname)" in (Darwin) sed -e 's^"/usr/"^"'"${jdkhome}/"'"^' \ <customizations.lisp.in >customizations.lisp ;; (*) sed -e 's^"/home/peter/sun/jdk1.5.0_16/"^"'"${jdkhome}/"'"^' \ -e 's/fastjar/jar/' \ <customizations.lisp.in >customizations.lisp ;; esac chmod 755 ./build-from-lisp.bash printi 'Building abcl from lisp with ccl' ./build-from-lisp.bash ccl > "${logbase}".build-from-lisp.log 2>&1 \ && ( printi 'Installing abcl' ; install -m 755 abcl "${PREFIX}"/bin/ > "${logbase}".make-install.log 2>&1 ) \ || printe 'Compiling abcl failed; check the logs.' } since errors aren’t detected, but just suspend the execution indefinitely. Therefore, I would suggest to wrap those progn forms into a handler-case; for example, in the case of ccl: (handler-case (progn $3 (ccl:quit)) (error (err) (princ err *error-output*) (terpri *error-output*) (finish-output *error-output*) (ccl:quit 1))) -- __Pascal J. Bourguignon__

2 1

Re: ABCL efficiency and build settings
by Mark Evenson 27 Nov '18

27 Nov '18

> On Nov 22, 2018, at 06:54, ThutmoseIII Thoth <thutmosethree(a)gmail.com> wrote: […] > How well do these debugging/profiling facilities work with ABCL? Will I be able to find out the name of lisp functions being called during a profile or only Java functions? CCL has this problem where we cannot get the lisp functions names in profiling, only the objective C methods. The inspectability of the JVM call stack is certainly better than Clojure even from just reading the function names. Using a [customized version of SLIME][1] allows the use the [ABCL-INTROSPECT][2], which is probably the most advanced way of debugging ABCL. [1]: https://github.com/easye/slime/tree/evenson-20170914a [2]:https://gitlab.common-lisp.net/abcl/abcl/tree/master/contrib/abcl-intros… As for your suspecting that your application is spawning more threads than you would expect, from your code snippet I can’t really offer much other than to wonder what the definition on the DISCONNECT involves. Again providing an example of code, even a stripped down toy application that demonstrates the problem would be enoromously more useful for me to help out. — -- "A screaming comes across the sky. It has happened before but there is nothing to compare to it now."

2 2

ABCL efficiency and build settings
by ThutmoseIII Thoth 15 Nov '18

15 Nov '18

Greetings ABCL developers! I have built an application with ABCL and am very pleased with both ABCL and my application, but I would like some help and suggestions in terms of the efficiency of my program, building settings, and perhaps JVM tuning. In the OS X Activity Monitor, my application is reporting to be using 29 threads and 200% of the CPU — This is enough to make my computer HOT to the touch! The equivalent program was running with CCL and cocoa at about 70% CPU and about 10 threads and was not hot to the touch… My program is fairly simple in that it just displays images in a JFrame that it gets from bytes over a socket. For this program I decided to handle each socket and display on its own thread, so I’ve only created two additional threads. I “built” the program by compiling all the .lisp files into .abcl files, then writing a tiny Java main function which creates an Interpreter and loads each .abcl file and finally calls Interpreter.eval on a lisp function which starts the program. I am using the Oracle Java 1.8 Hotspot JVM and ABCL 1.5.0 built from source. Thank you and please write back with suggestions and questions that will help me make my program run more efficiently.

2 1

[CfP] 12th European Lisp Symposium, April 1-2 2019, Genova, Italy
by Didier Verna 31 Oct '18

31 Oct '18

ELS'19 - 12th European Lisp Symposium Hotel Bristol Palace Genova, Italy April 1-2 2019 In co-location with <Programming> 2019 Sponsored by EPITA http://www.european-lisp-symposium.org/2019/ 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 12th 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 Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els2019 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Important dates: - 01 Feb 2019 Submission deadline - 01 Mar 2019 Notification of acceptance - 18 Mar 2019 Final papers due - 01-02 Apr 2019 Symposium Programme chair: Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Programme committee: tba Search Keywords: #els2019, ELS 2019, ELS '19, European Lisp Symposium 2019, European Lisp Symposium '19, 12th ELS, 12th European Lisp Symposium, European Lisp Conference 2019, European Lisp Conference '19 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Trouble running abcl 1.5.0 with java 1.8.0_161 on macOS 10.12.6
by Carlo Tambuatco 29 Jun '18

29 Jun '18

It seems to build fine, and generate the abcl.jar in the dist/ folder when I build from source. But this error occurs when I run the generated abcl wrapper: Armed Bear Common Lisp 1.5.0 Java 1.8.0_161 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.282 seconds. org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:763) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:748) ERROR placeholder called with arguments: Failed to find loadable system file 'autoloads-gen' in boot classpath. Failed to find loadable system file 'autoloads-gen' in boot classpath. Exception in thread "interpreter" org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:763) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:748) It seems to recognize the correct java to build from, but I have no idea what these integrity errors mean.

4 3

ABCL conflicts with tomcat on ## path names
by Blake McBride 30 May '18

30 May '18

With tomcat, if you want to change the root application you can either rename the directory ROOT or ROOT##myapp. ROOT#myapp makes a lot of sense because it reminds you what's there. However, that naming convention seems to conflict with ABCL. My app under ROOT works fine, but when I name it to ROOT##myapp ABCL gives: org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.ZipCache.get(ZipCache.java:222) at org.armedbear.lisp.ZipCache.get(ZipCache.java:102) at org.armedbear.lisp.Pathname.truename(Pathname.java:2275) at org.armedbear.lisp.Load.findLoadableFile(Load.java:69) at org.armedbear.lisp.Load.loadSystemFile(Load.java:305) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) at com.arahant.lisp.ABCL.init(ABCL.java:35) at com.arahant.utils.StartupListener.contextInitialized(StartupListener.java:225) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4792) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5256) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1140) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1875) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) ERROR placeholder called with arguments: Failed to get cached ZipFile because java.io.FileNotFoundException: /home/arahant/apache-tomcat-8.5.31/demo/ROOT (No such file or directory) Failed to get cached ZipFile because java.io.FileNotFoundException: /home/arahant/apache-tomcat-8.5.31/demo/ROOT (No such file or directory) [ERROR] [utils.StartupListener ] - 2018-05-30 12:42:02 Error initializing Lisp. org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.ZipCache.get(ZipCache.java:222) at org.armedbear.lisp.ZipCache.get(ZipCache.java:102) at org.armedbear.lisp.Pathname.truename(Pathname.java:2275) at org.armedbear.lisp.Load.findLoadableFile(Load.java:69) at org.armedbear.lisp.Load.loadSystemFile(Load.java:305) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) at com.arahant.lisp.ABCL.init(ABCL.java:35) at com.arahant.utils.StartupListener.contextInitialized(StartupListener.java:225) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4792) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5256) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1140) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1875) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.ZipCache.get(ZipCache.java:222) at org.armedbear.lisp.ZipCache.get(ZipCache.java:102) at org.armedbear.lisp.Pathname.truename(Pathname.java:2275) at org.armedbear.lisp.Load.findLoadableFile(Load.java:69) at org.armedbear.lisp.Load.loadSystemFile(Load.java:305) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) at com.arahant.lisp.ABCL.init(ABCL.java:35) at com.arahant.utils.StartupListener.contextInitialized(StartupListener.java:225) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4792) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5256) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1140) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1875) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748) [ERROR] [utils.StartupListener ] - org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.ZipCache.get(ZipCache.java:222) at org.armedbear.lisp.ZipCache.get(ZipCache.java:102) at org.armedbear.lisp.Pathname.truename(Pathname.java:2275) at org.armedbear.lisp.Load.findLoadableFile(Load.java:69) at org.armedbear.lisp.Load.loadSystemFile(Load.java:305) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) at com.arahant.lisp.ABCL.init(ABCL.java:35) at com.arahant.utils.StartupListener.contextInitialized(StartupListener.java:225) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4792) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5256) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:754) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:730) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:734) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1140) at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1875) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)

2 5

Buglet: format "~$" on negative numbers prints two "-" signs
by Scott L. Burson 30 May '18

30 May '18

ABCL> (format nil "~$" -2.34) --2.34 I've fixed this locally by modifying 'format-dollars' to call 'abs' on the first argument to 'sys::flonum-to-string'. -- Scott

2 1

ASDF 3.3.2 released
by Robert Goldman 04 May '18

04 May '18

Dear Lisp implementors and maintainers, Today we release ASDF 3.3.2, the second bugfix release for the 3.3 release series. Of primary interest in this release are 1. Multiple fixes in handling misnamed (or "legacy-named," if you prefer) secondary systems ("foo-test" instead of "foo/test"). Thanks to Eric Timmons, there is also a similar fix for package-inferred-systems. 2. Fix an annoying warning message for compute-action-stamp. 3. Add support for the Mezzano implementation (thanks to E. Housel, H. Harrington). 4. Miscellaneous minor fixes and documentation tweaks. We urge implementations that are currently bundling previous versions of ASDF -- and especially those bundling 3.3.0 or 3.3.1 -- to upgrade to 3.3.2 at their earliest convenience. Immense thanks, as always, to Fare Rideau. Also thanks to the many bug reporters and patch submitters (see the Changelog), and to Anton Vodonosov and Dave Cooper for help with testing. Here is the changelog entry for 3.3.2: cl-asdf (2:3.3.2-1) unstable; urgency=low Bug fix release: * Dependency tracking: fix bugs in handling misnamed secondary systems. We now distinguish between "syntactic" and "semantic" primariness, properly warn in case a secondary system is misnamed, yet properly recompile or avoid spurious recompilation depending on whether there or not is a conflict or redefinition. Similarly handle package-inferred-system (thanks to Eric Timmons). Better warning in a fishy case of compute-action-stamp. * UIOP: Add package location information to define-package on SBCL. * Upgrade: fix issue with asdf/bundle. * Portability: add support for Mezzano (thanks to E. Housel, H. Harrington) * Documentation: add discussion of best practices. * Package-inferred system: Improve source file handling. * Test and documentation improvements. -- Francois-Rene Rideau <fare(a)tunes.org> Thu, 03 May 2018 22:46:19 -0400

1 0

Causing an exception rather than calling the debugger
by Blake McBride 02 May '18

02 May '18

Hi, I embedded ABCL in an app some years ago. When an error occurred, ABCL threw an exception. It did what I want. Today I upgraded to the latest jar and I am experiencing a different behavior. When an error occurs ABCL enters a debug REP loop. Calling a REP loop on error is perfect for interactive use but not workable in an embedded situation. I'm hoping there is a simple way for me to change this behavior. Any help is greatly appreciated. Thanks. Blake McBride

2 2

Re-entrant and multi-entrant ABCL calls
by Blake McBride 20 Apr '18

20 Apr '18

Greetings, Does ABCL safely support re-entrant and multi-entrant calls? What I mean by that is the following: Re-entrant: on a single OS thread - my Java program calls into ABCL, then ABCL calls into my Java application, and then the Java application calls back into ABCL. So the stack has Java, ABCL, JAVA, and then ABCL again. Multi-entrant: my Java application has many threads. One of my threads calls into ABCL. Then, while one thread is still in ABCL, another thread evokes ABCL. So now we have two calls into ABCL by two independent Java/OS threads running at the same time. I understand the typical problems associated with application-level shared variables. This is expected. The question revolves around ABCL's internals. I presume ABCL would have some shared data that is internal to ABCL. That's what I am unclear about. ABCL would have had to be designed for these scenarios from the ground up. This is a little hard to test because if it can't always correctly handle these situations, it may not become clear until certain scenarios arrive. It may be hard for any "test" program I write to cause those scenarios, so I thought this may be a known answer. Thanks! Blake

2 2

[Final CfPart] ELS 2018, April 16-17, Marbella, Spain
by Didier Verna 08 Apr '18

08 Apr '18

ELS'18 - 11th European Lisp Symposium Centro Cultural Cortijo de Miraflores Marbella, Málaga Spain April 16-17 2018 In cooperation with: ACM SIGPLAN Sponsored by RavenPack, Brunner Software GmbH, Franz Inc., LispWorks Ltd., and EPITA http://www.european-lisp-symposium.org/ Recent news: - ELS 2018 is in cooperation with ACM SIGPLAN - Full program now available on the website - Still one week to register! 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. Keynote speakers: - Vsevolod Domkin -- Lisp in a Startup: the Good, the Bad, and the Ugly - R. Matthew Emerson -- This Old Lisp (a look at Clozure CL) Important dates: - 16-17 Apr 2018 Symposium Programme chair: David Cooper, Genworks Intl., USA Local chairs: Andrew Lawson, Ravenpack, Spain Programme committee: Andy Wingo, Igalia, Spain Christophe Rhodes, Goldsmiths University, UK Christopher Wellons Null Program USA Ernst van Waning, Infometrics.nl, Netherlands Irène Durand, LaBRI, Université de Bordeaux, France Julian Padget, University of Bath, UK Ludovic Courtès, Inria, France Michael Sperber, DeinProgramm, Germany Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Olin Shivers Northeastern University USA Philipp Marek, Austria Robert Strandh, Université de Bordeaux, France Sacha Chua Living an Awesome Life Canada Scott McKay, Future Fuel, USA Search Keywords: #els2018, ELS 2018, ELS '18, European Lisp Symposium 2018, European Lisp Symposium '18, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2018, European Lisp Conference '18 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

available encodings symbols strangeness; was: How to determine allowable external formats at run time
by Robert Dodier 02 Apr '18

02 Apr '18

Hi, I've made some progress, but ran into a problem. I see that SYSTEM:AVAILABLE-ENCODINGS returns a list of symbols which represent the various encodings that are discovered via Charset.availableCharsets. That's great, but the symbols are apparently not interned in the keyword package, so it makes it somewhat confusing to determine whether a given encoding is on the list. e.g. (member :utf-16 (system:available-encodings)) returns NIL, although looking at the list, you can see that :UTF-16 is there. Confusingly, (mapcar #'symbol-package (system:available-encodings)) shows that all symbols are in the keyword package, but (find-symbol "UTF-16" :keyword) returns NIL. I believe the problem is that availableEncodings in src/org/armedbear/lisp/Stream.java says, in part, (at line 399 in the current version) new Symbol(charset, PACKAGE_KEYWORD) but I think more appropriate would be PACKAGE_KEYWORD.intern(charset) or, at any rate, something to intern the charset symbol in the package, since the Symbol constructor doesn't have that effect. What does anyone think about that? I tried to sign in to Trac to enter a bug report about this but wasn't able. (1) "Login" wants a common-lisp.net user id -- I don't see a method to obtain a user id on the common-lisp.net website. (2) "OpenId login", clicked on Google, got: "Error in discovery: HTTP Response status from identity URL host is not 200. Got status 404". Hope this helps, and all the best. Robert Dodier

2 3

Re: available encodings symbols strangeness; was: How to determine allowable external formats at run time
by Robert Dodier 27 Mar '18

27 Mar '18

On Sun, Mar 25, 2018 at 8:41 PM, Alan Ruttenberg <alanruttenberg(a)gmail.com> wrote: > You can submit a bug report at https://github.com/armedbear/abcl/issues if > you would like. Thanks Alan, I have reported the bug as: https://github.com/armedbear/abcl/issues/82 Perhaps it would be helpful to mention this bug tracker elsewhere. I wasn't able to find it by looking at the common-lisp.net project info, I only found Trac. best, Robert Dodier

2 1

How to determine allowable external formats at run time
by Robert Dodier 26 Mar '18

26 Mar '18

Hi, I'm wondering if there is a way to get the list of allowable values of the :EXTERNAL-FORMAT keyword for OPEN. Is there a way to determine the possible values at run time? I looked into the source code for MAKE-FILE-STREAM but I got a little lost ... perhaps someone can point me in the right direction. What I'm trying to do is to verify whether a given format is acceptable. I am thinking that I can inspect a list to see if the given format is on the list. Another workable solution would be a function which can report whether the given format is acceptable, if such a function exists. Thanks for your help, Robert Dodier

2 1

[CfPart] European Lisp Symposium 2018, 16-17 April, Marbella, Spain
by Didier Verna 14 Mar '18

14 Mar '18

ELS'18 - 11th European Lisp Symposium Centro Cultural Cortijo de Miraflores Marbella, Málaga Spain April 16-17 2018 Sponsored by Brunner Software GmbH, Franz Inc., LispWorks Ltd., and EPITA http://www.european-lisp-symposium.org/ Recent news: - Invited speakers announced (see below) - Registration open. Don't miss the March 25 deadline for the early bird discount! 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. Keynote speakers: - Vsevolod Domkin -- Lisp in a Startup: the Good, the Bad, and the Ugly - R. Matthew Emerson -- This Old Lisp (a look at Clozure CL) Important dates: - 25 Mar 2018 Early registration deadline - 16-17 Apr 2018 Symposium Programme chair: David Cooper, Genworks Intl., USA Local chairs: Andrew Lawson, Ravenpack, Spain Programme committee: Andy Wingo, Igalia, Spain Christophe Rhodes, Goldsmiths University, UK Christopher Wellons Null Program Canada Irène Durand, LaBRI, Université de Bordeaux, France Julian Padget, University of Bath, UK Ludovic Courtès, Inria, France Michael Sperber, DeinProgramm, Germany Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Olin Shivers Northeastern University USA Philipp Marek, Austria Robert Strandh, LaBRI, Université de Bordeaux, France Sacha Chua Living an Awesome Life Canada Scott McKay, Future Fuel, USA Search Keywords: #els2018, ELS 2018, ELS '18, European Lisp Symposium 2018, European Lisp Symposium '18, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2018, European Lisp Conference '18 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

interrupting and destroying threads [internals, help wanted]
by Alan Ruttenberg 03 Mar '18

03 Mar '18

TL;DR; Doesn't seem to work reliably. Interrupts, for example in slime, don't reliably get acted on. Sometimes threads are killed instead of interrupted. Some effort to amend this is discussed below. Background: There are two interrupt systems in ABCL, one defined on org.armedbear.lisp.Lisp, and one on org.armedbear.lisp.LispThread. It is unclear why there are two parallel systems. The interrupt defined on org.armedbear.lisp.Lisp works as follows: Call (interrupt-lisp) A object variable "interrupted" is set. At several places in the interpreter (eval, tagbody) the variable is checked. When compiling code - typically at branch points - code is emitted to check the variable, and if set, handleInterrupts is called. handleInterrupts starts a break loop. It's not clear which thread that will happen in, since there is a delay between when an interrupt is signaled and when the break is called, so you might be in a different thread than the one in which interrupt-lisp is called. This interrupt system is *not* the one used in slime or bordeaux threads. The second interrupt system, which *is* used by slime and bordeaux uses an instance variable on LispThread called "threadInterrupted". One calls (interrupt-thread thread function &rest args) to interrupt. At that point the variable threadInterrupted is set to true and the function is queued for eventual (hopefully prompt) execution. Then the java thread built-in interrupt call is made, which also sets some state in the thread (JVM internal) indicating a request for interrupt. Java's interrupt is checked by Java in some set of internals that wait, such as when sleep is called, or presumably when there is blocking IO, or by explicit checks by user code. When detected by java an InterruptedException is thrown. When doing user checked the user has to throw the exception. It is intended that there are exception handlers to process the interrupts. In several places ABCL explicitly catches the exception and calls processThreadInterrupts which executes the queued set of interrupt functions and should then proceed in whatever it was doing. Presumably the issue with threads dying is when an Interrupted Exception is not handled. Handling of InterruptException happens at only a few points - thread-join, sleep, object-wait. Unlike as with lisp-interrupt the compiler does *not* generate code to check. As a consequence if a thread is doing anything else it will not notice the exception. This leads to a poor interactive experience - slime's control-c often does not work in a timely manner. Handling the interrupt can be tricky if called at the wrong time as there is no guarantee that other lisp state is consistent. Related to this the implementation of destroy thread is suboptimal. Bordeaux threads documents that it is implementation-defined whether unwind-protected forms are handled on destroy. Practically it seems many implementations do, as the package lparallel (highly recommended!) depends on that and implements the ability to kill worker threads on all supported platforms *except* than ABCL. Thread destroying is implemented in a similar manner to interrupts. There is a variable that is set when the destruction is requested, with a single place where it is checked an acted on (beginning of eval). When detected a ThreadDestroyed exception is thrown. ThreadDestroyed is caught at the top of the thread's execution, which seems to explain why unwind protects are not handled. That the only check is in eval means that if you are executing only compiled code the thread will not actually be destroyed. --- As you can see, this is something of a mess. I've made some initial attempts to remedy it but am not confident enough that they are the correct way of doing things, or whether they will work reliably. The changes are: 1) Whenever Lisp interrupts are checked, also check for thread interrupts. There are a few places in the java code that do this and I simply add a check for thread interrupts at those points as well. In addition I modify the code generation so that when checks for lisp interrupts are generated as part of compiled code, I also generate a check for thread interrupts. 2) Don't call JVMs thread.interrupt. The benefit of not calling it is that you remove the possibility that the lisp will be in an inconsistent state when it handles the interrupt. The disadvantage is that you won't be able to interrupt anything that's not in lisp code. 3) Have destroy-thread use interrupt-thread to throw to a new catch tag which is set around the thread run function. There is already a provision for defining a wrapper around a thread's run function - a lisp function called (unsurprisingly) THREAD-FUNCTION-WRAPPER. Currently it has an abort restart handler. However destroying a thread is not necessarily the same as abort. Since the throw works correctly wrt unwind protect and other lisp state, behavior of destroy is predictable - active unwind-protections are run before the thread exits. Note: the ThreadDestroyed exception is never called now. --- The above seem to work "ok" but haven't been extensively tested. Responsiveness to slime's control-c is often fast, and lparallel can kill worker threads. So the first question I have is: Is there something I've missed, or does it seem like the strategy above should work. Is anybody doing thread-heavy work that you could test this against. Having done the above and verified that it passes the smoke test, I'd like to enable using java's thread.interrupt(), so that interrupts can happen even when JVM or foreign java code is running. I've enabled it to see what would happen and things work ok in some cases, but there are gaps. For example, in one case lparallel code complained about working with a lock. So the second question is: What needs to be done to have thread.interrupt be reliable. My current speculation is that the way to handle it is in code generation. The code generation for unwind protect already uses exception catching to for unwind protect and some other cases. One thought is to, effectively, automatically add more cleanup code wherever the compiler generates and (JVM Exception) catch. However the compiler is complicated and I don't understand enough of how it works yet. The differences, as they stand now, can be seen at https://github.com/armedbear/abcl/compare/master...alanruttenberg:thread-in… Comments, suggestions, help, would very much be welcomed. Regards, Alan Ruttenberg

1 0

[Final CfP] European Lisp Symposium 2018 -- Deadline extension
by Didier Verna 20 Feb '18

20 Feb '18

ELS'18 - 11th European Lisp Symposium Centro Cultural Cortijo de Miraflores Marbella, Málaga Spain April 16-17 2018 Sponsored by Brunner Software GmbH and EPITA http://www.european-lisp-symposium.org/ *** Important: submission deadline extended to Sunday Feb. 25! 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 11th 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 Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els2018 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Important dates: - 25 Feb 2018 Submission deadline (*** extended! ***) - 19 Mar 2018 Notification of acceptance - 25 Mar 2018 Early registration deadline - 02 Apr 2018 Final papers due - 16-17 Apr 2018 Symposium Programme chair: David Cooper, Genworks Intl., USA Local chairs: Andrew Lawson, Ravenpack, Spain Programme committee: Andy Wingo, Igalia, Spain Christophe Rhodes, Goldsmiths University, UK Christopher Wellons Null Program Canada Irène Durand, LaBRI, Université de Bordeaux, France Julian Padget, University of Bath, UK Ludovic Courtès, Inria, France Michael Sperber, DeinProgramm, Germany Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Olin Shivers Northwestern University USA Philipp Marek, Austria Robert Strandh, LaBRI, Université de Bordeaux, France Sacha Chua Living an Awesome Life Canada Scott McKay, Future Fuel, USA Search Keywords: #els2018, ELS 2018, ELS '18, European Lisp Symposium 2018, European Lisp Symposium '18, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2018, European Lisp Conference '18 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

[CfP] ELS 2018, April 16-17, Marbella, Spain
by Didier Verna 13 Feb '18

13 Feb '18

Reminder: submission deadline this sunday! ELS'18 - 11th European Lisp Symposium Centro Cultural Cortijo de Miraflores Marbella, Málaga Spain April 16-17 2018 Sponsored by Brunner Software GmbH and EPITA 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 11th 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 Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els2018 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Important dates: - 18 Feb 2018 Submission deadline - 19 Mar 2018 Notification of acceptance - 25 Mar 2018 Early registration deadline - 02 Apr 2018 Final papers due - 16-17 Apr 2018 Symposium Programme chair: David Cooper, Genworks Intl., USA Local chairs: Andrew Lawson, Ravenpack, Spain Programme committee: Christophe Rhodes, Goldsmiths University, UK Christopher Wellons Null Program Canada Irène Durand, LaBRI, Université de Bordeaux, France Julian Padget, University of Bath, UK Ludovic Courtès, Inria, France Michael Sperber, DeinProgramm, Germany Nicolas Neuss, Universität Karlsruhe, Germany Olin Shivers Northwestern University USA Robert Strandh, LaBRI, Université de Bordeaux, France Sacha Chua Living an Awesome Life Canada Scott McKay, Future Fuel, USA Search Keywords: #els2018, ELS 2018, ELS '18, European Lisp Symposium 2018, European Lisp Symposium '18, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2018, European Lisp Conference '18 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

[CfP] 11th European Lisp Symposium, 16-17 Apr 2018, Marbella, Spain
by Didier Verna 18 Dec '17

18 Dec '17

ELS'18 - 11th European Lisp Symposium Centro Cultural Cortijo de Miraflores Marbella, Málaga Spain April 16-17 2018 Sponsored by EPITA 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 11th 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 Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els2018 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Important dates: - 18 Feb 2018 Submission deadline - 19 Mar 2018 Notification of acceptance - 25 Mar 2018 Early registration deadline - 02 Apr 2018 Final papers due - 16-17 Apr 2018 Symposium Programme chair: David Cooper, Genworks Intl., USA Local chairs: Andrew Lawson & Nick Levine, Ravenpack, Spain Programme committee: tba Search Keywords: #els2018, ELS 2018, ELS '18, European Lisp Symposium 2018, European Lisp Symposium '18, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2018, European Lisp Conference '18 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

FriCAS w. ABCL
by Kurt Pagani 05 Dec '17

05 Dec '17

I (almost) successfully compiled the fricas computer algebra system using ABCL (https://github.com/nilqed/fricas0). "Almost" because four of the over 1300 algebra files are refractory. I essentially got two errors: >> System error: The value :INT is not of type (COMMON-LISP:MEMBER COMMON-LISP:NIL :BOOLEAN). and >> System error: The assertion (COMMON-LISP:<= -32768 JVM::OFFSET 32767) failed. While the first one might be related to http://abcl.org/trac/ticket/316 (http://abcl.org/trac/changeset/15034) http://armedbear-devel.common-lisp.narkive.com/rm9OArfe/the-value-long-is-n… I have no idea what the second one could mean. Google, however, shows similar ones @: https://common-lisp.net/project/cl-test-grid/ql/qlalpha-2014-08-23-abcl-loa… (fishpack, lapack ...). Well, I'm stuck, so any ideas would be very welcome. Many thanks Kurt

2 2

Bug: format ~G of 1.0d0
by Willem Broekema 07 Nov '17

07 Nov '17

The following output seems to be wrong:(format nil "~G" 1.0d0) "1.0 " I expect it to be "1. " For the formula in CLHS "22.3.3.3 Tilde G: General Floating-Point" I arrive at q=0, n=1, d=1, dd=0 where dd stands for the number of decimals to print. Allegro, ECL, SBCL agree with this. Kind regards, Willem

1 0

Bug: defmacro environment variable declaration
by Willem Broekema 05 Nov '17

05 Nov '17

In the following form: (defmacro m (&environment e) (declare (ignore e)) 'm))) The declaration ends up in the wrong place after macro expansion: (LAMBDA (#:WHOLE-5584 #:ENVIRONMENT-5585) (LET* ((E #:ENVIRONMENT-5585)) ;; the (DECLARE (IGNORE E)) should go here (UNLESS (<= 0 (SYSTEM::DOT-LENGTH (CDR #:WHOLE-5584)) 0) (SYSTEM::ARG-COUNT-ERROR 'DEFMACRO 'M (CDR #:WHOLE-5584) '(&ENVIRONMENT E) 0 0)) (LET* () (DECLARE (IGNORE E)) ;; but it ends up here (BLOCK M 'M)))) Using Armed Bear Common Lisp 1.5.0 - Willem

1 0

abcl-web
by Alexandre Rademaker 16 Oct '17

16 Oct '17

What is the current status of http://abcl-web.sourceforge.net? What is the best alternative for web developing in ABCL? I am particularly interested in ABCL for using the Java starter kits in IBM Bluemix https://console.bluemix.net/developer/appservice/starter-kits Best, -- Alexandre Rademaker http://arademaker.github.io <http://arademaker.github.io/>

2 1

difficulties building abcl 1.5 from source distribution
by Guenther Thomsen 11 Oct '17

11 Oct '17

So far I wasn't able to build abcl release 1.5 under Linux (Ubuntu 16.04.3 which comes at this time with ant 1.9.6 and openjdk 1.8.0_131) from the distributed source [1]. The (ant) build completes (reportedly) successful even though there are errors: --8<-- [java] ; (DEFMACRO DIAG ...) [java] ; (DECLAIM (FTYPE # ...)) [java] ; (DEFUN VERIFY-LOAD ...) [java] ;SYSTEM:%MAKE-CONDITION triggers autoloading of org.armedbear.lisp.make_condition ... [java] ; Autoloaded org.armedbear.lisp.make_condition (0.001 seconds) [java] 2.081 seconds real time [java] 6753524 cons cells [java] FORMAT-ERROR: error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] #<THREAD "interpreter" {79A0B5CB}>: Debugger invoked on condition of type FORMAT-ERROR [java] error in format: [java] Maximum error depth exceeded (11 nested errors) with '#<FORMAT-ERROR {67090C23}>'. [java] CL-USER(2): abcl.compile: [echo] Compiled ABCL with Java version: 1.8.0_131 abcl.version.src.0: abcl.version.src.1: abcl.version.src.2: abcl.version.src.3: abcl.version.src: abcl.stamp.version.uptodate: abcl.stamp.version.generate: abcl.stamp.version.0: abcl.stamp.version.1: abcl.stamp.version.2: abcl.stamp.version: [echo] ABCL implementation version: 1.5.0 abcl.stamp.hostname: [echo] abcl.hostname: slab abcl.stamp: abcl.jar.uptodate: abcl.contrib: abcl-contrib.jar: abcl.jar: [jar] Building jar: /home/tho/Downloads/src/abcl-src-1.5.0/dist/abcl.jar abcl.wrapper.unix: abcl.wrapper.windows: abcl.wrapper: [copy] Copying 1 file to /home/tho/Downloads/src/abcl-src-1.5.0 [echo] Created executable ABCL wrapper in 'abcl' [echo] N.B. This wrapper requires '/home/tho/Downloads/src/abcl-src-1.5.0/dist/abcl.jar' not be moved. BUILD SUCCESSFUL -->8-- Then the executable cannot be run: --8<-- $ ./abcl Armed Bear Common Lisp 1.5.0 Java 1.8.0_131 Oracle Corporation OpenJDK 64-Bit Server VM Low-level initialization completed in 0.173 seconds. org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:763) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:748) ERROR placeholder called with arguments: Failed to find loadable system file 'autoloads-gen' in boot classpath. Failed to find loadable system file 'autoloads-gen' in boot classpath. Exception in thread "interpreter" org.armedbear.lisp.IntegrityError at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) at org.armedbear.lisp.Primitive.execute(Primitive.java:113) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.Lisp.error(Lisp.java:383) at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) at org.armedbear.lisp.Load$load_system_file.execute(Load.java:763) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:575) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.loadStream(Load.java:629) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:597) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:477) at org.armedbear.lisp.Load.loadSystemFile(Load.java:375) at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) at org.armedbear.lisp.Interpreter.createDefaultInstance(Interpreter.java:102) at org.armedbear.lisp.Main$1.run(Main.java:46) at java.lang.Thread.run(Thread.java:748) -->8-- Meanwhile I cloned the git repository and the HEAD as well as a branch off of commit 3e92245341ef07dd0915d1f7f59fa335626330db (release 1.5 [a tag would be nice, imho]) build and run successful, as far as I can tell. I noticed that the files in the zip archive are DOS formatted, which _shouldn't_ cause any such issue (making comparison with the files in the git repository a bit more cumbersome though). I haven't investigated further, as I got now a working abcl, but wanted to have mentioned it, as I couldn't find any hint regarding above error online. hth ~ Guenther [1] abcl-src-1.5.0.zip from https://common-lisp.net/project/armedbear/releases/1.5.0/abcl-src-1.5.0.zip

1 1

ASDF 3.3 is released
by Robert Goldman 07 Oct '17

07 Oct '17

Today we release ASDF 3.3. The most substantial change is to the build planning process, which has been reformed by François-René Rideau so that DEFSYSTEM-DEPENDS-ON now behaves correctly. There are a number of other improvements, and we are indebted to Daniel Kochmanski, Rommel Martinez, and Chun Tian for contributions. Thanks again to Anton Vodonosov and Dave Cooper for support in testing, and new thanks to Martti Halminen, Jens K. Loewe, and Jason Miller. I would like to dedicate this ASDF release to the late Elias Pipping. On a technical level, Elias made great improvements in some of the most challenging ASDF internals, notably the RUN-PROGRAM component of UIOP, a place where implementations are not constrained by the language specification, diverge radically from each other, and are poorly documented. On a personal level, Elias was very supportive to me as ASDF maintainer, and while I was going through an illness. He did all these things despite being gravely ill with the cancer that eventually killed him. He will be greatly missed, Z'chrono L'vracha. We urge implementations that are currently bundling previous versions of ASDF to adopt 3.3.0 at their earliest convenience. The improvements offered in this release will substantially improved the reliability and predictability of ASDF use. Details on bugfixes can be found at https://launchpad.net/asdf and in the discussions in merged branches of https://gitlab.common-lisp.net/asdf/asdf Here is the changelog entry for 3.3: cl-asdf (2:3.3.0-1) unstable; urgency=low New milestone: * Build-plan: Extensively revised the build plan process so that :DEFSYSTEM-DEPENDS-ON would work correctly, even when depended on systems change (which didn't work before). See our ELS demonstration about it: "Delivering Common Lisp Applications with ASDF 3.3" < https://github.com/fare/asdf2017 > * Internals: to support the above, many ASDF internals have changed. ASDF now has the notion of multiple build phases to a common build session (which generalizes the previous build cache). ASDF considers loading a .asd file as an operation DEFINE-OP, and tracks as dependencies files mentioned during in :LOAD-FILE-FORM statements, etc. Some code has moved to new files or among old files, and between packages. Actions are now uniformly represented as a CONS of an OPERATION and a COMPONENT, where in some cases previously only the class of the operation was preserved. Forcing is constrained to be uniform across all phases of a top level ASDF operation invocation. Fixed the protocol for resetting systems being (re)defined, allowing subclasses to define default slot values. Remove *LOAD-SYSTEM-OPERATION*, as the current maintainer of ECL, for which it was originally designed, decided that it could never be made to work properly, after all. * ASDF&UIOP: Tweak dependencies between ASDF and UIOP. To avoid DEFINE-OP circularity, asdf.asd with no longer causes uiop.asd to be loaded. A standalone UIOP won't be loaded at all unless it's strictly more recent than ASDF. * Tests: tests for new capabilities and bugs. Test backtraces can be disabled. * Documentation: a number of improvements and clarifications. * Feature: a new feature :asdf3.3 * ECL: restored the deprecated function MAKE-BUILD, removed in 3.2.0, in a way that works on top of supported APIs (we still recommend you migrate to these supported APIs). Also stop using the deprecated COMPUTE-INIT-NAME. * Deprecation: starting to emit STYLE-WARNINGs for deprecated functions. Will gradually escalate to true WARNINGs and then ERRORs. -- Robert P. Goldman <rpgoldman(a)sift.net> Sun, 20 August 2017 21:00:00 -0500

1 0

Compiler error during compile of TAGBODY and CATCH
by Paul Dietz 06 Oct '17

06 Oct '17

(compile nil '(lambda () (tagbody (catch 'c 17)))) ==> COMPILE-TAGBODY: tag not found: 17 [Condition of type SIMPLE-ERROR]

2 1

Compiler fail: Stack inconsistency detected in <unknown> at index 40: found 2, expected 0.
by Paul Dietz 06 Oct '17

06 Oct '17

(defparameter *abcl1* '(lambda (a) (declare (optimize (debug 0) (compilation-speed 1) (speed 2) (space 3) (safety 1))) (ash 0 (bit #*0100 (catch 'ct7 a))))) (defun test1 () (let ((fn (compile nil *abcl1*))) (mapcar fn '(0 1 2 3)))) (test1) ==> ; Caught ERROR: ; Stack inconsistency detected in <unknown> at index 40: found 2, expected 0.

2 1

It appears that ABCL is not ready for Java 9
by Gregory Baryza 27 Sep '17

27 Sep '17

I tried compiling it and was presented with the following error: .... [java] ; Loading C:/Downloads/Armed_Bear_Lisp/abcl-src-1.5.0/build/classes/org/armedbear/lisp/abcl-contrib.abcl ... [java] [java] ; Compilation unit finished [java] ; The following functions were used but not defined: [java] ; SYSTEM::SOURCE [java] [java] 311.988 seconds real time [java] 249904041 cons cells [java] JAVA-EXCEPTION: Java exception 'java.lang.NoSuchMethodException: No applicable method named getURLs found in java.lang.ClassLoader or jdk.internal.loader.ClassLoaders$AppClassLoader'. BUILD FAILED C:\Downloads\Armed_Bear_Lisp\abcl-src-1.5.0\build.xml:280: The following error occurred while executing this line: C:\Downloads\Armed_Bear_Lisp\abcl-src-1.5.0\build.xml:299: Java returned: -1 Total time: 6 minutes 11 seconds It compiled successfully under JDK_1_8_0_144. Has anyone else seen this?

4 6

Towards save-world for ABCL
by Alan Ruttenberg 14 Sep '17

14 Sep '17

A limiting factor in uptake and wider-scale use of ABCL, and java applications in general, has been startup time. Some native lisps have a save-world or save-image facility <https://stackoverflow.com/questions/39133421/how-to-properly-save-common-li…> that lets you create a snapshot of a running lisp which can then quickly resumed. I've long wanted something like this for ABCL - loading the system I work on (LSW <https://github.com/alanruttenberg/lsw2>) takes maybe 15 seconds on my reasonably fast laptop. This makes it annoying to run for short tasks, or to run in a pipe with non-lisp tooks. I also work with OWL ontologies that can take 10s of minutes to classify. I'd very much like to save that work so that I can fire off quick query, or reduce development time turnaround. Recently I've started to play with docker <https://www.docker.com/community-edition> and found that there is starting to be support for CRIU <https://github.com/xemul/criu>, which allows one to save the state of linux processes/containers and then restart them. I've just run a first successful test of this and I wanted to share the recipe, see if others have poked at this, see if there is interest in thinking about / implementing more transparent support for this for ABCL, and in case it is useful, as is, for someone. 1. You may need to install support for CRIU into docker. I had to do this with docker for mac <https://www.docker.com/docker-mac>, which is what I'm running. I think it's built into docker for linux, and am not sure about docker for windows. To install the mac support I followed instructions at https://hub.docker.com/r/boucher/criu-for-mac/ run: *docker run --rm -it --privileged --pid=host boucher/criu-for-mac* 2. Start a container that loads up ABCL and give it enough time to load (about 20 seconds in my case) *docker run -id lsw2/devel /home/lsw/repos/lsw2/bin/lsw* Note that the shell prompt returns immediately. There's no automatic way, at the moment, to see when the lisp has finished loading. In this case lsw2/lisp is my image built according to instructions at https://github.com/alanruttenberg/lsw2/tree/owlapiv4/virtual-machine /home/lsw/repos/lsw2/bin/lsw is the command that runs ABCL and loads my system inside the container. Replace these with your own, or use Mark Evenson's easye/abcl as an image to try (or use his Dockerfile <https://github.com/armedbear/abcl/blob/master/Dockerfile> as a base) . That image starts ABCL by itself, so you don't need to do it on the docker run command line as I do above. The -i switch hooks up stdin and the -d switch lets the container sit running in the background. Once ABCL is finished starting, the process in the container is effectively sitting at the repl prompt, waiting for input, but its stdin isn't connected to anything at the moment. Note that if you use the -t switch, as one commonly sees in docker examples, the checkpoint stage below will fail. 3. run: *docker ps* to get the Container ID for the container just created. 4. run: *docker checkpoint create <container-id> <checkpoint-name>* <container-id> is the id you just got from docker ps. <checkpoint-name> is a label you choose for the saved-state. On completion of the command the container stops running. 5. run: *docker start --checkpoint <checkpoint-name> <container-id>* After a much quicker startup(fraction of a second), the container is running again. You can interact with it by 6. run: *docker attach <container-id>* Hit return and you'll get the REPL prompt and can type something in to eval. Use control-d (EOF) to detach. You can reattach the same way again. Type (quit) to the repl, or run *docker kill <container-id>* to stop the container for good and exit. -- Obviously there is MUCH more that needs to be done to make this easy and practical, e.g. - packaging: While one can package up an image that a container can start from and easily serve it, the checkpoints are not easily attachable to images. Rather, they are specific to containers, and saving process state isn't couple with saving file-system state. That could be managed with some wrapper scripts that checkpoints on first run, etc. I'm also not sure of the mechanics of running several containers from the same checkpoint, at the same time. I'm guessing that sort of thing will be more directly supported in docker within a year or 2, if not sooner. - Doing this without docker: While using docker means that you can create an artifact that runs in all platforms, it may be easier to package up an application that will certainly run under linux to use CRIU directly. It may even be more practical to use CRIU inside the container instead of docker checkpoint. dunno. - reliability: I haven't run many tests yet to try to ensure that the checkpointed process doesn't have any problems - I've just tried simple things at the prompt. I haven't experimented with, e.g. running a web server inside ABCL and seeing if there are any issues with ports or network processes on restart. - restart hooks: some things may not be able to be saved. We'll need a provision for hooks that run when restarting and documentation about when they have to be used. Alan Ruttenberg

1 0

BUG: clhs limits adherence
by Peter Keller 10 Sep '17

10 Sep '17

Hello, I would like to report, well, a bug of sorts. Suppose we look at this in ABCL 1.5.0: CL-USER(1): (values call-arguments-limit lambda-parameters-limit multiple-values-limit (lisp-implementation-type)) 50 50 32 "Armed Bear Common Lisp" I claim that those limits are valid from the CLHS, but are not enforced, and hence not correct, in version 1.5.0 of ABCL. I did a cursory look through the ABCL sources and found that really only FORMAT actually checks (well, the appropriate ones anyway) these limits when processing the format string (IIUC). Here is a place where the limits should have been enforced: I tried these with (declaim (optimize (safety 3))) set. CL-USER(2): (list 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10) (1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10) CL-USER(3): Another example: CL-USER(3): (setf *foo* (loop for i below 1024 collect i)) <big correct list as output> CL-USER(4): (apply #'max *foo*) 1023 Another example: CL-USER(1): (defmacro defit (name size) (let ((ll (loop for i below size collect (make-symbol (format nil "V~A" i))))) `(defun ,name ,ll (list ,@ll)))) DEFIT CL-USER(2): (defit foo 1024) FOO CL-USER(3): (apply #'foo (loop for i below 1024 collect i)) <big correct list as output> Another example: (funcall #'values 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 ) <correct returned values> I believe that these worked when they should have failed. That is the, uh, bug, that I'm reporting. :) The only other legitimate option to believe is that I'm silently corrupting memory somewhere because I'm blowing unchecked limits... In looking at the code, all of the Primitives.java functions I sampled seemed to accept arbitrarily large numbers of arguments and handled this by allocating memory (as it should be). So, instead of fixing ABCL to actually honor those limits, which is a step backwards IMHO, I propose raising them to much larger values, like 2^32 or whatever true and real value they should have. Is there any reason why this can't be done? Like large allocated tables that I missed in the code, etc, etc, etc? Thank you! -pete

1 0

Hi, problem with building ABCL extension for MIT App Inventor
by Tomislav Tomšić 26 Aug '17

26 Aug '17

Greetings, currently I am building extension for AI, as indicated in title. It works for Scheme (JScheme and Kawa). It is quite a simply one, for now, I am only interested in evaluating simple symbolic expression, and then build on that, adding other features etc. However, I would also like to have access to Common Lisp, ergo ABCL. Here is a code for its respective method: @SimpleFunction(description = "ABCL evaluation") public String ABCLEvaluation(String expression) { // Environment.getInstance(true); // Interpreter abclInterpreter = Interpreter.createInstance(); // Interpreter.createInstance(); // LispObject evalResult = Interpreter.evaluate(expression); Interpreter interpreter = Interpreter.createInstance(); LispObject lo= interpreter.eval(expression); return lo.getStringValue(); } Commented code is there for completion sake, just as an indication that I tried everything I could find in documentation and examples. Nothing works. As you see, idea is a simple one, String is received, and then evaluated, except that in the case of ABCL it isn't. For JScheme and Kawa logic is precisely the same, environment/interpreter is initialized, expression is evaluated and then it returns the correct result. After playing with the various code combinations, there are always just two errors present in logs, so here they are: First one: W/System.err(20761): java.lang.NullPointerException: Attempt to invoke virtual method 'org.armedbear.lisp.LispObject org.armedbear.lisp.Interpreter.eval(java.lang.String)' on a null object reference W/System.err(20761): at lisp.tomislavt.ext.LispEvaluation.ABCLEvaluation(LispEvaluation.java:46) W/System.err(20761): at java.lang.reflect.Method.invoke(Native Method) W/System.err(20761): at java.lang.reflect.Method.invoke(Method.java:372) W/System.err(20761): at gnu.expr.PrimProcedure.apply(PrimProcedure.java:285) W/System.err(20761): at gnu.mapping.CallContext.runUntilDone(CallContext.java:234) W/System.err(20761): at gnu.mapping.CallContext.runUntilValue(CallContext.java:298) W/System.err(20761): at gnu.mapping.MethodProc.applyN(MethodProc.java:113) W/System.err(20761): at gnu.kawa.reflect.Invoke.applyN(Invoke.java:193) W/System.err(20761): at gnu.kawa.functions.ApplyToArgs.applyN(ApplyToArgs.java:139) W/System.err(20761): at gnu.kawa.functions.Apply.applyN(Apply.java:70) W/System.err(20761): at gnu.mapping.ProcedureN.apply2(ProcedureN.java:39) W/System.err(20761): at com.google.youngandroid.runtime.callComponentMethod(runtime1661793284635134238.scm:879) W/System.err(20761): at appinventor.ai_test.AbclKawaTest.Screen1.Abcl$Click(Screen1.yail:68) W/System.err(20761): at appinventor.ai_test.AbclKawaTest.Screen1$frame.apply0(Screen1.yail:456) W/System.err(20761): at gnu.expr.ModuleBody.applyN(ModuleBody.java:226) W/System.err(20761): at gnu.expr.ModuleMethod.applyN(ModuleMethod.java:216) W/System.err(20761): at gnu.kawa.functions.ApplyToArgs.applyN(ApplyToArgs.java:139) W/System.err(20761): at gnu.kawa.functions.Apply.applyN(Apply.java:70) W/System.err(20761): at gnu.mapping.ProcedureN.apply2(ProcedureN.java:39) W/System.err(20761): at appinventor.ai_test.AbclKawaTest.Screen1.dispatchEvent(Screen1.yail:10121) W/System.err(20761): at com.google.appinventor.components.runtime.EventDispatcher.delegateDispatchEvent(EventDispatcher.java:220) W/System.err(20761): at com.google.appinventor.components.runtime.EventDispatcher.dispatchEvent(EventDispatcher.java:198) W/System.err(20761): at com.google.appinventor.components.runtime.Button.Click(Button.java:51) W/System.err(20761): at com.google.appinventor.components.runtime.Button.click(Button.java:43) W/System.err(20761): at com.google.appinventor.components.runtime.ButtonBase.onClick(ButtonBase.java:656) W/System.err(20761): at android.view.View.performClick(View.java:4848) W/System.err(20761): at android.view.View$PerformClick.run(View.java:20262) W/System.err(20761): at android.os.Handler.handleCallback(Handler.java:815) W/System.err(20761): at android.os.Handler.dispatchMessage(Handler.java:104) W/System.err(20761): at android.os.Looper.loop(Looper.java:194) W/System.err(20761): at android.app.ActivityThread.main(ActivityThread.java:5631) W/System.err(20761): at java.lang.reflect.Method.invoke(Native Method) W/System.err(20761): at java.lang.reflect.Method.invoke(Method.java:372) W/System.err(20761): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:959) W/System.err(20761): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:754) I/RuntimeErrorAlert(20761): in alert Second one: W/System.err(26401): Unable to determine LISP_HOME. W/System.err(26401): Unable to determine LISP_HOME. W/System.err(26401): org.armedbear.lisp.IntegrityError W/System.err(26401): at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) W/System.err(26401): at org.armedbear.lisp.Primitive.execute(Primitive.java:113) W/System.err(26401): at org.armedbear.lisp.Symbol.execute(Symbol.java:803) W/System.err(26401): at org.armedbear.lisp.Lisp.error(Lisp.java:383) W/System.err(26401): at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) W/System.err(26401): at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) W/System.err(26401): at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) W/System.err(26401): at lisp.tomislavt.ext.LispEvaluation.ABCLEvaluation(LispEvaluation.java:48) W/System.err(26401): at java.lang.reflect.Method.invoke(Native Method) W/System.err(26401): at java.lang.reflect.Method.invoke(Method.java:372) W/System.err(26401): at gnu.expr.PrimProcedure.apply(PrimProcedure.java:285) W/System.err(26401): at gnu.mapping.CallContext.runUntilDone(CallContext.java:234) W/System.err(26401): at gnu.mapping.CallContext.runUntilValue(CallContext.java:298) W/System.err(26401): at gnu.mapping.MethodProc.applyN(MethodProc.java:113) W/System.err(26401): at gnu.kawa.reflect.Invoke.applyN(Invoke.java:193) W/System.err(26401): at gnu.kawa.functions.ApplyToArgs.applyN(ApplyToArgs.java:139) W/System.err(26401): at gnu.kawa.functions.Apply.applyN(Apply.java:70) W/System.err(26401): at gnu.mapping.ProcedureN.apply2(ProcedureN.java:39) W/System.err(26401): at com.google.youngandroid.runtime.callComponentMethod(runtime284371300273757224.scm:879) W/System.err(26401): at appinventor.ai_test.AbclKawaTest3.Screen1.Abcl$Click(Screen1.yail:68) W/System.err(26401): at appinventor.ai_test.AbclKawaTest3.Screen1$frame.apply0(Screen1.yail:456) W/System.err(26401): at gnu.expr.ModuleBody.applyN(ModuleBody.java:226) W/System.err(26401): at gnu.expr.ModuleMethod.applyN(ModuleMethod.java:216) W/System.err(26401): at gnu.kawa.functions.ApplyToArgs.applyN(ApplyToArgs.java:139) W/System.err(26401): at gnu.kawa.functions.Apply.applyN(Apply.java:70) W/System.err(26401): at gnu.mapping.ProcedureN.apply2(ProcedureN.java:39) W/System.err(26401): at appinventor.ai_test.AbclKawaTest3.Screen1.dispatchEvent(Screen1.yail:10121) W/System.err(26401): at com.google.appinventor.components.runtime.EventDispatcher.delegateDispatchEvent(EventDispatcher.java:220) W/System.err(26401): at com.google.appinventor.components.runtime.EventDispatcher.dispatchEvent(EventDispatcher.java:198) W/System.err(26401): at com.google.appinventor.components.runtime.Button.Click(Button.java:51) W/System.err(26401): at com.google.appinventor.components.runtime.Button.click(Button.java:43) W/System.err(26401): at com.google.appinventor.components.runtime.ButtonBase.onClick(ButtonBase.java:656) W/System.err(26401): at android.view.View.performClick(View.java:4848) W/System.err(26401): at android.view.View$PerformClick.run(View.java:20262) W/System.err(26401): at android.os.Handler.handleCallback(Handler.java:815) W/System.err(26401): at android.os.Handler.dispatchMessage(Handler.java:104) W/System.err(26401): at android.os.Looper.loop(Looper.java:194) W/System.err(26401): at android.app.ActivityThread.main(ActivityThread.java:5631) W/System.err(26401): at java.lang.reflect.Method.invoke(Native Method) W/System.err(26401): at java.lang.reflect.Method.invoke(Method.java:372) W/System.err(26401): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:959) W/System.err(26401): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:754) I/System.out(26401): ERROR placeholder called with arguments: I/System.out(26401): Failed to find loadable system file 'boot.lisp' in boot classpath. I/System.out(26401): Failed to find loadable system file 'boot.lisp' in boot classpath. W/System.err(26401): org.armedbear.lisp.IntegrityError W/System.err(26401): at org.armedbear.lisp.Primitives$pf_error.execute(Primitives.java:1577) W/System.err(26401): at org.armedbear.lisp.Primitive.execute(Primitive.java:113) W/System.err(26401): at org.armedbear.lisp.Symbol.execute(Symbol.java:803) W/System.err(26401): at org.armedbear.lisp.Lisp.error(Lisp.java:383) W/System.err(26401): at org.armedbear.lisp.Load.loadSystemFile(Load.java:322) W/System.err(26401): at org.armedbear.lisp.Interpreter.initializeLisp(Interpreter.java:172) W/System.err(26401): at org.armedbear.lisp.Interpreter.createInstance(Interpreter.java:72) W/System.err(26401): at lisp.tomislavt.ext.LispEvaluation.ABCLEvaluation(LispEvaluation.java:48) W/System.err(26401): at java.lang.reflect.Method.invoke(Native Method) W/System.err(26401): at java.lang.reflect.Method.invoke(Method.java:372) W/System.err(26401): at gnu.expr.PrimProcedure.apply(PrimProcedure.java:285) W/System.err(26401): at gnu.mapping.CallContext.runUntilDone(CallContext.java:234) W/System.err(26401): at gnu.mapping.CallContext.runUntilValue(CallContext.java:298) W/System.err(26401): at gnu.mapping.MethodProc.applyN(MethodProc.java:113) W/System.err(26401): at gnu.kawa.reflect.Invoke.applyN(Invoke.java:193) W/System.err(26401): at gnu.kawa.functions.ApplyToArgs.applyN(ApplyToArgs.java:139) W/System.err(26401): at gnu.kawa.functions.Apply.applyN(Apply.java:70) W/System.err(26401): at gnu.mapping.ProcedureN.apply2(ProcedureN.java:39) W/System.err(26401): at com.google.youngandroid.runtime.callComponentMethod(runtime284371300273757224.scm:879) W/System.err(26401): at appinventor.ai_test.AbclKawaTest3.Screen1.Abcl$Click(Screen1.yail:68) W/System.err(26401): at appinventor.ai_test.AbclKawaTest3.Screen1$frame.apply0(Screen1.yail:456) W/System.err(26401): at gnu.expr.ModuleBody.applyN(ModuleBody.java:226) W/System.err(26401): at gnu.expr.ModuleMethod.applyN(ModuleMethod.java:216) W/System.err(26401): at gnu.kawa.functions.ApplyToArgs.applyN(ApplyToArgs.java:139) W/System.err(26401): at gnu.kawa.functions.Apply.applyN(Apply.java:70) W/System.err(26401): at gnu.mapping.ProcedureN.apply2(ProcedureN.java:39) W/System.err(26401): at appinventor.ai_test.AbclKawaTest3.Screen1.dispatchEvent(Screen1.yail:10121) W/System.err(26401): at com.google.appinventor.components.runtime.EventDispatcher.delegateDispatchEvent(EventDispatcher.java:220) W/System.err(26401): at com.google.appinventor.components.runtime.EventDispatcher.dispatchEvent(EventDispatcher.java:198) W/System.err(26401): at com.google.appinventor.components.runtime.Button.Click(Button.java:51) W/System.err(26401): at com.google.appinventor.components.runtime.Button.click(Button.java:43) W/System.err(26401): at com.google.appinventor.components.runtime.ButtonBase.onClick(ButtonBase.java:656) W/System.err(26401): at android.view.View.performClick(View.java:4848) W/System.err(26401): at android.view.View$PerformClick.run(View.java:20262) W/System.err(26401): at android.os.Handler.handleCallback(Handler.java:815) W/System.err(26401): at android.os.Handler.dispatchMessage(Handler.java:104) W/System.err(26401): at android.os.Looper.loop(Looper.java:194) W/System.err(26401): at android.app.ActivityThread.main(ActivityThread.java:5631) W/System.err(26401): at java.lang.reflect.Method.invoke(Native Method) W/System.err(26401): at java.lang.reflect.Method.invoke(Method.java:372) W/System.err(26401): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:959) W/System.err(26401): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:754) I hope that I am missing something obvious :), and I am thankful in advance for any input, advice or idea. Some additional clarification may be in order, MIT App Inventor is environment for rapid development of applications for Android (Arduino, Lego mindstorm etc.), hence it doesn't follow usual Android work-flow. Backbone of it is Kawa, components, extensions are written in Java, but more about it can be easily find on its webpage. First log example is fairly useless one imo, when i tested my extension with simple App, same expression was evaluated correctly in both Kawa and JScheme, so that String was not a null one, but I've put it here for completion sake. For the second one I've find something similar for version a.1 or 1.2, back in 2012, I believe, and it was something about dynamic linking during the build process. I am using ABCL 1.5 jar that I downloaded from the ABCL project page. In any case, I am bit at loss, and thus, I would appreciate any advice what should I try next. Thank you for your time. Respectfully, Tomislav Tomsic

2 1

ASDF Issue with compiler warnings on ABCL
by Robert Goldman 18 Aug '17

18 Aug '17

ASDF wraps its compilation process with WITH-COMPILATION-UNIT. On at least some implementations, this is necessary so that building doesn't emit spurious undefined function (variable, etc.) warnings. However, on ABCL, using WITH-COMPILATION-UNIT has the side effect of causing warnings to be intercepted and handled by HANDLE-WARNING. Then it seems that *resignal-compiler-warnings* is bound to NIL, and the compiler swallows them, instead of allowing them to flow down the stack to ASDF's handlers. In turn, this causes at least some of our regression tests to fail, because they check for expected warnings. This looks to me like a bug, but perhaps it's a feature ;-) Would you please explain and let us know how to handle this? thanks, r

2 2

Directory and wild pathnames.
by Mark Cox 24 Jul '17

24 Jul '17

G'day all, The following code signals an error in ABCL 1.5.0 on OS X 10.10.5. [1] CL-USER(1): (directory (merge-pathnames (make-pathname :directory '(:relative :wild)) (user-homedir-pathname))) #<THREAD "interpreter" {590C3415}>: Debugger invoked on condition of type TYPE-ERROR The value NIL is not of type (OR PATHNAME STRING FILE-STREAM SYSTEM:JAR-STREAM SYSTEM:URL-STREAM). Any help would be appreciated. Thanks Mark Cox

2 1

Putative abcl-1.5.0 release plan
by Mark Evenson 21 Jul '17

21 Jul '17

In the "gee that took a lot longer than expected", I'd like to announce my rough plan to release abcl-1.5.0 in the next week. The biggest change in the implementation will be the dropping of Java 5 support since there is no longer a freely redistributable JDK5 implementation (it went with the Sun set…) to run the GPL'd ABCL upon. We will endeavor to ensure that Java 6 continues to be supported as long as the openjdk6 is actively maintained. As always, comments and patches solicited. Yers in CONS, Mark >From <http://abcl.org/trac/milestone/1.5.0>: Milestones ========== Drop Java 5; ensure Java [678] work well. ABCL-CONTRIB ------------ ABCL-BUILD Unified build system (using UIOP; able to install and use Ant, Maven, and others via interactive restarts) ABCL-INTROSPECT Vastly improved support for Java object introspection (Used via as yet unreleased SLIME patches https://github.com/easye/slime.git) CL:DISASSEMBLE works "out of the box" with JAD (if installed on PATH), or Objectweb ABCL-AIO Package arbitrary run-time dependencies (both Java and Lisp) in 'abcl-aio.jar' for customized deployment scenarios ABCL-CONTRIB semantics described (UNIMPLEMENTED) Bootstrap the config mechanism across the network if a local abcl-contrib source tree cannot be located. JSS optimizations & features to support dynamic introspection ABCL-ASDF Robust Maven support -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 4

How to call System.getProperty("user.home") from ABCL
by Mirko Vukovic 21 Jun '17

21 Jun '17

Hello, after a recent update of my company Windows 10 laptop, ABCL 1.4 is landing me in an incorrect home directory. Before I contact our support I would like to investigate the problem a bit more. This is how far I got: (user-homedir-pathname) returns #P"C:/WINDOWS/system32/config/systemprofile/" I wrote a little Java snippet to test "user.home" public class UserHome { public static void main(String[] args) { System.out.println(System.getProperty("user.home")); } } and it returns, correctly, "C:\Users\977315" I don't know how to call System.getProperty("user.home") from ABCL. I have multiple Java's on my laptop, and I need to doublecheck that my tests are self-consistent. But in the meantime, how do I call System.getProperty? Thanks, Mirko

4 8

ABCL User Question about following HTTP redirects for CL:OPEN on EXT:PATHNAME-URL references?
by Mark Evenson 04 Jun '17

04 Jun '17

Alan Ruttenberg from <http://abcl.org/trac/ticket/432>: So if you want to do something like use uiop/stream:copy-file which does something like open the source, open the dest, read/write, it will not do what you might expect. I don't see a way of controlling this behavior. Arguably the default ought to be to follow redirects and open the redirected-to file. I replied: ABCL-BUILD now uses uiop/steam:copy-file for the machinery which retreives XDG rooted Ant and Maven installations from well-known URIs c.f. <http://abcl.org/trac/browser/trunk/abcl/contrib/abcl-build/build/install.li…>, so the underlying ext:pathname-url implementation on java.net.HTTPUrlConnection seems to be working for cases in which the URI is already canonical in the form that would be idempotent for following across HTTP 3xx redirects. WORKAROUND: The current usage expected of the user is to introspect any reference to a ext:pathname-url via CL:TRUENAME. If there is an underlying redirect, CL:TRUENAME should somehow offer an API to the user to customize its behavior. I am currently against "jumping" across URI schema changes without a chance for user intervention. Smells like another restart to me. What would the current users of Armed Bear to do: automatically follow all HTTP retrieval redirects without regards to security concerns, or follow the current policy of doing "whatever ORCL thinks is right for java.net.HTTPUrlConnection"? -- "No, this is not a disentanglement, but a progressive /knotting-into/."

1 0

How to load the jna jar file before cffi?
by Mirko Vukovic 26 May '17

26 May '17

Hello, In order for CFFI to load, I need to load jna-4.2.2.jar. Right now, I have to do something like this: (let ((jar-pathname #P"c:/Users/977315/.m2/repository/net/java/dev/jna/jna/4.2.2/jna-4.2.2.jar")) (java:add-to-classpath (namestring jar-pathname))) To automate loading of ASDFs that require CFFI I tried to automate the process by adding a before method to 'load-op: (eval-when (:compile-toplevel :execute :load-toplevel) (defmethod operate :before ((operation (eql 'asdf/lisp-action:load-op)) (component (eql :cffi))) (let ((jar-pathname #P"c:/Users/977315/.m2/repository/net/java/dev/jna/jna/4.2.2/jna-4.2.2.jar")) (java:add-to-classpath (namestring jar-pathname))))) That did not work. I did read the ASDF manual, but could not figure out how to do it. I suspect someone has figured out the right way. What is it? Thanks, Mirko

3 8

Maven and ABCL
by Alan Ruttenberg 25 May '17

25 May '17

I'm using :mvn ASDF components and ran into a problem with having multiple versions of the same library. The issue boils down to the fact that ABCL currently processes dependencies for :mvn components one at a time, which doesn't take into account mutual dependencies. Attached is a function resolve-multiple-maven-dependencies, which takes a set of maven components and computes the dependencies. As an example, here is a comparison of treating the dependencies individually vs at once. (length (mapcan 'resolve-multiple-maven-dependencies '(("net.sourceforge.owlapi:owlapi-distribution:4.2.6") ("net.sourceforge.owlapi:org.semanticweb.hermit:1.3.8.413") ("org.semanticweb.elk/elk-reasoner/0.4.3") ("net.sourceforge.owlapi/pellet-cli-ignazio1977/2.4.0-ignazio1977") ("net.sourceforge.owlapi/owlexplanation/2.0.0")))) -> 210 (length (mapcan 'resolve-multiple-maven-dependencies '(("net.sourceforge.owlapi:owlapi-distribution:4.2.6" "net.sourceforge.owlapi:org.semanticweb.hermit:1.3.8.413" "org.semanticweb.elk/elk-reasoner/0.4.3" "net.sourceforge.owlapi/pellet-cli-ignazio1977/2.4.0-ignazio1977" "net.sourceforge.owlapi/owlexplanation/2.0.0")))) -> 90 In particular there are several versions of owlapi-distribution that are put on the classpath. Which one is actually used is not easily predictable. In my case even though I specified version 4.2.6 in my system definition, 4.1.3 was actually used. The attached code also has features not yet supported by the :mvn syntax that are really needed: The ability to override versions of a particular dependency that a downstream dependency specifies, and the ability to exclude certain artifacts altogether. Mark has suggested that the maven resolution could be moved to the ASDF planning stage, which sounds like a good idea. However there is still an issue regarding maven dependencies in different loaded ASDF systems. One idea is to remember dependencies across systems and then uses them as constraints on subsequent maven resolutions. Comments and ideas would be appreciated. Alan

3 11

sys:run-program errs on first invocation, works afterwards
by Mirko Vukovic 24 May '17

24 May '17

On Windows 10, ABCL 1.4.0 sys:run-program first issues an error. With abcl --no-init, the first call goes like this: (sys:run-program "where.exe" '("mvn.bat")) Error message: Class not found: java.lang.UNIXProcess [Condition of type ERROR] ... 48: (JCLASS "java.lang.UNIXProcess") 49: (SYSTEM::GET-FASL-FUNCTION #<org.armedbear.lisp.FaslClassLoader org.armedbear.lisp.FaslClassLoad.... {445C74}> 48) 50: (SYSTEM:INIT-FASL :VERSION 42) 51: (SYSTEM::%EVAL (SYSTEM:RUN-PROGRAM "where.exe" '("mvn.bat"))) Repeating the command the second time, and parsing the output (as done in abcl-asdf:find-mvn) gives the expected result. Mirko

1 0

Finding abcl-contrib packages inside a JAR: approach and suggestions
by Frederico Munoz 30 Apr '17

30 Apr '17

Hello, I'm almost done with my small experiment: * I'm loading lisp code via a Java file using Load.loadSystemFile in an init method * I'm adding the file file to *lisp-home* via gradle * I'm using gradle tasks to create a single JAR with abcl and abcl-contrib added (not as JAR files) Note that I need to have only one jar file and with specific requirements around the main method; the above allows me to have it working fine, a single JAR which is essentially standalone. My only remaining doubt (apart from other possible solutions which could also work and be more elegant, I'm open to suggestions of course) is around loading abcl-contrib.jar or more specifically the included packages (JSS and JFLI specifically). I've spent some hours tracking the loading mechanism and learned a bit about the process but I'm still missing some pieces. My current solution (which works) is: (require :abcl-contrib) (pushnew (make-pathname :device (pathname-device *lisp-home*) :directory '(:absolute "jss")) asdf:*central-registry*) (require :jss) This adds #P"jar:file:/foo/myapp.jar!/jss" to ASDF, but I would like something more direct. With my setup (system::find-contrib) returns NIL; I've tried to add the abcl-contrib.jar to myapp.jar (which is in the CLASSPATH of course) but the code on abcl-contrib.lisp (and specifically find-contrib) doesn't seem to seach inside a jar for another one. I also tried to use something like (system::add-contrib (make-pathname :device (pathname-device *lisp-home*) :directory '(:absolute "abcl-contrib.jar"))) to see if it would pick up the jar but no luck. I think there is something obvious I'm missing, the pieces are all there (the jar handling code works fine, etc) but I can't seem to find the right way to put them together. Best regards, -- fsmunoz(a)sdf.org SDF Public Access UNIX System - http://sdf.org

2 2

disabling debugger in production
by Vibhu Mohindra 26 Apr '17

26 Apr '17

I'm bundling up a program for distribution to customers. I don't want it to ever enter the debugger. I want it to raise Java exceptions instead. What I've written to achieve this follows. I've observed it working. However, there are still times when my program enters the debugger. I can't tell why, and want to prevent it entirely. Does anybody know? Does anyone on this list distribute ABCL applications to end users, and how do you disable the debugger? /* disable the debugger. raise a RuntimeException instead */ static void installDebuggerHook() { Symbol.DEBUGGER_HOOK .setSymbolValue(new Function() { public LispObject execute(LispObject c, LispObject h) { throw translateCondition(c);}}); } static RuntimeException translateCondition(LispObject c) { return new RuntimeException( c instanceof Condition ? String.format("%s: %s", c.princToString(), ((Condition) c).getConditionReport()) : c.princToString()); } My program is really a Lisp library that people will use via a thin Java layer. I have a hunch that the above takes care of errors that occur in: interpreter.eval("...") but not errors that occur in: someSymbol.execute(...) Thanks in advance, Vibhu

1 2

"Don't know how to REQUIRE JSS" when loading Lisp code from Java
by Frederico Munoz 25 Apr '17

25 Apr '17

Hello, I'm using the following code to execute a Lisp function: #+BEGIN_SRC java public class Call { public static void main(String [] args) { Call thisObject = new Call(); Interpreter interpreter = Interpreter.createInstance(); interpreter.eval("(load \"lispfunctions.lisp\")"); org.armedbear.lisp.Package defaultPackage = Packages.findPackage("CL-USER"); Symbol voidsym = defaultPackage.findAccessibleSymbol("SAY-HELLO"); Function voidFunction = (Function) voidsym.getSymbolFunction(); LispObject result = voidFunction.execute(new JavaObject(thisObject)); } } #+END_SRC The Lisp side: #+BEGIN_SRC lisp ;;; lispfunctions.lisp (java:add-to-classpath "/opt/abcl-bin-1.4.0/abcl-contrib.jar") (require :jss) (defun say-hello () "Hi!") #+END_SRC It works without the (requirese :jss); whenever I try to use it I get: #<THREAD "main" {C7BBB6C0}>: Debugger invoked on condition of type SIMPLE-ERROR Don't know how to REQUIRE JSS. Any pointers? Thanks! -- fsmunoz(a)sdf.org SDF Public Access UNIX System - http://sdf.org

2 2

Getting a Java class from Function.execute (LispObject introspection)
by Frederico Munoz 25 Apr '17

25 Apr '17

Hello, I'm experimenting with compiling some code using javac and the following example: https://github.com/slyrus/abcl/blob/master/examples/pure-lisp-to-java/Main.… I have one doubt regarding LispObject (what we get from Function.execute): I have read some introspection in the manual but my use-case is slightly different since the I will use the return value of the Lisp call and that value is actually a Java class (from a non-standard library which I use) that will be the return value of the main method of the Main class. Is this feasible? Perhaps I'm missing something obvious, especially since my Java is hardly the strongest. Best regards, -- fsmunoz(a)sdf.org SDF Public Access UNIX System - http://sdf.org

1 1

CFFI on Windows does not load sqlite3.dll
by Mirko Vukovic 24 Apr '17

24 Apr '17

Hello, This is on Windows 10, Armed Bear Common Lisp 1.4.0, Java 1.7.0_51 Oracle Corporation I am trying to link to sqlite3.dll with CFFI (as required by the cl-dbi package) I have jna installed in my home directory under ~/.m2/... and cffi loads cleanly as does cl-dbi. Note that the ~/.m2/.../jna-4.2.2.jar is not in my classpath. Instead I added it via (java:add-to-classpath ...) (cffi:load-foreign-library "c:/Program Files/sqlite/sqlite3.dll") gives an error (shown below). I also tried by adding the directory to cffi:*foreign-library-directoris*, and then calling (cffi:load-foreign-library "sqlite3.dll"). The error message is: Unable to load foreign library (SQLITE3.DLL-30929). Unable to load library 'C:/Program Files/sqlite/sqlite3.dll': Native library (win32-x86/C:/Program Files/sqlite/sqlite3.dll) not found in resource path ([file:/C:/mv-program-files/abcl-bin-1.4.0/, file:/C:/mv-program-files/abcl-bin-1.4.0/abcl.jar]) Questions: 1. What is the implication of the win32-x86 prefix to the path in the error message? Is that a 32/64 bit incompatibility? 2. I don't understand the part of the error message referring to the resource path 3. while CFFI does compile, do I have somehow to load JNA explicitly. In other words, is (ql:qload ...) enough, or do I need to do something else to activate JNA? 4. Does CFFI work on Windows (since Java is cross-platform, I would expect it to)? (My Java knowledge is epsilon where epsilon appraches 0, although I plan to work on this if I continue using ABCL to interface to Java libraries) Thank you, Mirko

2 2

Watson IoT MQTT with ABCL (dW recipe)
by Frederico Munoz 23 Apr '17

23 Apr '17

Hello all, Following my previous experiences with using Eclipe Paho with ABCL I wrote a more step-by-step tutorial that uses MQTT to send data to IBM's Watson IoT Platform. https://developer.ibm.com/recipes/tutorials/watson-iot-with-common-lisp/ It uses Quicklisp and tries to show to those who do not know ABCL the basics of what is possible. I'm sure there are some incorrections here and there but still, thought it would be interesting. The audience is the general community much more than those already acquainted with ABCL. Best regards -- fsmunoz(a)sdf.org SDF Public Access UNIX System - http://sdf.org

1 0

patch for bug 443 (ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument)
by Robert Dodier 17 Apr '17

17 Apr '17

Hi, here is a patch to fix bug 443. With this change, Maxima + ABCL passes its tests (in tests/rtest11.mac for the record) for parse_timedate which calls ENCODE-UNIVERSAL-TIME. Incidentally this patch also fixes an unreported bug in DECODE-UNIVERSAL-TIME: the daylight saving flag is reported incorrectly because EXT:GET-TIME-ZONE expects its argument in milliseconds, not seconds. I can't sign in to the bug tracker as the OpenID button doesn't work and I don't remember my common-lisp.net username/password and I don't see a way to get a password reminder on common-lisp.net. A comment on the bug tracker mentions Java 8. If I remember correctly, I tried the previous version of the code with both Java 7 and Java 8 and in both cases it fails. In any event the error seems to be pretty clearly a mistake in ENCODE-UNIVERSAL-TIME so I would be surprised if different Java versions yielded different results. Hope this helps, and all the best. Robert Dodier PS. This patch was taken against r14981 on armedbear-svn/trunk.

3 4

Help me get a Java object's name
by Mirko Vukovic 15 Apr '17

15 Apr '17

Hello, I am using the Apache POI library to read Excel files. The following is from within Slime. I am struggling to extract cell types as returned by getCellTypeEnum ( https://poi.apache.org/apidocs/org/apache/poi/ss/usermodel/Cell.html#getCel… ()) My code returns a Java Object like so: #<org.apache.poi.ss.usermodel.CellType FORMULA {5C25A9}> It is of class #<java class org.apache.poi.ss.usermodel.CellType> I would like to grab the "FORMULA" in the above object description. Slime can see it, it's inspector can see it, even DESCRIBE can see it: READER> (describe *) #<org.apache.poi.ss.usermodel.CellType FORMULA {11CC24A}> is an object of type JAVA-OBJECT. The wrapped Java object is an instance of org.apache.poi.ss.usermodel.CellType: "FORMULA" But, I could not figure out a way to get to "FORMULA". I tried to accessing the slot `name' but that does not work. I looked at the FFI page, but found no clues. I tried to get slot names via AMOP: (mop:class-direct-slots (class-of java-cell-type)) returns NIL It must be something simple that I am overlooking. Help is appreciated. Thanks! Mirko

2 2

Easy Maven publishing for GitHub projects
by Alessio Stalla 29 Mar '17

29 Mar '17

FYI, if you're interested, I've just stepped on this: https://jitpack.io/

1 0

bug report: ENCODE-UNIVERSAL-TIME effectively ignores TIME-ZONE argument
by Robert Dodier 23 Mar '17

23 Mar '17

A contributor to the Maxima project bumped into this while trying Maxima + ABCL 1.4.0. CL-USER(1): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -23) 3017516508 CL-USER(2): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 -13) 3017516508 CL-USER(3): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 13) 3017516508 CL-USER(4): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 23) 3017516508 CL-USER(5): (ENCODE-UNIVERSAL-TIME 48 1 15 15 8 1995 'foo) 3017516508 Not too surprising, I think -- a glance at ./src/org/armedbear/lisp/time.lisp shows that the TIME-ZONE argument doesn't take part in the calculations. TIME-ZONE does come into play in pre-14840 versions of time.lisp and the results are consistent with other CL implementations, at least for the examples exercised by the Maxima test suite (date parsing). Tried to submit a bug report via Trac but when I clicked on the OpenID button I get a connection reset error. Thanks for all your efforts, I appreciate it. Robert Dodier

2 1

integration with java's threading
by Devon Miller 13 Mar '17

13 Mar '17

I saw that Bordeaux threads uses a very thin layer of java threads in their abcl implementation file. I wanted to use some libraries from java that use threading fairly heavily (web apis) and was wondering if there had been good testing with exchanging data from the lisp layer to the java layer when threading is heavily used in the java layer. For example, passing xml and json s-expr into java for processing and sending out through a multi-threaded environment i.e. akka actors.

2 1

[CfPart] 10th European Lisp Symposium, Apr 3-4 2017, Brussels
by Didier Verna 03 Mar '17

03 Mar '17

ELS'17 - 10th European Lisp Symposium VUB - Vrije Universiteit Brussel Belgium April 3-4, 2017 In co-location with <Programming> 2017 Sponsors: Brunner Software GmbH, Franz Inc., LispWorks Ltd. and EPITA http://www.european-lisp-symposium.org/ Recent news: - Invited speakers announced (see below) - Registration open. Don't miss the March 13 deadline for the full <Programming> conference early bird discount! 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. Keynote speakers: - Hans Hübner -- Identity in a World of Values - Bohdan B. Khomtchouk -- How the Strengths of Lisp Facilitate Building Complex and Flexible Bioinformatics Applications Important dates: - 13 Mar 2017 Early registration deadline - 03-04 Apr 2017 Symposium - 05-06 Apr 2017 <Programming> main tack Programme chair: Alberto Riva, University of Florida, USA Programme committee: Marco Antoniotti, Università Milano Bicocca, Italy Marc Battyani, FractalConcept Theo D'Hondt, Vrije Universiteit Brussel, Belgium Marc Feeley, Université de Montreal, Canada Erick Gallesio, Université de Nice Sophia-Antipolis, France Stelian Ionescu, Google Rainer Joswig, Independent Consultant, Germany António Menezes Leitão, Technical University of Lisbon, Portugal Nick Levine, RavenPack Henry Lieberman, MIT, USA Mark Tarver, Shen Programming Group Jay McCarthy, University of Massachusetts Lowell, USA Christian Queinnec, Université Pierre et Marie Curie, France François-René Rideau, Bridgewater Associates, USA Nikodemus Siivola, ZenRobotics Ltd Alessio Stalla, Università degli Studi di Genova, Italy Chris Stacy, CS Consulting 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

asdf:defsystem complains about path, sometimes
by Mirko Vukovic 01 Mar '17

01 Mar '17

Hello, This is with asdf 3.1.7.27, Armed Bear Common Lisp 1.4.0 Java 1.6.0_41 Sun Microsystems Inc. OpenJDK 64-Bit Server VM, Emacs & Slime The following example code from the ASDF manual (asdf:defsystem "hello-lisp" :description "hello-lisp: a sample Lisp system." :version "0.0.1" :author "Joe User <joe(a)example.com>" :licence "Public Domain" :depends-on ("optima.ppcre" "command-line-arguments") :components ((:file "packages") (:file "macros" :depends-on ("packages")) (:file "hello" :depends-on ("macros")))) when executed via the ABCL command line gives a relative path error Invalid relative pathname #P"packages.lisp" for component ("hello-lisp" "packages") Restarts: 0: RETRY Retry ASDF operation. 1: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. 2: TOP-LEVEL Return to top level. If that code is in a file, then the file compiles cleanly: CL-USER(6): (load (compile-file "test.asd")) ; Compiling /home/mv/projects/poi+excel/test.asd ... ; (IN-PACKAGE :CL-USER) ; (ASDF/PARSE-DEFSYSTEM:DEFSYSTEM "hello-lisp" ...) ; Wrote /home/mv/projects/poi+excel/test.abcl (0.021 seconds) T CL-USER(7): I am looking for confirmation of this and second opinions before taking up at the ASDF mailing list. Thanks, Mirko

3 4

sys:run-program errs (both Windows & Linux)
by Mirko Vukovic 15 Jan '17

15 Jan '17

While narrowing down the problems I was having with maven and cffi, I came across the maven-embedded.lisp file ( https://common-lisp.net/svn/armedbear/branches/1.4.0/contrib/abcl-asdf/mave… ) where I saw the sys:run-program. I now have ABCL installed on both Linux and Windows, and have problems on both when issuing #+windows(sys:run-program "where.exe" nil) #+linux(sys:run-program "which" nil) On Windows, the first call fails, while the second succeeds. On Linux, the call fails, and repeated calls also fail. Is this just me or can anyone else reproduce this? Thanks. Transcript of the Windows 10 session (Linux follows) P:\>java -jar c:\mv-program-files\abcl-bin-1.4.0\abcl.jar --noinit Armed Bear Common Lisp 1.4.0 Java 1.8.0_112 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.274 seconds. Startup completed in 4.28 seconds. Type ":help" for a list of available commands. CL-USER(1): (sys:run-program "which.exe" nil) ;;; *First invocation results in error* Error loading jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 166 (offset 8688) #<THREAD "interpreter" {6A8B2747}>: Debugger invoked on condition of type ERROR Class not found: java.lang.UNIXProcess ;;; *ERROR* Restarts: 0: TOP-LEVEL Return to top level. [1] SYS(2): 0 java.lang.ExceptionInInitializerError ... Java stack elided Caused by: org.armedbear.lisp.Go Error loading jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl.jar!/org/armedbear/lisp/run-program.abcl at line 166 (offset 8688) #<THREAD "interpreter" {6A8B2747}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.run_program_49 from org.armedbear.lisp.Pathname@60a4bd75 Restarts: 0: TOP-LEVEL Return to top level. [1] SYS(3): 0 CL-USER(4): (sys:run-program "which.exe" nil) ;;; *Second invocation succeeds* #S(SYSTEM:PROCESS :JPROCESS #<java.lang.ProcessImpl java.lang.ProcessImpl@6aaa6218 {2F20252D}> :%INPUT #S(SYSTEM::SYSTEM-STREAM) :%OUTPUT #S(SYSTEM::SYSTEM-STREAM) :%ERROR #S(SYSTEM::SYSTEM-STREAM)) CL-USER(5): On Linux I work through Slime. Here is the startup message on a RedHat EL6. I hope my Java patch is recent enough. Armed Bear Common Lisp 1.4.0 Java 1.6.0_40 Sun Microsystems Inc. OpenJDK 64-Bit Server VM Low-level initialization completed in 0.491 seconds. Startup completed in 2.488 seconds. Using probed value of abcl-contrib: '/usr/local/share/java/abcl-contrib.jar'. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/quicklisp/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/mvn/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/jss/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/jfli/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/asdf-jar/ to ASDF. Added jar:file:/usr/local/share/java/abcl-contrib.jar!/abcl-asdf/ to ASDF. Loading /home/mv/.abclrc completed in 9.644 seconds. Type ":help" for a list of available commands. CL-USER(1): ; Loading /home/sm/software/slime/swank-loader.lisp ... Doing (sys:run-program "which" nil) the error backtrace is: Class not found: java.lang.ProcessBuilder$Redirect [Condition of type ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] Abort thread. Backtrace: 0: (#<FUNCTION {5A18A372}> #<ERROR {47BE45A7}> #<FUNCTION {5A18A372}>) 1: (APPLY #<FUNCTION {5A18A372}> (#<ERROR {47BE45A7}> #<FUNCTION {5A18A372}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<ERROR {47BE45A7}> #<FUNCTION {5A18A372}>) 3: (INVOKE-DEBUGGER #<ERROR {47BE45A7}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Java.classForName(Java.java:1299) 6: org.armedbear.lisp.Java.javaClass(Java.java:1332) 7: org.armedbear.lisp.Java.javaClass(Java.java:1306) 8: org.armedbear.lisp.Java.jfield(Java.java:177) 9: org.armedbear.lisp.Java$pf_jfield.execute(Java.java:272) 10: org.armedbear.lisp.Primitive.execute(Primitive.java:123) 11: (JFIELD "java.lang.ProcessBuilder$Redirect" "INHERIT") 12: (SYSTEM:INIT-FASL :VERSION 42) 13: (SYSTEM::%MAKE-PROCESS-BUILDER "which" NIL) 14: (SYSTEM:RUN-PROGRAM "which" NIL) 15: (SYSTEM::%EVAL (SYSTEM:RUN-PROGRAM "which" NIL)) 16: (EVAL (SYSTEM:RUN-PROGRAM "which" NIL))

2 2

Strange, magical, thing :)
by Marco Antoniotti 13 Jan '17

13 Jan '17

Hi just to point out what happens hitting (or just writing) the following address in you Browser :) (I noticed it because of my CL Ook compiler) ook.common-lisp.net Cheers -- Marco Antoniotti

2 1

Anyone understand the logic of pushJavaStackFrames
by Alan Ruttenberg 09 Jan '17

09 Jan '17

I'm getting backtraces that are noisy and therefore impede comprehension. For example, in the following stack trace, frames 68-4 seem to recapitulate, for the most part, the java stack corresponding to frames 87-69 Thanks, Alan The value CL-UTILS::FORMS is not of type LIST. [Condition of type TYPE-ERROR] Restarts: 0: [RETRY] Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "jnil" "cl-utils">. 1: [ACCEPT] Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "jnil" "cl-utils"> as having been successful. 2: [RETRY] Retry ASDF operation. 3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the configuration. 4: [ABORT] Abort compilation. 5: [*ABORT] Return to SLIME's top level. --more-- Backtrace: 0: (#<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}> #<TYPE-ERROR {D3CDE50}> #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}>) 1: (APPLY #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}> (#<TYPE-ERROR {D3CDE50}> #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}>)) 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<TYPE-ERROR {D3CDE50}> #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}>) 3: (INVOKE-DEBUGGER #<TYPE-ERROR {D3CDE50}>) 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) 5: org.armedbear.lisp.Lisp.type_error(Lisp.java:435) 6: org.armedbear.lisp.LispObject.car(LispObject.java:165) 7: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 8: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 9: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 10: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 11: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 12: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 13: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 14: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 15: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 16: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 17: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 18: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 19: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 20: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 21: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 22: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 23: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 24: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 25: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 26: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 27: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 28: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 29: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 30: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 31: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) 32: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 33: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 34: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 35: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 36: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 37: org.armedbear.lisp.precompiler_73.execute(precompiler.lisp:643) 38: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 39: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 40: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) 41: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 42: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 43: org.armedbear.lisp.precompiler_105.execute(precompiler.lisp:988) 44: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:121) 45: org.armedbear.lisp.Symbol.execute(Symbol.java:826) 46: org.armedbear.lisp.compiler_pass2_362.execute(compiler-pass2.lisp:7380) 47: org.armedbear.lisp.Symbol.execute(Symbol.java:867) 48: org.armedbear.lisp.LispThread.execute(LispThread.java:918) 49: org.armedbear.lisp.compile_file_19.execute(compile-file.lisp:175) 50: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 51: org.armedbear.lisp.LispThread.execute(LispThread.java:832) 52: org.armedbear.lisp.compile_file_51.execute(compile-file.lisp:655) 53: org.armedbear.lisp.Symbol.execute(Symbol.java:826) 54: org.armedbear.lisp.LispThread.execute(LispThread.java:851) 55: org.armedbear.lisp.compile_file_59.execute(compile-file.lisp:780) 56: org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2.lisp:7450) 57: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 58: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 59: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 60: org.armedbear.lisp.compile_file_57.execute(compile-file.lisp:780) 61: org.armedbear.lisp.Symbol.execute(Symbol.java:914) 62: org.armedbear.lisp.LispThread.execute(LispThread.java:986) 63: org.armedbear.lisp.compile_file_68.execute(compile-file.lisp:962) 64: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:150) 65: org.armedbear.lisp.Symbol.execute(Symbol.java:852) 66: org.armedbear.lisp.LispThread.execute(LispThread.java:894) 67: org.armedbear.lisp.Lisp.funcall(Lisp.java:180) 68: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2845) 69: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::KEY . CL-UTILS::FORMS)) 70: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::KEY . CL-UTILS::FORMS)) 71: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::LOOP CL-UTILS::FOR (CL-UTILS::KEY . CL-UTILS::FORMS) CL-UTILS::IN CL-UTILS::CLAUSES CL-UTILS::DO ...)) 72: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::LOOP CL-UTILS::FOR (CL-UTILS::KEY . CL-UTILS::FORMS) CL-UTILS::IN CL-UTILS::CLAUSES CL-UTILS::DO ...)) 73: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::LET ((CL-UTILS::CLAUSE-COLLECTION (CL-UTILS::LIST))) ..)) 74: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::LET ((CL-UTILS::CLAUSE-COLLECTION (CL-UTILS::LIST))) ..)) 75: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) ..)) 76: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) ..)) 77: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..)) 78: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..)) 79: (PRECOMPILER::PRECOMPILE-LAMBDA (LAMBDA NIL ..)) 80: (PRECOMPILER::PRECOMPILE1 (LAMBDA NIL (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) (CL-UTILS::LET # # #))))) 81: (JVM:COMPILE-DEFUN NIL (LAMBDA NIL (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) (CL-UTILS::LET # # #)))) NIL #P"/U.. 82: (SYSTEM::CONVERT-TOPLEVEL-FORM (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..) NIL) 83: (SYSTEM::PROCESS-TOPLEVEL-FORM (CL-UTILS::DEFMACRO CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..) #<FILE-STREAM {1773B7E}> NIL) 84: (JVM::%WITH-COMPILATION-UNIT #<LOCAL-FUNCTION IN COMPILE-FROM-STREAM {1FEBE62E}>) 85: (SYSTEM::COMPILE-FROM-STREAM #<FILE-STREAM {744E75DD}> #P"/Users/lori/.cache/common-lisp/abcl-1.5.0-dev-fasl43-macosx-x64/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils-tmpUYPFRO0B.abcl" #P"/Users/lor.. 86: (COMPILE-FILE #P"/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils.lisp" :OUTPUT-FILE #P"/Users/lori/.cache/common-lisp/abcl-1.5.0-dev-fasl43-macosx-x64/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils-tm.. 87: (APPLY COMPILE-FILE #P"/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils.lisp" :OUTPUT-FILE #P"/Users/lori/.cache/common-lisp/abcl-1.5.0-dev-fasl43-macosx-x64/Volumes/upstairs/repos/jnil/lisp/jnil/cl-ut.. private static final void pushJavaStackFrames() { final LispThread thread = LispThread.currentThread(); final StackTraceElement[] frames = thread.getJavaStackTrace(); // frames[0] java.lang.Thread.getStackTrace // frames[1] org.armedbear.lisp.LispThread.getJavaStackTrace // frames[2] org.armedbear.lisp.Lisp.pushJavaStackFrames if (frames.length > 5 && frames[3].getClassName().equals("org.armedbear.lisp.Lisp") && frames[3].getMethodName().equals("error") && frames[4].getClassName().startsWith("org.armedbear.lisp.Lisp") && frames[4].getMethodName().equals("eval")) { // Error condition arising from within Lisp.eval(), so no // Java stack frames should be visible to the consumer of the stack abstraction return; } // Search for last Primitive in the StackTrace; that was the // last entry point from Lisp. int last = frames.length - 1; for (int i = 0; i<= last; i++) { if (frames[i].getClassName().startsWith("org.armedbear.lisp.Primitive")) last = i; } // Do not include the first three frames which, as noted above, constitute // the invocation of this method. while (last > 2) { thread.pushStackFrame(new JavaStackFrame(frames[last])); last--; } }

3 9

IEEE NaN and Infinities
by Antoniotti Marco 08 Jan '17

08 Jan '17

Hi I am fiddling around with IEEE NaN and Infinities. In LW and CCL you have the following conventions for such things: 1d+-0 is NaN (quiet; double float) 1d++0 is positive infinity (double float) Negative infinities are obtained by prepending ‘-‘ to the positive infinities. Other float lengths can be obtained by using the appropriate ’s’, ‘e’, ‘f’, ‘l’. I tried an (APROPOS “NAN”) and an (APROPOS “INFINITY”) in ABCL, but got nothing. Being myself a lazy bastard, I thought of asking directly here instead of looking at the code :) Any possibility of seeing these in ABCL? Apart from that, there is the issue of “rounding modes”. Would it be possible to add them or access them in ABCL? Thanks Marco -- Marco Antoniotti, Associate Professor tel. +39 - 02 64 48 79 01 DISCo, Università Milano Bicocca U14 2043 http://bimib.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY Please check: http://cdac2017.lakecomoschool.org Please check: https://sites.google.com/site/troncopackage/ Please note that I am not checking my Spam-box anymore. Please do not forward this email without asking me first (cum grano salis).

1 0

Failure to load cffi (again): unable to find maven (again)
by Mirko Vukovic 05 Jan '17

05 Jan '17

Earlier today I was able to load cffi by renaming mvn.cmd to mvn.bat. Later on, I am unable to, and I would appreciate a fresh pair of eyes. (ABCL/Java info: C:\Users\977315>java -jar "c:\mv-program-files\abcl-bin-1.4.0\abcl.jar" Armed Bear Common Lisp 1.4.0 Java 1.8.0_112 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.243 seconds. Startup completed in 3.812 seconds. Loading C:\Users\977315\.abclrc completed in 13.729 seconds.) The error seems to happen in abcl-cffi.lisp. mvn.bat is visible: (uiop/run-program:run-program '("where" "mvn.bat") :output :string) gives "C:\\Program Files\\apache-maven-3.3.9\\bin\\mvn.bat " NIL 0 I don't know how to narrow down the search for the culprit. It makes me think that maybe the error message is not correct - that there is a different underlying cause. Is there some direct way I can test maven+aether? I now next to nothing about Java, and looking at abcl-cffi, I did not find anything obvious. Thanks for your help and patience, Backtrace follows. CL-USER(4): (asdf:load-system :cffi) ; Compiling C:/mv-program-files/my-lisp-libraries/cffi/src/cffi-abcl.lisp ... Using probed value of abcl-contrib: 'C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar'. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/quicklisp/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/mvn/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/jss/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/jfli/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/asdf-jar/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/abcl-asdf/ to ASDF. java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at java.lang.Class.newInstance(Unknown Source) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) ... at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) Caused by: org.armedbear.lisp.Go ; in (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL ...) ...) ; Caught SIMPLE-WARNING: ; Unable to locate Maven executable to find Maven Aether adaptors. jnaASDF could not load because Java exception 'java.lang.ClassNotFoundException: com.sun.jna.Native'.. #<THREAD "interpreter" {49B3491F}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'java.lang.ClassNotFoundException: com.sun.jna.Native'. Restarts: 0: RETRY Retry completing load for #<ASDF/SYSTEM:SYSTEM "jna">. 1: ACCEPT Continue, treating completing load for #<ASDF/SYSTEM:SYSTEM "jna"> as having been successful. 2: RETRY Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl">. 3: ACCEPT Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl"> as having been successful. 4: RETRY Retry ASDF operation. 5: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. 6: TOP-LEVEL Return to top level.

1 1

uiop/run-program:run-program regression after asdf-3.1.7
by Mirko Vukovic 05 Jan '17

05 Jan '17

I try running (uiop/run-program:run-program '("where" "mvn.bat") :output :string) On asdf 3.1.7, it returns the correct output. With asdf 3.1.7.27 and 3.1.7.43. I get an error "Class not found: java.lang.UNIXProcess". If I go to the top level, and try again, I get the correct result. This is with: C:\Users\977315>java -jar "c:\mv-program-files\abcl-bin-1.4.0\abcl.jar" Armed Bear Common Lisp 1.4.0 Java 1.8.0_112 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.238 seconds. Startup completed in 3.973 seconds. Loading C:\Users\977315\.abclrc completed in 14.029 seconds. Type ":help" for a list of available commands. CL-USER(1): The abclrc is minimal: load asdf and load quicklisp: (eval-when (:compile-toplevel :load-toplevel :execute) (let ((file "asdf.3.1.7.43.lisp")) (load (merge-pathnames file (user-homedir-pathname))))) (eval-when (:compile-toplevel :load-toplevel :execute) #-quicklisp (let ((quicklisp-init (merge-pathnames "quicklisp/setup.lisp" (user-homedir-pathname)))) (if (probe-file quicklisp-init) (load quicklisp-init) (error "Did not find ~a ... quicklisp not loaded" "~/quicklisp/setup.lisp")))) I posted this on the ASDF mailing list, and Fare suggested this may be an ABCL-related issue. I hope all the problems I am having have one single root cause - and that we discover it :-)

2 2

Bug in STABLE-SORT on empty vector
by Eric Marsden 05 Jan '17

05 Jan '17

Hello, A bug in STABLE-SORT on empty vectors. CL-USER(1): (lisp-implementation-version) "1.5.0-dev-svn-14939" "OpenJDK_64-Bit_Server_VM-Oracle_Corporation-1.7.0_111-b01" "amd64-Linux-3.2.0-4-amd64" CL-USER(2): (stable-sort #() '<) #<THREAD "interpreter" {7454F875}>: Debugger invoked on condition of type TYPE-ERROR Invalid array index 0 for #() -- Eric Marsden https://risk-engineering.org/

1 0

Errors loading CFFI: BAD-SYSTEM-NAME, missing Maven executable
by Mirko Vukovic 04 Jan '17

04 Jan '17

Loading CFFI, I get BAD-SYSTEM-NAME errors related to followed by a huge stack dump, and then debugger related to the Maven executable. I tested this with --noinit. Thanks for your help. Here are more details: Starting ABCL on Windows 10 like so: >/c/Windows/SysWOW64/java.exe -jar /c/mv-program-files/abcl-bin-1.4.0/abcl.jar Armed Bear Common Lisp 1.4.0 Java 1.7.0_51 Oracle Corporation Java HotSpot(TM) Client VM Low-level initialization completed in 0.23 seconds. Now I try to load cffi with quicklisp. Following quickload, I get many style-warnings about redefining UIOP: CL-USER(1): (ql:quickload :cffi) To load "cffi": Load 1 ASDF system: cffi ; Loading "cffi" .................................................. .................................................. .................................................. .................................................. .................................... ; Caught STYLE-WARNING: ; redefining UIOP/PACKAGE:FIND-PACKAGE* in #P"C:/mv-program-files/my-lisp-libraries/asdf/uiop/package.lisp" (previously defined in #P"C:/Users/977315/asdf.3.1.7.43.lisp") ; Caught STYLE-WARNING: ; redefining UIOP/PACKAGE:FIND-SYMBOL* in #P"C:/mv-program-files/my-lisp-libraries/asdf/uiop/package.lisp" (previously defined in #P"C:/Users/977315/asdf.3.1.7.43.lisp") .... many such warnings ... After finishing the style-warning messages, come ASDF load messages, the BAD-SYSTEM-NAME messages, followed by a long java stack dump: Using probed value of abcl-contrib: 'C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar'. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/quicklisp/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/mvn/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/jss/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/jfli/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/asdf-jar/ to ASDF. Added jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/abcl-asdf/ to ASDF. . ; Caught BAD-SYSTEM-NAME: ; System definition file #P"jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/jss/jss.asd" contains definition for system "jss-tests". Please only define "jss" and secondary systems with a name starting with "jss/" (e.g. "jss/test") in that file. ; Caught BAD-SYSTEM-NAME: ; System definition file #P"jar:file:C:/mv-program-files/abcl-bin-1.4.0/abcl-contrib.jar!/abcl-asdf/abcl-asdf.asd" contains definition for system "abcl-asdf-test". Please only define "abcl-asdf" and secondary systems with a name starting with "abcl-asdf/" (e.g. "abcl-asdf/test") in that file. java.lang.ExceptionInInitializerError at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source) at java.lang.reflect.Constructor.newInstance(Unknown Source) at java.lang.Class.newInstance(Unknown Source) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.ja va:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) ... At the end I get into the ABCL debugger: Caused by: org.armedbear.lisp.Go ; Caught SIMPLE-WARNING: ; Unable to locate Maven executable to find Maven Aether adaptors. jnaASDF could not load because Java exception 'java.lang.ClassNotFoundException: com.sun.jna .Native'.. #<THREAD "interpreter" {472108}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'java.lang.ClassNotFoundException: com.sun.jna.Native'. Restarts: 0: RETRY Retry completing load for #<ASDF/SYSTEM:SYSTEM "jna">. 1: ACCEPT Continue, treating completing load for #<ASDF/SYSTEM:SYSTE M "jna"> as having been successful. 2: RETRY Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" " src" "cffi-abcl">. 3: ACCEPT Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE- FILE "cffi" "src" "cffi-abcl"> as having been successful. 4: RETRY Retry ASDF operation. 5: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. 6: TOP-LEVEL Return to top level.

2 4

[CfP] ELS'17, 10th European Lisp Symposium, April 3-4 2017, Brussels
by Didier Verna 03 Jan '17

03 Jan '17

ELS'17 - 10th European Lisp Symposium VUB - Vrije Universiteit Brussel Belgium April 3-4, 2017 In co-location with <Programming> 2017 Sponsored by Brunner Software GmbH 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. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els17 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. 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: Marco Antoniotti, Università Milano Bicocca, Italy Marc Battyani, FractalConcept Theo D'Hondt, Vrije Universiteit Brussel, Belgium Marc Feeley, Université de Montreal, Canada Stelian Ionescu, Google Rainer Joswig, Independent Consultant, Germany António Menezes Leitão, Technical University of Lisbon, Portugal Nick Levine, RavenPack Henry Lieberman, MIT, USA Mark Tarver, Shen Programming Group Jay McCarthy, University of Massachusetts Lowell, USA Christian Queinnec, Université Pierre et Marie Curie, France François-René Rideau, Bridgewater Associates, USA Nikodemus Siivola, ZenRobotics Ltd Alessio Stalla, Università degli Studi di Genova, Italy 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

Examples of new vs old stacktrace (in slime)
by Alan Ruttenberg 03 Jan '17

03 Jan '17

Here are some examples of new versus old stacktrace. "!" means the frame was in the java exception stacktrace, but are no longer present because the exception was caught #### Generate error with: (#"new" 'bloh) ________________ New stacktrace Java exception 'java.lang.ClassNotFoundException: BLOH'. [Condition of type java-exception] Restarts: 0: [retry] Retry SLIME REPL evaluation request. 1: [*abort] Return to SLIME's top level. 2: [abort] Abort thread. Backtrace: 0: (invoke-debugger #<java:java-exception java.lang.ClassNotFoundException: BLOH {5C19BF31}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:382) 2: ! java.net.URLClassLoader.findClass(URLClassLoader.java:381) 3: ! java.lang.ClassLoader.loadClass(ClassLoader.java:424) 4: ! org.armedbear.lisp.JavaClassLoader.loadClass(JavaClassLoader.java:60) 5: ! java.lang.Class.forName0(Native Method) 6: ! java.lang.Class.forName(Class.java:348) 7: ! java.lang.reflect.Method.invoke(Method.java:497) 8: (java:jstatic #<method public static java.lang.Class java.lang.Class.forName(java.lang.String,boolean,java.lang.ClassLoader) throws java.lang.ClassNotFoundException> "java.lang.Class" "BLOH" #<java.la .. 9: (jss:find-java-class "BLOH") 10: (#"new" common-lisp-user::bloh) 11: (#<anonymous-interpreted-function {7D30E302}> common-lisp-user::bloh) 12: (system::%eval (#"new" 'common-lisp-user::bloh)) 13: (eval (#"new" 'common-lisp-user::bloh)) ________________ Old stacktrace Java exception 'java.lang.ClassNotFoundException: BLOH'. [Condition of type java-exception] Restarts: 0: [retry] Retry SLIME REPL evaluation request. 1: [*abort] Return to SLIME's top level. 2: [abort] Abort thread. Backtrace: 0: (system:backtrace) 1: (system::new-backtrace #<java:java-exception java.lang.ClassNotFoundException: BLOH {48D709DB}>) 2: (#<local-function in make-invoke-debugger-hook {FB48C75}> #<java:java-exception java.lang.ClassNotFoundException: BLOH {48D709DB}> #<local-function in make-invoke-debugger-hook {FB48C75}>) 3: (apply #<local-function in make-invoke-debugger-hook {FB48C75}> (#<java:java-exception java.lang.ClassNotFoundException: BLOH {48D709DB}> #<local-function in make-invoke-debugger-hook {FB48C75}>)) 4: (system::run-hook system::*invoke-debugger-hook* #<java:java-exception java.lang.ClassNotFoundException: BLOH {48D709DB}> #<local-function in make-invoke-debugger-hook {FB48C75}>) 5: (invoke-debugger #<java:java-exception java.lang.ClassNotFoundException: BLOH {48D709DB}>) 6: org.armedbear.lisp.Lisp.error(Lisp.java:382) 7: org.armedbear.lisp.Java.jstatic(Java.java:484) 8: org.armedbear.lisp.Java$pf_jstatic.execute(Java.java:510) 9: org.armedbear.lisp.Primitive.execute(Primitive.java:163) 10: (java:jstatic #<method public static java.lang.Class java.lang.Class.forName(java.lang.String,boolean,java.lang.ClassLoader) throws java.lang.ClassNotFoundException> "java.lang.Class" "BLOH" #<java.la .. 11: (jss:find-java-class "BLOH") 12: (#"new" common-lisp-user::bloh) 13: (#<anonymous-interpreted-function {641792AC}> common-lisp-user::bloh) 14: (system::%eval (#"new" 'common-lisp-user::bloh)) 15: (eval (#"new" 'common-lisp-user::bloh)) ################ Generate error with: (+ 1 nil) ________________ New stacktrace The value nil is not of type number. [Condition of type type-error] Restarts: 0: [retry] Retry SLIME REPL evaluation request. 1: [*abort] Return to SLIME's top level. 2: [abort] Abort thread. Backtrace: 0: (invoke-debugger #<type-error {4848F05A}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:382) 2: org.armedbear.lisp.Lisp.type_error(Lisp.java:435) 3: (+ 1 nil) 4: (system::%eval (+ 1 nil)) 5: (eval (+ 1 nil)) ________________ Old stacktrace The value nil is not of type number. [Condition of type type-error] Restarts: 0: [retry] Retry SLIME REPL evaluation request. 1: [*abort] Return to SLIME's top level. 2: [abort] Abort thread. Backtrace: 0: (system:backtrace) 1: (system::new-backtrace #<type-error {631F4DD}>) 2: (#<local-function in make-invoke-debugger-hook {FB48C75}> #<type-error {631F4DD}> #<local-function in make-invoke-debugger-hook {FB48C75}>) 3: (apply #<local-function in make-invoke-debugger-hook {FB48C75}> (#<type-error {631F4DD}> #<local-function in make-invoke-debugger-hook {FB48C75}>)) 4: (system::run-hook system::*invoke-debugger-hook* #<type-error {631F4DD}> #<local-function in make-invoke-debugger-hook {FB48C75}>) 5: (invoke-debugger #<type-error {631F4DD}>) 6: org.armedbear.lisp.Lisp.error(Lisp.java:382) 7: org.armedbear.lisp.Lisp.type_error(Lisp.java:435) 8: org.armedbear.lisp.Fixnum.add(Fixnum.java:387) 9: org.armedbear.lisp.Primitives$pf_add.execute(Primitives.java:752) 10: (+ 1 nil) 11: (system::%eval (+ 1 nil)) 12: (eval (+ 1 nil)) #### Generate error by typing #< then return into the slime repl ________________ New stacktrace Illegal # macro character: #\< [Condition of type reader-error] Restarts: 0: [retry] Retry SLIME REPL evaluation request. 1: [*abort] Return to SLIME's top level. 2: [abort] Abort thread. Backtrace: 0: (invoke-debugger #<reader-error {25D021FB}>) 1: (error #<reader-error {25D021FB}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:382) 3: org.armedbear.lisp.LispReader$22.execute(LispReader.java:350) = #<function sharp-illegal {2EF7C108}> 4: org.armedbear.lisp.Stream.readDispatchChar(Stream.java:813) 5: org.armedbear.lisp.LispReader$6.execute(LispReader.java:130) = #<function read-dispatch-char {153CFE29}> 6: org.armedbear.lisp.Stream.processChar(Stream.java:588) 7: org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:557) 8: org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:566) 9: (read #S(system::string-input-stream) nil #S(system::string-input-stream)) ________________ Old stacktrace Illegal # macro character: #\< [Condition of type reader-error] Restarts: 0: [retry] Retry SLIME REPL evaluation request. 1: [*abort] Return to SLIME's top level. 2: [abort] Abort thread. Backtrace: 0: (system:backtrace) 1: (system::new-backtrace #<reader-error {35F15D9A}>) 2: (#<local-function in make-invoke-debugger-hook {FB48C75}> #<reader-error {35F15D9A}> #<local-function in make-invoke-debugger-hook {FB48C75}>) 3: (apply #<local-function in make-invoke-debugger-hook {FB48C75}> (#<reader-error {35F15D9A}> #<local-function in make-invoke-debugger-hook {FB48C75}>)) 4: (system::run-hook system::*invoke-debugger-hook* #<reader-error {35F15D9A}> #<local-function in make-invoke-debugger-hook {FB48C75}>) 5: (invoke-debugger #<reader-error {35F15D9A}>) 6: (error #<reader-error {35F15D9A}>) 7: (#<local-function in eval-region {12C6FD1A}> #<reader-error {35F15D9A}>) 8: (signal #<reader-error {35F15D9A}>) 9: org.armedbear.lisp.Lisp.error(Lisp.java:382) 10: org.armedbear.lisp.LispReader$22.execute(LispReader.java:350) = #<function sharp-illegal {2EF7C108}> 11: org.armedbear.lisp.Stream.readDispatchChar(Stream.java:813) 12: org.armedbear.lisp.LispReader$6.execute(LispReader.java:130) = #<function read-dispatch-char {153CFE29}> 13: org.armedbear.lisp.Stream.processChar(Stream.java:588) 14: org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:557) 15: org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:566) 16: org.armedbear.lisp.Stream.read(Stream.java:501) 17: org.armedbear.lisp.Stream$16.execute(Stream.java:2436) = #<function read {7905182E}> 18: org.armedbear.lisp.Symbol.execute(Symbol.java:826) 19: org.armedbear.lisp.LispThread.execute(LispThread.java:851) 20: org.armedbear.lisp.swank_528.execute(swank.lisp:1732) = #<function eval-region {6A067578}> 21: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 22: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 23: org.armedbear.lisp.swank_repl_47.execute(swank-repl.lisp:270) = #<local-function in repl-eval {7AA59573}> 24: org.armedbear.lisp.LispThread.execute(LispThread.java:798) 25: org.armedbear.lisp.swank_repl_48.execute(swank-repl.lisp:283) = #<function track-package {24491179}> 26: org.armedbear.lisp.Symbol.execute(Symbol.java:803) 27: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 28: org.armedbear.lisp.swank_repl_46.execute(swank-repl.lisp:270) = #<local-function in repl-eval {6A4AF4AE}> 29: org.armedbear.lisp.LispThread.execute(LispThread.java:798) 30: org.armedbear.lisp.swank_272.execute(swank.lisp:490) = #<function call-with-retry-restart {4E68726}> 31: org.armedbear.lisp.Symbol.execute(Symbol.java:814) 32: org.armedbear.lisp.LispThread.execute(LispThread.java:832) 33: org.armedbear.lisp.swank_repl_45.execute(swank-repl.lisp:270) = #<local-function in repl-eval {18F59278}> 34: org.armedbear.lisp.LispThread.execute(LispThread.java:798) 35: abcl_027941ee_2c60_4fe0_8ae7_0a41efb34cac.execute(Unknown Source) = #<function call-with-syntax-hooks {16BB516F}> 36: org.armedbear.lisp.LispThread.execute(LispThread.java:814) 37: org.armedbear.lisp.Lisp.funcall(Lisp.java:172) 38: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.java:2827) = #<function apply {61157D6}> 39: (read #S(system::string-input-stream) nil #S(system::string-input-stream)) 40: (swank::eval-region "#<\n") 41: (#<local-function in repl-eval {78DF6AB0}>) 42: (swank-repl::track-package #<local-function in repl-eval {78DF6AB0}>) 43: (#<local-function in repl-eval {5C2443A9}>) 44: (swank::call-with-retry-restart "Retry SLIME REPL evaluation request." #<local-function in repl-eval {5C2443A9}>) 45: (#<local-function in repl-eval {6386D83A}>) 46: (swank/backend:call-with-syntax-hooks #<local-function in repl-eval {6386D83A}>) 47: (apply #<function call-with-syntax-hooks {16BB516F}> #<local-function in repl-eval {6386D83A}> nil) 48: (swank/backend:call-with-syntax-hooks #<local-function in repl-eval {6386D83A}>) 49: (swank::call-with-buffer-syntax nil #<local-function in repl-eval {6386D83A}>) 50: (swank-repl::repl-eval "#<\n") 51: (swank-repl:listener-eval "#<\n") 52: (system::%eval (swank-repl:listener-eval "#<\n")) 53: (eval (swank-repl:listener-eval "#<\n")) 54: (swank:eval-for-emacs (swank-repl:listener-eval "#<\n") "COMMON-LISP-USER" 418) 55: (apply #<function eval-for-emacs {347BE911}> ((swank-repl:listener-eval "#<\n") "COMMON-LISP-USER" 418)) 56: (swank::process-requests nil) 57: (#<local-function in handle-requests {468DC77D}>) 58: (#<local-function in handle-requests {1FC34DCD}>) 59: (swank/backend:call-with-debugger-hook #<function swank-debugger-hook {1C78BEE7}> #<local-function in handle-requests {1FC34DCD}>) 60: (apply #<function call-with-debugger-hook {2F2A561F}> #<function swank-debugger-hook {1C78BEE7}> #<local-function in handle-requests {1FC34DCD}> nil) 61: (swank/backend:call-with-debugger-hook #<function swank-debugger-hook {1C78BEE7}> #<local-function in handle-requests {1FC34DCD}>) 62: (#<local-function in handle-requests {2E4ADDE3}>) 63: (swank::call-with-bindings ((*standard-input* . #S(extensions:slime-input-stream)) (*standard-output* . #S(extensions:slime-output-stream)) (*trace-output* . #S(extensions:slime-output-stream)) ..) #<.. 64: (swank::handle-requests #<swank::multithreaded-connection {245DAD99}>) 65: (swank-repl::repl-loop #<swank::multithreaded-connection {245DAD99}>) 66: (#<local-function in spawn-repl-thread {376522E}>) 67: (swank::call-with-bindings nil #<local-function in spawn-repl-thread {376522E}>) 68: (#<local-function in spawn-repl-thread {5F73C8D9}>) 69: (#<local-function in g27583 {7AC7193C}>) 70: (threads::thread-function-wrapper #<local-function in g27583 {7AC7193C}>) On Mon, Jan 2, 2017 at 6:35 PM, Alan Ruttenberg <alanruttenberg(a)gmail.com> wrote: > Well, I've gone and made an attempt at a "less leaky" version. (It became > an obsession :( ) > > Some features: > - tries not to show internals of swank and abcl debugging calls > - shows top of exception trace for java exceptions, marked with "!" to > indicate they were caught. > - names local functions, even if we only would see the java frame. > - And some other nuisances. Read the code? > > > I am soliciting beta testers - need to see whether it holds up under > stress of use by other. > You will need to check out my branch of ABCL https://github.com/ > alanruttenberg/abcl.git - use branch "stage" > and you will need my branch of slime https://github.com/ > alanruttenberg/slime/ - use branch "beta" > > Build abcl with: ant abcl-aio.jar > > There are a number of other debugging goodies here, also worth testing: > - Better inspectors for some things, like java classes > - View source and disassemble from debugger should work on every frame > - Most definition sources are recorded, including those compiled in a > buffer. > Try edit definitions 'print-object and you will see all the methods and > their source locations > - slime-edit-callers > > Alan > > > > On Sun, Jan 1, 2017 at 6:11 AM, Mark Evenson <evenson(a)panix.com> wrote: > >> >> >> On 12/31/16 20:37, Alan Ruttenberg wrote: >> > I'm getting backtraces that are noisy and therefore impede >> comprehension. >> > >> > For example, in the following stack trace, frames 68-4 seem to >> > recapitulate, for the most part, the java stack corresponding to frames >> > 87-69 >> >> The ABCL backtrace abstraction is perhaps a little bit leaky and noisy >> with respect to its representation of Java calls, but it has been useful >> in improving the implementation in its present form since Tobias and I >> introduced it back in 2006-7 (?). >> >> My strong claim is that a user of ABCL never will see Java calls in the >> backtrace, as they only result in errors in the ABCL implementation >> which causes the "Lisp computation" to fail, thunking out into the >> surrounding Java Try/Catch/Exception mechanism. So, "normally" (i.e. >> when there are more bugs in your code than the implementation), these >> verbose, confusing messages are not seen by the user. >> >> In your example, frames 87-69 show the Lisp-side computation which got >> to the error being signaled in the ABCL implmentation. Then frames 4-68 >> provide the trace of Java attempting to deal with the error signaled by >> the JVM when executing Primitives.java:2845. Frames 0-2 show the error >> propagating back into the Lisp-side debugger machinery. >> >> I think the only real information I get as a developer here is that >> there is an error occuring in org.armedbear.lisp.Primitives:2845; the >> rest of the Java calls don't need to be shown. The backtrace from 4-67 >> can confirm/deny hypothesis about what exacly caused the Java error on >> that line, but usually I would figure things out by starting ABCL under >> JPDA, setting a break point before Primitives:2845, replicating the >> error, and single-stepping through the JVM execution until I understand >> the problem. >> >> The "logic" of javaPushStackFrames() (my code) is trying to elide noisy >> frames. Here it fails to elide frames in your example, as the entry >> point is in Primitive.java not Primitives.java, so this code should be >> changed. I would go with a simpler implementation of >> javaPushStackFrames() that doesn't try to elide frames, and place such a >> mechanism on actually viewing the stack. Perhaps we can get SLIME to >> "collapse" the Java portion of the backtrace (ala "the inspector") into >> a single statement of the source location that the Lisp computation >> enter the JVM error condition? >> >> Hopefully that provides some background for a proposal for a less noisy >> backtrace for your purposes to be possible. Since I often get bug >> reports consisting of little or more reproduction instructions than: "I >> have a problem with ABCL: it gave me this error." and a paste of the >> stack trace, it has been useful to have more information present than not. >> >> One could certainly somehow collapse frames 0-3 somehow into a single >> frame that represents the debugger invocation. >> >> >> >> >> >> >> > >> > Thanks, >> > Alan >> > >> > >> > The value CL-UTILS::FORMS is not of type LIST. >> > [Condition of type TYPE-ERROR] >> > >> > Restarts: >> > 0: [RETRY] Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "jnil" >> > "cl-utils">. >> > 1: [ACCEPT] Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-F >> ILE >> > "jnil" "cl-utils"> as having been successful. >> > 2: [RETRY] Retry ASDF operation. >> > 3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after >> resetting >> > the configuration. >> > 4: [ABORT] Abort compilation. >> > 5: [*ABORT] Return to SLIME's top level. >> > --more-- >> > >> > Backtrace: >> > 0: (#<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}> >> > #<TYPE-ERROR {D3CDE50}> #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK >> > {5108C7A9}>) >> > 1: (APPLY #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}> >> > (#<TYPE-ERROR {D3CDE50}> #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK >> > {5108C7A9}>)) >> > 2: (SYSTEM::RUN-HOOK SYSTEM::*INVOKE-DEBUGGER-HOOK* #<TYPE-ERROR >> > {D3CDE50}> #<LOCAL-FUNCTION IN MAKE-INVOKE-DEBUGGER-HOOK {5108C7A9}>) >> > 3: (INVOKE-DEBUGGER #<TYPE-ERROR {D3CDE50}>) >> > 4: org.armedbear.lisp.Lisp.error(Lisp.java:382) >> > 5: org.armedbear.lisp.Lisp.type_error(Lisp.java:435) >> > 6: org.armedbear.lisp.LispObject.car(LispObject.java:165) >> > 7: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) >> > 8: org.armedbear.lisp.Symbol.execute(Symbol.java:803) >> > 9: org.armedbear.lisp.LispThread.execute(LispThread.java:814) >> > 10: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) >> > 11: org.armedbear.lisp.Symbol.execute(Symbol.java:803) >> > 12: org.armedbear.lisp.LispThread.execute(LispThread.java:814) >> > 13: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) >> > 14: org.armedbear.lisp.Symbol.execute(Symbol.java:803) >> > 15: org.armedbear.lisp.LispThread.execute(LispThread.java:814) >> > 16: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) >> > 17: org.armedbear.lisp.Symbol.execute(Symbol.java:803) >> > 18: org.armedbear.lisp.LispThread.execute(LispThread.java:814) >> > 19: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) >> > 20: org.armedbear.lisp.Symbol.execute(Symbol.java:803) >> > 21: org.armedbear.lisp.LispThread.execute(LispThread.java:814) >> > 22: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) >> > 23: org.armedbear.lisp.Symbol.execute(Symbol.java:803) >> > 24: org.armedbear.lisp.LispThread.execute(LispThread.java:814) >> > 25: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) >> > 26: org.armedbear.lisp.Symbol.execute(Symbol.java:803) >> > 27: org.armedbear.lisp.LispThread.execute(LispThread.java:814) >> > 28: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) >> > 29: org.armedbear.lisp.Symbol.execute(Symbol.java:803) >> > 30: org.armedbear.lisp.LispThread.execute(LispThread.java:814) >> > 31: org.armedbear.lisp.precompiler_51.execute(precompiler.lisp:381) >> > 32: org.armedbear.lisp.Symbol.execute(Symbol.java:803) >> > 33: org.armedbear.lisp.LispThread.execute(LispThread.java:814) >> > 34: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) >> > 35: org.armedbear.lisp.Symbol.execute(Symbol.java:803) >> > 36: org.armedbear.lisp.LispThread.execute(LispThread.java:814) >> > 37: org.armedbear.lisp.precompiler_73.execute(precompiler.lisp:643) >> > 38: org.armedbear.lisp.Symbol.execute(Symbol.java:803) >> > 39: org.armedbear.lisp.LispThread.execute(LispThread.java:814) >> > 40: org.armedbear.lisp.precompiler_48.execute(precompiler.lisp:350) >> > 41: org.armedbear.lisp.Symbol.execute(Symbol.java:803) >> > 42: org.armedbear.lisp.LispThread.execute(LispThread.java:814) >> > 43: org.armedbear.lisp.precompiler_105.execute(precompiler.lisp:988) >> > 44: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure. >> java:121) >> > 45: org.armedbear.lisp.Symbol.execute(Symbol.java:826) >> > 46: org.armedbear.lisp.compiler_pass2_362.execute(compiler-pass2 >> .lisp:7380) >> > 47: org.armedbear.lisp.Symbol.execute(Symbol.java:867) >> > 48: org.armedbear.lisp.LispThread.execute(LispThread.java:918) >> > 49: org.armedbear.lisp.compile_file_19.execute(compile-file.lisp:175) >> > 50: org.armedbear.lisp.Symbol.execute(Symbol.java:814) >> > 51: org.armedbear.lisp.LispThread.execute(LispThread.java:832) >> > 52: org.armedbear.lisp.compile_file_51.execute(compile-file.lisp:655) >> > 53: org.armedbear.lisp.Symbol.execute(Symbol.java:826) >> > 54: org.armedbear.lisp.LispThread.execute(LispThread.java:851) >> > 55: org.armedbear.lisp.compile_file_59.execute(compile-file.lisp:780) >> > 56: org.armedbear.lisp.compiler_pass2_370.execute(compiler-pass2 >> .lisp:7450) >> > 57: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure. >> java:98) >> > 58: org.armedbear.lisp.Symbol.execute(Symbol.java:803) >> > 59: org.armedbear.lisp.LispThread.execute(LispThread.java:814) >> > 60: org.armedbear.lisp.compile_file_57.execute(compile-file.lisp:780) >> > 61: org.armedbear.lisp.Symbol.execute(Symbol.java:914) >> > 62: org.armedbear.lisp.LispThread.execute(LispThread.java:986) >> > 63: org.armedbear.lisp.compile_file_68.execute(compile-file.lisp:962) >> > 64: org.armedbear.lisp.CompiledClosure.execute(CompiledClosure. >> java:150) >> > 65: org.armedbear.lisp.Symbol.execute(Symbol.java:852) >> > 66: org.armedbear.lisp.LispThread.execute(LispThread.java:894) >> > 67: org.armedbear.lisp.Lisp.funcall(Lisp.java:180) >> > 68: org.armedbear.lisp.Primitives$pf_apply.execute(Primitives.ja >> va:2845) >> > 69: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::KEY . >> > CL-UTILS::FORMS)) >> > 70: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::KEY . CL-UTILS::FORMS)) >> > 71: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::LOOP >> CL-UTILS::FOR >> > (CL-UTILS::KEY . CL-UTILS::FORMS) CL-UTILS::IN CL-UTILS::CLAUSES >> > CL-UTILS::DO ...)) >> > 72: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::LOOP CL-UTILS::FOR >> (CL-UTILS::KEY >> > . CL-UTILS::FORMS) CL-UTILS::IN CL-UTILS::CLAUSES CL-UTILS::DO ...)) >> > 73: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::LET >> > ((CL-UTILS::CLAUSE-COLLECTION (CL-UTILS::LIST))) ..)) >> > 74: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::LET >> ((CL-UTILS::CLAUSE-COLLECTION >> > (CL-UTILS::LIST))) ..)) >> > 75: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::WITH-GENSYMS >> > (CL-UTILS::TEST) ..)) >> > 76: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) >> ..)) >> > 77: (PRECOMPILER::PRECOMPILE-FUNCTION-CALL (CL-UTILS::DEFMACRO >> > CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) >> ..)) >> > 78: (PRECOMPILER::PRECOMPILE1 (CL-UTILS::DEFMACRO CL-UTILS::CASE* >> > (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..)) >> > 79: (PRECOMPILER::PRECOMPILE-LAMBDA (LAMBDA NIL ..)) >> > 80: (PRECOMPILER::PRECOMPILE1 (LAMBDA NIL (CL-UTILS::DEFMACRO >> > CL-UTILS::CASE* (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) >> > (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) (CL-UTILS::LET # # #))))) >> > 81: (JVM:COMPILE-DEFUN NIL (LAMBDA NIL (CL-UTILS::DEFMACRO >> CL-UTILS::CASE* >> > (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) >> > (CL-UTILS::WITH-GENSYMS (CL-UTILS::TEST) (CL-UTILS::LET # # #)))) NIL >> > #P"/U.. >> > 82: (SYSTEM::CONVERT-TOPLEVEL-FORM (CL-UTILS::DEFMACRO CL-UTILS::CASE* >> > (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..) NIL) >> > 83: (SYSTEM::PROCESS-TOPLEVEL-FORM (CL-UTILS::DEFMACRO CL-UTILS::CASE* >> > (CL-UTILS::KEYFORM CL-UTILS::&REST CL-UTILS::CLAUSES) ..) #<FILE-STREAM >> > {1773B7E}> NIL) >> > 84: (JVM::%WITH-COMPILATION-UNIT #<LOCAL-FUNCTION IN >> COMPILE-FROM-STREAM >> > {1FEBE62E}>) >> > 85: (SYSTEM::COMPILE-FROM-STREAM #<FILE-STREAM {744E75DD}> >> > #P"/Users/lori/.cache/common-lisp/abcl-1.5.0-dev-fasl43-maco >> sx-x64/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils-tmpUYPFRO0B.abcl" >> > #P"/Users/lor.. >> > 86: (COMPILE-FILE #P"/Volumes/upstairs/repos/jni >> l/lisp/jnil/cl-utils.lisp" >> > :OUTPUT-FILE >> > #P"/Users/lori/.cache/common-lisp/abcl-1.5.0-dev-fasl43-maco >> sx-x64/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils-tm.. >> > 87: (APPLY COMPILE-FILE >> > #P"/Volumes/upstairs/repos/jnil/lisp/jnil/cl-utils.lisp" :OUTPUT-FILE >> > #P"/Users/lori/.cache/common-lisp/abcl-1.5.0-dev-fasl43-maco >> sx-x64/Volumes/upstairs/repos/jnil/lisp/jnil/cl-ut.. >> > >> > >> > >> > >> > >> > private static final void pushJavaStackFrames() >> > { >> > final LispThread thread = LispThread.currentThread(); >> > final StackTraceElement[] frames = thread.getJavaStackTrace(); >> > >> > // frames[0] java.lang.Thread.getStackTrace >> > // frames[1] org.armedbear.lisp.LispThread.getJavaStackTrace >> > // frames[2] org.armedbear.lisp.Lisp.pushJavaStackFrames >> > >> > if (frames.length > 5 >> > && frames[3].getClassName().equals("org.armedbear.lisp.Lisp") >> > && frames[3].getMethodName().equals("error") >> > && frames[4].getClassName().startsWith("org.armedbear.lisp. >> Lisp") >> > && frames[4].getMethodName().equals("eval")) { >> > // Error condition arising from within Lisp.eval(), so no >> > // Java stack frames should be visible to the consumer of the >> > stack abstraction >> > return; >> > } >> > // Search for last Primitive in the StackTrace; that was the >> > // last entry point from Lisp. >> > int last = frames.length - 1; >> > for (int i = 0; i<= last; i++) { >> > if >> > (frames[i].getClassName().startsWith("org.armedbear.lisp.Primitive")) >> > last = i; >> > } >> > // Do not include the first three frames which, as noted above, >> > constitute >> > // the invocation of this method. >> > while (last > 2) { >> > thread.pushStackFrame(new JavaStackFrame(frames[last])); >> > last--; >> > } >> > } >> > >> >> -- >> "A screaming comes across the sky. It has happened before, but there >> is nothing to compare to it now." >> >> >

1 0

How to add abcl.jar to your class path for ABCL projects
by Mirko Vukovic 01 Jan '17

01 Jan '17

Hello, This is a follow-up to my earlier post on stack overflow. That problem is still not solved and here is one question. On the user documentation page I found the instruction to "add abcl.jar to your class path for ABCL projects" How do I do that? Thanks, Mirko

2 3

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

Is there an exit-hook function in abcl?
by Ice Rove 19 Oct '16

19 Oct '16

Is there some way to add a exit-hook function to abcl so when quit abcl, these functions will be called automatically? Just like sbcl's *exit-hooks*. If not, can I help to add one?

2 1

Assorted patches
by Olof-Joachim Frahm 15 Oct '16

15 Oct '16

Hi list, attached are some patches (from [1]) that have been sitting around for a while; one is more of a work in progress, but it would still be great to know if it's at least going in the right direction. - 0001 Fixes an annoying issue I had where imported nested classes (with the dollar sign in their name) weren't found via JSS. - 0002 Adds the `external-only` option as seen in SBCL to `apropos`, because it's convenient. - 0005 Adds support for setting the `file-position` on `string-output-stream`s. Might be somewhat obscure, but I stumbled upon it in some situation. The next one could use some comments as well, but I consider it pretty well working: - 0003 Adds a hook and simple machinery to support multiple internal disassembler backends. At the moment I've added the ObjectWeb ASM one and kept the existing JAD call. Should this somehow add an ASDF system to support loading of those libraries via Maven? At the moment a user has to have the matching JARs in their classpath for it to work. Now the one that is not nearly done is 0004 which attempts to fix some of the issues with `jnew-runtime-class`, in particular working custom constructors. Now I've noticed that that's a *big* topic, so this is just a starting point. I'm deliberating ways of supporting a direct `super` call too, that includes fixing the supermethod calls that are still in the code. Let me know what you think, best regards, Olof [1]: https://github.com/Ferada/abcl/tree/patch-submissions

3 5

Automating install on Linux and Mac
by Robert Goldman 10 Oct '16

10 Oct '16

I was reading over the install instructions, and since I have to install ABCL on multiple platforms, I thought I would automate the process (at least for Mac and Linux). The approach I have taken requires the use of "stow", to get all the bits of ABCL where you want them, and critically automates getting the paths right. Attached please find (1) a Makefile that automates the construction of the "abcl" executable script, the abcl rlwrap completions, and the installation in preparation for the use of "stow". (2) an "abcl_template" file that the makefile will modify so that it can find completions and jar files (both the main one and the contrib). (3) an abcl_completions.lisp file that writes the completions. Adding them to the abcl-1.4.0 directory from the tarballs lets you do this: make prepare-install sudo make install cd /usr/local/stow sudo stow abcl Cheers, r

2 2

run-program patch / better UIOP support
by Olof-Joachim Frahm 07 Sep '16

07 Sep '16

Hi again, after Elias mentioned his work on UIOP I've produced a small patch that improves compatibility with regards to process spawning quite a bit, see attached (or from [1]). Missing is the option to pass in custom streams (which some other implementations support), as that's quite a bit more work with the `ProcessBuilder` interface and would require shuffling data back and forth in a separate thread perhaps. For Windows compatibility (for `process-pid`) I'm a bit stumped how that'd work with standard Java, thus it's currently unsupported. Best regards, Olof [1]: https://github.com/Ferada/abcl/tree/run-more-programs

2 1

IO bug
by Vibhu Mohindra 04 Sep '16

04 Sep '16

Hallo, I've got a file open for IO. Only writing to it works okay. But if I also try to read from it, then things start going wrong. I've attached a test case that should return NIL but instead raises an error in ABCL (1.3.3, on OSX). The problem is with the call to #'write-sequence on line 21. In fact, from some other tests, I believe that replacing that call to #'write-sequence with a call to a function that does the same thing but by repeatedly setting the file-position and writing a byte, for each byte in the sequence, fixes things. That means something about #'write-sequence is broken. Maybe I misunderstand the file level functions in Common Lisp, and my test doesn't use them correctly. However, the test passes in: CLISP, CCL, CMUCL, SBCL, ECL. So I thought I'd report this, just in case it is a bug in ABCL. Also, removing the last three lines of code in #'main, which read one byte, makes the test run without errors. Vibhu

3 6

Moved to github?
by Robert P. Goldman 03 Sep '16

03 Sep '16

I see that there are now active github repositories for ABCL. But the common-lisp.net homepage for ABCL still suggests that we get ABCL source from SVN. Should this be changed? thx, r

4 4

defgeneric, defmethod, and incongruent lambda list... bug?
by Paul Nathan 09 Aug '16

09 Aug '16

Hi, I have a generic function (defgeneric equals (a b &rest keys &key recursive key &allow-other-keys) ... ) This method works correctly: (defmethod equals ((a t) (b t) &rest keys) (declare (ignore keys)) (equalp a b)) ... ) But, this method throws an error: (defmethod equals ((a float) (b float) &rest keys &key floating-compare (max-relative-diff 1.19e-7)) ... ) My understanding from http://www.lispworks.com/documentation/HyperSpec/Body/07_fd.htm is that since &allow-other-keys has been set, this should work. As a point of reference, SBCL allows this, but of course that is not the determinant of correctness. :-) Best regards, Paul

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel