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

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