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

[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

[armedbear-devel] class-direct-subclasses has duplicates
by Alan Ruttenberg 18 Jan '10

18 Jan '10

It should be a set according to http://www.alu.org/mop/dictionary.html *Generic Function* *class-direct-subclasses* *class* Returns a set of the direct subclasses of *class*. The elements of this set are class metaobjects that all mention this class among their direct superclasses. The empty set is returned if *class* has no direct subclasses. This value is maintained by the generic functions *add-direct-subclass*<http://www.alu.org/mop/dictionary.html#add-direct-subclass> and *remove-direct-subclass*<http://www.alu.org/mop/dictionary.html#remove-direct-subclass> . (map nil 'print (system:class-direct-subclasses (find-class 'ido-pathway-block))) #<STANDARD-CLASS PARSED-SHEET-INFO-BLOCK {895391}> #<STANDARD-CLASS PARSED-EVIDENCE-BLOCK {C422A5}> #<STANDARD-CLASS PARSED-COMPLEX-BLOCK {90AD53}> #<STANDARD-CLASS PARSED-PROCESS-BLOCK {14D509}> #<STANDARD-CLASS PARSED-HANDLE-BLOCK {5AFFB3}> #<STANDARD-CLASS PARSED-SHEET-INFO-BLOCK {895391}> #<STANDARD-CLASS PARSED-EVIDENCE-BLOCK {C422A5}> #<STANDARD-CLASS PARSED-COMPLEX-BLOCK {90AD53}> #<STANDARD-CLASS PARSED-PROCESS-BLOCK {14D509}> #<STANDARD-CLASS PARSED-HANDLE-BLOCK {5AFFB3}> -Alan

2 2

[armedbear-devel] patch for ensure-directories-exist
by Alan Ruttenberg 18 Jan '10

18 Jan '10

ensure-directories-exist fails when passed a logical pathname. (defun ensure-directories-exist (pathspec &key verbose) - (let ((pathname (pathname pathspec)) + (let ((pathname (translate-logical-pathname (pathname pathspec))) (created-p nil)) (when (wild-pathname-p pathname) ....

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.18.1 released
by Erik Huelsmann 18 Jan '10

18 Jan '10

> On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to > be able to announce the 0.18.0 release. Because of some regressions which had gone undetected during testing for the release, we have released ABCL 0.18.1. Anyone using 0.18.0 should consider updating to 0.18.1 because the .0 release may exhibit seemingly random behavior. In addition, some enhancements have been included which were developed on user request. Bye, Erik.

1 0

[armedbear-devel] resend [ANNOUNCE] ABCL 0.18.0 released
by Erik Huelsmann 15 Jan '10

15 Jan '10

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.18.0 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 Java Specification Request (JSR) 223: Java scripting API. This release features - among lots of other things - faster initial startup, faster special variable lookup and portable fasl files. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.18.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/abcl-src-0.18.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.18.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.18.0.zip.asc This time with the correct url to the release notes. Bye, Erik.

3 2