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

Re: [armedbear-devel] [armedbear-cvs] r12405 - in trunk/abcl: . src/org/armedbear/lisp
by Erik Huelsmann 28 Jan '10

28 Jan '10

On Thu, Jan 28, 2010 at 9:49 AM, Mark Evenson <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Thu Jan 28 03:49:36 2010 > New Revision: 12405 > > Log: > Don't invoke the entire ABCL runtime just to get the version number during compilation. Clever change! Nice! Bye, Erik.

1 0

[armedbear-devel] need to customize print-object for a java class
by Mark Evenson 28 Jan '10

28 Jan '10

On 1/15/10 8:46 AM, Mark Evenson wrote: > On 1/14/10 3:33 PM, Alan Ruttenberg wrote: >> The Jena toolkit has antisocially defined the toString method of an >> important object to be computationally expensive - it triggers a >> description logical classification process in some cases, something >> which can blow out memory or take a very very long time. > > […] > > Ouch! I had hoped that the the toString() "contract" in Java entailed a > non-computationally expensive result, and that this was widely adopted. > > Then a HEADS UP is in order: I committed (~20100112) to SLIME HEAD a > patch that invokes the "toString()" method on all JAVA-OBJECTs as a > convenience. […] I have (finally) committed the necessary changes to SLIME HEAD (20100128) to make the inspection of toString() results a user interactive action. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Question about ABCL on Google App Engine
by Anthony Green 26 Jan '10

26 Jan '10

I'm trying to get my little abcl web app experiment (http://spindazzle.org/blow) working on google app engine. The gae sandbox is tripping me up, but I'm having a tough time figuring out where. Here's a stack trace: https://gist.github.com/0258a3794866eb6c120b If I'm reading this correctly, it looks like asdf is trying to compile something, which in turn is calling ensure-directories-exist, which doesn't work on GAE. I'm not sure what asdf could be compiling. I've pre-compiled all of the *.lisp files and removed them from the war file that gets uploaded to GAE. Any advice on tracking this down? Thanks! AG

2 2

[armedbear-devel] Some patches to improve arglist display in Slime
by Matthias Hölzl 26 Jan '10

26 Jan '10

Currently Slime cannot display arglist information for methods when running ABCL since ABCL does not export the required parts of the MOP. Most of the required functionality is already present in ABCL, so I've implemented the missing functionality (basically only the generic function COMPUTE-APPLICABLE-METHODS-USING-CLASSES), turned the function SLOT-DEFINITION-NAME into a generic function and created a patch that exports the new functionality. More precisely the externally visible changes are: * SLOT-DEFINITION-NAME is now a generic function with a single method specialized on SLOT-DEFINITION and not a (non-generic) function with unspecialized argument. * Generic functions and methods for SLOT-DEFINITION-ALLOCATION, SLOT-DEFINITION-INITARGS, SLOT-DEFINITION-INITFORM and SLOT-DEFINITION-INITFUNCTIONS are defined and exported from the MOP package. For each of these implementations the method argument is specialized on SLOT-DEFINITION and the implementation simply delegates to the corresponding % SLOT-DEFINITION-* function. * COMPUTE-APPLICABLE-METHODS-USING-CLASSES is implemented as generic function and exported from the MOP package. The behavior of these functions should be as specified in AMOP, but there are some caveats: 1. I have not checked my implementation of C-A-M-U-C against any other CLOS implementation, so I might have made mistakes or misunderstood something. 2. The methods for SLOT-DEFINITION-ALLOCATION, etc. are specialized on SLOT-DEFINITION and not, as specified in AMOP, on STANDARD-SLOT-DEFINITION since ABCL does not seem to implement the latter class. I don't know enough about ABCL to know what the preferred way of introducing STANDARD-SLOT-DEFINITION would be; re-implementing the slot-definition part in Lisp, subclassing Lisp classes from the Java class, or defining subclasses of existing classes in Java all seem like viable solutions. To implement these things I've made some minor internal changes; in particular: 1. I've extracted a function to sort methods from the implementation of %COMPUTE-APPLICABLE-METHODS since this algorithm is now needed in COMPUTE-APPLICABLE-METHODS-USING-CLASSES as well. 2. I've renamed METHOD-APPLICABLE-P-USING-CLASSES to METHOD-APPLICABLE-USING-CLASSES-P, changed its implementation and extended its implementation to take into account EQL specializers. 3. I've removed the autoload for SLOT-DEFINITION-NAME. I don't know enough about the ABCL compiler to understand what the purpose of autoloading some things is, so I don't know whether autoloads for SLOT-DEFINITION-NAME et al. should be added somewhere. Leaving them out does not seem to break anything but it might have undesired consequences that I have missed. The patch contains a few tests to verify that it does not completely break the compiler, but not a complete test-suite for the new functionality. Current Slime needs a one line patch to enable arglist display for the patched ABCL; I've included this patch as well. Best regards, Matthias

