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

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 13 Jul '22

13 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 11 Apr '22

11 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 09 Jan '22

09 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 26 Nov '21

26 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