[Top][All Lists]

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

Re: request review: branch "wingo"

From: Andy Wingo
Subject: Re: request review: branch "wingo"
Date: Fri, 03 Apr 2009 10:51:35 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (gnu/linux)

Howdy howdy,

On Tue 31 Mar 2009 16:25, Neil Jerram <address@hidden> writes:

> - On the other hand, it does feel slightly incourteous, and the
>   argument about master being broken sounds like nonsense - because
>   everyone has their own local branches, and AFAIK there is never any
>   need to push those apart from for publication purposes.  (Is there?)

Yeah, my apologies.

By way of explanation though perhaps not justification, I was getting to
the point at work where I wanted to tell folks to add Guile to the
autobuilding set of dependencies -- but I had to give them a pointer to
a branch that worked, and preferred that that branch be `master'.

Anyway. Apologies again, and hopefully we won't go through this again
any time soon.

>>> What's the idea of the numerical args?  Should RLIMIT_XXX be defined
>>> somewhere as Scheme-level integers?
>> Uf, dunno. Now that I look at this again I'm not sure. We should
>> probably just have RLIM_* and not the symbols, right? Easier for tab
>> completion in any case...
> I personally like the symbols, but precedent (e.g. socket, bind etc.)
> would favour just the integer constants.  If the constants are also
> better for completion, I guess that clinches it. :-)

Yeah I guess so ;) I'll get to that soon, and document and add a NEWS

> I'm favouring 80% getrlimit now because I don't think Guile (and I)
> have really benefitted from the time spent investigating stack
> overflows recently,  OK, so we are familiar in more detail with some
> platforms using more stack than others, but that's not that
> interesting and the time would probably have been better spent on
> something else... so let's try not to have to do any more of this in
> future.
> So my concern now is are there platforms that don't provide getrlimit
> (or equivalent)?  If not, I'm happy to rip out all the stack
> calibration stuff; but if there are, don't we still need to keep it as
> a fallback option?

I went ahead and pushed an 80%-only patch, as you suggest.

All UNIX systems that I know of have getrlimit. Windows does not of
course, but it seems that their stack limit is hard-coded:

In any case, it seems that when Windows people bump up against this
limit they'll let us know and we can send them looking for the right

>>> - fix "linking" of guile-config
>>> I don't understand the problem here.  In what way was @bindir@ not
>>> fully expanded?
>> Because it was a make variable and not a shell variable, so it expanded
>> to ${exec_prefix}/bin. (There was code in the before to sed
>> in the variables at make-time instead of configure-time, but I had
>> removed it to simplify things.)
> Should we then put the code back?  Or does that break your
> uninstalled usage?  Other things being equal, I think it's more
> important for the generated guile-config to be simple, than for our
> to be simple.

Perhaps we can just change guile-config to use pkg-config instead, as
noted in the other thread. That will remove the need for the "linking"
as the installed vs uninstalled case should be handled by pkg-config.



reply via email to

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