Re: [PATCH] Test-suite update

[Ludovic Courtès]

Hi,

Neil Jerram <address@hidden> 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.