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

Encode/decode-universal-time and DST
by Scott L. Burson 09 Nov '15

09 Nov '15

Hi, As daylight-saving time ended in the US today, I discovered that ABCL's interpretation of the CL spec concerning the behavior of 'encode/decode-universal-time' around DST is not the usual one. The usual interpretation is that when an explicit timezone is not supplied to these calls, DST is selected automatically based on whether it would have been in force (under certain assumptions, e.g., you're not in Arizona) at the time being converted. ABCL's behavior is to convert the time based on whether DST is in force at the time of the call. I think it's pretty clear that the former interpretation was the intended one, even if the language of the spec is admittedly not as clear as it should have been. SBCL does it that way, CCL does it that way, and I even dug out the Genera 7.2 sources, which I still have lying around, to confirm that it did it that way too. It looks like the ABCL interpretation was more-or-less intentional since a comment in the code says "adapted from SBCL". Do the ABCL developers feel strongly that this is the correct behavior? -- Scott

3 11

JEP 276: Dynamic Linking of Language-Defined Object Models
by Mark Evenson 24 Oct '15

24 Oct '15

Not sure exactly how this maps to Common Lisp, but it looks like JDK 9 will have a lot of interesting new APIs for compiling efficient code for langauges other than Lisp. The latest I have found out about is [JEP 276: Dynamic Linking of Language-Defined Object Models][1]. [1]: http://openjdk.java.net/jeps/276 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Maven plugin for compiling to bytecode?
by Andrew Pennebaker 21 Oct '15

21 Oct '15

Could there be a Maven plugin that compiles src/main/lisp/**/*.lisp to .class files for integration in Java projects? -- Cheers, Andrew

2 1

ASDF 3.1.6 is released
by Robert Goldman 17 Oct '15

17 Oct '15

