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

destructuring-bind not signaling error with &rest
by 2l8qyo+d734u52o8x7j0＠guerrillamail.com 22 Dec '15

22 Dec '15

(destructuring-bind (a b &rest c) '(1) b) => nil with no error. sbcl, clisp, and ecl signal an error. http://clhs.lisp.se/Body/m_destru.htm seems to suggest it should be an error. version is abcl 1.3.3 on jdk 1.8.0_66 ---- Sent using GuerrillaMail.com Block or report abuse: https://www.guerrillamail.com/abuse/?a=QFN5AAkCRrUHxQqx5nsTUhfIQMef3JpczrdS…

1 0

ASDF configuration for "JAR-only" system
by John Pallister 16 Dec '15

16 Dec '15

Hello list, I'm trying to configure ASDF to load my application while running within the Google App Engine development server (Jetty 6.1). My Ant build script uses ASDF-JAR:PACKAGE to produce a single JAR file containing my application and all dependencies, and copies this to the war/WEB-INF/lib/ directory so that it's in the classpath. At runtime (in a separate bootstrap.lisp file), following the example of ASDF-JAR:ADD-TO-ASDF[1], I search the application JAR file (obtained by grovelling JAVA:DUMP-CLASSPATH) for the .ASD files and push them all onto ASDF:*CENTRAL-REGISTRY*. So far so good. (Having read the ASDF manual I now know I should either build a .cl-source-registry.cache file into the JAR or compute an ASDF source registry configuration and include that.) When ASDF starts up it tries to read various configuration files from the filesystem, for both the source registry and for its output translations. This isn't allowed by App Engine. On #lisp, Attila Lendvai suggested that giving ASDF a source registry configuration of '(:SOURCE-REGISTRY :IGNORE-INHERITED-CONFIGURATION) should suppress this behaviour, and it does seem to work. Now I'm struggling to get the output translations to work. Based on ADD-TO-ASDF again I'm using an output translations configuration of: `(:output-translations (,(merge-pathnames "/**/*.*" *application-jar-path*)) ; => #P"/**/*.*" :ignore-inherited-configuration :disable-cache) My *APPLICATION-JAR-PATH* is #P"jar:file:/Volumes/SoftRAID/Users/john/src/synchromesh/forumfeedme/war/WEB-INF/lib/forumfeedme-lisp-0.1.0.jar!/", i.e. a pathname with the JAR path as the PATHNAME-DEVICE. With this I get the error "access denied ("java.io.FilePermission" "/___jar___file___root___" "read")". This matches the default translations seen in asdf.lisp:WRAPPING-OUTPUT-TRANSLATIONS: (defun wrapping-output-translations () `(:output-translations ;; Some implementations have precompiled ASDF systems, ;; so we must disable translations for implementation paths. #+(or #|clozure|# ecl mkcl sbcl) ,@(let ((h (resolve-symlinks* (lisp-implementation-directory)))) (when h `(((,h ,*wild-path*) ())))) #+mkcl (,(translate-logical-pathname "CONTRIB:") ()) ;; All-import, here is where we want user stuff to be: :inherit-configuration ;; These are for convenience, and can be overridden by the user: #+abcl (#p"/___jar___file___root___/**/*.*" (:user-cache #p"**/*.*")) #+abcl (#p"jar:file:/**/*.jar!/**/*.*" (:function translate-jar-pathname)) ;; We enable the user cache by default, and here is the place we do: :enable-user-cache)) Although I don't understand exactly how the "JAR file as device" (JFAD) translations are supposed to work, one thing that struck me as odd while investigating things was this: CL-USER> (make-pathname :device (list #P"/foo.jar")) #P"jar:file:/foo.jar!/" CL-USER> (merge-pathnames "**/*.*" *) #P"jar:file:/foo.jar!/**/*.*" CL-USER> (merge-pathnames "/**/*.*" **) #P"/**/*.*" CL-USER> (pathname-directory **) (:RELATIVE :WILD-INFERIORS) CL-USER> (pathname-directory **) (:ABSOLUTE :WILD-INFERIORS) That is, merging a relative path with the (absolute) JFAD path retained the default JAR file "device" (and remains a relative path, which ASDF won't accept), but merging an absolute path reset the device component. I've read through the documentation for MERGE-PATHNAMES in the HyperSpec[2] and AFAICT the device component should be copied across. I'm reasonably confident that if it were, things would work better. But I could be (doubly) wrong. I am trying to figure this out for myself, but I'm stuck for now, so I'm hoping someone (i.e. Mark) can, on reading this, offer some guidance as to where I should go from here. I haven't (yet) tried posting to the ASDF mailing list as this seems like a fairly ABCL-specific issue. I guess the fallback is to unpack the application JAR and just load the FASLs directly, but (based again on ADD-TO-ASDF) I'm pretty sure that this should work, and it does seem to be the Right Thing. Any or all comments and/or advice appreciated, Cheers, John :^P [1] http://abcl.org/trac/browser/trunk/abcl/contrib/asdf-jar/asdf-jar.lisp [2] http://www.lispworks.com/documentation/HyperSpec/Body/f_merge_.htm#merge-pa… -- John Pallister john(a)johnp.net john(a)synchromesh.com

2 3

Package-local nicknames
by Alessio Stalla 09 Dec '15

09 Dec '15

Hello list, long time no see :) I'm once again experimenting on ABCL with a sort of a pet peeve of mine: hierarchical symbols (aka symbols as packages aka symbol/package conflation). If I get good results I'll submit an article to the next ELS. Btw, is anyone going? I've seen that, since the time when I was actively contributing to it, ABCL has gained package-local nicknames (or, they were already there and I never noticed or I forgot about them). Since my experiment is, I suppose, a superset of what said nicknames have to offer, I'm curious: is anybody using them? How? Are they a novel idea of ABCL's, or were they inspired by other implementations? Do they implement some specification (e.g., a CDR)? Thanks for any input! Cheers Alessio

5 7

ABCL-JAR issues & patch
by John Pallister 24 Nov '15

24 Nov '15

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). For the original code, see http://abcl.org/trac/browser/trunk/abcl/contrib/asdf-jar/asdf-jar.lisp?rev=… 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 http://abcl.org/trac/browser/trunk/abcl/src/org/armedbear/lisp/zip.java?rev… "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... Cheers, John :^P -- John Pallister john(a)johnp.net john(a)synchromesh.com

1 1

Creating a Lisp stream from a java.io.Reader
by John Pallister 24 Nov '15

24 Nov '15

Hello list, I'm trying to get Clack (http://clacklisp.org/) 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 java-stream '(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. Cheers, John :^P -- John Pallister john(a)johnp.net john(a)synchromesh.com

4 6

Reports of problems in binding/connecting to localhost for testing http servers (clack, hunchentoot)
by Mark Evenson 21 Nov '15

21 Nov '15

[Something in the USOCKET code seems to have problems interpreting ip6 addresses with ABCL…][40]. [40]: http://abcl.org/trac/ticket/40 -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 1

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 18 Oct '15

18 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