Re: Rational

[David Kastrup]

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.  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.  LilyPond's data structures are too much of a
mixed bag to make that a good idea.

>> LilyPond has worked for decades on large file sets compiled in
>> sequence and large projects, with a conservative garbage collector
>> with a small seed core area (basically stack and memory explicitly
>> allocated by Guile).  You keep pontificating about problems with
>> solutions that have been known for decades and that have polished
>> abstractions and implementations (which made the Guilev2 migration
>> possible in the first place) in place.
>
> But the Boehm GC is new for Guile 2.

The problems of conservative garbage collection aren't.

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

-- 
David Kastrup