lilypond-devel
[Top][All Lists]
Advanced

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

Re: Issue 5790: Rational conversion clean-up (issue 573570043 by address


From: dak
Subject: Re: Issue 5790: Rational conversion clean-up (issue 573570043 by address@hidden)
Date: Tue, 25 Feb 2020 02:35:56 -0800

On 2020/02/25 08:07:14, hanwenn wrote:
> LGTM
> 
> (I wonder if we should bite the bullet and use uint64_t iso. U64.)

Just for the record: the big bullet would be a Simple_smob wrapper class
around Guile's rational data type.  Showstopper in the current setup:
Moments in data structures contain rationals and would need to get
heap-marked, but the Midi data structures are not memory-managed by
Scheme.  Even the non-showstopper parts would be quite a bit of work. 
Workaround/migration strategy could be a variant adding itself into a
doubly-linked list of data structures to be marked outside of the normal
Scheme mechanisms and handled by construction/destruction and reference
counting, with the obvious memory overhead.

The alternative would be to base our implementation of rationals not on
U64 but on GNU mp.  There is


 -- C Function: void scm_to_mpz (SCM val, mpz_t rop)
     Assign VAL to the multiple precision integer ROP.  VAL must be an
     exact integer, otherwise an error will be signalled.  ROP must have
     been initialized with ‘mpz_init’ before this function is called.
     When ROP is no longer needed the occupied space must be freed with
     ‘mpz_clear’.  *Note (gmp)Initializing Integers::, for details.

 -- C Function: SCM scm_from_mpz (mpz_t val)
     Return the ‘SCM’ value that represents VAL.

but that sounds like slowing down things more.  Maybe we should collect
this JFTR in some actual issue.

https://codereview.appspot.com/573570043/



reply via email to

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