We would like to announce the release of ASDF 3.1.6, the latest bug fix release for ASDF. As usual many thanks are due to Faré for many bug fixes, clean ups, explanations, etc. Thanks are also owed to Dave Cooper, for testing on the Windows platform, enabling the maintainers to test on Windows, and identifying uncaught bugs. Thanks to Anton Vodonosov for testing the release candidate against Quicklisp on cl-test-grid. Finally, thanks to all who found bugs, provided patches, and used prerelease candidates. We urge implementations that are currently bundling previous versions of ASDF to adopt 3.1.6. 3.1.6 does not introduce any API incompatibilities that we know of, and contains significant bug fixes on multiple platforms and implementations. See the Changelog (below) for a list of the major bug fixes. Details on minor bugfixes can be found at launchpad.net/asdf We had hoped that 3.1.5 would be the last 3.1.x bug fix release, paving the way for us to move to developing ASDF 3.2, which we expect will add new features. Maybe this time! Here is the changelog entry for 3.1.6: Bug fix and portability release: * Fix backtrace on SBCL. * Fix RUN-PROGRAM of string (shell command) on Windows SBCL (ticket #1501373). * Fix a number of issues with bundle operations (especially on non-C-compiler-based implementations). * Fix component-finding in package-inferred-system. * Fix race condition between multiple concurrent lisp processes doing ASDF builds (ticket #1483948). * Fix misplaced fasl cache on Windows. * Miscellaneous bug fixes. * Documentation improvements. -- Robert P. Goldman <rpgoldman(a)sift.net> Sat, 17 Oct 2015 15:01:34 -0500

1 0

[CfP] European Lisp Symposium 2016, May 9-10, Kraków, Poland
by Didier Verna 07 Oct '15

07 Oct '15

ELS'16 - 9th European Lisp Symposium AGH University of Science and Technology Kraków, Poland May 9-10, 2016 http://www.european-lisp-symposium.org/ Sponsored by EPITA and AGH University 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 9th 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 classification categories and terms. For more information on the submission guidelines and the ACM keywords, see: http://www.acm.org/sigs/publications/proceedings-templates and http://www.acm.org/about/class/1998. Important dates: - 19 Feb 2016 Submission deadline - 25 Mar 2016 Notification of acceptance - 15 Apr 2016 Early registration deadline - 22 Apr 2016 Final papers due - 9-10 May 2016 Symposium Programme chair: Irène Durand, University of Bordeaux, France Local chair: Michał Psota, Emergent Network Defense, Kraków, Poland Programme committee: Antonio Leitao — INESC-ID / Instituto Superior Técnico, Universidade de Lisboa, Portugal Charlotte Heerzel — IMEC, Leuven, Belgium Christian Queinnec — University Pierre et Marie Curie, Paris 6, France Christophe Rhodes — Goldsmiths, University of London, United Kingdom Didier Verna — EPITA Research and Development Laboratory, France Erick Gallesio — University of Nice-Sophia Antipolis, France Francois-René Rideau, Google, USA Giuseppe Attardi — University of Pisa, Italy Henry Lieberman — MIT, USA Kent Pitman, HyperMeta Inc., U.S.A. Leonie Dreschler-Fischer — University of Hamburg, Germany Pascal Costanza — Intel Corporation, Belgium Robert Strandh — University of Bordeaux, France Search Keywords: #els2016, ELS 2016, ELS '16, European Lisp Symposium 2016, European Lisp Symposium '16, 9th ELS, 9th European Lisp Symposium, European Lisp Conference 2016, European Lisp Conference '16 -- My new Jazz CD entitled "Roots and Leaves" is out! Check it out: http://didierverna.com/records/roots-and-leaves.php Lisp, Jazz, Aïkido: http://www.didierverna.info

1 0

Unable to quickload Drakma + CL+SSL on ABCL 1.3.2 - (Failed to read artifact descriptor for net.java.dev.jna:jna)
by Paul Nathan 27 Sep '15

27 Sep '15

Hello, I just downloaded ABCL 1.3.2 for OSX (curl -L -O http://abcl.org/releases/1.3.2/abcl-bin-1.3.2.tar.gz) and tried to load a few things in. Drakma & CL+SSL failed to load for me. I have copied the tracebacks to the end of the email. Please advise: is this my own error or something with ABCL? Is there more information you would like? Regards, Paul CL-USER(3): (ql:quickload :cl+ssl) To load "cl+ssl": Load 1 ASDF system: cl+ssl ; Loading "cl+ssl" .......... Using probed value of abcl-contrib: '/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar'. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/quicklisp/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/mvn/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/jss/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/jfli/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/asdf-jar/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/asdf-install/ to ASDF. Added jar:file:/Users/pnathan/bin/abcl-bin-1.3.2/abcl-contrib.jar!/abcl-asdf/ to ASDF. ARTIFACT_RESOLVING net.java.dev.jna:jna:pom:4.1.0 ARTIFACT_DOWNLOADING net.java.dev.jna:jna:pom:4.1.0 @ central ( http://repo1.maven.org/maven2/, default, releases+snapshots) ARTIFACT_DOWNLOADED net.java.dev.jna:jna:pom:4.1.0 @ central ( http://repo1.maven.org/maven2/, default, releases+snapshots) ARTIFACT_RESOLVED net.java.dev.jna:jna:pom:4.1.0 jnaASDF could not load because Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'.. #<THREAD "interpreter" {10EDE4B7}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'. Restarts: 0: RETRY Retry compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">. 1: ACCEPT Continue, treating compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0"> as having been successful. 2: RETRY Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl">. 3: ACCEPT Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl"> as having been successful. 4: RETRY Retry ASDF operation. 5: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. 6: ABORT Give up on "cl+ssl" 7: TOP-LEVEL Return to top level. CL-USER(4): (ql:quickload :drakma) To load "drakma": Load 1 ASDF system: drakma ; Loading "drakma" ARTIFACT_RESOLVING net.java.dev.jna:jna:pom:4.1.0 ARTIFACT_DOWNLOADING net.java.dev.jna:jna:pom:4.1.0 @ central ( http://repo1.maven.org/maven2/, default, releases+snapshots) ARTIFACT_DOWNLOADED net.java.dev.jna:jna:pom:4.1.0 @ central ( http://repo1.maven.org/maven2/, default, releases+snapshots) ARTIFACT_RESOLVED net.java.dev.jna:jna:pom:4.1.0 jnaASDF could not load because Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'.. #<THREAD "interpreter" {A19A2B4}>: Debugger invoked on condition of type JAVA-EXCEPTION Java exception 'org.eclipse.aether.collection.DependencyCollectionException: Failed to read artifact descriptor for net.java.dev.jna:jna:jar:4.1.0'. Restarts: 0: RETRY Retry compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0">. 1: ACCEPT Continue, treating compiling #<ASDF/INTERFACE:MVN "jna" "net.java.dev.jna/jna/4.1.0"> as having been successful. 2: RETRY Retry compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl">. 3: ACCEPT Continue, treating compiling #<ASDF/LISP-ACTION:CL-SOURCE-FILE "cffi" "src" "cffi-abcl"> as having been successful. 4: RETRY Retry ASDF operation. 5: CLEAR-CONFIGURATION-AND-RETRY Retry ASDF operation after resetting the configuration. 6: ABORT Give up on "drakma" 7: TOP-LEVEL Return to top level. [1] CL-USER(5): 6

3 6

Pointing out ABCL "extensions" to ANSI-TEST
by Mark Evenson 15 Sep '15

15 Sep '15

Congratulations on getting the divergent ANSI-TEST suite codebases back together in one place, as well as establishing this mailing list. As a Common Lisp implementer who only really started studying the language a decade ago, I have profited immeasurably from figuring out why ABCL fails a given ANSI-TEST while other implementations don't. I would like to point out a few "extensions" to the ANSI-TEST suite that ABCL has added over the years so that other implementations might profit from them and/or that some of the ideas might be included in the ANSI-TEST suite itself. Upon reviewing the implementation of these ideas, parts of me cringe at how my younger self implemented things so I wouldn't necessarily recommend adoption of our code wholesale. 1) ASDF By the nature of how ANSI-TEST loads and runs itself, encapsulation as a "true" ASDF system (i.e. one where all the source is declared) seems a little farfetched. And maybe it is useful to be able to run the suite in places where ASDF is not available, such as when bootstrapping a new implementation. Nevertheless, we put some work into encapsulating the ANSI-SUITE into ASDF to the point that it can be loaded and the tests run that might be of interest. [ABCL defines three ASDF systems][1], namely ANSI-RT, ANSI-COMPILED, and ANSI-INTERPRETED. ANSI-RT encapsulates the regression test framework, while ANSI-COMPILED and ANSI-INTERPETED provide definitions to the point that ASDF:TEST-SYSTEM can run the compiled or interpreted tests respectively. This helps with automation of the tests in ABCL's build mechanism. The one caveat is that one cannot run tests in "parallel" on, say, different versions of your implementation that you are regression testing due to the way that ANSI-TEST uses the filesystem of the ANSI-TEST itself to keep fasls and record state for tests in the course of running the suite. [1]: http://abcl.org/trac/browser/trunk/abcl/abcl.asd#L76 2) ABCL.TEST.ANSI In order to support the necessary shenanigans to make the ANSI-COMPILED and ANSI-INTERPRETED definitions work, we [created a small set of utility routines][2]. CLEAN-TESTS performs the removal of intermediate files that the old Makefile used to do. DO-TESTS-MATCHING will run only those tests whose symbols match a regular expression, which is useful for repeatedly running a subset of tests. [2] http://abcl.org/trac/browser/trunk/abcl/test/lisp/ansi/abcl-ansi.lisp 3) ANSI-TEST error "database" We [created a simple s-expr "database"][4] for recording test failures and then [reporting on the results][3]. ABCL is a unique CL implementation because it is hosted on a JVM for which there are multiple implementations and whose behavior often varies by operating system so running the ANSI-TEST suite has proven to be fairly sensitive to hosting JVM implementation version and operating system. Thus, such a database of regressions has proven to be of special importance to ABCL. That being said, my implementation of this idea is pretty amateurish in hindsight, so I think what is important here is the idea rather than the implementation. [3]: http://abcl.org/trac/browser/trunk/abcl/test/lisp/ansi/parse-ansi-errors.li… [4]: http://abcl.org/trac/browser/trunk/abcl/test/lisp/ansi/ansi-test-failures -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

Typo in last commit on svn
by Stefan Husmann 09 Sep '15

09 Sep '15

Hello, I think there is a typo, or, say, copy-and-paste error in the last commit on svn. abcl does not build the way it is. This is my correction. +++ a/trunk/abcl/build.xml +++ b/trunk/abcl/build.xml @@ -877,5 +877,5 @@ ${basedir}/../ansi-tests. -[1]: <git+https://gitlab.common-lisp.net/ansi-test/ansi-test.git> +[1]: git+https://gitlab.common-lisp.net/ansi-test/ansi-test.git The CL-BENCH tests require that [cl-bench][2] be manually installed in Best Regards Stefan Husmann PS: I am new on this list, so I apologize if thi has been brought up before.

2 1

Can't muffle COMPILE
by James M. Lawrence 08 Sep '15

08 Sep '15

(handler-bind ((warning #'muffle-warning)) (compile nil '(lambda () x))) => ; Caught STYLE-WARNING: ; Undefined variable X assumed special ; Compilation unit finished ; Caught 1 STYLE-WARNING condition Also, you might want that to be more than a style-warning; it's a full warning in other implementations. Best, lmj

2 1

Compiler can generate code it cannot load....
by Patrick Stein 02 Sep '15

02 Sep '15

This is a short program for which the compiler creates a file it cannot load. Save this program to a file, then try: (load (compile-file “this-file.lisp”)) ;;; This program causes the ABCL compiler to generate code it cannot load. ;;; ;;; The code compiles and loads correctly if you do any of the following: ;;; * change BUFSIZE to be 'INTEGER instead of '(INTEGER 0 100) ;;; * delete the INLINE declaration for BUFFER-LENGTH ;;; * delete the FTYPE declaration for BUFFER-LENGTH ;;; * delete the TYPE declaration for NEW-CAPACITY (deftype bufsize () '(integer 0 100)) (declaim (inline buffer-length) (ftype (function () bufsize) buffer-length)) (defun buffer-length () (the bufsize 10)) (defun calculate-new-buffer-length (new-capacity) (declare (type bufsize new-capacity)) (min (buffer-length) new-capacity)) As noted in the comment, it is very finicky. There are at least four ways this code could be slightly less-specific and then not trigger the bug. I tried it both with ABCL-1.3.1 and ABCL-1.3.2. The logs of the output are below. I’d love to be able to say that I’m looking at the compiler now to try to figure out where it’s going wrong, but realistically, I’m not going to have time to delve into it myself, I’ve never really looked at the ABCL compiler before, and I suspect the problem is in the compiling but doesn’t show up until the loading… so it won’t be as easy as exploring the stack when the error shows up. Thanks, Patrick Script started on Tue Sep 1 16:33:56 2015 bash-3.2$ cat compile-problem.lisp ;;; This program causes the ABCL compiler to generate code it cannot load. ;;; ;;; The code compiles and loads correctly if you do any of the following: ;;; * change BUFSIZE to be 'INTEGER instead of '(INTEGER 0 100) ;;; * delete the INLINE declaration for BUFFER-LENGTH ;;; * delete the FTYPE declaration for BUFFER-LENGTH ;;; * delete the TYPE declaration for NEW-CAPACITY (deftype bufsize () '(integer 0 100)) (declaim (inline buffer-length) (ftype (function () bufsize) buffer-length)) (defun buffer-length () (the bufsize 10)) (defun calculate-new-buffer-length (new-capacity) (declare (type bufsize new-capacity)) (min (buffer-length) new-capacity)) bash-3.2$ ABCL_HOME=/usr/local/src/abcl-1.3.2 abcl Armed Bear Common Lisp 1.3.2 Java 1.8.0_45 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.524 seconds. Startup completed in 2.65 seconds. Type ":help" for a list of available commands. CL-USER(1): (load (compile-file "compile-problem.lisp")) ; Compiling /Users/pat/compile-problem.lisp ... ; (DEFTYPE BUFSIZE ...) ; (DECLAIM (INLINE BUFFER-LENGTH) ...) ; (DEFUN BUFFER-LENGTH ...) ; (DEFUN CALCULATE-NEW-BUFFER-LENGTH ...) ; Wrote /Users/pat/compile-problem.abcl (0.208 seconds) java.lang.VerifyError: (class: org/armedbear/lisp/compile_problem_2, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Unable to pop operand off an empty stack at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) at java.lang.Class.getConstructor0(Class.java:3075) at java.lang.Class.newInstance(Class.java:412) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) 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.load(Load.java:224) at org.armedbear.lisp.Load.load(Load.java:745) at org.armedbear.lisp.Load$_load.execute(Load.java:693) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 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.Lisp.eval(Lisp.java:538) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) 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.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:285) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.top_level_47.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.top_level_48.execute(top-level.lisp:415) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Interpreter.run(Interpreter.java:361) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:745) Error loading /Users/pat/compile-problem.abcl at line 15 (offset 668) #<THREAD "interpreter" {33E81276}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.compile_problem_2 from org.armedbear.lisp.Pathname@2acec9eb Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): 0 CL-USER(3): (quit) bash-3.2$ ABCL_HOME=/usr/local/src/abcl-bin-1.3.1 abcl Armed Bear Common Lisp 1.3.1 Java 1.8.0_45 Oracle Corporation Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.471 seconds. Startup completed in 2.651 seconds. Type ":help" for a list of available commands. CL-USER(1): (load (compile-file "compile-problem.lisp")) ; Compiling /Users/pat/compile-problem.lisp ... ; (DEFTYPE BUFSIZE ...) ; (DECLAIM (INLINE BUFFER-LENGTH) ...) ; (DEFUN BUFFER-LENGTH ...) ; (DEFUN CALCULATE-NEW-BUFFER-LENGTH ...) ; Wrote /Users/pat/compile-problem.abcl (0.199 seconds) java.lang.VerifyError: (class: org/armedbear/lisp/compile_problem_2, method: execute signature: (Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Unable to pop operand off an empty stack at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671) at java.lang.Class.getConstructor0(Class.java:3075) at java.lang.Class.newInstance(Class.java:412) at org.armedbear.lisp.FaslClassLoader.loadFunction(FaslClassLoader.java:130) at org.armedbear.lisp.FaslClassLoader$pf_get_fasl_function.execute(FaslClassLoader.java:165) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:577) at org.armedbear.lisp.Lisp.eval(Lisp.java:540) at org.armedbear.lisp.Load.faslLoadStream(Load.java:667) at org.armedbear.lisp.Load$init_fasl.execute(Load.java:457) at org.armedbear.lisp.LispThread.execute(LispThread.java:832) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:582) 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.load(Load.java:224) at org.armedbear.lisp.Load.load(Load.java:745) at org.armedbear.lisp.Load$_load.execute(Load.java:693) at org.armedbear.lisp.Symbol.execute(Symbol.java:852) at org.armedbear.lisp.LispThread.execute(LispThread.java:894) at org.armedbear.lisp.load_1.execute(load.lisp:33) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:98) 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.Lisp.eval(Lisp.java:538) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:345) 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.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3742) at org.armedbear.lisp.Lisp.eval(Lisp.java:530) at org.armedbear.lisp.Lisp.progn(Lisp.java:709) at org.armedbear.lisp.Closure.execute(Closure.java:220) at org.armedbear.lisp.Closure.execute(Closure.java:148) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:285) at org.armedbear.lisp.Symbol.execute(Symbol.java:803) at org.armedbear.lisp.LispThread.execute(LispThread.java:814) at org.armedbear.lisp.top_level_47.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:89) at org.armedbear.lisp.Symbol.execute(Symbol.java:793) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.top_level_48.execute(top-level.lisp:415) at org.armedbear.lisp.LispThread.execute(LispThread.java:798) at org.armedbear.lisp.Interpreter.run(Interpreter.java:361) at org.armedbear.lisp.Main$1.run(Main.java:48) at java.lang.Thread.run(Thread.java:745) Error loading /Users/pat/compile-problem.abcl at line 15 (offset 668) #<THREAD "interpreter" {3F8D7E88}>: Debugger invoked on condition of type ERROR Compiled function can't be loaded: org.armedbear.lisp.compile_problem_2 from org.armedbear.lisp.Pathname@28015d1d Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2): 0 CL-USER(3): (quit) bash-3.2$ ccl --no-init Welcome to Clozure Common Lisp Version 1.11-dev-r16393-trunk (DarwinX8664)! CCL is developed and maintained by Clozure Associates. For more information about CCL visit http://ccl.clozure.com. To enquire about Clozure's Common Lisp consulting services e-mail info(a)clozure.com or visit http://www.clozure.com. ? (load (compile-file "compile-problem.lisp")) #P"/Users/pat/compile-problem.dx64fsl" ? (quit) bash-3.2$ sbcl --no-init This is SBCL 1.2.3.13-3446e1a-dirty, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (load (compile-file "compile-problem.lisp")) ; compiling file "/Users/pat/compile-problem.lisp" (written 01 SEP 2015 04:33:38 PM): ; compiling (DEFTYPE BUFSIZE ...) ; compiling (DECLAIM (INLINE BUFFER-LENGTH) ...) ; compiling (DEFUN BUFFER-LENGTH ...) ; compiling (DEFUN CALCULATE-NEW-BUFFER-LENGTH ...) ; /Users/pat/compile-problem.fasl written ; compilation finished in 0:00:00.007 T * (quit) bash-3.2$ exit Script done on Tue Sep 1 16:36:21 2015

