[Top][All Lists]

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

Re: Rational

From: Hans Åberg
Subject: Re: Rational
Date: Wed, 23 May 2018 17:54:33 +0200

> On 23 May 2018, at 16:15, David Kastrup <address@hidden> wrote:
> Hans Åberg <address@hidden> writes:
>>> On 23 May 2018, at 15:46, David Kastrup <address@hidden> wrote:
>>> Try actually reading the code.  lily/include/smobs* are not that many
>>> files and nowadays pretty exclusively encapsulate all Scheme-related
>>> memory management.
>> As long you don't have pointers into that, as you suggested with
>> Rational and other data that uses it.
> Look, you are just stabbing around in the dark here.  Quite a few of
> your statements don't even make sense.  You need to get yourself
> acquainted with the code if you want to get anywhere.  Rational is not a
> structure containing garbage-collected elements or pointers.

The thread started with suggestions for changing that.

>  It's
> fixed-size which is what triggered the original poster's complaints.
> Changing that requires work since currently you can use and store
> Rational everywhere without bothering about garbage collection.  I know
> perfectly well that the premise of the Boehm GC is that you can do that
> with SCM values anyway but the cost associated with that is a vastly
> expanded seed area for the mark pass of garbage collection, basically
> adding the complete heap.  

I ended up using GC_malloc_uncollectable, because it turned out too tricky to 
use malloc.

And I found no reference to it in LilyPond, so I got curious about how you do 
it. But you are not going to tell me, so forget about it.

> LilyPond's data structures are too much of a
> mixed bag to make that a good idea.

It is indeed slower, but not using it requires isolating it. But is of course 
fine that you are willing to do that.

>>> In contrast to the actual typesetting, the Midi backend is
>>> lackadaisical with its allocations and does not create data
>>> structures connected with the Guile garbage collector.  Nor does it
>>> free them.  The data structures are much more compact than the
>>> typical typesetting stuff but nevertheless this is a memory leak
>>> wanting to get patched up, and in the process of turning its timing
>>> data structures into SCM data structures, this might be a side
>>> benefit.
>> As long it does not use Rational with a pointer into Guile.
>> Anyway, you seem to have decided how the LilyPond development should
>> progress.
> No, I decide what I work on and I have the technical expertise to know
> what will work.  As long as nobody else steps up to the plate of the
> core Guile/LilyPond integration with more than advice unrelated to the
> actual code base, that determines how LilyPond development will
> progress.  Poorly, yes, but not for a lack of advice.

You must do it the way you find right.

reply via email to

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