[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Right, but we do not care much about the aggregated counts, do we?
Dunno, a matter of personal preference I guess :-).
Myself I wouldn't mind a --gdb option or something on ./pre-inst-guile
and/or ./check-guile. The best way I'd found to run up gdb
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> 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.
gdb might show where the stack is being used up, trap on
scm_report_stack_overflow I think.
When I looked it was
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> Did you try it (ie. ./check-guile)? I believe it uses
> ./pre-inst-guile, and that script sets the paths correctly to run
> uninstalled.
This is true, I was wrong. ;-)
> Yep. I've done that for my charting package, you can set
> TESTS_ENVIRONMENT
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
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> BTW, this script sets `GUILE_LOAD_PATH' to `${top_srcdir}/test-suite'
> only. Consequently, the `ice-9' modules (and in particular
> `boot-9.scm') are loaded from `${datadir}/guile/1.7', /not/ from the
> source tree, which is wrong.
Did you try it (
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> When running `elisp.test' untouched. Here's what I get:
>
> $ guile -L .. -l tests/elisp.test
> [...]
> PASS: scheme: value preservation: cdr
> PASS: scheme: value preservation: vector-ref
> ERROR: Stack overflow
I can't reproduce this, but
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Actually I'm not sure I understand. Do you see the stack overflow
> only after applying your patch, or did it occur before the patch also
> on your system? I don't see a problem on Intel using current CVS.
When running `elisp.test' untouched. Here
Hi,
Kevin Ryde <[EMAIL PROTECTED]> writes:
> It is, but from the top-level ./check-guile.
Ah, I see.
BTW, this script sets `GUILE_LOAD_PATH' to `${top_srcdir}/test-suite'
only. Consequently, the `ice-9' modules (and in particular
`boot-9.scm') are loaded from `${datadir}/guile/1.7', /not/ from
I wrote:
>
> It is, but from the top-level ./check-guile.
I mean the test-suite is run from make check, but via the top-level
Makefile.am, not the Makefile.am in the test-suite directory.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gn
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> It turns out that I had never looked at the test-suite, mostly because
> it isn't run at `make check' time.
It is, but from the top-level ./check-guile.
> Additionally, the `guile-test' script was largely outdated.
Maybe could be removed if no long
Neil Jerram <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes:
>
>> The patch below fixes these two things. It also comments out the
>> `elisp' test which results in a stack overflow here. My understanding
>> is that the Elisp work is almost only due to Neil has never been
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> The patch below fixes these two things. It also comments out the
> `elisp' test which results in a stack overflow here. My understanding
> is that the Elisp work is almost only due to Neil has never been widely
> used, so hopefully it won't hurt too
[Switched to `guile-devel'.]
Kevin Ryde <[EMAIL PROTECTED]> writes:
> You'll need to make something for
> test-suite/tests/socket.test exercising each case, eventually.
It turns out that I had never looked at the test-suite, mostly because
it isn't run at `make check' time. Additionally, the `g
13 matches
Mail list logo