2 2

Better integration between ABCL & Java
by Blake McBride 30 Aug '15

30 Aug '15

Greetings, I worked hard on a project to link ABCL with a very large Java application. Although the addition of ABCL to that project failed, the work I did could be of use, and with some effort could be made to solve the problem I had. I believe the original problem I had would be a very common problem in similar circumstances. My pre-existing Java application has almost 10,000 classes! I wasn't about to create lisp cover functions for each java method. I also wasn't going to use a convoluted syntax to get to java each time. What I did was create some Java and Lisp code that, through reflection, caused the system to auto-generate a complete set of CLOS classes to mirror my primary java application classes - including the class hierarchy. The methods in these CLOS classes would call the Java methods. With this, when in Lisp, I could just use all of my Java classes and methods as regular CLOS classes and methods. It's use of Java classes and methods internally was transparent to lisp. All of this worked fine. The problem I ran into was the fact that Java can have several methods with the same name but different arguments. So, the Java method being called depended on the types and number of arguments too (not just the class of the instance and the method name). I never solved this, although I think it could be. I just ran out of time and steam, as well as other non-technical reasons. The reason I bring this all up now is because I am unclear about what problems Ralph is trying to solve. I thought what I have done may be of use. Thanks. Blake McBride

5 5

All conformance ansi-test's passed
by Ralph Ritoch 26 Aug '15

