> Find attached > > - MVE (*.ly) indicating \version 2.25.31, including > > - include file (*.ily) with \version 2.24 (Tina's code, same behaviour > with https://wiki.lilypond.community/wiki/Time_mark_engraver) > > - default log output > > - (Allow me to send you the verbose output privately for privacy reasons) > > Retrospectively it's obvious that the problem I encountered was my own > fault, because I didn't update my codebase properly with convert-ly. > > Nevertheless, usually Lilypond gives me warnings or error messages > relating to my LilyPond code, which means I understand them and can read > and correct them. In Frescobaldi, I can even click on the error message > and I am taken to the line of code containing the error. > > In this case, none of that happened. The only thing I could deduce was > that the error must be somewhere in guile/scheme. But I have no idea > about that ;-) > > So my mileage varied - in a very unfavourable manner ;-) > > - Stephan
The error here is the code part
```
(and=> (ly:context-property context 'tempoWholesPerMinute #f)
ly:moment-main)
```
The reason is that in 2.24 the `tempoWholesPerMinute` was a moment, but 2.25
changed it to a
number (about a year ago by Dan, in this commit
https://gitlab.com/lilypond/lilypond/-/commit/
a044adea8d8f86c514a86cf6c03b5e1c2781b890[1]).
Here a new deprecated property `tempoWholesPerMinuteAsMoment` was introduced
which
sticks to the old behaviour, and convert-ly will simply replace the string
`tempoWholesPerMinute` by `tempoWholesPerMinuteAsMoment`.
Of course, while convert-ly works it is unreasonable to use this deprecated
property if we are
converting it to numeric anyway. So for a 2.25-compatible version the code
should rather simply
read
```
(ly:context-property context 'tempoWholesPerMinute #f)
```
(without the `(and=> ...)` and the `ly:moment-main`).
If you want the code to work in both 2.24 and 2.25 the easiest way I think
would be to change
code to check if the argument is a moment. Instead of
```
(new-wholes-per-minute
(and=> (ly:context-property context 'tempoWholesPerMinute #f)
ly:moment-main))
```
do
```
(new-wholes-per-minute
(ly:context-property context 'tempoWholesPerMinute #f))
(new-wholes-per-minute
(if (ly:moment? new-wholes-per-minute)
(ly:moment-main new-wholes-per-minute)
new-wholes-per-minute))
```
which will now work both in 2.24 and 2.25. Of course this could be put into a
function which is
input type agnostic and returns a numeric value:
```
#(define (->number x)
(cond
((ly:moment? x) (ly:moment-main x))
((number? x) x)
(else (ly:error "->number not implemented for input `~a`" x))))
```
and replace
```
(and=> (ly:context-property context 'tempoWholesPerMinute #f)
ly:moment-main)
```
by
```
(and=> (ly:context-property context 'tempoWholesPerMinute #f)
->number)
```
On the account of debugging: Yes scheme debugging is a bit hard in the current
state.
Theoretically it should be possible for the Lilypond parser to return the
location of the scheme
expression if a scheme expression fails to evaluate. But for further inspection
we’d essentially
need introspection into the scheme code, which only really works from GUILE.
I’m not too
knowledgeable with GUILE, but if GUILE could be conviced to return an code
location on error
the parser could maybe be improved to give the place in code where the actual
error happens
(which in this case should be the `(and=> ...)`-call).
Cheers,
Tina
--------
[1] https://gitlab.com/lilypond/lilypond/-/commit/
a044adea8d8f86c514a86cf6c03b5e1c2781b890
signature.asc
Description: This is a digitally signed message part.
