Re: Rational

[David Kastrup]

Hans Åberg <address@hidden> writes:

>> On 23 May 2018, at 13:10, David Kastrup <address@hidden> wrote:
>> 
>> Hans Åberg <address@hidden> writes:
>> 
>>>> On 23 May 2018, at 12:20, David Kastrup <address@hidden> wrote:
>>>> 
>>>> ... work on "the problem" has moved beyond the stage where one can
>>>> just propose a generic solution, everybody slaps his forehead and
>>>> gets to work and does what it takes to do.
>>> 
>>> How about using what I suggested and what you touched upon in your
>>> link?
>> 
>> Hans, with regard to the LilyPond code base you don't know what you are
>> talking about.  First, LilyPond is not in a state where you can get
>> serious work done with Guilev2 (memory consumption and speed are too far
>> off the mark) so the Boehm GC is just a theoretical consideration for
>> the bulk of the code base.  Second, its organization is such (using
>> loads of STL data structures with their own allocation for storing
>> structures containing only some SCM values) that the Boehm GC approach
>> does not make for a good match with wholescale conservative scanning
>> without employing mark hooks.
>
> I mentioned that the GC supports traditional allocations/deallocation,
>
>> Guilev2, including its use of the Boehm GC, is optimized for
>> applications that are principally Scheme, and it works also for
>> applications that are principally C++ in their approach.  Or at least
>> small.  LilyPond is huge, with large resource demands, and it's sort-of
>> half Scheme and half C++, both regarding its data structures as well as
>> the data itself.
>> 
>> Guilev2 support by now is workable enough that somebody actually cluing
>> himself in and working with the respective patches/branches can get a
>> working setup for experimentation.  If you want to gather your own
>> experience in that area and give actually qualified advice and code
>> proposals, feel free to do so.
>
> ...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.

-- 
David Kastrup