guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stack calibration


From: Neil Jerram
Subject: Re: stack calibration
Date: Tue, 31 Mar 2009 23:47:34 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)

Andy Wingo <address@hidden> writes:

> Hi Neil,

Hi Andy,

> On Mon 30 Mar 2009 13:43, Neil Jerram <address@hidden> 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?
>
> Dunno. While guile-tools should probably be written in Scheme, it
> doesn't bother me. The strange invocation stuff is just to get around
> posix's #! limitations -- it should be:
>
>   #!/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's
what you mean!)

> As far as needing the -e clause, it's so we can (use-modules (scripts
> compile)) in addition to being able to run it as a script. Not that I
> use that feature, but it is interesting.

I don't use it either, and I don't think it's interesting enough to
justify the oddness of the incantation.  I can't think of a scenario
where it really makes sense to have a module and main program combined
in the same file.  If the module part isn't generally useful it
doesn't need to be written as a module.  If the module is generally
useful, it should be given a place in the proper module tree (i.e. not
scripts/...), and the script file should (use-modules ...) it.

On the other hand, I took a look again at guile-tools and remembered
why that _is_ useful.  (Basically the same argument as "git ...",
i.e. not dropping tens of executables into the system $PATH.)  So I
take back some of my "FWIW..." rant. :-)

>> I think you may be misunderstanding.  stack-limit-calibration.scm
>> should make precisely 0 difference on the "canonical build platform" -
>> which in practice means ia32 GNU/Linux.
>
> ia32 GNU/Linux is sometimes broken -- for example, build it with -O0,
> and things often don't work at all.

Good point.

> I think I explained my perspective as well as I can in the other mail --
> perhaps we can follow that part of the discussion there?

D'oh! :-)  OK, let's do that.

      Neil




reply via email to

[Prev in Thread] Current Thread [Next in Thread]