Howdy howdy,
On Tue 31 Mar 2009 16:25, Neil Jerram <n...@ossau.uklinux.net> 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/
