Re: request review: branch "wingo"

[Andy Wingo]

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
entry.

> 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:

    http://www.mapleprimes.com/forum/stack_limit

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
#define.

>>> - 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 Makefile.am 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 Makefile.am 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
> Makefile.am 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.

Cheers,

Andy
-- 
http://wingolog.org/