Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Below is a proposed patch to do this. When and if this gets deployed,
> the third arg to %calibrate-stack-depth would be removed, so that it
> doesn't generate any output. But for now it's interesting to see what
> results people on various OSs get.
"Mikael Djurfeldt" <[EMAIL PROTECTED]> writes:
> I was thinking about inserting code which actually *measures* the size
> of frames during startup. This could be done, for example, by
> introducing a primitive which uses the internal stack measuring
> functions. One could use this primitive to m
2008/2/17, Han-Wen Nienhuys <[EMAIL PROTECTED]>:
> Isn't it be possible to catch SIGSEGV, and check whether it was
> caused by overflow?
Couldn't that leave the interpreter in a strange state so that one
would need to quit and restart? The current scheme allows the
interpreter to continue to run a
Neil Jerram escreveu:
> [moving over to guile-devel...]
>
> Not to disagree with anything that's already been said in this
> thread... But I wonder if there is a way to make Guile's stack
> overflow checking a bit less fragile - i.e. less subject to the
> behaviour of particular compilers / OSs
2008/2/14, Ludovic Courtès <[EMAIL PROTECTED]>:
> > Speaking as a user, I would prefer a solution where the evaluator
> > measures stack size the same way as currently (i.e. without the need
> > to do extra work at every return). It is possible to estimate the
> > average sizes of evaluator st
Hi,
"Mikael Djurfeldt" <[EMAIL PROTECTED]> writes:
> I think you should measure the effect on performance. Even if the hit
> isn't dramatic, remember that many a little makes a mickle...
Indeed...
> Speaking as a user, I would prefer a solution where the evaluator
> measures stack size the sam
2008/2/14, Ludovic Courtès <[EMAIL PROTECTED]>:
> We must also change `RETURN' to do "scm_i_eval_stack_depth--".
>
> Hopefully it's not too unreasonable performance-wise.
>
> What do you think?
I think you should measure the effect on performance. Even if the hit
isn't dramatic, remember that
Hi,
Neil Jerram <[EMAIL PROTECTED]> writes:
> Not to disagree with anything that's already been said in this
> thread... But I wonder if there is a way to make Guile's stack
> overflow checking a bit less fragile - i.e. less subject to the
> behaviour of particular compilers / OSs / optimization
[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Hi,
>
> Rainer Tammer <[EMAIL PROTECTED]> writes:
>
>> I added -qtune=auto but this did not solve the problem...
>> I will try other optimization settings...
>
> You did "make clean all" after reconfiguring with your `CFLAGS', right?
> Also, do the act
