Re: Evaluator cleanup
[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 remain so, and some could be subject to > inlining. OTOH, all the `scm_m_' functions are already exported and cannot be inlined (a pointer to them is passed to `scm_make_synt ()'). So memoizers do not need to be #included. Sorry for the confusion. Thanks, Ludovic. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Evaluator cleanup
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 and unmemoize functions come in pairs, and perhaps there could be 1 file per pair. -- Han-Wen Nienhuys - [EMAIL PROTECTED] - http://www.xs4all.nl/~hanwen ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Evaluator cleanup
[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
Re: autohackery and nightly snapshots
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 directory as the running > executable" logic, and that this logic wasn't present in some older > version of libtool. (Although there is nothing in libtool's NEWS or > doc to support this.) There's a comment that it tries the name as given, like just "foo.la" etc. Probably not what you normally want :(. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: A solution to pthread_getattr_np on MacOS X and potentially others.
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 obvious at apple.com. */
#define HAVE_GET_THREAD_STACK_BASE
static SCM_STACKITEM *
get_thread_stack_base ()
{
return pthread_get_stackaddr_np (pthread_self ());
}
Perhaps you could you see if that's enough.
> + <<< threads.c
> + >>> 1.88
You appear to have some cvs merge conflicts there ...
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Unbuffered socket I/O
[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 words as an authority!) Also of course send and recv! don't use the buffering, so there's no point having it when working with packets. > #define SCM_SOCK_FD_TO_PORT(fd) \ > scm_fdes_to_port (fd, "r", sym_socket) That's an incompatible change, I think, since it can leave unflushed data where previously it went straight out. Perhaps the unbuffering can be reiterated in the manual or docstrings in each of socket, socketpair and accept which create such ports. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: Evolution & optimization of the module system
[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 question is: how can we > provide the fastest variable lookup and duplicate binding detection, > i.e., using what data structures and algorithms? There's no need to think too hard about the data until the innermost code dealing with them is in C. I guess the general problem is sets of names to be combined and looked up with certain precedence. I can't see anything much to help that without using quite a bit of extra memory (which of course is bad for gc, and bad for the system generally because it's unshared). One possibility for duplicates would be lazy checking, only check for a clash when actually using a symbol. That's sort of the prolog theory: don't worry now about what might never come up. I suspect the total work would end up greater though. ___ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
Re: struct tail array, compare and segv
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 thing to do, but could always be
loosened up again later.
--- struct.c.~1.111.2.4.~ 2007-02-22 09:37:43.0 +1100
+++ struct.c 2007-02-26 10:40:36.0 +1100
@@ -430,6 +430,27 @@
layout = SCM_PACK (SCM_STRUCT_DATA (vtable) [scm_vtable_index_layout]);
basic_size = scm_i_symbol_length (layout) / 2;
tail_elts = scm_to_size_t (tail_array_size);
+
+ /* A tail array is only allowed if the layout fields string ends in "R",
+ "W" or "O". */
+ if (tail_elts != 0)
+{
+ SCM layout_str, last_char;
+ int last_c;
+
+ if (basic_size == 0)
+{
+bad_tail_size:
+ SCM_MISC_ERROR ("tail array not allowed unless layout ends R, W, or O", SCM_EOL);
+}
+
+ layout_str = scm_symbol_to_string (layout);
+ last_char = scm_string_ref (layout_str,
+ scm_from_size_t (2 * basic_size - 1));
+ if (! SCM_LAYOUT_TAILP (SCM_CHAR (last_char)))
+goto bad_tail_size;
+}
+
SCM_CRITICAL_SECTION_START;
if (SCM_STRUCT_DATA (vtable)[scm_struct_i_flags] & SCM_STRUCTF_ENTITY)
{
___
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
