Re: Issue XXXX: Clean up to_string () etc. (issue 583320043 by nine.fierce.ball...@gmail.com)

2020-01-11 Thread lemzwerg--- via Discussions on LilyPond development

s += EXTSEP; // append a char to s
s += ext_; // append a string to s



— vs. —



s += EXTSEP + ext_;
  \___/
  make a string
\/
  append it to s



Either one could involve memory allocation, but I deemed it more
likely in the latter case.  I don't have reason to suspect this is a
performance bottlenck, but given that I had to touch the line, and
that it wasn't a major rewrite, I decided to try to improve it.


I'm not sure that it is an improvement.  Today, compilers use very good
optimization tools; I can imagine that the performance of both lines is
exactly the same – or that the one-line version performs even better
since the compiler can handle the memory allocation internally in an
optimized way.  Only a profiler can give a clear answer, and this is
most certainly dependent on the platform and the compiler.

I thus favor code that is easiest to understand by the user, or which
looks nice.  Normally, I very much favor a vertical flow of source code,
but in this particular case the compact one-liner looks easier to
comprehend.

https://codereview.appspot.com/583320043/


Re: macOS 64-bit

2020-01-11 Thread 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: [Notensatz im 21. Jahrhundert] edition-engraver session, Sunday Jan 19 @ 15:30

2020-01-11 Thread Kieren MacMillan
Hi Urs (et al.),

> This is a very good idea, and it is good you brought it up for
> discussion. I had a very similar plan with regard to the openLilyLib
> presentation on Sunday.

Excellent!

> I think the main target audience for the Sunday topics is people who
> are very much into LilyPond and its development anyway. Probably there
> are random participants, but anybody who stays for another night will
> very much have a quite specific reason to do so. Nobody will need to
> learn at that point what the edition-engraver or openLilyLib are

Well, with my 10 minutes, I’m still going to try not to leave someone "in the 
dust"…  =)

> Given what I wrote above I can imagine you could even reduce that to
> not more than 10 minutes by sending example files before.

I’ll do that.

> I would put “solving low-level technical issues” to the bottom of that
> list. This is something that may not be too suitable for discussion in
> the larger group since (I suspect) nobody except Jan-Peter will be able
> to discuss such issues spontaneously.

I suppose I mean more like J-P asking “Why, when I try to make the EE do X, it 
does Y?”, and David K saying “Well, Lilypond sees X as Z, so you need to write 
Z->X first” or whatever.

> What I think would be most helpful and making most of the “historic
> situation“ would be discussing ways how to get the edition-engraver
> integrated in LilyPond.

Yes. Would love that.

> Integration of the edition-engraver in Frescobaldi is another issue
> with additional implications. We won't directly support it until it is
> integrated in LilyPond.

Ah. It’s good to know the order of operations on that.

> However, there is one road that can be pursued,
> and that is Frescobaldi's new extension API.

That’s what I was thinking.

> What do you think?

I like the direction that day is heading in.

Thanks,
Kieren.


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




Re: macOS 64-bit

2020-01-11 Thread 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

2020-01-11 Thread 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

2020-01-11 Thread 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: Replace deprecated functions from string module (issue 566920044 by jonas.hahnf...@gmail.com)

2020-01-11 Thread dak

On 2020/01/12 01:13:51, dak wrote:

https://codereview.appspot.com/566920044/diff/549120043/python/convertrules.py

File python/convertrules.py (right):



https://codereview.appspot.com/566920044/diff/549120043/python/convertrules.py#newcode3898

python/convertrules.py:3898: mods = str.join (re.findall ("\n(" +

wordsyntax +

r")\s*=\s*\\with(?:\s|\\|\{)")
   File


"/usr/local/tmp/lilypond/out/lib/lilypond/current/python/convertrules.py",
line

3892, in conv
 mods = str.join (re.findall ("\n(" + wordsyntax +
r")\s*=\s*\\with(?:\s|\\|\{)")
TypeError: findall() takes at least 2 arguments (1 given)



I'd call that a case of insufficient testing...  Sometimes our tests

don't cover

everything and one has to check out things on one's own.


Just pushed a fix to staging.

https://codereview.appspot.com/566920044/



Re: Replace deprecated functions from string module (issue 566920044 by jonas.hahnf...@gmail.com)

2020-01-11 Thread dak



https://codereview.appspot.com/566920044/diff/549120043/python/convertrules.py
File python/convertrules.py (right):

https://codereview.appspot.com/566920044/diff/549120043/python/convertrules.py#newcode3898
python/convertrules.py:3898: mods = str.join (re.findall ("\n(" +
wordsyntax + r")\s*=\s*\\with(?:\s|\\|\{)")
  File
"/usr/local/tmp/lilypond/out/lib/lilypond/current/python/convertrules.py",
line 3892, in conv
mods = str.join (re.findall ("\n(" + wordsyntax +
r")\s*=\s*\\with(?:\s|\\|\{)")
TypeError: findall() takes at least 2 arguments (1 given)

I'd call that a case of insufficient testing...  Sometimes our tests
don't cover everything and one has to check out things on one's own.

https://codereview.appspot.com/566920044/



Re: Fix a few complaints in python/convertrules.py (issue 583290043 by d...@gnu.org)

2020-01-11 Thread dak

Reviewers: hahnjo,


https://codereview.appspot.com/583290043/diff/557180043/python/convertrules.py
File python/convertrules.py (right):

https://codereview.appspot.com/583290043/diff/557180043/python/convertrules.py#newcode1774
python/convertrules.py:1774: str += "'" * (o + 1)
On 2020/01/08 08:17:25, hahnjo wrote:

I agree that this is equivalent, but still very confusing. I would

propose the

following which should highlight the intent:
o += 1
if o < 0:
 str += ',' * (-o)
elif o > 0:
 str += "'" * o


I thought about this but then considered it not significantly clearer.
Since the clarity is for readers of code rather than writers, I'll take
your opinion over mine here.

Description:
Fix a few complaints in python/convertrules.py

Please review this at https://codereview.appspot.com/583290043/

Affected files (+4, -11 lines):
  M python/convertrules.py


Index: python/convertrules.py
diff --git a/python/convertrules.py b/python/convertrules.py
index  
f412800666fcbf833a919869acd7bdb0d1b0f481..24e86e789914f39015413a973bcf61eaacb25247  
100644

--- a/python/convertrules.py
+++ b/python/convertrules.py
@@ -1759,13 +1759,7 @@ def conv (str):
 @rule ((2, 1, 27), "property transposing -> tuning")
 def conv (str):
 def subst (m):
-g = int (m.group (2))
-o = g / 12
-g -= o * 12
-if g <  0:
-g += 12
-o -= 1
-
+(o, g) = divmod (int (m.group (2)), 12)

 lower_pitches = filter (lambda x : x <= g, [0, 2, 4, 5, 7, 9, 11,  
12])

 s = len (lower_pitches) -1
@@ -1774,9 +1768,9 @@ def conv (str):

 str = 'cdefgab' [s]
 str += ['eses', 'es', '', 'is', 'isis'][a + 2]
-if o < 0:
+if o < -1:
 str += ',' * (-o - 1)
-elif o >= 0:
+elif o > -1:
 str += "'" * (o + 1)

 return '\\transposition %s ' % str
@@ -3218,7 +3212,6 @@ def paren_matcher (n):
 # parens inside; add the outer parens yourself if needed.
 # Nongreedy.
 return r"[^()]*?(?:\("*n+r"[^()]*?"+r"\)[^()]*?)*?"*n
-return

 def undollar_scm (m):
 return re.sub (r"\$(.?)", r"\1", m.group (0))
@@ -3977,7 +3970,7 @@ def conv (str):
 str = re.sub (r'\\powerChords', '', str)
 str = re.sub (r'"scripts\.trilelement"', r'"scripts.trillelement"',  
str)

 str = re.sub (r"\\fermataMarkup", r"\\fermata", str)
-if re.search (r"#[banter|jazz]-chord-names", str):
+if re.search (r"#(banter|jazz)-chordnames", str):
 stderr_write (NOT_SMART % "alternative chord naming functions")
 stderr_write (UPDATE_MANUALLY)
 return str





Re: Issue XXXX: Clean up to_string () etc. (issue 583320043 by nine.fierce.ball...@gmail.com)

2020-01-11 Thread nine . fierce . ballads


https://codereview.appspot.com/583320043/diff/581420044/flower/file-name.cc
File flower/file-name.cc (right):

https://codereview.appspot.com/583320043/diff/581420044/flower/file-name.cc#newcode124
flower/file-name.cc:124: s += ext_;
On 2020/01/11 22:20:34, lemzwerg wrote:

any reason to use two lines?  In other files you use a single line for

similar

things.


s += EXTSEP; // append a char to s
s += ext_; // append a string to s

— vs. —

s += EXTSEP + ext_;
 \___/
 make a string
\/
 append it to s

Either one could involve memory allocation, but I deemed it more
likely in the latter case.  I don't have reason to suspect this is a
performance bottlenck, but given that I had to touch the line, and
that it wasn't a major rewrite, I decided to try to improve it.

https://codereview.appspot.com/583320043/


Re: lilypond-devel Digest, Vol 206, Issue 32

2020-01-11 Thread Marnen Laibow-Koser
On Sat, Jan 11, 2020 at 6:05 PM Stanton Sanderson 
wrote:

> > On Jan 11, 2020, at 3:29 PM, lilypond-devel-requ...@gnu.org 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
> > (sha-256
> 6f1300a64281273da22c53926b6f5cbfa41fe612df173b0aaa4da905ee6b2af7;
>
>
> both new and previous versions work well on Mac X OS 14.6 EXCEPT that the
> convert-ly module fails with:
>
>  Traceback (most recent call last):
>   File
> "/Users/ssanders/Desktop/LilyPond_TEST_.app/Contents/Resources/bin/convert-ly",
> line 27, in 
> import shutil
>   File
> "/Users/ssanders/Desktop/LilyPond_TEST_.app/Contents/Resources/shutil.py",
> line 19, in 
> from . import tarfile
> ValueError: Attempted relative import in non-package
>
> (which may be expected… but you asked for reports;-)


I appreciate it.  I haven’t tested convert-ly yet.  Clearly I should have.
 :)  Thanks for the bug report.


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


Re: lilypond-devel Digest, Vol 206, Issue 32

2020-01-11 Thread Stanton Sanderson
> On Jan 11, 2020, at 3:29 PM, lilypond-devel-requ...@gnu.org 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
> (sha-256 6f1300a64281273da22c53926b6f5cbfa41fe612df173b0aaa4da905ee6b2af7;


both new and previous versions work well on Mac X OS 14.6 EXCEPT that the 
convert-ly module fails with:

 Traceback (most recent call last):
  File 
"/Users/ssanders/Desktop/LilyPond_TEST_.app/Contents/Resources/bin/convert-ly", 
line 27, in 
import shutil
  File 
"/Users/ssanders/Desktop/LilyPond_TEST_.app/Contents/Resources/shutil.py", line 
19, in 
from . import tarfile
ValueError: Attempted relative import in non-package

(which may be expected… but you asked for reports;-)

Thanks,

Stan




Re: Issue XXXX: Clean up to_string () etc. (issue 583320043 by nine.fierce.ball...@gmail.com)

2020-01-11 Thread lemzwerg--- via Discussions on LilyPond development

LGTM, thanks!


https://codereview.appspot.com/583320043/diff/581420044/flower/file-name.cc
File flower/file-name.cc (right):

https://codereview.appspot.com/583320043/diff/581420044/flower/file-name.cc#newcode124
flower/file-name.cc:124: s += ext_;
any reason to use two lines?  In other files you use a single line for
similar things.

https://codereview.appspot.com/583320043/



Re: [Notensatz im 21. Jahrhundert] edition-engraver session, Sunday Jan 19 @ 15:30

2020-01-11 Thread Werner LEMBERG

> 11:15 Frescobaldi
> 15:30 openLilyLib
> 16:00 edition-engraver

Program changed accordingly; I now use »Vormittag« and »Nachmittag« as
block names.


Werner


Re: [Notensatz im 21. Jahrhundert] edition-engraver session, Sunday Jan 19 @ 15:30

2020-01-11 Thread Thomas Morley
Am Sa., 11. Jan. 2020 um 20:45 Uhr schrieb Urs Liska :

> I think the main target audience for the Sunday topics is people who
> are very much into LilyPond and its development anyway. Probably there
> are random participants, but anybody who stays for another night will
> very much have a quite specific reason to do so. Nobody will need to
> learn at that point what the edition-engraver or openLilyLib are
> generally.

Well, my talk is mostly held out of a user's point of view and mostly
addresses advanced users and users on the way to be advanced. :)

Anyway, I don't know much about the edition-engraver (never used it
myself), but I support the idea to bundle talks about it.
Would be interesting to hear about it from different people shedding
light on it from different sides.

Cheers,
  Harm



Re: macOS 64-bit

2020-01-11 Thread 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: [Notensatz im 21. Jahrhundert] edition-engraver session, Sunday Jan 19 @ 15:30

2020-01-11 Thread Urs Liska
Hi Kieren,

Am Samstag, den 11.01.2020, 11:03 -0500 schrieb Kieren MacMillan:
> Hello colleagues!
> 
> I just had a wonderful video-chat with Jan-Peter, as part of the
> preparations for my session “The Edition-Engraver: The benefits and
> limitations of tweaking LilyPond scores” at next week’s
> [un]conference.
> 
> Rather than simply talk for thirty minutes about how I use the
> edition-engraver, I feel the very best use of this historic
> opportunity — having so many important Lilypond developers together
> in one place at one time — is to dedicate some portion of my session
> time to a discussion/brainstorm regarding the current roadblocks
> facing the edition-engraver, both technically and (to a much lesser
> extent) from the perspective of wider adoption and use.

This is a very good idea, and it is good you brought it up for
discussion. I had a very similar plan with regard to the openLilyLib
presentation on Sunday.

I think the main target audience for the Sunday topics is people who
are very much into LilyPond and its development anyway. Probably there
are random participants, but anybody who stays for another night will
very much have a quite specific reason to do so. Nobody will need to
learn at that point what the edition-engraver or openLilyLib are
generally.

> 
> I’m proposing I spend the first 10-15 minutes giving a more-or-less
> traditional presentation: an introduction to the extension/framework,
> examples of usage, best practices when coding with the EE, and so
> forth. 

Given what I wrote above I can imagine you could even reduce that to
not more than 10 minutes by sending example files before.

> Then, in the second "half" of the time slot, I facilitate/mediate a
> discussion — primarily between Jan-Peter and the main Lilypond and
> Frescobaldi development teams — in which we brainstorm how to bring
> the EE to its greatest potential, solve low-level technical issues,
> deeply integrate it in Frescobaldi, etc. The goal of this second
> section would not be to have solved the problems in 15-20 minutes, of
> course, but would just provide a chance for everyone to end up on the
> same page about this powerful tool and how it might move forward.

I would put “solving low-level technical issues” to the bottom of that
list. This is something that may not be too suitable for discussion in
the larger group since (I suspect) nobody except Jan-Peter will be able
to discuss such issues spontaneously.

What I think would be most helpful and making most of the “historic
situation“ would be discussing ways how to get the edition-engraver
integrated in LilyPond. This is raised every now and then, everybody (I
think) agrees to that, but it doesn't really have any substantial
progress. Which is - just like the deplorable state of openLilyLib's
documentation - due to the fact that Jan-Peter won't be able to achieve
that on his own and that never any community effort has gained any
traction.

Integration of the edition-engraver in Frescobaldi is another issue
with additional implications. We won't directly support it until it is
integrated in LilyPond. The only way to hard-code edition-engraver
support into Frescobaldi would be to include the code directly in the
Frescobaldi code, as we did with the code for the Layout Control Mode.
But I think everybody will agree that such a fork (which it would
effecitvely be) is a terrible idea.
However, there is one road that can be pursued, and that is
Frescobaldi's new extension API. I plan (have already old code that
could be adapted) to create an openLilyLib extension. This will allow
the Frescobaldi user to directly download, install and manage
openLilyLib and its packages and should also provide tools (shortcuts,
context menu items and maybe something like the Quick Insert Panel) to
simplify the inclusion of openLilyLib (a GUI for selecting and creating
the package loading code).
On top of that (but I haven't thought this through) that basic
extension will provide an infrastructure/API for *other* extensions
that may be added for specific packages. The prime use case *I* am
thinking of will be the scholarLY package, i.e. an annotation
editor/viewer. But such a package for the edition-engraver will also be
extremely helpful.

> 
> Jan-Peter is on board for this approach. How does it sound to
> everyone else? Please let us know if you plan to attend, and if so
> whether you’d be an interested/willing participant in a
> brainstorm/discussion.
> 

I think the above makes clear that I'm very much in favor of your
suggestion. However, I suggest we reorder the program for Sunday, and I
think it's not an issue to do that at this point. Regardless of the
actual points in time the three slots should be in the order
Frescobaldi => openLilyLib => edition-engraver. The Frescobaldi part
will introduce the extension concept, and openLilyLib is the framework
in which the edition-engraver operates (and any discussion about its
future should build upon the discussion of 

Re: macOS 64-bit

2020-01-11 Thread 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


[Notensatz im 21. Jahrhundert] edition-engraver session, Sunday Jan 19 @ 15:30

2020-01-11 Thread Kieren MacMillan
Hello colleagues!

I just had a wonderful video-chat with Jan-Peter, as part of the preparations 
for my session “The Edition-Engraver: The benefits and limitations of tweaking 
LilyPond scores” at next week’s [un]conference.

Rather than simply talk for thirty minutes about how I use the 
edition-engraver, I feel the very best use of this historic opportunity — 
having so many important Lilypond developers together in one place at one time 
— is to dedicate some portion of my session time to a discussion/brainstorm 
regarding the current roadblocks facing the edition-engraver, both technically 
and (to a much lesser extent) from the perspective of wider adoption and use.

I’m proposing I spend the first 10-15 minutes giving a more-or-less traditional 
presentation: an introduction to the extension/framework, examples of usage, 
best practices when coding with the EE, and so forth. Then, in the second 
"half" of the time slot, I facilitate/mediate a discussion — primarily between 
Jan-Peter and the main Lilypond and Frescobaldi development teams — in which we 
brainstorm how to bring the EE to its greatest potential, solve low-level 
technical issues, deeply integrate it in Frescobaldi, etc. The goal of this 
second section would not be to have solved the problems in 15-20 minutes, of 
course, but would just provide a chance for everyone to end up on the same page 
about this powerful tool and how it might move forward.

Jan-Peter is on board for this approach. How does it sound to everyone else? 
Please let us know if you plan to attend, and if so whether you’d be an 
interested/willing participant in a brainstorm/discussion.

Really looking forward to seeing all of you next week!

Best,
Kieren.


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




Re: macOS 64-bit

2020-01-11 Thread 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

2020-01-11 Thread 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

2020-01-11 Thread 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

2020-01-11 Thread 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

2020-01-11 Thread 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

2020-01-11 Thread 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

2020-01-11 Thread 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: GUB build error

2020-01-11 Thread Michael Käppler

Success for linux-64 target in GUB! Thank you very much, Dan. I did not
test the other targets yet, however.
It produces a usable lilypond installer which compiled a test example fine.


Am 11.01.2020 um 00:14 schrieb Dan Eble:

On Jan 10, 2020, at 16:21, Dan Eble mailto:d...@faithful.be>> wrote:


It seems that this implementation of the standard library declares
::isinf when  is included.  The three solutions I can think
of are (a) finish issue 4550, (b) require a version of the library
that does not do this, or (c) investigate whether it is possible to
avoid including  or any other header that triggers the same
problem.

I've been working on issue 4550.


During a much-needed dinner, the most obvious solution occurred to me,
which is to qualify the calls to std::isinf, std::isnan, etc.
everywhere.  This is a subset of issue 4550, but I'll try to add it to
the patch for issue 5658 in time for you to test tomorrow.
—
Dan

https://sourceforge.net/p/testlilyissues/issues/5658/





Re: macOS 64-bit

2020-01-11 Thread 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