26 Aug '15

Hello, I have been able to get ABCL to pass all of the ansi conformance tests. While this is not an official ABCL release, all of the modifications I made are released under the MIT license and may be freely integrated into ABCL at the discretion of the maintainers. To embed this conforming version into your java applications add the following dependencies which have been released at maven central. <dependency> <groupId>com.vnetpublishing.lisp</groupId> <artifactId>jrelisp-abcl-impl</artifactId> <version>0.0.2</version> </dependency> <dependency> <groupId>com.vnetpublishing.lisp</groupId> <artifactId>jrelisp-abcl-contrib</artifactId> <version>0.0.2</version> </dependency> The source code for this release can be found at https://github.com/rritoch/jrelisp-abcl/tree/55e808d3c0084d16d1ed04c36a6f5a… . While I have moved some files around it is still an ABCL implementation that is mostly backwards-compatible with the official ABCL releases. Moving forward it is likely that any future development on these branches will further deviate from ABCL. I am not claiming that this solves EVERY compliance issue but I have found solutions for each of the ansi conformance test failures. Any remaining compliance issues can be considered a bug. My primary intention of passing every test is to lock the build process so that builds will fail if any of the ansi tests fail. It is unlikely that future modifications to these forks will have any relevance to ABCL. I will likely continue developing features that are needed for modern application development and therefore are of little interest to some, if not all, of the ABCL maintainers. That being said, v0.0.2 is the best release to source conformance solutions from for ABCL as it passes every conformance test. Any future releases will no longer be based on improving ABCL but be for the purpose of better supporting modern application development. Best Regards, Ralph Ritoch

