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

[Final CfP] 18th European Lisp Symposium -- Extended Deadline
by Didier Verna 02 Mar '25

02 Mar '25

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 18th European Lisp Symposium Last Call for Papers *** Extended Deadline *** 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 artificial intelligence, and meta-programming beyond macros. Invited Speakers ~~~~~~~~~~~~~~~~ Joerg Gutknecht -- Project Oberon: A Late Appraisal Anurag Mendhekar -- Is Lisp Still Relevant in the New Age of AI? Robert Smith -- Toward safe, flexible, and efficient software in Common Lisp Important Dates ~~~~~~~~~~~~~~~ - Registration opens: Dec 10 2024 - Submission deadline: Mar 09 2025 ( *** extended *** ) - 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

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 05 Jul '23

05 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 24 May '23

24 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