Re: 64-bit MacBook Air M2 problems

[Jean Abou Samra]

Le 18/08/2022 à 14:18, Ian West a écrit :

Thanks gentlemen. You have been most helpful.

  * I am motoring with the 2.22.0 manual; so far everything is
working. When it does not, I shall search out the 2.20 as you suggest.
  * I started to load Frescobaldi, and indeed downloaded
MacPorts-2.7.2-12-Monterey.pkg. But could not face it. I have seen
command line used, once, but would have to look up how to use it.
Too much I fear.




You don't know to know how to use the command line in order to use
the .pkg installer. Quoting the tutorial: “In the Finder, double-click
on the file to run the installer.” It's as simple as that :-)

Best,
Jean

Re: 64-bit MacBook Air M2 problems

[Ian West]

Thanks gentlemen. You have been most helpful.
I am motoring with the 2.22.0 manual; so far everything is working. When it 
does not, I shall search out the 2.20 as you suggest.
I started to load Frescobaldi, and indeed downloaded 
MacPorts-2.7.2-12-Monterey.pkg. But could not face it. I have seen command line 
used, once, but would have to look up how to use it. Too much I fear.
Anyway, there is something very satisfying about the ‘longhand’ approach to 
writing music. I had one of the first copies of Sibelius sold (running on an 
Archimedes computer), but threw it and the Archimedes out and refused to buy 
another as the company would not credit me the £500 I had already spent. Made 
do with ABC,  Noteworthy and suchlike till I found Lilypond. They say it is not 
the arrival but the travelling, and I think it may apply here; but you know you 
are travelling when you get a score at the end. Compare a wordprocessor and 
setting type into a tray.
Viva Lilypond!
Best wishes, Ian West

---
Ian West
9 Thenford Road, Middleton Cheney,
BANBURY, OX17 2NB,
Tel: 01295 713 889; (Mobile: 07474 572 588)
==

> On 16 Aug 2022, at 21:41, Jean Abou Samra  wrote:
> 
> 
> 
>> Le 16 août 2022 à 22:16, Ian West  a écrit :
>> 
>> 
>> I reset my laptop to abolish 'smart quotes' . Successful. But there must be 
>> other subtleties that are frustrating me.
> 
> 
> If you have issues, please tell what they are, or we cannot do anything to 
> help you :-)
> 
> Have you tried setting up Frescobaldi as I recommended?
> 
> 
>> Perhaps if I type the text with textedit, then copy and paste to feed it to 
>> Ly. Or just change the suffix from .txt to .ly?
>> 
>> It has proved impossible to find a manual for version 2.20.0. What is it 
>> that I am doing wrong?
> 
> 
> Take the 2.22 manual
> 
> https://lilypond.org/doc/v2.22/Documentation/notation/index.fr.html 
> <https://lilypond.org/doc/v2.22/Documentation/notation/index.fr.html>
> 
> and replace "2.22" in the URL with "2.20", giving
> 
> https://lilypond.org/doc/v2.20/Documentation/notation/index.fr.html 
> <https://lilypond.org/doc/v2.20/Documentation/notation/index.fr.html>
> 
> 
>> I am inclined to think that, if Google cannot find it, then it does not 
>> exist. I do not know which would be better: use 2.18.x or 2.22.x?
> 
> 
> In theory, 2.22.x, which is the latest stable version, but to my knowledge 
> you won’t find a macOS 64-bit download for it like the unofficial bundle of 
> LilyPond 2.20. You have to use either MacPorts or HomeBrew, which are package 
> managers for macOS. If you don’t know how to use the command line or what it 
> even is, this is not recommended. Instead, use 2.23, which while being a 
> development release series is quite stable currently, and has official macOS 
> 64-bit binaries.
> 
> Best,
> Jean
> 
> 
> 
>> Ian West
>> 
>> 
>>> On 16 Aug 2022, at 11:08, Ian West >> <mailto:ian42w...@gmail.com>> wrote:
>>> 
>>> Thanks Hans, and Jean.
>>> I shall try and learn up those tricks. 
>>> Ian
>>> 
>>> ==
>>>> On 15 Aug 2022, at 17:01, Hans Åberg >>> <mailto:haber...@telia.com>> wrote:
>>>> 
>>>> 
>>>>> On 15 Aug 2022, at 17:57, Jean Abou Samra >>>> <mailto:j...@abou-samra.fr>> wrote:
>>>>> 
>>>>> Also, when you enter the apostrophe from the keyboard, is it really
>>>>> a straight apostrophe  ->   '   <-  or could it be that macOS does
>>>>> you the “favor” to replace it with a curly apostrophe ->’ <- ?
>>>>> LilyPond expects straight apostrophes. If this is the problem, you need
>>>>> to fix your macOS settings somewhere to prevent those “smart quotes”.
>>>> 
>>>> One can turn those off at System Preferences → Keyboard → Text → Use smart 
>>>> quotes and dashes. Those are reachable at least from the keyboard map I am 
>>>> using, so I decided to type them by hand at need.
>>>> 
>>>> Also, one can add custom text replacements, which I use for example for 
>>>> the arrows above.
>>>> 
>>>> 
>>> 
>> 

Re: 64-bit MacBook Air M2 problems

[Jean Abou Samra]

> Le 16 août 2022 à 22:16, Ian West  a écrit :
> 
> 
> I reset my laptop to abolish 'smart quotes' . Successful. But there must be 
> other subtleties that are frustrating me.


If you have issues, please tell what they are, or we cannot do anything to help 
you :-)

Have you tried setting up Frescobaldi as I recommended?


> Perhaps if I type the text with textedit, then copy and paste to feed it to 
> Ly. Or just change the suffix from .txt to .ly?
> 
> It has proved impossible to find a manual for version 2.20.0. What is it that 
> I am doing wrong?


Take the 2.22 manual

https://lilypond.org/doc/v2.22/Documentation/notation/index.fr.html

and replace "2.22" in the URL with "2.20", giving

https://lilypond.org/doc/v2.20/Documentation/notation/index.fr.html


> I am inclined to think that, if Google cannot find it, then it does not 
> exist. I do not know which would be better: use 2.18.x or 2.22.x?


In theory, 2.22.x, which is the latest stable version, but to my knowledge you 
won’t find a macOS 64-bit download for it like the unofficial bundle of 
LilyPond 2.20. You have to use either MacPorts or HomeBrew, which are package 
managers for macOS. If you don’t know how to use the command line or what it 
even is, this is not recommended. Instead, use 2.23, which while being a 
development release series is quite stable currently, and has official macOS 
64-bit binaries.

Best,
Jean



> Ian West
> 
> 
>> On 16 Aug 2022, at 11:08, Ian West  wrote:
>> 
>> Thanks Hans, and Jean.
>> I shall try and learn up those tricks. 
>> Ian
>> 
>> ==
>>>> On 15 Aug 2022, at 17:01, Hans Åberg  wrote:
>>>> 
>>>> 
>>>> On 15 Aug 2022, at 17:57, Jean Abou Samra  wrote:
>>>> 
>>>> Also, when you enter the apostrophe from the keyboard, is it really
>>>> a straight apostrophe  ->   '   <-  or could it be that macOS does
>>>> you the “favor” to replace it with a curly apostrophe ->’ <- ?
>>>> LilyPond expects straight apostrophes. If this is the problem, you need
>>>> to fix your macOS settings somewhere to prevent those “smart quotes”.
>>> 
>>> One can turn those off at System Preferences → Keyboard → Text → Use smart 
>>> quotes and dashes. Those are reachable at least from the keyboard map I am 
>>> using, so I decided to type them by hand at need.
>>> 
>>> Also, one can add custom text replacements, which I use for example for the 
>>> arrows above.
>>> 
>>> 
>> 
> 

Re: 64-bit MacBook Air M2 problems

[Ian West]

I reset my laptop to abolish 'smart quotes' . Successful. But there must be 
other subtleties that are frustrating me. Perhaps if I type the text with 
textedit, then copy and paste to feed it to Ly. Or just change the suffix from 
.txt to .ly?

It has proved impossible to find a manual for version 2.20.0. What is it that I 
am doing wrong? I am inclined to think that, if Google cannot find it, then it 
does not exist. I do not know which would be better: use 2.18.x or 2.22.x?

Ian West


> On 16 Aug 2022, at 11:08, Ian West  wrote:
> 
> Thanks Hans, and Jean.
> I shall try and learn up those tricks. 
> Ian
> 
> ==
>> On 15 Aug 2022, at 17:01, Hans Åberg  wrote:
>> 
>> 
>>> On 15 Aug 2022, at 17:57, Jean Abou Samra  wrote:
>>> 
>>> Also, when you enter the apostrophe from the keyboard, is it really
>>> a straight apostrophe  ->   '   <-  or could it be that macOS does
>>> you the “favor” to replace it with a curly apostrophe ->’ <- ?
>>> LilyPond expects straight apostrophes. If this is the problem, you need
>>> to fix your macOS settings somewhere to prevent those “smart quotes”.
>> 
>> One can turn those off at System Preferences → Keyboard → Text → Use smart 
>> quotes and dashes. Those are reachable at least from the keyboard map I am 
>> using, so I decided to type them by hand at need.
>> 
>> Also, one can add custom text replacements, which I use for example for the 
>> arrows above.
>> 
>> 
> 

Re: 64-bit MacBook Air M2 problems

[Jean Abou Samra]

Hello,

Please keep the list in copy so everyone can participate and learn from 
the answers.


Le 16/08/2022 à 12:03, Ian West a écrit :

Dear Jean,
Thank you for replying.

I got your address from the Gitlab website, describing you as 
“Factotum” . I thought that role best suited my questions.



I guess you mean the LilyPond website, the place where I'm mentioned as 
"factotum" is here: https://lilypond.org/authors.html


Anyway, I see now. For support questions, it is actually better to post 
on the lilypond-user mailing list, which is specifically dedicated to 
that. See https://lilypond.org/contact.html. Let's keep this one on 
lilypond-devel, but try posting to lilypond-user next time.




I also thought the MacBook was doing me “the favour” of using the wrong 
apostrophe, which is why I copied and pasted. But I am not using an Apple text 
editor; I type straight into Lilypond. Apple keyboard certainly. I can look up ASCII 
codes I am sure; I did it 30 years ago in the early days. Anyway, thanks for tips 
like -> ‘<-, and where to change straight to smart quotes.



What's important to understand is that job the core program
“LilyPond” is only to convert an input file to an output file.
For macOS, we used to ship a minimalistic application with
a very simplistic text editor. I assume this is what you are
using. I *strongly* recommend to use something else. Try
Frescobaldi, really. I was reluctant to try it during the first two
years I used LilyPond. When I did try it, it was a relief and I
blamed myself for not doing that earlier.

Again, the tutorial I linked in my previous email has complete
instructions on how to set up LilyPond 2.23 with Frescobaldi
on macOS 64-bit.

Normally, Frescobaldi won't have problems with curly apostrophes
(at least I don't recall anyone had that problem with Frescobaldi).

Best,
Jean

Re: 64-bit MacBook Air M2 problems

[Ian West]

Thanks Hans, and Jean.
I shall try and learn up those tricks. 
Ian

==
> On 15 Aug 2022, at 17:01, Hans Åberg  wrote:
> 
> 
>> On 15 Aug 2022, at 17:57, Jean Abou Samra  wrote:
>> 
>> Also, when you enter the apostrophe from the keyboard, is it really
>> a straight apostrophe  ->   '   <-  or could it be that macOS does
>> you the “favor” to replace it with a curly apostrophe ->’ <- ?
>> LilyPond expects straight apostrophes. If this is the problem, you need
>> to fix your macOS settings somewhere to prevent those “smart quotes”.
> 
> One can turn those off at System Preferences → Keyboard → Text → Use smart 
> quotes and dashes. Those are reachable at least from the keyboard map I am 
> using, so I decided to type them by hand at need.
> 
> Also, one can add custom text replacements, which I use for example for the 
> arrows above.
> 
> 

Re: 64-bit MacBook Air M2 problems

[Hans Åberg]

> On 15 Aug 2022, at 17:57, Jean Abou Samra  wrote:
> 
> Also, when you enter the apostrophe from the keyboard, is it really
> a straight apostrophe  ->   '   <-  or could it be that macOS does
> you the “favor” to replace it with a curly apostrophe ->’ <- ?
> LilyPond expects straight apostrophes. If this is the problem, you need
> to fix your macOS settings somewhere to prevent those “smart quotes”.

One can turn those off at System Preferences → Keyboard → Text → Use smart 
quotes and dashes. Those are reachable at least from the keyboard map I am 
using, so I decided to type them by hand at need.

Also, one can add custom text replacements, which I use for example for the 
arrows above.

Re: 64-bit MacBook Air M2 problems

[Jean Abou Samra]

Hello Ian,


Le 15/08/2022 à 12:41, Ian West a écrit :

Dear Jean,



As a point of curiosity, I am not sure why you address me specifically
(unless you know me somehow? I do not recall your name, either I do
not know you or I need to seriously worry about amnesia). The whole point
of asking a question on a mailing list is that everyone can answer :-)



I have been using Lilypond for some 10 years; first 2.12.3, then 2.18.2.
I just bought a new MacBook Air, which uses the new 64-bit M2 chip. I 
understood I could not use the 2.18.2; that the 64-bit chip required 
the “unofficial” version 2.20.0. So I loaded that, and it runs all the 
tunes that I tried. But it is very difficult to write new music. It is 
proving very hard to work out what some of the problems are.
[1]. There is some new language to learn, new ways to do things. But 
the manuals v2.22.0, and  v2.22.2 help and I am learning.
[2]  There are some baffling problems. It seems that the single 
apostrophe (used to raise the pitch by one octave) on the keyboard 
does not work. But, if I copy-and-paste from the manual, I can get 
round that problem.
[3]  The header section is absurdly sensitive. I can paste in from the 
manual:

\header {
   title = "SUITE I."
   composer = "J. S. Bach."
}
and it works. But my piece is by Monteverdi. I can change the title to 
“Take not my treasure”, but I cannot change Bach to Monteverdi. !!!




What text editor are you using to edit LilyPond code? Surely
that is a problem with the editor rather than the core LilyPond
program itself, especially if it works when you copy/paste instead
of entering with the keyboard.

Also, when you enter the apostrophe from the keyboard, is it really
a straight apostrophe  ->   '   <-  or could it be that macOS does
you the “favor” to replace it with a curly apostrophe ->    ’ <- ?
LilyPond expects straight apostrophes. If this is the problem, you need
to fix your macOS settings somewhere to prevent those “smart quotes”.

Best,
Jean

64-bit MacBook Air M2 problems

[Ian West]

Dear Jean,
I have been using Lilypond for some 10 years; first 2.12.3, then 2.18.2.
I just bought a new MacBook Air, which uses the new 64-bit M2 chip. I 
understood I could not use the 2.18.2; that the 64-bit chip required the 
“unofficial” version 2.20.0. So I loaded that, and it runs all the tunes that I 
tried. But it is very difficult to write new music. It is proving very hard to 
work out what some of the problems are.
[1]. There is some new language to learn, new ways to do things. But the 
manuals v2.22.0, and  v2.22.2 help and I am learning.
[2]  There are some baffling problems. It seems that the single apostrophe 
(used to raise the pitch by one octave) on the keyboard does not work. But, if 
I copy-and-paste from the manual, I can get round that problem. 
[3]  The header section is absurdly sensitive. I can paste in from the manual:
\header {
  title = "SUITE I."
  composer = "J. S. Bach."
}
and it works. But my piece is by Monteverdi. I can change the title to “Take 
not my treasure”, but I cannot change Bach to Monteverdi. !!!

Yours sincerely, Ian West

P.S. 
 Unofficial 64-bit application bundles for macOS 10.15 are available at 
https://bintray.com/marnen/lilypond-darwin-64 
<https://bintray.com/marnen/lilypond-darwin-64>.

---
Ian West
9 Thenford Road, Middleton Cheney,
BANBURY, OX17 2NB,
Tel: 01295 713 889; (Mobile: 07474 572 588)
==

Re: New URLs for 64-bit Mac downloads

[Marnen Laibow-Koser]

On Wed, Apr 28, 2021 at 5:25 PM Jean Abou Samra  wrote:

>
> Le 26/04/2021 à 04:33, Marnen Laibow-Koser a écrit :
> > Folks--
> >
> > I've been hosting our 64-bit Mac downloads at Bintray, but Bintray is
> > shutting down as of 1 May, so I've moved the downloads to the GitLab
> > project.  They can now be found at
> > https://gitlab.com/marnen/lilypond-mac-builder/-/releases or (a few more
> > files, but different UI) at
> > https://gitlab.com/marnen/lilypond-mac-builder/-/packages .  Can we
> update
> > the Lilypond website with one of these URLs before Bintray goes away on 1
> > May?  Thanks!
> >
> > Best,
>
> Here you go:
>
> https://gitlab.com/lilypond/lilypond/-/merge_requests/743


Thanks, beat me to it! :)

<https://gitlab.com/lilypond/lilypond/-/merge_requests/743>
>
> (Next time, it might be just as convenient for you to put up a merge
> request yourself on GitLab, which makes it easy to contribute these days.)


Yes, I would have done that if I’d realized that we were managing the
website that way.  Now I know. :)


>
> Best,
> Jean
>
> --
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: New URLs for 64-bit Mac downloads

[Jean Abou Samra]

Le 26/04/2021 à 04:33, Marnen Laibow-Koser a écrit :

Folks--

I've been hosting our 64-bit Mac downloads at Bintray, but Bintray is
shutting down as of 1 May, so I've moved the downloads to the GitLab
project.  They can now be found at
https://gitlab.com/marnen/lilypond-mac-builder/-/releases or (a few more
files, but different UI) at
https://gitlab.com/marnen/lilypond-mac-builder/-/packages .  Can we update
the Lilypond website with one of these URLs before Bintray goes away on 1
May?  Thanks!

Best,


Here you go:

https://gitlab.com/lilypond/lilypond/-/merge_requests/743

(Next time, it might be just as convenient for you to put up a merge 
request yourself on GitLab, which makes it easy to contribute these days.)


Best,
Jean

Re: New URLs for 64-bit Mac downloads

[James]

Hello

On 26/04/2021 03:33, Marnen Laibow-Koser wrote:

Folks--

I've been hosting our 64-bit Mac downloads at Bintray, but Bintray is
shutting down as of 1 May, so I've moved the downloads to the GitLab
project.  They can now be found at
https://gitlab.com/marnen/lilypond-mac-builder/-/releases or (a few more
files, but different UI) at
https://gitlab.com/marnen/lilypond-mac-builder/-/packages .  Can we update
the Lilypond website with one of these URLs before Bintray goes away on 1
May?  Thanks!

Best,


I've logged the request

https://gitlab.com/lilypond/lilypond/-/issues/6130

Thank you.

James

--
--

regards

James

New URLs for 64-bit Mac downloads

[Marnen Laibow-Koser]

Folks--

I've been hosting our 64-bit Mac downloads at Bintray, but Bintray is
shutting down as of 1 May, so I've moved the downloads to the GitLab
project.  They can now be found at
https://gitlab.com/marnen/lilypond-mac-builder/-/releases or (a few more
files, but different UI) at
https://gitlab.com/marnen/lilypond-mac-builder/-/packages .  Can we update
the Lilypond website with one of these URLs before Bintray goes away on 1
May?  Thanks!

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: Lilypond 64-bit binaries

[Jacques Menu]

> Le 22 avr. 2021 à 21:07, Marnen Laibow-Koser  a écrit :
> 
> 
> 
> On Thu, Apr 22, 2021 at 3:04 PM Jacques Menu  > wrote:
> Hello,
> 
> Starting yesterday, I ‘m now running LilyPond 2.20.0  on a Apple mini M1 
> running under Big Sur 11.2.3.
> 
> Cool!
> 
> I can contribute to building Mac OS versions on my machine.
> 
> The reason we’re currently doing Mac builds on MacStadium is that I do not 
> want the availability of Mac builds to depend on someone happening to have a 
> personal Mac available.  So while I appreciate your offer, I’d much rather 
> that we get some public infrastructure set up (if what we already have isn’t 
> sufficient). 
> 
> I’ll try to take a look at this more over the weekend. 
> 
> 
> 
> For my own work, I use AppVeyor, as has been setup by Grame’s Dom Fober, to 
> build installable Mac OS versions.
> 
> Installable on what?


I don’t know all the details. I’ll contact Dom and let you know.

JM

Re: Lilypond 64-bit binaries

[Marnen Laibow-Koser]

On Thu, Apr 22, 2021 at 3:04 PM Jacques Menu  wrote:

> Hello,
>
> Starting yesterday, I ‘m now running LilyPond 2.20.0  on a Apple mini M1
> running under Big Sur 11.2.3.
>

Cool!

I can contribute to building Mac OS versions on my machine.
>

The reason we’re currently doing Mac builds on MacStadium is that I do not
want the availability of Mac builds to depend on someone happening to have
a personal Mac available.  So while I appreciate your offer, I’d much
rather that we get some public infrastructure set up (if what we already
have isn’t sufficient).

I’ll try to take a look at this more over the weekend.

>


> For my own work, I use AppVeyor, as has been setup by Grame’s Dom Fober,
> to build installable Mac OS versions.
>

Installable on what?

Is that something that could help solve this issue?
>
> JM
>
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: Lilypond 64-bit binaries

[Jacques Menu]

Hello,

Starting yesterday, I ‘m now running LilyPond 2.20.0  on a Apple mini M1 
running under Big Sur 11.2.3.
I can contribute to building Mac OS versions on my machine.

For my own work, I use AppVeyor, as has been setup by Grame’s Dom Fober, to 
build installable Mac OS versions. Is that something that could help solve this 
issue?

JM

> Le 22 avr. 2021 à 20:16, Carl Sorensen  a écrit :
> 
> Marnen,
>  
> This is a response to an email from more than a year ago.  Our situation 
> hasn’t improved since then, even though you did all your great work.
>  
> What do you think it would take to make this bundle part of the core project?
>  
> I agree with you that it should be part of our core.  But it doesn’t match up 
> with our current build process, because it cannot be done on non-Apple 
> hardware.
>  
> I see from some old emails that you envision some sort of CI that builds an 
> app bundle.  It would need to have access to Apple hardware to do that, IIUC. 
>  Do you have thoughts about how we would get access to that Apple hardware?
>  
> Thanks,
>  
> Carl
>  
>  
> From: Marnen Laibow-Koser mailto:mar...@marnen.org>>
> Date: Thursday, April 2, 2020 at 2:18 PM
> To: Carl Sorensen mailto:c_soren...@byu.edu>>
> Cc: LilyPond Users mailto:lilypond-u...@gnu.org>>, 
> Moritz Heffter mailto:mxo...@me.com>>
> Subject: Re: Lilypond 64-bit binaries
>  
>  
>  
> On Thu, Apr 2, 2020 at 1:49 PM Carl Sorensen  <mailto:c_soren...@byu.edu>> wrote:
>>  
>>  
>> From: Marnen Laibow-Koser mailto:mar...@marnen.org>>
>> Date: Thursday, April 2, 2020 at 11:07 AM
>> To: Carl Sorensen mailto:c_soren...@byu.edu>>
>> Cc: LilyPond Users mailto:lilypond-u...@gnu.org>>, 
>> Moritz Heffter mailto:mxo...@me.com>>
>> Subject: Re: Lilypond 64-bit binaries
>>  
>>  
>>  
>> On Thu, Apr 2, 2020 at 1:02 PM Carl Sorensen > <mailto:c_soren...@byu.edu>> wrote:
>>> I note that Moritz mentions he gets the same results from the MacPorts 
>>> build.  Perhaps the MacPorts people could provide some insight.
>>  
>> Hmm.  I wonder if I should try using a more recent version of Mac OS and 
>> Xcode on the build box.  I was using the oldest possible version in order to 
>> produce the most backward-compatible build. 
>>  
>> But...if this is a general issue with Catalina, why are so few users 
>> affected by it, and why are users on Mojave among those affected?
>>  
>> I don’t think it’s a general issue.  I think it’s a specific issue, that 
>> varies from machine to machine.  My only suggestion was that perhaps 
>> somebody in the MacPorts group might be able to provide some debugging 
>> helps.  Hopefully the issue is the same in MacPorts as in your app bundle, 
>> so if it can be resolved in MacPorts it can be resolved in the app bundle….
>  
> Yeah, that might be a good point.  I think this is the first time we've seen 
> a MacPorts build have this same problem.
>  
> Also: it's not *my* bundle, except in that I figured out the process to build 
> it.  Ideally, it is the LilyPond project's bundle: I want this to be accepted 
> into the core project, not remain my own personal thing.
>  
>>  
>> Carl
>  
> Best, 
> -- 
> Marnen Laibow-Koser
> mar...@marnen.org <mailto:mar...@marnen.org>
> http://www.marnen.org <http://www.marnen.org/>

Re: Lilypond 64-bit binaries

[Marnen Laibow-Koser]

On Thu, Apr 22, 2021 at 2:48 PM Karlin High  wrote:

> On 4/22/2021 1:32 PM, Kieren MacMillan wrote:
> > I believe I have a client who might be willing to donate time on an
> internet-accessible Apple server.
>
> I'm pretty sure the original discussion mentioned MacStadium, a macOS
> hosting service.
>
> 
>
> "To support the FOSS community, MacStadium is offering FREE Mac mini
> hosting for developers working on open source projects."
>

I think we typed our messages at the same time.  A free OSS account at
MacStadium is in fact our current build box.


> --
> Karlin High
> Missouri, USA
>

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: Lilypond 64-bit binaries

[Marnen Laibow-Koser]

On Thu, Apr 22, 2021 at 2:32 PM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi Carl,
>
> > Do you have thoughts about how we would get access to that Apple
> hardware?
>
> I believe I have a client who might be willing to donate time on an
> internet-accessible Apple server. Feel free to ping me off-list if that
> option is worth pursuing.
>

We already have an Internet-accessible Mac available—our current build box
at MacStadium.  Is that insufficient?


> Cheers,
> Kieren.


Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: Lilypond 64-bit binaries

[Karlin High]

On 4/22/2021 1:32 PM, Kieren MacMillan wrote:

I believe I have a client who might be willing to donate time on an 
internet-accessible Apple server.


I'm pretty sure the original discussion mentioned MacStadium, a macOS 
hosting service.




"To support the FOSS community, MacStadium is offering FREE Mac mini 
hosting for developers working on open source projects."

--
Karlin High
Missouri, USA

Re: Lilypond 64-bit binaries

[Kieren MacMillan]

Hi Carl,

> Do you have thoughts about how we would get access to that Apple hardware?

I believe I have a client who might be willing to donate time on an 
internet-accessible Apple server. Feel free to ping me off-list if that option 
is worth pursuing.

Cheers,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kie...@kierenmacmillan.info

Re: Lilypond 64-bit binaries

[Carl Sorensen]

Marnen,

This is a response to an email from more than a year ago.  Our situation hasn’t 
improved since then, even though you did all your great work.

What do you think it would take to make this bundle part of the core project?

I agree with you that it should be part of our core.  But it doesn’t match up 
with our current build process, because it cannot be done on non-Apple hardware.

I see from some old emails that you envision some sort of CI that builds an app 
bundle.  It would need to have access to Apple hardware to do that, IIUC.  Do 
you have thoughts about how we would get access to that Apple hardware?

Thanks,

Carl


From: Marnen Laibow-Koser 
Date: Thursday, April 2, 2020 at 2:18 PM
To: Carl Sorensen 
Cc: LilyPond Users , Moritz Heffter 
Subject: Re: Lilypond 64-bit binaries



On Thu, Apr 2, 2020 at 1:49 PM Carl Sorensen 
mailto:c_soren...@byu.edu>> wrote:


From: Marnen Laibow-Koser mailto:mar...@marnen.org>>
Date: Thursday, April 2, 2020 at 11:07 AM
To: Carl Sorensen mailto:c_soren...@byu.edu>>
Cc: LilyPond Users mailto:lilypond-u...@gnu.org>>, 
Moritz Heffter mailto:mxo...@me.com>>
Subject: Re: Lilypond 64-bit binaries



On Thu, Apr 2, 2020 at 1:02 PM Carl Sorensen 
mailto:c_soren...@byu.edu>> wrote:
I note that Moritz mentions he gets the same results from the MacPorts build.  
Perhaps the MacPorts people could provide some insight.

Hmm.  I wonder if I should try using a more recent version of Mac OS and Xcode 
on the build box.  I was using the oldest possible version in order to produce 
the most backward-compatible build.

But...if this is a general issue with Catalina, why are so few users affected 
by it, and why are users on Mojave among those affected?

I don’t think it’s a general issue.  I think it’s a specific issue, that varies 
from machine to machine.  My only suggestion was that perhaps somebody in the 
MacPorts group might be able to provide some debugging helps.  Hopefully the 
issue is the same in MacPorts as in your app bundle, so if it can be resolved 
in MacPorts it can be resolved in the app bundle….

Yeah, that might be a good point.  I think this is the first time we've seen a 
MacPorts build have this same problem.

Also: it's not *my* bundle, except in that I figured out the process to build 
it.  Ideally, it is the LilyPond project's bundle: I want this to be accepted 
into the core project, not remain my own personal thing.


Carl

Best,
--
Marnen Laibow-Koser
mar...@marnen.org<mailto:mar...@marnen.org>
http://www.marnen.org

Re: 64-bit Mac build of 2.20 is now available! (convert.ly issue)

[David Kastrup]

David Kastrup  writes:

> Zone Dremik  writes:
>
>>  Thank you David, Marnen, David and Carl for your excellent
>> suggestions and helpful examples. (I will definitely be using more
>> variables in the future.)
>> For the convert.ly issue, your recommendations inspired me to try
>> using BBE. The multi-file search & replace function worked very well
>> (this was with the free version of BBE, so I was very impressed).
>>
>> Further note:
>> I ran a few more of the older files through convert.ly and found
>> that it is finding & updating other instances of obsolete syntax,
>> beyond the two that are missing.
>>
>> Here is a code sample, before & after, for a successful convert.ly:
>>
>> \version "2.12.2"
>> \include "english.ly"
>>  \override LyricText #'font-shape = #'italic
>>
>> \version "2.20.0"
>> \include "english.ly"
>>  \override LyricText.font-shape = #'italic
>>
>> (A side note: By mistake, I ran the compile before convert.ly and
>> was surprised that the Lilypond 2.20 didn't reject the obsolete
>> syntax. I definitely don't have any other versions installed on this
>> machine.)
>
> Yes, overrides and reverts are properly converted.  It's the naked
> assignments that seemed too indistinctive to warrant a generic rule for
> the conversion (there was one used for one-shot conversion of LilyPond's
> own documentation where one can keep the effects in check).

Ok, it seems like (almost?) exclusively variables ending in "-spacing"
are affected here.  That should make a reasonably safe rule
comparatively easy to design.

> I have it on my to-do list to do something here for the sake of
> 2.20.1, but I'm currently laboring on getting 2.21.0 out first: that's
> also urgent.

-- 
David Kastrup

Re: 64-bit Mac build of 2.20 is now available! (convert.ly issue)

[David Kastrup]

Zone Dremik  writes:

