Hi, Neil Jerram <[EMAIL PROTECTED]> writes:
> I can't reproduce this, but I wonder if the processing is genuinely on > the border line of the allowed stack depth. Does it help if you add > this to elisp.test just before the problem: > > (debug-set! stack (* (cadr (memq 'stack (debug-options))) 2)) Yes, it does help, i.e. the test now passes even when ran with `-l'. > Also, can you confirm whether you see this problem with current CVS, > i.e. without your patch? My patch (the one that relates to the test-suite) merely comments out `elisp.test'. So I just reverted it so that I could actually run the test, that's it (i.e. it is current CVS). OTOH, I'm using the "per-module reader" patch I posted sometime ago. It (slightly) modifies `primitive-load' in a way that increases the number of Scheme procedure calls that are necessary to load the various elisp modules (not dramatically, though -- I guess it just yields an additional call to `apply' instead of calling `read' directly). But still, that doesn't explain why the stack overflows when using `-l' and why everything's fine when loading the test from the REPL. > On the other hand, if it is a genuine stack depth problem, I'd expect > this one to fail also, since the stack depth of the code for > (top-repl) is a lot more than that of the code that script.c generates > for a -l arg. Right. Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
