> David Pirotte has been experiencing a problem where (reload-module ...)
> was failing to trigger a recompilation even after the source file has
> been modified.
Don't know if this is related or not, but it occured to me or my
coworkers several times that a given scm file was not recompiled to a
> I came across a couple I've used that aren't documented.
> (...)
>
> scm_display
> scm_puts
These two are "documented" in the sense that they are used in the
manual, more precisely in chapter about smob for the print_image()
sample function.
So they are mean to be public I guess.
-[ Tue, Dec 13, 2011 at 01:42:35PM +0100, Andy Wingo ]
> If you close the fd, isn't the memory unmapped? Isn't that a bad thing?
>
> Maybe I was just under a big misconception here :)
That's a common misconception. The mapping of VM space to disk storage
is unrelated to the file descriptor s
I'm a little worried by the amount of file descriptors left opened
after the objcode is mmaped.
I saw this "note to self" from objcodes.c:
/* FIXME: we leak ourselves and the file descriptor. but then again so does
dlopen(). */
So apparently the author was well aware of
> > and that other programs that use Guile for extension will run into
> > similar difficulties, but as far as I can tell Lilypond is quite
> > unique here.
>
> Because nobody else uses Guile for serious extensions. And not because
> of its performance: that is _irrelevant_ for most extension pur
You seam to believe that there is on one hand the guile developers and on
another one the guile users, facing each others on the ground of some kind
of contract that's being somewhat abused by the developers. In reality, guile
is a project belonging to the commons and such demarcation does not exi
-[ Thu, Nov 10, 2011 at 12:16:38AM +0100, Andy Wingo ]
> > Indeed, it would probably need per-port mutexes, making I/O primitives
> > thread-safe by default, and perhaps providing unlocked variants like
> > libc does.
>
> I did this in master, but something was going wrong so I stubbed it out
I still got this patch (attached) on v2.0.2 on my own repo, which
fixes runtime behavior when more than 1024 files are opened.
Can someone please comment/commit/reject it ?
commit da70784bd2048f7f1a8934711e5e24f975d68b0b
Author: Cedric Cellier
Date: Tue Jun 21 16:30:45 2011 +0200
Fix fpor
-[ Thu, Aug 18, 2011 at 11:36:37AM +0200, Andy Wingo ]
> Oh dear, this is a nasty one. The issue is that Guile's ports are not
> threadsafe. I hadn't thought about this one...
Aren't they supposed to be? I though that was what scm_i_port_table_mutex
was there for.
