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

[armedbear-devel] toplevel MACROLET bug?
by William Wadsworth 21 Jun '10

21 Jun '10

Dear List, Nice work going on on the ABCL compiler. Thanks. I have a file test1.lisp: ----- (in-package #:cl-user) (macrolet ((%mac () '(+ 1 1))) (defun test () (%mac))) ---- Compiling it: CL-USER(1): :cf test1.lisp ; Compiling test1.lisp ... ; (IN-PACKAGE #:CL-USER) ; (DEFUN TEST ...) ; Compilation unit finished ; The following functions were used but not defined: ; %MAC I am not 100% sure, but I think the %MAC should be visible within TEST. --- Martin.

2 1

[armedbear-devel] CL:FLOAT on Java Number objects could call {single, double}Float() on them
by Mario Lang 19 Jun '10

19 Jun '10

Hi. Along the lines of the previously submitted string conversion patch, here is some other possible interoperability thing. Index: src/org/armedbear/lisp/SingleFloat.java =================================================================== --- src/org/armedbear/lisp/SingleFloat.java (revision 12758) +++ src/org/armedbear/lisp/SingleFloat.java (working copy) @@ -635,6 +635,11 @@ return new SingleFloat(((Bignum)obj).floatValue()); if (obj instanceof Ratio) return new SingleFloat(((Ratio)obj).floatValue()); + if (obj instanceof JavaObject) { + final Object jobj = ((JavaObject)obj).getObject(); + if (jobj instanceof Number) + return new SingleFloat(((Number)jobj).floatValue()); + } error(new TypeError("The value " + obj.writeToString() + " cannot be converted to type SINGLE-FLOAT.")); // Not reached. Index: src/org/armedbear/lisp/DoubleFloat.java =================================================================== --- src/org/armedbear/lisp/DoubleFloat.java (revision 12758) +++ src/org/armedbear/lisp/DoubleFloat.java (working copy) @@ -646,6 +646,11 @@ return new DoubleFloat(((SingleFloat)obj).value); if (obj instanceof Ratio) return new DoubleFloat(((Ratio)obj).doubleValue()); + if (obj instanceof JavaObject) { + final Object jobj = ((JavaObject)obj).getObject(); + if (jobj instanceof Number) + return new DoubleFloat(((Number)jobj).doubleValue()); + } error(new TypeError("The value " + obj.writeToString() + " cannot be converted to type DOUBLE-FLOAT.")); // Not reached. P.S.: The following conditional is duplicated and could be removed: Index: src/org/armedbear/lisp/Pathname.java =================================================================== --- src/org/armedbear/lisp/Pathname.java (revision 12758) +++ src/org/armedbear/lisp/Pathname.java (working copy) @@ -1290,7 +1290,7 @@ if (host == NIL) { host = defaults.host; } - if (directory == NIL && defaults != null) { + if (directory == NIL) { directory = defaults.directory; } if (!deviceSupplied) { -- CYa, ⡍⠁⠗⠊⠕

1 0

[armedbear-devel] SLOT-VALUE and SLOT-VALUE-USING-CLASS with DEFSTRUCT
by William Wadsworth 18 Jun '10

18 Jun '10

Hi. The following transcript demonstrates the problem. --- BEGIN Armed Bear Common Lisp 0.20.0 Java 1.6.0_20 Sun Microsystems Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.667 seconds. Startup completed in 4.849 seconds. Type ":help" for a list of available commands. CL-USER(1): (defstruct x a b c) X CL-USER(2): (slot-value (make-x :a 10) 'a) #<THREAD "interpreter" {118958E}>: Debugger invoked on condition of type UNDEFINED-FUNCTION The function SLOT-VALUE is undefined. Restarts: 0: CONTINUE Try again. 1: USE-VALUE Specify a function to call instead. 2: RETURN-VALUE Return one or more values from the call to SLOT-VALUE. 3: TOP-LEVEL Return to top level. [1] CL-USER(3): :res CL-USER(4): (slot-value (make-x :a 10) 'a) #<THREAD "interpreter" {118958E}>: Debugger invoked on condition of type SIMPLE-ERROR There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION MOP::SLOT-VALUE-USING-CLASS {932FE} > when called with arguments (#<STRUCTURE-CLASS X {11EF443}> #<X {1184326}> A). Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(5): :res CL-USER(6): --- END DEFCLASS seems to work fine, though I would like to keep using DEFSTRUCT. I understand that the MOP is not really complete. However, Is there a workaround that will not resort in using DEFCLASS? --- Martin.

3 5

[armedbear-devel] JVM Compilation
by Mark Evenson 17 Jun '10

17 Jun '10

http://nerds-central.blogspot.com/2009/09/tuning-jvm-for-unusual-uses-have-… Tersely written from my iPod

2 2

Re: [armedbear-devel] SLOT-VALUE and SLOT-VALUE-USING-CLASS with DEFSTRUCT
by William Wadsworth 17 Jun '10

17 Jun '10

Hi Eric, (Apologies for the belated reply, just saw the message today.) On Mon, Jun 14, 2010 at 9:26 PM, Erik Huelsmann <ehuels(a)gmail.com> wrote: > Hi William, > > Thanks for your report below! > > On Mon, Jun 14, 2010 at 4:09 AM, William Wadsworth > <will.wadsworth.10(a)gmail.com> wrote: >> Hi. >> >> The following transcript demonstrates the problem. >> >> --- BEGIN >> Armed Bear Common Lisp 0.20.0 >> Java 1.6.0_20 Sun Microsystems Inc. >> Java HotSpot(TM) Client VM >> Low-level initialization completed in 0.667 seconds. >> Startup completed in 4.849 seconds. >> Type ":help" for a list of available commands. >> CL-USER(1): (defstruct x a b c) >> X >> CL-USER(2): (slot-value (make-x :a 10) 'a) >> #<THREAD "interpreter" {118958E}>: Debugger invoked on condition of >> type UNDEFINED-FUNCTION >> The function SLOT-VALUE is undefined. > > Well, you seem to have identified an issue here: you're correct our > MOP isn't fully complete, but it's not *that* bad. The function is > defined in clos.lisp. However, loading of that file happens on the > first use of one of the functions inside it. But: there's no trigger > installed on the function to trigger autoloading. > > It seems we need a list of all functions exported from clos.lisp in > order to fix up the auto-loading triggers. Could you create a list > like that? > I don't know whether I read you clearly, but using the following snippet I got the (manually flattened) results below it: (let ((file #P"clos.lisp")) (with-open-file (in file) (loop for form = (read in nil nil) while form when (and (listp form) (eq (car form) 'cl:export)) nconcing (cdr form)))) CLASS-PRECEDENCE-LIST CLASS-SLOTS COMPUTE-APPLICABLE-METHODS COMPUTE-APPLICABLE-METHODS-USING-CLASSES SLOT-DEFINITION-ALLOCATION SLOT-DEFINITION-INITARGS SLOT-DEFINITION-INITFORM SLOT-DEFINITION-INITFUNCTION SLOT-DEFINITION-NAME (Meanwhile, let me see what I can achieve by modifying autoloads.lisp and/or AutoLoads.java?) > > In order to see if a small commit would help you out, I added this > form to the beginning of your transcript: > > (autoload 'slot-value "clos") > --> T > > Turns out that's not all that's required: the next failure I ran into > is that the function either the function SLOT-VALUE is missing a > special case for structures, or SLOT-VALUE-USING-CLASS is missing a > method for structure classes; the error was "No applicable method"... > > Looks like there's no workaround, but maybe there's a quick patch. > I'll need to look into that a bit more. I thought I'd report you my > findings first. > > Thanks again for reporting and welcome to ABCL! > Thanks for the effort you and the rest of the team are putting into it. > > Bye, > > > Erik. > Martin.

1 0

[armedbear-devel] TYPE-ERROR #<java.lang.String foo {BADEAFFE}> cannot be coerced to a string.
by Mario Lang 16 Jun '10

16 Jun '10

Hi. Just stumbled across this one when I tried to use STRING-EQUAL to compare a value I received via JINTERFACE-IMPLEMENTATION. Now, it appears to be very simple to allow the expression (string (jnew "java.lang.String" "foo")) by overriding STRING() in JavaObject and checking if obj is a (java) String. What do you think? Index: src/org/armedbear/lisp/JavaObject.java =================================================================== --- src/org/armedbear/lisp/JavaObject.java (revision 12751) +++ src/org/armedbear/lisp/JavaObject.java (working copy) @@ -108,6 +108,14 @@ return super.typep(type); } + @Override + public LispObject STRING() + { + if (obj instanceof String) + return new SimpleString(obj.toString()); + return super.STRING(); + } + public final Object getObject() { return obj; -- CYa, ⡍⠁⠗⠊⠕

4 7

[armedbear-devel] less-reflection merge borks SLIME on trunk
by Mark Evenson 16 Jun '10

16 Jun '10

Unfortunately, the 'less-reflection' merge to trunk as of r12742 causes SLIME to fail to compile 'swank-abcl.lisp' as seen in the attached stack trace. To observe this outside of Emacs, obtain a [CVS HEAD snapshot of SLIME][1], start ABCL, point *DEFAULT-PATHNAME-DEFAULTS* to the location of 'swank.asd', then issue CL-USER> (asdf:load-system :asdf) [1]: http://common-lisp.net/project/slime/snapshots/slime-current.tgz -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."

2 2

[armedbear-devel] jinterface-implementation
by Knut Olav Bøhmer 10 Jun '10

10 Jun '10

Hi, Is it possible to implement two interfaces in one object? -- Knut Olav Bøhmer

3 3

[armedbear-devel] examples in abcl-src ?
by Mario Lang 10 Jun '10

10 Jun '10

Hi. Currently, the examples/ subdirectory is not included with the abcl source distribution. If this is not on purpose, I'd like to suggest the following change to build.xml: Index: build.xml =================================================================== --- build.xml (revision 12738) +++ build.xml (working copy) @@ -463,7 +463,8 @@ <include name="CHANGES"/> <include name="abcl.in"/> <include name="abcl.bat.in"/> - + <include name="examples/**"/> +  -- Thanks, Mario

2 1

Re: [armedbear-devel] [armedbear-cvs] r12748 - in trunk/abcl: . examples examples/google-app-engine examples/gui examples/java-exception examples/java-interface examples/java-to-lisp-1 examples/java-to-lisp-2 examples/jsr-223 examples/lisp-to-java examples/misc nbproj
by Ville Voutilainen 09 Jun '10

09 Jun '10

On 9 June 2010 14:17, Mark Evenson <mevenson(a)common-lisp.net> wrote: > Author: mevenson > Date: Wed Jun 9 07:17:17 2010 > New Revision: 12748 > Log: > Include 'examples' in release source distribution. > Reported by Mario Lang. > Modified: > trunk/abcl/build.xml > trunk/abcl/nbproject/build-impl.xml > trunk/abcl/nbproject/genfiles.properties > trunk/abcl/src/org/armedbear/lisp/Autoload.java > trunk/abcl/src/org/armedbear/lisp/Function.java > trunk/abcl/src/org/armedbear/lisp/Interpreter.java > trunk/abcl/src/org/armedbear/lisp/Lisp.java > trunk/abcl/src/org/armedbear/lisp/Load.java > trunk/abcl/src/org/armedbear/lisp/Readtable.java > trunk/abcl/src/org/armedbear/lisp/SlotDefinition.java > trunk/abcl/src/org/armedbear/lisp/StandardClass.java > trunk/abcl/src/org/armedbear/lisp/Stream.java > trunk/abcl/src/org/armedbear/lisp/Symbol.java > trunk/abcl/src/org/armedbear/lisp/clos.lisp > trunk/abcl/src/org/armedbear/lisp/compile-file.lisp > trunk/abcl/src/org/armedbear/lisp/compiler-pass1.lisp > trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > trunk/abcl/src/org/armedbear/lisp/disassemble.lisp > trunk/abcl/src/org/armedbear/lisp/gui.lisp > trunk/abcl/src/org/armedbear/lisp/load.lisp > trunk/abcl/src/org/armedbear/lisp/precompiler.lisp > trunk/abcl/src/org/armedbear/lisp/proclaim.lisp What the...? Why does this patch modify these files? > trunk/abcl/src/org/armedbear/lisp/scripting/AbclScriptEngine.java > trunk/abcl/src/org/armedbear/lisp/scripting/AbclScriptEngineFactory.java These modifications seem to put removed @Override annotations back, which breaks java 1.5 compatibility, because those are overrides of interface methods which aren't supported by 1.5 version of @Override. The patch looks botched, the only thing it's supposed to do is modify build.xml afaics.

2 1