Re: Rational

[Hans Åberg]

> 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.