3 3

[armedbear-devel] ABCL.TEST.LISP notes
by Mark Evenson 26 Jan '10

26 Jan '10

With [svn r12402][1], I've gotten the ABCL Lisp tests to a point that I am much happier with the interface. Loading and running the tests via ASDF is now the preferred method, and the Ant targets now utilize this, but here are some quick notes for invoking the tests from an ABCL REPL: I currently have overloaded the 'abcl.asd' with definitions for many subsystems, which works will if you symlink this file to 'abcl-test-lisp.asd', then CL-USER> (asdf:operate 'asdf:load-op :abcl-test-lisp) will load the tests. Now you can use ASDF to run all the tests CL-USER> (asdf:operate 'asdf:test-op :abcl-test-lisp) or, once the tests have been loaded, there is a convenience function ABCL.TEST.LISP:RUN-MATCHING that will run a subset of the tests CL-USER) (abcl.test.lisp:run-matching "jar-file") will run all tests which have the string "jar-file" in their name. Reporting here isn't the best yet as this only currently reports errors, so if you get a NIL, it means all the tests you specified succeeded. [1]: http://code.google.com/p/abcl-dynamic-install/source/detail?r=bf9aa23d2841d… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Patches to fix loading from JARs
by Mark Evenson 24 Jan '10

24 Jan '10

Attached find patches to ABCL trunk to fix the problems with JAR files. Additionally I have included my notes on the design which deviates a little from my original posting of a couple weeks ago. The main change from that design is that the PATHNAME DEVICE is now possiblly a proper list of jars so that #p"jar:jar:file:foo.jar!/bar.abcl!/bar._" constructs a Pathname that has the layout Pathname: { device: ( Pathname { name: "foo"; type: "jar"}; Pathname { name: "bar"; type: "abcl"}; ); name: "bar"; type: "_"; } This patch implements support for specifying ABCL FASLs from JAR files to the [documented level for JarURLConnection][1] for the LOAD, TRUENAME, and PROBE-FILE commands. so CL-USER> (load #p"jar:file:invoke.jar!/a/b/invoke") will search invoke.jar for an entry for "a/b/invoke.abcl", "a/b/invoke._", and "a/b/invoke.lisp", loading the first one that it finds. Actually it tries to compare timestamps, but I don't think that works so well with JAR entries. This patch needs to be tested under Windows when I get a chance where I expect there to be easily fixed errors around the use of the "!/" separator in the pathname namestring syntax. Loading JARs from URLs should need minor debugging to get working. Internally this patch reworks most of the loading routines to use Pathnames instead of strings, and reduceing a lot of the complexity in looking for the correct file. There are both Java based and Lisp based tests included. The Lisp based tests only run under UNIX, as I use a shell script to construct the JAR for testing. [1]: http://java.sun.com/javase/6/docs/api/java/net/JarURLConnection.html --- About the only disadvantage for the current patch is that I had to remove the use of ZipCache for entries as I was developing as it didn't make much sense. I haven't really noticed too much of a time difference for loading or compiling ABCL. Comments? Once I get things tested under Windows, and play around with the loading from http support, I intend to commit to trunk. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Utility macros to access Java from Lisp
by Blake McBride 24 Jan '10

24 Jan '10

Greetings, I find the following utility macros helpful when wanting to access Java from Lisp. I will give some examples after the actual code. (defmacro defun-class-method (lfun cls-name meth-name &rest arg-types) (let ((arglist (mapcar (lambda (x) (gensym)) arg-types)) (method (gensym)) (cls (gensym))) `(let ((,method (jmethod ,cls-name ,meth-name ,@arg-types)) (,cls (jclass ,cls-name))) (defun ,lfun ,arglist (jcall ,method ,cls ,@arglist))))) (defmacro defun-instance-method (lfun cls-name meth-name &rest arg-types) (let ((arglist (mapcar (lambda (x) (gensym)) (cons nil arg-types))) (method (gensym))) `(let ((,method (jmethod ,cls-name ,meth-name ,@arg-types))) (defun ,lfun ,arglist (jcall ,method ,@arglist))))) (defmacro defun-constructor (lfun cls-name &rest arg-types) (let ((arglist (mapcar (lambda (x) (gensym)) arg-types)) (method (gensym))) `(let ((,method (jconstructor ,cls-name ,@arg-types))) (defun ,lfun ,arglist (jnew ,method ,@arglist))))) Examples: The following line defines a lisp function named "java-abs". java-abs is a proxy for the java version. It takes the same arguments. (defun-class-method java-abs "java.lang.Math" "abs" "int") After the above is called, you may call the Java method from lisp as follows: (java-abs -44) The lisp functions created by these utilities are fast because they are closures. The class and method lookups are only done once. Other examples: (defun-constructor newInteger "java.lang.Integer" "int") (defun-instance-method hashCode "java.lang.Integer" "hashCode") I am in the process of doing the same thing for Java. Stay tuned. Blake McBride

1 0

[armedbear-devel] Utility macros to access Java from Lisp
by Blake McBride 24 Jan '10

24 Jan '10

Greetings, I find the following utility macros helpful when wanting to access Java from Lisp. I will give some examples after the actual code. (defmacro defun-class-method (lfun cls-name meth-name &rest arg-types) (let ((arglist (mapcar (lambda (x) (gensym)) arg-types)) (method (gensym)) (cls (gensym))) `(let ((,method (jmethod ,cls-name ,meth-name ,@arg-types)) (,cls (jclass ,cls-name))) (defun ,lfun ,arglist (jcall ,method ,cls ,@arglist))))) (defmacro defun-instance-method (lfun cls-name meth-name &rest arg-types) (let ((arglist (mapcar (lambda (x) (gensym)) (cons nil arg-types))) (method (gensym))) `(let ((,method (jmethod ,cls-name ,meth-name ,@arg-types))) (defun ,lfun ,arglist (jcall ,method ,@arglist))))) (defmacro defun-constructor (lfun cls-name &rest arg-types) (let ((arglist (mapcar (lambda (x) (gensym)) arg-types)) (method (gensym))) `(let ((,method (jconstructor ,cls-name ,@arg-types))) (defun ,lfun ,arglist (jnew ,method ,@arglist))))) Examples: The following line defines a lisp function named "java-abs". java-abs is a proxy for the java version. It takes the same arguments. (defun-class-method java-abs "java.lang.Math" "abs" "int") After the above is called, you may call the Java method from lisp as follows: (java-abs -44) The lisp functions created by these utilities are fast because they are closures. The class and method lookups are only done once. Other examples: (defun-constructor newInteger "java.lang.Integer" "int") (defun-instance-method hashCode "java.lang.Integer" "hashCode") I am in the process of doing the same thing for Java. Stay tuned. Blake McBride

1 0

[armedbear-devel] Passing lisp objects from java to lisp
by Blake McBride 24 Jan '10

24 Jan '10

Greetings, If I have a lisp function as follows: (defun myfun (a b) (+ a b)) I want to be able to call it from lisp or java. In other words I don't want the lisp side to have to use jobject-lisp-value. Therefore, from the java side, how do I take a java object and translate into a lisp object so that when I call the execute method the lisp function doesn't need jobject-lisp-value? Thanks. Blake McBride

1 1

[armedbear-devel] trouble with Maxima test suite
by Robert Dodier 21 Jan '10

21 Jan '10

Hello, I have updated ABCL from svn and rebuilt it and updated Maxima and rebuilt it with ABCL. It seems to mostly work except that in a new instance of Maxima launched via (require 'asdf) (asdf:operate 'asdf:load-op :maxima) (run) I find that run_testsuite(); pretty soon runs into some errors and grinds to a halt at rtest14 (pretty early in the test suite). However I find that load(orthopoly); before run_testsuite(); seems to avoid the problem. I don't remember that this work-around was necessary in previous versions of ABCL; I probably last updated ABCL a couple of months ago. orthopoly is a Lisp package which is supposed to be loaded automatically when any of the functions in the package are called for the first time, e.g. $hermite has the 'autoload property. Another clue? When I enter quit(); after the unsuccessful run_testsuite(); I get a Java exception as follows. quit(); java.lang.IllegalStateException: Current state = CODING_END, new state = CODING at java.nio.charset.CharsetDecoder.throwIllegalStateException(CharsetDecoder.java:951) at java.nio.charset.CharsetDecoder.decode(CharsetDecoder.java:537) at org.armedbear.lisp.util.DecodingReader.read(DecodingReader.java:261) at org.armedbear.lisp.util.DecodingReader.read(DecodingReader.java:249) at org.armedbear.lisp.util.DecodingReader.read(DecodingReader.java:227) at org.armedbear.lisp.Stream._readChar(Stream.java:1683) at org.armedbear.lisp.Stream.readChar(Stream.java:1513) at org.armedbear.lisp.Stream$16.execute(Stream.java:2393) at org.armedbear.lisp.Symbol.execute(Symbol.java:798) at org.armedbear.lisp.LispThread.execute(LispThread.java:596) at org.armedbear.lisp.mdebug_20.execute(mdebug.lisp:282) (etc ... I've suppressed the rest of the stack trace.) If you can suggest some additional info I could try to gather to aid debugging, I'll be glad to do so. Thanks for your help, and all your terrific work. Robert Dodier

2 2