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

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

02 Dec '19

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

3 2

ABCL 1.6.0 unleashed
by Mark Evenson 23 Nov '19

23 Nov '19

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

2 2

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

18 Nov '19

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

2 3

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

16 Nov '19

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

2 1

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

16 Nov '19

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

2 1

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

14 Nov '19

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

1 0

Directory handling
by Marco Antoniotti 13 Jun '19

13 Jun '19

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

4 10

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

12 Jun '19

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

3 2

Running Lisp tests
by Alessio Stalla 12 Jun '19

12 Jun '19

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

5 10

Re: ABCL functionality
by Marco Antoniotti 07 Jun '19

07 Jun '19

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

2 1

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

11 Apr '19

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

4 5

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

30 Mar '19

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

2 1

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

29 Mar '19

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

2 1

ASDF 3.3.3 is Released
by Robert Goldman 27 Mar '19

27 Mar '19

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

1 0

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

17 Mar '19

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

5 10

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

08 Mar '19

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

2 4

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

17 Jan '19

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

2 1

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

17 Jan '19

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

1 0

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

16 Jan '19

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

1 0

build failure
by Stephen Varey 16 Jan '19

16 Jan '19

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

2 1

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

12 Jan '19

ELS'19 - 12th European Lisp Symposium Hotel Bristol Palace Genova, Italy April 1-2 2019 In cooperation with: ACM SIGPLAN In co-location with <Programming> 2019 Sponsored by EPITA http://www.european-lisp-symposium.org/ Recent news: - Keynote by Stefan Monnier on Emacs Lisp - Keynote by Christophe Rhodes on SBCL - Guest appearance by Matthew Flatt on Racket The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp and Lisp-inspired dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, ACL2, ECMAScript, Racket, SKILL, Hop and so on. We encourage everyone interested in Lisp to participate. The 12th European Lisp Symposium invites high quality papers about novel research results, insights and lessons learned from practical applications and educational perspectives. We also encourage submissions about known ideas as long as they are presented in a new setting and/or in a highly elegant way. Topics include but are not limited to: - Context-, aspect-, domain-oriented and generative programming - Macro-, reflective-, meta- and/or rule-based development approaches - Language design and implementation - Language integration, inter-operation and deployment - Development methodologies, support and environments - Educational approaches and perspectives - Experience reports and case studies We invite submissions in the following forms: Papers: Technical papers of up to 8 pages that describe original results or explain known ideas in new and elegant ways. Demonstrations: Abstracts of up to 2 pages for demonstrations of tools, libraries, and applications. Tutorials: Abstracts of up to 4 pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The symposium will also provide slots for lightning talks, to be registered on-site every day. All submissions should be formatted following the ACM SIGS guidelines and include ACM Computing Classification System 2012 concepts and terms. Submissions should be uploaded to Easy Chair, at the following address: https://www.easychair.org/conferences/?conf=els2019 Note: to help us with the review process please indicate the type of submission by entering either "paper", "demo", or "tutorial" in the Keywords field. Important dates: - 01 Feb 2019 Submission deadline - 01 Mar 2019 Notification of acceptance - 18 Mar 2019 Final papers due - 01-02 Apr 2019 Symposium Programme chair: Nicolas Neuss, FAU Erlangen-Nürnberg, Germany Programme committee: Marco Antoniotti, Universita Milano Bicocca, Italy Marc Battyani, FractalConcept, France Pascal Costanza, IMEC, ExaScience Life Lab, Leuven, Belgium Leonie Dreschler-Fischer, University of Hamburg, Germany R. Matthew Emerson, thoughtstuff LLC, USA Marco Heisig, FAU, Erlangen-Nuremberg, Germany Charlotte Herzeel, IMEC, ExaScience Life Lab, Leuven, Belgium Pierre R. Mai, PMSF IT Consulting, Germany Breanndán Ó Nualláin, University of Amsterdam, Netherlands François-René Rideau, Google, USA Alberto Riva, Unversity of Florida, USA Alessio Stalla, ManyDesigns Srl, Italy Patrick Krusenotto, Deutsche Welle, Germany Philipp Marek, Austria Sacha Chua, Living an Awesome Life, Canada Search Keywords: #els2019, ELS 2019, ELS '19, European Lisp Symposium 2019, European Lisp Symposium '19, 12th ELS, 12th European Lisp Symposium, European Lisp Conference 2019, European Lisp Conference '19 -- Resistance is futile. You will be jazzimilated. Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

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

11 Dec '18

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

2 1

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

27 Nov '18

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

2 2

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

15 Nov '18

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

2 1

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

31 Oct '18

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

1 0