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

[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 05 Nov '09

05 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