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

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

16 Nov '19

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

2 1

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

11 Apr '19

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

4 5

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

30 Mar '19

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

2 1

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

29 Mar '19

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

2 1

ASDF 3.3.3 is Released
by Robert Goldman 27 Mar '19

27 Mar '19

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

1 0

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

17 Mar '19

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

5 10

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

08 Mar '19

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

2 4