armedbear-devel

armedbear-devel@common-lisp.net

1 participants
1200 discussions

[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

[armedbear-devel] IRONCLAD cannot be compiled on ABCL now
by Chun Tian (binghe) 08 Jul '11

08 Jul '11

Hi, ABCL developers The crypto library IRONCLAD [1] cannot be compiled on latest ABCL any more, I got following errors when compiling one of its source file. To show the core issue, create a lisp file with following single line and compile it, you'll see the same error: (defconstant a #.(make-array '(8 256) :element-type '(unsigned-byte 32) :initial-element 0)) I don't know how to fix this, have to ask help from ABCL maintainers. Regards, Chun Tian (binghe) [1] http://method-combination.net/lisp/ironclad/ -- Original error outputs: ; Compiling /Users/binghe/quicklisp/dists/quicklisp/software/ironclad_0.28/src/digests/whirlpool.lisp ... ; (IN-PACKAGE :CRYPTO) ; (DEFTYPE WHIRLPOOL-REGS ...) ; (DEFUN INITIAL-WHIRLPOOL-REGS ...) ; (DEFCONSTANT +WHIRLPOOL-REGS-HASH-OFFSET+ ...) ; (DEFCONSTANT +WHIRLPOOL-REGS-K-OFFSET+ ...) ; (DEFCONSTANT +WHIRLPOOL-REGS-STATE-OFFSET+ ...) ; (DEFCONSTANT +WHIRLPOOL-REGS-L-OFFSET+ ...) ; (DEFCONST +PRISTINE-WHIRLPOOL-REGISTERS+ ...) ; (DEFUN WHIRLPOOLREGS-DIGEST ...) ; (DEFCONSTANT +WHIRLPOOL-ROUNDS+ ...) ; (DECLAIM (TYPE # ...)) ; (DEFCONST +RC+ ...) ; (DECLAIM (TYPE # ...)) ; (DEFCONST +C-EVEN+ ...) #<THREAD "interpreter" {78D08435}>: Debugger invoked on condition of type PRINT-NOT-READABLE #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}> cannot be printed readably. Restarts: 0: TRY-RECOMPILING Try recompiling whirlpool 1: RETRY Retry compiling #<IRONCLAD-SYSTEM::IRONCLAD-SOURCE-FILE "ironclad" "src" "digests" "whirlpool">. 2: ACCEPT Continue, treating compiling #<IRONCLAD-SYSTEM::IRONCLAD-SOURCE-FILE "ironclad" "src" "digests" "whirlpool"> as having been successful. 3: TOP-LEVEL Return to top level. [1] CRYPTO(9): :bt 20 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<PRINT-NOT-READABLE {6EA518B6}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:373) 3: org.armedbear.lisp.SimpleArray_UnsignedByte32.writeToString(SimpleArray_UnsignedByte32.java:287) 4: org.armedbear.lisp.Primitives$pf__stream_output_object.execute(Primitives.java:887) 5: (SYSTEM:%STREAM-OUTPUT-OBJECT #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}> #<FILE-STREAM {18F98D7A}>) 6: (SYSTEM::DUMP-OBJECT #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}> #<FILE-STREAM {18F98D7A}>) 7: (SYSTEM::DUMP-CONS (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>) #<FILE-STREAM {18F98D7A}>) 8: (SYSTEM::DUMP-OBJECT (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>) #<FILE-STREAM {18F98D7A}>) 9: (SYSTEM::DUMP-CONS (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>)) #<FILE-STREAM {18F98D7A}>) 10: (SYSTEM::DUMP-OBJECT (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>)) #<FILE-STREAM {18F98D7A}>) 11: (SYSTEM:DUMP-FORM (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>)) #<FILE-STREAM {18F98D7A}>) 12: (SYSTEM::OUTPUT-FORM (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>))) 13: (SYSTEM::PROCESS-DEFCONSTANT (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>))) 14: (SYSTEM::PROCESS-TOPLEVEL-FORM (DEFCONSTANT IRONCLAD::+C-EVEN+ (IF (BOUNDP 'IRONCLAD::+C-EVEN+) (SYMBOL-VALUE 'IRONCLAD::+C-EVEN+) #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>)) #<FILE-STREAM {18F98D7A}> NIL) 15: (SYSTEM::PROCESS-TOPLEVEL-FORM (IRONCLAD::DEFCONST IRONCLAD::+C-EVEN+ #<(ARRAY (UNSIGNED-BYTE 32) (8 256)) {5E3D9EDF}>) #<FILE-STREAM {18F98D7A}> NIL) 16: (#<FUNCTION {1F97D330}>) 17: (JRUN-EXCEPTION-PROTECTED #<FUNCTION {1F97D330}>) 18: (JVM::%WITH-COMPILATION-UNIT #<FUNCTION {28AA0484}>) 19: (COMPILE-FILE #P"/Users/binghe/quicklisp/dists/quicklisp/software/ironclad_0.28/src/digests/whirlpool.lisp" :OUTPUT-FILE #P"/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13379-fasl37-macosx-java/Users/binghe/quicklisp/dists/quicklisp/software/ironclad_0.28/src/digests/ASDF-TMP-whirlpool.abcl" :OUTPUT-FILE #P"/Users/binghe/.cache/common-lisp/abcl-0.26.0-dev-svn-13379-fasl37-macosx-java/Users/binghe/quicklisp/dists/quicklisp/software/ironclad_0.28/src/digests/whirlpool.abcl")

4 8

[armedbear-devel] ABCL Usage Problem
by Nishant Trivedi 27 Jun '11

27 Jun '11

Hi All, We are trying to use ABCL for a project which requires a system coded in LISP to talk to another coded in JAVA. We are facing some issues and I would appreciate any help anyone can afford. For this project, I am using Windows 7 platform. I downloaded and built ABCL jar on my machine using ANT. I also setup the required system variables (JAVA_HOME, PATH and CLASSPATH). However, when I try to run the example code to call Java from Lisp ( as described at http://common-lisp.net/project/armedbear/doc/abcl-user.html), I keep getting the following error in ABCL: #<THREAD "interpreter" {13BC30A}>: Debugger invoked on condition of type ERROR Class not found: Main I have also manually compiled the Main.java file and placed the ".class" in the same folder as the lisp file that calls it. I am able to get built-in Java classes like "int". At this point I am stuck and would appreciate if anyone can help me out with this issue. Thanks in advance. Regards, Nishant.

2 1

[armedbear-devel] MAKE-IMMEDIATE-OBJECT and JOBJECT-LISP-VALUE conceptual problem
by Mark Evenson 22 Jun '11

22 Jun '11

Today, I spent a bit of time trying to figure out a way to efficiently compute message digest for Quicklisp. After confirming that java.security.MessageDigest implements the required digests, I noticed we didn't have a way to easily get at the underlying Java byte[] array in (SIMPLE-VECTOR (UNSIGNED-BYTE 8)). So, I patched the underlying Java code as attached, and wrote the following routine: (defun sha-256 (path) (let ((buffer (make-array 8192 :element-type '(unsigned-byte 8)) (digest (jstatic "getInstance" "java.security.MessageDigest" "SHA-256"))) (with-open-file (in path :element-type '(unsigned-byte 8)) (loop :for bytes = (read-sequence buffer in) :while (plusp bytes) :do (jcall-raw "update" digest (make-immediate-object buffer) 0 bytes)) (jcall "digest" digest))))) But then I noticed that MAKE-IMMEDIATE-OBJECT calls JOBJECT-LISP-VALUE which makes no conceptual sense. The doc for MAKE-IMMEDIATE-OBJECT reads "[a]ttempts to coerce a given Lisp object into a java-object" while the doc JOBJECT-LISP-VALUE reads "Attempts to coerce JAVA-OBJECT into a Lisp object". This seems wrong here, but I don't understand how exactly. I think we need to distinguish three types of values here: JAVA-OBJECT, LispObject, and the "raw" value of the Java. How should we really structure our Java FFI here? With my patch, for an underlying lisp value of type (SIMPLE-VECTOR (UNSIGNED-BYTE 8)), both MAKE-IMMEDIATE-OBJECT and JOBJECT-LISP-OBJECT return the byte[] array. I would think that MAKE-IMMEDIATE-OBJECT should just do this, which JOBJECT-LISP-OBJECT should .... return an error if its argument isn't of type JAVA-OBJECT? I don't know. I am confused. Can someone help me understand the right way forward here? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 4

[armedbear-devel] ASDF-JAR contrib packages systems in jar files
by Mark Evenson 20 Jun '11

20 Jun '11

The ASDF-JAR contrib now packages up ASDF systems in jar archives. Comments and/or additional needs from this system are welcome. From the documentation: ASDF-JAR ======== Mark Evenson Created: 20-JUN-2011 Modified: 20-JUN-2011 ASDF-JAR provides a system for packaging ASDF systems into jar archives for ABCL. Given a running ABCL image with loadable ASDF systems the code in this package will recursively package all the required source and fasls in a jar archive . To install ASDF systems, [Quicklisp]() is probably the best contemporary solution, although a version of ASDF-INSTALL is also packaged in ABCL contribs. [Quicklisp]: http://www.quicklisp.org Once the requisite ASDF systems have been installed, ensure that this contrib is loaded via CL-USER) (require :abcl-contrib) CL-USER> (require :asdf-jar) Then, to say package the Perl regular expression system ("CL-PPCRE"), one uses the ASDF-JAR:PACKAGE as follows: CL-USER> (asdf-jar:package :cl-ppcre) ; Loading #P"/home/evenson/quicklisp/dists/quicklisp/software/cl-ppcre-2.0.3/cl-ppcre.asd" ... ; Loaded #P"/home/evenson/quicklisp/dists/quicklisp/software/cl-ppcre-2.0.3/cl-ppcre.asd" (0.029 seconds) Packaging ASDF definition of #<ASDF:SYSTEM "cl-ppcre"> as /var/tmp/cl-ppcre-all-2.0.3.jar. Packaging contents in /var/tmp/cl-ppcre-all-2.0.3.jar with recursive dependencies. #P"/var/tmp/cl-ppcre-all-2.0.3.jar" The resulting jar contains all source and fasls required to run the ASDF system including any transitive ASDF dependencies. Each asdf system is packaged under its own top level directory within the jar archive. The jar archive itself is numbered with the version of the system that was specified in the packaging. To load the system from the jar one needs to add the ASDF file locations to the ASDF *CENTRAL-REGISTRY*. If one wishes to load the fasls from the jar alone, one needs to tell ASDF not to override its output translation rules. The function ASDF-JAR:ADD-TO-JAR does both of these options serving as the basis for customized load strategies tailored to end-user deployment needs. So, after CL-USER> (asdf-jar:add-to-asdf "/var/tmp/cl-ppcre-all-2.0.3.jar") a subsequent CL-USER> (asdf:load-system :cl-ppcre) should load the ASDF system from the jar. Setting CL:*LOAD-VERBOSE* will allow one to verify that the subsequent load is indeed coming from the jar. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel