[Top][All Lists]

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

Re: Rational

From: David Kastrup
Subject: Re: Rational
Date: Wed, 23 May 2018 16:15:22 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

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

reply via email to

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