Hi Neil & all,
On Mon 30 Mar 2009 22:43, Neil Jerram writes:
> Andy Wingo writes:
>> #!/bin/sh
>> # -*- scheme -*-
>> exec ${GUILE-guile} -e '(@ (scripts compile) compile)' -s $0 "$@"
>> !#
>
> FWIW, I think this kind of incantation is really horrible. Ditto for
> usage of "guile-tools ...".
Hi Neil,
On Tue 31 Mar 2009 15:47, Neil Jerram writes:
> Andy Wingo writes:
>
>> #!/usr/bin/env guile -e
>>
>> but we all know the problem with that.
>
> Only one argument being portably supported? (I _think_ that's the
> problem, but I'm not so sure that I don't want to check that that
Andy Wingo writes:
> Hi Neil,
Hi Andy,
> On Mon 30 Mar 2009 13:43, Neil Jerram writes:
>
>> FWIW, I think this kind of incantation is really horrible. Ditto for
>> usage of "guile-tools ...". What kind of a scripting language is it
>> that needs to be bootstrapped by a different language?
>
>
Neil Jerram writes:
> The primary purpose of stack-limit-calibration.scm is to allow "make
> check" to succeed on those platforms,
That's fine.
> and it now makes sense to
> generalize that to any other guile-using operations that we run during
> the build - such as compiling.
Not quite; the
Hello,
Andy Wingo writes:
> The recent commit to compile with the stack calibration file,
> 7ca96180f00800414a9cf855e5ca4dceb9baca07, breaks compilation because the
> compile scripts have hash-bang lines like this:
>
> #!/bin/sh
> # -*- scheme -*-
> exec ${GUILE-guile} -e '(@ (scripts compile) c
Hi Neil,
On Mon 30 Mar 2009 13:43, Neil Jerram writes:
> Andy Wingo writes:
>
>> Hey Guilers,
>
> Hi Andy,
>
> In summary, I'm not sure I'm following the logic here...
>
>> The recent commit to compile with the stack calibration file,
>> 7ca96180f00800414a9cf855e5ca4dceb9baca07, breaks compilat
Andy Wingo writes:
> Hey Guilers,
Hi Andy,
In summary, I'm not sure I'm following the logic here...
> The recent commit to compile with the stack calibration file,
> 7ca96180f00800414a9cf855e5ca4dceb9baca07, breaks compilation because the
> compile scripts have hash-bang lines like this:
>
> #
I do this as well, FWIW.
> I always set the stack limit higher, so that I can run a version
> that has been compiled without optimization, for the sake of
> GDB.
> From: Andy Wingo
>
> So I have a proposal. We should set the stack limit to 60k words.
I always set the stack limit higher, so that I can run a version
that has been compiled without optimization, for the sake of
GDB.
-Mike Gran
2008/10/14 Ludovic Courtès <[EMAIL PROTECTED]>:
> Hello,
>
> "Neil Jerram" <[EMAIL PROTECTED]> writes:
>
>> diff --git a/.gitignore b/.gitignore
>> index a122176..39c4b49 100644
>> --- a/.gitignore
>> +++ b/.gitignore
>> @@ -70,3 +70,4 @@ guile-readline/guile-readline-config.h
>> guile-readline/gu
Hello,
"Neil Jerram" <[EMAIL PROTECTED]> writes:
> diff --git a/.gitignore b/.gitignore
> index a122176..39c4b49 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -70,3 +70,4 @@ guile-readline/guile-readline-config.h
> guile-readline/guile-readline-config.h.in
> TAGS
> guile-1.8.pc
> +stack-li
Hi Neil,
"Neil Jerram" <[EMAIL PROTECTED]> writes:
>
> Goodness, that Ludovic, can't he ever just be happy with what I've proposed...
Eh eh, I'm starting to have a reputation! ;-)
I did think you may be annoyed by that review after all the work you had
put it, but well. :-)
> ...oh but hang
2008/10/12 Neil Jerram <[EMAIL PROTECTED]>:
>
> Here's the new patch. Please (as ever!) let me know what you think.
One update to this below. It isn't actually necessary or helpful, for
this case, to pull in the GOOPS interface to evaluator traps.
Neil
diff --git a/libguile/measure-hwm.scm
2008/10/12 Neil Jerram <[EMAIL PROTECTED]>:
>
> So yes, I think we can actually do this without any change to the C
> code except adding %get-stack-depth, by using an evaluator trap.
>>
>> As Greg suggested, this could be in `check_DATA' or something like that.
>
> Yes, but thanks for the more spec
Hi Ludovic,
2008/10/11 Ludovic Courtès <[EMAIL PROTECTED]>:
>
> The approach looks good to me. It's just annoying that
> `SCM_CHECK_STACK' (adding a slight overhead) and "threads.h" have to be
> modified.
>
> Instead of storing the high water mark in threads, could we have
> `%get-stack-depth' an
Hi Neil,
"Neil Jerram" <[EMAIL PROTECTED]> writes:
> - it uses a much larger amount of executed code to calibrate stack
> usage: specifically, all the code involved in starting up a standard
> debug-mode REPL
>
> - it focusses on the problem of getting `make check' to pass (when it
> should do so
On 10/10/2008, Greg Troxel <[EMAIL PROTECTED]> wrote:
> It would be nice to make that get generated only by make check, and not
> the regular build,
Good idea, I'll look at doing that.
"Neil Jerram" <[EMAIL PROTECTED]> writes:
> On 10/10/2008, Greg Troxel <[EMAIL PROTECTED]> wrote:
>> I am not really following, but does this make it harder to cross-compile
>> guile than it is now?
>
> I don't think so. In the Guile build, 'make' already executes the
> built guile in order to
On 10/10/2008, Greg Troxel <[EMAIL PROTECTED]> wrote:
> I am not really following, but does this make it harder to cross-compile
> guile than it is now?
I don't think so. In the Guile build, 'make' already executes the
built guile in order to generate the online help
(guile-procedures.txt). Wit
I am not really following, but does this make it harder to cross-compile
guile than it is now?
(I am working on a project cross-compiling code for arm11 linux; we
aren't using guile at the moment but I am now more sensitive to these
issues.)
pgpkZBpHvTXsm.pgp
Description: PGP signature
Hi Ludo,
OK, here's my next attempt at a solution for this problem. :-)
Compared to the previous stack calibration patch/approach, the main
points of this one are that
- it uses a much larger amount of executed code to calibrate stack
usage: specifically, all the code involved in starting up a s
2008/10/6 Ludovic Courtès <[EMAIL PROTECTED]>:
> Hello,
>
> Sorry for the latency...
Hi, no problem!
> "Neil Jerram" <[EMAIL PROTECTED]> writes:
>
>> - The problem we actually need to solve is getting a stack overflow
>> while running make and/or make check, and there may be other ways of
>> doin
Hello,
Sorry for the latency...
"Neil Jerram" <[EMAIL PROTECTED]> writes:
> FWIW, I'm actually thinking now that this stack calibration stuff is
> becoming way too tricky, in at least two ways.
>
> 1) The concept of the 'stack debug option being expressed in terms of
> some other "canonical" com
2008/9/30 Neil Jerram <[EMAIL PROTECTED]>:
>
> Well, ideally we should have a solution that works automatically in
> all circumstances...
FWIW, I'm actually thinking now that this stack calibration stuff is
becoming way too tricky, in at least two ways.
1) The concept of the 'stack debug option b
2008/10/2 Andy Wingo <[EMAIL PROTECTED]>:
> Heya,
>
> Neil, I'd love to try your patches, can you push to a branch?
>
> Andy
>
Sure, but I'm not yet familiar with how to do that. I already have a
local "stack-calibration" branch; if you already know the incantation
for just pushing that to savann
Heya,
Neil, I'd love to try your patches, can you push to a branch?
Andy
2008/9/28 Ludovic Courtès <[EMAIL PROTECTED]>:
> One last thing...
>
> "Neil Jerram" <[EMAIL PROTECTED]> writes:
>
>> @@ -81,6 +106,15 @@ scm_stack_report ()
>> void
>> scm_init_stackchk ()
>> {
>> +#ifdef GUILE_CALIBRATION_MEASURED_DEPTH_1
>> + /* Calculate calibrated stack depth limit. */
>>
2008/9/28 Ludovic Courtès <[EMAIL PROTECTED]>:
>
> "Neil Jerram" <[EMAIL PROTECTED]> writes:
>
>> I've done this part a bit differently - see the libguile/Makefile.am
>> changes - because I couldn't see exactly how the recursive make
>> approach would work. If you think recursive make would be
>>
One last thing...
"Neil Jerram" <[EMAIL PROTECTED]> writes:
> @@ -81,6 +106,15 @@ scm_stack_report ()
> void
> scm_init_stackchk ()
> {
> +#ifdef GUILE_CALIBRATION_MEASURED_DEPTH_1
> + /* Calculate calibrated stack depth limit. */
> + calibrated_m = ((double) (GUILE_CALIBRATION_MEASURED_DEPT
Hello,
"Neil Jerram" <[EMAIL PROTECTED]> writes:
>>> + SCM_VALIDATE_INT_COPY (1, d1, y1);
>>> + SCM_VALIDATE_INT_COPY (2, d2, y2);
>>> +
>>> + calibrated_m = ((double) (y2 - y1)) / (x2 - x1);
>>> + calibrated_c = ((double) y2) - calibrated_m * x2;
>>
>> Shouldn't it be:
>>
>> calibrated_c =
Hi there,
2008/9/12 Ludovic Courtès <[EMAIL PROTECTED]>:
>
> That's the second important thing that should go in 1.8.6 IMO.
Cool...
>> + /* x1 and x2 are the stack depth values that we get on a Debian
>> + GNU/Linux ia32 system - which we take as our canonical system.
>> + y1 and y2 are
31 matches
Mail list logo