>  Thank you David, Marnen, David and Carl for your excellent suggestions and 
> helpful examples. (I will definitely be using more variables in the future.)
> For the convert.ly issue, your recommendations inspired me to try using BBE. 
> The multi-file search & replace function worked very well (this was with the 
> free version of BBE, so I was very impressed).
>
> Further note:
> I ran a few more of the older files through convert.ly and found that it is 
> finding & updating other instances of obsolete syntax, beyond the two that 
> are missing.
>
> Here is a code sample, before & after, for a successful convert.ly:
>
> \version "2.12.2"
> \include "english.ly"
>  \override LyricText #'font-shape = #'italic
>
> \version "2.20.0"
> \include "english.ly"
>  \override LyricText.font-shape = #'italic
>
> (A side note: By mistake, I ran the compile before convert.ly and was 
> surprised that the Lilypond 2.20 didn't reject the obsolete syntax. I 
> definitely don't have any other versions installed on this machine.)

Yes, overrides and reverts are properly converted.  It's the naked
assignments that seemed too indistinctive to warrant a generic rule for
the conversion (there was one used for one-shot conversion of LilyPond's
own documentation where one can keep the effects in check).

I have it on my to-do list to do something here for the sake of 2.20.1,
but I'm currently laboring on getting 2.21.0 out first: that's also
urgent.

-- 
David Kastrup

Re: 64-bit Mac build of 2.20 is now available! (convert.ly issue)

[Zone Dremik via Discussions on LilyPond development]

 Thank you David, Marnen, David and Carl for your excellent suggestions and 
helpful examples. (I will definitely be using more variables in the future.)
For the convert.ly issue, your recommendations inspired me to try using BBE. 
The multi-file search & replace function worked very well (this was with the 
free version of BBE, so I was very impressed).

Further note:
I ran a few more of the older files through convert.ly and found that it is 
finding & updating other instances of obsolete syntax, beyond the two that are 
missing.

Here is a code sample, before & after, for a successful convert.ly:

\version "2.12.2"
\include "english.ly"
 \override LyricText #'font-shape = #'italic

\version "2.20.0"
\include "english.ly"
 \override LyricText.font-shape = #'italic

(A side note: By mistake, I ran the compile before convert.ly and was surprised 
that the Lilypond 2.20 didn't reject the obsolete syntax. I definitely don't 
have any other versions installed on this machine.)

I'm so glad to be back in business with this 64bit build!

All the best
 On Wednesday, March 18, 2020, 10:55:16 PM EDT, David Wright 
 wrote:  
 
 On Wed 18 Mar 2020 at 16:18:02 (+), 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.
  

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

[Marnen Laibow-Koser]

On Tue, Mar 17, 2020 at 7:06 PM Marnen Laibow-Koser 
wrote:

> On Tue, Mar 17, 2020 at 6:48 PM Marnen Laibow-Koser 
> wrote:
>
>> On Tue, Mar 17, 2020 at 6:43 PM Arle Lommel 
>> 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,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

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

[David Wright]

On Wed 18 Mar 2020 at 16:18:02 (+), 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.

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

[David Kastrup]

David Kastrup  writes:

> Marnen Laibow-Koser  writes:
>
>> On Wed, Mar 18, 2020 at 12:18 PM 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.
>>>
>>
>> Right, as David said, it was in fact valid syntax (which I didn’t realize)
>> but convert-ly doesn’t know about it.  D’oh!  So I guess this is under the
>> category of “known issues in convert-ly” rather than “broken build”.  Sorry
>> for the inconvenience!
>
> More like "should have known issues in convert-ly".  Analysis of what
> decisions have led there just came up yesterday.  There likely is going
> to be a fix in 2.20.1 but I cannot yet vouch what.

I may add that this is the kind of thing that happens when everybody
decides that they'll wait for "stable" releases rather than trying out
betas or prereleases.

At some point of time, problems need to get flagged.

-- 
David Kastrup

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

[David Kastrup]

Marnen Laibow-Koser  writes:

> On Wed, Mar 18, 2020 at 12:18 PM 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.
>>
>
> Right, as David said, it was in fact valid syntax (which I didn’t realize)
> but convert-ly doesn’t know about it.  D’oh!  So I guess this is under the
> category of “known issues in convert-ly” rather than “broken build”.  Sorry
> for the inconvenience!

More like "should have known issues in convert-ly".  Analysis of what
decisions have led there just came up yesterday.  There likely is going
to be a fix in 2.20.1 but I cannot yet vouch what.

-- 
David Kastrup

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

[Marnen Laibow-Koser]

On Wed, Mar 18, 2020 at 12:18 PM 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.
>

Right, as David said, it was in fact valid syntax (which I didn’t realize)
but convert-ly doesn’t know about it.  D’oh!  So I guess this is under the
category of “known issues in convert-ly” rather than “broken build”.  Sorry
for the inconvenience!

Best,
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

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

[Zone Dremik via Discussions on LilyPond development]

 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. On Wednesday, March 18, 2020, 11:49:29 AM EDT, 
Marnen Laibow-Koser  wrote:  
 
 

On Wed, Mar 18, 2020 at 6:49 AM David Kastrup  wrote:

Marnen Laibow-Koser  writes:
[...]


> 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.

Huh, that’s odd, but good to know. 



So basically the complaint is valid.

But it sounds like this is an omission (I’d say a bug) in convert-ly itself, 
not necessarily an indication that this build of it is broken, right?



-- 
David Kastrup

Best,-- 
Marnen Laibow-Kosermarnen@marnen.orghttp://www.marnen.orgSent from Gmail Mobile 
 

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

[David Kastrup]

Marnen Laibow-Koser  writes:

> On Wed, Mar 18, 2020 at 6:49 AM David Kastrup  wrote:
>
>> Marnen Laibow-Koser  writes:
>
> [...]
>
>>
>>
>> > 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.
>
>
> Huh, that’s odd, but good to know.
>
>
>>
>> So basically the complaint is valid.
>
>
> But it sounds like this is an omission (I’d say a bug) in convert-ly
> itself, not necessarily an indication that this build of it is broken,
> right?

Right.

-- 
David Kastrup

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

[Marnen Laibow-Koser]

On Wed, Mar 18, 2020 at 6:49 AM David Kastrup  wrote:

> Marnen Laibow-Koser  writes:

[...]

>
>
> > 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.


Huh, that’s odd, but good to know.


>
> So basically the complaint is valid.


But it sounds like this is an omission (I’d say a bug) in convert-ly
itself, not necessarily an indication that this build of it is broken,
right?


>
> --
> David Kastrup


Best,
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

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

[David Kastrup]

Marnen Laibow-Koser  writes:

> On Wed, Mar 18, 2020 at 12:57 AM Zone Dremik  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

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

[Marnen Laibow-Koser]

On Wed, Mar 18, 2020 at 12:57 AM Zone Dremik  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.

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

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

[Zone Dremik via Discussions on LilyPond development]

 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
 top-margin = 5\mm
 bottom-margin = 5\mm
 

>From the convert.ly log:

convert-ly (GNU LilyPond) 2.20.0
convert-ly: Processing `'... 
Applying conversion: 2.19.2, 2.19.7, 2.19.11, 2.19.16, 2.19.22, 2.19.24, 
2.19.28, 2.19.29, 2.19.32, 2.19.40, 2.19.46, 2.19.49, 2.19.80, 2.20.0

-\version "2.18.0"
+\version "2.20.0"
 \include "english.ly"
 \include "Three White Gulls (Melody).ly"
 \include "Three White Gulls (Verses).ly"

(No other changes were made) 
This is from the Lilypond Log after compiling the above code with 2.20:

Starting lilypond 2.20.0 [Three White Gulls (Score).ly]...
Processing `/Users/Zynjanthropis/Music Typesetting/Finished Scores/Three White 
Gulls/Three White Gulls (Score).ly'
Parsing...
/Users/Zynjanthropis/Music Typesetting/Finished Scores/Three White Gulls/Three 
White Gulls (Score).ly:14:25: error: syntax error, unexpected SCM_TOKEN, 
expecting ',' or '.' or '='
 system-system-spacing 
 #'basic-distance = #15 
Interpreting music...[8][16]
Preprocessing graphical objects...
Interpreting music...
MIDI output to `Three White Gulls (Score).midi'...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to 
`/var/folders/pk/2rfgzwtd2vj6fbn6pj30z41wgq/T//lilypond-QVR8nQ'...
Converting to `Three White Gulls (Score).pdf'...
Deleting `/var/folders/pk/2rfgzwtd2vj6fbn6pj30z41wgq/T//lilypond-QVR8nQ'...
fatal error: failed files: "/Users/Zynjanthropis/Music Typesetting/Finished 
Scores/Three White Gulls/Three White Gulls (Score).ly"
Exited with return code 1.

 On Tuesday, March 17, 2020, 02:28:33 PM EDT, Marnen Laibow-Koser 
 wrote:  
 
 On Tue, Mar 17, 2020 at 12:10 PM Zone Dremik  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,-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org  

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

[Marnen Laibow-Koser]

On Tue, Mar 17, 2020 at 12:10 PM Zone Dremik  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,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

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

[Zone Dremik via Discussions on LilyPond development]

 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.
Not a huge problem, since any instances of the old syntax (2.18.2) get 
highlighted during the compile anyway. 

I'm still running Mac System 10.14 (Mojave) but I will upgrade to OS 15 as time 
and the slow rolling Covid-19 disaster allows.

Be well everyone,
Zon D.


 On Wednesday, March 11, 2020, 01:53:27 PM EDT, Marnen Laibow-Koser 
 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,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org  

64-bit Mac build of 2.20 is now available!

[Marnen Laibow-Koser]

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,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: Linking 64-bit Mac builds from website

[Carl Sorensen]

From: Marnen Laibow-Koser 
Date: Sunday, March 8, 2020 at 4:16 PM
To: Carl Sorensen 
Cc: LilyPond , Phil Holmes 
Subject: Re: Linking 64-bit Mac builds from website



On Sun, Mar 8, 2020 at 6:06 PM Carl Sorensen 
mailto:c_soren...@byu.edu>> wrote:


On 3/8/20, 3:30 PM, "lilypond-devel on behalf of Marnen Laibow-Koser" 
mailto:byu@gnu.org> on 
behalf of mar...@marnen.org<mailto:mar...@marnen.org>> wrote:
[...]


Wouldn’t they all be triggered off the same Git event?


It seems to me that nightly (or git commit related) builds would have the 
version of the *next* unstable release.

Why do you think that?  It’s one possibility, sure, but there are others.  I 
haven’t done the research yet to know which option makes sense here.

Because right now we don’t have nightly builds, only released versions 
periodically.  Unless we simultaneously revised the rest of our process, OSX 64 
would be handled differently.  I wouldn’t think we want to drive the difference.

So a script on Marnen's site that builds an app bundle and uploads it to 
lilypond.org<http://lilypond.org> would have the release already on the website 
*before* the GUB build was released.

Meaning the GUB build of the next version that wouldn’t even exist yet?

GUB build of the next version would exist as a build from master, but it’s not 
a released version.  At least it’s my understanding of how the current system 
works.

However, this file wouldn't be linked anywhere on the website, so nobody would 
have a link to it (although, I guess they could guess what it is, since it has 
a known name structure).

If I were to upload it, I’d make sure there was a link of some sort to it.  
Otherwise what’s the point?

To have an automated system that does the CI, even when a version isn’t 
released.  To lay a foundation for future build system automation.



When an official release is made, the already-existing file is on 
lilypond.org<http://lilypond.org>.  And the next periodic build from Marnen's 
site would be for the *next* unstable version.

I don’t see how this follows from anything I’ve said...

Because master is always ahead of unstable.  When we release an unstable 
version, we bump the version number in master (to one past the current unstable 
release).  That’s the way the release process works, as I understand it.



So I'm in favor of

* Giving Marnen's CI site access to upload files at 
lilypond.org<http://lilypond.org>

(Small quibble: ideally, this will soon be the LilyPond project’s CI site, not 
‘mine’.  I really don’t want to be the sole person in charge of this.)

OK, no complaints here.  But it’s the LilyPond project’s CI site for OSX-64 
builds only, at least right now, IIUC.


* Using CI to provide regular upload to lilypond.org<http://lilypond.org> of 
the *next* stable version of lilypond.

What do you mean by “next stable version”?
I meant “unstable”, not stable.




Also, I'm in favor of automating Marnen's process as a test for future possible 
automation that doesn't use GUB.

Marnen,  thank you so much for developing the lilypond .app bundle!  I need 
that to be able to use multiple versions of lilypond with Frescobaldi on OSX.  
I'm really happy that you've done this work!

You’re most welcome!  Interesting point about multiple versions; some package 
managers support that use case and some do not.  But .app bundles always 
trivially support it.

That’s the main reason I was so excited to see your app bundle, in contrast to 
the MacPorts build.

Thanks,

Carl

Re: Linking 64-bit Mac builds from website

[David Kastrup]

Carl Sorensen  writes:

> On 3/8/20, 3:30 PM, "lilypond-devel on behalf of Marnen Laibow-Koser"
>  mar...@marnen.org> wrote:
>
> On Sun, Mar 8, 2020 at 5:10 PM Phil Holmes  wrote:
> 
> > > Why would there be a synchronization issue? I’m not sure I under stand
> > the problem you’re envisioning.
> >
> > Because I'd be building the documentation and the website and all the
> > other binaries, and you'd be building 64-bit Mac.  If I release 2.21.2 
> (for
> > instance) and it's not already on the website as a 64-bit Mac build, it
> > will be a dead link.  So we would need a system to synchronise GUB 
> builds
> > and 64-bit Mac builds.
> >
> 
> Wouldn’t they all be triggered off the same Git event?
> 
> 
> It seems to me that nightly (or git commit related) builds would have
> the version of the *next* unstable release.

Would have the version _number_.  That does not mean that the actual
version would not actually contain more commits.

> So a script on Marnen's site that builds an app bundle and uploads it
> to lilypond.org would have the release already on the website *before*
> the GUB build was released.

Would have _something_ already on the website _purporting_ to be the new
version.  Whether it actually _is_ the new version depends on timing and
luck.

-- 
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".

Re: Linking 64-bit Mac builds from website

[Marnen Laibow-Koser]

On Sun, Mar 8, 2020 at 6:06 PM Carl Sorensen  wrote:

>
>
> On 3/8/20, 3:30 PM, "lilypond-devel on behalf of Marnen Laibow-Koser"
>  mar...@marnen.org> wrote:

[...]

>
>
> Wouldn’t they all be triggered off the same Git event?
>
>
> It seems to me that nightly (or git commit related) builds would have the
> version of the *next* unstable release.


Why do you think that?  It’s one possibility, sure, but there are others.
I haven’t done the research yet to know which option makes sense here.

So a script on Marnen's site that builds an app bundle and uploads it to
> lilypond.org would have the release already on the website *before* the
> GUB build was released.


Meaning the GUB build of the next version that wouldn’t even exist yet?

However, this file wouldn't be linked anywhere on the website, so nobody
> would have a link to it (although, I guess they could guess what it is,
> since it has a known name structure).


If I were to upload it, I’d make sure there was a link of some sort to it.
Otherwise what’s the point?


>
> When an official release is made, the already-existing file is on
> lilypond.org.  And the next periodic build from Marnen's site would be
> for the *next* unstable version.


I don’t see how this follows from anything I’ve said...


>
> So I'm in favor of
>
> * Giving Marnen's CI site access to upload files at lilypond.org


(Small quibble: ideally, this will soon be the LilyPond project’s CI site,
not ‘mine’.  I really don’t want to be the sole person in charge of this.)


> * Using CI to provide regular upload to lilypond.org of the *next* stable
> version of lilypond.


What do you mean by “next stable version”?

>
>
> Also, I'm in favor of automating Marnen's process as a test for future
> possible automation that doesn't use GUB.
>
> Marnen,  thank you so much for developing the lilypond .app bundle!  I
> need that to be able to use multiple versions of lilypond with Frescobaldi
> on OSX.  I'm really happy that you've done this work!


You’re most welcome!  Interesting point about multiple versions; some
package managers support that use case and some do not.  But .app bundles
always trivially support it.


>
> Thanks,
>
> Carl


Best,

>
> --
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: Linking 64-bit Mac builds from website

[Carl Sorensen]

On 3/8/20, 3:30 PM, "lilypond-devel on behalf of Marnen Laibow-Koser" 
 wrote:

On Sun, Mar 8, 2020 at 5:10 PM Phil Holmes  wrote:

> > Why would there be a synchronization issue? I’m not sure I under stand
> the problem you’re envisioning.
>
> Because I'd be building the documentation and the website and all the
> other binaries, and you'd be building 64-bit Mac.  If I release 2.21.2 
(for
> instance) and it's not already on the website as a 64-bit Mac build, it
> will be a dead link.  So we would need a system to synchronise GUB builds
> and 64-bit Mac builds.
>

Wouldn’t they all be triggered off the same Git event?


It seems to me that nightly (or git commit related) builds would have the 
version of the *next* unstable release. So a script on Marnen's site that 
builds an app bundle and uploads it to lilypond.org would have the release 
already on the website *before* the GUB build was released.  However, this file 
wouldn't be linked anywhere on the website, so nobody would have a link to it 
(although, I guess they could guess what it is, since it has a known name 
structure).

When an official release is made, the already-existing file is on lilypond.org. 
 And the next periodic build from Marnen's site would be for the *next* 
unstable version.

So I'm in favor of

* Giving Marnen's CI site access to upload files at lilypond.org
* Using CI to provide regular upload to lilypond.org of the *next* stable 
version of lilypond.

Also, I'm in favor of automating Marnen's process as a test for future possible 
automation that doesn't use GUB.

Marnen,  thank you so much for developing the lilypond .app bundle!  I need 
that to be able to use multiple versions of lilypond with Frescobaldi on OSX.  
I'm really happy that you've done this work!

Thanks,

Carl

Re: Linking 64-bit Mac builds from website

[Marnen Laibow-Koser]

On Sun, Mar 8, 2020 at 5:10 PM Phil Holmes  wrote:

> > Why would there be a synchronization issue? I’m not sure I under stand
> the problem you’re envisioning.
>
> Because I'd be building the documentation and the website and all the
> other binaries, and you'd be building 64-bit Mac.  If I release 2.21.2 (for
> instance) and it's not already on the website as a 64-bit Mac build, it
> will be a dead link.  So we would need a system to synchronise GUB builds
> and 64-bit Mac builds.
>

Wouldn’t they all be triggered off the same Git event?


> At present, you can't upload to lilypond.org. Han Wen could change that
> if necessary.
>
> --
> Phil Holmes
>
>
>
> - Original Message -
> *From:* Marnen Laibow-Koser 
> *To:* Phil Holmes 
> *Cc:* LilyPond  ; pkx1...@posteo.net
> *Sent:* Sunday, March 08, 2020 6:23 PM
> *Subject:* Re: Linking 64-bit Mac builds from website
>
>
>
> On Sun, Mar 8, 2020 at 2:07 PM Phil Holmes  wrote:
>
>> > Would adding the links require manual intervention? If possible I’d
>> like to avoid that so that there’s minimal friction when a new build is
>> released.
>>
>> I don't see why, once they have initially been established.  The only
>> issue might be timing synchronisation.  If the website is updated with a
>> new version, it would be good to have the Mac binaries already there,
>> rather than a dead link for a while.
>>
>
> Why would there be a synchronization issue?  I’m not sure I under stand
> the problem you’re envisioning.
>
>
>> > The zipped .app bundles have been about 35–56 MB. Have a look here:
>>
>> Too big to email.  Can you ftp them to a website, or would you propose
>> getting them to me with a file transfer site?
>>
>
> I’d propose having GitLab CI (or whatever automated builder I wind up
> with) post them directly to an API or FTP/SCP them to the appropriate
> place, or alternatively to host then externally (on Bintray or GitLab, say)
> and just provide links.  But whatever we decide, it should be automatic
> just as I gather it currently is with GUB.
>
> The idea I have:
> 1. Every tag, or even every Git commit, automatically triggers a build.
> 2. The completed build is automatically pushed to some download server.
> 3. The website automatically provides a link to the completed build.
>
> Right now I already have a usable Makefile and build environment; I just
> need get some final kinks out and automate step 1 with GitLab CI or
> similar.  Once that happens, if we can automate steps 2 and 3 as well, we
> will have a fully automatic pipeline for the 64-bit Mac builds.  I don’t
> want any human (including myself) to be a single point of failure in the
> pipeline.
>
>
>> --
>> Phil Holmes
>>
>
> Best,
>
>> --
> Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from
> Gmail Mobile
>
> --
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: Linking 64-bit Mac builds from website

[Phil Holmes]

> Why would there be a synchronization issue? I’m not sure I under stand the 
> problem you’re envisioning. 

Because I'd be building the documentation and the website and all the other 
binaries, and you'd be building 64-bit Mac.  If I release 2.21.2 (for instance) 
and it's not already on the website as a 64-bit Mac build, it will be a dead 
link.  So we would need a system to synchronise GUB builds and 64-bit Mac 
builds.

At present, you can't upload to lilypond.org. Han Wen could change that if 
necessary.

--
Phil Holmes


  - Original Message - 
  From: Marnen Laibow-Koser 
  To: Phil Holmes 
  Cc: LilyPond ; pkx1...@posteo.net 
  Sent: Sunday, March 08, 2020 6:23 PM
  Subject: Re: Linking 64-bit Mac builds from website






  On Sun, Mar 8, 2020 at 2:07 PM Phil Holmes  wrote:

> Would adding the links require manual intervention? If possible I’d like 
to avoid that so that there’s minimal friction when a new build is released.

I don't see why, once they have initially been established.  The only issue 
might be timing synchronisation.  If the website is updated with a new version, 
it would be good to have the Mac binaries already there, rather than a dead 
link for a while.


  Why would there be a synchronization issue?  I’m not sure I under stand the 
problem you’re envisioning. 



> The zipped .app bundles have been about 35–56 MB. Have a look here: 

Too big to email.  Can you ftp them to a website, or would you propose 
getting them to me with a file transfer site?


  I’d propose having GitLab CI (or whatever automated builder I wind up with) 
post them directly to an API or FTP/SCP them to the appropriate place, or 
alternatively to host then externally (on Bintray or GitLab, say) and just 
provide links.  But whatever we decide, it should be automatic just as I gather 
it currently is with GUB.


  The idea I have:
  1. Every tag, or even every Git commit, automatically triggers a build. 
  2. The completed build is automatically pushed to some download server. 
  3. The website automatically provides a link to the completed build. 


  Right now I already have a usable Makefile and build environment; I just need 
get some final kinks out and automate step 1 with GitLab CI or similar.  Once 
that happens, if we can automate steps 2 and 3 as well, we will have a fully 
automatic pipeline for the 64-bit Mac builds.  I don’t want any human 
(including myself) to be a single point of failure in the pipeline. 



--
Phil Holmes


  Best,
  -- 

  Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail 
Mobile

Re: Linking 64-bit Mac builds from website

[Marnen Laibow-Koser]

On Sun, Mar 8, 2020 at 4:13 PM Jonas Hahnfeld  wrote:

> Am Sonntag, den 08.03.2020, 16:04 -0400 schrieb Marnen Laibow-Koser:
> > On Sun, Mar 8, 2020 at 3:43 PM Jonas Hahnfeld  wrote:
> > > Am Sonntag, den 08.03.2020, 15:23 -0400 schrieb Marnen Laibow-Koser:
> > > >
> > > >
> > > > On Sun, Mar 8, 2020 at 2:38 PM Jonas Hahnfeld 
> wrote:
> > > > > Am Sonntag, den 08.03.2020, 14:23 -0400 schrieb Marnen
> Laibow-Koser:
> >
> > [...]
> > > > > It might be worth holding off this level of automation for a bit.
> > > >
> > > > Why?  It’s common and (in the general case) easy to do with modern
> CI/CD infrastructure.  Besides, if we don’t do it, then the 64-bit Mac
> builds will be less generally available, and that will negate the point of
> all my work on them.
> > >
> > > I'm not saying that you shouldn't upload it (even though it kind of
> > > feels like a third party package right now).
> >
> > How does it feel like a third-party package?  I'm basically duplicating
> the structure of the official 32-bit Mac builds, except that I'm not using
> GUB.
>
> Exactly, precisely what I said.
>

That does not clarify what you meant.  I still do not understand.


>
> >
> > > Besides how often do you
> > > expect rebuilds for each release? That's hopefully one binary package
> > > per LilyPond release, right?
> >
> > At least.  Ideally I'd like to also make available a "bleeding-edge"
> .app build, either nightly or for each commit accepted into master.  But
> that's less important than making builds available for each release, of
> course.
> >
> > > >
> > > > Or are you suggesting another way to make the builds generally
> available?  If so, what?  Right now I’m manually uploading them to Bintray,
> which isn’t sustainable (although I *could* automate that through their
> API).
> > > >
> > > >
> > > > > I
> > > > > hope we can switch all platforms away from GUB,
> > > >
> > > > I do too.  It’s a good idea in theory, but *way* too complicated.
> >
> > Clarification: I meant that *GUB* is way too complicated.  I would like
> to switch to a simpler build method.
> > > No, it works: https://github.com/hahnjo/lilypond-binaries/
> >
> > What is that?  It has no description or README, and I cannot easily tell
> what it is meant to do.
>
> "There hasn't been a thread on lilypond-devel about this yet because
> I'm waiting for 2.21.0 which we'll do with GUB."
>

...which will not produce a 64-bit Mac build, so we're in the same position
we were in with 2.19 and 2.20.


>
> >
> > > And unless proven wrong, I think this will also work for macOS (given a
> > > few tweaks).
> >
> > We *already* have something working for macOS, as I've made clear on
> this list.  See https://bintray.com/marnen/lilypond-darwin-64 and
> http://gitlab.com/marnen/lilypond-mac-builder ;.  If you think my work
> can be improved by yours, or vice versa, pull requests are welcome!
>
> Yes, I think it can be improved: There should not be separate ways to
> build release binaries for each platform.


I think I agree with you, and *in theory* I believe the Mac Makefile I
wrote could be made platform-independent.  However, *in practice*, the way
native dependencies—and packaging—is managed on each platform is quite
different (Mac OS works best with .app bundles, other *nix wants naked
executables installed through a package manager, I have no idea how things
work on Windows), so how do we *get* to this point without just
reimplementing GUB, unless we somehow make the LilyPond codebase itself
less dependent on external binaries?


> I suggested that we
> collaborate back in January.
>

At the time, you didn't seem to provide anything useful to work with.  I
wasn't even aware of the lilypond-binaries repo till just now; as you said,
you never mentioned it on the list, and I don't think you ever told me
about it directly either, which means that I didn't know that there was
anything to collaborate *with* beyond some early sketches. :)

Anyway, I'd be happy to collaborate, but my proximate concern is ensuring
the continued availability of 64-bit Mac .app bundles.  As long as we can
keep doing that, I would *love* to improve the process for it.

In other words: this is kind of all bikeshedding right now.  I have
something usable today, and while we absolutely should improve the process
going forward, we shouldn't do that at the expense of the currently usable
thing today.


> Jonas
>

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: Linking 64-bit Mac builds from website

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Sonntag, den 08.03.2020, 16:04 -0400 schrieb Marnen Laibow-Koser:
> On Sun, Mar 8, 2020 at 3:43 PM Jonas Hahnfeld  wrote:
> > Am Sonntag, den 08.03.2020, 15:23 -0400 schrieb Marnen Laibow-Koser:
> > > 
> > > 
> > > On Sun, Mar 8, 2020 at 2:38 PM Jonas Hahnfeld  wrote:
> > > > Am Sonntag, den 08.03.2020, 14:23 -0400 schrieb Marnen Laibow-Koser:
> 
> [...] 
> > > > It might be worth holding off this level of automation for a bit. 
> > > 
> > > Why?  It’s common and (in the general case) easy to do with modern CI/CD 
> > > infrastructure.  Besides, if we don’t do it, then the 64-bit Mac builds 
> > > will be less generally available, and that will negate the point of all 
> > > my work on them. 
> > 
> > I'm not saying that you shouldn't upload it (even though it kind of
> > feels like a third party package right now).
> 
> How does it feel like a third-party package?  I'm basically duplicating the 
> structure of the official 32-bit Mac builds, except that I'm not using GUB.

Exactly, precisely what I said.

>  
> > Besides how often do you
> > expect rebuilds for each release? That's hopefully one binary package
> > per LilyPond release, right?
> 
> At least.  Ideally I'd like to also make available a "bleeding-edge" .app 
> build, either nightly or for each commit accepted into master.  But that's 
> less important than making builds available for each release, of course.
>  
> > > 
> > > Or are you suggesting another way to make the builds generally available? 
> > >  If so, what?  Right now I’m manually uploading them to Bintray, which 
> > > isn’t sustainable (although I *could* automate that through their API). 
> > > 
> > > 
> > > > I
> > > > hope we can switch all platforms away from GUB, 
> > > 
> > > I do too.  It’s a good idea in theory, but *way* too complicated. 
> 
> Clarification: I meant that *GUB* is way too complicated.  I would like to 
> switch to a simpler build method. 
> > No, it works: https://github.com/hahnjo/lilypond-binaries/
> 
> What is that?  It has no description or README, and I cannot easily tell what 
> it is meant to do.

"There hasn't been a thread on lilypond-devel about this yet because
I'm waiting for 2.21.0 which we'll do with GUB."

> 
> > And unless proven wrong, I think this will also work for macOS (given a
> > few tweaks).
> 
> We *already* have something working for macOS, as I've made clear on this 
> list.  See https://bintray.com/marnen/lilypond-darwin-64 and 
> http://gitlab.com/marnen/lilypond-mac-builder ;.  If you think my work can be 
> improved by yours, or vice versa, pull requests are welcome!

Yes, I think it can be improved: There should not be separate ways to
build release binaries for each platform. I suggested that we
collaborate back in January.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: Linking 64-bit Mac builds from website

[Marnen Laibow-Koser]

On Sun, Mar 8, 2020 at 3:43 PM Jonas Hahnfeld  wrote:

> Am Sonntag, den 08.03.2020, 15:23 -0400 schrieb Marnen Laibow-Koser:
> >
> >
> > On Sun, Mar 8, 2020 at 2:38 PM Jonas Hahnfeld  wrote:
> > > Am Sonntag, den 08.03.2020, 14:23 -0400 schrieb Marnen Laibow-Koser:
>
[...]

> > > It might be worth holding off this level of automation for a bit.
> >
> > Why?  It’s common and (in the general case) easy to do with modern CI/CD
> infrastructure.  Besides, if we don’t do it, then the 64-bit Mac builds
> will be less generally available, and that will negate the point of all my
> work on them.
>
> I'm not saying that you shouldn't upload it (even though it kind of
> feels like a third party package right now).


How does it feel like a third-party package?  I'm basically duplicating the
structure of the official 32-bit Mac builds, except that I'm not using GUB.


> Besides how often do you
> expect rebuilds for each release? That's hopefully one binary package
> per LilyPond release, right?
>

At least.  Ideally I'd like to also make available a "bleeding-edge" .app
build, either nightly or for each commit accepted into master.  But that's
less important than making builds available for each release, of course.


>
> >
> > Or are you suggesting another way to make the builds generally
> available?  If so, what?  Right now I’m manually uploading them to Bintray,
> which isn’t sustainable (although I *could* automate that through their
> API).
> >
> >
> > > I
> > > hope we can switch all platforms away from GUB,
> >
> > I do too.  It’s a good idea in theory, but *way* too complicated.
>

Clarification: I meant that *GUB* is way too complicated.  I would like to
switch to a simpler build method.

>
> No, it works: https://github.com/hahnjo/lilypond-binaries/


What is that?  It has no description or README, and I cannot easily tell
what it is meant to do.


> And unless proven wrong, I think this will also work for macOS (given a
> few tweaks).
>

We *already* have something working for macOS, as I've made clear on this
list.  See https://bintray.com/marnen/lilypond-darwin-64 and
http://gitlab.com/marnen/lilypond-mac-builder .  If you think my work can
be improved by yours, or vice versa, pull requests are welcome!

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: Linking 64-bit Mac builds from website

[Marnen Laibow-Koser]

On Sun, Mar 8, 2020 at 3:45 PM Jahrme Risner  wrote:

> On Sun, Mar 8, 2020 at 12:23, Marnen Laibow-Koser 
> wrote:
>
> I
> > hope we can switch all platforms away from GUB,
>
>
> I do too. It’s a good idea in theory, but *way* too complicated.
>
> so this likely needs a
> > general solution then.
>
>
> Whatever we build here can probably be the first step toward one. Besides,
> who knows how long it will take to get rid of GUB? I don’t want to force
> Catalina users to wait for that to happen in order to easily use LilyPond.
>
> Claiming that Catalina users do not have an easy way to use LilyPond is
> your opinion. While you have made it clear previously that you personally
> do not find MacPorts to be sufficiently “easy”, I would like to point out
> that its LilyPond port has already been updated to 2.20.0 and is in use.
>

OK, then let me rephrase: I don't want to force Catalina users to wait for
that to happen in order to use LilyPond *without a package manager*, and I
don't want to force Catalina users to install a package manager that they
don't otherwise need solely in order to use LilyPond.


> One benefit of using a package manager is that casual users do not need to
> track when a new version is released, the new version will just appear in
> their list of packages eligible for an update. Unless you are considering
> adding a “check for updates” capability to the .app bundles, that is
> something that cannot be done through static releases.
>

That is absolutely irrelevant to the present discussion.  If you don't want
to use the .app bundles, don't.

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: Linking 64-bit Mac builds from website

[Jahrme Risner]

On Sun, Mar 8, 2020 at 12:23, Marnen Laibow-Koser  wrote:

> I
>> hope we can switch all platforms away from GUB,
>
> I do too. It’s a good idea in theory, but *way* too complicated.
>
> so this likely needs a
>> general solution then.
>
> Whatever we build here can probably be the first step toward one. Besides,
> who knows how long it will take to get rid of GUB? I don’t want to force
> Catalina users to wait for that to happen in order to easily use LilyPond.

Claiming that Catalina users do not have an easy way to use LilyPond is your 
opinion. While you have made it clear previously that you personally do not 
find MacPorts to be sufficiently “easy”, I would like to point out that its 
LilyPond port has already been updated to 2.20.0 and is in use.

One benefit of using a package manager is that casual users do not need to 
track when a new version is released, the new version will just appear in their 
list of packages eligible for an update. Unless you are considering adding a 
“check for updates” capability to the .app bundles, that is something that 
cannot be done through static releases.

Best wishes,
Jahrme

>

Re: Linking 64-bit Mac builds from website

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Sonntag, den 08.03.2020, 15:23 -0400 schrieb Marnen Laibow-Koser:
> 
> 
> On Sun, Mar 8, 2020 at 2:38 PM Jonas Hahnfeld  wrote:
> > Am Sonntag, den 08.03.2020, 14:23 -0400 schrieb Marnen Laibow-Koser:
> 
> [...]
> > > 
> > > The idea I have:
> > > 1. Every tag, or even every Git commit, automatically triggers a build.
> > > 2. The completed build is automatically pushed to some download server.
> > > 3. The website automatically provides a link to the completed build.
> > > 
> > > Right now I already have a usable Makefile and build environment; I just
> > > need get some final kinks out and automate step 1 with GitLab CI or
> > > similar.  Once that happens, if we can automate steps 2 and 3 as well, we
> > > will have a fully automatic pipeline for the 64-bit Mac builds.  I don’t
> > > want any human (including myself) to be a single point of failure in the
> > > pipeline.
> > 
> > It might be worth holding off this level of automation for a bit. 
> 
> Why?  It’s common and (in the general case) easy to do with modern CI/CD 
> infrastructure.  Besides, if we don’t do it, then the 64-bit Mac builds will 
> be less generally available, and that will negate the point of all my work on 
> them. 

I'm not saying that you shouldn't upload it (even though it kind of
feels like a third party package right now). Besides how often do you
expect rebuilds for each release? That's hopefully one binary package
per LilyPond release, right?

> 
> Or are you suggesting another way to make the builds generally available?  If 
> so, what?  Right now I’m manually uploading them to Bintray, which isn’t 
> sustainable (although I *could* automate that through their API). 
> 
> 
> > I
> > hope we can switch all platforms away from GUB, 
> 
> I do too.  It’s a good idea in theory, but *way* too complicated. 

No, it works: https://github.com/hahnjo/lilypond-binaries/
And unless proven wrong, I think this will also work for macOS (given a
few tweaks).

There hasn't been a thread on lilypond-devel about this yet because I'm
waiting for 2.21.0 which we'll do with GUB.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: Linking 64-bit Mac builds from website

[Marnen Laibow-Koser]

On Sun, Mar 8, 2020 at 2:38 PM Jonas Hahnfeld  wrote:

> Am Sonntag, den 08.03.2020, 14:23 -0400 schrieb Marnen Laibow-Koser:

[...]

