[Top][All Lists]

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

Re: Rational

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

Hans Åberg <address@hidden> writes:

>> On 22 May 2018, at 22:07, David Kastrup <address@hidden> wrote:
>> Hans Åberg <address@hidden> writes:
>>>> On 22 May 2018, at 20:45, David Kastrup <address@hidden> wrote:
>>>> LilyPond's "rational" type should indeed get replaced
>>>> by Guile's rational types which would seriously shift the threshold
>>>> where things start breaking apart at the cost of efficiency.
>>>> That's quite a lot of tedious work (I have some started patches for
>>>> different approaches to that) but of course if its seminal for someone's
>>>> _own_ work, the motivation for finishing that might be larger.
>>> Guile uses GMP internally, and it might be fairly easy to change the
>>> class Rational to use GMP. Have you considered that?
>> Pointless.  The principal problem is that Rational is a fixed size
>> struct without additional allocations to keep track of.  Guile's SCM
>> isn't, and GMP's numbers aren't.  The garbage collection situation
>> becomes more rather than less complicated by introducing yet another
>> SCM-connected GMP type to be collected via Guile.
> I realized after my first post that it might better to write it
> directly onto Guile. I wrote a C++ wrap for Guile:
>> The grunt work to be done is to make sure that each SCM-connected class
>> having Rational or Moment(!) members calls the respective mark hooks.
> What are these mark hooks?
>> This was somewhat complicated by some Midi classes being heap-allocated
>> and containing Rational/Moment members: those Midi classes would have to
>> become SCM-connected.  I did some work on that, don't remember how
>> complete it was.
> Guile uses the Boehm GC.

Not Guile 1, and LilyPond will have large amounts of heap space outside
of Boehm's fully automated sweep areas even in Guile 2 for efficiency
and compatibility reasons.

> I wrote a C++ wrap for that latter, too. As it turns out to be
> difficult to keep of pointers into the GC heap, I had to use only
> those that it supplies. Do you do that?

I don't know what "I had to use only those that it supplies" is supposed
to mean, so I cannot answer the question.

David Kastrup

reply via email to

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