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@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@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-cvs
On Tue, Dec 29, 2009 at 12:29 AM, Erik Huelsmann ehuels@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.
Now the very strange thing is that the std-gf class is installed by a static block in StandardClass.java, and that - to my understanding - should be executed in our case, since with autoload-verbose I see the line ; Autoloading org.armedbear.lisp.StandardObjectFunctions ... early on during the loading of Slime. StandardObjectFunctions refers to StandardClass, thus it should initialize it.
What's worse, I have discovered that CLOS is entirely broken: (find-class 'standard-object) -> stack overflow (defclass c () ()) -> The value NIL is not of type STANDARD-CLASS.
I believe it's a bootstrap problem; something gets called too early, or too late, or doesn't get called at all.
Bye, Alessio
armedbear-devel@common-lisp.net