armedbear-devel

armedbear-devel@common-lisp.net

1199 discussions

[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 24 Jan '10

24 Jan '10

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

1 0

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

24 Jan '10

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel