Re: Rational

[Hans Åberg]

> On 23 May 2018, at 18:36, David Kastrup <address@hidden> wrote:
> 
> Hans Åberg <address@hidden> writes:
> 
>>> On 23 May 2018, at 18:12, David Kastrup <address@hidden> wrote:
>>> 
>>> Hans Åberg <address@hidden> writes:
>>> 
>>>> I ended up using GC_malloc_uncollectable, because it turned out too
>>>> tricky to use malloc.
>>> 
>>> This is C++, so we basically end up with operator ::new and operator
>>> ::delete unless overriden by individual classes.  They use
>> 
>> This what they suggest for the Boehm GC, and it is what caused
>> problems in my program.
> 
> Likely because of the expectation that it would be managed by the Boehm
> GC.  The Guilev2 documentation states:
> 
>       For memory that is not associated with a Scheme object, you can
>    use ‘scm_malloc’ instead of ‘malloc’.  Like ‘scm_gc_malloc’, it will
>    either return a valid pointer or signal an error.  However, it will
>    not assume that the new memory block can be freed by a garbage
>    collection.  The memory must be explicitly freed with ‘free’.
> 
> So memory allocated with the standard allocator in a Guile application
> is not managed by the Boehm GC.

The object has a container with GC objects, so using using standard allocation 
for the container causes the GC to not trace the objects in the container, and 
will thus collect them.

>>>> And I found no reference to it in LilyPond, so I got curious about
>>>> how you do it. But you are not going to tell me, so forget about it.
>>> 
>>> You know, if you actually bothered _asking_, you'd increase your
>>> chances of getting an answer.
>> 
>> Typically when the item is brought up people would say "Yes, we use
>> this or that", rather than long bodies of text with no such
>> information.
> 
> If you want an answer, ask a question.  Just stating something in the
> hope that the correction will work as an answer is trying your luck.

I will try to remember that these are your rules.