[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Killing off scm_init_guile for Guile 2.0 ?

From: Kjetil S. Matheussen
Subject: Re: Killing off scm_init_guile for Guile 2.0 ?
Date: Fri, 16 Jan 2009 18:20:05 +0100 (CET)

Linas Vepstas:

I feel obligated to respond, having made all sorts of noise.

2009/1/15 Neil Jerram <address@hidden>:

whether people think that scm_init_guile is really needed.

kill it. there seem to be perfectly adequate ways of
living without it.  Unfortunately, the current documentation
describing how to use guile with threads is confusing.
It is certainly the case that, for naive, new users,
scm_init_guile seems to be the easiest way to
get guile going in a thread. This makes it a popular
choice.  Its not until you dig in deeply, and discover
how guile actually works (and then think about it a bit),
that you discover that perhaps scm_init_guile wasn't
the right choice. And then you have to refactor your
code ... possibly in large ways ...

So, the real question is -- how many existing guile
apps call scm_init_guile()?

On the other hand, breaking them by removing
scm_init_guile is possibly a good thing ... it will
probably cause them to fix bugs that were lurking
and waiting to bite.

Snd uses scm_init_guile when compiled as a Pd external.
Pd is a graphical programming language for audio processing,
and "externals" are linked into the program during runtime.

When Snd is a Pd external, it has to run Guile in a separate
thread, so that it won't interrupt sound processing.

Is there an alternative to using scm_init_guile() for this
kind of usage?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]