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

[armedbear-devel] Tip: asterisks in classpaths
by Axel Rauschmayer 04 Jan '10

04 Jan '10

Java 6 has a feature that can help with plugging external JARs into ABCL: If the classpath includes an asterisk, all JARs in the given directory are added. For example, I've created the directory ~/local/abcl for my ABCL installation that includes abcl.jar plus any other JARs I want to use. Then the following command automatically adds everything in that directory to the classpath and starts ABCL: > exec java -cp "$HOME/local/abcl/*" \ > org.armedbear.lisp.Main \ > "$@" (The "exec" can probably be omitted) -- Axel.Rauschmayer(a)ifi.lmu.de http://www.pst.ifi.lmu.de/~rauschma/

1 0

[armedbear-devel] patch for converting LispErrors to ProgramErrors in Closure.java, also removes some of the assertions
by Ville Voutilainen 04 Jan '10

04 Jan '10

It looks like some of the assertions may be actually valid as assertions. The remaining ones are: 1) in Closure constructor, parsing of parameters else if (obj instanceof Cons) { if (state == STATE_AUX) { Symbol sym = checkSymbol(obj.car()); LispObject initForm = obj.cadr(); Debug.assertTrue(initForm != null); if (aux == null) aux = new ArrayList<Parameter>(); aux.add(new Parameter(sym, initForm, AUX)); } I don't see how to create a null initform other than creating a Cons that has a null car or cdr. And I don't know how to do that from lisp code. To me, that looks like it requires serious abuse from the Java side to accomplish. And I don't think that would be the only place where the validity of a Cons would need to be checked. I'm inclined to just remove that assertion completely. 2) again in Closure constructor, else { // Lambda list is empty. Debug.assertTrue(lambdaList == NIL); arity = 0; maxArgs = 0; } That's an else branch of if (lambdaList instanceof Cons), and it looks like it asserts that our own code in Closure is correct. I'm inclined to keep that assertion as is. 3) if (arity >= 0) Debug.assertTrue(arity == minArgs); a couple of lines down, check that minArgs is equal to arity if arity isn't negative. Looks correct to me, I'm inclined to keep it as is. 4) if (optionalParameters.length == 0 && keywordParameters.length == 0) args = fastProcessArgs(args); else args = processArgs(args, thread); Debug.assertTrue(args.length == variables.length); in the array version of execute. That looks like it verifies that our argument processing works, and looks correct to me. I'm inclined to keep it as is. 5) Parameter.processInitForm: if (initForm.constantp()) { if (initForm instanceof Symbol) return initForm.getSymbolValue(); if (initForm instanceof Cons) { Debug.assertTrue(initForm.car() == Symbol.QUOTE); return initForm.cadr(); } I'm not sure what is going on here. I don't know how to concoct a lambda that has a constant initform for a parameter so that the initform is Cons but is not quoted. Granted, I've mainly tested these changes with defuns, so I wouldn't be surprised if such a failure case can be demonstrated. I have no inclination here, this looks like it should probably be a ProgramError rather than an assert. Please review these cases (and the patch itself) and comment. I ran the tests and I have a failure in MAKE-BROADCAST-STREAM.8 that my baseline doesn't have, but I'm not sure if it's related to these changes.

1 0

Re: [armedbear-devel] SETF for JFEILDS
by logicmoo＠gmail.com 30 Dec '09

30 Dec '09

Thanks, you are right, much better to use the built-in key stuff (defun (setf jfield) (newvalue class-ref-or-field field-or-instance &optional ( instance nil instance-supplied-p) unused-value) (declare (ignore unused-value)) (if instance-supplied-p (jfield class-ref-or-field field-or-instance instance newvalue) (jfield class-ref-or-field field-or-instance newvalue))) ----- Original Message ----- From: "Thomas Russ" <tar(a)ISI.EDU> To: <dmiles(a)users.sourceforge.net> Sent: Tuesday, November 24, 2009 9:24 AM Subject: Re: [armedbear-devel] SETF for JFEILDS On Nov 23, 2009, at 6:47 AM, logicmoo(a)gmail.com wrote: > 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. For what it's worth, I am not a fan of using special values to determine whether optional (or keyword) arguments are actually passed or not. I prefer to use the predicate forms from the lambda list, so something more like (defun (setf jfield) (newvalue class-ref-or-field field-or-instance &optional ( instance nil instance-supplied-p) unusedvalue) (declare (ignore unusedvalue)) (if instance-supplied-p (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: "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 >> >> > > _______________________________________________ > armedbear-devel mailing list > armedbear-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

7 19

[armedbear-devel] How do I release ABCL's "package-lock"?
by Peter Olsen 30 Dec '09

30 Dec '09

I'm writing to ask how to redefine the "or" macro in ABCL. I'm working on a project and there's one package in which I need "or" to mean something else than its usual definition. I've tried simply to redefine it, but it doesn't work. I understand that the Common Lisp spec requires special provision for that to be done --- such as the package-lock construct in SBCL. How can I do that in ABCL? I want to be able to do this within the code, for example, with in a "let" so that I can bound its scope. Can anyone point me in the right direction? My first --- failed --- experiment is below. Thanks! Peter ------------------------------------------------------- A way that doesn't work. slipstream:~ pcolsen$ abcl Armed Bear Common Lisp 0.17.0 Java 1.5.0_20 Apple Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 1.476 seconds. Startup completed in 4.363 seconds. Type ":help" for a list of available commands. CL-USER(1): (or nil t) T CL-USER(2): (defmacro or (x) (+ 1 x)) ; My very own new "or" OR CL-USER(3): (or 3) ; Result should be 4 3 CL-USER(4): (or nil nil) ; My "or" should take only one argument. NIL CL-USER(5): (or nil t) T CL-USER(6): ;;; Redefinition didn't work. Peter Olsen olsen(a)sigmaxi.net I have loved the stars too fondly to be fearful of the night. Galileo Galilei

4 3

[armedbear-devel] Fwd: [armedbear-cvs] r12311 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 30 Dec '09

30 Dec '09

Accidentally sent to Alessio only: ---------- Forwarded message ---------- From: Erik Huelsmann <ehuels(a)gmail.com> Date: Wed, Dec 30, 2009 at 12:08 AM Subject: Re: [armedbear-devel] [armedbear-cvs] r12311 - trunk/abcl/src/org/armedbear/lisp To: Alessio Stalla <alessiostalla(a)gmail.com> On Tue, Dec 29, 2009 at 1:16 AM, Alessio Stalla <alessiostalla(a)gmail.com> wrote: > On Tue, Dec 29, 2009 at 12:29 AM, Erik Huelsmann <ehuels(a)gmail.com> wrote: >> While the fix below does seem to fix slime - on my system, it doesn't >> fix all cases of what we're seeing: infinite recursion in clos.lisp, >> related to initial-discriminating-function. >> >> My own application suffers from the same issue, even after this fix. >> >> (just to let you know what our progress is) > > Erik, to update you on my own progress: > I found out that the infinite recursion is caused by > initial-discriminating-function being called before the class > standard-generic-function has been installed - (find-class > 'standard-generic-function) returns NIL. This means that the branch > that calls std-compute-discr.-function (the base case) never gets to > run, causing an infinite loop. To follow up on this discussion: Alessio and I found and fixed the issue: r12306 had broken an assumption in LOAD-TIME-VALUE. The fix has been committed. Bye, Erik.

2 4

Re: [armedbear-devel] [armedbear-cvs] r12311 - trunk/abcl/src/org/armedbear/lisp
by Erik Huelsmann 28 Dec '09

28 Dec '09

While the fix below does seem to fix slime - on my system, it doesn't fix all cases of what we're seeing: infinite recursion in clos.lisp, related to initial-discriminating-function. My own application suffers from the same issue, even after this fix. (just to let you know what our progress is) Bye, Erik. On Tue, Dec 29, 2009 at 12:11 AM, Erik Huelsmann <ehuelsmann(a)common-lisp.net> wrote: > Author: ehuelsmann > Date: Mon Dec 28 18:11:35 2009 > New Revision: 12311 > > Log: > Followup to r12306: "unbreak" Slime, at least partially. > > Modified: > trunk/abcl/src/org/armedbear/lisp/AutoloadedFunctionProxy.java > trunk/abcl/src/org/armedbear/lisp/LispObject.java > trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > > Modified: trunk/abcl/src/org/armedbear/lisp/AutoloadedFunctionProxy.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/AutoloadedFunctionProxy.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/AutoloadedFunctionProxy.java Mon Dec 28 18:11:35 2009 > @@ -68,6 +68,12 @@ > this.fType = ft; > } > > + /** Resolve this instance by returning the function we're proxy for */ > + @Override > + public LispObject resolve() { > + return load(); > + } > + > final private synchronized Function load() { > if (fun != null) > return fun; > @@ -249,6 +255,9 @@ > LispObject pack = Symbol._PACKAGE_.symbolValue(thread); > > if (cache instanceof Nil) > + // during EVAL-WHEN :compile-toplevel, this function will > + // be called without a caching environment; we'll need to > + // forward to the compiled function loader > return loadCompiledFunction(name.getStringValue()); > else { > fun = new AutoloadedFunctionProxy(sym, name, cache, pack, > > Modified: trunk/abcl/src/org/armedbear/lisp/LispObject.java > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/LispObject.java (original) > +++ trunk/abcl/src/org/armedbear/lisp/LispObject.java Mon Dec 28 18:11:35 2009 > @@ -38,6 +38,16 @@ > > public class LispObject //extends Lisp > { > + > + /** Function to allow objects to return the value > + * "they stand for". Used by AutoloadedFunctionProxy to return > + * the function it is proxying. > + */ > + public LispObject resolve() > + { > + return this; > + } > + > public LispObject typeOf() > { > return T; > > Modified: trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp > ============================================================================== > --- trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp (original) > +++ trunk/abcl/src/org/armedbear/lisp/compiler-pass2.lisp Mon Dec 28 18:11:35 2009 > @@ -2048,6 +2048,10 @@ > "getSymbolSetfFunctionOrDie" > "getSymbolFunctionOrDie") > nil +lisp-object+) > + ;; make sure we're not cacheing a proxied function > + ;; (AutoloadedFunctionProxy) by allowing it to resolve itself > + (emit-invokevirtual +lisp-object-class+ > + "resolve" nil +lisp-object+) > (emit 'putstatic *this-class* f +lisp-object+) > (if *declare-inline* > (setf saved-code *code*) > > _______________________________________________ > armedbear-cvs mailing list > armedbear-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs >

2 1

[armedbear-devel] fast-boot-preloading branch merged to trunk
by Erik Huelsmann 28 Dec '09

28 Dec '09

After finding on the fast-boot-preloading branch that the experiment worked out: delaying access to the reflection API in order to save performance worked! Comparing the branch performance of loading ABCL on Google App Engine to the trunk, the trunk took rougly 19 seconds to load (theoretical performance) while the branch only took 11 seconds. Seeing this benefit, I decided to merge the code back to trunk once the branch was stable enough. Today was that moment: I found the last reason the branch was failing the ANSI tests (I needed to increase the runtime stack). Given this status, the merge of the branch to the trunk just got committed. The work isn't fully done though: 1. The same approach can be implemented for macro-functions 2. Functions loaded through EVAL-WHEN during file compilation can be addressed the same way Anybody with time to help out on either is heartily invited to join the effort and see how much compile time and boot time can be saved. With kind regards, Erik.

2 1

[armedbear-devel] Review of exception handling ["catch (Throwable"]
by Erik Huelsmann 28 Dec '09

28 Dec '09

Last weeks I did a full review of our code base of uses of "catch (Throwable" as a means of catching anything and "just continuing from there". It seems our code was relatively unpredictable, because in some sites it would throw a debugging exeption, whereas in others processing would continue. With the change where ControlTransfer is now an unchecked exception, it turns out most of the try/catch blocks were unnecessary anyway; most of them have been removed or made more specific (IOException, mostly). The remaining ones seem to have a function, however, everybody is invited to see if I didn't forget or misjudge some locations. With the removal, there's a new instability, it seems: when using the IGNORE-ERRORS macro, one expects the code inside it to catch all errors and continue processing after it, no matter what the error. However, since we no longer catch Throwable and therefore no longer catch any of the RuntimeExceptions, it turns out IGNORE-ERRORS leaks all runtime exceptions. Arguably it shouldn't leak StackOverflowException and many others: these might be *the* conditions to continue after IGNORE-ERRORS. So, I think we need to implement some construct to catch all java exceptions raised inside it and convert them to Lisp errors. This can then be included in IGNORE-ERRORS. Comments? Bye, Erik.

2 2

[armedbear-devel] Getting abcl source and examples with svn http://...
by Durward McDonell 23 Dec '09

23 Dec '09

Hi. Our firewall won't let svn (port 3690) through. Is there a way to download the abcl source through http? More precisely, I want to get the examples in one go, instead of getting them from the trac browser one at a time. (I'm not interested in developing abcl, at least not at the moment, and I have the 0.17 tarball.) Is this possible? Thanks. -- Durward McDonell durward.mcdonell(a)jhuapl.edu

2 3

Re: [armedbear-devel] Qi Lisp II
by Raoul Duke 23 Dec '09

23 Dec '09

how goes Qi on ABCL? cf. http://n2.nabble.com/Qi-on-ABCL-td3001784.html apologies if there's an answer out there that i just haven't hit via googling yet. thanks :)

2 1