John Pallister | 24 Nov 12:25 2015

ABCL-JAR issues & patch

Hello list,

I've been trying to use ABCL-JAR to package up my app for deployment to Google App Engine. I've come across a few issues; any comments would be appreciated. I've attached a patch to the ABCL-JAR:PACKAGE function that Works For Me(TM).

First, there was an issue where if the ROOT parameter is NIL the function would fail at line 90.

Second, The SYSTEM:ZIP function didn't want to nest JARs within the new JAR, so systems that depended on e.g. JSS via abcl-contrib.jar would fail. I filter out files in JARs on the assumption that one will just distribute those JARs along with the new one.

Third, my ASDF file includes a system that looks like:

(asdf:defsystem #:gabacle-clack-java
  :defsystem-depends-on (#:abcl-asdf)
  :version "0.1"
  :description "Java interface classes for Gabacle/Clack."
  :depends-on ()
  :components ((:module java-src
:pathname "src/"
:components ((:class-file-directory "java")))))

This may or may not be good style, but it seems to be legal. When traversing the ASDF files, the class file directory component comes back with a PATHNAME-TYPE of :UNSPECIFIC, so I filter such entries out so that SYSTEM:ZIP doesn't object.

On a minor note, at "incorporation" is spelled "incoporation".

I hope this is useful. If people could point out where I've just got the wrong end of the stick, that would be great...


--- asdf-jar.lisp <at> 14695	2015-11-24 10:29:22.000000000 +0000
+++ asdf-jar.lisp-jdp	2015-11-24 11:03:57.000000000 +0000
 <at>  <at>  -56,23 +56,26  <at>  <at> 
       (format verbose "~&Packaging contents in ~A" package-jar))
     (when (and verbose recursive dependencies) 
       (format verbose "~&  with recursive dependencies~{ ~A~^, ~}." dependencies))
+    (flet ((set-mapping (from to)
+	     (unless (string-equal (subseq (namestring from) 0 4) "jar:")
+	       (setf (gethash from mapping) to))))
     (dolist (system (append (list system) 
                             (when recursive 
                               (mapcar #'asdf:find-system dependencies))))
       (let ((base (slot-value system 'asdf::absolute-pathname))
             (name (slot-value system 'asdf::name))
             (asdf (slot-value system 'asdf::source-file)))
-        (setf (gethash asdf mapping) (let ((relative-path (archive-relative-path 
-                                                           base name asdf)))
+	  (set-mapping asdf (let ((relative-path (archive-relative-path base name asdf)))
                                        (if root
-                                         (merge-pathnames
-                                          relative-path
+				  (merge-pathnames relative-path
                                           (make-pathname :directory root))
         (loop :for component :in (all-files system) 
            :for source = (slot-value component 'asdf::absolute-pathname)
            :for source-entry = (archive-relative-path base name source)
-           :do (setf (gethash source mapping)
+	     :when (stringp (pathname-type source))
+	     :do (set-mapping source
                      (if root 
                          (merge-pathnames source-entry (make-pathname :directory root))
 <at>  <at>  -80,19 +83,19  <at>  <at> 
                  (format verbose "~&~A~& => ~A" source source-entry))
            :when (and (typep component 'asdf::source-file)
                       (not (typep component 'asdf::static-file)))
-           :do (let ((output 
-                      (make-pathname
-                       :defaults (asdf:apply-output-translations source)
+	     :do (let* ((output 
+			 (make-pathname :defaults (asdf:apply-output-translations source)
                        :type "abcl"))
+			(directory (pathname-directory source-entry))
                       (make-pathname :defaults source-entry 
                                      :type "abcl"
-                                     :directory (append root
-                                                        (rest (pathname-directory source-entry))))))
+					:directory (if root
+						       (append root (rest directory))
+						       directory))))
                  (when *debug*
                    (format verbose "~&~A~& => ~A" output output-entry))
-                 (setf (gethash output mapping)
-                       output-entry)))))
+		   (set-mapping output output-entry))))))
     (system:zip package-jar mapping)))

 (defun all-files (component)
Mark Evenson | 21 Nov 14:56 2015

Reports of problems in binding/connecting to localhost for testing http servers (clack, hunchentoot)

[Something in the USOCKET code seems to have problems interpreting ip6
addresses with ABCL…][40].



"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

Mark Evenson | 21 Nov 11:19 2015

Re: Creating a Lisp stream from a

On 2015/11/20 23:24, Anton Vodonosov wrote:
> John, don't forget to publish your results when you have clack working with ABCL

Note that Clack *does* currently seem to work with ABCL, at least [the
simple test on the clack home page][1].  It wasn't immediately obvious
how to run a clack test suite  as

    (asdf:test-system :clack)

doesn't seem to do anything.

John is trying to get clack to run in the Google App Engine, which is a
decidedly non-standard JVM.  Go John!



"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

John Pallister | 18 Nov 23:23 2015

Creating a Lisp stream from a

Hello list,

I'm trying to get Clack ( running on Google App Engine which means doing a Java Servlets back-end. Clack expects a :RAW-BODY request header that is an input stream, and the HTTPServletRequest object I receive from the Jetty web server inherits a getReader() method (for a character stream) and a getInputStream() method (for a binary stream).

Looking at the "reference implementation" (i.e. Hunchentoot), it creates a FLEXI-STREAM so that any HTTP "Content-Length" header can be used to set the bound on the stream. So based on that, and an IRC chat with Mark E., and some scratch code, I've come up with this to create a FLEXI-STREAM from the HTTPServletRequest:

(defconstant +latin-1+
  (make-external-format :latin1 :eol-style :lf)
  "A FLEXI-STREAMS external format used for `faithful' input and
output of binary data (via hunchentoot/specials.lisp).")

(defun make-stream-for-request (req content-length)
  "Construct a Lisp input flexi-stream from the binary stream provided
by the HTTPServletRequest. Set the bound of the stream to the value of
the Content-Length header, if any."
  (let* ((java-stream (#"getInputStream" req))
(lisp-stream (jss:new :|lisp.Stream|
      (jss:get-java-field :|lisp.Symbol| "SYSTEM_STREAM") ; structureClass
      '(unsigned-byte 8)))) ; elementType
    (make-flexi-stream lisp-stream
      :external-format +latin-1+
      :bound content-length)))

We agreed that there's not much documentation around this, hence this email.


John :^P
Scott L. Burson | 2 Nov 04:39 2015

Encode/decode-universal-time and DST


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

Mark Evenson | 24 Oct 18:16 2015

JEP 276: Dynamic Linking of Language-Defined Object Models

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].



"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

Robert Goldman | 18 Oct 04:25 2015

ASDF 3.1.6 is released

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

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
  * 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 <at>>  Sat, 17 Oct 2015 15:01:34 -0500

Andrew Pennebaker | 9 Oct 00:25 2015

Maven plugin for compiling to bytecode?

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

Didier Verna | 7 Oct 18:10 2015

[CfP] European Lisp Symposium 2016, May 9-10, Kraków, Poland

		 ELS'16 - 9th European Lisp Symposium
	       AGH University of Science and Technology
			    Kraków, Poland

			    May 9-10, 2016

		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: and

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:

Lisp, Jazz, Aïkido:

Mark Evenson | 15 Sep 11:02 2015

Pointing out ABCL "extensions" to ANSI-TEST

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.



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.


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.



"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."

Stefan Husmann | 9 Sep 21:34 2015

Typo in last commit on svn


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
 <at>  <at>  -877,5 +877,5  <at>  <at> 

-[1]: <git+>
+[1]: 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.