>
> >
> > The idea I have:
> > 1. Every tag, or even every Git commit, automatically triggers a build.
> > 2. The completed build is automatically pushed to some download server.
> > 3. The website automatically provides a link to the completed build.
> >
> > Right now I already have a usable Makefile and build environment; I just
> > need get some final kinks out and automate step 1 with GitLab CI or
> > similar.  Once that happens, if we can automate steps 2 and 3 as well, we
> > will have a fully automatic pipeline for the 64-bit Mac builds.  I don’t
> > want any human (including myself) to be a single point of failure in the
> > pipeline.
>
> It might be worth holding off this level of automation for a bit.


Why?  It’s common and (in the general case) easy to do with modern CI/CD
infrastructure.  Besides, if we don’t do it, then the 64-bit Mac builds
will be less generally available, and that will negate the point of all my
work on them.

Or are you suggesting another way to make the builds generally available?
If so, what?  Right now I’m manually uploading them to Bintray, which isn’t
sustainable (although I *could* automate that through their API).


I
> hope we can switch all platforms away from GUB,


I do too.  It’s a good idea in theory, but *way* too complicated.

so this likely needs a
> general solution then.


Whatever we build here can probably be the first step toward one.  Besides,
who knows how long it will take to get rid of GUB?  I don’t want to force
Catalina users to wait for that to happen in order to easily use LilyPond.


>
> Jonas


 Best,
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: Linking 64-bit Mac builds from website

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Sonntag, den 08.03.2020, 14:23 -0400 schrieb Marnen Laibow-Koser:
> On Sun, Mar 8, 2020 at 2:07 PM Phil Holmes <
> m...@philholmes.net
> > wrote:
> 
> > > Would adding the links require manual intervention? If possible I’d
> > 
> > like to avoid that so that there’s minimal friction when a new build is
> > released.
> > 
> > I don't see why, once they have initially been established.  The only
> > issue might be timing synchronisation.  If the website is updated with a
> > new version, it would be good to have the Mac binaries already there,
> > rather than a dead link for a while.
> > 
> 
> Why would there be a synchronization issue?  I’m not sure I under stand the
> problem you’re envisioning.
> 
> 
> > > The zipped .app bundles have been about 35–56 MB. Have a look here:
> > 
> > Too big to email.  Can you ftp them to a website, or would you propose
> > getting them to me with a file transfer site?
> > 
> 
> I’d propose having GitLab CI (or whatever automated builder I wind up with)
> post them directly to an API or FTP/SCP them to the appropriate place, or
> alternatively to host then externally (on Bintray or GitLab, say) and just
> provide links.  But whatever we decide, it should be automatic just as I
> gather it currently is with GUB.
> 
> The idea I have:
> 1. Every tag, or even every Git commit, automatically triggers a build.
> 2. The completed build is automatically pushed to some download server.
> 3. The website automatically provides a link to the completed build.
> 
> Right now I already have a usable Makefile and build environment; I just
> need get some final kinks out and automate step 1 with GitLab CI or
> similar.  Once that happens, if we can automate steps 2 and 3 as well, we
> will have a fully automatic pipeline for the 64-bit Mac builds.  I don’t
> want any human (including myself) to be a single point of failure in the
> pipeline.

It might be worth holding off this level of automation for a bit. I
hope we can switch all platforms away from GUB, so this likely needs a
general solution then.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: Linking 64-bit Mac builds from website

[Marnen Laibow-Koser]

On Sun, Mar 8, 2020 at 2:07 PM Phil Holmes  wrote:

> > Would adding the links require manual intervention? If possible I’d
> like to avoid that so that there’s minimal friction when a new build is
> released.
>
> I don't see why, once they have initially been established.  The only
> issue might be timing synchronisation.  If the website is updated with a
> new version, it would be good to have the Mac binaries already there,
> rather than a dead link for a while.
>

Why would there be a synchronization issue?  I’m not sure I under stand the
problem you’re envisioning.


> > The zipped .app bundles have been about 35–56 MB. Have a look here:
>
> Too big to email.  Can you ftp them to a website, or would you propose
> getting them to me with a file transfer site?
>

I’d propose having GitLab CI (or whatever automated builder I wind up with)
post them directly to an API or FTP/SCP them to the appropriate place, or
alternatively to host then externally (on Bintray or GitLab, say) and just
provide links.  But whatever we decide, it should be automatic just as I
gather it currently is with GUB.

The idea I have:
1. Every tag, or even every Git commit, automatically triggers a build.
2. The completed build is automatically pushed to some download server.
3. The website automatically provides a link to the completed build.

Right now I already have a usable Makefile and build environment; I just
need get some final kinks out and automate step 1 with GitLab CI or
similar.  Once that happens, if we can automate steps 2 and 3 as well, we
will have a fully automatic pipeline for the 64-bit Mac builds.  I don’t
want any human (including myself) to be a single point of failure in the
pipeline.


> --
> Phil Holmes
>

Best,

> --
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: Linking 64-bit Mac builds from website

[Phil Holmes]

> Would adding the links require manual intervention? If possible I’d like to 
> avoid that so that there’s minimal friction when a new build is released.

I don't see why, once they have initially been established.  The only issue 
might be timing synchronisation.  If the website is updated with a new version, 
it would be good to have the Mac binaries already there, rather than a dead 
link for a while.

> The zipped .app bundles have been about 35–56 MB. Have a look here: 

Too big to email.  Can you ftp them to a website, or would you propose getting 
them to me with a file transfer site?

--
Phil Holmes


  - Original Message - 
  From: Marnen Laibow-Koser 
  To: Phil Holmes 
  Cc: LilyPond ; pkx1...@posteo.net 
  Sent: Sunday, March 08, 2020 4:28 PM
  Subject: Re: Linking 64-bit Mac builds from website






  On Sun, Mar 8, 2020 at 12:14 PM Phil Holmes  wrote:

I ought to be able to scp them to the downloads directory and then we could 
put an appropriate link into the docs that build the website.  


  Would adding the links require manual intervention?  If possible I’d like to 
avoid that so that there’s minimal friction when a new build is released. 


How big is the file?


  The zipped .app bundles have been about 35–56 MB. Have a look here: 
  https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.19.83#files





--
Phil Holmes


  Best,
  -- 

  Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail 
Mobile

Re: Linking 64-bit Mac builds from website

[Marnen Laibow-Koser]

On Sun, Mar 8, 2020 at 12:14 PM Phil Holmes  wrote:

> I ought to be able to scp them to the downloads directory and then we
> could put an appropriate link into the docs that build the website.
>

Would adding the links require manual intervention?  If possible I’d like
to avoid that so that there’s minimal friction when a new build is
released.

How big is the file?
>

The zipped .app bundles have been about 35–56 MB. Have a look here:
https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.19.83#files



> --
> Phil Holmes
>

Best,

> --
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: Linking 64-bit Mac builds from website

[Phil Holmes]

I ought to be able to scp them to the downloads directory and then we could put 
an appropriate link into the docs that build the website.  How big is the file?

--
Phil Holmes


  - Original Message - 
  From: Marnen Laibow-Koser 
  To: Phil Holmes 
  Cc: LilyPond ; pkx1...@posteo.net 
  Sent: Sunday, March 08, 2020 3:05 PM
  Subject: Re: Linking 64-bit Mac builds from website






  On Sun, Mar 8, 2020 at 6:49 AM Phil Holmes  wrote:
  [...]
I do that.  The downloads section is automagically managed by GUB and I do 
the builds and upload the updates.


  So when the time comes (which isn’t quite yet, but should be soon if all goes 
well), what’s a good way of getting the non-GUB 64-bit Mac builds onto the 
website?  (There will be an automated process building them, probably GitLab 
CI, if that’s helpful to know.)


  Best,
  -- 

  Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail 
Mobile

Re: Linking 64-bit Mac builds from website

[Marnen Laibow-Koser]

On Sun, Mar 8, 2020 at 6:49 AM Phil Holmes  wrote:
[...]

> I do that.  The downloads section is automagically managed by GUB and I do
> the builds and upload the updates.


So when the time comes (which isn’t quite yet, but should be soon if all
goes well), what’s a good way of getting the non-GUB 64-bit Mac builds onto
the website?  (There will be an automated process building them, probably
GitLab CI, if that’s helpful to know.)

Best,
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: Linking 64-bit Mac builds from website

[Phil Holmes]

- Original Message - 
From: 
To: "Marnen Laibow-Koser" ; "LilyPond" 


Sent: Sunday, March 08, 2020 10:43 AM
Subject: Re: Linking 64-bit Mac builds from website



Marnen,

On 02/03/2020 20:23, Marnen Laibow-Koser wrote:

Folks--

It seems that I've got a working process for 64-bit Mac builds of 
LilyPond,

and I will soon automate the process to build Mac .app bundles for every
tagged release.  Which brings me to the next question: what is the 
process
to update the LilyPond website so that download links for these builds 
are

directly available?


The website is (re)generated from the LP source code periodically by a few 
developers who push the changes up.


Editing the website is similar to editing our main documentation - i.e. 
via patches which get tested and merged into the main source code.


However I am not sure who manages the download site where the stable and 
unstable binaries are held.


http://lilypond.org/download/binaries/

Hopefully someone will be able to expand on this from the developers.

Also see: 
http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#website-work


Regards

James



I do that.  The downloads section is automagically managed by GUB and I do 
the builds and upload the updates.


--
Phil Holmes 

Re: Linking 64-bit Mac builds from website

[pkx166h]

Marnen,

On 02/03/2020 20:23, Marnen Laibow-Koser wrote:

Folks--

It seems that I've got a working process for 64-bit Mac builds of LilyPond,
and I will soon automate the process to build Mac .app bundles for every
tagged release.  Which brings me to the next question: what is the process
to update the LilyPond website so that download links for these builds are
directly available?


The website is (re)generated from the LP source code periodically by a 
few developers who push the changes up.


Editing the website is similar to editing our main documentation - i.e. 
via patches which get tested and merged into the main source code.


However I am not sure who manages the download site where the stable and 
unstable binaries are held.


http://lilypond.org/download/binaries/

Hopefully someone will be able to expand on this from the developers.

Also see: 
http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#website-work


Regards

James

Linking 64-bit Mac builds from website

[Marnen Laibow-Koser]

Folks--

It seems that I've got a working process for 64-bit Mac builds of LilyPond,
and I will soon automate the process to build Mac .app bundles for every
tagged release.  Which brings me to the next question: what is the process
to update the LilyPond website so that download links for these builds are
directly available?

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: Mac 64-bit builds: Guile segfault?

[Marnen Laibow-Koser]

On Sat, Feb 8, 2020 at 8:39 AM Thomas Morley 
wrote:
[...]

>
> There are some reports of segfaulting builds of guile "Segfault while
> building on 64-bit Cygwin"
> https://lists.gnu.org/archive/html/guile-devel/2020-01/msg00112.html
>
> I doubt it's relevant, though. Those reports are for guile-2.9.7 and
> newer...


Plus these segfaults happen during execution, not compilation.


>
> Cheers,
>   Harm
>
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: Mac 64-bit builds: Guile segfault?

[Thomas Morley]

Am Sa., 8. Feb. 2020 um 13:51 Uhr schrieb Marnen Laibow-Koser
:
>
> Folks—
>
> From the feedback I’ve been getting, it looks like my 64-bit Mac builds are
> working well for most people.  However, one user—one only one of two Macs
> he has access to—is consistently getting a segfault with these builds right
> around the time that it loads Guile and/or lily.scm (he says the 32-bit
> builds work).  There are detailed logs and troubleshooting info at
> https://gitlab.com/marnen/lilypond-mac-builder/issues/16 , but I’ve run out
> of ideas to try.  Can someone help?  Thanks so much!
>
> Best,
> --
> Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
> Mobile

There are some reports of segfaulting builds of guile "Segfault while
building on 64-bit Cygwin"
https://lists.gnu.org/archive/html/guile-devel/2020-01/msg00112.html

I doubt it's relevant, though. Those reports are for guile-2.9.7 and newer...

Cheers,
  Harm

Re: Mac 64-bit builds: Guile segfault?

[Hans Åberg]

> On 8 Feb 2020, at 13:51, Marnen Laibow-Koser  wrote:
> 
> From the feedback I’ve been getting, it looks like my 64-bit Mac builds are
> working well for most people.  However, one user—one only one of two Macs
> he has access to—is consistently getting a segfault with these builds right
> around the time that it loads Guile and/or lily.scm (he says the 32-bit
> builds work).  There are detailed logs and troubleshooting info at
> https://gitlab.com/marnen/lilypond-mac-builder/issues/16 , but I’ve run out
> of ideas to try.  Can someone help?  Thanks so much!

Not knowing if it is related, but on MacOS, the Boehm GC must be initialized 
before the first allocation, and the latter may in C++ happen before ‘main' is 
called.

Mac 64-bit builds: Guile segfault?

[Marnen Laibow-Koser]

Folks—

>From the feedback I’ve been getting, it looks like my 64-bit Mac builds are
working well for most people.  However, one user—one only one of two Macs
he has access to—is consistently getting a segfault with these builds right
around the time that it loads Guile and/or lily.scm (he says the 32-bit
builds work).  There are detailed logs and troubleshooting info at
https://gitlab.com/marnen/lilypond-mac-builder/issues/16 , but I’ve run out
of ideas to try.  Can someone help?  Thanks so much!

Best,
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: 64-bit Mac build: now for 2.18 as well!

[Marnen Laibow-Koser]

On Fri, Feb 7, 2020 at 12:00 PM Carl Sorensen  wrote:

>
>
> On 2/7/20, 9:36 AM, "lilypond-devel on behalf of Marnen Laibow-Koser"
>  mar...@marnen.org> wrote:
>
> Folks--
>
> Just to let you know, I've packaged up 2.18 in a 64-bit Mac .app as
> well;
> you can get it at
>
> https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.18.2.build20200207162459-darwin-64.tar.gz
> .  2.19 builds continue to be available at
> https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.19.83 , and
> I'd be
> happy to have your feedback either here or at
> https://gitlab.com/marnen/lilypond-mac-builder/issues .
>
> Darn, I wish you hadn't done 2.18 __ .  Not having it available as a
> 64-bit MacOS app meant that we got people using the current version, rather
> than the relatively obsolete stable version.  But I know there are those
> who want the stable version.
>

I was always intending to have both available. :)


>
> So do you have the process automated now?  Is it available anywhere for
> one to review it?
>

Yes...did you look in the GitLab repo I posted a link to?

Once I get everything working reliably, I will set up some sort of CI/CD
pipeline (probably GitLab's, but really I'll use whatever works best) to
produce automatic builds for each release as GUB currently does for other
architectures.


> Thanks, again for doing this.  This is a HUGE benefit to LilyPond.
>

You're most welcome!  I really don't feel that I'm the right person to be
doing this in terms of my knowledge of Mac desktop application development,
but clearly I've gotten further than anyone else has on this...


> Carl
>
>
>
Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

64-bit Mac build: now for 2.18 as well!

[Marnen Laibow-Koser]

Folks--

Just to let you know, I've packaged up 2.18 in a 64-bit Mac .app as well;
you can get it at
https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.18.2.build20200207162459-darwin-64.tar.gz
.  2.19 builds continue to be available at
https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.19.83 , and I'd be
happy to have your feedback either here or at
https://gitlab.com/marnen/lilypond-mac-builder/issues .

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Sat, Jan 11, 2020 at 11:22 PM Carl Sorensen  wrote:

>
>
> On 1/11/20, 8:48 PM, "lilypond-devel on behalf of Kieren MacMillan"
>  kieren_macmil...@sympatico.ca> wrote:
>
> Hi Marnen,
>
> > New version is now available at
> >
> https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200111.1-darwin-64.tar.gz
> > (sha-256
> 6f1300a64281273da22c53926b6f5cbfa41fe612df173b0aaa4da905ee6b2af7;
> > I switched to Bintray because Google Drive isn't that great for
> hosting
> > large downloads).  I fixed the packaging error, and hopefully
> everything should be OK now.
>
> For me, the version statement is incorrect in both the default
> document and the "about" dialog.
> Am I the only one seeing that?
>
> Default document says "2.12.0"
>
> About says "2.15.22-1"
>
> But I'm not that concerned about the LilyPond app -- I really care about
> the app bundle, and it works the way I want it to with Frescobaldi.
>

Fixed in
https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200201185223-darwin-64.tar.gz
.


>
> Thanks,
>
> Carl
>
>
>
Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Sun, Jan 12, 2020 at 2:08 AM Marnen Laibow-Koser 
wrote:

>
>
> On Sat, Jan 11, 2020 at 10:47 PM Kieren MacMillan <
> kieren_macmil...@sympatico.ca> wrote:
>
>> Hi Marnen,
>>
>> > New version is now available at
>> >
>> https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200111.1-darwin-64.tar.gz
>> > (sha-256
>> 6f1300a64281273da22c53926b6f5cbfa41fe612df173b0aaa4da905ee6b2af7;
>> > I switched to Bintray because Google Drive isn't that great for hosting
>> > large downloads).  I fixed the packaging error, and hopefully
>> everything should be OK now.
>>
>> For me, the version statement is incorrect in both the default document
>> and the "about" dialog.
>> Am I the only one seeing that?
>
>
> Thanks, I meant to look at that and ran out of time.  I’ll see about next
> build.
>