5 7

loading lisp files from inside the java jar
by Hamda Binte Ajmal 18 Aug '15

18 Aug '15

Hi, I am sending this message again, as the last thread went a little too far. I have developed a Java Application that runs lisp code at the back end, and I use ABCL for that. Before using the lisp commands, I load a few .lisp files so that I can call the functions defined in those files. Everything works fine as long as I run the application from Netbeans. When I run the application from the jar file, it throws 'File not found error'. as the lisp files are not a part of file system inside the project jar. I tried to follow the suggestions given by Mark (load “jar:file:/absolute/path/to/file.jar!/path/within/jar/setup.lisp”) It shows the same File not found error. Am i missing something here? As suggested by Ralph to use (load-system-file "path/to/resource.lisp"), I tried to use that, but I was unable to access sys package, please let me know how to do this. I find the help documentation and tutorials very confusing, and difficult to understand. Any hints will be appreciated. Thanking in anticipation. Regards, Hamda NUIG, Ireland.

5 13

Re: Lisp filepath issues when running application directly from jar file
by Ralph Ritoch 17 Aug '15

17 Aug '15

This "idiot" refactored a very small portion of your code making it MUCH faster, and also passed more than 90% of the tests ABCL is currently failing, leaving only 3 ansi-tests that are still failing. If I'm an idiot it doesn't say much about you since you've been working on this for years and I've only been working on it for weeks. Best Regards, Ralph Ritoch On Mon, Aug 17, 2015 at 8: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. Re: Lisp filepath issues when running application directly > from jar file (Mark Evenson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 16 Aug 2015 14:38:44 +0200 > From: Mark Evenson <evenson(a)panix.com> > To: Armed Bear <armedbear-devel(a)common-lisp.net> > Subject: Re: Lisp filepath issues when running application directly > from jar file > Message-ID: <5616917D-F789-4F95-93E2-FC3B7633B051(a)panix.com> > Content-Type: text/plain; charset="utf-8" > > > > On Aug 16, 2015, at 02:34, Ralph Ritoch <rritoch(a)gmail.com> wrote: > > > > I have used this function in my code without ANY problems. [?] > > The SYSTEM package is not intended to be used by users unless there is no > alternative. The manual states clearly that functionality provided by > SYSTEM > is subject to be changed between major releases without warning. > Therefore, > the argument in this case isn?t that one would have problems using > SYSTEM:LOAD-SYSTEM-FILE, but rather that one should use the ANSI interface > as > implemented CL:LOAD which should be able to load Lisp and/or fasls in all > cases > needed by the user. My work on EXT:JAR-PATHNAME and EXT:URL-PATHNAME was > motivated by precisely the need for CL:LOAD to work in all conceivable > cases in > the JVM ecology. And the best contemporary mechanism for expression for > resolution of and dependency order for CL:LOAD lies in ASDF, hence my > emphasis on using its abstraction where extending CL:LOAD is not desirable. > > As a side note, over time, we wish to move functions in SYSTEM which > useful to > the user into the EXTENSION package, but this work is incomplete at best. > Currently, there are indeed cases in which using a function from SYSTEM is > unavoidable. The use of SYSTEM:LOAD-SYSTEM-FILE is not one of them. > > > Your attitude regarding "progress" is archaic. If you don't want to > support maven or other java technologies why do you even bother controlling > abcl? > > > Your attitude towards discussion is not only archaic (i.e. immature) but > counterproductive towards reaching the sort of consensus needed for > progress. > > However misguided such an endeavor may be, a couple points follow towards a > defense from your sleazy ad hominem ?argumentation?. > > As for supporting Maven, I have developed the machinery to use Maven > artifacts > in ABCL-ASDF, and continued to maintain them (with help from users) even > as the > lurching horror that comprises Maven release engineering continues to > change > API semantics between patch level releases. I have offered to collaborate > with you on incorporating your initial work on building from Maven, > pointing > out the problems that I see with your approach to which I have received no > reply. > > As for supporting ?other technologies?, I suppose you are referring to your > attempt to merge abcl-contrib.jar and abcl.jar. In this effort, I pointed > out > you could do this cleanly with the current code by adding site-specific > code to > the ?system.lisp? file whose contents are controlled by the Ant build > process. > Since your Maven build doesn?t use the Ant target to package (one of my > explicit criticisms), you presumedly weren?t interested in using this > mechanism. I responded twice to your proposal to probe jar files on the > classpath for code to pontential load with suggestions which you found too > burdensome to discuss so you developed what you needed. Your email > announcing > this implementation implied you had implemented to a ?specification?, but > no > such entity existed external to the source code. If you wish to provide > such a > specification for your current implementation, please do so that others may > consider its usefulness. > > As to whether I control ABCL, I was going to reply that I am but one > maintainer > out of five; that you are welcome to convince a majority of the maintainers > through useful and accepted contributions that that you should be in > ?control? > too; and that since the code is GPL?d so you are welcome to get the fork > out of > here. But at this point, I would reply that if I do somehow ?control? > ABCL, I > am glad to protect it from idiots like you. > > -- > "A screaming comes across the sky. It has happened before but there is > nothing > to compare to it now." > > > > > >

5 7

Lisp filepath issues when running application directly from jar file
by Hamda Binte Ajmal 17 Aug '15

17 Aug '15

Hi, I was working on an application, that loads a few lisp files using lisp command (load "fullfilepath.lisp") from java using ABCL. This file in turn loads the other lisp files located in same folder hierarchy, and then i call lisp functions (defined in these files) from java and everything works perfect as long as I run the application from Netbeans. Close to deployment, I tested the application by running it from jar file, I found that there are issues with filepaths, as the files are not a part of file-system, and hence not accessible using a file-path. Does anyone has any idea how to fix this issue ? I tried many things, like URL url = LispConnector.class.getResource("/Aima/aima/quicklisp/setup.lisp");String path = url.getFile();File f = new File(path); path = f.getAbsolutePath(); path = path.replace("\\", "/"); which returns [image: enter image description here] But which is wrong as this is not a valid file path and does not exists so lisp : (load "filepath") fails here. When I use the code String path = url.toURI();File = new File(path); path = path.getAbsolutePath(); Again it works fine while running from netbeans, but shows error "URI is not hierarchical" error while running the jar file. Has anyone encountered this issue, please help. -- Hamda Binte Ajmal NUIG, Ireland

2 2

Re: Lisp filepath issues when running application directly from jar file
by Ralph Ritoch 16 Aug '15

16 Aug '15

Hello, Since you are loading resources and not from the filesystem you probably want to utilize the load-system-file function which I believe is provided by the :sys package. I'm not sure how portable this is so you may want to add some additional control logic if you want portability. (load-system-file "path/to/resource.lisp") Best Regards, Ralph Ritoch On Fri, Aug 14, 2015 at 8: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. Lisp filepath issues when running application directly from > jar file (Hamda Binte Ajmal) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 14 Aug 2015 11:20:18 +0100 > From: Hamda Binte Ajmal <hamda.binte.ajmal(a)gmail.com> > To: armedbear-devel(a)common-lisp.net > Subject: Lisp filepath issues when running application directly from > jar file > Message-ID: > <CAJEb= > LPJuCP6FJoTxuCGaapbo4FHdjnWdEf_QumgMJF-9BhHXQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > I was working on an application, that loads a few lisp files using lisp > command > (load "fullfilepath.lisp") from java using ABCL. > This file in turn loads the other lisp files located in same folder > hierarchy, and then i call lisp functions (defined in these files) from > java and everything works perfect as long as I run the application from > Netbeans. > Close to deployment, I tested the application by running it from jar file, > I found that there are issues with filepaths, as the files are not a part > of file-system, and hence not accessible using a file-path. > Does anyone has any idea how to fix this issue ? > I tried many things, like > > URL url = > LispConnector.class.getResource("/Aima/aima/quicklisp/setup.lisp");String > path = url.getFile();File f = new File(path); > path = f.getAbsolutePath(); > path = path.replace("\\", "/"); > > which returns [image: enter image description here] > > But which is wrong as this is not a valid file path and does not exists so > lisp : (load "filepath") fails here. > > When I use the code > > String path = url.toURI();File = new File(path); > path = path.getAbsolutePath(); > > Again it works fine while running from netbeans, but shows error "URI is > not hierarchical" error while running the jar file. > > Has anyone encountered this issue, please help. > > > -- > Hamda Binte Ajmal > NUIG, Ireland >

2 3

ABCL on jailbroken iPhone
by Vibhu Mohindra 12 Aug '15

12 Aug '15

My jailbroken iPhone has GNU classpath[0] and jamvm[1] installed. To get ABCL working with GNU classpath, I needed to patch two of classpath's classes as below. I patched and built classpath in a Linux VM, then extracted the two class files from the resulting glibj.zip and inserted them into the iPhone's /usr/share/classpath/glibj.zip . I've reported these modifications to: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67188 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67189 the latter of which may be an ABCL problem, not a GNU classpath one. (Performance: The ABCL REPL takes a few minutes to appear, but things look good when it does.) ref: [0] http://www.gnu.org/software/classpath/ [1] http://jamvm.sourceforge.net/ Vibhu diff -Naur classpath-0.99/java/math/BigInteger.java classpath-0.99.abcl/java/math/BigInteger.java --- classpath-0.99/java/math/BigInteger.java 2010-09-02 17:47:07.000000000 +0100 +++ classpath-0.99.abcl/java/math/BigInteger.java 2015-08-11 02:01:18.000000000 +0100 @@ -183,6 +183,7 @@ int i, digit; boolean negative; byte[] bytes; + if (len == 0) throw new NumberFormatException("zero length big integer"); char ch = s.charAt(0); if (ch == '-') { diff -Naur classpath-0.99/java/nio/charset/CharsetEncoder.java classpath-0.99.abcl/java/nio/charset/CharsetEncoder.java --- classpath-0.99/java/nio/charset/CharsetEncoder.java 2010-06-03 20:13:04.000000000 +0100 +++ classpath-0.99.abcl/java/nio/charset/CharsetEncoder.java 2015-08-12 12:16:13.000000000 +0100 @@ -159,8 +159,6 @@ // in progress" and also that "it resets this Encoder". // Should we check to see that the state is reset, or should we // call reset()? - if (state != STATE_RESET) - throw new IllegalStateException (); // REVIEW: Using max instead of average may allocate a very large // buffer. Maybe we should do something more efficient? @@ -199,9 +197,6 @@ // a return value indicating an incomplete decoding operation" // XXX: We will not check the previous return value, just // that the previous call passed true for endOfInput - if (state != STATE_RESET && state != STATE_CODING - && !(endOfInput && state == STATE_END)) - throw new IllegalStateException (); state = newState; for (;;)

1 0

Proposal to improve the loading of the abcl-contrib dependency.
by Ralph Ritoch 03 Aug '15

03 Aug '15

Hi, I have run into an issue with making executable abcl jars when the jar depends on, and provides, abcl-contrib. As far as I can tell abcl looks for abcl-contrib in the following locations. 1. Looks for a jar named abcl-contrib.jar in the classpath determined by probing the classloader for the jars it provides. 2. Looks in the directory of the jars in the classpath for a file named abcl-contrib.jar Neither of these solutions work if the currently executing jar includes abcl-contrib and isn't named abcl-contrib.jar. The following code proves that it is relatively easy to add this capability. (in-package 'sys) (sys:add-contrib (make-pathname :defaults (java:jcall "toString" (svref (java:jcall "getURLs" (sys:boot-classloader)) 0)))) This code properly loads abcl-contrib when the executing jar provides abcl-contrib, while (require 'abcl-contrib) does not. My proposal is to add a file named abcl-contrib/version.lisp to the abcl-contrib.jar, possibly in the /META-INF directory to avoid any potential conflicts with java, and to have sys:find-contrib look for this file in the resources provided by the classpath. The contents of this file is not important. This change makes it possible to include the abcl-contrib "dependency" directly inside the jar application that is currently running, regardless of the name of the jar file. Therefore, applications which make use of abcl-contrib can be distributed as a single jar. For maven users, this means that their uberjars will work by just including abcl and abcl-contrib as dependencies. For ant users they would probably need to extract abcl-contrib and include the extracted files in their generated jar which I believe can be fully automated. It would be relatively easy for me to produce a patch to provide this feature as part of ABCL. It may be possible to provide this feature as an add-on, but the functions needed within the system package are private (not exported) so it would be difficult, if not impossible, to implement this feature as an add-on. I would like your feedback on this issue. If this is a feature you want, or if you have any specific objections to including this feature in ABCL, please let me know. Best Regards, Ralph Ritoch

2 11

Build ABCL with Maven using these updated POM files.
by Ralph Ritoch 03 Aug '15

03 Aug '15

Hi, I have created some maven POM files which can be used to build and deploy ABCL with maven. There have been a few modifications to these over the past few days and there is probably room for improvement but these make it possible to build and depoy ABCL with the normal maven lifecycle. Included are the following pom.xml => abcl\pom.xml (abcl-parent) main-pom.xml => abcl\main\pom.xml (abcl) contrib-pom.xml => abcl\contrib\pom.xml (abcl-contrib) Note: Filenames are relative to the trunk so they include the abcl prefix. These have been posted as a gist on github at https://gist.github.com/rritoch/70f9f211c523499b794a I have tested by deploying to my localrepo and the abcl artifact is functional. Additional work may be needed on the abcl-contrib artifact POM because I'm unsure how to test it. The file size is similar to the one generated by ant so it may be correct. Best Regards, Ralph Ritoch

2 4

Are you looking for an idea for an ABCL project?
by Ralph Ritoch 01 Aug '15

01 Aug '15

Hi, I was invited by someone in the virt.x community to add ABCL to the virt.x project http://vertx.io/ . I don't foresee having the time to do the integration this year but if anyone is interested it looks like there are many in the Java development community who are interested in using common-lisp in their JVM applications. The virt.x system supports maven and integration with vert.x will most likely require that the maven integration issues, including integration of abcl-contrib from the classpath (maven) be resolved before integration will be possible. I don't currently use virt.x but it looks like a good system for large teams with diverse programming backgrounds. Best Regards, Ralph Ritoch

1 0

bug?
by Alejandro Zamora Fonseca 27 Jul '15

27 Jul '15

Hi! Just now playing a little with ABCL(1.3.2), I saw some strange behaviour: CL-USER> '(2 . 5) (2 . 5) CL-USER> '(2 . 5 . 5) (2 . 5) CL-USER> (equal '(2 . 5) '(2 . 5 . 5)) T while other implementations give me an error when i type '(2 . 5 . 5) it's a bug or ANSI CL allows this? greetings, Alejandro -- Este mensaje le ha llegado mediante el servicio de correo electronico que ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema Nacional de Salud. La persona que envia este correo asume el compromiso de usar el servicio a tales fines y cumplir con las regulaciones establecidas Infomed: http://www.sld.cu/

3 2

Bordeaux-threads issues
by Stelian Ionescu 22 Jul '15

22 Jul '15

Hi, can somebody take a look at the Bordeaux-threads support for ABCL? The test suite hangs on Travis-CI.org during automatic tests so I guess there's something wrong there. TraviCI runs Ubuntu 12.04 LTS on x86_64. Thanks. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur.

3 7

ASDF 3.1.5 released
by Robert Goldman 21 Jul '15

21 Jul '15

1 0

Getting Java Class objects, and JSS
by John Pallister 08 Jul '15

08 Jul '15

Hello list, I'm working on getting ABCL + the Jetty <http://www.eclipse.org/jetty> web server + SLIME working together as a development environment for Google App Engine web apps[1]. This seems to be what the Clojure people have done <http://www.hackers-with-attitude.com/2009/08/intertactive-programming-with-…>: run your own Jetty server & SWANK server, then load the GAE JARs to provide the same emulated services as the GAE SDK's development server. I've been working through the "Embedding Jetty" tutorials[2] and making reasonable progress (with help from Mark Evenson and others on #abcl - thanks Mark!). I've been doing it all in Lisp (so far), making my own servlet classes using JNEW-RUNTIME-CLASS. Ideally I'd like to make an ABCL library equivalent to (a subset of) Compojure <https://github.com/weavejester/compojure> (and appengine-magic <https://github.com/gcv/appengine-magic>). Some of the tutorials have code like: context.addServlet(HelloServlet.class, "/"); Is it possible to get Class objects for Java classes I've made with JNEW-RUNTIME-CLASS (or indeed for any other Java class)? I've been using "raw" JCLASS & JMETHOD etc. calls to experience just how painful that really is, but I'm apprehensive about using JSS <http://abcl.org/trac/browser/trunk/abcl/contrib/jss/README.markdown> and paying the runtime dynamic dispatch penalty, given that on GAE time is money. Something more like a SLIME plug-in that looked up & cached classes, methods & fields at editing time (perhaps also parsing Java expressions) and generated "statically typed" code would be nice (possibly using code from e.g. JDEE <http://emacswiki.org/emacs/JavaDevelopmentEnvironment> and/or CEDET <http://cedet.sourceforge.net/>) - has anyone else thought about this? Cheers, John :^P (hoping HTML email to the list isn't a social faux pas) [1] I have a page of initial notes and links at https://johnp.net/jpkb/wiki/AbclOnGae [2] https://wiki.eclipse.org/Jetty/Tutorial/Embedding_Jetty, http://www.eclipse.org/jetty/documentation/current/embedding-jetty.html -- John Pallister john(a)johnp.net john(a)synchromesh.com

3 3

Licensing Issues
by Hamda Binte Ajmal 04 Jul '15

04 Jul '15

Hello, I am using ABCL to run lisp files in my Java code. ABCL is covered by the GNU General Public License with Classpath exception, meaning that you can use ABCL in your application without the requirement to open the sources to your application. So, I conclude the GNU GPL is not going to effect the license of my Java Code, BUT, what about the lisp code I load using ABCL? Would it have to be released under GNU GPL ? Regards, Hamda

7 23