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

[armedbear-devel] readtable-case :invert does not invert uninterned symbols
by Ole Arndt 16 Aug '11

16 Aug '11

This prevents loading a newer parenscript, which uses an inverted readtable case via named-readtables: Armed Bear Common Lisp 0.26.0-dev-svn-13273 Java 1.6.0_17 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.712 seconds. Startup completed in 3.154 seconds. Type ":help" for a list of available commands. CL-USER(1): (setf (readtable-case *readtable*) :invert) :invert CL-USER(2): (string :cl) "CL" CL-USER(3): (string '#:cl) "cl" Cheers Ole -- Ole Arndt http://www.sugarshark.com

3 5

[armedbear-devel] [ANNOUNCE] ABCL 0.26.1 released
by Erik Huelsmann 30 Jul '11

30 Jul '11

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.26.1 release. ABCL is a Common Lisp implementation implemented in Java and running on the JVM, featuring both an interpreter and a compiler. The compiler targets the JVM directly meaning that its output is runnable JVM bytecode. The fact that ABCL is written in Java allows for relatively easy embedding in larger applications. For integration with existing applications ABCL implements JSR 223: Java scripting API. This release features - among lots of other things - a major reduction in the number of failures in the ANSI test suite: dropping from 26 to 16 failures on some systems (of 21699 tests in total). Additionally, ABCL now runs Hunchentoot and several other packages from the top downloads from Quicklisp. http://common-lisp.net/project/armedbear/release-notes-0.26.shtml and the list of changes at: http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES If you have questions regarding use or licensing, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net Source distribution archives can be downloaded in ZIP or gzipped tar form: http://common-lisp.net/project/armedbear/releases/0.26.1/abcl-src-0.26.1.ta… http://common-lisp.net/project/armedbear/releases/0.26.1/abcl-src-0.26.1.zip Signatures are available under: http://common-lisp.net/project/armedbear/0.26.1/releases/abcl-src-0.26.1.ta… http://common-lisp.net/project/armedbear/0.26.1/releases/abcl-src-0.26.1.zi… In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/0.26.1/abcl-bin-0.26.1.ta… http://common-lisp.net/project/armedbear/releases/0.26.1/abcl-bin-0.26.1.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.26.1.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.26.1.zip.asc

2 2

[armedbear-devel] Release 0.26.1 -- status?
by Erik Huelsmann 27 Jul '11

27 Jul '11

The two issues below have been fixed and a few other issues which were resolved in the mean time have been backported to 0.26.1 as well. I was able to build the binaries using the abcl.release target (instead of using the separate abcl.binary.* targets), so it seems all our issues are now fixed and we can move to 0.26.1 next week. Is there anybody with any remaining issues or fixes up his sleeve? Anybody wants to report an issue with the current 0.26.x branch? If not, I'm planning to roll the 0.26.1 release mid next week. Bye, Erik. On Mon, Jul 11, 2011 at 10:18 PM, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi, > > On Mon, Jul 11, 2011 at 7:51 PM, Mark Evenson <evenson(a)panix.com> wrote: > >> On 7/10/11 12:53 AM, Erik Huelsmann wrote: >> >>> I've created the 0.26 release branch after updating CHANGES. >>> >>> If there are no further objections, I'll continue the release process by >>> signing the release. >>> >>> It'd be very helpful if one of the other committers can update the >>> webpages, as I won't have time to do that today or tomorrow. >>> >> >> Unfortunately, the abcl-0.26.0-src release won't build because that >> archive is missing the newly added org.armedbear.lisp.protocol package. >> >> [Fixed and backported to the abcl-0.26.x branch][1]. >> >> [1]: http://trac.common-lisp.net/**armedbear/changeset/13391<http://trac.common-lisp.net/armedbear/changeset/13391> >> >> My vote would be to figure out the stack overflow reported in [ticket >> #154][2] as well as whatever is causing the ansi-interpreted errors that >> Ville is noticing, and move to releasing an abcl-0.26.1. >> >> [2]: http://trac.common-lisp.net/**armedbear/ticket/154<http://trac.common-lisp.net/armedbear/ticket/154> >> >> Erik is on his first day of vacation, and probably has limited upload >> bandwidth, so we may be a bit constrained here. >> > > Yea, it'd be very convenient for me to fix any remaining issues and go for > a 0.26.1 in 2 weeks. Also because my signing key is most easily operated at > home. > > Let's take some time to solve these regressions and scrap the brown paper > bag release :-) > > > Bye, > > > Erik. >

3 3

[armedbear-devel] Adjustable arrays and Java
by Theam Yong Chew 20 Jul '11

20 Jul '11

Hi all, I might have found an interop issue with adjustable arrays. First create an adjustable array with some "empty unfilled space". (defparameter *arr* (let ((x (make-array 0 :fill-pointer 0 :adjustable t :element-type 'base-char))) (vector-push-extend #\a x) (vector-push-extend #\b x) (vector-push-extend #\c x) (vector-push-extend #\d x) x)) Pass the array into Java and copy it back into Lisp. CL-USER> (jcall "getText" (jnew "javax.swing.JButton" *arr*)) "abcd^@^@^@" CL-USER> (jcall "getText" (jnew "javax.swing.JButton" (copy-seq *arr*))) "abcd" I've hand edited the above -- the ^@ character is actually a #\Null of course. More examples: CL-USER> (jnew "java.lang.String" *arr*) #<java.lang.String abcd^@^@^@ {F10A53}> Yong.

2 2

[armedbear-devel] Anybody going to ECLM (Amsterdam) in October?
by Erik Huelsmann 18 Jul '11

18 Jul '11

This morning, I completed my own registration process for my own entry. Will I be seeing any other ABCL users/ developers? Bye, Erik.

3 2

[armedbear-devel] The purpose of the writeToString() method (before we can rename it to printObject() or anything else)
by Erik Huelsmann 17 Jul '11

17 Jul '11

Today I thought I'd address ticket #160. That ticket is about %OUTPUT-OBJECT (a primitive) checking the string returned for the non-readable "#<" marker. The problem is that it'll raise a PRINT-NOT-READABLE error on any output containing that marker, even if it's part the serialized presentation which *is* readable, like the uninterned symbol #:|#<32|. The solution I'm aiming at is to make every writeToString() method raise an error when it can't return a readable representation when a readable representation is requested. In preparation of this change I'm investigating the uses of writeToString(). There are 213 occurrences of the string ".writeToString()", many of which are related to the creation of error messages. It'd be particularly impractical to generate errors while creating an error message. On the other hand, there are also uses, such as the one by %OUTPUT-OBJECT which typically *should* obey those values and generate the PRINT-NOT-READABLE error accordingly. So, simply renaming writeToString() to printObject() is still an option. We can even make the printObject() functions check whether they are allowed to return unreadable output. However, it seems to me we additionally need a function which returns - optionally unreadable - output without generating errors. I'm thinking of a function which resets the variables to the values WITH-STANDARD-IO-SYNTAX except that it binds *PRINT-READABLY* to NIL. Maybe that function should be called printUnreadableObject() or something alike. I've also thought about renaming writeToString() to printObjectInternal() and creating a new printObject(boolean requireReadable) which does the required work if the argument is true. Hmm. I hope the above is something people want to comment on. At least I've tried to describe my findings so far. I'm interested to know what others think. Bye, Erik.

1 1

[armedbear-devel] Fixing PRINT.RANDOM-STATE.1
by Erik Huelsmann 17 Jul '11

17 Jul '11

Today I was looking at fixing some of our PRINT.* failures in the ansi test suite. Hoping to get an easy start, I started looking PRINT.RANDOM-STATE.1 The problem shown by the test is that our RANDOM-STATEs are not printable. From the perspective of ABCL, that's logical: Java's Random objects are serializable, but as everywhere in Java, it's serialization is internal to the implementation. The Random object is initialized using a 'seed' long value, but there's no way to extract a 'seed' value from the object to be used to initialize an object into the same state. So, I'm now pondering what action to take. I'm seeing several options: 1. build our own pseudo random number generator with its own random state 2. serialize the Random object to a byte array and use that array as some sort of printed representation (sure, we'll definitely need to look into ways to load) The advantage of (1) is that we can create it all in Lisp, however, it's pure additional code, since we won't be leveraging what's already there. The advantage of (2) is that we can use what Java maintains for us and even better: we can use the random number generator shared between Lisp and Java code. I imagine the disadvantage of this solution is that the serialization of the random state can differ between Java versions and implementations. Any ideas?? Bye, Erik.

4 6

Re: [armedbear-devel] [armedbear-cvs] r13407 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 16 Jul '11

16 Jul '11

This commit fixes a number of test cases related to circularity detection. Some of these cases showed loss of data. Even in the remaining failures, there's no longer any loss of data. The cases that still fail do however show loss of structure. That's on my list to be fixed. As it stands, I'm very happy to finally be fixing this long standing issue in our pretty printer. Bye, Erik. On Fri, Jul 15, 2011 at 11:18 PM, <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Fri Jul 15 14:18:28 2011 > New Revision: 13407 > > Log: > Eliminate a series of PPRINT.* ansi test suite failures > (dropping my test failure count from 27 to 20!). > > Modified: > trunk/abcl/src/org/armedbear/lisp/pprint.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/pprint.lisp > > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/pprint.lisp Fri Jul 15 09:34:23 > 2011 (r13406) > +++ trunk/abcl/src/org/armedbear/lisp/pprint.lisp Fri Jul 15 14:18:28 > 2011 (r13407) > @@ -611,12 +611,14 @@ > (if (xp-structure-p stream) > (apply fn stream args) > (let ((*abbreviation-happened* nil) > - (sys::*circularity-hash-table* > - (if (and *print-circle* (null sys::*circularity-hash-table*)) > - (make-hash-table :test 'eq) > - sys::*circularity-hash-table*)) > (*result* nil)) > - (xp-print fn (sys:out-synonym-of stream) args) > + (if (and *print-circle* (null sys::*circularity-hash-table*)) > + (let ((sys::*circularity-hash-table* (make-hash-table :test > 'eq))) > + (xp-print fn (make-broadcast-stream) args) > + (let ((sys::*circularity-counter* 0)) > + (xp-print fn (sys:out-synonym-of stream) args) > + )) > + (xp-print fn (sys:out-synonym-of stream) args)) > *result*))) > > (defun xp-print (fn stream args) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] RfC: Renaming LispObject.writeToString() to LispObject.printObject()
by Erik Huelsmann 15 Jul '11

15 Jul '11

Yesterday, we fixed #154 -- the PRINT-OBJECT regression in 0.26.0. Once again, it turns out that our object printing and stringification routines are confusingly named. Additionally, they are also under documented: The writeToString() method calls toString(), but doesn't document the difference between the two. My idea would be to disambiguate the two functions by making writeToString() a java-side PRINT-OBJECT, renaming it to printObject() and documenting that's what it does. Then, probably, the lisp side function %write-to-string should be renamed to %print-object too. Probably, more adjustments are required throughout the code base, but those are probably at the 'implementation detail' level. So, what's your take on it? Bye, Erik.

3 6

[armedbear-devel] Problems with making binary release?
by Mark Evenson 13 Jul '11

13 Jul '11

Erik reported problems making a binary release yesterday on #abcl related to the presence of the version information in the "build/classes/org/armedbear/lisp/version" file. I did indeed change the build process to try to be smarter about needing to create this file by creating the 'abcl.stamp.version.uptodate' task to compare the date of this file to the corresponding class of Version.java. But I can't reproduce a problem here via various permutations of manually removing the file, updating the timestamps of various files via touch(1), etc. If someone can provide instructions to reproduce the error here, I will endeavor to fix it. Maybe this is a problem under MSFT Windows environments? P.S. In looking over the build.xml code, I notice that the use of setting the 'abcl.version' system property to override is slightly sub-optimal which I will fix as well. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2