I've made a GitLab project for my build scripts at
https://gitlab.com/marnen/lilypond-mac-builder, so please feel free to
report further packaging issues there or e-mail them to
incoming+marnen-lilypond-mac-builder-16293898-iss...@incoming.gitlab.com .
And of course if you want to contribute, pull requests are more than
welcome!

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: macOS 64-bit

[Karlin High]

On Sat, Jan 11, 2020 at 1:32 PM Marnen Laibow-Koser 
wrote:

> New version is now available at
>
> https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200111.1-darwin-64.tar.gz
> 


I can report a success on a MacBook Air (mid 2012) running macOS Mojave
10.14.6. Way to go, Marnen!

I noticed the same "unable to revert mtime" message reported earlier, but
it seems that was only on first run.
-- 
Karlin High
Missouri, USA

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Sat, Jan 11, 2020 at 10:47 PM Kieren MacMillan <
kieren_macmil...@sympatico.ca> wrote:

> Hi Marnen,
>
> > New version is now available at
> >
> https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200111.1-darwin-64.tar.gz
> > (sha-256
> 6f1300a64281273da22c53926b6f5cbfa41fe612df173b0aaa4da905ee6b2af7;
> > I switched to Bintray because Google Drive isn't that great for hosting
> > large downloads).  I fixed the packaging error, and hopefully everything
> should be OK now.
>
> For me, the version statement is incorrect in both the default document
> and the "about" dialog.
> Am I the only one seeing that?


Thanks, I meant to look at that and ran out of time.  I’ll see about next
build.

Best,
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: macOS 64-bit

[Carl Sorensen]

On 1/11/20, 8:48 PM, "lilypond-devel on behalf of Kieren MacMillan" 
 wrote:

Hi Marnen,

> New version is now available at
> 
https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200111.1-darwin-64.tar.gz
> (sha-256 6f1300a64281273da22c53926b6f5cbfa41fe612df173b0aaa4da905ee6b2af7;
> I switched to Bintray because Google Drive isn't that great for hosting
> large downloads).  I fixed the packaging error, and hopefully everything 
should be OK now.

For me, the version statement is incorrect in both the default document and 
the "about" dialog.
Am I the only one seeing that?

Default document says "2.12.0"

About says "2.15.22-1"

But I'm not that concerned about the LilyPond app -- I really care about the 
app bundle, and it works the way I want it to with Frescobaldi.

Thanks,

Carl

Re: macOS 64-bit

[Kieren MacMillan]

Hi Marnen,

> New version is now available at
> https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200111.1-darwin-64.tar.gz
> (sha-256 6f1300a64281273da22c53926b6f5cbfa41fe612df173b0aaa4da905ee6b2af7;
> I switched to Bintray because Google Drive isn't that great for hosting
> large downloads).  I fixed the packaging error, and hopefully everything 
> should be OK now.

For me, the version statement is incorrect in both the default document and the 
"about" dialog.
Am I the only one seeing that?

Thanks,
Kieren.


Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: i...@kierenmacmillan.info

Re: macOS 64-bit

[Carl Sorensen]

Works for me on Sierra (10.12).

Thanks for your work on this, Marnen!

Carl


On 1/11/20, 12:32 PM, "lilypond-devel on behalf of Marnen Laibow-Koser" 
 wrote:

On Sat, Jan 11, 2020 at 8:58 AM Marnen Laibow-Koser 
wrote:

>
>
> On Sat, Jan 11, 2020 at 8:45 AM Dan Eble  wrote:
>
>> On Jan 11, 2020, at 08:40, Marnen Laibow-Koser  wrote:
>> > Dammit, I did already fix this error!  I wonder if I left the modified
>> gs.reloc file out of the bundle by mistake, or if something else is going
>> on.
>> >
>> > Would you post the contents of
>> LilyPond.app/Contents/Resources/etc/relocate/gs.reloc ?
>>
>> $ cat /Applications/LilyPond.app/Contents/Resources/etc/relocate/gs.reloc
>>
>> prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/ghostscript/9.50/fonts
>> prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/gs/fonts
>> prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource
>> prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource/Init
>
>
> OK, this was a packaging error: I forgot to update this file in the
> bundle.  I’ll have a fix later today if all goes welll.  Sorry to waste
> your time!
>

New version is now available at

https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200111.1-darwin-64.tar.gz
(sha-256 6f1300a64281273da22c53926b6f5cbfa41fe612df173b0aaa4da905ee6b2af7;
I switched to Bintray because Google Drive isn't that great for hosting
large downloads).  I fixed the packaging error, and hopefully everything
should be OK now.

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: macOS 64-bit

[Erlend Aasland]

Hi Marnen. Seems to work fine here (after necessary adjustments in System 
Preferences => Security & Privacy).
MacBook Pro running macOS Catalina version 10.15.2.


Erlend E. Aasland

On 11 Jan 2020, at 20:31, Marnen Laibow-Koser 
mailto:mar...@marnen.org>> wrote:

On Sat, Jan 11, 2020 at 8:58 AM Marnen Laibow-Koser 
mailto:mar...@marnen.org>>
wrote:



On Sat, Jan 11, 2020 at 8:45 AM Dan Eble 
mailto:d...@faithful.be>> wrote:

On Jan 11, 2020, at 08:40, Marnen Laibow-Koser 
mailto:mar...@marnen.org>> wrote:
Dammit, I did already fix this error!  I wonder if I left the modified
gs.reloc file out of the bundle by mistake, or if something else is going
on.

Would you post the contents of
LilyPond.app/Contents/Resources/etc/relocate/gs.reloc ?

$ cat /Applications/LilyPond.app/Contents/Resources/etc/relocate/gs.reloc

prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/ghostscript/9.50/fonts
prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/gs/fonts
prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource
prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource/Init


OK, this was a packaging error: I forgot to update this file in the
bundle.  I’ll have a fix later today if all goes welll.  Sorry to waste
your time!


New version is now available at
https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200111.1-darwin-64.tar.gz
(sha-256 6f1300a64281273da22c53926b6f5cbfa41fe612df173b0aaa4da905ee6b2af7;
I switched to Bintray because Google Drive isn't that great for hosting
large downloads).  I fixed the packaging error, and hopefully everything
should be OK now.

Best,
--
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Sat, Jan 11, 2020 at 8:58 AM Marnen Laibow-Koser 
wrote:

>
>
> On Sat, Jan 11, 2020 at 8:45 AM Dan Eble  wrote:
>
>> On Jan 11, 2020, at 08:40, Marnen Laibow-Koser  wrote:
>> > Dammit, I did already fix this error!  I wonder if I left the modified
>> gs.reloc file out of the bundle by mistake, or if something else is going
>> on.
>> >
>> > Would you post the contents of
>> LilyPond.app/Contents/Resources/etc/relocate/gs.reloc ?
>>
>> $ cat /Applications/LilyPond.app/Contents/Resources/etc/relocate/gs.reloc
>>
>> prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/ghostscript/9.50/fonts
>> prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/gs/fonts
>> prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource
>> prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource/Init
>
>
> OK, this was a packaging error: I forgot to update this file in the
> bundle.  I’ll have a fix later today if all goes welll.  Sorry to waste
> your time!
>

New version is now available at
https://bintray.com/marnen/lilypond-darwin-64/download_file?file_path=lilypond-2.19.83.build20200111.1-darwin-64.tar.gz
(sha-256 6f1300a64281273da22c53926b6f5cbfa41fe612df173b0aaa4da905ee6b2af7;
I switched to Bintray because Google Drive isn't that great for hosting
large downloads).  I fixed the packaging error, and hopefully everything
should be OK now.

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Sat, Jan 11, 2020 at 8:45 AM Dan Eble  wrote:

> On Jan 11, 2020, at 08:40, Marnen Laibow-Koser  wrote:
> > Dammit, I did already fix this error!  I wonder if I left the modified
> gs.reloc file out of the bundle by mistake, or if something else is going
> on.
> >
> > Would you post the contents of
> LilyPond.app/Contents/Resources/etc/relocate/gs.reloc ?
>
> $ cat /Applications/LilyPond.app/Contents/Resources/etc/relocate/gs.reloc
>
> prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/ghostscript/9.50/fonts
> prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/gs/fonts
> prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource
> prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource/Init


OK, this was a packaging error: I forgot to update this file in the
bundle.  I’ll have a fix later today if all goes welll.  Sorry to waste
your time!


> —
> Dan
>
> --
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: macOS 64-bit

[Dan Eble]

On Jan 11, 2020, at 08:40, Marnen Laibow-Koser  wrote:
> Dammit, I did already fix this error!  I wonder if I left the modified 
> gs.reloc file out of the bundle by mistake, or if something else is going on. 
>  
> 
> Would you post the contents of 
> LilyPond.app/Contents/Resources/etc/relocate/gs.reloc ?

$ cat /Applications/LilyPond.app/Contents/Resources/etc/relocate/gs.reloc 

prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/ghostscript/9.50/fonts
prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/gs/fonts
prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource
prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.50/Resource/Init
— 
Dan

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Sat, Jan 11, 2020 at 8:29 AM Jonas Hahnfeld  wrote:
[...]

>
> GUB has another gs.reloc which sets a few variables looking related...


I know, and I already tweaked that file, which is why I’m surprised that
these issues are still occurring.


>
> Jonas
>
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Sat, Jan 11, 2020 at 8:18 AM Dan Eble  wrote:

> On Jan 11, 2020, at 07:48, Marnen Laibow-Koser  wrote:
> >
> > Could you try it without renaming and see if you get the same results?
> (Renaming shouldn’t actually matter, but I want to make sure I didn’t do
> something stupid.)
>
> same result


OK, thanks for checking.


>
>
> > There was the usual security problem with running unsigned apps,
> > which was solved in the usual way in the Security & Privacy preferences
> pane.
> >
> > What “usual way” is that?  I usually just right-click on the app and
> open it and ask it to override, although I didn’t need to do that with this
> app.  Perhaps renaming the bundle did something here?
>
> With command-line programs, there's no right-clicking.  When you try to
> run the program, the OS kills it (signal 9).  If you're lucky, it pops up a
> dialog box explaining that it has done so.  Open the Security & Privacy
> preferences pane, where there is a message that such-and-such was prevented
> from running, and click the button to allow it in the future.


I haven’t had to do that for this app bundle.  I wonder if this is a
difference between Mojave and Catalina, or between your security settings
and mine.  In any case, this is tangential to the actual problem you’re
having.


>
> > Would you try running LilyPond from the command line in debug mode (
> LilyPond.app/Contents/Resources/bin/lilypond --loglevel=debug myfile.ly)
> and let me know what Ghostscript errors you see?


[error log snipped]

Dammit, I did already fix this error!  I wonder if I left the modified
gs.reloc file out of the bundle by mistake, or if something else is going
on.

