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

[armedbear-devel] jcall and t/nil boolean arguments
by Alan Ruttenberg 29 Jan '10

29 Jan '10

Can it be made so that within jcall, t or nil is understood as a java boolean argument? -Alan

3 3

[armedbear-devel] 0.18 and beyond
by Erik Huelsmann 29 Jan '10

29 Jan '10

This evening, I've updated the list of tickets at http://trac.common-lisp.net/armedbear/report/1. Assigning the tickets in the list to specific releases makes the roadmap view (http://trac.common-lisp.net/armedbear/roadmap) nicely indicate our progress. If you have an issue, but it's not mentioned in the list of tickets, 2 things can be the case: 1) We don't know about your ticket, or have forgotten about it 2) The ticket is more of a general thing we need to keep doing (there's no specific goal or target to be achieved) In the second case, we can't file a ticket, because I would like to be able to close tickets some day. As you'll find, I've assigned some tickets to the milestone "too-vague". If we can't come up with more specific descriptions, I think we'll have to reclassify these to "reminder" type tickets. (We don't have those, yet, btw.) So, I'd like to hear your comments on missing tickets. I'd also like to discuss assignment of tickets to milestones. This won't mean that they will be fixed by then, but they *are* meant to be a guideline for priorities and hopefully an indication for interested users on which larger issues we intend to tackle and roughly when. Bye, Erik.

5 12

[armedbear-devel] asdf loading from jar files
by Alan Ruttenberg 29 Jan '10

29 Jan '10

I've believe I've written code that can load a compiled asdf system from a jar file. Final testing is pending the patch for loading a compiled file from a subdirectory of a jar. In order to do that I needed to do 3 things. 1) Patch probe file so that it understands jar:file pathnames 2) Patch truename so that it understands jar:file pathnames 3) Create a new asdf op that knows to load only the compiled files. These patches are in http://svn.mumble.net:8080/svn/lsw/trunk/patches/jarfile.lisp I used advise (http://svn.mumble.net:8080/svn/lsw/trunk/util/encapsulate.lisp) to patch, probe-file, directory, and truename, but don't mind merging the changes into source if it's deemed that they are the right thing. I'd submit the code for advise too (adapted from MCL), but it's not quite cleaned up yet. The asdf op is in that file too. It's a bit hacky because I use asdf-binary-locations[1] and I didn't see how to cleanly integrate it. If someone knows how to drive asdf better than I do, please suggest a better way. There's still a nit in that if you load the system a second time it warns about file-write-date not working. I'm not sure file write date should return for a jar:file pathname. The write date of the containing jar? FWIW, I think that you should consider having asdf-binary-locations be part of the standard distribution. As ABCL is under active development I was always running into issues with stale fasls, but no more since I've been using it. -Alan [1] http://common-lisp.net/project/asdf-binary-locations/ laptop:~/ % jar tf test.jar META-INF/ META-INF/MANIFEST.MF bar/ bar/armedbear-0.18.0-dev-darwin-unknown/ bar/armedbear-0.18.0-dev-darwin-unknown/bar1.abcl bar/armedbear-0.18.0-dev-darwin-unknown/bar2.abcl bar/bar.asd CL-USER> (advise load (if (eql 0 (search "jar:file" (namestring (car arglist)))) (format t ";; would have loaded ~a~%" (car arglist)) (:do-it)) :when :around :name stub) #<FUNCTION (ENCAPSULATE::ADVISED 'LOAD) {ACB16B}> CL-USER> (load "jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar.asd") ; Loading jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar.asd ... ; Loaded jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar.asd (0.0030 seconds) T CL-USER> (asdf::oos 'asdf::load-just-fasls-op 'bar) ;; would have loaded jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/armedbear-0.18.0-dev-darwin-unknown/bar1.abcl ;; would have loaded jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/armedbear-0.18.0-dev-darwin-unknown/bar2.abcl CL-USER> (asdf::oos 'asdf::load-just-fasls-op 'bar) WARNING: Missing FILE-WRITE-DATE for #P"jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar1.lisp": treating operation #<ASDF::LOAD-JUST-FASLS-OP NIL {8C2182}> on component #<ASDF:CL-SOURCE-FILE "bar1" {B93BB6}> as done. WARNING: Missing FILE-WRITE-DATE for #P"jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar2.lisp": treating operation #<ASDF::LOAD-JUST-FASLS-OP NIL {8C2182}> on component #<ASDF:CL-SOURCE-FILE "bar2" {7242FD}> as done.

5 8

[armedbear-devel] problem with error reporting on undefined class during make instance
by Alan Ruttenberg 29 Jan '10

29 Jan '10

CL-USER(25): (defclass c (d) ((q :initarg :q))) #<STANDARD-CLASS C {B5BEE0}> CL-USER(26): (make-instance 'c :q t) Debugger invoked on condition of type PROGRAM-ERROR: Invalid initarg :Q. The error should say instead something about d not being defined. This in build of a freshly updated trunk abcl -Alan

2 1

[armedbear-devel] Using Java variable arguments
by Blake McBride 29 Jan '10

29 Jan '10

Java has had support for variable argument methods since version 5. Wouldn't it be cleaner to use that? For example, in LispObject.java there are several "execute" methods, one to support various numbers of arguments. In Java 5+ you could write: public LispObject execute(LispObject ... arg) { whatever } You call it like you do now, i.e. execute(a, b, c, d) but arg gets an array of the arguments. This way you could create one method that would handle virtually any number of arguments in one clean method. I'm sure this technique can be used in more places too. Blake McBride

3 2

[armedbear-devel] ABCL OpenOffice.org Extension
by Knut Olav Bøhmer 28 Jan '10

28 Jan '10

Hi, I want to make lisp the preferred way of developing openoffice.orgextensions, but I have to much problems with the java part. I have been able to make an extension for openoffice.org using an openoffice.org plugin for eclipse. Now, I have to figure out how to embed it with ABCL. I would be very happy if some one could help me by giving me some hints or even a step by step procedure to import abcl into the eclipse project. The first thing I want to do is to be able to load lisp files from the openoffice.org basic interface. Then I'll extend it to be able to start swank and run expressions from strings. -- Knut Olav Bøhmer

2 1

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 23 Jan '10

23 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 23 Jan '10

23 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 23 Jan '10

23 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

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

13 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.17.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

1 0

[armedbear-devel] Folding Lisp application code into a JAR file in the Java CLASSPATH
by Olsen, Peter C. 13 Jan '10

13 Jan '10

Ladies and Gentlemen, Is there an elegant way to have ABCL load Lisp code from a JAR file in the Java CLASSPATH? I'm helping build an application to run under ABCL and I'd like to take all the code and roll it up into a JAR file in the CLASSPATH when I start the interpreter. If possible I'd then like to have ABCL find the file as though it were in the current directory. I know that ABLC is finding its system files in abcl.jar and I can load Lisp code from a local JAR file, but I haven't figured out how to put the two together and load Lisp elegantly from a JAR file in the CLASSPATH. I can do it inelegantly by getting the CLASSPATH from the Java System class, inspecting all its JAR files, then loading the right ones manually, but that seems awkward for a customer application. I'd appreciate any pointers. Finally, please let me apologize in advance if there's some simple answer that I should have found but haven't. Peter -- Peter Olsen, P.E., Ae.E. Registered Professional Engineer, Maryland License 12283 The Johns Hopkins University Applied Physics Laboratory 11100 Johns Hopkins Road, M/S 17-214 Laurel, Maryland, 20723 Baltimore: 443-778-2577; Washington DC 240-228-2577 Performance and cost must be considered as well as functionality. (RFC 1958)

3 5

[armedbear-devel] Fwd: [Bug] Identically named gensymed coalesced into same object in fasl file
by Erik Huelsmann 12 Jan '10

12 Jan '10

Sent the response below to Tobias privately by accident. ---------- Forwarded message ---------- From: Erik Huelsmann <ehuels(a)gmail.com> Date: Mon, Jan 11, 2010 at 11:40 PM Subject: Re: [armedbear-devel] [Bug] Identically named gensymed coalesced into same object in fasl file To: "Tobias C. Rittweiler" <tcr(a)freebits.de> Hi Tobias, Thanks for your report. This issue has long been in ABCL and it's not fixed yet. I have known about this problem for a while, but was kind of hoping it wouldn't show up in practice. I guess it did. This is what happens: when reading, the fasl loader creates an anonymous package in which it interns uninterned symbols. It "has" to do that, because ABCL doesn't store references to the actual unique objects everywhere; instead it stores the textual representation in some places. These symbols get coalesced by use of the anonymous package. So, generally the system of coalescing is something inherent to this idea. The idea is wrong enough for you to run into and get bitten by it. We'll have to come up with a better idea. Can you add the mail message below to our issue tracker? BTW: Did you happen to find this issue by accident? How did you find it? Bye, Erik. On Mon, Jan 11, 2010 at 10:35 PM, Tobias C. Rittweiler <tcr(a)freebits.de> wrote: > > I'm currently running an old checkout ("0.17.0-dev"), so the issue may > have been fixed meanwhile. > > ### /tmp/foo.lisp > (eval-when (:load-toplevel :execute) > (let ((a '#:foo) > (b '#:foo)) > (setf (fdefinition 'foo) (lambda () (values a b))))) > > (eval-when (:load-toplevel :execute) > (format t "~&(multiple-value-call #'eq (foo)) => ~S~%" > (multiple-value-call #'eq (foo)))) > ### > > CL-USER> (compile-file "/tmp/foo.lisp") > ; Compiling /tmp/foo.lisp ... > ; (LET (# #) ...) > ; (FORMAT T ...) > > ; Compilation unit finished > ; The following functions were used but not defined: > ; FOO > > ; Wrote /tmp/foo.abcl (0.034 seconds) > #P"/tmp/foo.abcl" > NIL > NIL > > That warning is bogus. There some work in this area so this bit may be > fixed already. > > The actual issue of my mail is this one, though: > > CL-USER> (load *) > (multiple-value-call #'eq (foo)) => T > T > > As you can see, ABCL coalesces the two identical named gensyms into the > same object in the fasl file. > > While 3.2.4.2.2 does specify that > > Two apparently uninterned symbols S and C are similar if their names > are similar. > > ABCL's behavior is still wrong because 3.2.4.1 says > > If two literal objects appearing in the source code for a single file > processed with the file compiler are the [sic] identical, the > corresponding objects in the compiled code must also be the > identical. __With the exception of symbols and packages__, any two > literal objects in code being processed by the file compiler may be > coalesced if and only if they are similar; __if they are either both > symbols or both packages, they may only be coalesced if and only if > they are identical__. > > -T. > > > _______________________________________________ > armedbear-devel mailing list > armedbear-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >

2 1

[armedbear-devel] [Bug] Identically named gensymed coalesced into same object in fasl file
by Tobias C. Rittweiler 11 Jan '10

11 Jan '10

I'm currently running an old checkout ("0.17.0-dev"), so the issue may have been fixed meanwhile. ### /tmp/foo.lisp (eval-when (:load-toplevel :execute) (let ((a '#:foo) (b '#:foo)) (setf (fdefinition 'foo) (lambda () (values a b))))) (eval-when (:load-toplevel :execute) (format t "~&(multiple-value-call #'eq (foo)) => ~S~%" (multiple-value-call #'eq (foo)))) ### CL-USER> (compile-file "/tmp/foo.lisp") ; Compiling /tmp/foo.lisp ... ; (LET (# #) ...) ; (FORMAT T ...) ; Compilation unit finished ; The following functions were used but not defined: ; FOO ; Wrote /tmp/foo.abcl (0.034 seconds) #P"/tmp/foo.abcl" NIL NIL That warning is bogus. There some work in this area so this bit may be fixed already. The actual issue of my mail is this one, though: CL-USER> (load *) (multiple-value-call #'eq (foo)) => T T As you can see, ABCL coalesces the two identical named gensyms into the same object in the fasl file. While 3.2.4.2.2 does specify that Two apparently uninterned symbols S and C are similar if their names are similar. ABCL's behavior is still wrong because 3.2.4.1 says If two literal objects appearing in the source code for a single file processed with the file compiler are the [sic] identical, the corresponding objects in the compiled code must also be the identical. __With the exception of symbols and packages__, any two literal objects in code being processed by the file compiler may be coalesced if and only if they are similar; __if they are either both symbols or both packages, they may only be coalesced if and only if they are identical__. -T.

1 0

[armedbear-devel] Preliminary patch for deriving Stream from StructureObject, in preparation for Gray streams support
by Ville Voutilainen 11 Jan '10

11 Jan '10

Please take a look at this patch. With the modifications to clinit orders in Lisp.java, this builds, but it doesn't work well enough to run the ansi tests. Any help is grealy appreciated.

1 0

[armedbear-devel] Gray streams support: plan of attack
by Erik Huelsmann 10 Jan '10

10 Jan '10

Today on IRC, Ville and I had a long discussion on how to get Gray streams supported in ABCL. The outcome is a long description, but I think it's good to write it down, so everybody following trunk understands what we're doing. Of course, if you have any feedback, please send it! The problem The issue with our current support for Gray streams is that we have almost everything in place except for one important thing: without hacking TYPEP and STREAMP, we're not able to fully support user-defined streams. However, hacking TYPEP is extremely fragile, as the compiler may assume things about certain types in the CL package. So, we don't want to go that route. On the other hand, it's not possible to derive classes from built-in classes, which means that in the current situation where STREAM is a built-in class, we cannot get the type of FUNDAMENTAL-STREAM right at all. Since we need to change things anyway, given the above, it would be nice to implement some of the CL streams in Lisp, particularly the ones which are not required to get ABCL booted. The plan We found out that if one declares an empty structure class - meaning a structure without slots - this class can be used in the superclasse list of defclass. What we're now doing is this: * Make STREAM an empty structure class * Create a SYSTEM-STREAM structure class which will contain slots in the future (but none for now) * Derive all internal stream classes from SYSTEM-STREAM * Derive FUNDAMENTAL-STREAM from the empty STREAM structure class (which is now possible with a normal DEFCLASS), making it a real stream At a later stage, we want to move code from all the non-boot-essential streams to Lisp. This should allow for easier maintenance and more compact (yet fully comprehensible) code. Bye, Erik.

1 0

[armedbear-devel] Proposed change to jar:file semantics
by Mark Evenson 09 Jan '10

09 Jan '10

My initial code to get LOAD to use "jar:file:" was rather hackish in that it didn't consider enough scope of the impact so I've been looking hard at implementing TRUENAME, PROBE-FILE, MERGE-PATHNAMES (and eventually PROBE-DIRECTORY and DIRECTORY) for "jar:file" entries. I'd like to propose we change the use of the "jar:file:" string to only occur in the namestring representation of a jar file entry, i.e. the device entry would always be a "real" pathname. So what would currently be CL-USER> (pathname-name (pathname-device #p"jar:file:abcl.jar!/foo")) "jar:file:abcl" which would become CL-USER> (pathname-name (pathname-device #p"jar:file:abcl.jar!/foo")) "abcl" under my proposal. This would simplify the needed code quite a bit as one just has to detect we are dealing with a jar entry reference, pull the pathname out of device, and pass it to a sub-routine. And according to the unofficial specification of the "jar:file" URI schema, it is invalid not to have a reference to the entry by the path following the "!/" (i.e. "jar:file:abcl.jar" has no meaning, just "jar:file:abcl.jar!/foo"). I've started to implement this, but would like to float this idea across the list to see if there are objections and/or problems I've not foreseen. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 1

[armedbear-devel] Questions for use in a server
by Blake McBride 09 Jan '10

09 Jan '10

Greetings, I am considering using ABCL as an extension language to a Web server app I have. I know the answer to many of the questions I have in choosing the correct extension language and ABCL seems to fit the bill well. I do have some questions, however. 1. Can ABCL run concurrently in multiple threads without any problems (I understand the ramifications in terms of my application code)? 2. I would like to have some utility code which is loaded once and shared by all the ABCL threads. Each thread can then run code that is independent (i.e. they can have the same function names with different definitions). (Perhaps I'd have to use packages for this.) 3. If I am running a lot of different threads will ABCL allow code to be GC'd when the thread ends (presuming no other thread is using that code)? 4. ABCL seems to have a somewhat heavy startup time. This is okay for the first time, but I need the threads to start much faster (much less than half a second). Thanks for the answers! Blake

4 5

[armedbear-devel] Why does jcall use reflection?
by Axel Rauschmayer 09 Jan '10

09 Jan '10

I hope this is not a stupid question, but: Why does jcall use reflection? Doesn't ABCL compile lisp to byte code? If one could statically declare to the compiler the intended Java class, couldn't method invocations be compiled instead of being performed via reflection? OTOH, I don't know how ABCL handles interpretation versus compilation, so that might be an issue. -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/

3 4

[armedbear-devel] new jcall / jar:file: path functions
by Alan Ruttenberg 08 Jan '10

08 Jan '10

I'm trying to use the new jcall code in place of jss calls. However I am getting an error I don't understand. In the following: (defun directory-in-jar (pathname) (let* ((jarfile (subseq (namestring (pathname-device pathname)) 9)) (rest-pathname (namestring (make-pathname :directory (pathname-directory pathname) :name (pathname-name pathname) :type (pathname-type pathname))))) (if (or (position #\* (namestring rest-pathname)) (wild-pathname-p rest-pathname)) (let ((jar (jnew "java.util.zip.ZipFile" jarfile))) (let ((els (jcall "entries" jar))) (loop while (#"hasMoreElements" els) for name = (jcall "getName" (#"nextElement" els)) when (pathname-match-p (concatenate 'string "/" name) rest-pathname) collect (make-pathname :device (pathname-device pathname) :name (pathname-name name) :type (pathname-type name) :directory `(:absolute ,@(cdr (pathname-directory name))))))) (let ((truename (probe-file-in-jar pathname))) (if truename (list truename) nil))))) If I replace the call (#"hasMoreElements" els) with (jcall "hasMoreElements" els) I get the error: java.lang.IllegalAccessException: Class org.armedbear.lisp.Java can not access a member of class java.util.zip.ZipFile$3 with modifiers "public" at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65) at java.lang.reflect.Method.invoke(Method.java:583) at org.armedbear.lisp.Java.jcall(Java.java:660) ... If I replace the call (#"nextElement" els) with (jcall "nextElement" els) I get the error java.lang.IllegalAccessException: Class org.armedbear.lisp.Java can not access a member of class java.util.zip.ZipFile$3 with modifiers "public volatile" at sun.reflect.Reflection.ensureMemberAccess(Reflection.java:65) at java.lang.reflect.Method.invoke(Method.java:583) at org.armedbear.lisp.Java.jcall(Java.java:660) This from http://svn.mumble.net:8080/svn/lsw/trunk/patches/jarfile.lisp where I'm starting to add more path functions that work with the jar:file: pathname scheme. Feel free to steal and incorporate into abcl. -Alan

3 12

[armedbear-devel] loading from jar files
by Alan Ruttenberg 08 Jan '10

08 Jan '10

Seems like the extension is ignored and either lisp or .abcls files are loaded. This means that .asd files are not (an error is thrown) It also means that requests for files that don't exist get satisfied, e.g. if you give it a bogus filetype but there is a .lisp or .abcl file present. e.g. (load "jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar1.li") ; Loading jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar1.li ... Whoops - there is no bar1.li, just bar1.lisp (load "jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar.asd") The file #P"jar:file:/Users/alanr/repos/lsw/trunk/patches/test.jar!/bar/bar.asd" does not exist. Whoops - it does so! -Alan

3 8

[armedbear-devel] compiler problem
by Alan Ruttenberg 07 Jan '10

07 Jan '10

I sent a message earlier in the week about a miscompilation - a case where jss was landing up calling a java function on a cons rather than the intended object. In case it helps, here is a function in which that happens as well as the disassembly. The call that is miscompiled is the call to #"setLayout, which expands to ((LAMBDA (OBJECT &REST ARGS) (INVOKE-RESTARGS "setLayout" OBJECT ARGS NIL)) PANEL LAYOUT) It's hard for me to follow the disassembly, but I see: ; // 142 242:getstatic #88 <Field Symbol SYM13802_GET_JAVA_FIELD> ; // 143 245:getstatic #86 <Field Symbol SYM13801_JAVAAWTGRIDBAGCONSTRAINTS> ; // 144 248:getstatic #90 <Field SimpleString STR13803> ; // 145 251:invokevirtual #93 <Method LispObject LispThread.execute(LispObject, LispObject, LispObject)> which apparently is the call to compute the value for remainder, immediately before the setLayout call. I'm guessing that <Field LispObject LFUN13809> is the compiled function for the lambda in the macroexpansion. (BTW, I don't see why there would be an actual function created here - should be optimized away) You can see that the values to the call to setLayout, are java objects. (panel (new 'javax.swing.JPanel)) (layout (new 'java.awt.GridBagLayout)) However the call results in the error Debugger invoked on condition of type JAVA-EXCEPTION: SchemeException: ERROR: NO INSTANCE METHOD OF TYPE (.setLayout org.armedbear.lisp.Cons ...) at jsint.E.error(E.java:14) at jsint.E.error(E.java:19) at jsint.Invoke.methodTable(Invoke.java:221) at jsint.Invoke.invokeMethod(Invoke.java:117) at jsint.Invoke.invokeInstance(Invoke.java:110) at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:592) at org.armedbear.lisp.Java.jstatic(Java.java:393) at org.armedbear.lisp.Java.access$600(Java.java:51) at org.armedbear.lisp.Java$8.execute(Java.java:424) at org.armedbear.lisp.Primitive.execute(Primitive.java:174) .... So apparently the wrong argument is being passed in. As I said, the function executes properly when evaluated. The same error occurs in other methods that call java function in this way - the wrong argument is passed in. In another call (in a different function) I see (.setLayout org.armedbear.lisp.StandardGenericFunction ...) at jsint.E.error(E.java:14) at jsint.E.error(E.java:19) And elsewhere with calls to different java functions. Hope this gives you something to go on. -Alan (defmethod make-contents ((this inspector)) (with-slots (object header fields table table-maker history) this (let ((table-panel nil) (panel (new 'javax.swing.JPanel)) (layout (new 'java.awt.GridBagLayout)) (constraints (new 'java.awt.GridBagConstraints)) (remainder (get-java-field 'java.awt.GridBagConstraints "REMAINDER"))) (#"setLayout" panel layout) (labels ((add-component (comp) (#"setConstraints" layout comp constraints) (#"add" panel comp)) (jump-selected () (multiple-value-bind (field row) (selected-field this) (oojump this field row t)))) (loop for button in (make-inspector-buttons this) do (add-component button)) (setq table-maker #'(lambda () (if table-panel (let ((parent (#"getParent" table-panel))) (#"remove" parent table-panel))) (set-java-field constraints "gridwidth" remainder) (set-java-field constraints "gridheight" remainder) (set-java-field constraints "weightx" 1.0) (set-java-field constraints "weighty" 1.0) (set-java-field constraints "gridx" 0) (set-java-field constraints "gridy" 1) (set-java-field constraints "fill" (get-java-field 'java.awt.GridBagConstraints "BOTH")) (let ((data (oinspect-data this object))) (setq header (car data)) (setq fields (cdr data)) (setq table (make-table (mapcar #'(lambda (row) (mapcar #'(lambda (field) (tostring this field)) row)) fields) header))) (#"addMouseListener" table (jinterface-safe-implementation (jclass "java.awt.event.MouseListener") "mousePressed" #'(lambda (evt) (if (= (#"getClickCount" evt) 2) (jump-selected))))) (#"addMouseMotionListener" table (jinterface-safe-implementation (jclass "java.awt.event.MouseMotionListener") "mouseMoved" #'(lambda (evt) (let* ((point (#"getPoint" evt)) (col (#"columnAtPoint" table point)) (row (#"rowAtPoint" table point)) (value (value-at this row col))) (#"setToolTipText" table (html-wrap-string (tostring this value))))))) (setq table-panel (make-table-panel table 350 200)) (add-component table-panel))) (funcall table-maker) panel)))) CL-USER(82): (disassemble (mop::%method-function (car (mop::%compute-applicable-methods #'make-contents (list (make-instance 'inspector)))))) ; Couldn't fully decompile method execute ; // Decompiled by Jad v1.5.8g. Copyright 2001 Pavel Kouznetsov. ; // Jad home page: http://www.kpdus.com/jad.html ; // Decompiler options: packimports(3) annotate ; // Source File Name: oinspect.lisp ; ; package org.armedbear.lisp; ; ; ; // Referenced classes of package org.armedbear.lisp: ; // Primitive, LispThread, ClosureBinding, LispObject, ; // Lisp, CompiledClosure, Symbol, SimpleString, ; // AutoloadedFunctionProxy ; ; public class oinspect_21 extends Primitive ; { ; ; public LispObject execute(LispObject lispobject, LispObject lispobject1) ; { ; LispThread lispthread; ; ClosureBinding aclosurebinding[]; ; lispthread = LispThread.currentThread(); ; // 0 0:invokestatic #54 <Method LispThread LispThread.currentThread()> ; // 1 3:astore_3 ; aclosurebinding = (new ClosureBinding[] { ; new ClosureBinding(null), new ClosureBinding(null), new ClosureBinding(null), new ClosureBinding(null), new ClosureBinding(null), new ClosureBinding(null), new ClosureBinding(null), new ClosureBinding(null), new ClosureBinding(null) ; }); ; // 2 4:bipush 9 ; // 3 6:anewarray ClosureBinding[] ; // 4 9:dup ; // 5 10:iconst_0 ; // 6 11:new #56 <Class ClosureBinding> ; // 7 14:dup ; // 8 15:aconst_null ; // 9 16:invokespecial #60 <Method void ClosureBinding(LispObject)> ; // 10 19:aastore ; // 11 20:dup ; // 12 21:iconst_1 ; // 13 22:new #56 <Class ClosureBinding> ; // 14 25:dup ; // 15 26:aconst_null ; // 16 27:invokespecial #60 <Method void ClosureBinding(LispObject)> ; // 17 30:aastore ; // 18 31:dup ; // 19 32:iconst_2 ; // 20 33:new #56 <Class ClosureBinding> ; // 21 36:dup ; // 22 37:aconst_null ; // 23 38:invokespecial #60 <Method void ClosureBinding(LispObject)> ; // 24 41:aastore ; // 25 42:dup ; // 26 43:iconst_3 ; // 27 44:new #56 <Class ClosureBinding> ; // 28 47:dup ; // 29 48:aconst_null ; // 30 49:invokespecial #60 <Method void ClosureBinding(LispObject)> ; // 31 52:aastore ; // 32 53:dup ; // 33 54:iconst_4 ; // 34 55:new #56 <Class ClosureBinding> ; // 35 58:dup ; // 36 59:aconst_null ; // 37 60:invokespecial #60 <Method void ClosureBinding(LispObject)> ; // 38 63:aastore ; // 39 64:dup ; // 40 65:iconst_5 ; // 41 66:new #56 <Class ClosureBinding> ; // 42 69:dup ; // 43 70:aconst_null ; // 44 71:invokespecial #60 <Method void ClosureBinding(LispObject)> ; // 45 74:aastore ; // 46 75:dup ; // 47 76:bipush 6 ; // 48 78:new #56 <Class ClosureBinding> ; // 49 81:dup ; // 50 82:aconst_null ; // 51 83:invokespecial #60 <Method void ClosureBinding(LispObject)> ; // 52 86:aastore ; // 53 87:dup ; // 54 88:bipush 7 ; // 55 90:new #56 <Class ClosureBinding> ; // 56 93:dup ; // 57 94:aconst_null ; // 58 95:invokespecial #60 <Method void ClosureBinding(LispObject)> ; // 59 98:aastore ; // 60 99:dup ; // 61 100:bipush 8 ; // 62 102:new #56 <Class ClosureBinding> ; // 63 105:dup ; // 64 106:aconst_null ; // 65 107:invokespecial #60 <Method void ClosureBinding(LispObject)> ; // 66 110:aastore ; // 67 111:astore 4 ; new ClosureBinding(lispobject.car()); ; // 68 113:aload_1 ; // 69 114:invokevirtual #66 <Method LispObject LispObject.car()> ; // 70 117:new #56 <Class ClosureBinding> ; // 71 120:dup_x1 ; // 72 121:swap ; // 73 122:invokespecial #60 <Method void ClosureBinding(LispObject)> ; aclosurebinding; ; // 74 125:aload 4 ; JVM INSTR swap ; ; // 75 127:swap ; 0; ; // 76 128:iconst_0 ; JVM INSTR swap ; ; // 77 129:swap ; JVM INSTR aastore ; ; // 78 130:aastore ; new ClosureBinding(aclosurebinding[0].value); ; // 79 131:aload 4 ; // 80 133:iconst_0 ; // 81 134:aaload ; // 82 135:getfield #69 <Field LispObject ClosureBinding.value> ; // 83 138:new #56 <Class ClosureBinding> ; // 84 141:dup_x1 ; // 85 142:swap ; // 86 143:invokespecial #60 <Method void ClosureBinding(LispObject)> ; aclosurebinding; ; // 87 146:aload 4 ; JVM INSTR swap ; ; // 88 148:swap ; 1; ; // 89 149:iconst_1 ; JVM INSTR swap ; ; // 90 150:swap ; JVM INSTR aastore ; ; // 91 151:aastore ; new ClosureBinding(Lisp.NIL); ; // 92 152:getstatic #74 <Field LispObject Lisp.NIL> ; // 93 155:new #56 <Class ClosureBinding> ; // 94 158:dup_x1 ; // 95 159:swap ; // 96 160:invokespecial #60 <Method void ClosureBinding(LispObject)> ; aclosurebinding; ; // 97 163:aload 4 ; JVM INSTR swap ; ; // 98 165:swap ; 2; ; // 99 166:iconst_2 ; JVM INSTR swap ; ; // 100 167:swap ; JVM INSTR aastore ; ; // 101 168:aastore ; new ClosureBinding(lispthread.execute(SYM13798_NEW, SYM13799_JAVAXSWINGJPANEL)); ; // 102 169:aload_3 ; // 103 170:getstatic #78 <Field Symbol SYM13798_NEW> ; // 104 173:getstatic #80 <Field Symbol SYM13799_JAVAXSWINGJPANEL> ; // 105 176:invokevirtual #82 <Method LispObject LispThread.execute(LispObject, LispObject)> ; // 106 179:new #56 <Class ClosureBinding> ; // 107 182:dup_x1 ; // 108 183:swap ; // 109 184:invokespecial #60 <Method void ClosureBinding(LispObject)> ; aclosurebinding; ; // 110 187:aload 4 ; JVM INSTR swap ; ; // 111 189:swap ; 3; ; // 112 190:iconst_3 ; JVM INSTR swap ; ; // 113 191:swap ; JVM INSTR aastore ; ; // 114 192:aastore ; new ClosureBinding(lispthread.execute(SYM13798_NEW, SYM13800_JAVAAWTGRIDBAGLAYOUT)); ; // 115 193:aload_3 ; // 116 194:getstatic #78 <Field Symbol SYM13798_NEW> ; // 117 197:getstatic #84 <Field Symbol SYM13800_JAVAAWTGRIDBAGLAYOUT> ; // 118 200:invokevirtual #82 <Method LispObject LispThread.execute(LispObject, LispObject)> ; // 119 203:new #56 <Class ClosureBinding> ; // 120 206:dup_x1 ; // 121 207:swap ; // 122 208:invokespecial #60 <Method void ClosureBinding(LispObject)> ; aclosurebinding; ; // 123 211:aload 4 ; JVM INSTR swap ; ; // 124 213:swap ; 4; ; // 125 214:iconst_4 ; JVM INSTR swap ; ; // 126 215:swap ; JVM INSTR aastore ; ; // 127 216:aastore ; new ClosureBinding(lispthread.execute(SYM13798_NEW, SYM13801_JAVAAWTGRIDBAGCONSTRAINTS)); ; // 128 217:aload_3 ; // 129 218:getstatic #78 <Field Symbol SYM13798_NEW> ; // 130 221:getstatic #86 <Field Symbol SYM13801_JAVAAWTGRIDBAGCONSTRAINTS> ; // 131 224:invokevirtual #82 <Method LispObject LispThread.execute(LispObject, LispObject)> ; // 132 227:new #56 <Class ClosureBinding> ; // 133 230:dup_x1 ; // 134 231:swap ; // 135 232:invokespecial #60 <Method void ClosureBinding(LispObject)> ; aclosurebinding; ; // 136 235:aload 4 ; JVM INSTR swap ; ; // 137 237:swap ; 5; ; // 138 238:iconst_5 ; JVM INSTR swap ; ; // 139 239:swap ; JVM INSTR aastore ; ; // 140 240:aastore ; new ClosureBinding(lispthread.execute(SYM13802_GET_JAVA_FIELD, SYM13801_JAVAAWTGRIDBAGCONSTRAINTS, STR13803)); ; // 141 241:aload_3 ; // 142 242:getstatic #88 <Field Symbol SYM13802_GET_JAVA_FIELD> ; // 143 245:getstatic #86 <Field Symbol SYM13801_JAVAAWTGRIDBAGCONSTRAINTS> ; // 144 248:getstatic #90 <Field SimpleString STR13803> ; // 145 251:invokevirtual #93 <Method LispObject LispThread.execute(LispObject, LispObject, LispObject)> ; // 146 254:new #56 <Class ClosureBinding> ; // 147 257:dup_x1 ; // 148 258:swap ; // 149 259:invokespecial #60 <Method void ClosureBinding(LispObject)> ; aclosurebinding; ; // 150 262:aload 4 ; JVM INSTR swap ; ; // 151 264:swap ; 6; ; // 152 265:bipush 6 ; JVM INSTR swap ; ; // 153 267:swap ; JVM INSTR aastore ; ; // 154 268:aastore ; ClosureBinding aclosurebinding1[]; ; lispthread._values = null; ; // 155 269:aload_3 ; // 156 270:aconst_null ; // 157 271:putfield #97 <Field LispObject[] LispThread._values> ; //* 158 274:getstatic #99 <Field LispObject LFUN13809> ; System.arraycopy(aclosurebinding, 0, aclosurebinding1 = new ClosureBinding[9], 0, 9); ; // 159 277:aload 4 ; // 160 279:iconst_0 ; // 161 280:bipush 9 ; // 162 282:anewarray ClosureBinding[] ; // 163 285:dup ; // 164 286:astore 5 ; // 165 288:iconst_0 ; // 166 289:bipush 9 ; // 167 291:invokestatic #105 <Method void System.arraycopy(Object, int, Object, int, int)> ; Lisp.makeCompiledClosure(LFUN13809, aclosurebinding1); ; // 168 294:aload 5 ; // 169 296:invokestatic #109 <Method LispObject Lisp.makeCompiledClosure(LispObject, ClosureBinding[])> ; lispthread; ; // 170 299:aload_3 ; JVM INSTR swap ; ; // 171 300:swap ; aclosurebinding[3].value; ; // 172 301:aload 4 ; // 173 303:iconst_3 ; // 174 304:aaload ; // 175 305:getfield #69 <Field LispObject ClosureBinding.value> ; aclosurebinding[4].value; ; // 176 308:aload 4 ; // 177 310:iconst_4 ; // 178 311:aaload ; // 179 312:getfield #69 <Field LispObject ClosureBinding.value> ; execute(); ; // 180 315:invokevirtual #93 <Method LispObject LispThread.execute(LispObject, LispObject, LispObject)> ; JVM INSTR pop ; ; // 181 318:pop ; lispthread._values = null; ; // 182 319:aload_3 ; // 183 320:aconst_null ; // 184 321:putfield #97 <Field LispObject[] LispThread._values> ; //* 185 324:getstatic #111 <Field LispObject LFUN13827> ; //* 186 327:checkcast #113 <Class CompiledClosure> ; System.arraycopy(aclosurebinding, 0, aclosurebinding1 = new ClosureBinding[9], 0, 9); ; // 187 330:aload 4 ; // 188 332:iconst_0 ; // 189 333:bipush 9 ; // 190 335:anewarray ClosureBinding[] ; // 191 338:dup ; // 192 339:astore 5 ; // 193 341:iconst_0 ; // 194 342:bipush 9 ; // 195 344:invokestatic #105 <Method void System.arraycopy(Object, int, Object, int, int)> ; Lisp.makeCompiledClosure((CompiledClosure)LFUN13827, aclosurebinding1); ; // 196 347:aload 5 ; // 197 349:invokestatic #109 <Method LispObject Lisp.makeCompiledClosure(LispObject, ClosureBinding[])> ; aclosurebinding[7]; ; // 198 352:aload 4 ; // 199 354:bipush 7 ; // 200 356:aaload ; JVM INSTR swap ; ; // 201 357:swap ; value; ; // 202 358:putfield #69 <Field LispObject ClosureBinding.value> ; //* 203 361:getstatic #115 <Field LispObject LFUN13838> ; //* 204 364:checkcast #113 <Class CompiledClosure> ; System.arraycopy(aclosurebinding, 0, aclosurebinding1 = new ClosureBinding[9], 0, 9); ; // 205 367:aload 4 ; // 206 369:iconst_0 ; // 207 370:bipush 9 ; // 208 372:anewarray ClosureBinding[] ; // 209 375:dup ; // 210 376:astore 5 ; // 211 378:iconst_0 ; // 212 379:bipush 9 ; // 213 381:invokestatic #105 <Method void System.arraycopy(Object, int, Object, int, int)> ; Lisp.makeCompiledClosure((CompiledClosure)LFUN13838, aclosurebinding1); ; // 214 384:aload 5 ; // 215 386:invokestatic #109 <Method LispObject Lisp.makeCompiledClosure(LispObject, ClosureBinding[])> ; aclosurebinding[8]; ; // 216 389:aload 4 ; // 217 391:bipush 8 ; // 218 393:aaload ; JVM INSTR swap ; ; // 219 394:swap ; value; ; // 220 395:putfield #69 <Field LispObject ClosureBinding.value> ; LispObject lispobject2 = Lisp.NIL; ; // 221 398:getstatic #74 <Field LispObject Lisp.NIL> ; // 222 401:astore 5 ; LispObject lispobject4 = lispthread.execute(SYM13842_MAKE_INSPECTOR_BUTTONS, aclosurebinding[0].value); ; // 223 403:aload_3 ; // 224 404:getstatic #117 <Field Symbol SYM13842_MAKE_INSPECTOR_BUTTONS> ; // 225 407:aload 4 ; // 226 409:iconst_0 ; // 227 410:aaload ; // 228 411:getfield #69 <Field LispObject ClosureBinding.value> ; // 229 414:invokevirtual #82 <Method LispObject LispThread.execute(LispObject, LispObject)> ; // 230 417:astore 6 ; lispthread._values = null; ; // 231 419:aload_3 ; // 232 420:aconst_null ; // 233 421:putfield #97 <Field LispObject[] LispThread._values> ; do ; { ; if(lispobject4.endp()) ; //* 234 424:aload 6 ; //* 235 426:invokevirtual #121 <Method boolean LispObject.endp()> ; //* 236 429:ifeq 444 ; { ; if(Lisp.interrupted) ; //* 237 432:getstatic #125 <Field boolean Lisp.interrupted> ; //* 238 435:ifeq 441 ; Lisp.handleInterrupt(); ; // 239 438:invokestatic #129 <Method void Lisp.handleInterrupt()> ; break; ; // 240 441:goto 484 ; } ; LispObject lispobject3 = lispobject4.car(); ; // 241 444:aload 6 ; // 242 446:invokevirtual #66 <Method LispObject LispObject.car()> ; // 243 449:astore 5 ; lispobject4 = lispobject4.cdr(); ; // 244 451:aload 6 ; // 245 453:invokevirtual #132 <Method LispObject LispObject.cdr()> ; // 246 456:astore 6 ; aclosurebinding[7].value.execute(lispobject3); ; // 247 458:aload 4 ; // 248 460:bipush 7 ; // 249 462:aaload ; // 250 463:getfield #69 <Field LispObject ClosureBinding.value> ; // 251 466:aload 5 ; // 252 468:invokevirtual #135 <Method LispObject LispObject.execute(LispObject)> ; // 253 471:pop ; if(Lisp.interrupted) ; //* 254 472:getstatic #125 <Field boolean Lisp.interrupted> ; //* 255 475:ifeq 481 ; Lisp.handleInterrupt(); ; // 256 478:invokestatic #129 <Method void Lisp.handleInterrupt()> ; } while(true); ; // 257 481:goto 424 ; lispthread._values = null; ; // 258 484:aload_3 ; // 259 485:aconst_null ; // 260 486:putfield #97 <Field LispObject[] LispThread._values> ; //* 261 489:aload_3 ; //* 262 490:getstatic #137 <Field Symbol SYM13851_SET_SLOT_VALUE> ; //* 263 493:aload 4 ; //* 264 495:iconst_1 ; //* 265 496:aaload ; //* 266 497:getfield #69 <Field LispObject ClosureBinding.value> ; //* 267 500:getstatic #139 <Field Symbol SYM13852_TABLE_MAKER> ; //* 268 503:getstatic #141 <Field LispObject LFUN13987> ; ClosureBinding aclosurebinding2[]; ; System.arraycopy(aclosurebinding, 0, aclosurebinding2 = new ClosureBinding[9], 0, 9); ; // 269 506:aload 4 ; // 270 508:iconst_0 ; // 271 509:bipush 9 ; // 272 511:anewarray ClosureBinding[] ; // 273 514:dup ; // 274 515:astore 5 ; // 275 517:iconst_0 ; // 276 518:bipush 9 ; // 277 520:invokestatic #105 <Method void System.arraycopy(Object, int, Object, int, int)> ; lispthread.execute(SYM13851_SET_SLOT_VALUE, aclosurebinding[1].value, SYM13852_TABLE_MAKER, Lisp.makeCompiledClosure(LFUN13987, aclosurebinding2)); ; // 278 523:aload 5 ; // 279 525:invokestatic #109 <Method LispObject Lisp.makeCompiledClosure(LispObject, ClosureBinding[])> ; // 280 528:invokevirtual #144 <Method LispObject LispThread.execute(LispObject, LispObject, LispObject, LispObject)> ; // 281 531:pop ; lispthread.execute(Symbol.SLOT_VALUE, aclosurebinding[1].value, SYM13852_TABLE_MAKER); ; // 282 532:aload_3 ; // 283 533:getstatic #149 <Field Symbol Symbol.SLOT_VALUE> ; // 284 536:aload 4 ; // 285 538:iconst_1 ; // 286 539:aaload ; // 287 540:getfield #69 <Field LispObject ClosureBinding.value> ; // 288 543:getstatic #139 <Field Symbol SYM13852_TABLE_MAKER> ; // 289 546:invokevirtual #93 <Method LispObject LispThread.execute(LispObject, LispObject, LispObject)> ; lispthread; ; // 290 549:aload_3 ; JVM INSTR swap ; ; // 291 550:swap ; execute(); ; // 292 551:invokevirtual #150 <Method LispObject LispThread.execute(LispObject)> ; JVM INSTR pop ; ; // 293 554:pop ; lispthread._values = null; ; // 294 555:aload_3 ; // 295 556:aconst_null ; // 296 557:putfield #97 <Field LispObject[] LispThread._values> ; return aclosurebinding[3].value; ; // 297 560:aload 4 ; // 298 562:iconst_3 ; // 299 563:aaload ; // 300 564:getfield #69 <Field LispObject ClosureBinding.value> ; // 301 567:areturn ; } ; ; public oinspect_21() ; { ; super(Lisp.NIL, Lisp.readObjectFromString("(MOP::ARGS MOP::NEXT-EMFUN)")); ; // 0 0:aload_0 ; // 1 1:getstatic #74 <Field LispObject Lisp.NIL> ; // 2 4:ldc1 #154 <String "(MOP::ARGS MOP::NEXT-EMFUN)"> ; // 3 6:invokestatic #158 <Method LispObject Lisp.readObjectFromString(String)> ; // 4 9:invokespecial #161 <Method void Primitive(LispObject, LispObject)> ; // 5 12:ldc1 #6 <String "NEW"> ; // 6 14:ldc1 #8 <String "COMMON-LISP-USER"> ; // 7 16:invokestatic #165 <Method Symbol Lisp.internInPackage(String, String)> ; // 8 19:putstatic #78 <Field Symbol SYM13798_NEW> ; // 9 22:ldc1 #11 <String "JAVAX.SWING.JPANEL"> ; // 10 24:ldc1 #8 <String "COMMON-LISP-USER"> ; // 11 26:invokestatic #165 <Method Symbol Lisp.internInPackage(String, String)> ; // 12 29:putstatic #80 <Field Symbol SYM13799_JAVAXSWINGJPANEL> ; // 13 32:ldc1 #14 <String "JAVA.AWT.GRIDBAGLAYOUT"> ; // 14 34:ldc1 #8 <String "COMMON-LISP-USER"> ; // 15 36:invokestatic #165 <Method Symbol Lisp.internInPackage(String, String)> ; // 16 39:putstatic #84 <Field Symbol SYM13800_JAVAAWTGRIDBAGLAYOUT> ; // 17 42:ldc1 #17 <String "JAVA.AWT.GRIDBAGCONSTRAINTS"> ; // 18 44:ldc1 #8 <String "COMMON-LISP-USER"> ; // 19 46:invokestatic #165 <Method Symbol Lisp.internInPackage(String, String)> ; // 20 49:putstatic #86 <Field Symbol SYM13801_JAVAAWTGRIDBAGCONSTRAINTS> ; // 21 52:ldc1 #20 <String "GET-JAVA-FIELD"> ; // 22 54:ldc1 #8 <String "COMMON-LISP-USER"> ; // 23 56:invokestatic #165 <Method Symbol Lisp.internInPackage(String, String)> ; // 24 59:putstatic #88 <Field Symbol SYM13802_GET_JAVA_FIELD> ; // 25 62:new #167 <Class SimpleString> ; // 26 65:dup ; // 27 66:ldc1 #24 <String "REMAINDER"> ; // 28 68:invokespecial #170 <Method void SimpleString(String)> ; // 29 71:putstatic #90 <Field SimpleString STR13803> ; // 30 74:ldc1 #28 <String "oinspect-22.cls"> ; // 31 76:invokestatic #175 <Method LispObject AutoloadedFunctionProxy.loadPreloadedFunction(String)> ; // 32 79:putstatic #99 <Field LispObject LFUN13809> ; // 33 82:ldc1 #31 <String "oinspect-23.cls"> ; // 34 84:invokestatic #175 <Method LispObject AutoloadedFunctionProxy.loadPreloadedFunction(String)> ; // 35 87:putstatic #111 <Field LispObject LFUN13827> ; // 36 90:ldc1 #34 <String "oinspect-26.cls"> ; // 37 92:invokestatic #175 <Method LispObject AutoloadedFunctionProxy.loadPreloadedFunction(String)> ; // 38 95:putstatic #115 <Field LispObject LFUN13838> ; // 39 98:ldc1 #37 <String "MAKE-INSPECTOR-BUTTONS"> ; // 40 100:ldc1 #8 <String "COMMON-LISP-USER"> ; // 41 102:invokestatic #165 <Method Symbol Lisp.internInPackage(String, String)> ; // 42 105:putstatic #117 <Field Symbol SYM13842_MAKE_INSPECTOR_BUTTONS> ; // 43 108:ldc1 #40 <String "%SET-SLOT-VALUE"> ; // 44 110:ldc1 #42 <String "MOP"> ; // 45 112:invokestatic #165 <Method Symbol Lisp.internInPackage(String, String)> ; // 46 115:putstatic #137 <Field Symbol SYM13851_SET_SLOT_VALUE> ; // 47 118:ldc1 #45 <String "TABLE-MAKER"> ; // 48 120:ldc1 #8 <String "COMMON-LISP-USER"> ; // 49 122:invokestatic #165 <Method Symbol Lisp.internInPackage(String, String)> ; // 50 125:putstatic #139 <Field Symbol SYM13852_TABLE_MAKER> ; // 51 128:ldc1 #48 <String "oinspect-27.cls"> ; // 52 130:invokestatic #175 <Method LispObject AutoloadedFunctionProxy.loadPreloadedFunction(String)> ; // 53 133:putstatic #141 <Field LispObject LFUN13987> ; // 54 136:return ; } ; ; static final LispObject LFUN13987 = AutoloadedFunctionProxy.loadPreloadedFunction("oinspect-27.cls"); ; private static final Symbol SYM13852_TABLE_MAKER = Lisp.internInPackage("TABLE-MAKER", "COMMON-LISP-USER"); ; private static final Symbol SYM13851_SET_SLOT_VALUE = Lisp.internInPackage("%SET-SLOT-VALUE", "MOP"); ; private static final Symbol SYM13842_MAKE_INSPECTOR_BUTTONS = Lisp.internInPackage("MAKE-INSPECTOR-BUTTONS", "COMMON-LISP-USER"); ; static final LispObject LFUN13838 = AutoloadedFunctionProxy.loadPreloadedFunction("oinspect-26.cls"); ; static final LispObject LFUN13827 = AutoloadedFunctionProxy.loadPreloadedFunction("oinspect-23.cls"); ; static final LispObject LFUN13809 = AutoloadedFunctionProxy.loadPreloadedFunction("oinspect-22.cls"); ; private static final SimpleString STR13803 = new SimpleString("REMAINDER"); ; private static final Symbol SYM13802_GET_JAVA_FIELD = Lisp.internInPackage("GET-JAVA-FIELD", "COMMON-LISP-USER"); ; private static final Symbol SYM13801_JAVAAWTGRIDBAGCONSTRAINTS = Lisp.internInPackage("JAVA.AWT.GRIDBAGCONSTRAINTS", "COMMON-LISP-USER"); ; private static final Symbol SYM13800_JAVAAWTGRIDBAGLAYOUT = Lisp.internInPackage("JAVA.AWT.GRIDBAGLAYOUT", "COMMON-LISP-USER"); ; private static final Symbol SYM13799_JAVAXSWINGJPANEL = Lisp.internInPackage("JAVAX.SWING.JPANEL", "COMMON-LISP-USER"); ; private static final Symbol SYM13798_NEW = Lisp.internInPackage("NEW", "COMMON-LISP-USER"); ; }

2 7

[armedbear-devel] Spurious errors about redefinitions
by Mark Evenson 06 Jan '10

06 Jan '10

Since Erik's autoload patches of about a week ago hit the tree that started to optimize the FASL loading, I see a lot of spurious errors about redefining symbols like the following when loading SLIME: STYLE-WARNING: redefining SWANK::%MAKE-FUZZY-MATCHING in #P"/Users/evenson/work/slime/contrib/swank-fuzzy.lisp" (previously defined in NIL) STYLE-WARNING: redefining SWANK::FUZZY-MATCHING-P in #P"/Users/evenson/work/slime/contrib/swank-fuzzy.lisp" (previously defined in NIL) STYLE-WARNING: redefining SWANK::FUZZY-MATCHING.SYMBOL in #P"/Users/evenson/work/slime/contrib/swank-fuzzy.lisp" (previously defined in NIL) STYLE-WARNING: redefining SWANK::FUZZY-MATCHING.PACKAGE-NAME in #P"/Users/evenson/work/slime/contrib/swank-fuzzy.lisp" (previously defined in NIL) I thought this was taken care of with [svn 12324][1], but this doesn't seem to be the case. I haven't yet been able to isolate the behavior yet, but if someone knows a quick fix, that would be great. [1]: http://code.google.com/p/abcl-dynamic-install/source/detail?r=ad17b2b2733ee… -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

4 8

[armedbear-devel] User-extensible sequences?
by Axel Rauschmayer 06 Jan '10

06 Jan '10

I was looking for something similar to lazy lists or iterators in CL and asked a friend who told me about the following paper (abstract see below): http://www.doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdf Is this something worthy of inclusion into ABCL? -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/ User-extensible sequences in Common Lisp Christophe Rhodes Common Lisp is often touted as the programmable programming language, yet it sometimes places large barriers in the way, with the best of intentions. One of those barriers is a limit to the extensibility by the user of certain core language constructs, such as the ability to define subclasses of builtin classes usable with standard functions: even where this could be achievable with minimal penalties. We introduce the notion of user-extensible sequences, describing a protocol which implementations of such classes should follow. We show examples of their use, and discuss the issues observed in providing support for this protocol in a Common Lisp, including ensuring that there is no performance impact from its inclusion.

2 2

[armedbear-devel] Working toward an 0.18 release
by Erik Huelsmann 05 Jan '10

05 Jan '10

Even though trunk isn't "feature complete" yet, I'd like us to start preparing the 0.18 release as we do every roughly 2 months. Every release consists of the following steps: * Update CHANGES * Check/update INSTALL * Write release notes * Run ANSI tests and CL-BENCH on trunk (but preferrably also Maxima tests) * Trial-run the release script for source and binary distributions * Run ANSI test and CL-BENCH on the release trial-release archives (but preferrably also Maxima tests) [Don't distribute the trial-release archives! We don't want several version 0.18's floating around...] Because I'd like to distribute the work, making light work for everybody, I'm looking for takers on any of these tasks. Bye, Erik.

2 2

[armedbear-devel] Tip: asterisks in classpaths
by Axel Rauschmayer 04 Jan '10

04 Jan '10

Java 6 has a feature that can help with plugging external JARs into ABCL: If the classpath includes an asterisk, all JARs in the given directory are added. For example, I've created the directory ~/local/abcl for my ABCL installation that includes abcl.jar plus any other JARs I want to use. Then the following command automatically adds everything in that directory to the classpath and starts ABCL: > exec java -cp "$HOME/local/abcl/*" \ > org.armedbear.lisp.Main \ > "$@" (The "exec" can probably be omitted) -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/

1 0

[armedbear-devel] patch for converting LispErrors to ProgramErrors in Closure.java, also removes some of the assertions
by Ville Voutilainen 04 Jan '10

04 Jan '10

It looks like some of the assertions may be actually valid as assertions. The remaining ones are: 1) in Closure constructor, parsing of parameters else if (obj instanceof Cons) { if (state == STATE_AUX) { Symbol sym = checkSymbol(obj.car()); LispObject initForm = obj.cadr(); Debug.assertTrue(initForm != null); if (aux == null) aux = new ArrayList<Parameter>(); aux.add(new Parameter(sym, initForm, AUX)); } I don't see how to create a null initform other than creating a Cons that has a null car or cdr. And I don't know how to do that from lisp code. To me, that looks like it requires serious abuse from the Java side to accomplish. And I don't think that would be the only place where the validity of a Cons would need to be checked. I'm inclined to just remove that assertion completely. 2) again in Closure constructor, else { // Lambda list is empty. Debug.assertTrue(lambdaList == NIL); arity = 0; maxArgs = 0; } That's an else branch of if (lambdaList instanceof Cons), and it looks like it asserts that our own code in Closure is correct. I'm inclined to keep that assertion as is. 3) if (arity >= 0) Debug.assertTrue(arity == minArgs); a couple of lines down, check that minArgs is equal to arity if arity isn't negative. Looks correct to me, I'm inclined to keep it as is. 4) if (optionalParameters.length == 0 && keywordParameters.length == 0) args = fastProcessArgs(args); else args = processArgs(args, thread); Debug.assertTrue(args.length == variables.length); in the array version of execute. That looks like it verifies that our argument processing works, and looks correct to me. I'm inclined to keep it as is. 5) Parameter.processInitForm: if (initForm.constantp()) { if (initForm instanceof Symbol) return initForm.getSymbolValue(); if (initForm instanceof Cons) { Debug.assertTrue(initForm.car() == Symbol.QUOTE); return initForm.cadr(); } I'm not sure what is going on here. I don't know how to concoct a lambda that has a constant initform for a parameter so that the initform is Cons but is not quoted. Granted, I've mainly tested these changes with defuns, so I wouldn't be surprised if such a failure case can be demonstrated. I have no inclination here, this looks like it should probably be a ProgramError rather than an assert. Please review these cases (and the patch itself) and comment. I ran the tests and I have a failure in MAKE-BROADCAST-STREAM.8 that my baseline doesn't have, but I'm not sure if it's related to these changes.

1 0

Re: [armedbear-devel] SETF for JFEILDS
by logicmoo＠gmail.com 30 Dec '09

30 Dec '09

Thanks, you are right, much better to use the built-in key stuff (defun (setf jfield) (newvalue class-ref-or-field field-or-instance &optional ( instance nil instance-supplied-p) unused-value) (declare (ignore unused-value)) (if instance-supplied-p (jfield class-ref-or-field field-or-instance instance newvalue) (jfield class-ref-or-field field-or-instance newvalue))) ----- Original Message ----- From: "Thomas Russ" <tar(a)ISI.EDU> To: <dmiles(a)users.sourceforge.net> Sent: Tuesday, November 24, 2009 9:24 AM Subject: Re: [armedbear-devel] SETF for JFEILDS On Nov 23, 2009, at 6:47 AM, logicmoo(a)gmail.com wrote: > So actually > > (defun (setf jfield) (newvalue class-ref-or-field field-or- > instance &optional ( instance :noinst) unusedvalue) > (if (eq instance :noinst) > (jfield class-ref-or-field field-or-instance newvalue) > (jfield class-ref-or-field field-or-instance instance newvalue))) > > Would be a little better.. good eye. For what it's worth, I am not a fan of using special values to determine whether optional (or keyword) arguments are actually passed or not. I prefer to use the predicate forms from the lambda list, so something more like (defun (setf jfield) (newvalue class-ref-or-field field-or-instance &optional ( instance nil instance-supplied-p) unusedvalue) (declare (ignore unusedvalue)) (if instance-supplied-p (jfield class-ref-or-field field-or-instance newvalue) (jfield class-ref-or-field field-or-instance instance newvalue))) > > > ----- Original Message ----- > From: <dmiles(a)users.sourceforge.net> > To: "Alessio Stalla" <alessiostalla(a)gmail.com> > Cc: "Armed Bear" <armedbear-devel(a)common-lisp.net> > Sent: Monday, November 23, 2009 6:27 AM > Subject: Re: [armedbear-devel] SETF for JFEILDS > > >> >> ----- Original Message ----- >> From: "Alessio Stalla" <alessiostalla(a)gmail.com> >> To: <dmiles(a)users.sourceforge.net> >> Cc: "Armed Bear" <armedbear-devel(a)common-lisp.net> >> Sent: Monday, November 23, 2009 5:42 AM >> Subject: Re: [armedbear-devel] SETF for JFEILDS >> >> >> On Mon, Nov 23, 2009 at 2:36 PM, <logicmoo(a)gmail.com> wrote: >>>> Does anyone object to adding this to java.lisp? If not could it >>>> be done? >>>> >>>> (defun (setf jfield) >>>> (newvalue class-ref-or-field field-or-instance &optional >>>> ( instance :noinst) (value :novalue)) >>>> (if (eq instance :noinst) >>>> (jfield class-ref-or-field field-or-instance newvalue) >>>> (jfield class-ref-or-field field-or-instance instance newvalue))) >> >>> It seems a nice idea to me, but there are a couple of things that I >>> don't understand: >> >> A>- why :noinst and not simply nil? >> >> JFIELD is defined as: class-ref-or-field field-or-instance >> &optional instance value >> The valid argument patterns for this operation are: >> (class-ref field-name): to retrieve the value of a static field. >> (class-ref field-name instance-ref): to retrieve the value of a >> class field of the instance. >> (class-ref field-name primitive-value:) to store primitive-value >> in a static field. >> (class-ref field-name instance-ref value): to store value in a >> class field of the instance. >> (class-ref field-name nil value): to store value in a static >> field (when value may be confused with an instance-ref). >> (field-name instance): to retrieve the value of a field of the >> instance. The class is derived from the instance. >> (field-name instance value): to store value in a field of the >> instance. The class is derived from the instance. >> >> JFIELD doesn't distingusih between static and non static fields >> >> Also cases of "class-ref field-name instance-ref >> value" (accessing superclass field) >> >> Depending on how the field is defined >> >> (setf (jfield *MyClass* "someStaticBooleanField") NIL) >> it is distinguable from >> (setf (jfield *MySuperClass* "nonStaticBooleanField" *my- >> instance* ) NIL) >> >> >> -------------------------------------------------------------------------------------------------------------------------- >> A>- value is not used, what's the point of it? >> >> correct the "default :novalue" is not needed. >> (I was debugging and trying to find corner cases with all those >> bizzare legal jfield signatures ) >> >> >> but... "value" as an &optional was needed to match the signature >> of what is legal for jfield so things like this can work: >> >> (define-symbol-macro %iscold (jfield "org.armedbear.lisp.Lisp" >> "cold")) >> %iscold ;; ==> NIL >> (setq %iscold T) ;; ==> T >> %iscold ;; ==> T >> (setq %iscold NIL) ;; ==> NIL >> >> > > _______________________________________________ > armedbear-devel mailing list > armedbear-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

7 19

[armedbear-devel] How do I release ABCL's "package-lock"?
by Peter Olsen 30 Dec '09

30 Dec '09

I'm writing to ask how to redefine the "or" macro in ABCL. I'm working on a project and there's one package in which I need "or" to mean something else than its usual definition. I've tried simply to redefine it, but it doesn't work. I understand that the Common Lisp spec requires special provision for that to be done --- such as the package-lock construct in SBCL. How can I do that in ABCL? I want to be able to do this within the code, for example, with in a "let" so that I can bound its scope. Can anyone point me in the right direction? My first --- failed --- experiment is below. Thanks! Peter ------------------------------------------------------- A way that doesn't work. slipstream:~ pcolsen$ abcl Armed Bear Common Lisp 0.17.0 Java 1.5.0_20 Apple Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 1.476 seconds. Startup completed in 4.363 seconds. Type ":help" for a list of available commands. CL-USER(1): (or nil t) T CL-USER(2): (defmacro or (x) (+ 1 x)) ; My very own new "or" OR CL-USER(3): (or 3) ; Result should be 4 3 CL-USER(4): (or nil nil) ; My "or" should take only one argument. NIL CL-USER(5): (or nil t) T CL-USER(6): ;;; Redefinition didn't work. Peter Olsen olsen(a)sigmaxi.net I have loved the stars too fondly to be fearful of the night. Galileo Galilei

4 3

[armedbear-devel] Fwd: [armedbear-cvs] r12311 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 30 Dec '09

30 Dec '09

Accidentally sent to Alessio only: ---------- Forwarded message ---------- From: Erik Huelsmann <ehuels(a)gmail.com> Date: Wed, Dec 30, 2009 at 12:08 AM Subject: Re: [armedbear-devel] [armedbear-cvs] r12311 - trunk/abcl/src/org/armedbear/lisp To: Alessio Stalla <alessiostalla(a)gmail.com> On Tue, Dec 29, 2009 at 1:16 AM, Alessio Stalla <alessiostalla(a)gmail.com> wrote: > On Tue, Dec 29, 2009 at 12:29 AM, Erik Huelsmann <ehuels(a)gmail.com> wrote: >> While the fix below does seem to fix slime - on my system, it doesn't >> fix all cases of what we're seeing: infinite recursion in clos.lisp, >> related to initial-discriminating-function. >> >> My own application suffers from the same issue, even after this fix. >> >> (just to let you know what our progress is) > > Erik, to update you on my own progress: > I found out that the infinite recursion is caused by > initial-discriminating-function being called before the class > standard-generic-function has been installed - (find-class > 'standard-generic-function) returns NIL. This means that the branch > that calls std-compute-discr.-function (the base case) never gets to > run, causing an infinite loop. To follow up on this discussion: Alessio and I found and fixed the issue: r12306 had broken an assumption in LOAD-TIME-VALUE. The fix has been committed. Bye, Erik.

2 4

Re: [armedbear-devel] [armedbear-cvs] r12311 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 28 Dec '09

28 Dec '09

While the fix below does seem to fix slime - on my system, it doesn't fix all cases of what we're seeing: infinite recursion in clos.lisp, related to initial-discriminating-function. My own application suffers from the same issue, even after this fix. (just to let you know what our progress is) Bye, Erik. On Tue, Dec 29, 2009 at 12:11 AM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Mon Dec 28 18:11:35 2009 > New Revision: 12311 > > Log: > Followup to r12306: "unbreak" Slime, at least partially. > > Modified: > trunk/abcl/src/org/armedbear/lisp/AutoloadedFunctionProxy.java > trunk/abcl/src/org/armedbear/lisp/LispObject.java > trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/AutoloadedFunctionProxy.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/AutoloadedFunctionProxy.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/AutoloadedFunctionProxy.java Mon Dec 28 18:11:35 2009 > @@ -68,6 +68,12 @@ > this.fType = ft; > } > > + /** Resolve this instance by returning the function we're proxy for */ > + @Override > + public LispObject resolve() { > + return load(); > + } > + > final private synchronized Function load() { > if (fun != null) > return fun; > @@ -249,6 +255,9 @@ > LispObject pack = Symbol._PACKAGE_.symbolValue(thread); > > if (cache instanceof Nil) > + // during EVAL-WHEN :compile-toplevel, this function will > + // be called without a caching environment; we'll need to > + // forward to the compiled function loader > return loadCompiledFunction(name.getStringValue()); > else { > fun = new AutoloadedFunctionProxy(sym, name, cache, pack, > > Modified: trunk/abcl/src/org/armedbear/lisp/LispObject.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/LispObject.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/LispObject.java Mon Dec 28 18:11:35 2009 > @@ -38,6 +38,16 @@ > > public class LispObject //extends Lisp > { > + > + /** Function to allow objects to return the value > + * "they stand for". Used by AutoloadedFunctionProxy to return > + * the function it is proxying. > + */ > + public LispObject resolve() > + { > + return this; > + } > + > public LispObject typeOf() > { > return T; > > Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp Mon Dec 28 18:11:35 2009 > @@ -2048,6 +2048,10 @@ > "getSymbolSetfFunctionOrDie" > "getSymbolFunctionOrDie") > nil +lisp-object+) > + ;; make sure we're not cacheing a proxied function > + ;; (AutoloadedFunctionProxy) by allowing it to resolve itself > + (emit-invokevirtual +lisp-object-class+ > + "resolve" nil +lisp-object+) > (emit 'putstatic *this-class* f +lisp-object+) > (if *declare-inline* > (setf saved-code *code*) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

2 1

[armedbear-devel] fast-boot-preloading branch merged to trunk
by Erik Huelsmann 28 Dec '09

28 Dec '09

After finding on the fast-boot-preloading branch that the experiment worked out: delaying access to the reflection API in order to save performance worked! Comparing the branch performance of loading ABCL on Google App Engine to the trunk, the trunk took rougly 19 seconds to load (theoretical performance) while the branch only took 11 seconds. Seeing this benefit, I decided to merge the code back to trunk once the branch was stable enough. Today was that moment: I found the last reason the branch was failing the ANSI tests (I needed to increase the runtime stack). Given this status, the merge of the branch to the trunk just got committed. The work isn't fully done though: 1. The same approach can be implemented for macro-functions 2. Functions loaded through EVAL-WHEN during file compilation can be addressed the same way Anybody with time to help out on either is heartily invited to join the effort and see how much compile time and boot time can be saved. With kind regards, Erik.

2 1

[armedbear-devel] Review of exception handling ["catch (Throwable"]
by Erik Huelsmann 28 Dec '09

28 Dec '09

Last weeks I did a full review of our code base of uses of "catch (Throwable" as a means of catching anything and "just continuing from there". It seems our code was relatively unpredictable, because in some sites it would throw a debugging exeption, whereas in others processing would continue. With the change where ControlTransfer is now an unchecked exception, it turns out most of the try/catch blocks were unnecessary anyway; most of them have been removed or made more specific (IOException, mostly). The remaining ones seem to have a function, however, everybody is invited to see if I didn't forget or misjudge some locations. With the removal, there's a new instability, it seems: when using the IGNORE-ERRORS macro, one expects the code inside it to catch all errors and continue processing after it, no matter what the error. However, since we no longer catch Throwable and therefore no longer catch any of the RuntimeExceptions, it turns out IGNORE-ERRORS leaks all runtime exceptions. Arguably it shouldn't leak StackOverflowException and many others: these might be *the* conditions to continue after IGNORE-ERRORS. So, I think we need to implement some construct to catch all java exceptions raised inside it and convert them to Lisp errors. This can then be included in IGNORE-ERRORS. Comments? Bye, Erik.

2 2

[armedbear-devel] Getting abcl source and examples with svn http://...
by Durward McDonell 23 Dec '09

23 Dec '09

Hi. Our firewall won't let svn (port 3690) through. Is there a way to download the abcl source through http? More precisely, I want to get the examples in one go, instead of getting them from the trac browser one at a time. (I'm not interested in developing abcl, at least not at the moment, and I have the 0.17 tarball.) Is this possible? Thanks. -- Durward McDonell durward.mcdonell(a)jhuapl.edu

2 3

Re: [armedbear-devel] Qi Lisp II
by Raoul Duke 23 Dec '09

23 Dec '09

how goes Qi on ABCL? cf. http://n2.nabble.com/Qi-on-ABCL-td3001784.html apologies if there's an answer out there that i just haven't hit via googling yet. thanks :)

2 1

[armedbear-devel] [PATCH] jcall(there are multiple matching methods)
by Yoshinori Tahara 23 Dec '09

23 Dec '09

Hello. Attached is a patch which fixes jcall in case there are multiple matching methods. Regards, -- Yoshinori Tahara

6 17

[armedbear-devel] Exception Handling
by Peter Olsen 18 Dec '09

18 Dec '09

Ladies and Gentlemen, I'm writing to ask how to handle exceptions generated in Java code called from ABCL. I'm part of a group trying to combine an existing Common Lisp back-end with an existing Java front end. We've pretty much decided that ABCL is the best way to do that, using Alan Ruttenberg's Java Syntax Solution to make Java calls back to the front-end from Lisp. One problem we're facing is how to handle gracefully exceptions generated in Lisp code called from Java. In our case, we'll need to make calls back to the Java front-end to get user information and to display results. Some of these calls throw exceptions. What is the best way to catch these? I'd also like any thoughts on the comparative advantages of using the JSS as opposed to the native ABCL calls. Thanks! Peter Olsen -- Peter Olsen, P.E., Ae.E. olsen(a)sigmaxi.net Engineering is the art of using a professional knowledge of mathematics and the physical sciences to get things done.

5 5

[armedbear-devel] abcl 0.17 & slime 1:20080223-2
by Durward McDonell 11 Dec '09

11 Dec '09

Hello. I have been trying to get abcl to run under slime, and I have hit the limits of my understanding of all the relevant components. This is on Ubuntu Jaunty (9.04), with abcl 0.17.0 and slime 1:20080223-2. The symptom is that slime starts to load, then quits with the error "Package "CLC" not found." I tracked this down to swank-loader: binary-pathname calls clc:calculate-fasl-root. I've tried everything I could think of, like loading clc from my .abclrc, but I could not trick it into loading. This must be a solved problem, but I have not been able to find anything on the web. On a tangentially related note, in doing all this I discovered that asdf integrates with sbcl specially, in a way that makes it a little bit easier to load packages. Is there a way to get abcl to look in more than one directory for (load "foo.lisp")? Thanks. -- Durward McDonell durward.mcdonell(a)jhuapl.edu

2 2

[armedbear-devel] Faster startup on GAE
by Erik Huelsmann 08 Dec '09

08 Dec '09

One of the conclusions of many of the profiles that we've been doing on our code base was that our boot up loads compiled functions through reflection. However, reflection is a very costly business, so it's best avoided. This is specially notable with Google App Engine which allows limited time per request, but uses that time limit on all requests including the first - which needs to initialize the entire JVM (!). To reduce the time spent on booting ABCL, I changed our class loading routine (on a branch) to *only* resolve byte code into classes which are actually required for execution of the lisp code which is currently executed. All other functions stay in memory without being resolved into classes, preventing invocations of reflection. With this method - which is in branches/fast-boot-preloading - we've reduced GAE startup times from 19000 cpu_ms to roughly 11000 cpu_ms. I intend to clean up the code - adding documentation and code comments - and moving this to the trunk. To anybody who wants a stable release: this is at the heart of the implementation; please help us test it with your application(s)! With kind regards, Erik.

1 0

[armedbear-devel] AASTORE Removal - Bounds checking
by logicmoo＠gmail.com 03 Dec '09

03 Dec '09

With the execute(...) functions in Primitive.java @Override public LispObject execute(LispObject first, LispObject second, LispObject third) { LispObject[] args = new LispObject[3]; args[0] = first; args[1] = second; args[2] = third; return execute(args); } Should probably be transformed to @Override public LispObject execute(LispObject first, LispObject second, LispObject third) { return execute(new LispObject[]{first,second,third}); } To remove the redundant bounds checking of AASTORE

2 2

[armedbear-devel] Virtual call removal patch
by Ville Voutilainen 29 Nov '09

29 Nov '09

Here's a patch that removes some virtuals from LispObject. My measurements show a small positive performance impact. I see no reason not to apply this patch, so please holler if you have any complaints. Erik, does this require a fasl version update? I imagine yes, but I'm not 100% sure, and haven't have time to check.

1 0

[armedbear-devel] Bug in translate-logical-pathname.
by Thomas Russ 26 Nov '09

26 Nov '09

There seems to be a bug in TRANSLATE-LOGICAL-PATHNAME when the logical pathname source includes constant elements in addition to wildcards. Here is an example that demonstrates the problem: CL-USER(1): (setf (logical-pathname-translations "L") '(("L:NATIVE;**;*.*" "/usr/lisp/abcl/native/**/*.*"))) ((#P"L:NATIVE;**;*.*" #P"/usr/lisp/abcl/native/**/*.*")) CL-USER(2): (translate-logical-pathname "L:NATIVE;TEST;FOO.FASL") #P"/usr/lisp/abcl/native/native/test/foo.fasl" ;; ERROR. Should be #P"/usr/lisp/abcl/native/test/foo.fasl" ;; ;; With :wild-inferiors, the full directory path is copied instead of ;; just the part after the matching constant part. That results in ;; the "native" element appearing twice. ;; The problem seems to be in the file "abcl/src/org/armedbear/lisp/ pathnames.lisp", in the function SYSTEM::TRANSLATE-DIRECTORY-COMPONENTS: (defun translate-directory-components (source from to case) (cond ((null to) nil ) ((memq (car to) '(:absolute :relative)) (cons (car to) (translate-directory-components (cdr source) (cdr from) (cdr to) case)) ) ((eq (car to) :wild) (if (eq (car from) :wild) ;; Grab the next chunk from SOURCE. (append (casify (car source) case) (translate-directory-components (cdr source) (cdr from) (cdr to) case)) (error "Unsupported case 1: ~S ~S ~S" source from to)) ) ((eq (car to) :wild-inferiors) ;; Grab the next chunk from SOURCE. (append (casify (car source) case) (translate-directory-components (cdr source) (cdr from) (cdr to) case)) ) (t ;; "If the piece in TO-WILDCARD is present and not wild, it is copied ;; into the result." (append (casify (car to) case) (translate-directory-components source from (cdr to) case)) ) )) The final COND clause ("T") needs to be more sophisticated in what it does. If there are non-wildcard elements in the FROM, then it will need to eliminate the the common prefix between "source" and "from". In order to be a valid match, it I think it SHOULD be guaranteed that a non-wildcard "from" component is a leading subsequence or equal to "source" -- but I'm not fully familiar with the code, but a quick test seems to indicate that the following modified function covers at least the simpler cases of this issue. It adds a new clause checking for :WILD-INFERIORS in the FROM slot which performs the current function, and changes the T clause to properly manage the subsequence matching. (defun translate-directory-components (source from to case) (cond ((null to) nil ) ((memq (car to) '(:absolute :relative)) (cons (car to) (translate-directory-components (cdr source) (cdr from) (cdr to) case)) ) ((eq (car to) :wild) (if (eq (car from) :wild) ;; Grab the next chunk from SOURCE. (append (casify (car source) case) (translate-directory-components (cdr source) (cdr from) (cdr to) case)) (error "Unsupported case 1: ~S ~S ~S" source from to)) ) ((eq (car to) :wild-inferiors) ;; Grab the next chunk from SOURCE. (append (casify (car source) case) (translate-directory-components (cdr source) (cdr from) (cdr to) case)) ) ((eq (car from) :wild-inferiors) ;; "If the piece in TO-WILDCARD is present and not wild, and the FROM item ;; doesn't contain any constants, then just copy TO to the result." (append (casify (car to) case) (translate-directory-components source from (cdr to) case))) (t ;; "If the piece in TO-WILDCARD is present and not wild, then FROM should ;; be a subsequence of SOURCE. The common subsequence needs to be removed ;; in the recursive call. Special case handling for a full match is ;; also needed." (let ((pos (mismatch (car source) (car from) :test #'string- equal))) (append (casify (car to) case) (if (null pos) ;; A full match, pop both source and from (translate-directory-components (cdr source) (cdr from) (cdr to) case) (translate-directory-components (cons (subseq (car source) pos) (cdr source)) (cdr from) (cdr to) case)))) ) ))

5 5

Re: [armedbear-devel] DEFUN (SETF ...)s
by dmiles＠users.sourceforge.net 23 Nov '09

23 Nov '09

Ah, look at this: (offline Erik suggested something) Armed Bear Common Lisp 0.18.0-dev (built Mon Nov 23 2009 12:07:35 PST) Java 1.6.0_10 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.766 seconds. Startup completed in 1.642 seconds. Type ":help" for a list of available commands. CL-USER(1): (require "JAVA") ("CLOS" "JAVA-EXTENSIONS") CL-USER(2): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") "stuff" CL-USER(3): If my app calls (require "JAVA") first that's not a bad thing When I use Allegro Lisp I gotta call a few forms before #'jfield works :) (require :jlinker) (use-package "javatools.jlinker") (jlinker-init) It is kinda a hard call to know when we have to require the user to (require ..something..) ? so much in ABCL happens by magic.. I get spoiled > > ----- Original Message ----- > From: "Alessio Stalla" <alessiostalla(a)gmail.com> > To: <dmiles(a)users.sourceforge.net> > Cc: "Armed Bear" <armedbear-devel(a)common-lisp.net> > Sent: Monday, November 23, 2009 12:38 PM > Subject: Re: [armedbear-devel] DEFUN (SETF ...)s > > > It might be related to autoloading: java.lisp is not autoloaded by > (setf jfield), but it is by the debugger, so after the error it works. > If that is the problem, I don't have the solution... other than > calling some function defined in java.lisp before (setf jfield), but > that's not pretty. > > hth, > Alessio > > On Mon, Nov 23, 2009 at 9:30 PM, <logicmoo(a)gmail.com> wrote: >> It looks to be a loadtime thing (offline Erik thought maybe it was so) >> See this output: >> >> Armed Bear Common Lisp 0.18.0-dev (built Mon Nov 23 2009 12:07:35 PST) >> Java 1.6.0_10 Sun Microsystems Inc. >> Java HotSpot(TM) 64-Bit Server VM >> Low-level initialization completed in 0.658 seconds. >> Startup completed in 1.516 seconds. >> Type ":help" for a list of available commands. >> CL-USER(1): (jfield "dmiles.TestClass" "StaticField") >> "fresh" >> CL-USER(2): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") >> Debugger invoked on condition of type UNDEFINED-FUNCTION: >> The function (SETF JFIELD) is undefined. >> Restarts: >> 0: TOP-LEVEL Return to top level. >> [1] CL-USER(3): 0 >> CL-USER(4): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") >> Debugger invoked on condition of type UNDEFINED-FUNCTION: >> The function (SETF JFIELD) is undefined. >> Restarts: >> 0: TOP-LEVEL Return to top level. >> [1] CL-USER(5): :bt >> 0: (SYSTEM:BACKTRACE) >> 1: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION {27F40B69}>) >> 2: org.armedbear.lisp.Lisp.error(Lisp.java:365) >> 3: org.armedbear.lisp.SpecialOperators$14.execute(SpecialOperators.java:493) >> 4: org.armedbear.lisp.Lisp.eval(Lisp.java:461) >> 5: org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) >> 6: org.armedbear.lisp.Lisp.eval(Lisp.java:471) >> 7: org.armedbear.lisp.Lisp.progn(Lisp.java:640) >> [1] CL-USER(6): 0 >> CL-USER(7): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") >> "stuff" >> CL-USER(8): >> >> _______________________________________________ >> armedbear-devel mailing list >> armedbear-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >>

1 0

Re: [armedbear-devel] DEFUN (SETF ...)s
by logicmoo＠gmail.com 23 Nov '09

23 Nov '09

It looks to be a loadtime thing (offline Erik thought maybe it was so) See this output: Armed Bear Common Lisp 0.18.0-dev (built Mon Nov 23 2009 12:07:35 PST) Java 1.6.0_10 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.658 seconds. Startup completed in 1.516 seconds. Type ":help" for a list of available commands. CL-USER(1): (jfield "dmiles.TestClass" "StaticField") "fresh" CL-USER(2): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") Debugger invoked on condition of type UNDEFINED-FUNCTION: The function (SETF JFIELD) is undefined. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): 0 CL-USER(4): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") Debugger invoked on condition of type UNDEFINED-FUNCTION: The function (SETF JFIELD) is undefined. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(5): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION {27F40B69}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:365) 3: org.armedbear.lisp.SpecialOperators$14.execute(SpecialOperators.java:493) 4: org.armedbear.lisp.Lisp.eval(Lisp.java:461) 5: org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) 6: org.armedbear.lisp.Lisp.eval(Lisp.java:471) 7: org.armedbear.lisp.Lisp.progn(Lisp.java:640) [1] CL-USER(6): 0 CL-USER(7): (setf (jfield "dmiles.TestClass" "StaticField") "stuff") "stuff" CL-USER(8):

2 1

[armedbear-devel] DEFUN (SETF ...)s
by logicmoo＠gmail.com 23 Nov '09

23 Nov '09

Help me out! I made a class called: TestClass ------------------------src/dmiles/TestClass.java--------------------- package dmiles public class TestClass { static public String StaticField = "fresh"; } ------------------------------------------------------------------------- Now in the REPL everything works fine. Armed Bear Common Lisp 0.18.0-dev (built Mon Nov 23 2009 06:46:01 PST) Java 1.6.0_10 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.658 seconds. Startup completed in 1.877 seconds. Type ":help" for a list of available commands. CL-USER(1): (defun (setf jfield) (newvalue class-ref-or-field field-or-instance &optional ( instance :noinst) unused-value) (declare (ignorable unused-value)) (if (eq instance :noinst) (jfield class-ref-or-field field-or-instance newvalue) (jfield class-ref-or-field field-or-instance instance newvalue))) (SETF JFIELD) CL-USER(2): (jfield "dmiles.TestClass" "StaticField") "fresh" CL-USER(3): (define-symbol-macro %TESTSYM (jfield "dmiles.TestClass" "StaticField")) %TESTSYM CL-USER(4): CL-USER(4): %TESTSYM "fresh" CL-USER(5): (setf %TESTSYM "flithy") "flithy" CL-USER(6): %TESTSYM "flithy" CL-USER(7): (jfield "dmiles.TestClass" "StaticField") "flithy" CL-USER(8): --------------------------------------------------------------------------------- Question: locally I added this to the bottem of java.lisp (defun (setf jfield) (newvalue class-ref-or-field field-or-instance &optional ( instance :noinst) unused-value) (declare (ignorable unused-value)) (if (eq instance :noinst) (jfield class-ref-or-field field-or-instance newvalue) (jfield class-ref-or-field field-or-instance instance newvalue))) Cleaned and rebuilt the system.. To test it: Armed Bear Common Lisp 0.18.0-dev (built Mon Nov 23 2009 12:07:35 PST) Java 1.6.0_10 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.564 seconds. Startup completed in 1.651 seconds. Type ":help" for a list of available commands. CL-USER(1): (jfield "dmiles.TestClass" "StaticField") "fresh" CL-USER(2): (define-symbol-macro %TESTSYM (jfield "dmiles.TestClass" "StaticField")) %TESTSYM CL-USER(3): %TESTSYM "fresh" CL-USER(4): (setf %TESTSYM "flithy") Debugger invoked on condition of type UNDEFINED-FUNCTION: The function (SETF JFIELD) is undefined. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(5): :bt 0: (SYSTEM:BACKTRACE) 1: (INVOKE-DEBUGGER #<UNDEFINED-FUNCTION {50E26AE7}>) 2: org.armedbear.lisp.Lisp.error(Lisp.java:365) 3: org.armedbear.lisp.SpecialOperators$14.execute(SpecialOperators.java:493) 4: org.armedbear.lisp.Lisp.eval(Lisp.java:461) 5: org.armedbear.lisp.Lisp.evalCall(Lisp.java:501) 6: org.armedbear.lisp.Lisp.eval(Lisp.java:471) 7: org.armedbear.lisp.Lisp.progn(Lisp.java:640) [1] CL-USER(6): Hw do a add a new (defun (setf ..) .. .) to the library?

1 0

Re: [armedbear-devel] SETF for JFEILDS
by dmiles＠users.sourceforge.net 23 Nov '09

23 Nov '09

> ----- Original Message ----- > From: "Alessio Stalla" <alessiostalla(a)gmail.com> > To: <dmiles(a)users.sourceforge.net> > Cc: "Armed Bear" <armedbear-devel(a)common-lisp.net> > Sent: Monday, November 23, 2009 9:18 AM > Subject: Re: [armedbear-devel] SETF for JFEILDS > > > On Mon, Nov 23, 2009 at 5:57 PM, <logicmoo(a)gmail.com> wrote: >> Ok even Allegro uses T and NIL for the Booleans.. which is why >> >>> CL-USER(17): (jclass-of (jfield "java.lang.Boolean" "TRUE")) >>> NIL >>> NIL >> >> was still correct.. I think the closer we stick with Allegro the better. >> >> >> >> for future reference (to myself) to make a boolean one does: >> >> >> CL-USER(21): (jnew (jconstructor "java.lang.Boolean" "java.lang.String") "True") >> #<java.lang.Boolean true {44AC5E}> >> CL-USER(22): (jclass-of (jnew (jconstructor "java.lang.Boolean" "java.lang.String") "True")) >> "java.lang.Boolean" >> "java.lang.Boolean" > > If you want a boolean (primitive type) I believe you can do > (make-immediate-object T-or-NIL :boolean) (make-immediate-object t :boolean) #<java.lang.Boolean true {1C904F75}> Neat, I hadn't known (or forgot) about Arg2 of #'make-immediate-object ! Thx > If you want Boolean.TRUE or Boolean.FALSE the cleaner way would be to > have a jfield-raw like jcall-raw, if I understand it correctly. CL-USER(24): (jfield-raw "java.lang.Boolean" "TRUE") #<java.lang.Boolean true {465098F9}> Indeed. >> >> >> If there is any action items out of all this: >> >> Perhaps: javaInstance() on Nil returns Boolean.FALSE? > > This would break a lot of existing code, I'm afraid. NIL is often used > to mean null. *nod* well either meaning is just as dubious.. but as you say allot of existing code likes NIL to mean EMPTY which sounds more like a 'null' than a 'false'. > >> Then in Symbol.java >> >> Object javaInstance() { >> if (this == T) return Boolean.TRUE; >> return super.javaInstance(); >> } >> > > I don't agree for consistency with NIL and for similar concerns on > existing code. However, hold on... > >> >> And in LispObject itself any thoughts on? >> >> LispObject.this.javaInstance(Class c) { >> if (c.isInstance(this)) return this; >> // widen and resubmit for subclasses >> if (c==int.class) return javaInstance(Integer.class); >> if (c==boolean.class) return javaInstance(Boolean.class); >> // they requested a boolean.. give it to them >> if (c==Boolean.class) return getBooleanValue(); >> ..... >> //hit the error logic >> } > > Now for javaInstance(Class) I completely agree with you: it should > mean - everywhere! - "convert this object to a Java object of the > given class, if possible". > > So LispObject.javaInstance(Class c) should be like you said, and in > some subclasses (Fixnum, AbstractString come to my mind) it should be > overridden. Good > At that point we could even generify it: > > public <T> T javaInstance(Class<T> c) > > So users might write, e.g., String s = myLispObject.javaInstance(String.class); > I like the generics for it as well > Just my €.02 > > Alessio > >> >> >> ----- Original Message ----- >> From: <dmiles(a)users.sourceforge.net> >> To: "Armed Bear" <armedbear-devel(a)common-lisp.net> >> Sent: Monday, November 23, 2009 7:42 AM >> Subject: Re: [armedbear-devel] SETF for JFEILDS >> >> >>> >>> These 3 look good >>> >>> >>> CL-USER(2): (jclass-of (jfield "java.lang.System" "out")) >>> "java.io.PrintStream" >>> "java.io.PrintStream" >>> >>> CL-USER(4): (jclass-of 1) >>> NIL >>> NIL >>> >>> CL-USER(5): (jclass-of (make-immediate-object 1)) >>> "java.lang.Integer" >>> "java.lang.Integer" >>> >>> >>> >>> But is this correct? >>> >>> >>> CL-USER(17): (jclass-of (jfield "java.lang.Boolean" "TRUE")) >>> NIL >>> NIL >>> CL-USER(18): (jclass-of (jfield "java.lang.Boolean" "FALSE")) >>> NIL >>> NIL >>> >>> >>> >>> >> >> _______________________________________________ >> armedbear-devel mailing list >> armedbear-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel >> > > _______________________________________________ > armedbear-devel mailing list > armedbear-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

1 0

Re: [armedbear-devel] SETF for JFEILDS
by logicmoo＠gmail.com 23 Nov '09

23 Nov '09

Ok even Allegro uses T and NIL for the Booleans.. which is why > CL-USER(17): (jclass-of (jfield "java.lang.Boolean" "TRUE")) > NIL > NIL was still correct.. I think the closer we stick with Allegro the better. for future reference (to myself) to make a boolean one does: CL-USER(21): (jnew (jconstructor "java.lang.Boolean" "java.lang.String") "True") #<java.lang.Boolean true {44AC5E}> CL-USER(22): (jclass-of (jnew (jconstructor "java.lang.Boolean" "java.lang.String") "True")) "java.lang.Boolean" "java.lang.Boolean" If there is any action items out of all this: Perhaps: javaInstance() on Nil returns Boolean.FALSE? Then in Symbol.java Object javaInstance() { if (this == T) return Boolean.TRUE; return super.javaInstance(); } And in LispObject itself any thoughts on? LispObject.this.javaInstance(Class c) { if (c.isInstance(this)) return this; // widen and resubmit for subclasses if (c==int.class) return javaInstance(Integer.class); if (c==boolean.class) return javaInstance(Boolean.class); // they requested a boolean.. give it to them if (c==Boolean.class) return getBooleanValue(); ..... //hit the error logic } ----- Original Message ----- From: <dmiles(a)users.sourceforge.net> To: "Armed Bear" <armedbear-devel(a)common-lisp.net> Sent: Monday, November 23, 2009 7:42 AM Subject: Re: [armedbear-devel] SETF for JFEILDS > > These 3 look good > > > CL-USER(2): (jclass-of (jfield "java.lang.System" "out")) > "java.io.PrintStream" > "java.io.PrintStream" > > CL-USER(4): (jclass-of 1) > NIL > NIL > > CL-USER(5): (jclass-of (make-immediate-object 1)) > "java.lang.Integer" > "java.lang.Integer" > > > > But is this correct? > > > CL-USER(17): (jclass-of (jfield "java.lang.Boolean" "TRUE")) > NIL > NIL > CL-USER(18): (jclass-of (jfield "java.lang.Boolean" "FALSE")) > NIL > NIL > > > >

2 1

Re: [armedbear-devel] SETF for JFEILDS
by logicmoo＠gmail.com 23 Nov '09

23 Nov '09

Does anyone object to adding this to java.lisp? If not could it be done? (defun (setf jfield) (newvalue class-ref-or-field field-or-instance &optional ( instance :noinst) (value :novalue)) (if (eq instance :noinst) (jfield class-ref-or-field field-or-instance newvalue) (jfield class-ref-or-field field-or-instance instance newvalue))) ----- Original Message ----- From: <dmiles(a)users.sourceforge.net> To: "Armed Bear" <armedbear-devel(a)common-lisp.net> Sent: Tuesday, November 10, 2009 12:24 AM Subject: SETF for JFEILDS > Hi, > > Could we add add something like this to java.lisp? > > (defun (setf jfield) > (newvalue class-ref-or-field field-or-instance &optional ( instance :noinst) (value :novalue)) > (if (eq instance :noinst) > (jfield class-ref-or-field field-or-instance newvalue) > (jfield class-ref-or-field field-or-instance instance newvalue))) > > -Thx

2 3

Re: [armedbear-devel] SETF for JFEILDS
by logicmoo＠gmail.com 23 Nov '09

23 Nov '09

So actually (defun (setf jfield) (newvalue class-ref-or-field field-or-instance &optional ( instance :noinst) unusedvalue) (if (eq instance :noinst) (jfield class-ref-or-field field-or-instance newvalue) (jfield class-ref-or-field field-or-instance instance newvalue))) Would be a little better.. good eye. ----- Original Message ----- From: <dmiles(a)users.sourceforge.net> To: "Alessio Stalla" <alessiostalla(a)gmail.com> Cc: "Armed Bear" <armedbear-devel(a)common-lisp.net> Sent: Monday, November 23, 2009 6:27 AM Subject: Re: [armedbear-devel] SETF for JFEILDS > > ----- Original Message ----- > From: "Alessio Stalla" <alessiostalla(a)gmail.com> > To: <dmiles(a)users.sourceforge.net> > Cc: "Armed Bear" <armedbear-devel(a)common-lisp.net> > Sent: Monday, November 23, 2009 5:42 AM > Subject: Re: [armedbear-devel] SETF for JFEILDS > > > On Mon, Nov 23, 2009 at 2:36 PM, <logicmoo(a)gmail.com> wrote: >>> Does anyone object to adding this to java.lisp? If not could it be done? >>> >>> (defun (setf jfield) >>> (newvalue class-ref-or-field field-or-instance &optional ( instance :noinst) (value :novalue)) >>> (if (eq instance :noinst) >>> (jfield class-ref-or-field field-or-instance newvalue) >>> (jfield class-ref-or-field field-or-instance instance newvalue))) > >>It seems a nice idea to me, but there are a couple of things that I >>don't understand: > > A>- why :noinst and not simply nil? > > JFIELD is defined as: class-ref-or-field field-or-instance &optional instance value > The valid argument patterns for this operation are: > (class-ref field-name): to retrieve the value of a static field. > (class-ref field-name instance-ref): to retrieve the value of a class field of the instance. > (class-ref field-name primitive-value:) to store primitive-value in a static field. > (class-ref field-name instance-ref value): to store value in a class field of the instance. > (class-ref field-name nil value): to store value in a static field (when value may be confused with an instance-ref). > (field-name instance): to retrieve the value of a field of the instance. The class is derived from the instance. > (field-name instance value): to store value in a field of the instance. The class is derived from the instance. > > JFIELD doesn't distingusih between static and non static fields > > Also cases of "class-ref field-name instance-ref value" (accessing superclass field) > > Depending on how the field is defined > > (setf (jfield *MyClass* "someStaticBooleanField") NIL) > it is distinguable from > (setf (jfield *MySuperClass* "nonStaticBooleanField" *my-instance* ) NIL) > > > -------------------------------------------------------------------------------------------------------------------------- > A>- value is not used, what's the point of it? > > correct the "default :novalue" is not needed. > (I was debugging and trying to find corner cases with all those bizzare legal jfield signatures ) > > > but... "value" as an &optional was needed to match the signature of what is legal for jfield so things like this can work: > > (define-symbol-macro %iscold (jfield "org.armedbear.lisp.Lisp" "cold")) > %iscold ;; ==> NIL > (setq %iscold T) ;; ==> T > %iscold ;; ==> T > (setq %iscold NIL) ;; ==> NIL > >

1 0

[armedbear-devel] PATCH to StopExtendingLisp for 12281
by logicmoo＠gmail.com 23 Nov '09

23 Nov '09

PATCH to StopExtendingLisp for trunk 12281 This patch uncompressed to 105k and it effects many files It has a some goals: When foreign libs instancing a subclass of LispObject to not get Lisp.<clinit> called until its time. Removes an invoke-special from bytecode of LispObject Marks Lisp class as final - (A new file LispTrampolinesFile.java is put in as a historical placeholder for static trampoline classes that once extended Lisp) Does not pass or fail any extra ANSI-TESTS

1 0

Re: [armedbear-devel] [j-devel] Compilation Problem in ABCL 0.17
by Mark Evenson 15 Nov '09

15 Nov '09

On 11/15/09 10:03 PM, Dr. Thomas Sturm wrote: > I am using a 64-bit Mac with Snow Leopard (Mac OSX 10.6.2). I didi not do anything special but simply went (compile-file "test") in a fresh session. > > Here is my banner of ABCL: > > sturm@lennier[~] abcl > Armed Bear Common Lisp 0.17.0 > Java 1.6.0_15 Apple Inc. > Java HotSpot(TM) 64-Bit Server VM > Low-level initialization completed in 0.348 seconds. > Startup completed in 0.936 seconds. > Type ":help" for a list of available commands. > CL-USER(1): > > The ABCL is not from the svn but the 0.17.0 distribution as of last Saturday. […] I can reproduce your problem as well with ABCL trunk under the same OS/JVM. No idea yet on fixing it, but I will file a bug report for you. Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

Re: [armedbear-devel] Inline primitives as static method calls
by logicmoo＠gmail.com 11 Nov '09

11 Nov '09

> > ----- Original Message ----- > From: "Alessio Stalla" <alessiostalla(a)gmail.com> > To: <dmiles(a)users.sourceforge.net> > Cc: "Armed Bear" <armedbear-devel(a)common-lisp.net> > Sent: Tuesday, November 10, 2009 1:12 AM > Subject: Re: [armedbear-devel] Inline primitives as static method calls > > > On Tue, Nov 10, 2009 at 9:01 AM, <logicmoo(a)gmail.com> wrote: >> Alessio, >> Excellent Work! >> >> Your .patch is what I meant. > > Thanks! > >> >>> when compiled it is translated as a direct call to the static >>> method, without passing through the symbol, which is faster than now >> >> Perfect - Yeah >> >> >> >> A Side note: >>> >>> When interpreted or passed as a higher-order function an >>> InlinedPrimitive calls the static method through reflection, resulting >>> in slower performance than now. >> >> I wrote a workaround for this into LarKC because of the performance >> degradation. >> >> So later on.... >> Like after we have everything working/vetted calling static inlines as much >> as possible. >> And using InlinePrimtives to call reflection... >> >> >> >> We'll have some options like: "FixedArityFunctor": >> >> http://larkc.svn.sourceforge.net/viewvc/larkc/trunk/platform/src/com/cyc/to… >> >> What I did was created a new Class via ASM that contains a single >> execute(a,b,c,d,e,f) signature per "args used". >> That simply calls the static method . >> >> So in InlinePrimitive later suplimented with some extras like: >> >> //The methodWith0Args - methodWithNArgs is what that .java url above >> generates. >> LispObject execute() { >> return methodWith0Args.evaluate(); >> } >> LispObject execute(LispObject a0) { >> return methodWith1Args.evaluate(a0); >> } >> LispObject execute(LispObject a0,LispObject a1) { >> return methodWith2Args.evaluate(a0,a1); >> } >> etc >> >> >> Figured I should mention the "FixedArityFunctor" so we dont get scared off >> by any performance >> degration of higher level calls before we learn all the benefits of inlining >> static functions! > > Ok, I'm not sure I followed everything. Oh the above was attempting to describe LarKC SubLisp implementation of this article: http://www.ibm.com/developerworks/java/library/j-dyn0610/ I couldnt find it before sending the email! The intial LarKC implemention used reflection in the same maner as InlinedPrimive does. The after reading that article, I found I could replace Method[] cache inside InlinedPrimive with generated methodStubs produced runtime for reflection performance. > but consider also that the > implementation through reflection is the default one, for convenience, > but you can still override the various execute() methods and call the > static method directly (of course, you have to make sure the method > you call is the same as the one you pass in the constructor, or things > start to behave differently in interpreted vs compiled code and that's > definitely not good :D). Something like > > new InlinedPrimitive(My.class, "myMethod", ...) { > public LispObject execute(LispObject arg) { > return My.myMethod(arg); > } > } Yup, InlinePrimtive still leaves that option open. If someone really wanted to, they can do that with a couple of their InlinedPrimtives if they noticed one particualtar method was getting called quite a bit. Making the instance execute call the static function (Like EQ/EQL/EQUAL for instance avoiding reflection.) > > The class I posted lacks the constructors taking the class and the > method, because I have been lazy ;), but they can easily be added - > with the caveat that, since the call to super() must be the first and > for Function super() sometimes (always?) installs the function in a > symbol (iirc), if you pass a wrong class/method to InlinedPrimitive > and as a result an exception is thrown, you'll have a symbol pointing > to an invalid function. I realy do like how you did it as factory method: public static final Primitive COPY_TREE = InlinedPrimitive.get(Primitives.class, "copyTree", Symbol.COPY_TREE, "object"); And depending on safety/speed you could save the string name of the class and method name for later and not even try to resolve the method[] until first time call.. and signal an error then if not found. This could be used like autoloading. > > Bye, > Ale

2 1

[armedbear-devel] Array Cleanup Example
by logicmoo＠gmail.com 11 Nov '09

11 Nov '09

Here is an example of an array cleanup that might be usefull. * It uses Arrays.fill(...) when it can * throwing badMajorRowIndex from one array (repeated code) This one is a bit questionable: * It started out as int32[] backing becasue we needed one extra signless bit to represent a 'unit16' PROS: Also notice the previous was constantly: store -> unboxing , get -> reboxing So almost anytime we wanted to store .. we took a submitted valid Fixnum.. then forgot about it. Then when we want a value: we have to recreate a fixnum to replace the one we had previously lost. CONS: On a 32bit machine the new represention takes the same ram 64 bit machine takes twice the ram after the refactor. Later on we might decide to allow this array to participate in the JavaObject ontology .. if so, then this is a neat object for storing unsigned shorts.. however would JavaObject ever rerpresent Unsigned numbers? ----------------------------------------------------------------------------------- Index: src/org/armedbear/lisp/SimpleArray_UnsignedByte16.java =================================================================== --- src/org/armedbear/lisp/SimpleArray_UnsignedByte16.java (revision 12275) +++ src/org/armedbear/lisp/SimpleArray_UnsignedByte16.java (working copy) @@ -33,17 +33,19 @@ package org.armedbear.lisp; +import java.util.Arrays; + public final class SimpleArray_UnsignedByte16 extends AbstractArray { private final int[] dimv; private final int totalSize; - private final int[] data; + private final Fixnum[] data; public SimpleArray_UnsignedByte16(int[] dimv) { this.dimv = dimv; totalSize = computeTotalSize(dimv); - data = new int[totalSize]; + data = new Fixnum[totalSize]; } public SimpleArray_UnsignedByte16(int[] dimv, LispObject initialContents) @@ -57,7 +59,7 @@ rest = rest.elt(0); } totalSize = computeTotalSize(dimv); - data = new int[totalSize]; + data = new Fixnum[totalSize]; setInitialContents(0, dimv, initialContents, 0); } @@ -75,7 +77,7 @@ rest = rest.elt(0); } totalSize = computeTotalSize(dimv); - data = new int[totalSize]; + data = new Fixnum[totalSize]; setInitialContents(0, dimv, initialContents, 0); } @@ -85,7 +87,7 @@ { if (dims.length == 0) { try { - data[index] = coerceLispObjectToJavaByte(contents); + data[index] = checkValue(contents); } catch (ArrayIndexOutOfBoundsException e) { error(new LispError("Bad initial contents for array.")); @@ -192,10 +194,10 @@ public int aref(int index) { try { - return data[index]; + return data[index].value; } catch (ArrayIndexOutOfBoundsException e) { - error(new TypeError("Bad row major index " + index + ".")); + badRowMajorIndex(index); // Not reached. return 0; } @@ -205,21 +207,33 @@ public LispObject AREF(int index) { try { - return Fixnum.getInstance(data[index]); + return data[index]; } catch (ArrayIndexOutOfBoundsException e) { - return error(new TypeError("Bad row major index " + index + ".")); + return badRowMajorIndex(index); } } + + private LispObject badRowMajorIndex(int index) { + return error(new TypeError("Bad row major index " + index + ".")); + } + public static Fixnum checkValue(LispObject obj) + { + if (obj instanceof Fixnum) { + return (Fixnum)obj; + } + return (Fixnum)type_error(obj, UNSIGNED_BYTE_16); + } + @Override public void aset(int index, LispObject obj) { try { - data[index] = Fixnum.getValue(obj); + data[index] = checkValue(obj); } catch (ArrayIndexOutOfBoundsException e) { - error(new TypeError("Bad row major index " + index + ".")); + badRowMajorIndex(index); } } @@ -259,11 +273,10 @@ public LispObject get(int[] subscripts) { try { - return Fixnum.getInstance(data[getRowMajorIndex(subscripts)]); + return data[getRowMajorIndex(subscripts)]; } catch (ArrayIndexOutOfBoundsException e) { - return error(new TypeError("Bad row major index " + - getRowMajorIndex(subscripts) + ".")); + return badRowMajorIndex(getRowMajorIndex(subscripts)); } } @@ -272,20 +285,17 @@ { try { - data[getRowMajorIndex(subscripts)] = Fixnum.getValue(obj); + data[getRowMajorIndex(subscripts)] = checkValue(obj); } catch (ArrayIndexOutOfBoundsException e) { - error(new TypeError("Bad row major index " + - getRowMajorIndex(subscripts) + ".")); + badRowMajorIndex(getRowMajorIndex(subscripts)); } } @Override public void fill(LispObject obj) { - int n = Fixnum.getValue(obj); - for (int i = totalSize; i-- > 0;) - data[i] = n; + Arrays.fill(data, 0, totalSize, checkValue(obj)); } @Override

2 2

[armedbear-devel] Performance improvement special binding read/write
by Erik Huelsmann 10 Nov '09

10 Nov '09

Last weekend, I ran Maxima tests since some time again. I don't remember the older performance figures, although I remember the total test suite - possibly performance tuned - to take 3300seconds before. Last weekend, it was 3900seconds, giving me a feeling of performance regression. So I decided to take another look. I found two things, one of which is that we still have slow special binding value lookup. Peter Graves suggested some time ago that we switch to the same scheme used by SBCL and CCL because he found that XCL benefitted ~10% on his tests when he made the same switch. The scheme used by SBCL/CCL differs from the one used by ABCL in the way the "active" binding is being accessed. ABCL manages all bindings as a linked list, with the most recent one as the active one. This means O(n) access time on the number of special bindings. In SBCL/CCL, the active binding is stored in an array, with a linked list to record which values to restore when unwinding the binding. Upon restore, this solution takes more cycles than our solution: we simply change the head of the linked list, whereas the SBCL/CCL solution needs to set all the array elements. Running the application which we know tests special bindings performance the best [Maxima], I see a strong performance improvement: 3900 seconds before and 2300 seconds after the change. Performance improved by ~40%! I'll commit this change after cleaning up. Bye, Erik.

1 1

[armedbear-devel] Class file extenstions
by logicmoo＠gmail.com 10 Nov '09

10 Nov '09

I dont think this patch has any ill-effects - But I only tested on Win64/Linux64 Sun Java 6s Its for http://trac.common-lisp.net/armedbear/attachment/ticket/34 (Ignore the previous patch posted there) The goal of it.. for is for the start leveraging Ahead Of Time compilers like GCJ/EcellisorJET According to Peter the original use of ".cls" was more for figuring out which files to delete.. not because the classfile format was non-compliant. ---------------------------------------------------------------------------------------------------------------- Index: src/org/armedbear/lisp/compile-file.lisp =================================================================== --- src/org/armedbear/lisp/compile-file.lisp (revision 12273) +++ src/org/armedbear/lisp/compile-file.lisp (working copy) @@ -45,8 +45,8 @@ *output-file-pathname*)) "Computes the name of the class file associated with number `n'." (let ((name - (%format nil "~A-~D" - (substitute #\_ #\. + (%format nil "~A_~D" + (substitute #\$ #\. (pathname-name output-file-pathname)) n))) (namestring (merge-pathnames (make-pathname :name name :type "cls") output-file-pathname))))

1 0

[armedbear-devel] Inline primitives as static method calls
by Alessio Stalla 10 Nov '09

10 Nov '09

Attached is a patch + a Java class that tentatively implement logicmoo's idea of "inlining" primitives as calls to static methods (just for test on a single primitive, COPY-TREE). The Java class, InlinedPrimitive, extends Primitive and implements its execute() methods with static methods with a given name found in a given class. When interpreted or passed as a higher-order function an InlinedPrimitive calls the static method through reflection, resulting in slower performance than now. But, when compiled it is translated as a direct call to the static method, without passing through the symbol, which is faster than now (I haven't measured how much faster). Consider this patch as a rough draft - it must be polished if we ever decide to include it. In particular "inlining" is always performed, while we should probably avoid it with some debug/speed settings. Bye, Alessio

2 2

[armedbear-devel] SETF for JFEILDS
by logicmoo＠gmail.com 10 Nov '09

10 Nov '09

Hi, Could we add add something like this to java.lisp? (defun (setf jfield) (newvalue class-ref-or-field field-or-instance &optional ( instance :noinst) (value :novalue)) (if (eq instance :noinst) (jfield class-ref-or-field field-or-instance newvalue) (jfield class-ref-or-field field-or-instance instance newvalue))) -Thx

1 0

Re: [armedbear-devel] Changes to ConditionThrowable
by logicmoo＠gmail.com 07 Nov '09

07 Nov '09

Yep I had *improperly* tried to divide the three type of ControlTransfers They are indeed undistinguishable by class. In fact my now I remember: 3rd party code didn't catch the ControlTransfers but instead override ERROR/%DEBUGGER-HOOK-FUNCTION Symbol sym = Lisp.PACKAGE_CL_USER.findAccessibleSymbol("ERROR"); sym.setSymbolFunction(new CSThrowError(sym.getSymbolFunction())); sym = Lisp.PACKAGE_SYS.findAccessibleSymbol("%DEBUGGER-HOOK-FUNCTION"); sym.setSymbolFunction(new CSThrowError(sym.getSymbolFunction())); Then had to decide to handle it with inspecting the arguments with lines: 32-54 of http://code.google.com/p/opensim4opencog/source/browse/trunk/Cogbot/ScriptE… Thanks for he clarity. ----- Original Message ----- From: "Erik Huelsmann" <ehuels(a)gmail.com> To: <dmiles(a)users.sourceforge.net> Sent: Friday, November 06, 2009 11:39 PM Subject: Re: [armedbear-devel] Changes to ConditionThrowable Hi Douglas, On Sat, Nov 7, 2009 at 1:33 AM, <logicmoo(a)gmail.com> wrote: > My two cents: > > Those who call Lisp.eval(...) or mySymbol.execute() should at least be > capable of catching RuntimeCondition But should not be forced to also catch > Go and Throw > > The way it is now.. > I have a Primitive that I implement outside of ABCL. > It catches certain condition throwables but should not have to catch > Throw/Go > > which means: > ABCL calls my primitive. > My code is calling back into ABCL > I must catch ConditionThrowable. > I must also check to see if ConditionThrowable instanceof Go or instanceof > Throw. > If one of these things are true, I have to rethrow the Go or Throw > However I do not rethrow SeriousCondtions.. I have a different handler. > that may change the type of condition. > > > I suggest dividing the ontology of ConditionThrowable into two types: > > ControlTransfer > RuntimeCondition > Derive them both from RuntimeException if you'd like. The thing is: SeriousCondition is never thrown in terms of Java 'throw': it's either signalled or error-ed, which don't use the Java throw primitive. I think these conditions really *are* transfer-of-control events. Thanks for your feedback! Bye, Erik.

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.17.0 released
by Erik Huelsmann 07 Nov '09

07 Nov '09

On behalf of the developers of ABCL (Armed Bear Common Lisp) I'm glad to be able to announce the 0.17.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 JSR-223. This release features - among lots of other things - performance improvements, a fix for unexpected thread termination due to uncaught exceptions and example code for running ABCL on Google App Engine. You can find the full release notes at: http://common-lisp.net/project/armedbear/release-notes-0.17.shtml 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.17.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.17.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.17.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.17.0.zip.asc In addition, binaries are also available: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.17.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-bin-0.17.0.zip With associated signatures: http://common-lisp.net/project/armedbear/releases/abcl-bin-0.17.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-bin-0.17.0.zip.asc Erik Huelsmann

1 0

Re: [armedbear-devel] Changes to ConditionThrowable
by logicmoo＠gmail.com 06 Nov '09

06 Nov '09

Sorry I should said Go & Return -> ControlTransfer - > RuntimeException Throw -> RuntimeCondition -> RuntimeException Though some people use Throw for for flow control ----- Original Message ----- From: <dmiles(a)users.sourceforge.net> To: "Erik Huelsmann" <ehuels(a)gmail.com>; "Armed Bear" <armedbear-devel(a)common-lisp.net> Sent: Friday, November 06, 2009 4:33 PM Subject: Re: [armedbear-devel] Changes to ConditionThrowable > My two cents: > > Those who call Lisp.eval(...) or mySymbol.execute() should at least be capable of catching RuntimeCondition > But should not be forced to also catch Go and Throw > > The way it is now.. > I have a Primitive that I implement outside of ABCL. > It catches certain condition throwables but should not have to catch Throw/Go > > which means: > ABCL calls my primitive. > My code is calling back into ABCL > I must catch ConditionThrowable. > I must also check to see if ConditionThrowable instanceof Go or instanceof Throw. > If one of these things are true, I have to rethrow the Go or Throw > However I do not rethrow SeriousCondtions.. > I have a different handler. that may change the type of condition. > > > I suggest dividing the ontology of ConditionThrowable into two types: > > ControlTransfer > RuntimeCondition > > Derive them both from RuntimeException if you'd like. > > > > ----- Original Message ----- > From: "Erik Huelsmann" <ehuels(a)gmail.com> > To: "Armed Bear" <armedbear-devel(a)common-lisp.net> > Sent: Friday, November 06, 2009 11:49 AM > Subject: [armedbear-devel] Changes to ConditionThrowable > > >>A very prominent item in our API is that nearly every function is >> declared to throw ConditionThrowable. >> >> Personally, I have 2 gripes with that situation: >> >> 1) ConditionThrowable is the most undescriptive name of what it actually is and >> 2) Since ConditionThrowable is a completely *internal* thing to ABCL, >> it's wrong to expose it this way >> >> >> My proposal is to: >> >> 1) Rename ConditionThrowable to ControlTransfer - which is more of a >> description of what it does: it's used internal to ABCL to cause >> non-local transfer of control >> 2) Make ControlTransfer an unchecked exception (thus derive it from >> RuntimeException), because that'll allow us to keep it from being >> exposed in the API. >> We'll need to document in an abcl-embedding manual that callbacks >> should be aware of the fact that a ControlTransfer exception may cause >> the function's execution to be terminated. >> >> >> For normal API use, ControlTransfer won't be seen: it'll be thrown and >> consumed inside ABCL. >> >> >> How about that? >> >> Bye, >> >> >> Erik. >> >> _______________________________________________ >> armedbear-devel mailing list >> armedbear-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

2 1

[armedbear-devel] Changes to ConditionThrowable
by Erik Huelsmann 06 Nov '09

06 Nov '09

A very prominent item in our API is that nearly every function is declared to throw ConditionThrowable. Personally, I have 2 gripes with that situation: 1) ConditionThrowable is the most undescriptive name of what it actually is and 2) Since ConditionThrowable is a completely *internal* thing to ABCL, it's wrong to expose it this way My proposal is to: 1) Rename ConditionThrowable to ControlTransfer - which is more of a description of what it does: it's used internal to ABCL to cause non-local transfer of control 2) Make ControlTransfer an unchecked exception (thus derive it from RuntimeException), because that'll allow us to keep it from being exposed in the API. We'll need to document in an abcl-embedding manual that callbacks should be aware of the fact that a ControlTransfer exception may cause the function's execution to be terminated. For normal API use, ControlTransfer won't be seen: it'll be thrown and consumed inside ABCL. How about that? Bye, Erik.

2 1

[armedbear-devel] Compilation bug in LET/LET* init-form
by Mark Evenson 06 Nov '09

06 Nov '09

There seems to be a bug around the compilation of illegal LET/LET* init forms with an extra set of parentheses. The form (defun f () (let ((x ((1))))) 42) when placed in a file, and compiled gives a error on loading the file that it can't find the '.cls' associated with this function. Looking at the FASL shows that the '.cls' is zero length. The compiler should signal an error when compiling the form rather than writing the malformed FASL. Presumably this is a failure to recognize that the compilation of the the LET init form has failed somewhere in the compiler. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 3

Re: [armedbear-devel] 0.18 and beyond
by logicmoo＠gmail.com 06 Nov '09

06 Nov '09

>> How do you then pass the primitive as one? Like passing EQ/EQUAL/EQUALP >> to FIND/POSITION family of functions? Oh right, I understand the question a little better Here is that impl: http://larkc.svn.sourceforge.net/viewvc/larkc/trunk/platform/src/com/cyc/to… public static final SubLObject find(SubLObject item, SubLObject sequence, SubLObject test, SubLObject key, SubLObject start, SubLObject end) { // throw type error or allow user to supply a sequence type SubLSequence sequenceTyped = sequence.toSeq(); // find or compile 2 arg signture version of the Test function // if UNPROVIDED use EQ BinaryFunction testFunction = extractBinaryFunc(test); // find or compile 1 arg signture version of the key function UnaryFunction keyFunction = extractUnaryFunc(key); //unboxers (or force user to supply an int if not coercable) int startTyped = extractStart(start); int endTyped = extractEnd(end); // use the specific Seq find/5 impl SubLObject result = sequenceTyped.find(item, testFunction, keyFunction, startTyped, endTyped); return result; }

2 4

Re: [armedbear-devel] 0.18 and beyond
by logicmoo＠gmail.com 06 Nov '09

06 Nov '09

Dissregared the last email there was a Hypelink that I misspelled as well as rewrote my last post to make clearer ----- Original Message ----- From: "Ville Voutilainen" <ville.voutilainen(a)gmail.com> To: <dmiles(a)users.sourceforge.net> Cc: "Armed Bear" <armedbear-devel(a)common-lisp.net> Sent: Thursday, November 05, 2009 9:57 PM Subject: Re: [armedbear-devel] 0.18 and beyond > 2009/11/6 <logicmoo(a)gmail.com>: >>>> Other java lisps define each Primitive execute as a single static function >>>> in a trampolines file. >>>> The Primitive itself just calls the static function in the trampolines ( >>>This is a useful technique to speed up compiled code. It could also >>>speed up startup times as long as you don't invoke such primitives >> Indeed > > The translation looks like there's no longer a Primitive that extends > LispObject. No longer a "requirement" for the compiler to *have to* use a Primitive > Do we generate wrappers on the fly? Correct As you foresee, for cases like #'APPLY/#'FUNCALL etc and from the interpreter it is done on the fly. Previous code that read: declareFunction(myName,"primitive_CHAR_LESS_THAN_execute_1_0_false","CHAR<",1,0,false); declareFunction(myName,"primitive_CHAR_LESS_THAN_execute_2_0_false","CHAR<",2,0,false); declareFunction(myName,"primitive_CHAR_LESS_THAN_execute_0_0_true","CHAR<",0,0,true); Does actually create 5 objects: One Symbol: Symbol s = intern("CHAR<",pkg); One Primtive subclass called a FunctorIndexer FunctorIndexer p = new FunctorIndexer(s); One Primtive is placed inside the symbol-function: s.setSymbolFunction(p); Three Functors: p.Add( new ForwardFunctor(s,myName,"primitive_CHAR_LESS_THAN_execute_1_0_false","CHAR<",1,0,false)); p.Add ( new ForwardFunctor(s,myName,"primitive_CHAR_LESS_THAN_execute_2_0_false","CHAR<",2,0,false)); p.Add( new ForwardFunctor(s,myName,"primitive_CHAR_LESS_THAN_execute_0_0_true","CHAR<",0,0,true)); This will later be used to index the call sigs to the best ForwardFunctor. So far we have made 5 objects: s,p,f0,f1,f2 ------------------------------------------------------------------------------------------ On first use: lets say: (funcall 'char< #\a #\b #\c) thats 3 args ins .. the best match is f2 - This transistion is handled in here: http://larkc.svn.sourceforge.net/viewvc/larkc/trunk/platform/src/com/cyc/to… It creates one class that implments processArgs(LispObject r0,LispObject r1,LispObject r2) And loads the arity3Cache of the FunctorIndexer which physically calls the static function: return primitive_CHAR_LESS_THAN_execute_0_0_true(new LispObject[]{r0,r1,r2}); ----------------------- So far we have made 6 objects ----------------------- Note though this machinery is only used in FUNCALL and interpreted code When hitting the functor generator .. it should be considered "worse case" But serves a better way case than hitting the reflection on line 62 of http://larkc.svn.sourceforge.net/viewvc/larkc/trunk/platform/src/com/cyc/to… (But this 2ndary wrapper technique still isn't that bad. ) > How do you then pass the primitive as one? Like passing EQ/EQUAL/EQUALP > to FIND/POSITION family of functions? You find-or-create the Symbol like findSymbol("EQ",pgk).getSymbolFunction().execue(a0,a1,etc); like before. ".getSymbolFunction()" is where the new magic takes place > Or user-defined functions that take > functions, and you don't know the type and must box it (aka pass it as > a LispObject)? Currently all execute(..,.,.,.) signatures take LispObject as before. However with not much more work it is possible to make a cache of unboxed versions like... public final static LispObject primitive_CHAR_LESS_THAN_execute_2_0_false_nobox(char req0, char req1) { return req0 < req1? T : NIL; } Registered the same way to the interpreter and compiler: declareFunction(myName,"primitive_CHAR_LESS_THAN_execute_2_0_false_unboxed","CHAR<",2,0,false); Actually if you want, is even simplier to not go thru the explicit "registration process" but using Annotations @InlineCompiler(symbolname="CHAR<", package="COMMON-LISP"); public final static LispObject primitive_CHAR_LESS_THAN_execute_2_0_false_nobox(char req0, char req1) { return req0 < req1? T : NIL; }

1 0

[armedbear-devel] symbol-macrolet bug
by szergling 05 Nov '09

05 Nov '09

Hi everyone, I've been quite stoked to watch the surge of activity on armedbear in the last few months. Keep up the good work guys! My reason for this email is: If I type the following at the REPL, or load from a file (that's how I discovered this), I get an error in abcl-0.16.0. Regardless of mode (REPL. load file, with or without eval-when), I always get an error. It's that load-time-value causing trouble, I believe... (defun test () (symbol-macrolet ((ii (load-time-value 45))) ii)) (test) #+nil ;; uncomment for alternative test (eval-when (:load-toplevel :execute) (test)) The symbol-macro seems to have disappeared for some reason... Debugger invoked on condition of type UNBOUND-VARIABLE: The variable II is unbound. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(78): Apologies if this is a well known bug. Thank you!

2 2

[armedbear-devel] ABCL basics
by dusan lukic 05 Nov '09

05 Nov '09

Hi all, with your help, I managed to create abcl.jar file, and now I need some basic knowledge of using it. I would like to know how to compile Lisp code (in a form of String or text file) and call it from Java code. I would also like to get some basic idea of which classes are defined in the abcl.jar file, and what is their purpose and what can I do with them. Furthermore, I would like to obtain some abcl help (it can be online, too), which contain descriptions of abcl classes and their methods, fields, stuff like that. Can anyone point me to some documentation or give some guidelines? Thaks.

2 1

[armedbear-devel] Fwd: [j-devel] Improving startup time: sanity check
by Erik Huelsmann 03 Nov '09

03 Nov '09

forwarding ---------- Forwarded message ---------- From: Alessio Stalla <alessiostalla(a)gmail.com> Date: Wed, Oct 28, 2009 at 11:20 PM Subject: Re: [j-devel] Improving startup time: sanity check To: Erik Huelsmann <ehuels(a)gmail.com> Cc: armedbear-j-devel(a)lists.sourceforge.net, Alex Muscar <muscar(a)gmail.com> On Wed, Oct 28, 2009 at 9:15 PM, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Last weekend, we experimented with better autoloading. It turned out > to strip roughly .4 seconds from a cold startup time of 1.7s, making > it a 25% improvement. > > However, the reason we started out with the startup time improvements > in the first place was the ABCL startup time on Google App Engine. It > turns out that our CPU usage during startup hasn't really decreased > much (as per their benchmark indicator - they can't really give an > actual figure). > > So, I asked for advice on #appengine (on freenode). Their reaction was > "we can't imagine the startup time being related to the size of the > JAR" even though Peter Graves calculated a 34% ratio between ABCL and > Clojure jar sizes and a 35% ratio between startup times - that looks > like a linear match. Their reaction continued "you're probably just > doing too much work during the init() phase." > > The init() phase is where the ABCL environment gets loaded and all > function objects get created. > > Let's assume for a second they're right. In that case we must assume > it's not I/O holding us up: it's the work the CPU must do to get us up > and running. If that's true, profiling the application should tell us > something about the bottlenecks we're running into. I happen to have > done quite a number of such profiles in the course of last week. The > conclusion which stands out is that ABCL - during the startup process > - spends ~ 40% of its time finding class constructors: the main > component of creating function objects. > > This brought me to the conclusion that our startup process could be > much faster, if we decided to delay function object creation until the > function is actually used: we would eliminate the need to construct > function objects until they're used instead of creating them when > their siblings are requested to be loaded. > > The idea is to create another Autoload derivative which will be > "installed" in the appropriate places which, when invoked, loads the > actual class from the byte array. I'm hoping this will cause a more > equally spread "initialization load". The performance hit will only be > the first call to the function: after it has been converted from the > byte array, the autoload object will remove itself from the function > call chain. > > So, how about it? Comments most welcome! I have mixed feelings about the idea. I think it's clever; but I also think we (I, at least) need more data to know if it will be actually beneficial. If the goal is speeding up startup time in a context like AppEngine - where not only Lisp, but the whole user application will be loaded from scratch from time to time - then it is critical to know how many Lisp functions a generic application uses on average (both directly and indirectly). If it turns up that, say, 50% of Lisp is commonly used, then no matter how clever an autoloading scheme you implement, you'll cut loading times only by roughly 50% at best. If getting constructors through reflection is really the bottleneck, and if we determine that using new instead of reflection is significantly faster (from a quick test of mine, it seems it *really* is [1]), then it might be sensible to avoid reflection altogether and devise another scheme. For example, the compiler-generated class X could contain in its static initialization block the equivalent of something like Lisp.someThreadLocal.set(new X()) and loadCompiledFunction or what it is could just fetch the instance from the threadlocal; not very elegant, but if it speeds things up... Alessio [1] this is the astounding result on a couple of runs on 50000 iterations (test files attached): REFLECTION: 16262373155 NEW: 84267527 % SLOWER: 19298 REFLECTION: 15917190176 NEW: 103681915 % SLOWER: 15351 REFLECTION: 15838714133 NEW: 77235481 % SLOWER: 20507 (times in ns) i.e. reflection as we use it is roughly 150-200 times slower than new and that's on a very simple class with no superclasses and a single constructor! The test might be wrong as I wrote it quickly and it's quite tricky. It uses the very same classloader of abcl, though (copy-pasted).

3 3

[armedbear-devel] Focusing 0.18 efforts
by Erik Huelsmann 03 Nov '09

03 Nov '09

Today, I branched for 0.17 (to be released soon), meaning that trunk has become free for 0.18 development. Personally, I found there are a number of items open any one of which could become part of our 0.18 effort. These are the points I identified: * Investigate and improve startup performance * CLOS conformance improvements (including define-method-combination support?) * Cleanup of Load.java - which would allow loading compressed fasls off streams * Gray stream compatibility finalization [we're 99% compatible, but FUNDAMENTAL-STREAM should be recognized as a subtype of STREAM] * Some random other stuff that comes along Do you have your own, or opinions on the points I mentioned above? Let's hear it! Bye, Erik.

2 3

[armedbear-devel] One more change for 0.17: FASL format update
by Erik Huelsmann 03 Nov '09

03 Nov '09

During the coming into existence of 0.17, there was an API change with respect to binding specials. This api change allows quick local access to the binding generated. However, the function for which the api signature is changed, is part of our generated .cls files (FASLs). Hence, I conclude we need a FASL version increment before 0.17 - which hasn't happened yet. Regards, Erik.

1 0

[armedbear-devel] Fw: [jvm-l] Re: Some Array vs GETFILED access times
by logicmoo＠gmail.com 01 Nov '09

01 Nov '09

----- Original Message ----- From: "Charles Oliver Nutter" <headius(a)headius.com> To: <jvm-languages(a)googlegroups.com> Sent: Sunday, November 01, 2009 8:47 PM Subject: [jvm-l] Re: Some Array vs GETFILED access times None of your results are too surprising to me. In JRuby, we moved several structures from encapsulating an array to using differently-sized "slotted" objects, with performance registering much better as a result. Some of that was due to the lack of boundschecks on the arrays, but another portion was probably due to the reduced size of an object + reference versus object + reference + array. Some comments inline below. On Sun, Nov 1, 2009 at 7:48 PM, <logicmoo(a)gmail.com> wrote: > public class ArrayVsClass { > > public static void main(String[] args) { > long lVectorStartTime = System.currentTimeMillis(); > int iterations = Integer.MAX_VALUE; > while (iterations-- > 0) { > // int iterations2 = 10; > //while (iterations2-- > 0) > { > //testArray(); // ARRAY > // vs > //testGETFIELD(); // GETFIELD > // vs > testIBean(); // INVOKE INTERFACE > // vs > //testBean(); // INVOKE VIRTUAL > // vs > //testABean(); // INVOKE VIRTUAL POSSIBLY THROW > // vs > //testSlots(); // INVOKE FOR AVALUE > } > } > long lVectorRunTime = System.currentTimeMillis() - lVectorStartTime; > System.out.println("Bench time: " + lVectorRunTime); > > } Because of optimization effects, you should try running them all together in the same benchmark in varying orders. Short benchmarks like these can skew actual results because only a small subset of the full code needs to be considered for optimization. > // SLOTS time: 33157,33250,33156 > public static void testSlots() { > ClassWithSlots oneSlot = new ClassWithSlots(6); ... > // Array time: 18438,18437,18422 > public static void testArray() { > final long[] accessArray = new long[] { 6 }; Not too surprising; you're paying the cost of the array plus the cost of the virtual invocation. So even after inlining, you've got something like boundscheck + deref + virtual call. > // GETFIELD time: 14688,14531,14453 > public static void testGETFIELD() { > ClassWithOneSlot oneSlot = new ClassWithOneSlot(6); ... > // INVOKE VIRTUAL time: 14750,14594,14719 > public static void testBean() { > ClassWithOneSlot oneSlot = new ClassWithOneSlot(6); This is exactly the pattern we use in JRuby for heap-based scopes. We have from ZeroVarDynamicScope up to FourVarDynamicScope and then it falls over into an array-based version. Because we can statically tell how many variable slots we'll need in most Ruby scopes, this ended up being a big perf improvement for us. > // INVOKE INTERFACE time: 14469,14610,14859 > public static void testIBean() { > IBeanWithOneSlot oneSlot = new ClassWithOneSlot(6); > > int iterations = Integer.MAX_VALUE; > long result = 0; > while (iterations-- > 0) { > result += oneSlot.getValue(); > } > } invokeinterface ends up as fast as invokevirtual once it's been inlined, so this is no surprise. > // INVOKE VIRTUAL POSSIBLY THROW time: 14641,14594,14547 > public static void testABean() { > AClassWithOneSlot oneSlot = new ClassWithOneSlot(6); Exception-handling paths not followed do not impact performance, so this is also not surprising. Try having one out of the N invocations trigger the exception and watch the perf change drastically from then on. - Charlie --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to jvm-languages(a)googlegroups.com To unsubscribe from this group, send email to jvm-languages+unsubscribe(a)googlegroups.com For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---

1 0

[armedbear-devel] Some Array vs GETFILED access times
by logicmoo＠gmail.com 01 Nov '09

01 Nov '09

ABCL, For implementing MOP-like objects these times are something to consider. What I draw from it is when not messing with arrays (array bounds checking). Every case is better than. JVM-L, Do these tests with times make sense? package ArrayTests; public class ArrayVsClass { public static void main(String[] args) { long lVectorStartTime = System.currentTimeMillis(); int iterations = Integer.MAX_VALUE; while (iterations-- > 0) { // int iterations2 = 10; //while (iterations2-- > 0) { //testArray(); // ARRAY // vs //testGETFIELD(); // GETFIELD // vs testIBean(); // INVOKE INTERFACE // vs //testBean(); // INVOKE VIRTUAL // vs //testABean(); // INVOKE VIRTUAL POSSIBLY THROW // vs //testSlots(); // INVOKE FOR AVALUE } } long lVectorRunTime = System.currentTimeMillis() - lVectorStartTime; System.out.println("Bench time: " + lVectorRunTime); } // SLOTS time: 33157,33250,33156 public static void testSlots() { ClassWithSlots oneSlot = new ClassWithSlots(6); int iterations = Integer.MAX_VALUE; long result = 0; while (iterations-- > 0) { result += oneSlot.getValue(); } } // Array time: 18438,18437,18422 public static void testArray() { final long[] accessArray = new long[] { 6 }; int iterations = Integer.MAX_VALUE; long result = 0; while (iterations-- > 0) { result += accessArray[0]; } } // GETFIELD time: 14688,14531,14453 public static void testGETFIELD() { ClassWithOneSlot oneSlot = new ClassWithOneSlot(6); int iterations = Integer.MAX_VALUE; long result = 0; while (iterations-- > 0) { result += oneSlot.slot; } } // INVOKE VIRTUAL time: 14750,14594,14719 public static void testBean() { ClassWithOneSlot oneSlot = new ClassWithOneSlot(6); int iterations = Integer.MAX_VALUE; long result = 0; while (iterations-- > 0) { result += oneSlot.getValue(); } } // INVOKE INTERFACE time: 14469,14610,14859 public static void testIBean() { IBeanWithOneSlot oneSlot = new ClassWithOneSlot(6); int iterations = Integer.MAX_VALUE; long result = 0; while (iterations-- > 0) { result += oneSlot.getValue(); } } // INVOKE VIRTUAL POSSIBLY THROW time: 14641,14594,14547 public static void testABean() { AClassWithOneSlot oneSlot = new ClassWithOneSlot(6); int iterations = Integer.MAX_VALUE; long result = 0; while (iterations-- > 0) { result += oneSlot.getValue(); } } static interface IBeanWithOneSlot { public long getValue(); } static class ClassWithOneSlot extends AClassWithOneSlot implements IBeanWithOneSlot { final public long slot; ClassWithOneSlot(long s) { slot = s; } @Override final public long getValue() { return slot; } } static class ClassWithSlots { final public long[] slots = new long[1]; ClassWithSlots(long s) { slots[0] = s; } final public long getValue() { return slots[0]; } } static abstract class AClassWithOneSlot implements IBeanWithOneSlot { @Override public long getValue() { throw new NullPointerException(); } } }

1 0

[armedbear-devel] Fwd: [j-devel] Improving startup time: sanity check
by Erik Huelsmann 29 Oct '09

29 Oct '09

forwarding ---------- Forwarded message ---------- From: Alessio Stalla <alessiostalla(a)gmail.com> Date: Wed, Oct 28, 2009 at 11:34 PM Subject: Re: [j-devel] Improving startup time: sanity check To: Erik Huelsmann <ehuels(a)gmail.com> Cc: armedbear-j-devel(a)lists.sourceforge.net, Alex Muscar <muscar(a)gmail.com> On Wed, Oct 28, 2009 at 11:20 PM, Alessio Stalla <alessiostalla(a)gmail.com> wrote: > The test might be wrong It was, indeed, wrong. It measured class loading time too for reflection, but that can't be eliminated, no matter what instantiation technique you use. New results on 50000 iterations: REFLECTION: 9660480097 NEW: 88353767 % SLOWER: 10933 REFLECTION: 9602410291 NEW: 78459331 % SLOWER: 12238 REFLECTION: 9925574038 NEW: 86923015 % SLOWER: 11418 ~100 times slower is still impressive. Ale

1 1

[armedbear-devel] Fwd: [j-devel] Improving startup time: sanity check
by Erik Huelsmann 29 Oct '09

29 Oct '09

Sorry, we seem to be having this discussion on the wrong mailing list. Forwarding. ---------- Forwarded message ---------- From: Alessio Stalla <alessiostalla(a)gmail.com> Date: Thu, Oct 29, 2009 at 9:36 AM Subject: Re: [j-devel] Improving startup time: sanity check To: Erik Huelsmann <ehuels(a)gmail.com> Cc: armedbear-j-devel(a)lists.sourceforge.net, Alex Muscar <muscar(a)gmail.com> On Wed, Oct 28, 2009 at 11:34 PM, Alessio Stalla <alessiostalla(a)gmail.com> wrote: > On Wed, Oct 28, 2009 at 11:20 PM, Alessio Stalla > <alessiostalla(a)gmail.com> wrote: >> The test might be wrong > > It was, indeed, wrong. It measured class loading time too for > reflection, but that can't be eliminated, no matter what instantiation > technique you use. > > New results on 50000 iterations: > > REFLECTION: 9660480097 > NEW: 88353767 > % SLOWER: 10933 > > REFLECTION: 9602410291 > NEW: 78459331 > % SLOWER: 12238 > > REFLECTION: 9925574038 > NEW: 86923015 > % SLOWER: 11418 > > ~100 times slower is still impressive. Incidentally, if those figures are right, it means that class loading from byte array is very costly too, and Erik's idea is likely to improve performance significantly if the application never uses a relatively large part of Lisp.

1 0

Re: [armedbear-devel] [armedbear-cvs] r12226 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 27 Oct '09

27 Oct '09

> Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp Sun Oct 25 18:35:52 2009 > @@ -1948,6 +1948,8 @@ > (when (plusp (length output)) > output))) > > +(defvar *declare-inline* nil) > + > (defmacro declare-with-hashtable (declared-item hashtable hashtable-var > item-var &body body) > `(let* ((,hashtable-var ,hashtable) > @@ -1970,19 +1972,19 @@ > (declare-object symbol +lisp-symbol+ > +lisp-symbol-class+)))) > (t > - (let ((*code* *static-code*) > - (s (sanitize symbol))) > - (setf g (symbol-name (gensym "SYM"))) > - (when s > - (setf g (concatenate 'string g "_" s))) > - (declare-field g +lisp-symbol+ +field-access-private+) > - (emit 'ldc (pool-string (symbol-name symbol))) > - (emit 'ldc (pool-string (package-name (symbol-package symbol)))) > - (emit-invokestatic +lisp-class+ "internInPackage" > - (list +java-string+ +java-string+) +lisp-symbol+) > - (emit 'putstatic *this-class* g +lisp-symbol+) > - (setf *static-code* *code*) > - (setf (gethash symbol ht) g)))))) > + (let ((*code* *static-code*) > + (s (sanitize symbol))) > + (setf g (symbol-name (gensym "SYM"))) > + (when s > + (setf g (concatenate 'string g "_" s))) > + (declare-field g +lisp-symbol+ +field-access-private+) > + (emit 'ldc (pool-string (symbol-name symbol))) > + (emit 'ldc (pool-string (package-name (symbol-package symbol)))) > + (emit-invokestatic +lisp-class+ "internInPackage" > + (list +java-string+ +java-string+) +lisp-symbol+) > + (emit 'putstatic *this-class* g +lisp-symbol+) > + (setf *static-code* *code*) > + (setf (gethash symbol ht) g)))))) There's a thinko in the above hunk: it only re-indents, that was intentional. However, it assumes the package to intern into exist. When *declare-inline* is non-NIL, there's a fair chance the package hasn't been created at *static-code* time though. This means the symbol creation will need to happen in-line too. I'll fix this later today. Bye, Erik.

1 0

[armedbear-devel] Change the default action of 'build.xml' to 'abcl.clean abcl.wrapper'?
by Mark Evenson 26 Oct '09

26 Oct '09

[Including armedbear-devel@ for potential wider dicussion.] On 10/26/09 1:05 PM, Erik Huelsmann wrote: […] > > BTW: I'm always doing complete builds; are you too? Yeah, in fact I think the much more common use case of the build system is 'ant abcl.clean abcl.wrapper'. I almost always want a full build from scratch, which is now taking slightly under two minutes for my MacBook Pro laptop. A couple years ago, a full build took something like five minutes from what I remember, so there was more of a need for incremental builds. What's your usage pattern like? Maybe I should make 'abcl.clean abcl.wrapper' the default target, where the old behavior could be re-restablished via setting an Ant property. This is contrary to the behavior of most build systems that I have experienced, but since we could write a banner message like "Starting build from scratch; set 'abcl.build.incremental' in 'build.properties' to enable incremental builds in the future." Thoughts? -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

[armedbear-devel] Binary FASL support
by Erik Huelsmann 26 Oct '09

26 Oct '09

As the result of an attempt to reduce our startup time, I implemented binary FASL support: a compiled lisp function (= Java class) which gets executed instead of the interpreted forms which used to constitute the texty fasl format. The texty format is still there, but in case of a binary fasl only contains 2 forms to be evaluated, the rest will be in the compiled function. I don't feel like we achieved much: my startup times used to be 0.4 s and 1.6 s and that doesn't seem to have changed. Bummer. However, that's probably to be expected, because I was just guessing where our performance issue would be: I want to know how much of the 0.4 and 1.6 seconds are actually spent waiting on I/O happening. In case we're waiting big time on the data coming from the JAR, maybe there's an optimization possible to the way we create/read the JAR file. Any help on the subject of reducing our startup time would be most welcome! Bye, Erik.

2 1

[armedbear-devel] Error in 'test.lisp' to create .abcl_completions
by John Pallister 23 Oct '09

23 Oct '09

Hello list, I think there's an error in the 'test.lisp' code used to create .abcl_completions at http://common-lisp.net/project/armedbear/doc/abcl-install-with-java.html . Basically it should start with (defvar symbols nil) or somesuch to avoid an UNBOUND-VARIABLE error. Cheers, John :^P -- John Pallister john(a)johnp.net john(a)synchromesh.com

2 1

[armedbear-devel] Binary release 0.17 (steps to be taken)
by Erik Huelsmann 23 Oct '09

23 Oct '09

I'm hoping to be able to publish binaries when releasing 0.17. However, I think we're not yet completely ready to do so. We're missing: * Usage descriptions in terms of an INSTALL file, or something similar * Build targets, like we have for the src archives, for abcl-bin-<version>.zip and abcl-bin-<version>.tar.gz * Anything else? As for the archives, I'd like them to contain many of our top-level files (COPYING, README, etc) and instead of the subdirectories, I think it should contain abcl.jar Comments? Bye, Erik.

2 2

[armedbear-devel] Bug: Attempt to GO to a tag whose extent has ended quits ABCL
by Brian Mastenbrook 23 Oct '09

23 Oct '09

When attempting to GO to a tag whose dynamic extent has ended, ABCL quits and prints the name of the exception used for internally handling GO (org.armedbear.lisp.Go). I see the same behavior in compiled or interpreted code. CL-USER(1): (lisp-implementation-version) "0.16.0" CL-USER(2): (let ((f nil)) (tagbody (setf f (lambda () (go foo))) foo) (funcall f)) org.armedbear.lisp.Go abcl-src-0.16.0 chandler$ -- Brian Mastenbrook brian(a)mastenbrook.net http://brian.mastenbrook.net/

2 1

Re: [armedbear-devel] Using Java Libraries
by Carlos Ungil 21 Oct '09

21 Oct '09

> Hi folks, > > I'm searching for a (more systematic) documentation (or tutorial) > about how to use Java libraries from ABCL. > > I couldn't find anything else except the examples on > "http://trac.common-lisp.net/armedbear/browser/trunk/abcl/examples/abcl". > > Is there any such tutorial (or documentation) at all? > Any feedback is very much appreciated! > > Regards > Nik Hello, you might want to check jfli-abcl. Jfli, by Rich Hickey (who would later create Clojure), makes it possible to call Java from LispWorks. It was ported to ABCL by Andras Simon. You can I've just noticed you can find a recent (and improved) copy of jfli-abcl (including sample code) from http://github.com/avodonosov/abcl-idea/tree/master/src/abclidea/lisp/jfli-a… My version of the file has a couple of extra things that might be useful. 1) I had to add a case to infer-box-type to be able to call functions with java.lang.Float arguments. (defun infer-box-type (x) (cond ((null x) nil) ((boxed? x) (jobject-class (get-ref x))) ((integerp x) integer.type) ((typep x 'single-float) float.type) ((numberp x) double.type) ........ 2) I think the following change was done by Alex Mizrahi (I took the file from abcl-web). I don't know if it's still required. < `(defclass ,(class-symbol full-class-name) < ,supers ())))))))) --- > `(unless (get ,class-sym :ensured) ;no fwd ref'd classes in abcl > (ensure-java-class ,full-class-name) > (defclass ,(class-symbol full-class-name) > ,supers ()))))))))) I also added a "doto" macro similar to the one in Clojure (http://clojure.org/java_interop#toc15) (defmacro doto (object &body body) `(let ((object ,object)) ,@(loop for form in body collect `(,(first form) object ,@(rest form))) object)) so I can do things like (document.add (doto (pdfptable.new 3) (pdfptable.addCell (doto (pdfpcell.new (paragraph.new "header with colspan 2")) (pdfpcell.setColspan 2))) (pdfptable.addCell "A") (pdfptable.addCell "B"))) Cheers, Carlos

1 0

[armedbear-devel] Optimizing startup time
by Erik Huelsmann 21 Oct '09

21 Oct '09

Yesterday, Alex Muscar and I were chatting about the options and possibilities to use ABCL on GAE. It turns out that ABCL's startup gets triggered more often than we expected: instances of ABCL may get swapped out of memory or mapped to different servers, meaning ABCL needs to load all from scratch. So, we were evaluating what options we have to optimize ABCL's startup time. As always, I want to base such a decision on facts, so I ran the profiler on ABCL's startup yesterday. The conclusion is that ~ 40 to 45% of our startup time is spent in "privateGetDeclaredConstructors()". This is due to loadCompiledFunction calling the class's newInstance() method. That however, is the processing time spent. I'd love to be able to reduce it, but the function body delegates to a C/C++ function which means I can't fully understand its performance characteristics. Now, the other thing might be "I/O waiting time". Although the profiler measures "run time" and "wait time", I'm not sure how to deduce I/O wait time from that, or how to profile I/O times in another way. If there is considerable I/O wait time, we could probably speed up ABCL's startup process without having to drastically change any design decisions. Does anybody have any comments to that? Helpful remarks on how to find out about I/O wait time? Bye, Erik.

1 0

Re: [armedbear-devel] Using named classes for primitives
by Erik Huelsmann 21 Oct '09

21 Oct '09

On Mon, Oct 19, 2009 at 2:59 PM, Alessio Stalla <alessiostalla(a)gmail.com> wrote: > On Mon, Oct 19, 2009 at 2:22 PM, Alex Muscar <muscar(a)gmail.com> wrote: >> Hi, >> >> I've been messing around with the code. I've managed to load the fasl, >> but I think we're missing some initializations because I get the >> following error: >> >> ERROR placeholder called with arguments: >> #<UNDEFINED-FUNCTION SYSTEM::ENSURE-AVAILABLE-SYMBOLS {E5F46E}> >> >> Here's a full stack trace: >> >> org.armedbear.lisp.ConditionThrowable: java.lang.Error >> at org.armedbear.lisp.Primitives$70.execute(Primitives.java:1459) > > OT, but not too much: if we used named classes for primitives we could > get more meaningful stack traces (say, JCALL instead of > Primitives$XY). I.e. instead of > > private static final Primitive xyz = new Primitive(...) { ... }; > > we could use > > private static class JCALL extends Primitive { > JCALL(...) { super(...); } > ... > } > private static final Primitive xyz = new JCALL(...); > > a bit more verbose, but worth the effort imho. I think so too. However, there are a few too many of these to start changing them over now. Or does anybody feel like hacking up a perl script to get it done? :-) Bye, Erik.

4 7

[armedbear-devel] abcl on AppEngine
by Alex Muscar 19 Oct '09

19 Oct '09

Here's the first abcl "app" running on Google AppEngine: http://1.latest.abcl-test.appspot.com/hello . It's not much, but it's a start ;). -- All the best, Alex Muscar

1 0

[armedbear-devel] Using Java Libraries
by nitralime 19 Oct '09

19 Oct '09

Hi folks, I'm searching for a (more systematic) documentation (or tutorial) about how to use Java libraries from ABCL. I couldn't find anything else except the examples on "http://trac.common-lisp.net/armedbear/browser/trunk/abcl/examples/abcl". Is there any such tutorial (or documentation) at all? Any feedback is very much appreciated! Regards Nik

3 5

[armedbear-devel] Google AppEngine
by Alex Muscar 19 Oct '09

19 Oct '09

Hi, I've been messing around with the code. I've managed to load the fasl, but I think we're missing some initializations because I get the following error: ERROR placeholder called with arguments: #<UNDEFINED-FUNCTION SYSTEM::ENSURE-AVAILABLE-SYMBOLS {E5F46E}> Here's a full stack trace: org.armedbear.lisp.ConditionThrowable: java.lang.Error at org.armedbear.lisp.Primitives$70.execute(Primitives.java:1459) at org.armedbear.lisp.Primitive.execute(Primitive.java:108) at org.armedbear.lisp.Symbol.execute(Symbol.java:781) at org.armedbear.lisp.Lisp.error(Lisp.java:349) at org.armedbear.lisp.Primitives$72.execute(Primitives.java:1509) at org.armedbear.lisp.Symbol.execute(Symbol.java:792) at org.armedbear.lisp.LispThread.execute(LispThread.java:528) at org.armedbear.lisp.Symbol.undefinedFunction(Symbol.java:898) at org.armedbear.lisp.Symbol.execute(Symbol.java:779) at org.armedbear.lisp.LispThread.execute(LispThread.java:511) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:488) at org.armedbear.lisp.Lisp.eval(Lisp.java:453) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:511) at org.armedbear.lisp.Lisp.eval(Lisp.java:453) at org.armedbear.lisp.Lisp.eval(Lisp.java:451) at org.armedbear.lisp.Load.faslLoadStream(Load.java:523) at org.armedbear.lisp.Load.access$100(Load.java:47) at org.armedbear.lisp.Load$1.execute(Load.java:381) at org.armedbear.lisp.LispThread.execute(LispThread.java:528) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:495) at org.armedbear.lisp.Lisp.eval(Lisp.java:453) at org.armedbear.lisp.Load.loadStream(Load.java:491) at org.armedbear.lisp.Load.loadFileFromStream(Load.java:452) at org.armedbear.lisp.Load.load(Load.java:165) at org.armedbear.lisp.Load.load(Load.java:94) at org.armedbear.lisp.Load.load(Load.java:53) at abcl_ae.AbclInit.<clinit>(AbclInit.java:32) at abcl_ae.HelloWorldServlet.doGet(HelloWorldServlet.java:17) at javax.servlet.http.HttpServlet.service(HttpServlet.java:693) at javax.servlet.http.HttpServlet.service(HttpServlet.java:806) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1093) at com.google.apphosting.utils.servlet.TransactionCleanupFilter.doFilter(TransactionCleanupFilter.java:43) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at com.google.appengine.tools.development.StaticFileFilter.doFilter(StaticFileFilter.java:121) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1084) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:360) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at com.google.apphosting.utils.jetty.DevAppEngineWebAppContext.handle(DevAppEngineWebAppContext.java:54) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at com.google.appengine.tools.development.JettyContainerService$ApiProxyHandler.handle(JettyContainerService.java:342) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:313) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:506) at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:830) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:514) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:381) at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:396) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) ERROR placeholder called with arguments: #<UNDEFINED-FUNCTION SYSTEM::ENSURE-AVAILABLE-SYMBOLS {E5F46E}> I've made Primitives.ERROR throw a ConditionThrowable instead of calling exit -- for debugging purpose. The fasls need to be in the war directory (or in a subdirectory). An ant task copies the .abcl files from src to war\fasls. I've attached an archive with the code as it looks now. -- All the best, Alex Muscar

3 2

[armedbear-devel] ABCL on Google App Engine (progress)
by Erik Huelsmann 19 Oct '09

19 Oct '09

Today, on IRC (irc://irc.freenode.net/#abcl) Alex and I have been working on getting ABCL to run on GAE (Google App Engine). We didn't complete our work, but since this mailing list has a wider audience than the IRC channel, I thought I'd forward our progress (his typing) to the mailing list. Possibly there are additional people interested. If others want to join in this effort to get ABCL running on GAE, I could commit the code to the examples directory in the repository. From there, we could make this a joint effort. One of the things we were running into is that we knew how to get a stream to the first-servlet.abcl file, but not how to get a path/URL to it. Can anybody contribute by answering how we should? When we know, we can do with the existing public functions, if there's not way, we need to make additional functions public. Bye, Erik. ---------- Forwarded message ---------- From: Alex Muscar <muscar(a)gmail.com> Date: Sun, Oct 18, 2009 at 6:13 PM Subject: The GAE bits To: ehuels(a)gmail.com Still hackish, though :(. We'll talk more about this tomorrow. -- All the best, Alex Muscar

2 3

[armedbear-devel] Serious bug involving UWP
by Tobias C. Rittweiler 18 Oct '09

18 Oct '09

Steps to reproduce: * ABCL from svn, updated a few minutes ago. * Slime from CVS. * M-x slime-scratch * Put (defun test (x) ,bar) in the buffer * Press C-c C-c You'll see "Evaluation aborted." in the minibuffer even though the debugger should have popped up complaining about comma not being inside backquote. C-c C-c is SWANK-COMPILE-STRING in swank-abcl.lisp. If you follow the control flow, you'll see that in SLDB-LOOP (we come here through *DEBUGGER-HOOK*) in swank.lisp, __the UNWINDED-PROTECT's protected form is *never* executed and it goes straight to the cleanup forms.__ -T.

4 13

[armedbear-devel] ABCL 0.16.1 released
by Erik Huelsmann 18 Oct '09

18 Oct '09

On behalf of the ABCL development team, I would like to announce the new ABCL release: 0.16.1 This release is a maintenance release on the 0.16 version line. In total four issues have been fixed: - In case of unsuccessful completion of a COMPILE call, ABCL would leak (= not correctly clean up behind itself) temporary files - In some cases, an exception thrown by a GO or RETURN-FROM form would not be correctly caught, causing the thread in which it occurs to terminate - Honor appearance of *&allow-other-keys* in CLOS MAKE-INSTANCE argument checking - More careful checking of 'null' arguments when processing stack frames Should you have any comments, remarks or bugs to be found in this release, please contact the developers through the mailing list mentioned on the ABCL project home page <http://common-lisp.net/project/armedbear/>.

1 0

[armedbear-devel] How to build the abcl.jar file within Eclipse
by dusan lukic 16 Oct '09

16 Oct '09

Hi all, I've downloaded ABCL from http://common-lisp.net/project/armedbear/ site, and, on it's building & running page, I've read that I can build abcl.jar file within Eclipse. I already have Eclipse installed on my computer, so can anyone, please, tell me how to do it. I do not have much experience with Eclipse, so a step-by-step procedure is preferred. Thanks, in advance.

2 1

Re: [armedbear-devel] [armedbear-cvs] r12180 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 15 Oct '09

15 Oct '09

John, The commit below removes temporary file use from the COMPILE function. This is the minimal requirement to get running on GAE. So, I hope that you'll be using ABCL as of this version in your testing. I'm eager to learn about your progress. If you run into issues, please don't hesitate, we definitely want to fix them. If at all possible I'm for doing that ASAP. Bye, Erik. On Wed, Oct 7, 2009 at 11:51 PM, Alessio Stalla <astalla(a)common-lisp.net> wrote: > Author: astalla > Date: Wed Oct 7 17:51:00 2009 > New Revision: 12180 > > Log: > Ticket #56: eliminated use of temporary files for COMPILE > > > Modified: > trunk/abcl/src/org/armedbear/lisp/CompiledClosure.java > trunk/abcl/src/org/armedbear/lisp/JavaClassLoader.java > trunk/abcl/src/org/armedbear/lisp/Lisp.java > trunk/abcl/src/org/armedbear/lisp/Stream.java > trunk/abcl/src/org/armedbear/lisp/compile-file.lisp > trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/CompiledClosure.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/CompiledClosure.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/CompiledClosure.java Wed Oct 7 17:51:00 2009 > @@ -207,7 +207,7 @@ > > // ### load-compiled-function > private static final Primitive LOAD_COMPILED_FUNCTION = > - new Primitive("load-compiled-function", PACKAGE_SYS, true, "pathname") > + new Primitive("load-compiled-function", PACKAGE_SYS, true, "source") > { > @Override > public LispObject execute(LispObject arg) throws ConditionThrowable > @@ -219,6 +219,14 @@ > namestring = arg.getStringValue(); > if (namestring != null) > return loadCompiledFunction(namestring); > + if(arg instanceof JavaObject) { > + try { > + return loadCompiledFunction((byte[]) arg.javaInstance(byte[].class)); > + } catch(Throwable t) { > + Debug.trace(t); > + return error(new LispError("Unable to load " + arg.writeToString())); > + } > + } > return error(new LispError("Unable to load " + arg.writeToString())); > } > }; > > Modified: trunk/abcl/src/org/armedbear/lisp/JavaClassLoader.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/JavaClassLoader.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/JavaClassLoader.java Wed Oct 7 17:51:00 2009 > @@ -37,17 +37,7 @@ > import java.util.HashSet; > import java.util.Set; > > -public class JavaClassLoader extends ClassLoader > -{ > - private static final boolean isSableVM; > - > - static { > - String vm = System.getProperty("java.vm.name"); > - if (vm != null && vm.equals("SableVM")) > - isSableVM = true; > - else > - isSableVM = false; > - } > +public class JavaClassLoader extends ClassLoader { > > private static JavaClassLoader persistentInstance; > > @@ -79,6 +69,10 @@ > } > } > > + public Class<?> loadClassFromByteArray(byte[] classbytes) { > + return loadClassFromByteArray(null, classbytes); > + } > + > public Class<?> loadClassFromByteArray(String className, > byte[] classbytes) > { > > Modified: trunk/abcl/src/org/armedbear/lisp/Lisp.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/Lisp.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/Lisp.java Wed Oct 7 17:51:00 2009 > @@ -1376,6 +1376,16 @@ > new Pathname(namestring))); > } > > + public static final LispObject makeCompiledFunctionFromClass(Class<?> c) > + throws Exception { > + if (c != null) { > + LispObject obj = (LispObject)c.newInstance(); > + return obj; > + } else { > + return null; > + } > + } > + > private static final LispObject loadCompiledFunction(InputStream in, int size) > { > try > @@ -1405,21 +1415,19 @@ > } > > public static final LispObject loadCompiledFunction(byte[] bytes) throws Throwable { > - Class<?> c = (new JavaClassLoader()) > - .loadClassFromByteArray(null, bytes, 0, bytes.length); > - if (c != null) { > - Constructor constructor = c.getConstructor((Class[])null); > - LispObject obj = (LispObject)constructor > - .newInstance((Object[])null); > - if (obj instanceof Function) { > - ((Function)obj).setClassBytes(bytes); > - } > - return obj; > - } else { > - return null; > - } > + return loadCompiledFunction(bytes, new JavaClassLoader()); > } > > + public static final LispObject loadCompiledFunction(byte[] bytes, JavaClassLoader cl) throws Throwable { > + Class<?> c = cl.loadClassFromByteArray(null, bytes, 0, bytes.length); > + LispObject obj = makeCompiledFunctionFromClass(c); > + if (obj instanceof Function) { > + ((Function)obj).setClassBytes(bytes); > + } > + return obj; > + } > + > + > public static final LispObject makeCompiledClosure(LispObject template, > ClosureBinding[] context) > throws ConditionThrowable > > Modified: trunk/abcl/src/org/armedbear/lisp/Stream.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/Stream.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/Stream.java Wed Oct 7 17:51:00 2009 > @@ -119,6 +119,14 @@ > { > } > > + public Stream(Reader r) { > + initAsCharacterInputStream(r); > + } > + > + public Stream(Writer w) { > + initAsCharacterOutputStream(w); > + } > + > public Stream(InputStream inputStream, LispObject elementType) > { > this(inputStream, elementType, keywordDefault); > > Modified: trunk/abcl/src/org/armedbear/lisp/compile-file.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compile-file.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compile-file.lisp Wed Oct 7 17:51:00 2009 > @@ -146,11 +146,17 @@ > (parse-body body) > (let* ((expr `(lambda ,lambda-list > ,@decls (block ,block-name ,@body))) > - (classfile-name (next-classfile-name)) > - (classfile (report-error > - (jvm:compile-defun name expr nil > - classfile-name))) > + (classfile (next-classfile-name)) > + (result (with-open-file > + (f classfile > + :direction :output > + :element-type '(unsigned-byte 8) > + :if-exists :supersede) > + (report-error > + (jvm:compile-defun name expr nil > + classfile f)))) > (compiled-function (verify-load classfile))) > + (declare (ignore result)) > (cond > (compiled-function > (setf form > @@ -205,10 +211,14 @@ > (let ((name (second form))) > (eval form) > (let* ((expr (function-lambda-expression (macro-function name))) > - (classfile-name (next-classfile-name)) > - (classfile > - (ignore-errors > - (jvm:compile-defun nil expr nil classfile-name)))) > + (classfile (next-classfile-name))) > + (with-open-file > + (f classfile > + :direction :output > + :element-type '(unsigned-byte 8) > + :if-exists :supersede) > + (ignore-errors > + (jvm:compile-defun nil expr nil classfile f))) > (if (null (verify-load classfile)) > ;; FIXME error or warning > (format *error-output* "; Unable to compile macro ~A~%" name) > @@ -342,10 +352,17 @@ > (eq (%car function-form) 'FUNCTION)) > (let ((lambda-expression (cadr function-form))) > (jvm::with-saved-compiler-policy > - (let* ((classfile-name (next-classfile-name)) > - (classfile (report-error > - (jvm:compile-defun nil lambda-expression nil classfile-name))) > + (let* ((classfile (next-classfile-name)) > + (result > + (with-open-file > + (f classfile > + :direction :output > + :element-type '(unsigned-byte 8) > + :if-exists :supersede) > + (report-error > + (jvm:compile-defun nil lambda-expression nil classfile f)))) > (compiled-function (verify-load classfile))) > + (declare (ignore result)) > (cond (compiled-function > (setf (getf tail key) > `(load-compiled-function ,(file-namestring classfile)))) > @@ -356,9 +373,16 @@ > (declaim (ftype (function (t) t) convert-toplevel-form)) > (defun convert-toplevel-form (form) > (let* ((expr `(lambda () ,form)) > - (classfile-name (next-classfile-name)) > - (classfile (report-error (jvm:compile-defun nil expr nil classfile-name))) > + (classfile (next-classfile-name)) > + (result > + (with-open-file > + (f classfile > + :direction :output > + :element-type '(unsigned-byte 8) > + :if-exists :supersede) > + (report-error (jvm:compile-defun nil expr nil classfile f)))) > (compiled-function (verify-load classfile))) > + (declare (ignore result)) > (setf form > (if compiled-function > `(funcall (load-compiled-function ,(file-namestring classfile))) > > Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp Wed Oct 7 17:51:00 2009 > @@ -4921,16 +4921,16 @@ > (emit-push-nil) > (emit-move-from-stack target))) > > -(defun compile-and-write-to-file (class-file compiland) > +(defun compile-and-write-to-stream (class-file compiland stream) > (with-class-file class-file > (let ((*current-compiland* compiland)) > (with-saved-compiler-policy > (p2-compiland compiland) > - (write-class-file (compiland-class-file compiland)))))) > + (write-class-file (compiland-class-file compiland) stream))))) > > -(defun set-compiland-and-write-class-file (class-file compiland) > +(defun set-compiland-and-write-class (class-file compiland stream) > (setf (compiland-class-file compiland) class-file) > - (compile-and-write-to-file class-file compiland)) > + (compile-and-write-to-stream class-file compiland stream)) > > > (defmacro with-temp-class-file (pathname class-file lambda-list &body body) > @@ -4949,15 +4949,18 @@ > (let* ((pathname (funcall *pathnames-generator*)) > (class-file (make-class-file :pathname pathname > :lambda-list lambda-list))) > - (set-compiland-and-write-class-file class-file compiland) > + (with-open-class-file (f class-file) > + (set-compiland-and-write-class class-file compiland f)) > (setf (local-function-class-file local-function) class-file))) > (t > - (with-temp-class-file > - pathname class-file lambda-list > - (set-compiland-and-write-class-file class-file compiland) > + (let ((class-file (make-class-file > + :pathname (funcall *pathnames-generator*) > + :lambda-list lambda-list))) > + (with-open-stream (stream (sys::%make-byte-array-output-stream)) > + (set-compiland-and-write-class class-file compiland stream) > (setf (local-function-class-file local-function) class-file) > (setf (local-function-function local-function) > - (load-compiled-function pathname))))))) > + (load-compiled-function (sys::%get-output-stream-bytes stream))))))))) > > (defun emit-make-compiled-closure-for-labels > (local-function compiland declaration) > @@ -4981,19 +4984,24 @@ > (let* ((pathname (funcall *pathnames-generator*)) > (class-file (make-class-file :pathname pathname > :lambda-list lambda-list))) > - (set-compiland-and-write-class-file class-file compiland) > + (with-open-class-file (f class-file) > + (set-compiland-and-write-class class-file compiland f)) > (setf (local-function-class-file local-function) class-file) > (let ((g (declare-local-function local-function))) > (emit-make-compiled-closure-for-labels > local-function compiland g)))) > (t > - (with-temp-class-file > - pathname class-file lambda-list > - (set-compiland-and-write-class-file class-file compiland) > + (let ((class-file (make-class-file > + :pathname (funcall *pathnames-generator*) > + :lambda-list lambda-list))) > + (with-open-stream (stream (sys::%make-byte-array-output-stream)) > + (set-compiland-and-write-class class-file compiland stream) > (setf (local-function-class-file local-function) class-file) > - (let ((g (declare-object (load-compiled-function pathname)))) > + (let ((g (declare-object > + (load-compiled-function > + (sys::%get-output-stream-bytes stream))))) > (emit-make-compiled-closure-for-labels > - local-function compiland g))))))) > + local-function compiland g)))))))) > > (defknown p2-flet-node (t t t) t) > (defun p2-flet-node (block target representation) > @@ -5041,7 +5049,8 @@ > (make-class-file :pathname (funcall *pathnames-generator*) > :lambda-list lambda-list)) > (let ((class-file (compiland-class-file compiland))) > - (compile-and-write-to-file class-file compiland) > + (with-open-class-file (f class-file) > + (compile-and-write-to-stream class-file compiland f)) > (emit 'getstatic *this-class* > (declare-local-function (make-local-function :class-file > class-file)) > @@ -5051,14 +5060,13 @@ > (setf (compiland-class-file compiland) > (make-class-file :pathname pathname > :lambda-list lambda-list)) > - (unwind-protect > - (progn > - (compile-and-write-to-file (compiland-class-file compiland) > - compiland) > - (emit 'getstatic *this-class* > - (declare-object (load-compiled-function pathname)) > - +lisp-object+)) > - (delete-file pathname))))) > + (with-open-stream (stream (sys::%make-byte-array-output-stream)) > + (compile-and-write-to-stream (compiland-class-file compiland) > + compiland stream) > + (emit 'getstatic *this-class* > + (declare-object (load-compiled-function > + (sys::%get-output-stream-bytes stream))) > + +lisp-object+))))) > (cond ((null *closure-variables*)) ; Nothing to do. > ((compiland-closure-register *current-compiland*) > (duplicate-closure-array *current-compiland*) > @@ -8030,7 +8038,14 @@ > (setf (compiland-arity compiland) arg-count) > (get-descriptor (list +lisp-object-array+) +lisp-object+))))) > > -(defun write-class-file (class-file) > +(defmacro with-open-class-file ((var class-file) &body body) > + `(with-open-file (,var (class-file-pathname ,class-file) > + :direction :output > + :element-type '(unsigned-byte 8) > + :if-exists :supersede) > + ,@body)) > + > +(defun write-class-file (class-file stream) > (let* ((super (class-file-superclass class-file)) > (this-index (pool-class (class-file-class class-file))) > (super-index (pool-class super)) > @@ -8045,43 +8060,39 @@ > (when (and (boundp '*source-line-number*) > (fixnump *source-line-number*)) > (pool-name "LineNumberTable")) ; Must be in pool! > - > - ;; Write out the class file. > - (with-open-file (stream (class-file-pathname class-file) > - :direction :output > - :element-type '(unsigned-byte 8) > - :if-exists :supersede) > - (write-u4 #xCAFEBABE stream) > - (write-u2 3 stream) > - (write-u2 45 stream) > - (write-constant-pool stream) > - ;; access flags > - (write-u2 #x21 stream) > - (write-u2 this-index stream) > - (write-u2 super-index stream) > - ;; interfaces count > - (write-u2 0 stream) > - ;; fields count > - (write-u2 (length *fields*) stream) > - ;; fields > - (dolist (field *fields*) > - (write-field field stream)) > - ;; methods count > - (write-u2 (1+ (length (class-file-methods class-file))) stream) > - ;; methods > - (dolist (method (class-file-methods class-file)) > - (write-method method stream)) > - (write-method constructor stream) > - ;; attributes count > - (cond (*file-compilation* > - ;; attributes count > - (write-u2 1 stream) > - ;; attributes table > - (write-source-file-attr (file-namestring *compile-file-truename*) > - stream)) > - (t > - ;; attributes count > - (write-u2 0 stream)))))) > + > + (write-u4 #xCAFEBABE stream) > + (write-u2 3 stream) > + (write-u2 45 stream) > + (write-constant-pool stream) > + ;; access flags > + (write-u2 #x21 stream) > + (write-u2 this-index stream) > + (write-u2 super-index stream) > + ;; interfaces count > + (write-u2 0 stream) > + ;; fields count > + (write-u2 (length *fields*) stream) > + ;; fields > + (dolist (field *fields*) > + (write-field field stream)) > + ;; methods count > + (write-u2 (1+ (length (class-file-methods class-file))) stream) > + ;; methods > + (dolist (method (class-file-methods class-file)) > + (write-method method stream)) > + (write-method constructor stream) > + ;; attributes count > + (cond (*file-compilation* > + ;; attributes count > + (write-u2 1 stream) > + ;; attributes table > + (write-source-file-attr (file-namestring *compile-file-truename*) > + stream)) > + (t > + ;; attributes count > + (write-u2 0 stream))) > + stream)) > > (defknown p2-compiland-process-type-declarations (list) t) > (defun p2-compiland-process-type-declarations (body) > @@ -8359,7 +8370,7 @@ > (push execute-method (class-file-methods class-file))) > t) > > -(defun compile-1 (compiland) > +(defun compile-1 (compiland stream) > (let ((*all-variables* nil) > (*closure-variables* nil) > (*undefined-variables* nil) > @@ -8393,8 +8404,7 @@ > ;; Pass 2. > (with-class-file (compiland-class-file compiland) > (p2-compiland compiland) > - (write-class-file (compiland-class-file compiland))) > - (class-file-pathname (compiland-class-file compiland))))) > + (write-class-file (compiland-class-file compiland) stream))))) > > (defvar *compiler-error-bailout*) > > @@ -8402,7 +8412,7 @@ > `(lambda ,(cadr form) > (error 'program-error :format-control "Execution of a form compiled with errors."))) > > -(defun compile-defun (name form environment filespec) > +(defun compile-defun (name form environment filespec stream) > (aver (eq (car form) 'LAMBDA)) > (catch 'compile-defun-abort > (let* ((class-file (make-class-file :pathname filespec > @@ -8415,13 +8425,15 @@ > :class-file > (make-class-file :pathname ,filespec > :lambda-name ',name > - :lambda-list (cadr ',form)))))) > + :lambda-list (cadr ',form))) > + ,stream))) > (*compile-file-environment* environment)) > (compile-1 (make-compiland :name name > :lambda-expression > (precompiler:precompile-form form t > environment) > - :class-file class-file))))) > + :class-file class-file) > + stream)))) > > (defvar *catch-errors* t) > > @@ -8517,11 +8529,22 @@ > (tempfile (make-temp-file))) > (with-compilation-unit () > (with-saved-compiler-policy > - (unwind-protect > - (setf compiled-function > - (load-compiled-function > - (compile-defun name expr env tempfile)))) > - (delete-file tempfile))) > + (setf compiled-function > + (load-compiled-function > + (if *file-compilation* > + (unwind-protect > + (progn > + (with-open-file (f tempfile > + :direction :output > + :element-type '(unsigned-byte 8) > + :if-exists :supersede) > + (compile-defun name expr env tempfile f)) > + tempfile) > + (delete-file tempfile)) > + (with-open-stream (s (sys::%make-byte-array-output-stream)) > + (compile-defun name expr env tempfile s) > + (finish-output s) > + (sys::%get-output-stream-bytes s))))))) > (when (and name (functionp compiled-function)) > (sys::set-function-definition name compiled-function definition)) > (or name compiled-function))) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

3 3

Re: [armedbear-devel] [j-devel] regression
by Erik Huelsmann 15 Oct '09

15 Oct '09

On Thu, Oct 15, 2009 at 2:21 PM, Alan Ruttenberg <alanruttenberg(a)gmail.com> wrote: > On Thu, Oct 15, 2009 at 5:50 AM, Erik Huelsmann <ehuels(a)gmail.com> wrote: >> Hi Alan, >> >> On Thu, Oct 15, 2009 at 5:53 AM, Alan Ruttenberg >> <alanruttenberg(a)gmail.com> wrote: >>> I'm sorry about this bug report. Basically, a system I've been working >>> with for a long time has ceased to function in odd ways. I suspect it >>> has to do with exception handling changes recently introduced because >>> the symptom seems to be that a java function that I call that has a >>> timeout function continues to run even after the timeout is supposed >>> to have happened. >> >> Are you talking about ABCL? Or about something else? Which version of >> ABCL? Trunk? 0.16? > > Both it appears. The java code being called is from the pellet > reasoner, which has timers which it checks while it does it's work, > and when they are exceeded it throws the exception. Ok. The most helpful would be a version number (or repository revision number) which starts failing. >> Could you provide a bit more information on what the code is doing? One of the things I mean to ask here: are you calling the lisp code from the EVAL function? Or straight SYMBOL.execute() calls? >>> Unfortunately working on isolating the bug isn't something I have time >>> for so I've had to revert back to an earlier version. >>> >>> Wish I could say more at this point, but perhaps just notice that this >>> is happening might ring a bell for someone. >> >> If you're not talking about J, but specifically about ABCL, then, no, >> no bell yet. However, I'd like to look into it, ofcourse. > > abcl. I'll try to narrow it when I have some time. Thanks! Bye, Erik.

1 0

[armedbear-devel] CLOS optimizations
by Erik Huelsmann 15 Oct '09

15 Oct '09

This weekend, I committed an optimization which shows 4 - 12% performance gain on the CL-BENCH common lisp benchmarking toolset tests for CLOS. However, the test collects performance results from a high number of invocations. Low numbers of invocations should show even better improvements. Profiling one of the performance tests for CL-BENCH which shows huge difference with CLISP, it turned out that our CHECK-INITARGS function in the MOP package is taking 40% of the object instantiation time consumed by MAKE-INSTANCE. After the first invocation, it's possible to replace this function by a lookup in a cache. The same applies to args checking for some of the other functions defined to object instantiation and class modification. However, the time required to build this into our CLOS in a structured manner, exceeds "just" a few evenings, meaning that I probably will be delaying this task until I have a more time to undertake this effort. Ofcourse, I remain on the look out for possibilities to increase the performance of our clos implementation. An important input are the issues you experience with our performance, especially if you have example code to demonstrate it. Bye, Erik.

3 4

[armedbear-devel] Implementing non local exits in a runtime with structured exception handling
by Matthew D. Swank 15 Oct '09

15 Oct '09

I am playing with a lisp dialect (at least in my head) that I am thinking about implementing on the CLR. Like Java the CLR requires jumps across method call boundaries to be done using the exception handling mechanism. If I have code like the following in abcl: (block foo (flet ((callback () (return-from foo t))) (something-that-calls-into-java #'callback) ... stuff that won't happen if the callback is invoked)) And the plain old Java I'm calling into is pathological and catches the exception raised by calling the callback without re-throwing it, the non-local return never happens. Is that correct? If so, is there no way around it? Matt -- "You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein.

2 1

[armedbear-devel] Java callbacks
by Alessio Stalla 14 Oct '09

14 Oct '09

Hello, I was thinking about the integration of lisp and java with abcl and it struck me that we don't have an easy way to pass a callback from Java to Lisp (e.g. a function acting as a factory of objects): one can extend Function, Primitive or even LispObject and implement the appropriate execute() method overload; however, one must perform conversion to/from Lisp objects manually, and while this is a minor inconvenience, it adds boilerplate code that could be easily avoided. So I was thinking about adding a Callback class extending Function, with overloads for execute() taking and returning regular java.lang.Object instances, and corresponding execute() based on LispObjects that perform the necessary conversions and call the Java-friendly versions. Example: public LispObject execute(LispObject arg0) { return JavaObject.getInstance(execute(arg0.javaInstance())); } /** To be overridden by the implementing subclass */ protected Object execute(Object arg0) { return error(new WrongNumberOfArgumentsException(this)); } Such a class could have convenience factory methods taking Runnables, Callables and other popular kinds of Java callback objects. Thoughts? Ale

2 2

Re: [armedbear-devel] [armedbear-cvs] r12183 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 10 Oct '09

10 Oct '09

Mark, The commit below should enable the use of Gray streams with ABCL. I think this means SLIME can now switch to its normal pattern of using Gray streams to wrap its input and output processors. At least, I'd like to remove the SlimeInputStream and SlimeOutputStream Java classes and move the problem to SLIME, if that's possible. Maybe I want to do the same thing for socket streams. Bye, Erik. On Fri, Oct 9, 2009 at 11:31 PM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Fri Oct 9 17:31:50 2009 > New Revision: 12183 > > Log: > Fix last Gray stream incompatibilities: generic functions > overlapping with CL functions are no longer have the STREAM- prefix. > > Note: this commit also removes gray stream testing code which does > not belong in the "production" image of our software. > > Modified: > trunk/abcl/src/org/armedbear/lisp/gray-streams.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/gray-streams.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/gray-streams.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/gray-streams.lisp Fri Oct 9 17:31:50 2009 > @@ -94,25 +94,7 @@ > ;;;; > ;;;; Notes > ;;;; ===== > -;;;; CLOSE is not a generic function in this implementation. Instead, > -;;;; the generic is called STREAM-CLOSE and the function CLOSE calls > -;;;; STREAM-CLOSE. The same goes for STREAMP, INPUT-STREAM-P, > -;;;; OUTPUT-STREAM-P and STREAM-ELEMENT-TYPE. The generic functions for > -;;;; these are STREAM-STREAMP, STREAM-INPUT-STREAM-P, > -;;;; STREAM-OUTPUT-STREAM-P and STREAM-STREAM-ELEMENT-TYPE. > ;;;; > -;;;; The standard Corman Lisp streams are not derived from > -;;;; FUNDAMENTAL-STREAM. All the stream functions check to see if the > -;;;; stream is an original Corman Lisp stream and forward on to the > -;;;; original function implementations. > -;;;; > -;;;; The string streams are implemented in this file as Gray streams > -;;;; but do not replace the Corman Lisp string streams. They are only > -;;;; implemented here to test the Gray stream functionality. These methods > -;;;; are called: > -;;;; GRAY-MAKE-STRING-OUTPUT-STREAM > -;;;; GRAY-GET-OUTPUT-STREAM-STRING > -;;;; GRAY-MAKE-STRING-INPUT-STREAM > ;;;; > ;;;; Much of the implementation of the Gray streams below is from the > ;;;; document referenced earlier. > @@ -123,7 +105,6 @@ > (:nicknames "GS") ;; # fb 1.01 > (:export > "FUNDAMENTAL-STREAM" > - "STREAM-CLOSE" > "STREAM-OPEN-STREAM-P" > "STREAM-STREAMP" > "STREAM-INPUT-STREAM-P" > @@ -200,21 +181,14 @@ > > (defclass fundamental-stream ()) > > -(defgeneric stream-close (stream &key abort)) > -(defgeneric stream-open-stream-p (stream)) > -(defgeneric stream-streamp (stream)) > -(defgeneric stream-input-stream-p (stream)) > -(defgeneric stream-input-character-stream-p (stream)) ;; # fb 1.01 > -(defgeneric stream-output-stream-p (stream)) > -(defgeneric stream-stream-element-type (stream)) > +(defgeneric gray-close (stream &key abort)) > +(defgeneric gray-open-stream-p (stream)) > +(defgeneric gray-streamp (stream)) > +(defgeneric gray-input-stream-p (stream)) > +(defgeneric gray-input-character-stream-p (stream)) ;; # fb 1.01 > +(defgeneric gray-output-stream-p (stream)) > +(defgeneric gray-stream-element-type (stream)) > > -(defmethod stream-close (stream &key abort) > - (declare (ignore stream abort)) > - nil) > - > -(defmethod stream-streamp (s) > - (declare (ignore s)) > - nil) > > (defmethod stream-streamp ((s fundamental-stream)) > s) > @@ -225,20 +199,12 @@ > (and (stream-input-stream-p s) > (eq (stream-stream-element-type s) 'character))) > > -(defmethod stream-input-stream-p (s) > - (declare (ignore s)) > - nil) > - > (defmethod stream-input-stream-p ((s fundamental-input-stream)) > (declare (ignore s)) > t) > > (defclass fundamental-output-stream (fundamental-stream)) > > -(defmethod stream-output-stream-p (s) > - (declare (ignore s)) > - nil) > - > (defmethod stream-output-stream-p ((s fundamental-output-stream)) > (declare (ignore s)) > t) > @@ -539,72 +505,6 @@ > (funcall *old-write-byte* integer binary-output-stream) > (stream-write-byte binary-output-stream integer))) > > -(defclass string-input-stream (fundamental-character-input-stream) > - ((string :initarg :string :type string) > - (index :initarg :start :type fixnum) > - (end :initarg :end :type fixnum))) > - > -(defun gray-make-string-input-stream (string &optional (start 0) end) > - (make-instance 'string-input-stream :string string > - :start start :end (or end (length string)))) > - > -(defmethod stream-read-char ((stream string-input-stream)) > - (with-slots (index end string) stream > - (if (>= index end) > - :eof > - (prog1 > - (char string index) > - (incf index))))) > - > -(defmethod stream-unread-char ((stream string-input-stream) character) > - (with-slots (index end string) stream > - (decf index) > - (assert (eql (char string index) character)) > - nil)) > - > -(defmethod stream-read-line ((stream string-input-stream)) > - (with-slots (index end string) stream > - (let* ((endline (position #\newline string :start index :end end)) > - (line (subseq string index endline))) > - (if endline > - (progn > - (setq index (1+ endline)) > - (values line nil)) > - (progn > - (setq index end) > - (values line t)))))) > - > -(defclass string-output-stream (fundamental-character-output-stream) > - ((string :initform nil :initarg :string))) > - > -(defun gray-make-string-output-stream () > - (make-instance 'string-output-stream)) > - > -(defun gray-get-output-stream-string (stream) > - (with-slots (string) stream > - (if (null string) > - "" > - (prog1 > - (coerce string 'string) > - (setq string nil))))) > - > -(defmethod stream-write-char ((stream string-output-stream) character) > - (with-slots (string) stream > - (when (null string) > - (setq string (make-array 64 :slement-type 'character > - :fill-pointer 0 :adjustable t))) > - (vector-push-extend character string) > - character)) > - > -(defmethod stream-line-column ((stream string-output-stream)) > - (with-slots (string) stream > - (if (null string) > - 0 > - (let ((nx (position #\newline string :from-end t))) > - (if (null nx) > - (length string) > - (- (length string) nx 1)))))) > - > (defmethod stream-line-column ((stream stream)) > nil) > > @@ -614,40 +514,26 @@ > nil ;(funcall *old-stream-column* stream) > (stream-line-column stream)))) > > -(defun gray-stream-element-type (stream) > - (if (old-streamp stream) > - (funcall *old-stream-element-type* stream) > - (stream-stream-element-type stream))) > +(defmethod gray-stream-element-type (stream) > + (funcall *old-stream-element-type* stream)) > > -(defun gray-close (stream &key abort) > - (if (old-streamp stream) > - (funcall *old-close* stream :abort abort) > - (stream-close stream :abort nil))) > +(defmethod gray-close (stream &key abort) > + (funcall *old-close* stream :abort abort)) > > -(defun gray-input-stream-p (stream) > - (if (old-streamp stream) > - (funcall *old-input-stream-p* stream) > - (stream-input-stream-p stream))) > +(defmethod gray-input-stream-p (stream) > + (funcall *old-input-stream-p* stream)) > > -(defun gray-input-character-stream-p (stream) > - (if (old-streamp stream) > - (funcall *old-input-character-stream-p* stream) > - (stream-input-character-stream-p stream))) > +(defmethod gray-input-character-stream-p (stream) > + (funcall *old-input-character-stream-p* stream)) > > -(defun gray-output-stream-p (stream) > - (if (old-streamp stream) > - (funcall *old-output-stream-p* stream) > - (stream-output-stream-p stream))) > +(defmethod gray-output-stream-p (stream) > + (funcall *old-output-stream-p* stream)) > > -(defun gray-open-stream-p (stream) > - (if (old-streamp stream) > - (funcall *old-open-stream-p* stream) > - (stream-open-stream-p stream))) > +(defmethod gray-open-stream-p (stream) > + (funcall *old-open-stream-p* stream)) > > -(defun gray-streamp (stream) > - (if (old-streamp stream) > - (funcall *old-streamp* stream) > - (stream-streamp stream))) > +(defmethod gray-streamp (stream) > + (funcall *old-streamp* stream)) > > (defun gray-write-sequence (sequence stream &key (start 0) end) > (if (old-streamp stream) > @@ -659,24 +545,6 @@ > (funcall *old-read-sequence* sequence stream :start start :end end) > (stream-read-sequence stream sequence start end))) > > -(defstruct two-way-stream-g > - input-stream output-stream) > - > -(defun gray-make-two-way-stream (in out) > - (if (and (old-streamp in) (old-streamp out)) > - (funcall *old-make-two-way-stream* in out) > - (make-two-way-stream-g :input-stream in :output-stream out))) > - > -(defun gray-two-way-stream-input-stream (stream) > - (if (old-streamp stream) > - (funcall *old-two-way-stream-input-stream* stream) > - (two-way-stream-g-input-stream stream))) > - > -(defun gray-two-way-stream-output-stream (stream) > - (if (old-streamp stream) > - (funcall *old-two-way-stream-output-stream* stream) > - (two-way-stream-g-output-stream stream))) > - > (setf (symbol-function 'common-lisp::read-char) #'gray-read-char) > (setf (symbol-function 'common-lisp::peek-char) #'gray-peek-char) > (setf (symbol-function 'common-lisp::unread-char) #'gray-unread-char) > @@ -703,8 +571,5 @@ > (setf (symbol-function 'common-lisp::streamp) #'gray-streamp) > (setf (symbol-function 'common-lisp::read-sequence) #'gray-read-sequence) > (setf (symbol-function 'common-lisp::write-sequence) #'gray-write-sequence) > -(setf (symbol-function 'common-lisp::make-two-way-stream) #'gray-make-two-way-stream) > -(setf (symbol-function 'common-lisp::two-way-stream-input-stream) #'gray-two-way-stream-input-stream) > -(setf (symbol-function 'common-lisp::two-way-stream-output-stream) #'gray-two-way-stream-output-stream) > > (provide 'gray-streams) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

3 3

[armedbear-devel] bug with initialize-instance and keyword arguments
by Steve Rolls 09 Oct '09

09 Oct '09

This is present in 0.16 and latest from svn, but not in 0.15. Specifying a keyword arg in an initialize-instance method does not make the keyword a valid initarg for make-instance. Armed Bear Common Lisp 0.16.0 Java 1.6.0_12 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.425 seconds. Startup completed in 2.086 seconds. Type ":help" for a list of available commands. CL-USER(1): (defclass c1() (x)) #<STANDARD-CLASS C1 {5A347448}> CL-USER(2): (defmethod initialize-instance :after ((c c1) &key x2) (setf (slot-value c 'x) x2)) #<STANDARD-METHOD INITIALIZE-INSTANCE :AFTER (C1) {79A1EA46}> CL-USER(3): (make-instance 'c1 :x2 1) Debugger invoked on condition of type PROGRAM-ERROR: Invalid initarg :X2. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(4): Works as expected in 0.15 Armed Bear Common Lisp 0.15.0 Java 1.6.0_12 Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM Low-level initialization completed in 0.45 seconds. Startup completed in 2.021 seconds. Type ":help" for a list of available commands. CL-USER(1): (defclass c1() (x)) #<STANDARD-CLASS C1 {615E7597}> CL-USER(2): (defmethod initialize-instance :after ((c c1) &key x2) (setf (slot-value c 'x) x2)) #<STANDARD-METHOD INITIALIZE-INSTANCE :AFTER (C1) {7346B111}> CL-USER(3): (make-instance 'c1 :x2 1) #<C1 {772EDF9A}> CL-USER(4):

3 8

[armedbear-devel] No :DARWIN, "No tag" & no ASDF
by John Pallister 06 Oct '09

06 Oct '09

Hello list, I'm inching my way towards working with ABCL (stupid day job) and I thought I'd mention a few things that have cropped up. I'm running on OS X 10.5.8 using the OpenJDK 6 (for JSR-223, and the server VM). I updated the source from the SVN repo this morning. When I build ABCL, I get the warning "Use of Java version 1.6.0-internal not recommended." Perhaps '<matches string="${java.version}" pattern="1\.6\.0-internal"/>' could be added to the appropriate spot in build.xml to suppress this warning. When I run ABCL, I get :JAVA-1.6 in *FEATURES* but not :DARWIN (or any other OS identifier). (*FEATURES* is (:DARWIN :JAVA-1.6 :ARMEDBEAR :ABCL :COMMON-LISP :ANSI-CL :CDR6). What's :CDR6?) When my '(load ".../start-swank.lisp")' fails, I get an error when I enter ':cont 0': shadow:abcl john$ ./abcl Armed Bear Common Lisp 0.17.0-dev Java 1.6.0-internal Sun Microsystems Inc. OpenJDK Server VM Low-level initialization completed in 1.699 seconds. Startup completed in 8.5 seconds. [on my Dell Mini 9, not real Apple h/w] Type ":help" for a list of available commands. CL-USER(1): (load "/Users/john/src/lisp/abcl/start-swank.lisp") Error loading /Users/john/src/lisp/asdf/asdf.lisp at line 193 (offset 7111) Debugger invoked on condition of type SIMPLE-ERROR: The long form of DEFINE-METHOD-COMBINATION is not implemented. Restarts: 0: TOP-LEVEL Return to top level. [1] ASDF(2): :cont 0 Debugger invoked on condition of type CONTROL-ERROR: No tag named #:G140089 is currently visible Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(3): :res CL-USER(4): Which brings me to the last problem: asdf.lisp won't load, since it uses the long form of DEFINE-METHOD-COMBINATION. Is there a workaround for this? If anyone can shed some light on these issues, that would be great. As an aside, does anyone want to share their .emacs settings for Java development? I've installed JDE (which was a PITA FWIW), CC-Mode etc. and I'm curious as to what other (Emacs-minded) people are using. Cheers, John :^P -- John Pallister john(a)johnp.net john(a)synchromesh.com

5 13

Re: [armedbear-devel] [armedbear-cvs] r12153 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 06 Oct '09

06 Oct '09

Hi Mark, On Fri, Sep 18, 2009 at 3:43 PM, Mark Evenson <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Fri Sep 18 09:43:42 2009 > New Revision: 12153 > > Log: > Tenative fix for #63: transform caught Go throwable to LispError. > > Normalized printStackTrace() calls through Debug.trace() interface. > > > > Modified: > trunk/abcl/src/org/armedbear/lisp/Lisp.java > > Modified: trunk/abcl/src/org/armedbear/lisp/Lisp.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/Lisp.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/Lisp.java Fri Sep 18 09:43:42 2009 > @@ -123,7 +123,7 @@ > } > catch (Throwable t) > { > - t.printStackTrace(); > + Debug.trace(t); > } > } > > @@ -277,7 +277,7 @@ > } > catch (Go go) > { > - throw go; > + return error(go.getCondition()); > } > catch (Throw t) > { This hunk causes "havoc" with the command line interface where people select the "go to toplevel" restart. I think this is the major change in this commit? If I want to revert this bit, do I have to revert the rest too, or are those just improvements on what was already there? BTW: With my recent changes, I don't think there's anything wrong with re-throwing the Go anymore: we check for a catching environment before throwing now. > @@ -1042,6 +1042,7 @@ > } > catch (Throwable t) > { > + Debug.trace(t); > return null; > } > } > @@ -2586,7 +2587,7 @@ > } > catch (ClassNotFoundException e) > { > - e.printStackTrace(); > + Debug.trace(e); > } > } > > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

2 1

[armedbear-devel] Fw: SparseChars patch
by logicmoo＠gmail.com 04 Oct '09

04 Oct '09

ABCL, Here is the SparseChars patch. It shouldn't pass more or less ANSI-TESTs. but will improve performance due to the fact it uses less java heap and copies less. The one thing I might do later is stop using the character iterator (CharHashMap would get a copyToOther(CharHashMap)).. but for now its sane.

2 1

[armedbear-devel] Making tags (in tagbody) and block names unique
by Erik Huelsmann 29 Sep '09

29 Sep '09

On IRC, we had a discussion some days ago where it was found that ABCL doesn't use unique tag-identifications in tagbody, leading to somewhat dynamically scoped tagbodies, instead of perfectly lexically scoped. BLOCK also uses non-unique names (think NIL), leading to the same issue. Both the compiler and the interpreter exhibit the problem. Consider the following code: (labels ((p (b) (tagbody (if (not b) (p #'(lambda () (go :foo))) (funcall b)) (return-from p :bar) :foo (return-from p :foo)))) (p nil)) It should return :foo, but returns :bar on ABCL's interpreter instead. (The fact that the compiler works, means there's probably a bug in it somewhere, because there's no explanation why it would.) I'm now thinking of ways to make the tags/blocknames unique. The one way I could come up with for the interpreter is this: Adding a second identifier (created using "new Object();") to the blocks and tags registered in the interpreter environment. Then, when a Go or Return is thrown, it should include the identifier. The catching tagbodies and blocks can verify that the Go or Return is meant for that block by checking the identifier. The approach above requires an additional "identifier" field in the Binding object. For the compiler, this could work similarly, except that the identifier can't be stored in the environment (because there is none), meaning it should probably be stored in a closure variable which any throwing function can then use when creating the Go or Return object. Any comments? Bye, Erik.

1 2

[armedbear-devel] Performance of ABCL?
by Žiga Lenarčič 27 Sep '09

27 Sep '09

Hi! I've tested Maxima with ABCL. While it runs, which is rather cool, it's fairly slow! On my computer (with -server) Maxima on ABCL is about 10x - 20x slower than SBCL for various operations in Maxima (and using 3-4x more RAM). I don't know much about implementation details - but as far as I know, every lisp object is encapsulated in a Java object, so there is a lot of allocation going on. Compiler is also very slow (compared to SBCL). My question is, is performance ever increase dramatically (perhaps with java 7?) or is ABCL inherently slower because of the JVM? Clojure performs better than ABCL usually and is also running on JVM. I don't know about KAWA. Is JVM bytecode not flexible enough to perhaps reuse some compilation techniques of native compilers (CCL, SBCL) ? I was thinking about writing a GUI for maxima in java, using ABCL to run Maxima. This way the gui could interact directly with the lisp functions of Maxima. But the main advantage of Maxima is IMO that it can be easily extended via Lisp, which can compile to near C speed on native compilers such as SBCL and CCL. Using ABCL (if it is as slow as it is now), this would not be true and the only fast extensions to Maxima could be written in Java perhaps, which is fine, but is not portable to other CLs and Java code is verbose. Regards, Ziga

6 6

[armedbear-devel] Ugh! java.lang.OutOfMemoryError: PermGen space
by Alessio Stalla 26 Sep '09

26 Sep '09

(dotimes (i 100000) (compile 'f (lambda () 42))) abcl dies with java.lang.OutOfMemoryError: PermGen space if I use nil instead of f it doesn't die. Also with nil is noticeably faster. Adding (when (= 999 (mod i 1000)) (room)) in the loop shows that gc is performed and memory is reclaimed, but apparently there's a leak somewhere. I'll try to find out more. Later, Ale

2 2

[armedbear-devel] In-memory compilation!
by Alessio Stalla 26 Sep '09

26 Sep '09

Hello list, I managed to get temp-file-less compilation with COMPILE working. And the hilarious things is: the classloader experiment was not necessary for this, as the compiler already behaved differently according the the value of *file-compilation*, and the use of loadCompiledFunction that troubled me was only done for the file compiler! So it's sufficient to move file creation from inner functions to outer ones and to pass an additional stream parameter to inner functions. Things can be made clearer - now the structure used to represent compilation results, class-file, is required to always have a pathname set, even when no file is created, for example. But I believe we're on the right track. I cannot provide a patch now because I have still have to clean up the classloader changes. Btw I believe that the use of classloaders is a good thing even if it's not used for memory compilation (for one thing, it would play nicer with serialization of lisp functions, if we ever want that). Cheers, Ale

1 1

[armedbear-devel] Some thoughts on classloaders, inner classes and in-memory compilation
by Alessio Stalla 24 Sep '09

24 Sep '09

Hello folks, I'd like to share some thoughts on the "usual" problem of in-memory compilation in abcl. I haven't written any code to support my thoughts - I just hope to make things clearer for me and other people on the list, and I'm asking you to share your ideas and comment mine. Warning - this is going to be a long post. Let's start by describing how abcl works now. Every piece of code in the JVM needs to be contained in a method of some class, so when abcl compiles a function it produces - surprise - a class, or better, a stream of bytes that the JVM knows how to interpret to create a class. Classes produced by the compiler extend a common abcl class providing the methods that will be used to actually invoke the function; the compiler, among other things, will override some of those methods. When using the runtime compiler, the class is immediately loaded; when using the file compiler, it is stored on the filesystem for later use. So far, nothing requires temporary files to work. However, a Lisp function can contain nested functions introduced with FLET or LABELS, and those have to be compiled to classes as well. Also, they need to be loaded contextually with the main function. How does abcl solve this? By adding instructions in the main class to load the local functions when the class itself is loaded, relatively to where it is loaded from. And here lies the problem. That location is always assumed to be a file in some filesystem subtree. So even when using the runtime compiler all the classes must be, at least temporarily, stored in files for the load machinery to work. Changing this is hard; classes are resolved from strings, how do know when a given string represents a file and when it represents some object in memory instead? There are workarounds, but I think it's the approach itself that's brittle. So let's step back a bit and take a look at how the JVM and Java the language work with respect to loading classes. The JVM uses dedicated objects called classloaders. They are responsible of translating from a class' symbolic name (a string) to a class metaobject, much like the CLOS find-class function does. Classloaders are organized hierarchically: every classloader has a parent which is first consulted to see if it already has the class (there is of course a built-in bootstrap classloader to break the circularity); if it has, it returns it, if it hasn't, it is loaded in a manner dependent to the particular classloader (e.g. from a file, from http, from memory, ...). The process of loading a class from a byte array is native in the JVM, so classloaders only get to decide where the byte array comes from and what it contains. Now to the more interesting things: 1. A class never exists in isolation; to do its work it will need to refer to other classes (at a bare minimum, its superclass and any interface it implements). The JVM - automatically! - uses the same classloader to load a class and, at linking time, all of its dependencies. 2. If I had to manually redo in Java what the abcl compiler does with functions, I'd use static inner classes to represent local functions. Inner classes are classes which are textually defined inside another class and share some data with it. Inner classes do not exist at the bytecode level, only at the Java language level: the compiler (javac) translates them to regular classes, with their name mangled. For example, a class Inner defined inside a class Outer will be referred to Outer.Inner in Java, but compiled to Outer$Inner.class by javac. 3. Inner classes then are treated exactly like the others: referred using strings inside code, resolved by a classloader (generally - always? - by the classloader of the containing class). Return to abcl. As you may have guessed, I propose that we no longer make classes autoload their dependencies, but properly use classloaders instead, in a fashion similar to how inner classes work. We will have an InMemoryClassLoader which will load classes from a Map<String, byte[]>, and a slightly extended URLClassLoader to load classes from the filesystem. Both, in addition to load classes, will be used by the compiler to write classes as well, so it will continue to use the class-file abstraction, changing only the code that actually writes the bytes. Every time the compiler would have written a call to loadCompiledFunction(classname) it will now use something like functionFoo.class.getClassLoader().loadClass(classname) where functionFoo is the compiler-generated name of the class representing the compiled Lisp function. Everything else should stay the same. Does this sound convincing? I admit I have left many things to elaborate on, and I haven't rehashed the code in the compiler, going mainly from memory instead. But I believe this approach has not been proposed before and looks doable. The next few days I'll try writing some sketch code to back up my ideas, if no-one finds any serious problem with them. Peace, Alessio

7 23

[armedbear-devel] [BUG] SET-SYNTAX-FROM-CHAR should clear dispatch tables
by Tobias C. Rittweiler 22 Sep '09

22 Sep '09

(let ((rt (copy-readtable nil))) (set-syntax-from-char #\# #\A rt (copy-readtable nil)) (get-dispatch-macro-character #\# #\x rt)) should signal an error as #\# is no longer a dispatching macro character. -T.

1 0

[armedbear-devel] packaging external libs with abcl
by Matthew D. Swank 21 Sep '09

21 Sep '09

I've been messing with running abcl on the google appengine, and I was wondering what was the best way to package libraries, especially the results of loading an asdf system and its dependencies? Thanks, Matt -- "You do not really understand something unless you can explain it to your grandmother." -- Albert Einstein.

3 8

[armedbear-devel] Bug: Attempt to GO to a tag whose extent has ended quits ABCL
by Brian Mastenbrook 21 Sep '09

21 Sep '09

When attempting to GO to a tag whose dynamic extent has ended, ABCL quits and prints the name of the exception used for internally handling GO (org.armedbear.lisp.Go). I see the same behavior in compiled or interpreted code. CL-USER(1): (lisp-implementation-version) "0.16.0" CL-USER(2): (let ((f nil)) (tagbody (setf f (lambda () (go foo))) foo) (funcall f)) org.armedbear.lisp.Go abcl-src-0.16.0 chandler$ -- Brian Mastenbrook brian(a)mastenbrook.net http://brian.mastenbrook.net/

6 10

[armedbear-devel] [BUG] make-thread and :NAME nil
by Tobias C. Rittweiler 21 Sep '09

21 Sep '09

Not providing a :NAME parameter to MAKE-THREAD will currently fail: CL-USER(1): (threads:make-thread (constantly t)) Debugger invoked on condition of type TYPE-ERROR: The value NIL is not of type STRING. Funnily enough, explicitly providing NIL kind of works: CL-USER(2): (threads:make-thread (constantly t) :name nil) #<THREAD "NIL" {1EEB372}> But, as you can see, the passed NIL is taken as a string designator, but probably shouldn't. -T.

2 1

[armedbear-devel] Your NAMED-READTABLES test
by Erik Huelsmann 20 Sep '09

20 Sep '09

Hi Tobias, The named-readtables test you sent me, does show an obvious bug in ABCL, but not the one you're trying to point me at: when loading your files on Windows, I'm getting an Index out of bounds error: the dispatch tables think our characters range from 0 - 255 in value whereas in practice that number is much higher. I'm working on a fix right now (setting CHAR_MAX to a higher value) but I don't feel too comfortable with it: it'll make us consume much more memory on a number of things. However, what's a K of memory worth these days... ? Bye, Erik.

2 2

[armedbear-devel] JSR-223: Returning immutable lists in ScriptEngineFactory
by Clemens Blamauer 20 Sep '09

20 Sep '09

Hi everyone, I was looking through the JSR-223 code in org.armedbear.lisp.scripting as I noticed that AbclScriptEngineFactory is not fully compliant to JSR-223 [1] (p. 101-102 in the Final Draft Specification, v1.0). For the methods: - java.util.List<java.lang.String> getExtensions() - java.util.List<java.lang.String> getMimeTypes() - java.util.List<java.lang.String> getNames() _immutable_ Lists should be returned. Please find a remedying patch below. Cheerz, Clemens [1] http://jcp.org/en/jsr/detail?id=223 ---- Index: AbclScriptEngineFactory.java =================================================================== --- AbclScriptEngineFactory.java (revision 12157) +++ AbclScriptEngineFactory.java (working copy) @@ -21,6 +21,7 @@ package org.armedbear.lisp.scripting; import java.util.ArrayList; +import java.util.Collections; import java.util.List; import javax.script.ScriptEngine; @@ -44,7 +45,7 @@ public List<String> getExtensions() { List<String> extensions = new ArrayList<String>(1); extensions.add("lisp"); - return extensions; + return Collections.unmodifiableList(extensions); } @Override @@ -89,7 +90,7 @@ @Override public List<String> getMimeTypes() { - return new ArrayList<String>(); + return Collections.unmodifiableList(new ArrayList<String>()); } @Override @@ -99,7 +100,7 @@ names.add("cl"); names.add("Lisp"); names.add("Common Lisp"); - return names; + return Collections.unmodifiableList(names); } @Override -- # Trust in code: # lynx http://lxr.linux.no/linux+v2.6.23.14/arch/i386/kernel/cpu/common.c#L677

2 1

[armedbear-devel] [PATCH] incorporating java stack frames into backtrace
by Tobias C. Rittweiler 20 Sep '09

20 Sep '09

When evaluating (ext:make-thread #'(lambda ())) you get an error "The value NIL is not of type STRING." -- this is a bug in ABCL itself, by the way, but that's not the matter of this mail. The concern of this mail is the backtrace that'd you get: Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {B1A201}>) 1: (MAKE-THREAD #<FUNCTION (LAMBDA ()) {15343C2}>) 2: (SYSTEM::%EVAL (MAKE-THREAD #'(LAMBDA NIL))) 3: (EVAL (MAKE-THREAD #'(LAMBDA NIL))) ... The only thing the backtrace reveales is that the error was signalled somewhere in MAKE-THREAD. With the patch of this mail, the backtrace will also contain the relevant Java stack frames for errors that were signalled from within ABCL's Java runtime: Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {B1A201}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:375) 2: org.armedbear.lisp.Lisp.type_error(Lisp.java:390) 3: org.armedbear.lisp.LispObject.getStringValue(LispObject.java:1061) 4: org.armedbear.lisp.LispThread.<init>(LispThread.java:111) 5: org.armedbear.lisp.LispThread.<init>(LispThread.java:39) 6: org.armedbear.lisp.LispThread$3.execute(LispThread.java:909) 7: org.armedbear.lisp.Primitive.execute(Primitive.java:108) 8: (MAKE-THREAD #<FUNCTION (LAMBDA ()) {15343C2}>) 9: (SYSTEM::%EVAL (MAKE-THREAD #'(LAMBDA NIL))) 10: (EVAL (MAKE-THREAD #'(LAMBDA NIL))) Another example: (LENGTH 12) Backtrace: 0: (INVOKE-DEBUGGER #<TYPE-ERROR {814AF5}>) 1: org.armedbear.lisp.Lisp.error(Lisp.java:375) 2: org.armedbear.lisp.Lisp.type_error(Lisp.java:390) 3: org.armedbear.lisp.LispObject.length(LispObject.java:403) 4: org.armedbear.lisp.LispObject.LENGTH(LispObject.java:410) 5: org.armedbear.lisp.Primitives$24.execute(Primitives.java:427) 6: (LENGTH 12) 7: (SYSTEM::%EVAL (LENGTH 12)) 8: (EVAL (LENGTH 12)) -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

4 18

[armedbear-devel] JSR-223: Return immutable lists in ScriptEngineFactory
by Clemens Blamauer 20 Sep '09

20 Sep '09

Hi everyone, I was looking through the JSR-223 code in org.armedbear.lisp.scripting as I noticed that AbclScriptEngineFactory is not fully compliant to JSR-223 [1]. For the methods: - java.util.List<java.lang.String> getExtensions() - java.util.List<java.lang.String> getMimeTypes() - java.util.List<java.lang.String> getNames() _immutable_ Lists should be returned. Please find a remedying patch below. Cheerz, Clemens [1] http://jcp.org/en/jsr/detail?id=223 ---- Index: AbclScriptEngineFactory.java =================================================================== --- AbclScriptEngineFactory.java (revision 12157) +++ AbclScriptEngineFactory.java (working copy) @@ -21,6 +21,7 @@ package org.armedbear.lisp.scripting; import java.util.ArrayList; +import java.util.Collections; import java.util.List; import javax.script.ScriptEngine; @@ -44,7 +45,7 @@ public List<String> getExtensions() { List<String> extensions = new ArrayList<String>(1); extensions.add("lisp"); - return extensions; + return Collections.unmodifiableList(extensions); } @Override @@ -89,7 +90,7 @@ @Override public List<String> getMimeTypes() { - return new ArrayList<String>(); + return Collections.unmodifiableList(new ArrayList<String>()); } @Override @@ -99,7 +100,7 @@ names.add("cl"); names.add("Lisp"); names.add("Common Lisp"); - return names; + return Collections.unmodifiableList(names); } @Override

1 0

[armedbear-devel] Build problem
by Paul 20 Sep '09

20 Sep '09

Can anybody help with this build problem? I'm on MACOSX 10.5.8 trying to build from SVN, which I updated a few minutes ago. Buildfile: build.xml abcl.copy.lisp: [copy] Copying 171 files to /Users/pdo/Lisp/ABCL/build/classes abcl.init: [echo] java.version: 1.5.0_19 [echo] Implementation-Source: ${version.src} abcl.java.warning: abcl.jsr-223.notice: [echo] [echo] Notice: JSR-223 support won't be built since it is not [echo] supported, neither natively by your JVM nor by [echo] libraries in the CLASSPATH. [echo] abcl.compile.java: [javac] Compiling 268 source files to /Users/pdo/Lisp/ABCL/build/ classes abcl.fasls.uptodate: abcl.compile.lisp: [java] Armed Bear Common Lisp 0.15.0 [java] Java 1.5.0_19 Apple Inc. [java] Java HotSpot(TM) Client VM [java] Low-level initialization completed in 1.627 seconds. [java] Startup completed in 7.773 seconds. [java] [java] Caught SIMPLE-ERROR while processing --eval option "(compile-system :zip nil :quit t)": [java] *LISP-HOME* is NIL or invalid. [java] Please set *LISP-HOME* to the full pathname of the directory containing the Lisp system files. BUILD FAILED /Users/pdo/Lisp/ABCL/build.xml:211: Java returned: 2 Thanks, Paul

2 2

[armedbear-devel] [PATCH] Add SYS::*INVOKE-DEBUGGER-HOOK*
by Tobias C. Rittweiler 20 Sep '09

20 Sep '09

The first patch adds SYS::*INVOKE-DEBUGGER-HOOK* which is like *DEBUGGER-HOOK* but is observed by INVOKE-DEBUGGER even when BREAK is called. This obliterates the need to redefine SYS::BREAK in swank-abcl.lisp. A patch for swank-abcl is also attached. -T.

2 1

[armedbear-devel] r12147
by Ville Voutilainen 17 Sep '09

17 Sep '09

Thanks to Douglas Miles, I committed a fix to PRINT-LENGTH.INIT.1 ansi test. I'll commit the rest of Douglas' fixes shortly. Douglas, thanks for the contributions!

1 0

Re: [armedbear-devel] [j-devel] slime swank-abcl.lisp
by Mark Evenson 17 Sep '09

17 Sep '09

On 9/12/09 7:45 AM, Alan Ruttenberg wrote: > Here's a patch against the current swank-abcl.lisp to make a couple of > things work for the trunk abcl. > > I don't want to check it in, as I don't know whether there are issues > with it working for older versions of abcl. > > The fixes make edit definition work, and arglists for generic functions. > > Is there anyone out there who is currently active on slime development > that is comfortable checking these in? Applied to SLIME CVS HEAD. Thanks for the patch! I tested with abcl-0.{15,16} and HEAD with the patch working as I expected. Keeping compatibility with more ancient versions of ABCL takes a too much of my scant resources, but if someone is stuck with a previous version of ABCL they wish to maintain compatibility with SLIME CVS HEAD, drop me an email to work something out. For those following the "old" armedbear-j-devel(a)lists.sourceforge.net list, and perhaps wondering why things have been so quiet lately, note that we moved [ABCL specific traffic to common-lisp.net][1] some months ago. [1]: http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 4

[armedbear-devel] [ANN] Snow 0.1 released - GUI library for ABCL
by Alessio Stalla 15 Sep '09

15 Sep '09

Greetings everyone, I am pleased to announce the first public release of my "Snow" library, available at http://alessiostalla.altervista.org/software/snow/index.php It is a declarative DSL for creating GUIs (Swing-only for now) built on ABCL 0.16. It supports Cells by Ken Tilton and MiG Layout (a declarative, CSS-like layout manager for Swing and SWT). As a bonus, Snow includes the GUI versions of ABCL's inspector, debugger and REPL. Snow is to be considered alpha quality. In particular, % of Swing supported is ridiculously small, and little testing has been performed. If you feel brave enough to play with it, let me know about your experience. Cheers, Alessio

2 3

[armedbear-devel] [from abcl-dev] Question on ABCL-SCRIPT
by Mark Evenson 15 Sep '09

15 Sep '09

Over on the abcl-dev blog OMouse said... I have a question: how do you change the eval/load-script stuff so it doesn't use the ABCL-SCRIPT package? I'm trying to add extensive scripting to a game but I'd like to be able to switch the package so that the scripter can use a huge bunch of variables without me having to :export them. Can anyone help with this question? I must sheepishly confess to not having much experience with ABCL-SCRIPT yet, but the question seems to ask for refinements in our implementation. Posting a reply on the [abcl-dev blog][1] would be great. [1]: http://abcl-dev.blogspot.com/2009/09/abcl-0160-released.html#comments -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 1

[armedbear-devel] Loading ABCL fasls from JARs
by Erik Huelsmann 14 Sep '09

14 Sep '09

Hi Mark, Today I was thinking about what to write in our bi-weekly blog. Then I remembered you committed the support for loading FASLs from JARs. Would you -or someone else- want to write a blog entry on the ABCL-DEV blog to make this feature world-known? Of course, if you don't have time, that's fine too. It's just that I suddenly figured it would be a nice subject to blog about. Bye, Erik.

2 1

[armedbear-devel] asdf regression
by Alan Ruttenberg 11 Sep '09

11 Sep '09

asdf::oos used to take a :verbose argument. It no longer does. This breaks some of my code (I'm trying to migrate to the latest abcl so I can test/use the jar file feature - thanks Mark!) (I've worked around it for now) -Alan

3 10

[armedbear-devel] Summarizing "In-memory compilation status"
by Erik Huelsmann 09 Sep '09

09 Sep '09

As pointed out, Alessio added some primitives required to add in-memory compilation. However, the rest of the thread seems to mix a number of issues and their progress. As a result, I thought a summary might be in order. There were several things "in-memory" versus "using files": 1. Compilation of functions in our JSR-223 support (Alessio changed ABCL's behaviour here) 2. Compilation of lisp forms into compiled functions 3. Compilation of lisp files into fasls With respect to (1): This is where Alessio changed ABCL's behaviour to use COMPILE instead of COMPILE-FILE, eliminating the use of a single temporary file. With respect to (2): Currently, ABCL uses a temporary file for each "compiland" (FLET/LABELS defined function, LAMBDA, DEFUN) in the forms to be compiled. This file is created with a ".cls" extention. After it's written, it gets loaded into the running jvm by loading the bytes in a byte array. That byte array is then resolved to a class. ABCL uses its own class loader to do so. Because the the bytes get written and read without this being required by the Java class loader, there should not be a need to write the bytes out to a file. After the file has been read into memory, the temporary file gets deleted. With respect to (3): Each "compiland" in a file to be compiled leads to a ".cls" file, which is created as a temp file, then read into memory and after that written into the ".abcl" file - which as noted is in fact a .zip file. The intermediate temp file is then deleted. This process too takes much more I/O (what if you're compiling to a network drive with this kind of I/O?!) then required. It's with respect to items (2) and (3) that I'd like to see things changed. In case of (2) there's no reason to send output to any type of disc, while in case (3) it would be beneficial to write our output straight into the ZIP file, instead of using intermediary files. I'm looking for a good solution to both cases. One of the things I came up with is some kind of "storage factory" which would be a function to be called which either generates a stream sending output to the ZIP, or an in-memory stream or a file-backed stream if that's still required. So, what are your comments to that? Bye, Erik.

3 2

[armedbear-devel] [OT] best way to structure and deploy a project
by Alessio Stalla 09 Sep '09

09 Sep '09

Hello everyone, I have a question which is not exactly pertinent with the development of ABCL, but which imho can start a useful discussion. Please forgive me if this is too OT. I have a project with sources in two languages, Java and Lisp. It is an Eclipse project, but the IDE does not make difference. The project is a library, not an end-user application. Currently it is structured as follows: src/java - Java source code src/lisp - Lisp source code lib/ - third-party libraries, both Java (jars) and Lisp (directories). The Java code is compiled by the IDE and put in an output directory. The Lisp source files are treated by the IDE as normal, non-source files, and copied verbatim into the same ouput folder as the Java classes. When I run the project from the IDE, I launch a class which compiles and loads the Lisp systems using asdf. This works for me locally, but thinking about distributing the project to users, this approach has some drawbacks: - Lisp files must be true files, they can't be in a Jar (asdf doesn't understand jars). - Lisp files are recompiled every time, since the IDE always overwrites the Lisp source files in the output directory. - If I make a jar, it will contain Lisp source files, not binaries, since binaries are unknown to the IDE. Ideally I'd like to do what ABCL does, i.e. create one big jar containing .class files and compiled Lisp files. Lisp sources could be compiled by the IDE or by a script, I don't care. Still, I would like to maintain the use of asdf (since some of my dependencies use it and loading them manually is too much of a hassle). I don't know how I can do this. I have also thought about leaving everything as-is, and when I'll distribute the library as a jar, have it extract at runtime the Lisp source files from the jar in a temporary directory and instruct asdf to search for systems in that directory. I will also need the lib/ folder to be in a known place, since asdf has to load stuff from there too (but this is less of a problem since I can make the library user configure that place, and use a sensible default otherwise). I am wondering if a cleaner approach exists, and if someone has experience in this regard. Cheers, Alessio

7 19

[armedbear-devel] In-memory compilation status
by John Pallister 08 Sep '09

08 Sep '09

Hello list, I'm interested in trying to get ABCL running (and preferably REPL-ing & compiling) on a certain cloud computing platform that has a JVM with no access to a file system. The Wiki page for JSR-223 and the sample code both mention that "compilation using the runtime compiler has been removed due to inconsistencies with evaluation and file-based compilation", since May '09. Browsing the mailing list archives suggests that people have been working on removing the need for temporary files since then, but I can't find any mention of "inconsistencies". The thread "Save-image w/Serialization - progress report" from April ends with Sig. Stalla in the process of implementing a byte-array-output-stream, then silence... Can someone comment on the state of runtime compilation, preferably entirely in-memory without reference to a file system? Basically I'd like to be able to compile stuff to a byte array, store the array as a blob in a memcache and/or other datastore, then pull it out again as required and load it via a custom classloader. Is this doable, or would it be easier to port ParenScript to Clojure (which is currently my Plan B)? Cheers, and it's great to see the ABCL project still going strong! John :^P P.S. If anyone is going to be in Hamburg at the weekend and wants to chat about this stuff, that'd be great! -- John Pallister john(a)johnp.net john(a)synchromesh.com

3 9

[armedbear-devel] Passing FORMAT.C.4A and FORMATTER.C.4A
by logicmoo＠gmail.com 06 Sep '09

06 Sep '09

Passing FORMAT.C.4A and FORMATTER.C.4A Index: src/org/armedbear/lisp/LispCharacter.java =================================================================== --- src/org/armedbear/lisp/LispCharacter.java (revision 12140) +++ src/org/armedbear/lisp/LispCharacter.java (working copy) @@ -32,6 +32,8 @@ */ package org.armedbear.lisp; +import java.util.HashMap; +import java.util.Map; public final class LispCharacter extends LispObject { @@ -44,7 +46,7 @@ } public final char value; - + private String name; public static LispCharacter getInstance(char c) { try @@ -256,8 +258,11 @@ case 127: sb.append("Rubout"); break; - default: - sb.append(value); + default: + if (name!=null) + sb.append(name); + else + sb.append(value); break; } } @@ -541,6 +546,8 @@ public static final int nameToChar(String s) { String lower = s.toLowerCase(); + LispCharacter lc = namedToChar.get(lower); + if (lc!=null) return lc.value; if (lower.equals("null")) return 0; if (lower.equals("bell")) @@ -605,7 +612,8 @@ case 127: return "Rubout"; } - return null; + if (c<0 || c>255) return null; + return constants[c].name; } // ### char-name @@ -627,6 +635,39 @@ return Character.toUpperCase(c); } + static int maxNamedChar = 0; + static Map<String, LispCharacter> namedToChar = new HashMap<String, LispCharacter>(); + + static void setCharNames(int i, String[] string) { + int settingChar = i; + int index = 0; + int stringLen = string.length; + while(stringLen-->0) { + setCharName(settingChar,string[index]); + index++; + settingChar++; + } + if (maxNamedChar<settingChar) maxNamedChar = settingChar; + } + + static void setCharName(int settingChar, String string) { + if (settingChar>=CHAR_MAX) return; + LispCharacter c = constants[settingChar]; + c.name = string; + namedToChar.put(string.toLowerCase(), c); + } + + static { + new CharNameMaker0(); + } + + static class CharNameMaker0{ + { + setCharNames(0,new String[]{"Null", "Soh", "Stx", "Etx", "Eot", "Enq", "Ack", "Bell", "Backspace", "Tab", "Newline", "Vt", "Page", "Return", "So", "Si", "Dle", "Dc1", "Dc2", "Dc3", "Dc4", "Nak", "Syn", "Etb", "Can", "Em", "Sub", "Escape", "Fs", "Gs", "Rs", "Us"}); + setCharNames(128,new String[]{"U0080", "U0081", "U0082", "U0083", "U0084", "U0085", "U0086", "U0087", "U0088", "U0089", "U008a", "U008b", "U008c", "U008d", "U008e", "U008f", "U0090", "U0091", "U0092", "U0093", "U0094", "U0095", "U0096", "U0097", "U0098", "U0099", "U009a", "U009b", "U009c", "U009d", "U009e", "U009f"}); + } + } + private static final char[] UPPER_CASE_CHARS = new char[128]; static

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.16.0
by Erik Huelsmann 06 Sep '09

06 Sep '09

On behalf of the developers of ABCL (Armed Bear Common Lisp) - a lisp implementation running on the JVM - I'm glad to be able to announce the 0.16.0 release. This release features - among lots of other things - performance improvements, better type checking for the THE form and ANSI tests fixes. You can find the release notes at: http://common-lisp.net/project/armedbear/release-notes-0.16.shtml If you have questions regarding its license or use, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net The sources can be downloaded in ZIP or .tar.gz form from SourceForge: http://common-lisp.net/project/armedbear/releases/abcl-src-0.16.0.tar.gz http://common-lisp.net/project/armedbear/releases/abcl-src-0.16.0.zip Signatures are available under: http://common-lisp.net/project/armedbear/releases/abcl-src-0.16.0.tar.gz.asc http://common-lisp.net/project/armedbear/releases/abcl-src-0.16.0.zip.asc Bye, Erik.

1 0

[armedbear-devel] Branching 0.16.x
by Erik Huelsmann 04 Sep '09

04 Sep '09

With the recent changes to our Ant build to create ZIP files with CRLF line endings and LF line endings in the TAR archive, I think we have enough basis to create a branch for release management of our 0.16.x release line. Should further fixes be required, they can be backported. Creating the release branch now frees up the trunk for further development. Are there any last minute fixes that need to be applied? From the silence on the list this last week I concluded there probably are not. I hope to be able to create a release before the end of the weekend, however, no guarantees! Bye, Erik.

2 1

[armedbear-devel] eol-style problem with abcl-src-0.15.tar.gz
by Mark Evenson 01 Sep '09

01 Sep '09

Somehow we seemed to have shipped [the abcl-0.15.0 source][1] with a CR+LF file-ending for 'abcl.in', which means when built under a 'NIX one gets the slightly mysterious message "#!/bin/sh -- interpreter not found. It is slightly surprising that we haven't gotten more complaints on this (or maybe everyone builds from SVN?). The svn:eol-style is now set to 'LF' in SVN for 'abcl.in', which does the "right thing" when building the source tar balls, so abcl-0.16 should be ok, as long as whoever builds the release doesn't somehow override this is local SVN settings Looking through the SVN log for metadata changes to 'abcl.in' doesn't seem to report anything. Maybe there is somehow to report metadata changes, but I don't see how to do this quickly. We have the currently unused ability to fix line endings in the relevant Ant targets. Maybe I should revisit them? If so, what would be the correct policy? [1]: http://downloads.sourceforge.net/armedbear-j/abc/abcl-src-0.15.0.tgz -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 4

[armedbear-devel] Release planning: two month intervals, but which months?
by Erik Huelsmann 31 Aug '09

31 Aug '09

Last year we set a bi-monthly release planning. Last spring, we released once or twice within 6 weeks. This summer it took me - due to holidays - more time to get our trunk into a releasable state. Or so it must have looked from the outside. What I should have communicated is that I'd like to set our bi-monthly release planning to release around the first weekend of the odd-numbered months. Why? Well, it allows the release schedule to continue without suffering from most of the holidays: summer holidays (at least mine) are mostly during august; Christmas isn't around a first weekend and October holidays are rarely close to the first weekend of November. This means that February holidays may interfere with our release planning, but if I look at school holidays, these are mostly in the middle or the end of February. This plan would also mean that a release should be cut around next weekend. Then there's the issue of me being the only one with the right access to SourceForge to upload ABCL release files. We can do two things about that: 1. Give others upload access to SourceForge 2. Host our downloads on c-l.net The second option would make any committer a release manager, if we decided to do that [because we would commit the releases to our repository, which automatically updates our site]. The reason our downloads are currently hosted on SF is that they provide nice download stats. If we decide we don't need those or that we can create those stats ourselves on c-l.net, there's no reason to continue with SF. What are your comments? Bye, Erik.

2 2

[armedbear-devel] BLOCK-NODE -> specific node types done; let's go for a release
by Erik Huelsmann 31 Aug '09

31 Aug '09

Hi everybody, Over the past weeks, I've been rewriting our generic use of BLOCK-NODE structures to specific structures for every node type. There are TAGBODY-NODEs, CATCH-NODEs, etc. Although I introduced that change for a reason: I want to be able to analyse the nesting set up by pass1 from outer to inner blocks. This gives us some opportunities in preventing functions from becoming closures. Currently every function which is enclosed in a block which defines a closure, becomes a closure. That's too generic and doesn't need to be. Well, as I said, even though I want to introduce changes to that extent, I'm done changing the existing structure. This means I think we're in shape to go for a release. Everybody please run your test suite and your own applications to see if we still meet the quality levels we've delivered in the past releases (or, preferably: better!) I've updated changes, but there are probably a lot more tasks to be addressed. Just to name one: did 'build.xml' get fixed for releasing with Java 1.5? Or should I use 1.6 next time? Bye, Erik.

3 5

[armedbear-devel] BUG: problem with THE type checks in compiler
by eric.marsden＠free.fr 31 Aug '09

31 Aug '09

Hi, There is a problem in the recent improvements to the way the compiler handles THE type checking. File-compiling the code below leads to an error "The value 6 is not of type FOO". (defconstant +foo-OK+ (the (integer 0 10) 5)) (deftype foo () '(integer 0 10)) (defmacro assemble-foo (x) `(the foo ,x)) (defconstant +foo+ (assemble-foo 6)) Eric

3 4

[armedbear-devel] No JSR-223 code in abcl-src-0.15.tar.gz
by Alessio Stalla 28 Aug '09

28 Aug '09

Greetings all, I have downloaded the 0.15 release of abcl from the official site, to use it in a side-project at work. I found out that the archive does not contain the src/org/armedbear/lisp/scripting directory, where the JSR-223 stuff resides. Worse, the archive does contain the META-INF/services/javax.script.ScriptEngineFactory, so when built the jar actually declares it contains a JSR-223 implementation, but it does not. How is the archive built? I think I saw tasks in the Ant-based build file to zip the source, maybe those don't include the scripting/ directory. If that is the case, I can fix it for build.xml. I don't know how the Lisp based build works, though. Alessio

2 3

[armedbear-devel] Embedding ABCL into IntelliJ IDEA and writing plugins
by Anton Vodonosov 23 Aug '09

23 Aug '09

Hello, I created IntelliJ IDEA plugin that embeds ABCL, allows to connect from SLIME and extend IDEA using Common Lisp. I haven't contrived any useful functionality (that is easy to implement), therefore, for the sake of example, the plugin ads to IDEA commands yank and yank-pop, like in Emacs. Source may be found here: http://github.com/avodonosov/abcl-idea/tree/master Binary distro: http://cloud.github.com/downloads/avodonosov/abcl-idea/abcl-idea.zip There is a readme, check it for more details. Some conclusions from my experience: - it is absolutely possible to create IDEA plugins using ABCL. - Jfli interface to java is currently more convenient than native ABCL's - ABCL's performance of slime fuzzy-completion is still unsatisfying (it is the only little unsatisfying thing for me) - ABCL is more suited to be embedded into J editor, than into something else. For example Interpreter.kill method stops ABCL like: if (jlisp) { ... close input output streams } else System.exit(status); I.e. if we call Interpretter.kill() in IDEA plugin, it will exit whose IDEA process This is not a big problem, because with having Interpreter source code we may But having source code we can copy/past desirable kill behavior - closing streams. But it would make sense to reactor it a little to be more embedding friendly. If somebody is interested to write IDEA plugins in Lisp, my plugin may be used as a basis for further extension. Best regards, - Anton

3 4

Re: [armedbear-devel] progress on Maxima + ABCL -- light at the end of the tunnel!
by Erik Huelsmann 09 Aug '09

09 Aug '09

On Thu, Jul 30, 2009 at 8:04 PM, Robert Dodier<robert_dodier(a)yahoo.com> wrote: > > --- On Thu, 7/30/09, Erik Huelsmann <ehuels(a)gmail.com> wrote: > >> Another question: I'm running these profiles too, of >> course. On my system rtest_integrate takes forever to run, >> could that be this is the main cause it takes that long? >> Should we start profiling only that test set? > > Yes, that sounds reasonable. The integration code makes > use of the sign-inference code, to which DGR and DLS belong, > so maybe it is actually true that they are doing something > that is taking a long time. Well, I found a reason why ABCL may be taking so extremely long: in SPRDET.lisp, there's a top-level special declaration of the variable name X. In ABCL such declarations are retained after file compilation completes (which is allowed by the spec). Hence, after compilation of sprdet.lisp, any reference to a variable with the name X, or creation of a binding thereof, is a special binding. In ABCL, there's a non-trivial difference between evaluation of a special variable versus a local variable. So, renaming the special variable could be a solution, but that would require a change on part of Maxima; I'm thinking about how to revert the side effect at the end of the file compilation. That's a non-trivial change to ABCL. I haven't figured it out yet. Bye, Erik.

2 5

[armedbear-devel] European Common Lisp Meeting
by Arthur Lemmens 07 Aug '09

07 Aug '09

Hi, We just want to remind you that the registration deadline for this year's ECLM (European Common Lisp Meeting) is August 15. You can still register at http://weitz.de/eclm2009 We hope to see you in Hamburg, Edi Weitz & Arthur Lemmens

1 0

[armedbear-devel] [PATCH] Problems with new JavaObject.javaInstance(Class c) and JSS
by Mark Evenson 05 Aug '09

05 Aug '09

Unfortunately Alessio's (and Tobias?) work on [adding richness to inspection of Java objects][1] contains a bug that manifests itself in stopping [JSS][2] from working. The attached patch gets JSS to run again, but I am not sure the right way to fix the problem in the trunk, mainly as I don't understand all of our conversion rules, and how they interact with Java's autoboxing. The problem with JSS occurs when JavaObject.javaInstance(Class c) is invoked with a Class from a primitive boolean on an JavaObject that wraps a java.lang.Boolean. The call to java.lang.Class.isAssignableFrom() has an oddly (to me) specific contract that "[i]if [the] Class object represents a primitive type, this method returns true if the specified Class parameter is exactly this Class object; otherwise it returns false." This makes JavaObject<java.lang.Boolean>.javaInstance(boolean) fail, when everything seems to work fine if we simply return the wrapped object. What I don't understand mainly is if boolean/java.lang.Boolean objects are somehow special in our treatment of them, or should we do this for all of the other primitive types? [1]: http://trac.common-lisp.net/armedbear/changeset/12081 [2]: http://mumble.net:8080/svn/lsw/trunk/jss/ -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

3 5

[armedbear-devel] test, please ignore
by Anton Vodonosov 02 Aug '09

02 Aug '09

1 0

[armedbear-devel] [PATCH] 20090731b Java stack frames
by Mark Evenson 01 Aug '09

01 Aug '09

Last night I sent out an older version of my work; attached is the correct current version. Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Integration of CL and Java
by Tobias C. Rittweiler 31 Jul '09

31 Jul '09

To incite some discussion about what steps are required to make it convenient to write Java from within CL. The result should probably be added to Trac. Short term: * make Java objects inspectable. * make DESCRIBE be useful on Java objects. Should mention inheritance tree, public attributes, and methods. * fix inconsistencies, for example JMETHOD takes class-name first, then method-name, but JSTATIC takes it the other way around. Medium term: * make JMethods be a subclass of FUNCALLABLE-INSTANCE, so they can be funcalled, passed to HOFs, stored into SYMBOL-FUNCTION etc. * add reader-macros for convenience. For example, #J'class.method for (jmethod "class" "method"). * add iteration macro, HOFs, for Java Collections. * Figure out how to get arglist information from Java methods. * Documentation * Useful PRINT-OBJECT methods for Java Objects. For example, Collection objects could be printed showing their content, e.g. #<JAVA-CLASS COLLECTION [a b c d e]>. Make sure to make it heed the printer variables properly, though. Long term: * Add an extensible sequence protocol, and make Java Collection abide it. * integrate Java's object hierarchy into the CLOS object hierarchy. I'm not a CLOS expert, but a few people come to mind who to ask. * Make it possible to extend Java classes from Lisp. * Make it possible to implement Java interfaces from Lisp. People who have experience with Clojure, and other Lisp-like languages on the JVM are welcomed to chime in how other do the integration, and how they like it. Also people who have opinions how they'd like it to look like. -T.

4 3

[armedbear-devel] [REVISED 2] Java stack frame in Java
by Mark Evenson 31 Jul '09

31 Jul '09

Attached is another revision of the Java/Lisp stack frame patch. This one has a problem with SLIME that I'm not entirely sure whats going on, but Tobias asked for the latest revision, so I'm providing as a check point. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

1 0

[armedbear-devel] Revised patch for ticket #58 (inspection of Java objects)
by Alessio Stalla 30 Jul '09

30 Jul '09

Hi all, Here is my third iteration. It no longer represents fields as a Lisp lists, which was a premature optimization and as such the root of all evil (*) - i.e. it had the same problem discussed with Tobias, caching too much, because the value of a field was calculated once and never updated, unless one reinspected the root object. Now a FieldRef class is used instead. When inspected, a FieldRef shows the full string representation of the field - e.g. private static java.lang.Object foo - and of course allows to inspect the field's value, which is always coherent to the value the field has when the FieldRef is inspected. If there are no objections, tomorrow I'll commit the patch. Cheers, Alessio (*) as a side note, today I got my copy of Knuth's The Art of Computer Programming!

1 0

[armedbear-devel] Lisp (0.12.0) crashes with (dotimes (x 35) (print #x
by Phil Berry 30 Jul '09

30 Jul '09

Guys, FYI, I assume this shouldn't crash it: [pb@redhat-linux ~]$ lisp Armed Bear Common Lisp 0.12.0 Java 1.6.0 IBM Corporation IBM J9 VM Low-level initialization completed in 0.768 seconds. Startup completed in 2.637 seconds. Type ":help" for a list of available commands. CL-USER(1): *(dotimes (x 35) (print #x* java.lang.StringIndexOutOfBoundsException at java.lang.String.charAt(String.java:418) at org.armedbear.lisp.Stream.readRadix(Stream.java:1487) at org.armedbear.lisp.LispReader$18.execute(LispReader.java:370) at org.armedbear.lisp.Stream.readDispatchChar(Stream.java:785) at org.armedbear.lisp.LispReader$6.execute(LispReader.java:159) at org.armedbear.lisp.Stream.processChar(Stream.java:533) at org.armedbear.lisp.Stream.readList(Stream.java:722) at org.armedbear.lisp.LispReader$3.execute(LispReader.java:121) at org.armedbear.lisp.Stream.processChar(Stream.java:533) at org.armedbear.lisp.Stream.readList(Stream.java:722) at org.armedbear.lisp.LispReader$3.execute(LispReader.java:121) at org.armedbear.lisp.Stream.processChar(Stream.java:533) at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:448) at org.armedbear.lisp.Stream.readPreservingWhitespace(Stream.java:459) at org.armedbear.lisp.Stream.read(Stream.java:399) at org.armedbear.lisp.Stream$14.execute(Stream.java:2720) at org.armedbear.lisp.Symbol.execute(Symbol.java:733) at org.armedbear.lisp.LispThread.execute(LispThread.java:659) at org.armedbear.lisp.top_level_42.execute(top-level.lisp:765) at org.armedbear.lisp.Symbol.execute(Symbol.java:720) at org.armedbear.lisp.LispThread.execute(LispThread.java:638) at org.armedbear.lisp.top_level_43.execute(top-level.lisp:786) at org.armedbear.lisp.LispThread.execute(LispThread.java:659) at org.armedbear.lisp.top_level_44.execute(top-level.lisp:830) at org.armedbear.lisp.CompiledFunction.execute(CompiledFunction.java:63) at org.armedbear.lisp.Symbol.execute(Symbol.java:708) at org.armedbear.lisp.LispThread.execute(LispThread.java:618) at org.armedbear.lisp.top_level_45.execute(top-level.lisp:849) at org.armedbear.lisp.LispThread.execute(LispThread.java:618) at org.armedbear.lisp.Interpreter.run(Interpreter.java:373) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:735) [pb@redhat-linux ~]$

1 0

[armedbear-devel] Maxima profiling results
by Erik Huelsmann 30 Jul '09

30 Jul '09

Today I changed the profiler in ABCL to determine hot spots in our code, by looking only at the 8 stack frames at the head of the stack. The outcome of running the test suite with that changed profiler is this: 10.0 271135 TMS 10.2 275152 TIMESIN 10.7 289952 SIMPTIMES 11.1 300877 GREAT 12.3 332154 KINDP 13.7 371011 MEVAL1 14.1 382393 DMARK 15.8 427010 MEVAL 26.1 706542 SIMPLIFYA 74.3 2009777 DLSF 80.5 2177991 DLS 92.2 2493681 DGRF 100.0 2705263 DGR Where DGR is the hottest spot and the others are percentages of that. So, it looks like it that DGR is in the 8 most recent stack frames the most often of all functions used. Note this is based on sampling at a rate of 1ms intervals, not exact measurement. Robert, I'm hoping together we can explain the outcomes? Bye, Erik.

1 0

[armedbear-devel] ABCL in FreeBSD
by Erik Huelsmann 29 Jul '09

29 Jul '09

Hi Frank, Peter Graves pointed out to me that FreeBSD has a package for ABCL in its ports repository. Upon inspection, it turned out to have your name on it as the maintainer. It's great news! Thanks! There's one thing I'd like to ask you though: we started releasing regular releases of ABCL (bi-monthly intervals) and we're now working toward a release of ABCL 0.16. We noticed FreeBSD has a very old copy: 0.0.10.3. This was a bit of a downside to great news. Are you still the maintainer of that package? If not, do you know who is? If so, could you include more recent versions of ABCL? If you need help in order to be able to get more recent ABCL versions in your packages, maybe we can provide it? If so, what would we be able to do to support your package maintenance? Bye, Erik on behalf of the ABCL community.

1 0

[armedbear-devel] Proposed patch for ticket #58 (inspection of Java objects)
by Alessio Stalla 29 Jul '09

29 Jul '09

I have added to our inspector the ability to look into Java classes, showing the values of fields and allowing them to be further inspected. Here's an example interaction: CL-USER(1): (setq obj (jnew (jconstructor "java.util.ArrayList"))) #<JAVA-OBJECT java.util.ArrayList {98062F}> CL-USER(2): (inspect obj) #<JAVA-OBJECT java.util.ArrayList {98062F}> is an object of type JAVA-OBJECT. The wrapped Java object is an instance of java.util.ArrayList: "[]" 0 java-class -------> #<JAVA-OBJECT java.lang.Class {1FB7CBB}> 1 fields -----------> (("serialVersionUID" 8683452581122892189 ...) ("elementData" # ...) ...) [1i] CL-USER(3): :istep 1 A proper list with 4 elements at #x385715 0-> ("serialVersionUID" 8683452581122892189 ...) 1-> ("elementData" #(NIL NIL ...) ...) 2-> ("size" 0 ...) 3-> ("modCount" 0 ...) [1i] CL-USER(4): :istep 1 A proper list with 3 elements at #xDD23CF 0-> "elementData" 1-> #(NIL NIL ...) 2-> #<JAVA-OBJECT java.lang.reflect.Field {5A25F3}> [1i] CL-USER(5): As you can see, fields are triplets: the field name, the value, and the Field metaobject. I chose to represent them as simple lists to avoid having a class just for that purpose. NB: since the field values are read when the object is first inspected, and then translated to Lisp objects, the inspector will NOT reflect the current state of the object should it be altered (e.g. by another thread, or interactively by the user while inspecting). This is important especially wrt. inner objects: if A contains B and later C, inspecting A at a certain time will show me B, and inspecting B will, unsurprisingly, show me B, not C - even if A contains C now. I don't know if our inspector behaves like this for other objects too or not, but I don't see any (easy) way to change this fact. Next I'd like to show methods as well, and maybe even allow one to easily call them interactively (e.g. by making a method be a shown as triplet as well - the signature as a string, the java.lang.reflect.Method metaobject, and a closure which, when invoked, calls the method on the inspected object with the given parameters). I'm also working on a graphical inspector, but that's a bit more in the works ;) Thoughts? Ale

5 11

[armedbear-devel] Patch for LispThread.java, do not copy arrays in StackFrame
by Ville Voutilainen 29 Jul '09

29 Jul '09

Here's a very simple patch that should make function calls faster. I have only anecdotal tests with the raytracing shootout test and the compiled ansi-tests, but the numbers seem to support this patch. If nobody objects, I'll commit this.

2 1

[armedbear-devel] A clos patch for review
by Ville Voutilainen 28 Jul '09

28 Jul '09

Here's a stab at checking initargs for make-instance and others. With this patch, I get rid of the following errors: -CHANGE-CLASS.1.11 -MAKE-INSTANCE.ERROR.3 -MAKE-INSTANCE.ERROR.4 Feel free to comment.

2 7

[armedbear-devel] false-positive ansi tests
by Peter Tsenter 28 Jul '09

28 Jul '09

It seems abcl generates correct result on some ANSI tests, but in actuality abcl fails. The way tests are written, it's hidden from the user. Example: disassemble.4 If one executes (disassemble-it (eval '(function (lambda (x y) (cons x y))))) as it's written then everything looks ok, but (disassemble (eval '(function (lambda (x y) (cons x y))))) returns the following ; 'jad' is not recognized as an internal or external command, ; operable program or batch file. NIL _________________________________________________________________ Windows Live™ Hotmail®: Search, add, and share the web’s latest sports videos. Check it out. http://www.windowslive.com/Online/Hotmail/Campaign/QuickAdd?ocid=TXT_TAGLM_…

2 2

Re: [armedbear-devel] [j-devel] bug - interaction between unwind-protect, function call, multiple values
by Erik Huelsmann 28 Jul '09

28 Jul '09

Hi Alan, On Mon, Jul 27, 2009 at 2:08 AM, Alan Ruttenberg<alanruttenberg(a)gmail.com> wrote: > (defun bar () (values 1 2)) > (bar) => > 1 > 2 > (defun foo () (unwind-protect (return-from foo (bar)) 2)) > (foo) => > 1 > (defun foo () (unwind-protect (return-from foo (values 1 2) 2))) > (foo) => > 1 > 2 > > I noticed this in an early version of abcl, but just downloaded and > built from subversion and it's still there. > Doesn't seem to matter whether it is interpreted or evaluated. It didn't matter whether interpreter or compiled, because both had the same issue. Anyway, thanks for the report! It's fixed now. Bye, Erik.

2 1

Re: [armedbear-devel] [j-devel] bug - interaction between unwind-protect, function call, multiple values
by Erik Huelsmann 27 Jul '09

27 Jul '09

Hi Alan! On Mon, Jul 27, 2009 at 2:08 AM, Alan Ruttenberg<alanruttenberg(a)gmail.com> wrote: > (defun bar () (values 1 2)) > (bar) => > 1 > 2 > (defun foo () (unwind-protect (return-from foo (bar)) 2)) > (foo) => > 1 > (defun foo () (unwind-protect (return-from foo (values 1 2) 2))) > (foo) => > 1 > 2 > > I noticed this in an early version of abcl, but just downloaded and > built from subversion and it's still there. > Doesn't seem to matter whether it is interpreted or evaluated. I can see the error in the compiler; it's in p2-unwind-proctect: the exception handler doesn't save the values register of the thread. Maybe it's the same in the interpreter. I'll have a look later today, if I have time. Thanks for the report! Bye, Erik.

1 0

[armedbear-devel] progress on Maxima + ABCL -- light at the end of the tunnel!
by Robert Dodier 26 Jul '09

26 Jul '09

Hi, I've compiled Maxima (from CVS) with ABCL (from svn) and run_testsuite() shows just a few errors due to different floating point results. Hurray! The key change to Maxima seems to have been changing EQ to EQUAL in a pattern-matching function ... In ABCL it appears that numbers are not necessarily EQ so a lot of patterns failed. Since the pattern-matching stuff is widely used in Maxima (especially integrals) there were a lot of failed tests. Just that one change seems to have fixed dozens of test failures! I found it necessary to run the autoconf machinery (sh bootstrap && ./configure at least; I ran make as well, although I don't know if that's actually necessary, and then I ran configure.lisp as described in INSTALL.lisp) before compiling with ABCL via: (require 'asdf) (asdf:operate 'asdf:load-op :maxima) Without the autoconf stuff, src/autoconf-variables.lisp has incorrect values, it seems. Maxima + ABCL is extremely slow -- something like 7 times slower than Maxima + Clisp, which is the slowest of the established Lisp implementations I've tried (GCL, ECL, SBCL, CMUCL, and Clisp). I'm working on Linux, maybe it helps to run on Windows -- I'm thinking the Java implementation might be faster. Just a guess. I'm pretty excited about the possibilities here. A long-term project is to organize Maxima into modules in hopes of making it possible to load different modules a la carte -- I think that might make it attractive for bolting it onto different projects. Thanks to the ABCL developers for all their work. best Robert Dodier Maxima developer

1 0

[armedbear-devel] Deploying compiled ABCL apps/elements
by Matt Lamari 26 Jul '09

26 Jul '09

What is the mechanism for converting source code or an in-memory image (or fragment thereof) into a deployable unit? Just point me at a function name/document and I can take it from there. . . . Thanks, Matt

4 5

[armedbear-devel] Problem loading Lisp file on Mac, but works on Windows
by Paul Reiners 25 Jul '09

25 Jul '09

I've written a Java program that calls a Lisp program. On Windows, this works just fine. However when I run it on Mac OS X, I get this error: Error loading /Users/paul/Documents/workspaces/MyOpenSourceProjects/ JVMLanguages/src/life.lisp at line 53 (offset 1628) Debugger invoked on condition of type END-OF-FILE: #<END-OF-FILE {51190A}> [1] CL-USER(1): Any idea what is going wrong here? I wrote both the Lisp and Java files on Windows originally. Is it some sort of character encoding problem? Here are the relevant files: http://automatous-monk.cvs.sourceforge.net/viewvc/automatous-monk/JVMLangua… http://automatous-monk.cvs.sourceforge.net/viewvc/automatous-monk/JVMLangua… Paul

1 0

[armedbear-devel] Holidays or the release of 0.16?
by Erik Huelsmann 25 Jul '09

25 Jul '09

With the normal release schedule, it would be time to release 0.16 in 1 or 2 weeks. However, I'll be travelling with unknown amounts of net time around that time. Until then, I'll be busy with work and travel preparations. So, we have 2 options here: 1. One of the other committers steps up and makes the release Most of our release process is documented in the wiki. What's not there can be added until then 2. We delay 0.16 until some time I have time to create the release. With kind regards, Erik.

2 1

[armedbear-devel] second version of the StackFrame cleanup
by Ville Voutilainen 23 Jul '09

23 Jul '09

Same as before, but use a vararg function instead of doing manual arrays. Java does correctly choose a multi-param version when it's available, it only uses a vararg version when it has to.

1 0

[armedbear-devel] (lisp) Stack management efficiency
by Erik Huelsmann 21 Jul '09

21 Jul '09

Peter Graves pointed me at the language/implementation efficiency shootout at http://www.ffconsultancy.com/languages/ray_tracer/benchmark.html which implements a ray tracer in a multitude of languagues, one of them being Common Lisp. There are a number of rows, which I conviniently name version 1 (row 1) to version 5 (last row). Peter points out that version 1 isn't optized at all: all functions lead to function calls (no inlining). When running this code, it takes around 1440 seconds on my PC. Then I modified the stack management routine to re-use available stack frames (and conses), instead of creating new ones on every call. This took execution time down to around 1240 seconds. A good improvement, I'd say. However, with the change described above, stack frames won't ever become garbage anymore. My question is: does the loss of GC-ability outweigh the performance gain? Please note that it's possible to run without a lisp stack (but that also means without traces) by compiling code with a (SPEED 3) declaration. Comments? Bye, Erik.

7 16

[armedbear-devel] Parameterized Lisp Calls vs Array Calls
by logicmoo＠gmail.com 21 Jul '09

21 Jul '09

Parameterized Lisp Calls vs Array Calls In the code I added a Interface "barrier" just in-case there was some inlining /***********************START JAVA*************************************************/ package benchtest; interface ISomeFunParams { int SomeFun(int i, int j); } interface ISomeFunArray { int SomeFun(int[] ij); } interface ISomeFunVarArgs { int SomeFun(int... ij); } class BenchArrays1 { public static void main(String[] args) { ISomeFunParams sumFun = new SomeFunImpl1(); int res = 0; for (int i = 0; i < 100000; i++) for (int j = 0; j < 100000; j++) { res += sumFun.SomeFun(i, j); } // make sure we care about 'res' int foo = res; if (foo > 0) { res--; } } } class BenchArrays2 { public static void main(String[] args) { ISomeFunVarArgs sumFun = new SomeFunImpl2(); int res = 0; for (int i = 0; i < 100000; i++) for (int j = 0; j < 100000; j++) { res += sumFun.SomeFun(i, j); } // make sure we care about 'res' int foo = res; if (foo > 0) { res--; } } } class BenchArrays3 { public static void main(String[] args) { ISomeFunArray sumFun = new SomeFunImpl3(); int res = 0; for (int i = 0; i < 100000; i++) for (int j = 0; j < 100000; j++) { res += sumFun.SomeFun(new int[]{i, j}); } // make sure we care about 'res' int foo = res; if (foo > 0) { res--; } } } class SomeFunImpl1 implements ISomeFunParams { public int SomeFun(int i, int j) { return i + j; } } class SomeFunImpl2 implements ISomeFunVarArgs { public int SomeFun(int... ij) { return ij[0] + ij[1]; } } class SomeFunImpl3 implements ISomeFunArray { public int SomeFun(int[] ij) { return ij[0] + ij[1]; } } /***********************END JAVA*************************************************/ [root@titan ArrayBoundsCheckBenchmarks]# time java -cp bin/ benchtest.BenchArrays1 real 0m0.113s user 0m0.040s sys 0m0.013s [root@titan ArrayBoundsCheckBenchmarks]# time java -cp bin/ benchtest.BenchArrays2 real 1m42.898s user 1m21.279s sys 0m0.742s [root@titan ArrayBoundsCheckBenchmarks]# time java -cp bin/ benchtest.BenchArrays3 real 1m40.823s user 1m21.411s sys 0m0.651s

1 0

[armedbear-devel] Proposed patch to move remaining symbols to THREADS
by Mark Evenson 21 Jul '09

21 Jul '09

Attached is a proposed patch to complete moving the various THREADS related stuff into the new package. This patch removes the Gates implementation, as the new SYNCHRONIZED-ON and OBJECT-NOTIFY primitives provide more appropriate (i.e. more JVM specific) abstractions. If Tobias and Erik could check that this patch is what they want to have happen, I'll commit it. -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] missing right parenthesis for Clisp in build script
by Robert Dodier 20 Jul '09

20 Jul '09

Hi, I tried to use the build-from-lisp.sh with Clisp but there was a missing right parenthesis in the forms to be evaluated on the command line. Just putting in another paren fixed it. HTH Robert Dodier

2 1

[armedbear-devel] Wikipedia page on ABCL deleted
by Kevin Krouse 18 Jul '09

18 Jul '09

Yesterday, the wikipedia minions decided ABCL is not "notable enough" and so have deleted the ABCL page: http://en.wikipedia.org/wiki/Armed_Bear_Common_Lisp http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Armed_Bear_Com… http://en.wikipedia.org/w/index.php?title=Special:Log/delete&page=Armed_Bea… I'm not sure what their requirements for notability are exactly. At any rate, it would be good to get the page restored and expand upon the sparse text that was originally there -- perhaps with code samples and links to projects using ABCL. Kevin

2 1

[armedbear-devel] patch for bug: function JVM::%FLOAT-BITS is undefined
by Anton Vodonosov 18 Jul '09

18 Jul '09

Hello, Consider the following java snippet: public static void main(String[] args) throws Throwable { Interpreter interpreter = Interpreter.createInstance(); interpreter.eval("(compile nil '(lambda () 0.1))"); } It fails with error: Debugger invoked on condition of type UNDEFINED-FUNCTION: The function JVM::%FLOAT-BITS is undefined. In the REPL (compile nil '(lambda () 0.1)) works normally. I do not understand what is the difference in environment between ABCL REPL and embedded ABCL, but the following trivial patch fixes the problem in for the embedded case. Index: src/org/armedbear/lisp/compiler-pass2.lisp =================================================================== --- src/org/armedbear/lisp/compiler-pass2.lisp (revision 12050) +++ src/org/armedbear/lisp/compiler-pass2.lisp (working copy) @@ -132,7 +132,7 @@ (defknown pool-float (single-float) (integer 1 65535)) (defun pool-float (n) (declare (optimize speed)) - (pool-get (list 4 (%float-bits n)))) + (pool-get (list 4 (sys::%float-bits n)))) (defun pool-long/double (entry) (let* ((ht *pool-entries*) @@ -163,7 +163,7 @@ (defknown pool-double (double-float) (integer 1 65535)) (defun pool-double (n) (declare (optimize speed)) - (let* ((n (%float-bits n)) + (let* ((n (sys::%float-bits n)) (entry (list 6 (logand (ash n -32) #xffffffff) (logand n #xffffffff)))) Best regards, - Anton

1 1

[armedbear-devel] Thread safety of the compiler (was: Thread safety of clos.lisp)
by Erik Huelsmann 17 Jul '09

17 Jul '09

Well, I've been investigating the issue with our clos.lisp not being thread safe and me seeing NullPointerExceptions. It turns out that GENSYM was not thread safe in case there were no thread-local special bindings: the SYMBOL-VALUE wasn't protected against being manipulated from 2 threads at the same time. I changed that. Now, even though clos.lisp is not thread safe, I'm not seeing any NullPointerExceptions anymore. The NullPointerExceptions were caused by the fact that COMPILE was running in 2 threads at the same time, generating the same symbol at the same time. Then, it called REMEMBER from both threads, one overwriting the value stored by the other. That doesn't cause NullPointerExceptions by itself, but when each thread loads its COMPILEd function, the constructor calls Lisp.recall(), which removes the key from the hash used for temp-storage. The second function then finds 'null' instead of the value it stored. So, that's another mystery solved. Fixed in trunk now. However, what remains is the fact that the remember/recall combo uses global keys while COMPILE may be generating thread-local key values. I'm wondering what to do about that. Possibly I should just create a ThreadLocal which has a temp-storage hash table per thread and document remember/recall are a thread-local storage mechanism. Of course, your opinions are welcome as always, especially with respect to the last paragraph. Bye, Erik.

1 1

[armedbear-devel] Thread safety of clos.lisp (and supporting Java classes)
by Erik Huelsmann 15 Jul '09

15 Jul '09

During my testing of multi-threaded use of ABCL over the past weeks, I found that ABCL performs reliably with 2 threads on 2 cores (fully dedicated to running ABCL code). However, there's one notable exception: Any code which requires CLOS, such as the pretty printer and other actions which require generic methods. I'm able to quite reliably break ABCL by starting a specific series of actions on 2 threads at the same time. (No global values in the program code!) The cause can be led back to slow-method-lookup; if I add SYNCHRONIZED-ON to it, the tests work fine. However, SLOW-METHOD-LOOKUP has friends which also manipulate the EMF-CACHE, so I don't think this would be the full solution. There's however an additional issue: Hashmap is defined to be thread-unsafe: 2 concurrent readers are fine, but concurrent writers or mixed concurrent readers/writers are not guaranteed to work. So, to guarantee results with the current EMF-CACHE implementation, we need to make sure there's 1 reader/writer at the same time - using synchronized-on, that is. For most applications this would be horribly inefficient: most methods will be added once and read huge numbers of times. ECL chose a rather unconventional direction in this case: instead of searching for lock-less semantics of global state, they have an EMF-CACHE per thread, meaning that read/write operations on the cache are thread-local and hence can be done lockless. ABCL could easily go with java.util.concurrent.ConcurrentHashMap, which is lock-less and allows concurrent readers and limited synchronous writers (~16 by default). However, this assumes that the actual threading issue is mainly with writing values to the cache. ie, before an "entry to be cached" is available, nothing happens which can't be overwritten immediately after it has been added to the cache. It's that last bit I have problems with assessing: do we simply need to use another caching hash class or do we need to do much broader "global" locking? (The "global" locking proposed would simply be locking that specific generic function; clos could easily run in other threads for other GFs...) Help welcome! Bye, Erik.

1 0

[armedbear-devel] Compiler macros vs source transforms
by Erik Huelsmann 14 Jul '09

14 Jul '09

While reading through precompiler.lisp, I noticed we have 3 concepts for transformation of lisp sources * normal macros, * compiler-macros, * source-transforms The difference between macros and compiler-macros is well documented in the CLHS; however, the difference between compiler-macros and source-transforms is unclear to me. I found that the former is expanded in compiler-pass1 while the latter is expanded in precompiler.lisp. However, when we're compiling for interpretation (not compilation), *in-jvm-compile* is NIL, meaning that source-transforms don't get expanded. The net effect would be that both source-transforms and compiler-macros only get expanded when we're compiling. I'm wondering what the benefit of source transforms is if this is really true. Bye, Erik.

3 4

[armedbear-devel] LispThread.execute, funcall(), stack frames
by Tobias C. Rittweiler 14 Jul '09

14 Jul '09

I just added http://trac.common-lisp.net/armedbear/ticket/60 Essentially the code needs some refactoring. It's not obvious that LispThread.execute is "execute with stack frame". It's also not really obvious when to use it. In fact, why is it there? Isn't it the same as Lisp.funcall()? -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1

[armedbear-devel] patch: do not call compile for every call of eql-specialized generic functions
by Anton Vodonosov 14 Jul '09

14 Jul '09

Hello. The attached is a patch to improve performance of eql-specialized generic functions. I started to investigate this problem because slime fuzzy completion works very slow with ABCL. For example (time (swank::fuzzy-completions "de" 'cl-user)) takes 1.5 - 2 seconds. That long time is not pleasant for user interface. Turned out that most of the time is spent in COMPILE. During SWANK::FUZZY-COMPLETIONS every symbol is processed by SWANK-CLASSIFY-SYMBOL, which uses (DOCUMENTATION s 'TYPE), and every invocation (DOCUMENTATION s 'TYPE) being eql-specialized function leads to COMPILE. With my patch (time (swank::fuzzy-completions "de" 'cl-user)) takes 0.25 - 0.5 seconds. Not too fast, in CLISP the same takes 0.07 sec, in CCL 0.03 sec. But significantly better than it was. In the patch method getArgSpecialization could probably be named better. Also I am not sure if you want to keep the wordy javadoc comment; i just decided to put the patch explanation to the sources instead of this email. Best regards, - Anton

2 3

[armedbear-devel] [PATCH] build-from-lisp.sh (take 2)
by Tobias C. Rittweiler 14 Jul '09

14 Jul '09

Ok, I've redone build-from-lisp.sh so that build-abcl.lisp can remain untouched. I also added the feature to set :clean, :full, :batch from the command-line via --clean, --full, and --batch. I used the script to build ABCL successfully on SBCL, CLISP, and CCL. -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1

[armedbear-devel] [PATCH] fix arglist of EXT:ARGLIST
by Tobias C. Rittweiler 13 Jul '09

13 Jul '09

Fix (ext:arglist 'ext:arglist) => NIL. -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1

[armedbear-devel] [PATCH] build-from-lisp.sh
by Tobias C. Rittweiler 13 Jul '09

13 Jul '09

The following makes it possible to build ABCL from the command line directly: ./build-from-lisp.sh sbcl ./build-from-lisp.sh clisp etc. -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

3 3

[armedbear-devel] [PATCH] Move some symbols into the THREADS package.
by Tobias C. Rittweiler 13 Jul '09

13 Jul '09

The patch attached to this mail moves the usual suspects to the THREADS package. It does not move the Gates-related functions because I think that Gates can be removed again now with the SYNCHRONIZE-ON stuff. -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

2 1

[armedbear-devel] gmane.lisp.armedbear.devel
by Tobias C. Rittweiler 13 Jul '09

13 Jul '09

With this message, the gmane.lisp.armedbear.devel group should be created. -T. -- Diese Nachricht wurde auf Viren und andere gefaerliche Inhalte untersucht und ist - aktuelle Virenscanner vorausgesetzt - sauber. Freebits E-Mail Virus Scanner

1 0

[armedbear-devel] Saving stackframes?
by Erik Huelsmann 12 Jul '09

12 Jul '09

When looking at numerous backtraces, I find that the pattern LispThread.execute->Symbol.execute->function.execute happens very often. The only thing Symbol.execute does is forward the call to the function in its function slot. Now, we could save ourselves this stackframe by taking "the stack hit" in LispThread.execute the following way: if (function instanceof Symbol) function.getSymbolFunction().execute() else function.execute() where the execute function in LispThread currently only contains function.execute()... I found our implementation uses a *lot* more stack than the average Java application. This may be a way to reduce that a bit. What about it? Bye, Erik.

1 0

[armedbear-devel] Blog to report on ABCL development progress
by Erik Huelsmann 12 Jul '09

12 Jul '09

Yesterday Tobias Rittweiler brought to my attention that all the good work that's being done on the development of ABCL probably has gone unnoticed in the larger Lisp community: we didn't post our release announcements on usenet (comp.lang.lisp) and we don't have a blog to feed the Planet Lisp syndication with. So, as a first step, I created http://abcl-dev.blogspot.com/ seeding it with a first post. A request has been submitted to add the blog to the Planet Lisp feed syndication. Anybody who has an interest in blogging or submitting a blog once in a while, feel free to step up. The blog is intended to be - weekly or bi-weekly, but not high volume - about the highs and lows that make up the ABCL development experience and progress. Bye, Erik.

1 0

[armedbear-devel] [PATCH] Support for SYNCHRONIZED blocks (and company)
by Erik Huelsmann 11 Jul '09

11 Jul '09

Based on discussion earlier this week, I'd like the following patch to get committed to our trunk. It introduces a new block statement SYNCHRONIZED-ON <object> body and next to that a number of functions: object-wait <object> &optional timeout object-notify <object> object-notify-all <object> So, what's the verdict? Anyway, I plan on including some simple test cases, but ofcourse, if someone feels like doing so, please feel free! Bye, Erik.

4 10

[armedbear-devel] [RFC] Support for 'synchronized' blocks in Lisp code
by Erik Huelsmann 07 Jul '09

07 Jul '09

I propose that we introduce a WITH-EXCLUSIVE-ACCESS form in the EXT package, which takes 1 argument (the second value) and a body (the third value). The form makes sure that the body is evaluated as if it had been called with: synchronized (arg1) { body-to-evaluate; } Except that it implements this in Lisp. This way, our Lisp<>Java interoperability would increase. It would also be an efficient way to guarantee exclusive access when modifying a cross-thread shared resource (such as generic functions). Comments? Bye, Erik.

5 7

[armedbear-devel] Extensible sequences
by Alessio Stalla 07 Jul '09

07 Jul '09

Hello, has anyone ever thought of adding extensible sequences[1] to abcl? Given that our implementation of sequences is copied/adapted from CMUCL, and extensible sequences have been implemented in SBCL which is itself a fork of CMUCL, it may be as easy as copy-pasting from SBCL with minor adaptations. Extensible sequences would allow to easily make Java collections first-class citizens in our Lisp world. This would have a number of benefits, last but not least the fact that we could easily use Clojure collections with abcl. Unfortunately I have not the time to do this myself, but if someone likes the idea and is willing to contribute... Cheers, Alessio [1] http://www.doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdf

2 2

[armedbear-devel] armedbear-devel@common-lisp.net
by Anton Vodonosov 06 Jul '09

06 Jul '09

Hello, According to the project page, there is ansi test suite. But 0.15.0 package from sourceforge doesn't contain it. Also I can't find on the project page any reference to source code repository. Is it really the current state of affairs, or I missing something? Best regards, - Anton

2 1

[armedbear-devel] ansi tests
by Anton Vodonosov 05 Jul '09

05 Jul '09

on Sunday, July 5, 2009, 3:27:37 PM Ville wrote: > On Sun, Jul 5, 2009 at 1:51 PM, Anton > Vodonosov<avodonosov(a)gmail.com> wrote: >> According to the project page, there is ansi test suite. >> But 0.15.0 package from sourceforge doesn't contain it. > You need to get it separately, from > svn://common-lisp.net/project/ansi-test/svn/trunk/ansi-tests I checked-out the suite, but it seems to be insufficient. How to run the tests? ant in the abcl directory suggest to use "ant acbl.test.java". It fails with: BUILD FAILED C:\usr\unpacked\abcl\abcl-src-0.15.0-original\build.xml:481: srcdir "C:\usr\unpacked\abcl\abcl-src-0.15.0-original\test\src" does not exist! The project page suggests to run ant test.ansi.interpreted ant test.ansi.compiled This fails with [java] Debugger invoked on condition of type FILE-ERROR: [java] File not found: C:\usr\unpacked\abcl\abcl-src-0.15.0-original/test/lisp/ansi/ansi-tests-interpreted.lisp There is indeed no directory "test" in the 0.15.0 package I downloaded from sourceforge. Best regards, - Anton

1 0

[armedbear-devel] Franz-style Gates implementation
by Mark Evenson 04 Jul '09

04 Jul '09

Tobias Rittweiler writes: > The attached patch adds Gates to ABCL, inspired by what Franz Allegro > Common Lisp provides. > > A GATE is an object with two states, open and closed. It is > created with MAKE-GATE. Its state can be opened (OPEN-GATE) or > closed (CLOSE-GATE) and can be explicitly tested with > GATE-OPEN-P. Usually though, a thread awaits the opening of a > gate by WAIT-OPEN-GATE. > > This will be used to implement the threading communication style in > ABCL's Swank backend. > > I'm not particularly good at writing multiprocessing, or Java code. So > please review carefully. Tobias wrote this to support his version of a multi-threaded SLIME backend, and has proposed it for inclusion in ABCL. When I get some time, I'll do some tests, but post the patch here in case it helps someone else out before that time or if their is any feedback. As it stands, the Gates implementation would go in the EXTENSIONS package. Mark -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

4 6

[armedbear-devel] Threading issue with ERROR (?)
by Erik Huelsmann 04 Jul '09

04 Jul '09

I have an application which uses a combination of DEFINE-CONDITION, ERROR and HANDLER-CASE to handle certain exceptional situations. The call sequence basically looks like this: (when loading the file:) (define-condition model-error (error) ()) (defun foo1 (arg) (if arg (error 'model-error) 3)) (defun foo2 (arg) (handler-case (foo1 arg) (model-error () 0.0d0)) and then, from different threads: (foo2 <some value or NIL>) When I do this in a single-threaded application all goes well. When I do this in a multi threaded application with a single calculation (lisp) thread, all goes well as well. When I do this in a multi threaded application with multiple calculation threads (lisp), I get a NullPointerException somewhere deep in our CLOS code... Has anybody experienced the same? Bye, Erik.

1 0

[armedbear-devel] Patch to add multi-threading to ABCL SLIME CVS HEAD
by Mark Evenson 02 Jul '09

02 Jul '09

Attached is a patch against SLIME CVS HEAD to implement multi-threading (aka the :spawn *COMMUNICATION-STYLE*) as a default in ABCL. In addition this patch muffles various STYLE-WARNING compilation messages via DECLARE forms. Among other things, this seems to fix the fugliness around where *STANDARD-OUTPUT* ends up and the missing CR (or LF) in the NIL *COMMUNICATION-STYLE*. This patch has been tested against ABCL 0.16.0-dev as of [svn r12022] with Emacs 22.3 under OS X. I didn't need to do much to the existing code except fix a typo while comparing against the current 'swank-sbcl.lisp' version, making me somewhat suspicious of why that code was not used in the first place (did someone just cut and paste the SBCL implementation without trying to get it to work? But thanks to whoever got it that far!) -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now." diff -r 2225a8f2d322 -r 3c562ce589df swank-abcl.lisp --- a/swank-abcl.lisp Wed Jul 01 05:38:54 2009 +0200 +++ b/swank-abcl.lisp Wed Jul 01 11:06:42 2009 +0200 @@ -17,6 +17,7 @@ (defun sys::break (&optional (format-control "BREAK called") &rest format-arguments) (let ((*saved-backtrace* (backtrace-as-list-ignoring-swank-calls))) + (declare (ignore *saved-backtrace*)) (with-simple-restart (continue "Return from BREAK.") (invoke-debugger (sys::%make-condition 'simple-condition @@ -42,10 +43,16 @@ ;(defun class-finalized-p (class) t) -(defun slot-definition-documentation (slot) #+nil (documentation slot 't)) -(defun slot-definition-type (slot) t) -(defun class-prototype (class)) -(defun generic-function-declarations (gf)) +(defun slot-definition-documentation (slot) + (declare (ignore slot)) + #+nil (documentation slot 't)) +(defun slot-definition-type (slot) + (declare (ignore slot)) + t) +(defun class-prototype (class) + (declare (ignore class))) +(defun generic-function-declarations (gf) + (declare (ignore gf))) (defun specializer-direct-methods (spec) (mop::class-direct-methods spec)) (defun slot-definition-name (slot) @@ -61,9 +68,11 @@ (mop::%method-function method)) (defun slot-boundp-using-class (class object slotdef) + (declare (ignore class)) ; FIXME (system::slot-boundp object (slot-definition-name slotdef))) (defun slot-value-using-class (class object slotdef) + (declare (ignore class)) ; FIXME (system::slot-value object (slot-definition-name slotdef))) (import-to-swank-mop @@ -119,7 +128,7 @@ (defimplementation preferred-communication-style () - nil) + :spawn) (defimplementation create-socket (host port) (ext:make-server-socket port)) @@ -483,8 +492,8 @@ ;;;; Multithreading -(defimplementation startup-multiprocessing () - #+nil(mp:start-scheduler)) +#+nil ; Already started +(defimplementation startup-multiprocessing (continuation)) (defimplementation spawn (fn &key name) (ext:make-thread (lambda () (funcall fn)) :name name)) @@ -513,7 +522,23 @@ (defimplementation thread-status (thread) (format nil "Thread is ~:[dead~;alive~]" (ext:thread-alive-p thread))) +;; XXX should be a weak hash table +(defparameter *thread-description-map* (make-hash-table)) + +(defvar *thread-description-map-lock* + (ext:make-mutex)) + +(defimplementation thread-description (thread) + (ext:with-mutex (*thread-description-map-lock*) + (or (gethash thread *thread-description-map*) + "No description available."))) + +(defimplementation set-thread-description (thread description) + (ext:with-mutex (*thread-description-map-lock*) + (setf (gethash thread *thread-description-map*) description))) + (defimplementation make-lock (&key name) + (declare (ignore name)) (ext:make-thread-lock)) (defimplementation call-with-lock-held (lock function) @@ -525,8 +550,11 @@ (defimplementation all-threads () (copy-list (ext:mapcar-threads #'identity))) +(defimplementation thread-alive-p (thread) + (member thread (all-threads))) + (defimplementation interrupt-thread (thread fn) - (ext:interrupt-thread thread fn)) + (ext:interrupt-thread thread fn)) (defimplementation kill-thread (thread) (ext:destroy-thread thread)) @@ -542,14 +570,13 @@ (setf (getf (gethash thread *thread-props*) 'mailbox) (make-mailbox))))) -(defimplementation send (thread object) +(defimplementation send (thread message) (let ((mbox (mailbox thread))) (ext:with-mutex ((mailbox-mutex mbox)) (setf (mailbox-queue mbox) (nconc (mailbox-queue mbox) (list message)))))) -#+(or) -(defimplementation receive-if (thread &optional timeout) +(defimplementation receive-if (test &optional timeout) (let* ((mbox (mailbox (current-thread)))) (assert (or (not timeout) (eq timeout t))) (loop @@ -561,9 +588,7 @@ (setf (mailbox-queue mbox) (nconc (ldiff q tail) (cdr tail))) (return (car tail)))) (when (eq timeout t) (return (values nil t))) - ;;(java:jcall (java:jmethod "java.lang.Object" "wait") - ;; (mailbox-mutex mbox) 1000) - )))) + (sleep .05))))) (defimplementation quit-lisp () (ext:exit))

2 3

[armedbear-devel] Lisp->Java object conversion
by Alessio Stalla 25 Jun '09

25 Jun '09

ABCL has a built-in way of converting values from Java to Lisp: JavaObject.getInstance(x, true), which covers the most common cases. The contrary AFAIK is not as well-defined: conversion from Lisp to Java is done in ad-hoc ways all over the place. This is not optimal, especially for someone using abcl embedded into Java - someone who might not know the rules and conventions used in abcl. I believe the method LispObject.javaInstance(Class) could be used to provide such a conversion facility. Currently it has not very clear semantics: the one in LispObject does a type check to ensure "this" is an instance of the class passed as parameter, however there are overrides in subclasses which skip the check and happily return a value in all cases, ignoring the parameter. I propose the following unified semantics: x.javaInstance(c) returns a value (x itself, or some other object) that is guaranteed to be of class c (*) and to represent a value "similar" to x, for some meaning of "similar". If such a value cannot be produced, a type error is signaled. Examples: LispObject.javaInstance(Boolean.{class|TYPE}) ==> true if this != NIL, false otherwise LispObject.javaInstance(anythingelse) ==> this if (this instanceof anythingelse), error otherwise (like it does now) Nil.javaInstance(Boolean.{class|TYPE}) ==> false Nil.javaInstance(anything else) ==> null AbstractString.javaInstance(CharSequence and subclasses) ==> the string AbstractString.javaInstance(anything else) ==> error ...etc (numbers, what else?) ... I.e. in general x = y.javaInstance(c); JavaObject.getInstance(x, true).equals(y) ==> true and x = JavaObject.getInstance(y, true); x.javaInstance(y.getClass()).equals(y) ==> true What do you think? Bye, Ale --------------------- (*) or better, assignable to a variable of type c - this includes null while the former doesn't.

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.15.0
by Reinhard Oldenburg 25 Jun '09

25 Jun '09

Dear all, I failed to detect from the source code how to set the working directory from abcl at the lisp value. There is an inital directory in the Interpreter class, but there seems to be no way to change the directory after startup, or is there? Reinhard Oldenburg

2 1

[armedbear-devel] patch: dump-specials
by Alessio Stalla 24 Jun '09

24 Jun '09

Hello folks, I'll be the first to test the new mailing list ;) Some time ago I found myself in need of inspecting abcl's dynamic environment because I wanted to check if a certain variable was rebound somewhere. So, I added a DUMP-SPECIALS primitive that prints the dynamic environment as an alist, taking rebinding into account so that (cdr (assoc 'x (dump-specials))) is equivalent to (symbol-value 'x). I don't know if this functionality was already present, nor if it interests anyone, anyway here's the patch. Bye, Alessio

1 0

[armedbear-devel] Readably printing of #<SINGLE-FLOAT NaN>s and #<DOUBLE-FLOAT NaN>s
by Erik Huelsmann 15 Jun '09

15 Jun '09

Last week I found that - although I requested information to be printed readably - NaNs are printed unreadable, without generating an error. I'd really like to fix this, especially because it broke the expectation of readable input after succesfull save. At first, I thought I'd print it as #.SYS::SINGLE-FLOAT-NAN However, that has the disadvantage that it's definitely non-portable. However, some implementations have a mode where (/ 0.0s0 0.0s0) results in a NaN instead of a DIVISION-BY-ZERO. The new proposal is to print NaN as #.(/ 0.0s0 0.0s0) and #.(/ 0.0d0 0.0d0) respectively, if readable printing is requested; non-readable printing can stay as it is (ie using #<...>). That works (is readable input) for ABCL. For SBCL, this is readable input if it's in IEEE mode. With respect to any of the other Lisps, I have no idea. Comments? With kind regards, Erik.

1 0

[armedbear-devel] CFFI ported to ABCL
by Luís Oliveira 14 Jun '09

14 Jun '09

Hello, I have ported CFFI to ABCL using the Java Native Access (JNA) library. This is a preliminary version that will have to be cleaned up and optimized, etc. Nevertheless, at this point it passes all of the relevant CFFI tests except one. Callbacks and shareable vectors are not implemented yet. The former seem to require functionality that is not yet present in ABCL, IIUC. If anyone is interested in playing with this port, I have uploaded a patch to <http://common-lisp.net/~loliveira/patches/cffi-abcl.diff>. It requires trivial-features 0.5. Cheers. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/

1 0

[armedbear-devel] [ANNOUNCE] ABCL 0.15.0
by Erik Huelsmann 08 Jun '09

08 Jun '09

On behalf of the developers of ABCL (Armed Bear Common Lisp) - a lisp implementation running on the JVM - I'm glad to be able to announce the 0.15.0 release. This release features - among lots of other things - changes to support Google App Engine, another round of improvements in handling of special variables (compiled code) and a lot of improvements on handling closures (compiled code). Measured by the number of failing ANSI tests, this release is only a small step: most improvements were not detected as errors. Additionally some work has been done on improving performance. For a full list of changes see [1]. If you have questions regarding its license or use, or you find issues, please report back to the development list: armedbear-devel at common-lisp dot net The sources can be downloaded in ZIP or .tar.gz form from SourceForge: http://downloads.sourceforge.net/armedbear-j/abc/abcl-src-0.15.0.tgz http://downloads.sourceforge.net/armedbear-j/abc/abcl-src-0.15.0.zip Signatures will become available shortly. When they do, they will be available under: http://downloads.sourceforge.net/armedbear-j/abc/abcl-src-0.15.0.tgz.asc http://downloads.sourceforge.net/armedbear-j/abc/abcl-src-0.15.0.zip.asc Bye, Erik. [1] http://trac.common-lisp.net/armedbear/browser/trunk/abcl/CHANGES

1 1

Re: [armedbear-devel] [armedbear-cvs] r11589 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 26 Jan '09

26 Jan '09

Since several commits have trickled through which implement bits of what I'm doing, I thought it'd be a good idea to describe the outline of what's still to come. That makes it easier to judge the merits of the current commits too. The final goal of much of this is to start using the 'float' and 'double' JVM built-in types for floating point calculations whenever possible. The implementation of the above basically means: - The introduction of 2 new representations (:float and :double) - next to the three existing ones: NIL, :int and :long - Because of the number of representations, it's no longer viable to enumerate all possible representations separately (see the current implementation of p2-plus/p2-minus for what I mean: they have code special handling :int and :long representations) - Representation conversion becomes a bit tedious too: there will be 5 possible states, meaning we need a set of general purpose representation conversion routines - Adding additional opcodes (of which the commit below is an example) - Make 'SINGLE-FLOAT and 'DOUBLE-FLOAT supported compiler types - Extend type derivation routines to recognise 'single-float and 'double-float types Most of the above is in my working copy at home, for the case to implement p2-times, p2-plus and p2-minus with support for single and double float types. Over the next days, I hope to commit the content of my working copy in logical and coherent bits, instead of dumping all of the above on your heads :-) The above is mostly informative, but should you have any questions, please feel free to ask! Bye, Erik. On Mon, Jan 26, 2009 at 12:33 AM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Sun Jan 25 23:33:01 2009 > New Revision: 11589 > > Log: > Add stack information for opcodes we'll start using soon. > > Modified: > trunk/abcl/src/org/armedbear/lisp/opcodes.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/opcodes.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/opcodes.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/opcodes.lisp Sun Jan 25 23:33:01 2009 > @@ -150,16 +150,16 @@ > (define-opcode swap 95 1 0) > (define-opcode iadd 96 1 -1) > (define-opcode ladd 97 1 -2) > -(define-opcode fadd 98 1 nil) > -(define-opcode dadd 99 1 nil) > +(define-opcode fadd 98 1 -1) > +(define-opcode dadd 99 1 -2) > (define-opcode isub 100 1 -1) > (define-opcode lsub 101 1 -2) > (define-opcode fsub 102 1 nil) > (define-opcode dsub 103 1 nil) > (define-opcode imul 104 1 -1) > (define-opcode lmul 105 1 -2) > -(define-opcode fmul 106 1 nil) > -(define-opcode dmul 107 1 nil) > +(define-opcode fmul 106 1 -1) > +(define-opcode dmul 107 1 -2) > (define-opcode idiv 108 1 nil) > (define-opcode ldiv 109 1 nil) > (define-opcode fdiv 110 1 nil) > @@ -186,14 +186,14 @@ > (define-opcode lxor 131 1 -2) > (define-opcode iinc 132 3 0) > (define-opcode i2l 133 1 1) > -(define-opcode i2f 134 1 nil) > -(define-opcode i2d 135 1 nil) > +(define-opcode i2f 134 1 0) > +(define-opcode i2d 135 1 1) > (define-opcode l2i 136 1 -1) > (define-opcode l2f 137 1 nil) > -(define-opcode l2d 138 1 nil) > +(define-opcode l2d 138 1 0) > (define-opcode f2i 139 1 nil) > (define-opcode f2l 140 1 nil) > -(define-opcode f2d 141 1 nil) > +(define-opcode f2d 141 1 1) > (define-opcode d2i 142 1 nil) > (define-opcode d2l 143 1 nil) > (define-opcode d2f 144 1 nil) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] Is Israel a Democracy? -- The problem with intellectually insecure whites -- Should Christians Support Israeli Terrorism in Gaza?
by Lawrence Auster 23 Jan '09

23 Jan '09

The Jewish State of Israel has no constitution, nor does it name its borders. Israel's hidden constitution is Judaism. Israel's undeclared borders range from the Nile to the Euphrates rivers. Israel's desired jurisdiction extends over the entire Earth. It could not be more clear that the Jewish State follows a foreign policy which obeys Jewish Law as iterated in the Hebrew Bible, the Talmud, Maimonedes, the Cabalah, and the many commentaries and refinements of same. The Jews are genociding the native inhabitants of Palestine, just as their religion advises, and because their religion teaches them to do so. They treat non-Jews as if non-humans, just as their religion requires them to do. They make perpetual war on every nation on Earth, just as their genocidal Jewish God has instructed. The Jews of Israel are simply being Jews. Jews are an existential threat to the human race. Israel contains one third of the Jews of the World. It is not some aberration of the Jewish spirit, but the condensation and concentration of the perverse Jewish mentality, which malady also pervades the remaining two thirds of Jewry, who almost unanimously support the Jewish State, and who certainly do unanimously support the Jewish People and its consistent and constant crimes against the human race. Israel is Jewry and the danger of Israel is the danger of the Jewish People to all others, as the Jews have demonstrated each and every day of their existence. The Jews, the entire Jewish People of 15 million, will not relent until they have wiped out all non-Jews in "Greater Israel". They will not stop destroying all other cultures, nations, religions, ethnicities, races, competition, etc. until they are either stopped, or succeed in their ancient quest to destroy the human race. What Israel is doing is not some reaction to outside forces, nor was the formation of Israel a response to the Holocaust. Israel is simply following the plan laid out in the Jews' religious texts. The Jews have openly planned to take Palestine and genocide the native population of Palestine for some 2,500 years before the Holocaust. The Jews have openly complained that "anti-Semitism" is a threat that gives them the right to genocide the Palestinians, not merely since the advent of Nazism, but for some 2,500 years. The Jewish religion is the Constitution of the Jewish State of Israel, and, to a greater or lesser extent, the constitution of the nature of every Jew alive. The borders of Israel are the range the Jew roams over the entire World. The perverse Jewish mentality is inbred by a Jew's exposure to his parents and to his community. Judaism passes in the spit and slobber of Jewish mother telling her Jewish child that he is a "Jew", as much as Judaism passes in the poison and pain of a Talmudic tractate. The secular Jews did not suddenly come to life after the Enlightenment and the Jewish Reformation a body of vampires that appeared ex nihilo, in vacuo, mostly atheistical and undetached from formally practiced Judaism. Judaism is the Jew. It is a mindset that transcends and supercedes religion. It is a belief set, a way of life, a perception of one's self and one's relation to the World that makes a Jew, a Jew, and a danger to all of humanity. In fact, the religious shell of Judaism is like the stretched and infected skin of a lycanthropic pustule. When you lance it to cure the infection, the virus only becomes more contagious and spills directly on the non-Jew. The secular Jew is a deliberate product of the hyper-religious Jew, a monster created out of the hewed corpses of the fanatically religious Jew, a Golem which is conjured up to enter the World of the non-Jew and poison its blood, and boil its brain with a rabid lunacy that bites and spreads, until the infected community feeds on itself and fills the fields with rotting bloating bodies, where once human beings tilled the soil and tended to their families. The religious Jew created the secular Jew as an army of Esthers who seduce with open thighs, broad smiles, and a Siren call that lures in the non-Jew to cast his skull upon the jagged rocks and color the seas with his blood, sickened and blinded by the venereal disease of Judaism in secular form. Israel is not a secular democracy. It is a religious mockery. It is a rabid bat flying to the ends of the Earth, to end the Earth. No one will be free nor safe until the disease is quarantined and dies out. Source: http://www.ziopedia.org/articles/israel/how_can_israel_claim_to_be_a_%27dem… -------------------- The problem with intellectually insecure whites By Kevin MacDonald January 19, 2009 America will soon have a white minority. This is a much desired state of affairs for the hostile elites who hold political power and shape public opinion. But it certainly creates some management issues � at least in the long run. After all, it�s difficult to come up with an historical example of a nation with a solid ethnic majority (90% white in 1950) that has voluntarily decided to cede political and cultural power. Such transformations are typically accomplished by military invasions, great battles, and untold suffering. And it�s not as if everyone is doing it. Only Western nations view their own demographic and cultural eclipse as a moral imperative. Indeed, as I have noted previously, it is striking that racial nationalism has triumphed in Israel at the same time that the Jewish intellectual and political movements and the organized Jewish community have been the most active and effective force for a non-white America. Indeed, a poll in 2008 found that Avigdor Lieberman was the second most popular politician in Israel. Lieberman has advocated expulsion of Arabs from Israel and has declared himself a follower of Vladimir Jabotinsky, the leading pioneer of racial Zionism. The most popular politician in the poll was Benjamin Netanyahu � another admirer of Jabotinsky. Prime Minister Ehud Olmert and Foreign Minister Tzipi Livni are also Jabotinskyists. The racial Zionists are now carrying out yet another orgy of mass murder after a starvation-inducing blockade and the usual triggering assault designed to provoke Palestinian retaliation � which then becomes the cover for claims that Israel is merely defending itself against terrorism. This monstrosity was approved by overwhelming majorities of both Houses of Congress. The craven Bush administration did its part by abstaining from a UN resolution designed by the US Secretary of State as a result of a personal appeal by the Israeli Prime Minister. This is yet another accomplishment of the Israel Lobby, but one they would rather not have discussed in public. People might get the impression that the Lobby really does dictate US foreign policy in the Mideast. Obviously, such thoughts are only entertained by anti-Semites. But I digress. In managing the eclipse of white America, one strategy of the mainstream media is to simply ignore the issue. Christopher Donovan (�For the media, the less whites think about their coming minority status, the better�) has noted that the media, and in particular, the New York Times, are quite uninterested in doing stories that discuss what white people think about this state of affairs. It�s not surprising that the New York Times � the Jewish-owned flagship of anti-white, pro-multicultural media � ignores the issue. The issue is also missing from so-called conservative media even though one would think that conservatives would find the eclipse of white America to be an important issue. Certainly, their audiences would find it interesting. Now we have an article �The End of White America� written by Hua Hsu, an Assistant Professor of English at Vassar College. The article is a rather depressing display of what passes for intellectual discourse on the most important question confronting white people in America. Hsu begins by quoting a passage in F. Scott Fitzgerald�s The Great Gatsby in which a character, Tom Buchanan, states: �Have you read The Rise of the Colored Empires by this man Goddard?� � Well, it�s a fine book, and everybody ought to read it. The idea is if we don�t look out the white race will be�will be utterly submerged. It�s all scientific stuff; it�s been proved.� Buchanan�s comment is a thinly veiled reference to Lothrop Stoddard�s The Rising Tide of Color which Hsu describes as �rationalized hatred� presented in a scholarly, gentlemanly, and scientific tone. (This wording that will certainly help him when he comes up for tenure.) As Hsu notes, Stoddard had a doctorate from Harvard and was a member of many academic associations. His book was published by a major publisher. It was therefore �precisely the kind of book that a 1920s man of Buchanan�s profile � wealthy, Ivy League�educated, at once pretentious and intellectually insecure � might have been expected to bring up in casual conversation.� Let�s ponder that a bit. The simple reality is that in the year 2009 an Ivy League-educated person, "at once pretentious and intellectually insecure," would just as glibly assert the same sort of nonsense as Hsu. To wit: The coming white minority does not mean that the racial hierarchy of American culture will suddenly become inverted, as in 1995�s White Man�s Burden, an awful thought experiment of a film, starring John Travolta, that envisions an upside-down world in which whites are subjugated to their high-class black oppressors. There will be dislocations and resentments along the way, but the demographic shifts of the next 40 years are likely to reduce the power of racial hierarchies over everyone�s lives, producing a culture that�s more likely than any before to treat its inhabitants as individuals, rather than members of a caste or identity group. The fact is that no one can say for certain what multicultural America without a white majority will be like. There is no scientific or historical basis for claims like �the demographic shifts of the next 40 years are likely to reduce the power of racial hierarchies over everyone�s lives, producing a culture that�s more likely than any before to treat its inhabitants as individuals, rather than members of a caste or identity group.� Indeed, there is no evidence at all that we are proceeding to a color blind future. The election results continue to show that white people are coalescing in the Republican Party, while the Democrats are increasingly the party of a non-white soon-to-be majority. Is it so hard to believe that when this coalition achieves a majority that it will further compromise the interests of whites far beyond contemporary concerns such as immigration policy and affirmative action? Hsu anticipates a colorblind world, but affirmative action means that blacks and other minorities are certainly not treated as individuals. And it means that whites � especially white males � are losing out on opportunities they would have had without these policies and without the massive non-white immigration of the last few decades. Given the intractability of changing intelligence and other traits required for success in the contemporary economy, it is unlikely that 40 more years of affirmative action will attain the outcomes desired by the minority lobbies. Indeed, in Obama's America, blacks are rioting in Oakland over perceived racial injustices, and from 2002 �2007, black juvenile homicide victims increased 31%, while black juvenile homicide perpetrators increased 43%. Hence, the reasonable outlook is for a continuing need for affirmative action and for racial activism in these groups, even after whites become a minority. Whites will also lose out because of large-scale importation of relatively talented immigrants from East Asia. Indeed, as I noted over a decade ago, "The United States is well on the road to being dominated by an Asian technocratic elite and a Jewish business, professional, and media elite." Hsu shows that there already is considerable anxiety among whites about the future. An advertizing executive says, �I think white people feel like they�re under siege right now � like it�s not okay to be white right now, especially if you�re a white male. ... People are stressed out about it. �We used to be in control! We�re losing control�� Another says, "There�s a lot of fear and a lot of resentment." It's hard to see why these feelings won't increase in the future. A huge problem for white people is lack of intellectual and cultural confidence. Hsu quotes Christian (Stuff White People Like) Lander saying, "I get it: as a straight white male, I�m the worst thing on Earth." A professor comments that for his students "to be white is to be culturally broke. The classic thing white students say when you ask them to talk about who they are is, �I don�t have a culture.� They might be privileged, they might be loaded socioeconomically, but they feel bankrupt when it comes to culture � They feel disadvantaged, and they feel marginalized." This lack of cultural confidence is no accident. For nearly 100 years whites have been subjected to a culture of critique emanating from the most prestigious academic and media institutions. And, as Hsu points out, the most vibrant and influential aspect of American popular culture is hip-hop�a product of the African American urban culture. The only significant group of white people with any cultural confidence centers itself around country music, NASCAR, and the small town values of traditional white America. For this group of whites � and only this group � there is "a racial pride that dares not speak its name, and that defines itself through cultural cues instead�a suspicion of intellectual elites and city dwellers, a preference for folksiness and plainness of speech (whether real or feigned), and the association of a working-class white minority with 'the real America.'� This is what I term implicit whiteness � implicit because explicit assertions of white identity have been banned by the anti-white elites that dominate our politics and culture. It is a culture that, as Hsu notes, "cannot speak its name." But that implies that the submerged white identity of the white working class and the lack of cultural confidence exhibited by the rest of white America are imposed from outside. Although there may well be characteristics of whites that facilitate this process, this suppression of white identity and interests is certainly not the natural outcome of modernization or any other force internal to whites as a people. In my opinion, it is the result of the successful erection of a culture of critique in the West dominated by Jewish intellectual and political movements. The result is that educated, intellectually insecure white people these days are far more likely to believe in the utopian future described by Hsu than in hard and cautious thinking about what the future might have in store for them. It's worth dwelling a bit on the intellectual insecurity of the whites who mindlessly utter the mantras of multiculturalism that they have soaked up from the school system and from the media. Most people do not have much confidence in their intellectual ability and look to elite opinion to shape their beliefs. As I noted elsewhere, A critical component of the success of the culture of critique is that it achieved control of the most prestigious and influential institutions of the West, and it became a consensus among the elites, Jewish and non-Jewish alike. Once this happened, it is not surprising that this culture became widely accepted among people of very different levels of education and among people of different social classes. Most people are quite insecure about their intellectual ability. But they know that the professors at Harvard, and the editorial page of the New York Times and the Washington Post, and even conservative commentators like Rush Limbaugh and Sean Hannity are all on page when it comes to racial and ethnic issues. This is a formidable array, to the point that you almost have to be a crank to dissent from this consensus. I think one of the greatest triumphs of the left has been to get people to believe that people who assert white identity and interests or who make unflattering portrayals of organized Jewish movements are morally degenerate, stupid, and perhaps psychiatrically disturbed. Obviously, all of these adjectives designate low status. The reality is that the multicultural emperor has no clothes and, because of its support for racial Zionism and the racialism of ethnic minorities in America, it is massively hypocritical to boot. The New York Times, the academic left, and the faux conservatives that dominate elite discourse on race and ethnicity are intellectually bankrupt and can only remain in power by ruthlessly suppressing or ignoring the scientific findings. This is particularly a problem for college-educated whites. Like Fitzgerald's Tom Buchanan, such people have a strong need to feel that their ideas are respectable and part of the mainstream. But the respectable mainstream gives them absolutely nothing with which to validate themselves except perhaps the idea that the world will be a better place when people like them no longer have power. Hsu quotes the pathetic Christian Lander: "�Like, I�m aware of all the horrible crimes that my demographic has done in the world. ... And there�s a bunch of white people who are desperate � desperate � to say, �You know what? My skin�s white, but I�m not one of the white people who�s destroying the world.�� As a zombie leftist during the 1960s and 1970s, I know what that feeling of desperation is like � what it's like to be a self-hating white. We must get to the point where college-educated whites proudly and confidently say they are white and that they do not want to become a minority in America. This reminds me of the recent docudrama Milk, which depicts the life of gay activist Harvey Milk. Milk is sure be nominated for an Oscar as Best Picture because it lovingly illustrates a triumph of the cultural left. But is has an important message that should resonate with the millions of whites who have been deprived of their confidence and their culture: Be explicit. Just as Harvey Milk advocated being openly gay even in the face of dire consequences, whites need to tell their family and their friends that they have an identity as a white person and believe that whites have legitimate interests as white people. They must accept the consequences when they are harassed, fired from their jobs, or put in prison for such beliefs. They must run for political office as openly pro-white. Milk shows that homosexuals were fired from their jobs and arrested for congregating in public. Now it's the Southern Poverty Law Center and the rest of the leftist intellectual and political establishment that harasses and attempts to get people fired. But it's the same situation with the roles reversed. No revolution was ever accomplished without some martyrs. The revolution that restores the legitimacy of white identity and the legitimacy of white interests will be no exception. But it is a revolution that is absolutely necessary. The white majority is foolish indeed to entrust its future to a utopian hope that racial and ethnic identifications will disappear and that they won�t continue to influence public policy in ways that compromise the interests of whites. It does not take an overactive imagination to see that coalitions of minority groups could compromise the interests of formerly dominant whites. We already see numerous examples in which coalitions of minority groups attempt to influence public policy, including immigration policy, against the interests of the whites. Placing ourselves in a position of vulnerability would be extremely risky, given the deep sense of historical grievance fostered by many ethnic activists and organized ethnic lobbies. This is especially the case with Jews. Jewish organisations have been unanimous in condemning Western societies, Western traditions, and Christianity, for past crimes against Jews. Similar sentiments are typical of a great many African Americans and Latinos, and especially among the ethnic activists from these groups. The �God damn America� sermon by President Obama's pastor comes to mind as a recent notorious example. The precedent of the early decades of the Soviet Union should give pause to anyone who believes that surrendering ethnic hegemony does not carry risks. The Bolshevik revolution had a pronounced ethnic angle: To a very great extent, Jews and other non-Russians ruled over the Russian people, with disastrous consequences for the Russians and other ethnic groups that were not able to become part of the power structure. Jews formed a hostile elite within this power structure � as they will in the future white-minority America; Jews were �Stalin�s willing executioners.� Two passages from my review of Yuri Slezkine's The Jewish Century seem particularly appropriate here. The first passage reminds me of the many American Jews who adopt a veneer of support for leftist versions of social justice and racial tolerance while nevertheless managing to support racial Zionism and the mass murder, torture, and incarceration of the Palestinian people in one of the largest prison systems the world has ever seen. Such people may be very different when they become a hostile elite in a white-minority America. Many of the commentators on Jewish Bolsheviks noted the �transformation� of Jews [after the Bolshevik Revolution]. In the words of [a] Jewish commentator, G. A. Landau, �cruelty, sadism, and violence had seemed alien to a nation so far removed from physical activity.� And another Jewish commentator, Ia. A. Bromberg, noted that: the formerly oppressed lover of liberty had turned into a tyrant of �unheard-of-despotic arbitrariness��. The convinced and unconditional opponent of the death penalty not just for political crimes but for the most heinous offenses, who could not, as it were, watch a chicken being killed, has been transformed outwardly into a leather-clad person with a revolver and, in fact, lost all human likeness. ... After the Revolution, ... there was active suppression of any remnants of the older order and their descendants. ... The mass murder of peasants and nationalists was combined with the systematic exclusion of the previously existing non-Jewish middle class. The wife of a Leningrad University professor noted, �in all the institutions, only workers and Israelites are admitted; the life of the intelligentsia is very hard� (p. 243). Even at the end of the 1930s, prior to the Russification that accompanied World War II, �the Russian Federation�was still doing penance for its imperial past while also serving as an example of an ethnicity-free society� (p. 276). While all other nationalities, including Jews, were allowed and encouraged to keep their ethnic identities, the revolution remained an anti-majoritarian movement. The difference from the Soviet Union may well be that in white-minority America it will not be workers and Israelites who are favored, but non-whites and Israelites. Whites may dream that they are entering the post-racial utopia imagined by their erstwhile intellectual superiors. But it is quite possible that they are entering into a racial dystopia of unimaginable cruelty in which whites will be systematically excluded in favor of the new elites recruited from the soon-to-be majority. It's happened before. Kevin MacDonald is a professor of psychology at California State University�Long Beach. Permanent URL with hyperlinks: http://www.theoccidentalobserver.net/articles/MacDonald-Hsu.html ----------- Should Christians Support Israeli Terrorism in Gaza? A timely discussion between Rev. Ted Pike and Dr. David Duke, one especially important for the Christians in our audience http://www.davidduke.com/mp3/dukeradio090122DukeandPikeonGaza.mp3 In this vital discussion, Rev. Pike and Dr. Duke explore the Pro-Israel attitude of some Christian evangelical organizations, and why their position not only goes directly against Christian morality and decency, but actually is directly opposite of that expressed by Christian Scriptures. Today, Many Christians are instructed that Jews and today�s Israel has a special covenant� with God. In fact, the New Testament in the clearest of language states that the Jews �continued not in my covenant, and I considered them not, saith the Lord.� Here�s the quote that Christians aren�t supposed to notice.: 8:10 Not according to the covenant that I made with their fathers, in the day when I took them by the hand out of the land of Egypt; because they continued not in my covenant, and I regarded them not, saith the Lord. (Hebrews 8:10) They also don�t seem to notice that a 2000 year old Judaic war against Christianity that has been waged since time of Jesus Christ and still goes on today with the most powerful Jewish organizations attempting to destroy European and American traditions, that has even become a war on our Christmas traditions. Dr. Duke and Ted Pike also speak about how over a hundred thousand Christian Palestinians have suffered with their families from anti-Christian Israel! Christian support of Israel has resulted in the very birthplace of Jesus Christ, go from 90 percent Palestinian Christians to 35 percent today because of Israeli terror and occupation. They ask, �How could any Christian in good conscience support the anti-Christian state of Israel, bombing the homes, killing and maiming, torturing and oppressing fellow Christian men, women and children?� This is a vital show for every Christian reader and listener of DavidDuke.com. Next time, you hear someone say, �God tells us that we must support Israel� you will have the clear Christian answer that just the opposite is true! For documentation on this be sure to read some of the well-footnoted, sample chapters of Jewish Supremacism and My Awakening. Source : http://www.davidduke.com/general/should-christians-support-israeli-terroris… ------------------------------------- You or someone using your email adress is currently subscribed to the Lawrence Auster Newletter. If you wish to unsubscribe from our mailing list, please let us know by calling to 1 212 865 1284 Thanks, Lawrence Auster, 238 W 101 St Apt. 3B New York, NY 10025 Contact: lawrence.auster(a)att.net -------------------------------------

1 0

Re: [armedbear-devel] [armedbear-cvs] r11465 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 21 Dec '08

21 Dec '08

If you're using trunk, you'll need to delete your .abcl files after updating and building this commit: it changes the structure of the .cls files stored in the .abcl files. Bye, Erik. On Sun, Dec 21, 2008 at 11:16 PM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Sun Dec 21 22:16:29 2008 > New Revision: 11465 > > Log: > Make clear difference between calling the template evaluator or evaluating the object. (Relates to ClosureTemplateFunction.) > > Modified: > trunk/abcl/src/org/armedbear/lisp/ClosureTemplateFunction.java > trunk/abcl/src/org/armedbear/lisp/CompiledClosure.java > trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/ClosureTemplateFunction.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/ClosureTemplateFunction.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/ClosureTemplateFunction.java Sun Dec 21 22:16:29 2008 > @@ -33,42 +33,62 @@ > > package org.armedbear.lisp; > > -public abstract class ClosureTemplateFunction extends Closure > +public class ClosureTemplateFunction extends Closure > + implements Cloneable > { > + > + public LispObject[] ctx; > + > public ClosureTemplateFunction(LispObject lambdaList) > throws ConditionThrowable > { > super(list2(Symbol.LAMBDA, lambdaList), null); > } > > + public ClosureTemplateFunction setContext(LispObject[] context) > + { > + ctx = context; > + return this; > + } > + > + public ClosureTemplateFunction dup() > + throws CloneNotSupportedException > + { > + return (ClosureTemplateFunction)super.clone(); > + } > + > + > + > + // execute methods have the semantic meaning > + // "evaluate this object" > public final LispObject execute() throws ConditionThrowable > { > - return notImplemented(); > + return _execute(ctx); > } > > public final LispObject execute(LispObject arg) throws ConditionThrowable > { > - return notImplemented(); > + return _execute(ctx); > } > > public final LispObject execute(LispObject first, LispObject second) > throws ConditionThrowable > { > - return notImplemented(); > + return _execute(ctx, first, second); > } > > public final LispObject execute(LispObject first, LispObject second, > LispObject third) > throws ConditionThrowable > { > - return notImplemented(); > + return _execute(ctx, first, second, third); > } > > public final LispObject execute(LispObject first, LispObject second, > LispObject third, LispObject fourth) > throws ConditionThrowable > { > - return notImplemented(); > + return _execute(ctx, first, second, third, fourth); > } > > public final LispObject execute(LispObject first, LispObject second, > @@ -76,7 +96,7 @@ > LispObject fifth) > throws ConditionThrowable > { > - return notImplemented(); > + return _execute(ctx, first, second, third, fourth, fifth); > } > > public final LispObject execute(LispObject first, LispObject second, > @@ -84,7 +104,7 @@ > LispObject fifth, LispObject sixth) > throws ConditionThrowable > { > - return notImplemented(); > + return _execute(ctx, first, second, third, fourth, fifth, sixth); > } > > public final LispObject execute(LispObject first, LispObject second, > @@ -93,7 +113,7 @@ > LispObject seventh) > throws ConditionThrowable > { > - return notImplemented(); > + return _execute(ctx, first, second, third, fourth, fifth, sixth, seventh); > } > > public final LispObject execute(LispObject first, LispObject second, > @@ -102,7 +122,14 @@ > LispObject seventh, LispObject eighth) > throws ConditionThrowable > { > - return notImplemented(); > + return _execute(ctx, first, second, third, fourth, fifth, > + sixth, seventh, eighth); > + } > + > + public final LispObject execute(LispObject[] args) > + throws ConditionThrowable > + { > + return _execute(ctx, args); > } > > private final LispObject notImplemented() throws ConditionThrowable > @@ -110,35 +137,39 @@ > return error(new WrongNumberOfArgumentsException(this)); > } > > + > + // _execute methods have the semantic meaning > + // "evaluate this template with these values" > + > // Zero args. > - public LispObject execute(LispObject[] context) throws ConditionThrowable > + public LispObject _execute(LispObject[] context) throws ConditionThrowable > { > LispObject[] args = new LispObject[0]; > - return execute(context, args); > + return _execute(context, args); > } > > // One arg. > - public LispObject execute(LispObject[] context, LispObject first) > + public LispObject _execute(LispObject[] context, LispObject first) > throws ConditionThrowable > { > LispObject[] args = new LispObject[1]; > args[0] = first; > - return execute(context, args); > + return _execute(context, args); > } > > // Two args. > - public LispObject execute(LispObject[] context, LispObject first, > + public LispObject _execute(LispObject[] context, LispObject first, > LispObject second) > throws ConditionThrowable > { > LispObject[] args = new LispObject[2]; > args[0] = first; > args[1] = second; > - return execute(context, args); > + return _execute(context, args); > } > > // Three args. > - public LispObject execute(LispObject[] context, LispObject first, > + public LispObject _execute(LispObject[] context, LispObject first, > LispObject second, LispObject third) > throws ConditionThrowable > { > @@ -146,11 +177,11 @@ > args[0] = first; > args[1] = second; > args[2] = third; > - return execute(context, args); > + return _execute(context, args); > } > > // Four args. > - public LispObject execute(LispObject[] context, LispObject first, > + public LispObject _execute(LispObject[] context, LispObject first, > LispObject second, LispObject third, > LispObject fourth) > throws ConditionThrowable > @@ -160,11 +191,11 @@ > args[1] = second; > args[2] = third; > args[3] = fourth; > - return execute(context, args); > + return _execute(context, args); > } > > // Five args. > - public LispObject execute(LispObject[] context, LispObject first, > + public LispObject _execute(LispObject[] context, LispObject first, > LispObject second, LispObject third, > LispObject fourth, LispObject fifth) > throws ConditionThrowable > @@ -175,11 +206,11 @@ > args[2] = third; > args[3] = fourth; > args[4] = fifth; > - return execute(context, args); > + return _execute(context, args); > } > > // Six args. > - public LispObject execute(LispObject[] context, LispObject first, > + public LispObject _execute(LispObject[] context, LispObject first, > LispObject second, LispObject third, > LispObject fourth, LispObject fifth, > LispObject sixth) > @@ -192,11 +223,11 @@ > args[3] = fourth; > args[4] = fifth; > args[5] = sixth; > - return execute(context, args); > + return _execute(context, args); > } > > // Seven args. > - public LispObject execute(LispObject[] context, LispObject first, > + public LispObject _execute(LispObject[] context, LispObject first, > LispObject second, LispObject third, > LispObject fourth, LispObject fifth, > LispObject sixth, LispObject seventh) > @@ -210,11 +241,11 @@ > args[4] = fifth; > args[5] = sixth; > args[6] = seventh; > - return execute(context, args); > + return _execute(context, args); > } > > // Eight args. > - public LispObject execute(LispObject[] context, LispObject first, > + public LispObject _execute(LispObject[] context, LispObject first, > LispObject second, LispObject third, > LispObject fourth, LispObject fifth, > LispObject sixth, LispObject seventh, > @@ -230,11 +261,11 @@ > args[5] = sixth; > args[6] = seventh; > args[7] = eighth; > - return execute(context, args); > + return _execute(context, args); > } > > // Arg array. > - public LispObject execute(LispObject[] context, LispObject[] args) > + public LispObject _execute(LispObject[] context, LispObject[] args) > throws ConditionThrowable > { > return notImplemented(); > > Modified: trunk/abcl/src/org/armedbear/lisp/CompiledClosure.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/CompiledClosure.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/CompiledClosure.java Sun Dec 21 22:16:29 2008 > @@ -53,32 +53,32 @@ > > public LispObject execute() throws ConditionThrowable > { > - return ctf.execute(context); > + return ctf._execute(context); > } > > public LispObject execute(LispObject arg) throws ConditionThrowable > { > - return ctf.execute(context, arg); > + return ctf._execute(context, arg); > } > > public LispObject execute(LispObject first, LispObject second) > throws ConditionThrowable > { > - return ctf.execute(context, first, second); > + return ctf._execute(context, first, second); > } > > public LispObject execute(LispObject first, LispObject second, > LispObject third) > throws ConditionThrowable > { > - return ctf.execute(context, first, second, third); > + return ctf._execute(context, first, second, third); > } > > public LispObject execute(LispObject first, LispObject second, > LispObject third, LispObject fourth) > throws ConditionThrowable > { > - return ctf.execute(context, first, second, third, fourth); > + return ctf._execute(context, first, second, third, fourth); > } > > public LispObject execute(LispObject first, LispObject second, > @@ -86,7 +86,7 @@ > LispObject fifth) > throws ConditionThrowable > { > - return ctf.execute(context, first, second, third, fourth, fifth); > + return ctf._execute(context, first, second, third, fourth, fifth); > } > > public LispObject execute(LispObject first, LispObject second, > @@ -94,7 +94,7 @@ > LispObject fifth, LispObject sixth) > throws ConditionThrowable > { > - return ctf.execute(context, first, second, third, fourth, fifth, sixth); > + return ctf._execute(context, first, second, third, fourth, fifth, sixth); > } > > public LispObject execute(LispObject first, LispObject second, > @@ -103,7 +103,7 @@ > LispObject seventh) > throws ConditionThrowable > { > - return ctf.execute(context, first, second, third, fourth, fifth, sixth, > + return ctf._execute(context, first, second, third, fourth, fifth, sixth, > seventh); > } > > @@ -113,12 +113,12 @@ > LispObject seventh, LispObject eighth) > throws ConditionThrowable > { > - return ctf.execute(context, first, second, third, fourth, fifth, sixth, > + return ctf._execute(context, first, second, third, fourth, fifth, sixth, > seventh, eighth); > } > > public LispObject execute(LispObject[] args) throws ConditionThrowable > { > - return ctf.execute(context, args); > + return ctf._execute(context, args); > } > } > > Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp Sun Dec 21 22:16:29 2008 > @@ -8939,7 +8939,14 @@ > super) > (*child-p* > (if *closure-variables* > - +lisp-ctf-class+ > + (progn > + (setf execute-method-name > + (setf (method-name execute-method) "_execute")) > + (setf (method-name-index execute-method) > + (pool-name (method-name execute-method))) > + (setf (method-descriptor-index execute-method) > + (pool-name (method-descriptor execute-method))) > + +lisp-ctf-class+) > (if *hairy-arglist-p* > +lisp-compiled-function-class+ > +lisp-primitive-class+))) > @@ -9251,4 +9258,4 @@ > (initialize-p2-handlers) > > > -(provide "COMPILER-PASS2") > \ No newline at end of file > +(provide "COMPILER-PASS2") > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0

[armedbear-devel] EXTERNAL-FORMAT support r11409 - branches/open-external-format/
by Erik Huelsmann 01 Dec '08

01 Dec '08

With the commit below, there's infrastructure for general streams to do character encoding and generate a specified line-ending style. It behaves like this: * output: '\n' is translated into - '\r' if :EOL-STYLE is :CR - "\r\n" if :EOL-STYLE is :CRLF - '\n' if :EOL-STYLE is :LF, :RAW * input: '\r" is translated to '\n' for :EOL-STYLE :CR "\r\n" is translated to '\n' for :EOL-STYLE :CRLF '\n' untouched for :EOL-STYLE :LF or :RAW As you see we don't detect \r\n, \r, \n all as end-of-lines, recoding them when required. This is inconsistent with what Subversion does; however, I'm modelling our EXTERNAL-FORMAT support after flexi-streams, so, it needs some investigation to see whether we're actually compatible in that area. Bye, Erik. On Mon, Dec 1, 2008 at 12:05 AM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Sun Nov 30 23:05:51 2008 > New Revision: 11409 > > Log: > End-of-line translation for generic streams. > > Modified: > branches/open-external-format/src/org/armedbear/lisp/Stream.java > > Modified: branches/open-external-format/src/org/armedbear/lisp/Stream.java > ============================================================================== > --- branches/open-external-format/src/org/armedbear/lisp/Stream.java (original) > +++ branches/open-external-format/src/org/armedbear/lisp/Stream.java Sun Nov 30 23:05:51 2008 > @@ -1760,13 +1760,19 @@ > { > int n = reader.read(); > ++offset; > - if (n == '\r') > - { > - if (interactive && Utilities.isPlatformWindows) > - return _readChar(); > - } > - if (n == '\n') > + if (eolStyle == EolStyle.CRLF && n == '\r') { > + n = _readChar(); > + if (n != '\n') { > + _unreadChar(n); > + return '\r'; > + } > + } > + > + if (n == eolChar) { > ++lineNumber; > + return '\n'; > + } > + > return n; > } > catch (NullPointerException e) > @@ -1793,7 +1799,7 @@ > { > reader.unread(n); > --offset; > - if (n == '\n') > + if (n == eolChar) > --lineNumber; > } > catch (NullPointerException e) > @@ -1841,14 +1847,16 @@ > { > try > { > - writer.write(c); > - if (c == '\n') > - { > - writer.flush(); > - charPos = 0; > - } > - else > + if (c == '\n') { > + if (eolStyle == EolStyle.CRLF) > + writer.write('\r'); > + writer.write(eolChar); > + writer.flush(); > + charPos = 0; > + } else { > + writer.write(c); > ++charPos; > + } > } > catch (NullPointerException e) > { > @@ -1874,6 +1882,13 @@ > { > try > { > + if (eolStyle != EolStyle.RAW) { > + for (int i = start; i++ < end;) > + //###FIXME: the number of writes can be greatly reduced by > + // writing the space between newlines as chunks. > + _writeChar(chars[i]); > + } > + > writer.write(chars, start, end - start); > int index = -1; > for (int i = end; i-- > start;) > @@ -1918,15 +1933,10 @@ > { > try > { > - writer.write(s); > - int index = s.lastIndexOf('\n'); > - if (index < 0) > - charPos += s.length(); > - else > - { > - charPos = s.length() - (index + 1); > - writer.flush(); > - } > + for (int i = 0; i++ < s.length();) > + //###FIXME: the number of writes can be greatly reduced by > + // writing the space between newlines as chunks. > + _writeChar(s.charAt(i)); > } > catch (NullPointerException e) > { > @@ -1935,10 +1945,6 @@ > else > throw e; > } > - catch (IOException e) > - { > - error(new StreamError(this, e)); > - } > } > > /** Writes a string to the underlying stream, appending > @@ -1951,20 +1957,14 @@ > { > try > { > - writer.write(s); > - writer.write('\n'); > - writer.flush(); > - charPos = 0; > + _writeString(s); > + _writeChar('\n'); > } > catch (NullPointerException e) > { > // writer is null > streamNotCharacterOutputStream(); > } > - catch (IOException e) > - { > - error(new StreamError(this, e)); > - } > } > > // Reads an 8-bit byte. > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

1 0