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

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

14 Mar '18

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

1 0

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

03 Mar '18

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

1 0

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

20 Feb '18

ELS'18 - 11th European Lisp Symposium Centro Cultural Cortijo de Miraflores Marbella, Málaga Spain April 16-17 2018 Sponsored by Brunner Software GmbH and EPITA http://www.european-lisp-symposium.org/ *** Important: submission deadline extended to Sunday Feb. 25! The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 11th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els2018 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Important dates: - 25 Feb 2018 Submission deadline (*** extended! ***) - 19 Mar 2018 Notification of acceptance - 25 Mar 2018 Early registration deadline - 02 Apr 2018 Final papers due - 16-17 Apr 2018 Symposium Programme chair: David Cooper, Genworks Intl., USA Local chairs: Andrew Lawson, Ravenpack, Spain Programme committee: Andy Wingo, Igalia, Spain Christophe Rhodes, Goldsmiths University, UK Christopher Wellons Null Program Canada Irène Durand, LaBRI, Université de Bordeaux, France Julian Padget, University of Bath, UK Ludovic Courtès, Inria, France Michael Sperber, DeinProgramm, Germany Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Olin Shivers Northwestern University USA Philipp Marek, Austria Robert Strandh, LaBRI, Université de Bordeaux, France Sacha Chua Living an Awesome Life Canada Scott McKay, Future Fuel, USA Search Keywords: #els2018, ELS 2018, ELS '18, European Lisp Symposium 2018, European Lisp Symposium '18, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2018, European Lisp Conference '18 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

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

13 Feb '18

Reminder: submission deadline this sunday! ELS'18 - 11th European Lisp Symposium Centro Cultural Cortijo de Miraflores Marbella, Málaga Spain April 16-17 2018 Sponsored by Brunner Software GmbH and EPITA http://www.european-lisp-symposium.org/ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 11th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els2018 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Important dates: - 18 Feb 2018 Submission deadline - 19 Mar 2018 Notification of acceptance - 25 Mar 2018 Early registration deadline - 02 Apr 2018 Final papers due - 16-17 Apr 2018 Symposium Programme chair: David Cooper, Genworks Intl., USA Local chairs: Andrew Lawson, Ravenpack, Spain Programme committee: Christophe Rhodes, Goldsmiths University, UK Christopher Wellons Null Program Canada Irène Durand, LaBRI, Université de Bordeaux, France Julian Padget, University of Bath, UK Ludovic Courtès, Inria, France Michael Sperber, DeinProgramm, Germany Nicolas Neuss, Universität Karlsruhe, Germany Olin Shivers Northwestern University USA Robert Strandh, LaBRI, Université de Bordeaux, France Sacha Chua Living an Awesome Life Canada Scott McKay, Future Fuel, USA Search Keywords: #els2018, ELS 2018, ELS '18, European Lisp Symposium 2018, European Lisp Symposium '18, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2018, European Lisp Conference '18 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

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

18 Dec '17

ELS'18 - 11th European Lisp Symposium Centro Cultural Cortijo de Miraflores Marbella, Málaga Spain April 16-17 2018 Sponsored by EPITA http://www.european-lisp-symposium.org/ The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 11th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els2018 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Important dates: - 18 Feb 2018 Submission deadline - 19 Mar 2018 Notification of acceptance - 25 Mar 2018 Early registration deadline - 02 Apr 2018 Final papers due - 16-17 Apr 2018 Symposium Programme chair: David Cooper, Genworks Intl., USA Local chairs: Andrew Lawson & Nick Levine, Ravenpack, Spain Programme committee: tba Search Keywords: #els2018, ELS 2018, ELS '18, European Lisp Symposium 2018, European Lisp Symposium '18, 10th ELS, 10th European Lisp Symposium, European Lisp Conference 2018, European Lisp Conference '18 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

FriCAS w. ABCL
by Kurt Pagani 05 Dec '17

05 Dec '17

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

2 2

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

07 Nov '17

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

1 0

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

05 Nov '17

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

1 0

abcl-web
by Alexandre Rademaker 16 Oct '17

16 Oct '17

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

2 1

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

11 Oct '17

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

1 1