Please join SRFI-110 (sweet-expression) mailing list if you're interested!

I've just started a new SRFI, SRFI 110, for "Sweet-expressions (t-expressions)". This SRFI creates an optional set of additional abbreviations to make s-expressions easier to read. In particular, it adds syntactically-relevant indentation when outside a list. If you're interested, please see the

Re: Thread-unsafe initialization problems in Guile

Noah Lavine writes: > I'm not sure I understand the issue, but I think I was imagining > something like > > if (variable == SCM_BOOL_F) { >   acquire_mutex(var_mutex); >   if (variable == SCM_BOOL_F) { >     variable = initialize_variable(); >     memory_barrier(); >   } >   release_mutex(var_mut

Re: Thread-unsafe initialization problems in Guile

Hello, On Tue, Mar 5, 2013 at 10:24 PM, Mark H Weaver wrote: > Hi Noah, > > Noah Lavine writes: > > I've only read the most recent article you posted, but if I understand > > correctly, there is a third option: (3) somehow find a way to generate > > a portable memory barrier instruction. Is th

Re: Thread-unsafe initialization problems in Guile

Hi Noah, I wrote: > In each of these cases, we have two options: (1) synchronize on every > access of the lazily-initialized variable (including reads), or (2) > abandon lazy initialization. Noah Lavine writes: > I've only read the most recent article you posted, but if I understand > corr

Re: goops - accessors, methods and generics

Hi David, David Pirotte writes: > no, what needlessly complicates things is the unfortunate decision of guilers > to > mix goops with the module system: you do not want any [by far inferior] > module > system to interfere with clos/goops. [...] [...] > if at least guile designers and goops imp

Re: goops - accessors, methods and generics

Hello, > Right, I had misread part of your initial message by focusing on the > lack of a superclass. there is no lack of superclass, your are giving your opinion, which is fine, but i didn't ask, and actually it is a bad opinion: you don't want to [and don't have to by clos spec] create a supe

My Guile 2.0.8 TODO list

FYI, here's what I'm hoping to get into Guile 2.0.8. Mark 2.0.8 TODO == * [SUBMITTED] Refactor pending numerics patches. * [SUBMITTED] Implement Dybvig and Burger's algorithm for printing floats. * [NEEDS REVISION] Fix BOM handling. * #!optional and #!rest reader handling. * A

Re: [PATCH] Fix thread-unsafe lazy initializations

l...@gnu.org (Ludovic Courtès) writes: > Agreed. Perhaps just something like: “Note that the program should > ensure that ‘my_init’ is called only once, and in a thread-safe way.” Okay, I went ahead and pushed it to stable-2.0, with the code comment: "It is important that the call to 'my_init' ha

Re: [PATCH] Fix thread-unsafe lazy initializations

Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Mark H Weaver skribis: >> >>> --- a/doc/ref/api-modules.texi >>> +++ b/doc/ref/api-modules.texi >>> @@ -942,14 +942,15 @@ the @var{name} is not bound in the module, signals an >>> error. Returns a >>> variable, always. >>>

Re: Thread-unsafe initialization problems in Guile

I've only read the most recent article you posted, but if I understand correctly, there is a third option: (3) somehow find a way to generate a portable memory barrier instruction. Is that currently possible? I'm not sure that it is. Probably option (2) is best if we can do it. Noah On Thu, Feb

Re: Adding new information to scm_t_port (was Re: always O_BINARY?)

Andy Wingo writes: > On Thu 28 Feb 2013 04:24, Mark H Weaver writes: > >> Instead of having 'input_cd' and 'output_cd' point directly to the >> platform's iconv_t structures, let's have them point to our own internal >> structure(s) that hold the needed transcoder state. This could include >> t

Re: [PATCH] Fix thread-unsafe lazy initializations

Hi Ludovic, l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> --- a/doc/ref/api-modules.texi >> +++ b/doc/ref/api-modules.texi >> @@ -942,14 +942,15 @@ the @var{name} is not bound in the module, signals an >> error. Returns a >> variable, always. >> >> @example >> -SCM m

Better generator and iterator support in guile w.r.t. speed

Hi guilers! Inspired by wingo's recent blogage on wingolog in combination with my portings of racket and cl loop frameworks, I did some thinking about generators. Especially inlining. 1. Can we make stubs like this inlinable (iterate (generator g (iterate (for x in l-i-s-t)