Re: 64-bit Mac build of 2.20 is now available!

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

Re: 64-bit Mac build of 2.20 is now available!

marnen
On Tue, Mar 17, 2020 at 12:10 PM Zone Dremik <[hidden email]> wrote:
A Big Thank You to Marnen Laibow-Koser —  Mac OS 64 bit Lilypond 2.20 downloaded, installed and is running! This is a huge relief since my skill level is basically; download file and drag to application folder.

The only thing not running quite as expected is convert.ly updating. It isn't flagging the syntax differences. It does execute without error messages and it changes the version number.

I thought that if it was run from the LilyPad app bundle, it would just silently update the whole file (I don't like that behavior, but it seemed to be design in LilyPad).  I'll admit that I haven't tested it thoroughly, though; if you run it from within Frescobaldi, you at least see the diff.  Is it missing syntax differences?  If so, I'd appreciate a sample file that it's not behaving properly on.

Not a huge problem, since any instances of the old syntax (2.18.2) get highlighted during the compile anyway.

If convert-ly is working properly, there shouldn't *be* any of the old syntax left.  If there are, that *is* a huge problem and means that the version I packaged is broken.  Is that the case?

Best,
--
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

Arle Lommel-2
Two bugs pop up in the default install.

#1. Use of the wrong encoding for the file system.

I previously reported it on Hans Åberg’s installer.

The build seems to expect file names to use ISO Latin-1 rather than UTF-8, so if you use characters outside of the 7-bit range in your directory tree or file names, you get crashes where Lilypond cannot save the results after processing the file.  A log looks like this:

Starting lilypond 2.20.0 [Bartók-Béla-Székely-friss.ly]...
Processing `/Users/fenevad/Dropbox/music scores/bartok/Bartók-Béla-Székely-friss.ly'
Parsing...
Interpreting music...[8][16][24][32][40][40]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 3 or 4 pages...
Drawing systems...
Layout output to `/var/folders/64/hl6gpmy17994gn1w87__6yvc0000gn/T//lilypond-7Vi2o3'...
Converting to `Bartók-Béla-Székely-friss.pdf'...
warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -dAutoRotatePages=/None -dPrinted=false -sOutputFile=Bartók-Béla-Székely-friss.pdf -c.setpdfwrite -f/var/folders/64/hl6gpmy17994gn1w87__6yvc0000gn/T//lilypond-7Vi2o3)' failed (256)

fatal error: failed files: "/Users/fenevad/Dropbox/music scores/bartok/Barto�\x81k-Be�\x81la-Sze�\x81kely-friss.ly"
Exited with return code 1.

You can see the problem in the second-to-last line. If I change the file name to lose the non-ASCII characters, it works fine.

Hans reported the following as a solution:

I believe this is bug in the software that LilyPond depends on, MacOS sets LC_CTYPE=UTF-8, and does not set LANG.

I use a script to call it from named ‘lilypond', which can be put in /usr/local/bin/lilypond:
export LC_CTYPE=en_US.UTF-8
export LANG=en_US.UTF-8
exec /opt/lilypond/bin/lilypond "$@“

It can be created and installed as follows: In Terminal write (^D is <control D>)
% cat > lilypond
export LC_CTYPE=en_US.UTF-8
export LANG=en_US.UTF-8
exec /opt/lilypond/bin/lilypond "$@“
^D

% chmod a+x lilypond
% sudo -s cp lilypond /usr/local/bin/lilypond

And 'rm lilypond' if you do not want to keep the script.

Ideally the executables would solve the problem without an external script.

#2: Update.ly doesn’t work for me when invoked from Frescobaldi. I get this message about a bad CPU type when I run it from Frescobaldi.


However, when run from the Lilypond app itself, it works fine. I’m not sure what is going on here.

-Arle

On Wednesday, March 11, 2020, 01:53:27 PM EDT, Marnen Laibow-Koser <[hidden email]> wrote:  

Folks--
I've just published 64-bit Mac builds of 2.20 at https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.20.0 .  Enjoy, and please let me know if you run into any issues: it appears to work, but I haven't tested it exhaustively.
Best,
-- 

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

marnen
On Tue, Mar 17, 2020 at 5:35 PM Arle Lommel <[hidden email]> wrote:
Two bugs pop up in the default install.

#1. Use of the wrong encoding for the file system.

I previously reported it on Hans Åberg’s installer.

The build seems to expect file names to use ISO Latin-1 rather than UTF-8, so if you use characters outside of the 7-bit range in your directory tree or file names, you get crashes where Lilypond cannot save the results after processing the file.  A log looks like this:

Starting lilypond 2.20.0 [Bartók-Béla-Székely-friss.ly]...
Processing `/Users/fenevad/Dropbox/music scores/bartok/Bartók-Béla-Székely-friss.ly'
Parsing...
Interpreting music...[8][16][24][32][40][40]
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 3 or 4 pages...
Drawing systems...
Layout output to `/var/folders/64/hl6gpmy17994gn1w87__6yvc0000gn/T//lilypond-7Vi2o3'...
Converting to `Bartók-Béla-Székely-friss.pdf'...
warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite -dAutoRotatePages=/None -dPrinted=false -sOutputFile=Bartók-Béla-Székely-friss.pdf -c.setpdfwrite -f/var/folders/64/hl6gpmy17994gn1w87__6yvc0000gn/T//lilypond-7Vi2o3)' failed (256)

fatal error: failed files: "/Users/fenevad/Dropbox/music scores/bartok/Barto�\x81k-Be�\x81la-Sze�\x81kely-friss.ly"
Exited with return code 1.

You can see the problem in the second-to-last line. If I change the file name to lose the non-ASCII characters, it works fine.

Hans reported the following as a solution:

I believe this is bug in the software that LilyPond depends on, MacOS sets LC_CTYPE=UTF-8, and does not set LANG.

I use a script to call it from named ‘lilypond', which can be put in /usr/local/bin/lilypond:
export LC_CTYPE=en_US.UTF-8
export LANG=en_US.UTF-8
exec /opt/lilypond/bin/lilypond "$@“

It can be created and installed as follows: In Terminal write (^D is <control D>)
% cat > lilypond
export LC_CTYPE=en_US.UTF-8
export LANG=en_US.UTF-8
exec /opt/lilypond/bin/lilypond "$@“
^D

% chmod a+x lilypond
% sudo -s cp lilypond /usr/local/bin/lilypond

And 'rm lilypond' if you do not want to keep the script.

Ideally the executables would solve the problem without an external script.

Thanks, this makes sense.  I should be able to set the variables correctly (and actually, the lilypond "binary" in the app bundle is already a script that sets a few variables and calls the real executable, so putting a few more in there should not be a problem).   

I've created https://gitlab.com/marnen/lilypond-mac-builder/-/issues/23 for this bug.  Feel free to subscribe there for updates, or to create new issues there if they're problems with the 64-bit Mac packaging rather than LilyPond itself.


#2: Update.ly doesn’t work for me when invoked from Frescobaldi.

You mean convert-ly?
 
I get this message about a bad CPU type when I run it from Frescobaldi.

Weird, I haven't seen that.  I'll try to reproduce.  What version of Mac OS are you running?

Best,
--

PastedGraphic-1.png (356K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

Arle Lommel-2
Glad my feedback seems to be useful.

[cutting a bit here]

Thanks, this makes sense.  I should be able to set the variables correctly (and actually, the lilypond "binary" in the app bundle is already a script that sets a few variables and calls the real executable, so putting a few more in there should not be a problem).   

I've created https://gitlab.com/marnen/lilypond-mac-builder/-/issues/23 for this bug.  Feel free to subscribe there for updates, or to create new issues there if they're problems with the 64-bit Mac packaging rather than LilyPond itself.

Great. Glad it seems solvable.

#2: Update.ly doesn’t work for me when invoked from Frescobaldi.

You mean convert-ly?

Yes. My mistake.

 I get this message about a bad CPU type when I run it from Frescobaldi.

Weird, I haven't seen that.  I'll try to reproduce.  What version of Mac OS are you running?

I’m running 10.15.3 on a 2016 13” Touch Bar MacBook Pro. I’m using Frescobaldi 2.20.0. I seem to recall there are problems with the more recent versions on the Mac.

Best,

Arle
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

marnen
On Tue, Mar 17, 2020 at 6:43 PM Arle Lommel <[hidden email]> wrote:
Glad my feedback seems to be useful.

[cutting a bit here]

Thanks, this makes sense.  I should be able to set the variables correctly (and actually, the lilypond "binary" in the app bundle is already a script that sets a few variables and calls the real executable, so putting a few more in there should not be a problem).   

I've created https://gitlab.com/marnen/lilypond-mac-builder/-/issues/23 for this bug.  Feel free to subscribe there for updates, or to create new issues there if they're problems with the 64-bit Mac packaging rather than LilyPond itself.

Great. Glad it seems solvable.

Yeah, if it's just a question of setting a few variables, it shouldn't be too hard to fix.
 

#2: Update.ly doesn’t work for me when invoked from Frescobaldi.

You mean convert-ly?

Yes. My mistake.

 I get this message about a bad CPU type when I run it from Frescobaldi.

Weird, I haven't seen that.  I'll try to reproduce.  What version of Mac OS are you running?

I’m running 10.15.3 on a 2016 13” Touch Bar MacBook Pro. I’m using Frescobaldi 2.20.0. I seem to recall there are problems with the more recent versions on the Mac.

Hmm, I can't reproduce this on Mojave on my 2018 MacBook Pro (with the same version of Fresco, FWIW).  Do you get this message with every file?  Do you have a sample LilyPond file that you can share with me?
 

Best,

Arle

Best, 
--
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

marnen
On Tue, Mar 17, 2020 at 6:48 PM Marnen Laibow-Koser <[hidden email]> wrote:
On Tue, Mar 17, 2020 at 6:43 PM Arle Lommel <[hidden email]> wrote:
Glad my feedback seems to be useful.

[cutting a bit here]

Thanks, this makes sense.  I should be able to set the variables correctly (and actually, the lilypond "binary" in the app bundle is already a script that sets a few variables and calls the real executable, so putting a few more in there should not be a problem).   

I've created https://gitlab.com/marnen/lilypond-mac-builder/-/issues/23 for this bug.  Feel free to subscribe there for updates, or to create new issues there if they're problems with the 64-bit Mac packaging rather than LilyPond itself.

Great. Glad it seems solvable.

Yeah, if it's just a question of setting a few variables, it shouldn't be too hard to fix.

...but that isn't the case.  Setting those variables (which were actually already set in my shell anyway) appears to have no effect.  Moreover, it's only GhostScript choking on these filenames, not LilyPond.  See the GitLab issue for more.

Best,
--
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

Davide Liessi-2
In reply to this post by Arle Lommel-2
Il giorno mar 17 mar 2020 alle ore 22:36 Arle Lommel
<[hidden email]> ha scritto:
> #2: Update.ly doesn’t work for me when invoked from Frescobaldi. I get this message about a bad CPU type when I run it from Frescobaldi.

Known problem, depending only on Frescobaldi, see
https://github.com/frescobaldi/frescobaldi/issues/1232
I have already fixed it in a pull request: Frescobaldi 3.1.2 will have it.

Best wishes.
Davide

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

marnen


On Tue, Mar 17, 2020 at 7:17 PM Davide Liessi <[hidden email]> wrote:
Il giorno mar 17 mar 2020 alle ore 22:36 Arle Lommel
<[hidden email]> ha scritto:
> #2: Update.ly doesn’t work for me when invoked from Frescobaldi. I get this message about a bad CPU type when I run it from Frescobaldi.

Known problem, depending only on Frescobaldi, see
https://github.com/frescobaldi/frescobaldi/issues/1232
I have already fixed it in a pull request: Frescobaldi 3.1.2 will have it.

Will that work on Mac OS without the problems that have plagued the other 3.x versions of Fresco?



Best wishes.
Davide
--
Marnen Laibow-Koser [hidden email] http://www.marnen.org Sent from Gmail Mobile
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

Davide Liessi-2
Il giorno mer 18 mar 2020 alle ore 00:23 Marnen Laibow-Koser
<[hidden email]> ha scritto:
> Will that work on Mac OS without the problems that have plagued the other 3.x versions of Fresco?

I solved some problems, but unfortunately not all.
The main packaging problem concerning PyQtWebEngine, which caused
crashes on startup or when using some panels, is not solved yet, but
3.1.2 will fail gracefully, simply disabling the features depending on
WebEngine (Documentation browser, SVG viewer).

Best wishes.
Davide

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

marnen


On Tue, Mar 17, 2020 at 7:45 PM Davide Liessi <[hidden email]> wrote:
Il giorno mer 18 mar 2020 alle ore 00:23 Marnen Laibow-Koser
<[hidden email]> ha scritto:
> Will that work on Mac OS without the problems that have plagued the other 3.x versions of Fresco?

I solved some problems, but unfortunately not all.
The main packaging problem concerning PyQtWebEngine, which caused
crashes on startup or when using some panels, is not solved yet, but
3.1.2 will fail gracefully, simply disabling the features depending on
WebEngine (Documentation browser, SVG viewer).

Understood.  I look forward to trying it; thanks!



Best wishes.
Davide
--
Marnen Laibow-Koser [hidden email] http://www.marnen.org Sent from Gmail Mobile
Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

Aaron Hill
In reply to this post by marnen
On 2020-03-17 11:05 pm, Marnen Laibow-Koser wrote:
> AFAIK this was never proper syntax to begin with.  Does it compile with
> LilyPond 2.18?  I'd be surprised if it does.

Definitely valid syntax in 2.18.2 [1]:

%%%%
\version "2.18.2"

\paper {
   indent = #0 ragged-right = ##f
   system-system-spacing #'padding = #20
}

{ b'1 \break b'1 }
%%%%

[1]: http://lilybin.com/99jt2g/1


-- Aaron Hill

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

Thomas Morley-2
Am Mi., 18. März 2020 um 07:49 Uhr schrieb Aaron Hill
<[hidden email]>:

>
> On 2020-03-17 11:05 pm, Marnen Laibow-Koser wrote:
> > AFAIK this was never proper syntax to begin with.  Does it compile with
> > LilyPond 2.18?  I'd be surprised if it does.
>
> Definitely valid syntax in 2.18.2 [1]:
>
> %%%%
> \version "2.18.2"
>
> \paper {
>    indent = #0 ragged-right = ##f
>    system-system-spacing #'padding = #20
> }
>
> { b'1 \break b'1 }
> %%%%
>
> [1]: http://lilybin.com/99jt2g/1
>
>
> -- Aaron Hill
>

Yep. Though,
system-system-spacing.padding = #20
works as well in 2.18.2.
Looks like there's no convert-rule for it.

David?

Cheers,
  Harm

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

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

> Am Mi., 18. März 2020 um 07:49 Uhr schrieb Aaron Hill
> <[hidden email]>:
>>
>> On 2020-03-17 11:05 pm, Marnen Laibow-Koser wrote:
>> > AFAIK this was never proper syntax to begin with.  Does it compile with
>> > LilyPond 2.18?  I'd be surprised if it does.
>>
>> Definitely valid syntax in 2.18.2 [1]:
>>
>> %%%%
>> \version "2.18.2"
>>
>> \paper {
>>    indent = #0 ragged-right = ##f
>>    system-system-spacing #'padding = #20
>> }
>>
>> { b'1 \break b'1 }
>> %%%%
>>
>> [1]: http://lilybin.com/99jt2g/1
>>
>>
>> -- Aaron Hill
>>
>
> Yep. Though,
> system-system-spacing.padding = #20
> works as well in 2.18.2.
> Looks like there's no convert-rule for it.
>
> David?

Issue 4068.  Looks like I considered the rule too likely for false
positives to let it stay permanently.

The rationale in the issue states:

    When pushed to staging, another commit reverting the convert-ly rule
    will be added since we don't want to apply somewhat generic patterns
    like those on unknown user-provided code when unchanged code remains
    valid.

Of course, since then the "when unchanged code remains valid" bit went
out the window in issue 4800.

Maybe one would want to reintroduce a more specific version of the issue
4068 rule restricted to known variables and/or only within
\header/\layout/\paper blocks?

For which version number then?  Likely the one for issue 4800?

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

David Kastrup
In reply to this post by marnen
Marnen Laibow-Koser <[hidden email]> writes:

> On Wed, Mar 18, 2020 at 12:57 AM Zone Dremik <[hidden email]> wrote:
>
>> Hello, convert.ly is not working as you described. Here are some code
>> excerpts.
>> Let me know if there is anything else I can send that would be helpful.
>>
>> From a file previously created with Frescobaldi 2.20 & Lilypond 2.18:
>>
>> \version "2.18.0"
>> \include "english.ly"
>> \include "Three White Gulls (Melody).ly"
>> \include "Three White Gulls (Verses).ly"
>> \include "Three White Gulls (Chords).ly"
>> \paper {
>> #(set-paper-size "letter")
>> system-system-spacing #'basic-distance = #15
>> markup-system-spacing #'basic-distance = #24
>>
> [...]
>
> AFAIK this was never proper syntax to begin with.  Does it compile with
> LilyPond 2.18?  I'd be surprised if it does.

It was prior to 2.18, and it was merely discouraged with 2.18 (in the
course of which all occurences got replaced).  There were good reasons
for retiring the syntax for good, but they were not accompanied by a
suitable convert-ly rule.

So basically the complaint is valid.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

Davide Liessi-2
In reply to this post by David Kastrup
Dear David,

Il giorno mer 18 mar 2020 alle ore 09:48 David Kastrup <[hidden email]> ha scritto:
> For which version number then?  Likely the one for issue 4800?

I may be wrong, but shouldn't it be for the version containing the new
convert-ly rule (that is, by now, later than 2.20.0)?
If a user has already used convert-ly on a file, as in Zon's case,
then the file already has a 2.20.0 version statement and rules for
previous versions would not be applied by a subsequent run of
convert-ly.

Best wishes.
Davide

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

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

> Dear David,
>
> Il giorno mer 18 mar 2020 alle ore 09:48 David Kastrup <[hidden email]> ha scritto:
>> For which version number then?  Likely the one for issue 4800?
>
> I may be wrong, but shouldn't it be for the version containing the new
> convert-ly rule (that is, by now, later than 2.20.0)?
> If a user has already used convert-ly on a file, as in Zon's case,
> then the file already has a 2.20.0 version statement and rules for
> previous versions would not be applied by a subsequent run of
> convert-ly.

It doesn't make sense to have convert-ly produce non-working code for
version 2.19.40 .  And convert-ly cannot promise to fix code that never
worked due to its combination of version statement and old syntax.

It isn't guaranteed that you can run convert-ly multiple times for the
same version range without producing invalid code.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

Davide Liessi-2
Il giorno mer 18 mar 2020 alle ore 13:07 David Kastrup <[hidden email]> ha scritto:
> It doesn't make sense to have convert-ly produce non-working code for
> version 2.19.40 .  And convert-ly cannot promise to fix code that never
> worked due to its combination of version statement and old syntax.
>
> It isn't guaranteed that you can run convert-ly multiple times for the
> same version range without producing invalid code.

Would it make sense to have the rule twice, once for the correct
version and once for post-2.20.0?
That would produce working code for 2.19.40, while also taking care of
files that were diligently converted with convert-ly up to 2.20.0 (the
invalid code in those files is not the user's error but convert-ly's).
Of course provided that the applying the rule twice doesn't ruin the code.

Davide

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

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

> Il giorno mer 18 mar 2020 alle ore 13:07 David Kastrup <[hidden email]> ha scritto:
>> It doesn't make sense to have convert-ly produce non-working code for
>> version 2.19.40 .  And convert-ly cannot promise to fix code that never
>> worked due to its combination of version statement and old syntax.
>>
>> It isn't guaranteed that you can run convert-ly multiple times for the
>> same version range without producing invalid code.
>
> Would it make sense to have the rule twice, once for the correct
> version and once for post-2.20.0?
> That would produce working code for 2.19.40, while also taking care of
> files that were diligently converted with convert-ly up to 2.20.0 (the
> invalid code in those files is not the user's error but convert-ly's).

Frankly, if you don't keep the originals when producing non-working
code, you could still reapply with the given version range.

And I don't really see the point in providing extra rules for converting
code that never could possibly have worked due to the combination of old
syntax with new \version statement.

That's sort of a bottomless pit.

> Of course provided that the applying the rule twice doesn't ruin the
> code.

At any rate, this is somewhat academical without having a rule for which
we are not certain that applying it once may ruin the code.  That was
part of the justification for not keeping the previously used rule
permanently.  And if we have such dangerous conversions, then jumping
from applying them not at all to applying them several times seems like
adding nuisance (namely people having to manually undo the effects
several times in a row).

--
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

David Wright
In reply to this post by David Kastrup
On Wed 18 Mar 2020 at 16:18:02 (+0000), Zone Dremik wrote:
>  It was quite a few years ago that copied this code sample from the LilyPond Notation Reference v2.18.2 webpage:
> http://lilypond.org/doc/v2.18/Documentation/notation/flexible-vertical-spacing-paper-variables
> I've compiled hundreds of Lead-Sheets with it, but haven't up-dated Lilypond since 2.18.2 until now.

Perhaps you could run sed over the files, if the relevant lines are
formatted reasonably consistently. Something like:

$ cat /tmp/sed.ly
  system-system-spacing = #'((minimum-distance . 0) (basic-distance . 15) (padding . 9))
  markup-system-spacing #'basic-distance = #15
  top-system-spacing   #'basic-distance  =#15
  last-bottom-spacing #'basic-distance=  #15
  last-bottom-spacing #'padding=#9
$ sed -e "s/\(-spacing\)[ ]\+#'\([^ ]\+\)[ ]*=[ ]*#/\1.\2 = #/;" /tmp/sed.ly
  system-system-spacing = #'((minimum-distance . 0) (basic-distance . 15) (padding . 9))
  markup-system-spacing.basic-distance = #15
  top-system-spacing.basic-distance = #15
  last-bottom-spacing.basic-distance = #15
  last-bottom-spacing.padding = #9
$

Cheers,
David.

Reply | Threaded
Open this post in threaded view
|

Re: 64-bit Mac build of 2.20 is now available!

marnen
In reply to this post by marnen


On Tue, Mar 17, 2020 at 7:06 PM Marnen Laibow-Koser <[hidden email]> wrote:
On Tue, Mar 17, 2020 at 6:48 PM Marnen Laibow-Koser <[hidden email]> wrote:
On Tue, Mar 17, 2020 at 6:43 PM Arle Lommel <[hidden email]> wrote:
Glad my feedback seems to be useful.

[cutting a bit here]

Thanks, this makes sense.  I should be able to set the variables correctly (and actually, the lilypond "binary" in the app bundle is already a script that sets a few variables and calls the real executable, so putting a few more in there should not be a problem).   

I've created https://gitlab.com/marnen/lilypond-mac-builder/-/issues/23 for this bug.  Feel free to subscribe there for updates, or to create new issues there if they're problems with the 64-bit Mac packaging rather than LilyPond itself.

Great. Glad it seems solvable.

Yeah, if it's just a question of setting a few variables, it shouldn't be too hard to fix.

...but that isn't the case.  Setting those variables (which were actually already set in my shell anyway) appears to have no effect.  Moreover, it's only GhostScript choking on these filenames, not LilyPond.  See the GitLab issue for more.

This issue appears related to http://lilypond.1069038.n5.nabble.com/Ghostscript-fails-with-special-characters-in-filename-td80105.html .  Was that ever fixed?  It's not clear from the mailing list archive.

Best,
--
12