Would you post the contents of
LilyPond.app/Contents/Resources/etc/relocate/gs.reloc ?
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: macOS 64-bit

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Samstag, den 11.01.2020, 08:18 -0500 schrieb Dan Eble:
> On Jan 11, 2020, at 07:48, Marnen Laibow-Koser <
> mar...@marnen.org
> > wrote:
> > Could you try it without renaming and see if you get the same results?  
> > (Renaming shouldn’t actually matter, but I want to make sure I didn’t do 
> > something stupid.)
> 
> same result
> 
> 
> > There was the usual security problem with running unsigned apps,
> > which was solved in the usual way in the Security & Privacy preferences 
> > pane.
> > 
> > What “usual way” is that?  I usually just right-click on the app and open 
> > it and ask it to override, although I didn’t need to do that with this app. 
> >  Perhaps renaming the bundle did something here?
> 
> With command-line programs, there's no right-clicking.  When you try to run 
> the program, the OS kills it (signal 9).  If you're lucky, it pops up a 
> dialog box explaining that it has done so.  Open the Security & Privacy 
> preferences pane, where there is a message that such-and-such was prevented 
> from running, and click the button to allow it in the future.
> 
> > Would you try running LilyPond from the command line in debug mode ( 
> > LilyPond.app/Contents/Resources/bin/lilypond --loglevel=debug myfile.ly) 
> > and let me know what Ghostscript errors you see?
> 
> Converting to `simple.pdf'...
> Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 
> -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite 
> -dAutoRotatePages=/None -dPrinted=false -sOutputFile=simple.pdf 
> -c.setpdfwrite 
> -f/var/folders/3k/ftz328kw8xj94s0059bcsnx8gp/T//lilypond-gJjMWd'...
> 
> GPL Ghostscript 9.50 (2019-10-15)
> Copyright (C) 2019 Artifex Software, Inc.  All rights reserved.
> This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
> see the file COPYING for details.
> 
> *** Warning: GenericResourceDir doesn't point to a valid resource directory.
>the -sGenericResourceDir=... option can be used to set this.

GUB has another gs.reloc which sets a few variables looking related...

Jonas

prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/ghostscript/9.21/fonts
prependdir GS_FONTPATH=$INSTALLER_PREFIX/share/gs/fonts
prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.21/Resource
prependdir GS_LIB=$INSTALLER_PREFIX/share/ghostscript/9.21/Resource/Init


signature.asc
Description: This is a digitally signed message part

Re: macOS 64-bit

[Dan Eble]

On Jan 11, 2020, at 07:48, Marnen Laibow-Koser  wrote:
> 
> Could you try it without renaming and see if you get the same results?  
> (Renaming shouldn’t actually matter, but I want to make sure I didn’t do 
> something stupid.)

same result


> There was the usual security problem with running unsigned apps,
> which was solved in the usual way in the Security & Privacy preferences pane.
> 
> What “usual way” is that?  I usually just right-click on the app and open it 
> and ask it to override, although I didn’t need to do that with this app.  
> Perhaps renaming the bundle did something here?

With command-line programs, there's no right-clicking.  When you try to run the 
program, the OS kills it (signal 9).  If you're lucky, it pops up a dialog box 
explaining that it has done so.  Open the Security & Privacy preferences pane, 
where there is a message that such-and-such was prevented from running, and 
click the button to allow it in the future.

> Would you try running LilyPond from the command line in debug mode ( 
> LilyPond.app/Contents/Resources/bin/lilypond --loglevel=debug myfile.ly) and 
> let me know what Ghostscript errors you see?

Converting to `simple.pdf'...
Invoking `gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite 
-dAutoRotatePages=/None -dPrinted=false -sOutputFile=simple.pdf -c.setpdfwrite 
-f/var/folders/3k/ftz328kw8xj94s0059bcsnx8gp/T//lilypond-gJjMWd'...

GPL Ghostscript 9.50 (2019-10-15)
Copyright (C) 2019 Artifex Software, Inc.  All rights reserved.
This software is supplied under the GNU AGPLv3 and comes with NO WARRANTY:
see the file COPYING for details.

*** Warning: GenericResourceDir doesn't point to a valid resource directory.
   the -sGenericResourceDir=... option can be used to set this.

  ./base/gsicc_manage.c:1254: gsicc_open_search(): Could not find 
default_gray.icc 
| ./base/gsicc_manage.c:2272: gsicc_init_iccmanager(): cannot find default icc 
profile
 Unable to open the initial device, quitting.
warning: `(gs -dSAFER -dDEVICEWIDTHPOINTS=595.28 -dDEVICEHEIGHTPOINTS=841.89 
-dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 -sDEVICE=pdfwrite 
-dAutoRotatePages=/None -dPrinted=false -sOutputFile=simple.pdf -c.setpdfwrite 
-f/var/folders/3k/ftz328kw8xj94s0059bcsnx8gp/T//lilypond-gJjMWd)' failed 
(256)

fatal error: failed files: "./simple.ly"
— 
Dan

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Sat, Jan 11, 2020 at 7:08 AM Dan Eble  wrote:

> On Jan 11, 2020, at 01:36, Marnen Laibow-Koser  wrote:
> > I'd really appreciate fellow Mac users testing the build and reporting
> any
> > issues you find.  (Karlin? Carl?)  You can download it at
> > https://drive.google.com/open?id=18b1nX5nJsBrzDBGqga9T753oCL8ilwqs ; it
> > should work on any recent version of Mac OS.  I'm particularly interested
> > in reports from Catalina users, but really, at this point, any
> information
> > is useful.
>
> I've never been a LilyPond GUI user,


Neither am I; I use Frescobaldi instead.  The .app bundle is convenient for
packaging dependencies, though, which is why I’m putting the effort into
making it work.

so I first tried to run
> /Applications/LilyPond-2.19.app/Contents/Resources/bin/lilypond from a
> Makefile on macOS 10.15.2 (Catalina).  (Renaming LilyPond.app to include
> the version number has been my practice for a while.)


Could you try it without renaming and see if you get the same results?
 (Renaming shouldn’t actually matter, but I want to make sure I didn’t do
something stupid.)


>
> There was the usual security problem with running unsigned apps,

which was solved in the usual way in the Security & Privacy preferences
> pane.


What “usual way” is that?  I usually just right-click on the app and open
it and ask it to override, although I didn’t need to do that with this
app.  Perhaps renaming the bundle did something here?



> Near startup, there was this message I don't remember having seen before:
>
> Unable to revert mtime: /Library/Fonts
>
> It probably comes from here:
>
> $ (cd /Applications/LilyPond* && grep -r "Unable to revert mtime" .)
> Binary file ./Contents/Resources/lib/libfontconfig.1.dylib matches


I wonder if that’s an actual problem.


>
> Next, it looks like gs failed:
>
> warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=612.00
> -dDEVICEHEIGHTPOINTS=792.00 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH
> -r1200 -sDEVICE=pdfwrite -dAutoRotatePages=/None -dPrinted=false
> -sOutputFile=ar10_holy_God_behold_my_heart_is_turning.pdf -c.setpdfwrite
> -f/var/folders/3k/ftz328kw8xj94s0059bcsnx8gp/T//lilypond-zC36CX)'
> failed (256)


How frustrating.  I thought I had fixed this issue.

Would you try running LilyPond from the command line in debug mode (
LilyPond.app/Contents/Resources/bin/lilypond --loglevel=debug myfile.ly)
and let me know what Ghostscript errors you see?

Thanks very much for testing this, and I’m sorry about the lingering
errors.  I’ll try to fix them.

Best,
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: macOS 64-bit

[Dan Eble]

On Jan 11, 2020, at 01:36, Marnen Laibow-Koser  wrote:
> I'd really appreciate fellow Mac users testing the build and reporting any
> issues you find.  (Karlin? Carl?)  You can download it at
> https://drive.google.com/open?id=18b1nX5nJsBrzDBGqga9T753oCL8ilwqs ; it
> should work on any recent version of Mac OS.  I'm particularly interested
> in reports from Catalina users, but really, at this point, any information
> is useful.

I've never been a LilyPond GUI user, so I first tried to run 
/Applications/LilyPond-2.19.app/Contents/Resources/bin/lilypond from a Makefile 
on macOS 10.15.2 (Catalina).  (Renaming LilyPond.app to include the version 
number has been my practice for a while.)

There was the usual security problem with running unsigned apps, which was 
solved in the usual way in the Security & Privacy preferences pane.

Near startup, there was this message I don't remember having seen before:

Unable to revert mtime: /Library/Fonts

It probably comes from here:

$ (cd /Applications/LilyPond* && grep -r "Unable to revert mtime" .)
Binary file ./Contents/Resources/lib/libfontconfig.1.dylib matches

Next, it looks like gs failed:

warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=612.00 
-dDEVICEHEIGHTPOINTS=792.00 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 
-sDEVICE=pdfwrite -dAutoRotatePages=/None -dPrinted=false 
-sOutputFile=ar10_holy_God_behold_my_heart_is_turning.pdf -c.setpdfwrite 
-f/var/folders/3k/ftz328kw8xj94s0059bcsnx8gp/T//lilypond-zC36CX)' failed 
(256)

I tried processing input/regression/bend-bound.ly in the GUI; the result was 
similar:

Processing `/Users/dan/Music/LilyPond/bend-bound.ly'
Parsing…
Interpreting music…
Preprocessing graphical objects…
Interpreting music…
Preprocessing graphical objects…
Finding the ideal number of pages…
Fitting music on 1 page…
Drawing systems…
Layout output to 
`/var/folders/3k/ftz328kw8xj94s0059bcsnx8gp/T//lilypond-JXArKN'…
Converting to `bend-bound.pdf'…
warning: `(gs -q -dSAFER -dDEVICEWIDTHPOINTS=595.28 
-dDEVICEHEIGHTPOINTS=841.89 -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -r1200 
-sDEVICE=pdfwrite -dAutoRotatePages=/None -dPrinted=false 
-sOutputFile=bend-bound.pdf -c.setpdfwrite 
-f/var/folders/3k/ftz328kw8xj94s0059bcsnx8gp/T//lilypond-JXArKN)' failed 
(256)

fatal error: failed files: "/Users/dan/Music/LilyPond/bend-bound.ly"
— 
Dan

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Thu, Jan 9, 2020 at 10:11 PM Marnen Laibow-Koser 
wrote:

> On Thu, Jan 9, 2020 at 1:44 PM Marnen Laibow-Koser 
> wrote:
>
>> On Thu, Jan 9, 2020 at 12:15 PM Jonas Hahnfeld  wrote:
>>
>>> Am Donnerstag, den 09.01.2020, 11:14 -0500 schrieb Marnen Laibow-Koser:
>>> >
>>> >
>>> > On Thu, Jan 9, 2020 at 10:47 AM Jonas Hahnfeld 
>>> wrote:
>>> > [...]
>>> > > Running
>>> > > $ diff -ur root/usr/ installer/LilyPond.app/Contents/Resources/
>>> > > in target/darwin-x86 reveals many files that I cannot attribute to
>>> the
>>> > > mentioned blacklist. Hence there must be additional mechanism that
>>> > > determine which files go in and which do not.
>>> >
>>> > Hmm, interesting.  I can't easily run that diff (because of not having
>>> a GUB environment available); would you be willing to post the contents so
>>> I can do research on that?
>>>
>>> Sure, here it is.
>>>
>>
>> Thanks!  I might add it to that Gist so everything is in one place.
>>
>
> I think I am very close to having a working 64-bit Mac .app bundle,
> probably about a day’s worth of work or less.  Then I have to come up with
> a good way of automating the process (my research notes and shell commands
> I’m using are also in that Gist I posted a link to).
>

And SUCCESS!  I have a working 64-bit Mac .app bundle build of LilyPond
2.19.83, and I just used it to typeset a chamber work of mine without
problems.  Build info (such as it is) is at the Gist at
https://gist.github.com/marnen/137b056d95b1c8400af8f823dced54f0 ; I'll be
putting this into a proper repo and automating it for CI (probably either
GitLab CI or Buildkite) soon.

I'd really appreciate fellow Mac users testing the build and reporting any
issues you find.  (Karlin? Carl?)  You can download it at
https://drive.google.com/open?id=18b1nX5nJsBrzDBGqga9T753oCL8ilwqs ; it
should work on any recent version of Mac OS.  I'm particularly interested
in reports from Catalina users, but really, at this point, any information
is useful.

If it seems like it works, I'd recommend putting it on the website's
download page so that Mac users have something to work with...

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Fri, Jan 10, 2020 at 7:57 PM Marnen Laibow-Koser 
wrote:

> On Fri, Jan 10, 2020 at 10:45 AM Marnen Laibow-Koser 
> wrote:
>
>>
>>
>> On Fri, Jan 10, 2020 at 10:19 AM Jonas Hahnfeld  wrote:
>>
>>> Am Freitag, den 10.01.2020, 09:04 -0500 schrieb Marnen Laibow-Koser:
>>> > On Fri, Jan 10, 2020 at 2:29 AM Jonas Hahnfeld 
>>> wrote:
>>
>> [...]
>>
>>> > > From my experiments, this is where LilyPond's relocation kicks in. I
>>> > > think you have to provide .reloc files in etc/relocation, that's also
>>> > > what GUB does.
>>> >
>>> > Yup, I copied those over from the GUB-built bundle.  I'm not quite
>>> sure how they work, but it looks like the LilyPond executable looks for
>>> them on startup, right?
>>>
>>> Yes, I think that's in lily/relocate.cc.
>>
>>
>> Right.  I’ve been trying to understand what goes on in there.
>>
>>
>>>
>>> > Unfortunately, I don't quite see how to set the right path in those:
>>> an .app bundle is movable, and while the Mac OS path resolver has a special
>>> notation (@executable_path) for the path of the executable within that
>>> bundle, it doesn't seem to put it into an environment variable in any
>>> useful way.  I tried @executable_path in those pathnames, but it didn't
>>> *seem* to work; OTOH, it changed enough behavior that further research may
>>> be worth while.
>>>
>>> LilyPond sets INSTALLER_PREFIX to the directory where bin/, lib/,
>>> share/ etc are. This worked quite well in my experiments, with the
>>> files I provided.
>>
>>
>> Oh, that variable is set by LilyPond?  Awesome; that will make my life
>> easier.
>>
>> I’m not sure it’s all working properly, though.  It seems like relocate
>> is setting the Guile library path correctly, and I’ve also set
>> LTDL_LIBRARY_PATH, but it’s still not finding ice-9/boot.scm, even though
>> it’s in the appropriate directory.
>>
>
> I was wrong about ice-9 being the issue; that seems to have been fixed
> with GUILE_LOAD_PATH and/or LDTL_LIBRARY_PATH.  However, while the load
> path is being set properly, load-extension in Guile is looking for dylibs
> in the wrong place (specifically, in LilyPond.app/Contents/Resources/var,
> as well as a couple of related paths and some /usr/lib-type directories).
> I can't figure out how to change that setting, and Guile's docs are not
> very clear on how to set the extensiondir.  Any ideas before I just give up
> and put the libraries in var?
>

Please disregard.  I had misspelled LTDL as LDTL.  Grr.


>
> Best,
> --
> Marnen Laibow-Koser
> mar...@marnen.org
> http://www.marnen.org
>


-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Fri, Jan 10, 2020 at 10:45 AM Marnen Laibow-Koser 
wrote:

>
>
> On Fri, Jan 10, 2020 at 10:19 AM Jonas Hahnfeld  wrote:
>
>> Am Freitag, den 10.01.2020, 09:04 -0500 schrieb Marnen Laibow-Koser:
>> > On Fri, Jan 10, 2020 at 2:29 AM Jonas Hahnfeld 
>> wrote:
>
> [...]
>
>> > > From my experiments, this is where LilyPond's relocation kicks in. I
>> > > think you have to provide .reloc files in etc/relocation, that's also
>> > > what GUB does.
>> >
>> > Yup, I copied those over from the GUB-built bundle.  I'm not quite sure
>> how they work, but it looks like the LilyPond executable looks for them on
>> startup, right?
>>
>> Yes, I think that's in lily/relocate.cc.
>
>
> Right.  I’ve been trying to understand what goes on in there.
>
>
>>
>> > Unfortunately, I don't quite see how to set the right path in those: an
>> .app bundle is movable, and while the Mac OS path resolver has a special
>> notation (@executable_path) for the path of the executable within that
>> bundle, it doesn't seem to put it into an environment variable in any
>> useful way.  I tried @executable_path in those pathnames, but it didn't
>> *seem* to work; OTOH, it changed enough behavior that further research may
>> be worth while.
>>
>> LilyPond sets INSTALLER_PREFIX to the directory where bin/, lib/,
>> share/ etc are. This worked quite well in my experiments, with the
>> files I provided.
>
>
> Oh, that variable is set by LilyPond?  Awesome; that will make my life
> easier.
>
> I’m not sure it’s all working properly, though.  It seems like relocate is
> setting the Guile library path correctly, and I’ve also set
> LTDL_LIBRARY_PATH, but it’s still not finding ice-9/boot.scm, even though
> it’s in the appropriate directory.
>

I was wrong about ice-9 being the issue; that seems to have been fixed with
GUILE_LOAD_PATH and/or LDTL_LIBRARY_PATH.  However, while the load path is
being set properly, load-extension in Guile is looking for dylibs in the
wrong place (specifically, in LilyPond.app/Contents/Resources/var, as well
as a couple of related paths and some /usr/lib-type directories).  I can't
figure out how to change that setting, and Guile's docs are not very clear
on how to set the extensiondir.  Any ideas before I just give up and put
the libraries in var?

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Fri, Jan 10, 2020 at 10:19 AM Jonas Hahnfeld  wrote:

> Am Freitag, den 10.01.2020, 09:04 -0500 schrieb Marnen Laibow-Koser:
> > On Fri, Jan 10, 2020 at 2:29 AM Jonas Hahnfeld  wrote:

[...]

> > > From my experiments, this is where LilyPond's relocation kicks in. I
> > > think you have to provide .reloc files in etc/relocation, that's also
> > > what GUB does.
> >
> > Yup, I copied those over from the GUB-built bundle.  I'm not quite sure
> how they work, but it looks like the LilyPond executable looks for them on
> startup, right?
>
> Yes, I think that's in lily/relocate.cc.


Right.  I’ve been trying to understand what goes on in there.


>
> > Unfortunately, I don't quite see how to set the right path in those: an
> .app bundle is movable, and while the Mac OS path resolver has a special
> notation (@executable_path) for the path of the executable within that
> bundle, it doesn't seem to put it into an environment variable in any
> useful way.  I tried @executable_path in those pathnames, but it didn't
> *seem* to work; OTOH, it changed enough behavior that further research may
> be worth while.
>
> LilyPond sets INSTALLER_PREFIX to the directory where bin/, lib/,
> share/ etc are. This worked quite well in my experiments, with the
> files I provided.


Oh, that variable is set by LilyPond?  Awesome; that will make my life
easier.

I’m not sure it’s all working properly, though.  It seems like relocate is
setting the Guile library path correctly, and I’ve also set
LTDL_LIBRARY_PATH, but it’s still not finding ice-9/boot.scm, even though
it’s in the appropriate directory.


>
> Jonas


Best,
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: macOS 64-bit

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Freitag, den 10.01.2020, 09:04 -0500 schrieb Marnen Laibow-Koser:
> On Fri, Jan 10, 2020 at 2:29 AM Jonas Hahnfeld  wrote:
> > Am Freitag, den 10.01.2020, 01:07 -0500 schrieb Marnen Laibow-Koser:
> > > 
> > > 
> > > On Fri, Jan 10, 2020 at 1:03 AM Werner LEMBERG  wrote:
> > > > > There is one lingering problem: when LilyPond calls Guile, Guile is
> > > > > not finding the library files specified in load-extension
> > > > > expressions, even though they *should* be in the right place.
> > > > > Before I go too crazy searching, does anyone know what controls this
> > > > > path choice?  I'm assuming it may be a compilation option for the
> > > > > LilyPond binary, but I really don't know.
> > > > 
> > > > Here's a link to the script MacPorts is using to call lilypond.
> > > > 
> > > >   
> > > > https://github.com/macports/macports-ports/blob/master/textproc/lilypond-devel/files/lilypond.in
> > > > 
> > > > It seems you have to set LDTL_LIBRARY_PATH.
> > > 
> > > I saw that, of course, but I’m not sure what that variable even is.  In 
> > > particular, I have no reason to believe that it affects Guile’s load 
> > > path...but I’ll try it and see.  Thanks for the reminder. 
> > > 
> > > I *think* that the Guile load path is the last issue standing between me 
> > > and a self-contained 64-bit Mac .app bundle.  Everything else appears to 
> > > be working.
> > 
> > From my experiments, this is where LilyPond's relocation kicks in. I
> > think you have to provide .reloc files in etc/relocation, that's also
> > what GUB does.
> 
> Yup, I copied those over from the GUB-built bundle.  I'm not quite sure how 
> they work, but it looks like the LilyPond executable looks for them on 
> startup, right?

Yes, I think that's in lily/relocate.cc.

> Unfortunately, I don't quite see how to set the right path in those: an .app 
> bundle is movable, and while the Mac OS path resolver has a special notation 
> (@executable_path) for the path of the executable within that bundle, it 
> doesn't seem to put it into an environment variable in any useful way.  I 
> tried @executable_path in those pathnames, but it didn't *seem* to work; 
> OTOH, it changed enough behavior that further research may be worth while.

LilyPond sets INSTALLER_PREFIX to the directory where bin/, lib/,
share/ etc are. This worked quite well in my experiments, with the
files I provided.

Jonas


signature.asc
Description: This is a digitally signed message part

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Fri, Jan 10, 2020 at 2:29 AM Jonas Hahnfeld  wrote:

> Am Freitag, den 10.01.2020, 01:07 -0500 schrieb Marnen Laibow-Koser:
> >
> >
> > On Fri, Jan 10, 2020 at 1:03 AM Werner LEMBERG  wrote:
> > > > There is one lingering problem: when LilyPond calls Guile, Guile is
> > > > not finding the library files specified in load-extension
> > > > expressions, even though they *should* be in the right place.
> > > > Before I go too crazy searching, does anyone know what controls this
> > > > path choice?  I'm assuming it may be a compilation option for the
> > > > LilyPond binary, but I really don't know.
> > >
> > > Here's a link to the script MacPorts is using to call lilypond.
> > >
> > >
> https://github.com/macports/macports-ports/blob/master/textproc/lilypond-devel/files/lilypond.in
> > >
> > > It seems you have to set LDTL_LIBRARY_PATH.
> >
> > I saw that, of course, but I’m not sure what that variable even is.  In
> particular, I have no reason to believe that it affects Guile’s load
> path...but I’ll try it and see.  Thanks for the reminder.
> >
> > I *think* that the Guile load path is the last issue standing between me
> and a self-contained 64-bit Mac .app bundle.  Everything else appears to be
> working.
>
> From my experiments, this is where LilyPond's relocation kicks in. I
> think you have to provide .reloc files in etc/relocation, that's also
> what GUB does.


Yup, I copied those over from the GUB-built bundle.  I'm not quite sure how
they work, but it looks like the LilyPond executable looks for them on
startup, right?

Unfortunately, I don't quite see how to set the right path in those: an
.app bundle is movable, and while the Mac OS path resolver has a special
notation (@executable_path) for the path of the executable within that
bundle, it doesn't seem to put it into an environment variable in any
useful way.  I tried @executable_path in those pathnames, but it didn't
*seem* to work; OTOH, it changed enough behavior that further research may
be worth while.

I should say here that I don't know that much about Mac application
packaging; I'm doing this mostly because no one else seemed interested to
do it and I really want a 64-bit build.


> It allows to dynamically set environment variables, in
> this case GUILE_LOAD_PATH.
> To point you to the next error in advance: You have to do the same for
> Fontconfig or it can't find its config file 😉
>

Ah, thanks for the warning.  At this point I think it's all about
path-munging.


>
> Hope this helps,
> Jonas
>

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: macOS 64-bit

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Freitag, den 10.01.2020, 01:07 -0500 schrieb Marnen Laibow-Koser:
> 
> 
> On Fri, Jan 10, 2020 at 1:03 AM Werner LEMBERG  wrote:
> > > There is one lingering problem: when LilyPond calls Guile, Guile is
> > > not finding the library files specified in load-extension
> > > expressions, even though they *should* be in the right place.
> > > Before I go too crazy searching, does anyone know what controls this
> > > path choice?  I'm assuming it may be a compilation option for the
> > > LilyPond binary, but I really don't know.
> > 
> > Here's a link to the script MacPorts is using to call lilypond.
> > 
> >   
> > https://github.com/macports/macports-ports/blob/master/textproc/lilypond-devel/files/lilypond.in
> > 
> > It seems you have to set LDTL_LIBRARY_PATH.
> 
> I saw that, of course, but I’m not sure what that variable even is.  In 
> particular, I have no reason to believe that it affects Guile’s load 
> path...but I’ll try it and see.  Thanks for the reminder. 
> 
> I *think* that the Guile load path is the last issue standing between me and 
> a self-contained 64-bit Mac .app bundle.  Everything else appears to be 
> working.

From my experiments, this is where LilyPond's relocation kicks in. I
think you have to provide .reloc files in etc/relocation, that's also
what GUB does. It allows to dynamically set environment variables, in
this case GUILE_LOAD_PATH.
To point you to the next error in advance: You have to do the same for
Fontconfig or it can't find its config file 😉

Hope this helps,
Jonas
prependdir GUILE_LOAD_PATH=$INSTALLER_PREFIX/share/guile/1.8
prependdir LD_LIBRARY_PATH=$INSTALLER_PREFIX/lib
set? FONTCONFIG_FILE=$INSTALLER_PREFIX/etc/fonts/fonts.conf


signature.asc
Description: This is a digitally signed message part

Re: macOS 64-bit

[Werner LEMBERG]

>> It seems you have to set LDTL_LIBRARY_PATH.

Typo!  I mean LTDL_LIBRARY_PATH/

> I saw that, of course, but I’m not sure what that variable even is.
> In particular, I have no reason to believe that it affects Guile’s
> load path...but I’ll try it and see.

It's documented in the guile manual, being the path for extensions:

 A shared library can be loaded into a running Guile process with
  the function `load-extension'.  [...]

 For this to work, `load-extension' [...] will look in the places
  that are usual for your operating system, and it will additionally
  look into the directories listed in the `LTDL_LIBRARY_PATH'
  environment variable.


Werner

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Fri, Jan 10, 2020 at 1:03 AM Werner LEMBERG  wrote:

>
> > There is one lingering problem: when LilyPond calls Guile, Guile is
> > not finding the library files specified in load-extension
> > expressions, even though they *should* be in the right place.
> > Before I go too crazy searching, does anyone know what controls this
> > path choice?  I'm assuming it may be a compilation option for the
> > LilyPond binary, but I really don't know.
>
> Here's a link to the script MacPorts is using to call lilypond.
>
>
> https://github.com/macports/macports-ports/blob/master/textproc/lilypond-devel/files/lilypond.in
>
> It seems you have to set LDTL_LIBRARY_PATH.


I saw that, of course, but I’m not sure what that variable even is.  In
particular, I have no reason to believe that it affects Guile’s load
path...but I’ll try it and see.  Thanks for the reminder.

I *think* that the Guile load path is the last issue standing between me
and a self-contained 64-bit Mac .app bundle.  Everything else appears to be
working.

>
>
>
> Werner
>
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: macOS 64-bit

[Werner LEMBERG]

> There is one lingering problem: when LilyPond calls Guile, Guile is
> not finding the library files specified in load-extension
> expressions, even though they *should* be in the right place.
> Before I go too crazy searching, does anyone know what controls this
> path choice?  I'm assuming it may be a compilation option for the
> LilyPond binary, but I really don't know.

Here's a link to the script MacPorts is using to call lilypond.

  
https://github.com/macports/macports-ports/blob/master/textproc/lilypond-devel/files/lilypond.in

It seems you have to set LDTL_LIBRARY_PATH.


Werner

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Thu, Jan 9, 2020 at 10:11 PM Marnen Laibow-Koser 
wrote:

> On Thu, Jan 9, 2020 at 1:44 PM Marnen Laibow-Koser 
> wrote:
>
>> On Thu, Jan 9, 2020 at 12:15 PM Jonas Hahnfeld  wrote:
>>
>>> Am Donnerstag, den 09.01.2020, 11:14 -0500 schrieb Marnen Laibow-Koser:
>>> >
>>> >
>>> > On Thu, Jan 9, 2020 at 10:47 AM Jonas Hahnfeld 
>>> wrote:
>>> > [...]
>>> > > Running
>>> > > $ diff -ur root/usr/ installer/LilyPond.app/Contents/Resources/
>>> > > in target/darwin-x86 reveals many files that I cannot attribute to
>>> the
>>> > > mentioned blacklist. Hence there must be additional mechanism that
>>> > > determine which files go in and which do not.
>>> >
>>> > Hmm, interesting.  I can't easily run that diff (because of not having
>>> a GUB environment available); would you be willing to post the contents so
>>> I can do research on that?
>>>
>>> Sure, here it is.
>>>
>>
>> Thanks!  I might add it to that Gist so everything is in one place.
>>
>
> I think I am very close to having a working 64-bit Mac .app bundle,
> probably about a day’s worth of work or less.  Then I have to come up with
> a good way of automating the process (my research notes and shell commands
> I’m using are also in that Gist I posted a link to).
>

There is one lingering problem: when LilyPond calls Guile, Guile is not
finding the library files specified in load-extension expressions, even
though they *should* be in the right place. Before I go too crazy
searching, does anyone know what controls this path choice? I'm assuming it
may be a compilation option for the LilyPond binary, but I really don't
know.


> Best,
> --
> Marnen Laibow-Koser
> mar...@marnen.org
> http://www.marnen.org
> --
> Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from
> Gmail Mobile
>


-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Thu, Jan 9, 2020 at 1:44 PM Marnen Laibow-Koser 
wrote:

> On Thu, Jan 9, 2020 at 12:15 PM Jonas Hahnfeld  wrote:
>
>> Am Donnerstag, den 09.01.2020, 11:14 -0500 schrieb Marnen Laibow-Koser:
>> >
>> >
>> > On Thu, Jan 9, 2020 at 10:47 AM Jonas Hahnfeld 
>> wrote:
>> > [...]
>> > > Running
>> > > $ diff -ur root/usr/ installer/LilyPond.app/Contents/Resources/
>> > > in target/darwin-x86 reveals many files that I cannot attribute to the
>> > > mentioned blacklist. Hence there must be additional mechanism that
>> > > determine which files go in and which do not.
>> >
>> > Hmm, interesting.  I can't easily run that diff (because of not having
>> a GUB environment available); would you be willing to post the contents so
>> I can do research on that?
>>
>> Sure, here it is.
>>
>
> Thanks!  I might add it to that Gist so everything is in one place.
>

I think I am very close to having a working 64-bit Mac .app bundle,
probably about a day’s worth of work or less.  Then I have to come up with
a good way of automating the process (my research notes and shell commands
I’m using are also in that Gist I posted a link to).

Best,
-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Thu, Jan 9, 2020 at 12:15 PM Jonas Hahnfeld  wrote:

> Am Donnerstag, den 09.01.2020, 11:14 -0500 schrieb Marnen Laibow-Koser:
> >
> >
> > On Thu, Jan 9, 2020 at 10:47 AM Jonas Hahnfeld  wrote:
> > [...]
> > > Running
> > > $ diff -ur root/usr/ installer/LilyPond.app/Contents/Resources/
> > > in target/darwin-x86 reveals many files that I cannot attribute to the
> > > mentioned blacklist. Hence there must be additional mechanism that
> > > determine which files go in and which do not.
> >
> > Hmm, interesting.  I can't easily run that diff (because of not having a
> GUB environment available); would you be willing to post the contents so I
> can do research on that?
>
> Sure, here it is.
>

Thanks!  I might add it to that Gist so everything is in one place.


>
> Jonas
>


-- 
Marnen Laibow-Koser
mar...@marnen.org
http://www.marnen.org

Re: MacOS 64-bit build

[Hans Åberg]

> On 9 Jan 2020, at 18:00, Werner LEMBERG  wrote:
> 
>>> There is no guarantee that `FlexLexer.h` found during compilation
>>> is the one that is used by a recent flex version.  Unfortunately,
>>> `FlexLexer.h` doesn't contain any version information, so it is
>>> really impossible to protect against this situation automatically.
>> 
>> Akim Demaille made a patch for it, see:
>> https://lists.gnu.org/archive/html/bug-bison/2018-09/msg00020.html
> 
> Nope, he didn't.  This patch is for something completely different, as
> far as I can see – LilyPond doesn't use `FlexLexer.hh`, it rather uses
> `FlexLexer.h` that comes with flex.

I did not look so careful at it, but I get the impression he makes his own 
header that depends on the Flex version.

> If you look into the git repository of flex you can see that even the
> most recent version of `FlexLexer.h` doesn't have any version
> information.

You can’t get around that, so one way around it is to make ones own header and 
include that. Then the .cc uses system includes, so either that should be 
patched too, or an option passed to the compiler.

Re: MacOS 64-bit build

[Dan Eble]

On Jan 9, 2020, at 07:00, Erlend Aasland  wrote:
> 
> Use flex 2.5.37, as the flex 2.6.* C++ lexer is broken (discussed on the Bison
> lists): a stream pointer has been changed in the declaration to a reference
> without doing it in the code. Reported some years ago on the flex list.

I've been building master with flex 2.6.4 and I have not had any problem.
— 
Dan

Re: macOS 64-bit

[Marnen Laibow-Koser]

On Thu, Jan 9, 2020 at 12:16 PM Jonas Hahnfeld  wrote:

> Am Donnerstag, den 09.01.2020, 11:55 -0500 schrieb Marnen Laibow-Koser:
> > On Thu, Jan 9, 2020 at 10:47 AM Jonas Hahnfeld  wrote:
> > [...]
> > > Running
> > > $ diff -ur root/usr/ installer/LilyPond.app/Contents/Resources/
> > > in target/darwin-x86 reveals many files that I cannot attribute to the
> > > mentioned blacklist. Hence there must be additional mechanism that
> > > determine which files go in and which do not.
> >
> > Hmm, I just ran a similar diff (comparing the Lily bundle I just built
> with the "official" downloaded bundle).  Results are here:
> https://gist.github.com/marnen/137b056d95b1c8400af8f823dced54f0
>
> Your Lily bundle is still without LilyPond in Resources/, right?


Right.  I’m trying to figure out what files need to go into Resources/.

>
>
> Jonas
>
-- 
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile

Re: macOS 64-bit

[Jonas Hahnfeld via Discussions on LilyPond development]

Am Donnerstag, den 09.01.2020, 11:14 -0500 schrieb Marnen Laibow-Koser:
> 
> 
> On Thu, Jan 9, 2020 at 10:47 AM Jonas Hahnfeld  wrote:
> [...]
> > Running
> > $ diff -ur root/usr/ installer/LilyPond.app/Contents/Resources/
> > in target/darwin-x86 reveals many files that I cannot attribute to the
> > mentioned blacklist. Hence there must be additional mechanism that
> > determine which files go in and which do not.
> 
> Hmm, interesting.  I can't easily run that diff (because of not having a GUB 
> environment available); would you be willing to post the contents so I can do 
> research on that?

Sure, here it is.

Jonas
Only in root/usr/bin: 2to3
Only in root/usr/bin: 2to3-3.7
Only in root/usr/bin: autopoint
Only in root/usr/bin: bmp2tiff
Binary files root/usr/bin/dfont2res and installer/LilyPond.app/Contents/Resources/bin/dfont2res differ
Only in root/usr/bin: dvipdf
Only in root/usr/bin: envsubst
Only in root/usr/bin: fax2ps
Only in root/usr/bin: fax2tiff
Binary files root/usr/bin/fc-cache and installer/LilyPond.app/Contents/Resources/bin/fc-cache differ
Binary files root/usr/bin/fc-cat and installer/LilyPond.app/Contents/Resources/bin/fc-cat differ
Binary files root/usr/bin/fc-list and installer/LilyPond.app/Contents/Resources/bin/fc-list differ
Binary files root/usr/bin/fc-match and installer/LilyPond.app/Contents/Resources/bin/fc-match differ
Binary files root/usr/bin/flex and installer/LilyPond.app/Contents/Resources/bin/flex differ
Binary files root/usr/bin/fondu and installer/LilyPond.app/Contents/Resources/bin/fondu differ
Only in root/usr/bin: font2c
Only in root/usr/bin: freetype-config
Binary files root/usr/bin/frombin and installer/LilyPond.app/Contents/Resources/bin/frombin differ
Binary files root/usr/bin/gapplication and installer/LilyPond.app/Contents/Resources/bin/gapplication differ
Binary files root/usr/bin/gdbus and installer/LilyPond.app/Contents/Resources/bin/gdbus differ
Only in root/usr/bin: gettext
Only in root/usr/bin: gettextize
Only in root/usr/bin: gettext.sh
Only in root/usr/bin: gif2tiff
Binary files root/usr/bin/gio-querymodules and installer/LilyPond.app/Contents/Resources/bin/gio-querymodules differ
Binary files root/usr/bin/glib-compile-resources and installer/LilyPond.app/Contents/Resources/bin/glib-compile-resources differ
Binary files root/usr/bin/glib-compile-schemas and installer/LilyPond.app/Contents/Resources/bin/glib-compile-schemas differ
Binary files root/usr/bin/glib-genmarshal and installer/LilyPond.app/Contents/Resources/bin/glib-genmarshal differ
Only in root/usr/bin: glib-gettextize
Only in root/usr/bin: glib-mkenums
Binary files root/usr/bin/gobject-query and installer/LilyPond.app/Contents/Resources/bin/gobject-query differ
Binary files root/usr/bin/gresource and installer/LilyPond.app/Contents/Resources/bin/gresource differ
Binary files root/usr/bin/gs and installer/LilyPond.app/Contents/Resources/bin/gs differ
Only in root/usr/bin: gsbj
Only in root/usr/bin: gsdj
Only in root/usr/bin: gsdj500
Binary files root/usr/bin/gsettings and installer/LilyPond.app/Contents/Resources/bin/gsettings differ
Only in root/usr/bin: gslj
Only in root/usr/bin: gslp
Only in root/usr/bin: gsnd
Binary files root/usr/bin/gsx and installer/LilyPond.app/Contents/Resources/bin/gsx differ
Binary files root/usr/bin/gtester and installer/LilyPond.app/Contents/Resources/bin/gtester differ
Binary files root/usr/bin/guile and installer/LilyPond.app/Contents/Resources/bin/guile differ
Only in root/usr/bin: guile-config
Binary files root/usr/bin/hb-ot-shape-closure and installer/LilyPond.app/Contents/Resources/bin/hb-ot-shape-closure differ
Binary files root/usr/bin/hb-shape and installer/LilyPond.app/Contents/Resources/bin/hb-shape differ
Only in root/usr/bin: idle3
Only in root/usr/bin: idle3.7
Only in root/usr/bin: libtool
Only in root/usr/bin: libtoolize
Binary files root/usr/bin/lilypond and installer/LilyPond.app/Contents/Resources/bin/lilypond differ
Binary files root/usr/bin/lumper and installer/LilyPond.app/Contents/Resources/bin/lumper differ
Only in root/usr/bin: msgattrib
Only in root/usr/bin: msgcat
Only in root/usr/bin: msgcmp
Only in root/usr/bin: msgcomm
Only in root/usr/bin: msgconv
Only in root/usr/bin: msgen
Only in root/usr/bin: msgexec
Only in root/usr/bin: msgfilter
Only in root/usr/bin: msgfmt
Only in root/usr/bin: msggrep
Only in root/usr/bin: msginit
Only in root/usr/bin: msgmerge
Only in root/usr/bin: msgunfmt
Only in root/usr/bin: msguniq
Only in root/usr/bin: ngettext
Only in root/usr/bin: pal2rgb
Binary files root/usr/bin/pango-view and installer/LilyPond.app/Contents/Resources/bin/pango-view differ
Only in root/usr/bin: pf2afm
Only in root/usr/bin: ppm2tiff
Only in root/usr/bin: printafm
Only in root/usr/bin: pydoc3
Only in root/usr/bin: pydoc3.7
Only in root/usr/bin: python3
Only in root/usr/bin: python3.7
Only in root/usr/bin: python3.7-config
Only in root/usr/bin: python3.7m
Only in root/usr/bin: python3.7m-config
Only in root/usr/bin: python3-config
O