[EMAIL PROTECTED] (Ludovic Courtès) writes:
> Neil Jerram <[EMAIL PROTECTED]> writes:
>> Do these need to be .i.c - i.e. implying that they need to be
>> #included? Can't they be normal .c files?
>
> No, because some of them are `static' (all the `unmemoize_' functions
> for instance) and should
Ludovic Courtès escreveu:
> Not sure about this. The alternative would be to keep both in a single
> file, but that would lead to a long file with mixed
> memoizing/unmemoizing logic, and with a load of helper functions for
> both. Would that be preferable?
I think yes. I expect that memoize an
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Ok to commit?
No. Please don't move stuff around, it works fine like it is.
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Neil Jerram <[EMAIL PROTECTED]> writes:
>
> I noticed from strace (below) that, on my machine, ltdl tries to open
> libguile-i18n-v-0.so from libguile/.libs, once it has failed with the
> locations in LTDL_LIBRARY_PATH. I'm guessing that this is a piece of
> fallback "try to open .so in the same d
Steven Wu <[EMAIL PROTECTED]> writes:
>
> + start = pthread_get_stackaddr_np (self_id); \
Thanks, in fact we have some code in the cvs with that,
/* This method for MacOS X.
It'd be nice if there was some documentation on pthread_get_stackaddr_np,
but as of 2006 there's nothing
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Is there a reason why `SCM_SOCK_FD_TO_PORT ()' in `socket.c' asks for an
> unbuffered port?
To make send and receive conversations reliable, according to sockets
section in the manual. (I don't think I added that. I hope I'm not
claiming my own wor
[EMAIL PROTECTED] (Ludovic Courtès) writes:
>
> Well it _does_ hurt, even with real-life numbers of imports, as the
> experiments I made tend to show
If that's true you'll have to start from the beginning again,
everyone's eyes glaze over at "1000 modules".
> From a performance viewpoint, the que
I'm looking at this to allow non-zero tail array only when the layout
provides for it. I think all the internal uses of structs have no
tail array (and a zero size) so that should all be ok. Dunno if
anyone else might have used the tail size to get some sneaky extra
space. Sounds like the wrong
