upgrading a songbook from 2.14 to 2.18

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

upgrading a songbook from 2.14 to 2.18

Maurits Lamers-2
Hi all,

In order to have my braille generator not have to support Lilypond 2.14 I tried to upgrade my music library I am building this braille generator on.

However, because of (a lot of) specific "hacks" on the layout, simply running convert-ly on the entire library doesn't completely finish the job.
These overrides use a specific syntax to distinguish between the scheme part and the lilypond part, also inside function definitions.
The following function is an example of this. It is defined as a scheme function, but uses Lilypond syntax inside which is put between #{ and #}.

These kind of definitions seem to cause all kinds of issues. 
One of these issues can be found in a piece of code taken from the lilypond-user mailing list (https://lists.gnu.org/archive/html/lilypond-user/2011-03/msg00270.html) of which I will only include the start:

====

alignGrob =
#(define-music-function (parser location grob-to-align reference-grob dir corr) (string? symbol? integer? number?)
  #{
     \overrideProperty  $grob-to-align #'after-line-breaking
     #(lambda (grob)
        (let* ((sys (ly:grob-system grob))


====

The lambda expression on the fifth line of this definition causes a "warning: ignoring non-musical expression".

Another example is in the function below.

====

stanza = #
(define-music-function (parser location str)
  (string?)
  #{ 
    \set stanza = #
     (markup #:stanza-number 
       (string-append $str "")) #})
====

In this function, the line with '\set stanza causes an GUILE error: "unbound variable str" wherever this function is applied.


So, I see two options here: either something changed around the use of the #{ and #} and any embedded scheme between 2.14 and 2.18, or the define-music-function argument list is incorrect. If I remember correctly, the last one only changed between 2.18 and 2.20.
Are there options that I missed?

cheers and thanks in advance!

Maurits

Reply | Threaded
Open this post in threaded view
|

Re: upgrading a songbook from 2.14 to 2.18

David Kastrup
Maurits Lamers <[hidden email]> writes:

> Hi all,
>
> In order to have my braille generator not have to support Lilypond 2.14 I tried to upgrade my music library I am building this braille generator on.
>
> However, because of (a lot of) specific "hacks" on the layout, simply running convert-ly on the entire library doesn't completely finish the job.
> These overrides use a specific syntax to distinguish between the scheme part and the lilypond part, also inside function definitions.
> The following function is an example of this. It is defined as a scheme function, but uses Lilypond syntax inside which is put between #{ and #}.
>
> These kind of definitions seem to cause all kinds of issues.
> One of these issues can be found in a piece of code taken from the lilypond-user mailing list (https://lists.gnu.org/archive/html/lilypond-user/2011-03/msg00270.html <https://lists.gnu.org/archive/html/lilypond-user/2011-03/msg00270.html>) of which I will only include the start:
>
> ====
>
> alignGrob =
> #(define-music-function (parser location grob-to-align reference-grob dir corr) (string? symbol? integer? number?)
>   #{
>      \overrideProperty  $grob-to-align #'after-line-breaking
>      #(lambda (grob)
>         (let* ((sys (ly:grob-system grob))
>
>
> ====
>
> The lambda expression on the fifth line of this definition causes a "warning: ignoring non-musical expression".
>
> Another example is in the function below.
>
> ====
>
> stanza = #
> (define-music-function (parser location str)
>   (string?)
>   #{
>     \set stanza = #
>      (markup #:stanza-number
>        (string-append $str "")) #})
> ====
>
> In this function, the line with '\set stanza causes an GUILE error:
> "unbound variable str" wherever this function is applied.

convert-ly does text replacements.  It is not a full parser.  If text
replacements are supposed to work, you need to write your text in a way
that the replacement patterns cover.  Stuff like putting # on one line
and a corresponding opening paren on the next line are just too weird
for those writing the conversion rules to have foreseen.

So first try formatting your source in a somewhat common manner and then
try running convert-ly.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: upgrading a songbook from 2.14 to 2.18

Maurits Lamers-2
Hi,

> convert-ly does text replacements.  It is not a full parser.  If text
> replacements are supposed to work, you need to write your text in a way
> that the replacement patterns cover.  Stuff like putting # on one line
> and a corresponding opening paren on the next line are just too weird
> for those writing the conversion rules to have foreseen.
>
> So first try formatting your source in a somewhat common manner and then
> try running convert-ly.

I did notice this way of indenting though and changed it before running Lilypond, but I didn't anticipate that convert-ly would also check for scheme code patterns.

Thanks for the hint, will try this.

cheers

Maurits


Reply | Threaded
Open this post in threaded view
|

Re: upgrading a songbook from 2.14 to 2.18

David Kastrup
Maurits Lamers <[hidden email]> writes:

> Hi,
>
>> convert-ly does text replacements.  It is not a full parser.  If text
>> replacements are supposed to work, you need to write your text in a way
>> that the replacement patterns cover.  Stuff like putting # on one line
>> and a corresponding opening paren on the next line are just too weird
>> for those writing the conversion rules to have foreseen.
>>
>> So first try formatting your source in a somewhat common manner and then
>> try running convert-ly.
>
> I did notice this way of indenting though and changed it before
> running Lilypond, but I didn't anticipate that convert-ly would also
> check for scheme code patterns.

It doesn't "check" for style.  It catches some patterns and converts
them and overlooks others.

The 2.14 to 2.16 upgrade overhauled # syntax significantly, changed the
meaning of $ for LilyPond, changed the meaning of $ in embedded Scheme
inside of #{ #}, replaced #(ly:export ...) with $... and a few other
comparatively invasive things, all using regular expressions.

It did a pretty good job on LilyPond's own code base formatted in
LilyPond's own style, but things like #<some whitespace> or
#(<some whitespace> are so unusual that they have not made it into the
patterns.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: upgrading a songbook from 2.14 to 2.18

David Kastrup
David Kastrup <[hidden email]> writes:

> Maurits Lamers <[hidden email]> writes:
>
>> Hi,
>>
>>> convert-ly does text replacements.  It is not a full parser.  If text
>>> replacements are supposed to work, you need to write your text in a way
>>> that the replacement patterns cover.  Stuff like putting # on one line
>>> and a corresponding opening paren on the next line are just too weird
>>> for those writing the conversion rules to have foreseen.
>>>
>>> So first try formatting your source in a somewhat common manner and then
>>> try running convert-ly.
>>
>> I did notice this way of indenting though and changed it before
>> running Lilypond, but I didn't anticipate that convert-ly would also
>> check for scheme code patterns.
>
> It doesn't "check" for style.  It catches some patterns and converts
> them and overlooks others.
>
> The 2.14 to 2.16 upgrade overhauled # syntax significantly, changed the
> meaning of $ for LilyPond, changed the meaning of $ in embedded Scheme
> inside of #{ #}, replaced #(ly:export ...) with $... and a few other
> comparatively invasive things, all using regular expressions.

Start and end of sentence don't fit together.  The "all using regular
expressions" concerns how convert-ly upgrades source files.  The
invasive changes, of course, were to LilyPond itself.  Sorry for losing
my own context here.

>
> It did a pretty good job on LilyPond's own code base formatted in
> LilyPond's own style, but things like #<some whitespace> or
> #(<some whitespace> are so unusual that they have not made it into the
> patterns.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: upgrading a songbook from 2.14 to 2.18

Maurits Lamers-2
In reply to this post by David Kastrup
Hi,

> Op 2 sep. 2020, om 21:07 heeft David Kastrup <[hidden email]> het volgende geschreven:
>
> Maurits Lamers <[hidden email]> writes:
>
>> Hi,
>>
>>> convert-ly does text replacements.  It is not a full parser.  If text
>>> replacements are supposed to work, you need to write your text in a way
>>> that the replacement patterns cover.  Stuff like putting # on one line
>>> and a corresponding opening paren on the next line are just too weird
>>> for those writing the conversion rules to have foreseen.
>>>
>>> So first try formatting your source in a somewhat common manner and then
>>> try running convert-ly.
>>
>> I did notice this way of indenting though and changed it before
>> running Lilypond, but I didn't anticipate that convert-ly would also
>> check for scheme code patterns.
>
> It doesn't "check" for style.  It catches some patterns and converts
> them and overlooks others.
>
> The 2.14 to 2.16 upgrade overhauled # syntax significantly, changed the
> meaning of $ for LilyPond, changed the meaning of $ in embedded Scheme
> inside of #{ #}, replaced #(ly:export ...) with $... and a few other
> comparatively invasive things, all using regular expressions.
>
> It did a pretty good job on LilyPond's own code base formatted in
> LilyPond's own style, but things like #<some whitespace> or
> #(<some whitespace> are so unusual that they have not made it into the
> patterns.

There is indeed only so much that can be caught.
I now got things to work, so thanks a lot!
There is one little thing you might know the answer to. I referred earlier to this alignGrob code which came from the lilypond-user mailing list.

This function is defined like this:

alignGrob = #(define-music-function (parser location grob-to-align reference-grob dir corr) (string? symbol? integer? number?)
  #{
     \overrideProperty  $grob-to-align #'after-line-breaking #(lambda (grob)

and called like this:

\alignGrob "Score.RehearsalMark" #'StaffSymbol #1 #0

It ran into an error, telling that Score.RehearsalMark was an invalid property path.
So, I made a test file with the following line: \overrideProperty Score.RehearsalMark #'after-line-breaking #(lambda (grob) )
and ran this through convert-ly, which resulted in this line being rewritten as \overrideProperty Score.RehearsalMark.after-line-breaking.
I managed to that the alignGrob function working by replacing #'after-line-breaking with .after-line-breaking, but I had to leave a space between $grob-to-align and .after-line-breaking.
After replacing this, I ran a file successfully, so that seems to work as required.

Two questions about this though:
1. is this space inbetween going to cause any trouble in the future?
2. is there another way to insert the $grob-to-align string where the space doesn't have to be there?

cheers and thanks!

Maurits