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

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