armedbear-devel December 2009

armedbear-devel@common-lisp.net

14 participants
21 discussions

[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 29 Dec '09

29 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

[armedbear-devel] [PATCH] jcall(there are multiple matching methods)
by Yoshinori Tahara 23 Dec '09

23 Dec '09

Hello. Attached is a patch which fixes jcall in case there are multiple matching methods. Regards, -- Yoshinori Tahara

6 17

[armedbear-devel] Exception Handling
by Peter Olsen 18 Dec '09

18 Dec '09

Ladies and Gentlemen, I'm writing to ask how to handle exceptions generated in Java code called from ABCL. I'm part of a group trying to combine an existing Common Lisp back-end with an existing Java front end. We've pretty much decided that ABCL is the best way to do that, using Alan Ruttenberg's Java Syntax Solution to make Java calls back to the front-end from Lisp. One problem we're facing is how to handle gracefully exceptions generated in Lisp code called from Java. In our case, we'll need to make calls back to the Java front-end to get user information and to display results. Some of these calls throw exceptions. What is the best way to catch these? I'd also like any thoughts on the comparative advantages of using the JSS as opposed to the native ABCL calls. Thanks! Peter Olsen -- Peter Olsen, P.E., Ae.E. olsen(a)sigmaxi.net Engineering is the art of using a professional knowledge of mathematics and the physical sciences to get things done.

5 5

[armedbear-devel] abcl 0.17 & slime 1:20080223-2
by Durward McDonell 11 Dec '09

11 Dec '09

Hello. I have been trying to get abcl to run under slime, and I have hit the limits of my understanding of all the relevant components. This is on Ubuntu Jaunty (9.04), with abcl 0.17.0 and slime 1:20080223-2. The symptom is that slime starts to load, then quits with the error "Package "CLC" not found." I tracked this down to swank-loader: binary-pathname calls clc:calculate-fasl-root. I've tried everything I could think of, like loading clc from my .abclrc, but I could not trick it into loading. This must be a solved problem, but I have not been able to find anything on the web. On a tangentially related note, in doing all this I discovered that asdf integrates with sbcl specially, in a way that makes it a little bit easier to load packages. Is there a way to get abcl to look in more than one directory for (load "foo.lisp")? Thanks. -- Durward McDonell durward.mcdonell(a)jhuapl.edu

2 2

[armedbear-devel] Faster startup on GAE
by Erik Huelsmann 08 Dec '09

08 Dec '09

One of the conclusions of many of the profiles that we've been doing on our code base was that our boot up loads compiled functions through reflection. However, reflection is a very costly business, so it's best avoided. This is specially notable with Google App Engine which allows limited time per request, but uses that time limit on all requests including the first - which needs to initialize the entire JVM (!). To reduce the time spent on booting ABCL, I changed our class loading routine (on a branch) to *only* resolve byte code into classes which are actually required for execution of the lisp code which is currently executed. All other functions stay in memory without being resolved into classes, preventing invocations of reflection. With this method - which is in branches/fast-boot-preloading - we've reduced GAE startup times from 19000 cpu_ms to roughly 11000 cpu_ms. I intend to clean up the code - adding documentation and code comments - and moving this to the trunk. To anybody who wants a stable release: this is at the heart of the implementation; please help us test it with your application(s)! With kind regards, Erik.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

armedbear-devel December 2009