Re: LSR updates: was: polychords: a working solution

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 2012/2/19 David Kastrup <address@hidden>:
>
>> So if it is not too much work to collect triplets of "version #, before,
>> after convert-ly, after correct change", it might be a nice base for
>> looking how to improve the convertrules file.
>
> as an example I use: overriding-automatic-beam-settings.ly
> I atached the original-file, the after-convert-ly-file and the manual
> upgraded file.

I'll take a look.

> Furthermore, I realized, that there seems to be no conversion rule for
> the following 2.12.3-definitions:
>
> From 2.12.3:  \scm\lily-library.scm
>
>    (define (interval-translate iv amount)
>      (cons (+ amount (car iv))
>       (+ amount (cdr iv))))

It's used in snippets?  Ugh.  Probably easiest to put that back in and
document it, then.  Is there a known replacement?

> From 2.12.3:  \ly\markup-init.ly
>
> #(define-public toplevel-module-define-public! #f)
> #(define-public toplevel-module-ref #f)

Those can be replaced by their straightforward counterpart.  Where are
they used?

> And of course any 2.14.2-chordRootNamer-definition expects two
> arguments now. I've no idea how that could be covered by converting
> rules.

Give a before/after example.  It might be more reliable to actually just
let the function deal with it via an optional argument, but it is not
inconceivable to write conversion rules either.  If you take a look at
convertrules.py, you'll see that I did some rather heavy lifting inside
of Scheme constructs for dealing with ly:export.  It is not the same as
doing compatibility in Scheme itself, but it was sufficient for the
LilyPond repository.

-- 
David Kastrup