Re: Appreciation / Financial support

[Han-Wen Nienhuys]

On Tue, May 29, 2012 at 3:01 AM, David Kastrup <address@hidden> wrote:
> Mike is a big fan of C++ and admits to not understanding garbage
> collection.  And we had several hard to track down errors with strange
> symptoms because of that combination already.  When programming In
> Scheme, you don't need to know about garbage collection.
>
>> (the thought of having to go in and change -let's say- the
>> partcombiner without breaking anything makes me shudder.)
>
> Just recently I fixed a bad loop condition causing unprotected memory in
> the part combiner...  Had been there for eternities.
>
> We have things like
>
>    void
>    Time_signature_engraver::process_music ()
>    {
>      /*
>        not rigorously safe, since the value might get GC'd and
>        reallocated in the same spot */
>      SCM fr = get_property ("timeSignatureFraction");
>      if (!time_signature_
>          && last_time_fraction_ != fr
>          && scm_is_pair (fr))
>        {
>
> Scary comment, right?  Also wrong because of
>
>    void
>    Time_signature_engraver::derived_mark () const
>    {
>      scm_gc_mark (last_time_fraction_);
>    }
>
> Both sections written by you, though admittedly the latter section in
> 2005, and the former in 2000 when it may have been accurate still.

I think most of the GC concerns go away with GUILE 2.0, which uses
Boehm GC. (what is the status of the conversion to Guile 2.0?)

> Bad input tends to let LilyPond segfault.  You need C++ for that: it is
> not possible in Scheme alone.  Take a look at listener.cc, one of our
> simplest C++ classes with things like

>From a user perspective, there is little difference in getting a
Scheme level stacktrace or a segmentation fault. (I am assuming he is
not doing any scheme hacking). By itself, exchanging core dumps for
scheme stack traces is not that valuable.

While the scheme integration have been a big leap forward in terms of
expandability and flexibility, I think it has also been our gravest
design error. Both for technical reasons (GUILE is a poor
implementation), but also for practical reasons: writing scheme is
hard for the general public, and it has surely decreased the amount of
developer participation we've had.

For this reason, I feel scared of the plan to move large, working
parts of LilyPond from C++ to Scheme.

--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen