Re: the future of Guile

[Kjetil S. Matheussen]

"Marco Maggi":
> > > 4. If  a garbage  collector allows  to remove  the  need for
> > >    "scm_remember_upto_here"  it must be  adopted even  if it
> > >    makes Guile slower  and it raises memory usage  a bit (or
> > >    more than a bit).
> >
> > Who cares?  I have written thousands and  thousands of lines
> > of  guile  extensions  in C.  I  have  not  yet had  to  use
> > this. Perhaps it's just dumb luck or something.
>
> While coding GEE I had  crashes that I fixed by remembering.
> I  am probably  using  it also  in  places where  it is  not
> required. But I  am not able to recognise  those places, can
> you guess why?

When I developed this:
http://www.notam02.no/arkiv/doc/snd-rt/ , my biggest problem
was all crashes related to garbage collection.

I think I got rid of the last garbage collector-bug in september 2006, 
which was related to the ladspa plugin[1] SMOB in the function
rt-compiler.scm/make-ladspa. In that function, the variable "handle"
could be garbage collected during the execution
of the function. The diff for the fix is here:

http://snd.cvs.sourceforge.net/snd/cvs-snd/rt-compiler.scm?r1=1.45&r2=1.46

I think the exampe above shows how insanely complicated things
can get when you manually have to tell guile's garbage collector
what to scan and what not,  and I also think it was
a miracle that I eventually spotted the bug. :-)

So in my experience, the current system is very inconvenient, and should 
be replaced by a general garbage collector which works also works
for C objects, where this and other related problems wouldn't be an 
issue.


[1] ladspa is the linux audio plugin format