Re: Rational

[David Kastrup]

Hans Åberg <address@hidden> writes:

>> On 23 May 2018, at 14:34, David Kastrup <address@hidden> wrote:
>> 
>> Hans Åberg <address@hidden> writes:
>> 
>>> I mentioned that the GC supports traditional allocations/deallocation,
>>> but they must be traced so as to not end up with dead pointers.
>> 
>> Hans, please.  You are proferring utter trivialities.  There is a reason
>> that Guilev2 support is available in a rudimentary form, and the reason
>> is that people actually have bothered dealing with the respective
>> problems and getting Boehm GC bugs flagged and fixed or at least worked
>> around in the Guile and LilyPond code bases.
>> 
>> If you don't believe me, feel free to make yourself acquainted with the
>> respective code.  You want to offer advice but at your current level of
>> knowledge about LilyPond, it would be a rather strange coincidence if
>> you could offer anything not already well-known and well-considered.
>
> They are not mentioned in the link you gave, so it looks as though
> like you insist on using untraceable containers, which of course, will
> end up with dead pointers.

Try actually reading the code.  lily/include/smobs* are not that many
files and nowadays pretty exclusively encapsulate all Scheme-related
memory management.

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.

LilyPond could not have worked in the manner it did for most of its
existence if the assumptions underlying your continued "advice" were
valid.  Really, if you want to offer anything of value, there is no way
around getting your eyes dirty and actually reading and working with the
code.

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.

There are a few other areas in want of cleanup.  But advice is the last
thing that is needed here: actual work on and with the code is called
for.

-- 
David Kastrup