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

[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

Re: [armedbear-devel] [armedbear-cvs] r13381 - trunk/abcl
by Erik Huelsmann 11 Jul '11

11 Jul '11

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. Bye, Erik. On Sun, Jul 10, 2011 at 12:49 AM, <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Sat Jul 9 15:49:04 2011 > New Revision: 13381 > > Log: > Update CHANGES with 0.26.0 items. > > Modified: > trunk/abcl/CHANGES > > Modified: trunk/abcl/CHANGES > > ============================================================================== > --- trunk/abcl/CHANGES Fri Jul 8 01:40:37 2011 (r13380) > +++ trunk/abcl/CHANGES Sat Jul 9 15:49:04 2011 (r13381) > @@ -1,3 +1,91 @@ > +Version 0.26.0 > +============== > +svn://common-lisp.net/project/armedbear/svn/tags/0.26.0/abcl > +(?? ???? 2011) > + > +Features > +-------- > + > + * Add support for weak reference objects > + > + * Add support for finalizers on LispObject derived classes > + > + * Upgrade ASDF to 2.0.16.1 > + > + * #\ reader macro now understands #\uNNNN as unicode codepoints > + > + * JAVA:JRESOLVE-METHOD returns same method as would have been > + called by JAVA:JCALL with the same arguments > + > + * Ant 'update' target to upload application to Google App Engine > + > + * Simple RUN-PROGRAM implementation > + > + * Support for custom slot definitions according to AMOP > + > + * New JAVA:*JAVA-OBJECT-TO-STRING-LENGTH* variable to control pretty > + printing of Java objects > + > + * JSS - more dynamic Lisp/Java FFI - ( > http://lsw2.googlecode.com/svn/trunk) > + imported > + > + * (REQUIRE :ABCL-CONTRIB) adds 'abcl-contrib.jar' to the ASDF search path > + > + * Support for weak references in hash tables through a :WEAKNESS keyword > + argument to MAKE-HASH-TABLE; with SYS:HASH-TABLE-WEAKNESS for > inspection > + > + * Support for loading ASDF systems from JAR archives > + > + * Fast SHA1, SHA256 and SHA512 cryptographic hashes for files > + > + * Beginnings of a manual > + > + * ABCL/ASDF integration with Maven provided systems > + > + * ASDF-JAR:PACKAGE function to package ASDF systems into JARs > + > +Changes > +======= > + > + * Reduced code size in the compiler by changing COMPILE-TEST-FORM > + > + * Enhanced SLIME inspector for JAVA:JAVA-OBJECT > + > + * Reimplemented MERGE-PATHNAMES > + > + * TRANSLATE-PATHNAME aligned with SBCL's behaviour if version is wild > + > + * Removed PRINT-OBJECT methods duplicating Java side code > + > + * Refactored code in SYSTEM:ZIP function > + > + * Allow JCOERCE to convert any number to java.lang.Byte (using > + its two's complement) > + > + * Replace MAKE-IMMEDIATE-OBJECT with +NULL+, +TRUE+ and +FALSE+ constants > + (the only supported ones) > + > + * Better separation between java-collections package and Java FFI > + > + * JAVA:ADD-TO-CLASSPATH is now a generic function > + > +Fixes > +===== > + > + * Google App Engine example fixed > + > + * MAKE-PATHNAME erroneously merges directories as in MERGE-PATHNAME > + > + * Pretty printer routines using SYS:OUTPUT-OBJECT with GRAY-STREAM > + > + * Value of *PRINT-CASE* affects file (to FASL) compilation > + > + * MAKE-PATHNAME ignores version in :DEFAULTS > + > + * URI decoding algorithm in Pathname.java > + > + * JNEW-ARRAY-FROM-ARRAY should create byte[] arrays > + > Version 0.25.0 > ============== > svn://common-lisp.net/project/armedbear/svn/tags/0.25.0/abcl > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

3 5

[armedbear-devel] Spaces in pathnames (jar:file:/x/y/z/a space/...)
by Theam Yong Chew 11 Jul '11

11 Jul '11

Dear ABCL developers, While ABCL can handle spaces (& others) in file pathnames just fine, a space in jar file pathnames still doesn't work. I have confirmed this on Linux, Mac and Windows. An example using Cygwin, $ java -jar abcl.jar Armed Bear Common Lisp 0.24.0 Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.625 seconds. Startup completed in 4.438 seconds. Type ":help" for a list of available commands. CL-USER(1): (load "jar:file:e:/My Dropbox/temp/a space/hello.jar!/hello.abcl") #<THREAD "interpreter" {9AC0F5}>: Debugger invoked on condition of type FILE-ERROR Failed to create URI from 'e:/My Dropbox/temp/a space/hello.jar': Illegal character in opaque part at index 10: file:e:/My Dropbox/temp/a space/hello.jar Restarts: 0: TOP-LEVEL Return to top level. (and yeah, this particular path already has a space character in "My Dropbox" along with my original intended "a space" folder) By the way, thanks for the :wildcard directory support (I've only just tested that, it works for me now!). Yong.

4 15