- 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