Re: Drop undocumented lilymidi and lilysong (issue 571250043 by jonas.hahnf...@gmail.com)
LGTM, thanks. https://codereview.appspot.com/571250043/
Re: Issue 5621: Improve rehearsal mark position at beginning of staff. (issue 553290043 by lemzw...@googlemail.com)
See https://codereview.appspot.com/547340043/ . Looks promising, thanks! https://codereview.appspot.com/553290043/
Re: Issue 5621: Improve rehearsal mark position at beginning of staff (issue 547340043 by nine.fierce.ball...@gmail.com)
One early comment :-) https://codereview.appspot.com/547340043/diff/575390044/lily/break-alignment-interface.cc File lily/break-alignment-interface.cc (right): https://codereview.appspot.com/547340043/diff/575390044/lily/break-alignment-interface.cc#newcode328 lily/break-alignment-interface.cc:328: Break_alignable_interface::self_alignment_cis_breakable (SCM grob) Well, the cis–trans pairing is IMHO only understandable for people who have a Latin background (or come from Austria, since it was divided into »Cisleithanien« and »Transleithanien« in the K. und K. era)... As nice as it is, I suggest that you find names that are easier to comprehend for other people. https://codereview.appspot.com/547340043/
Re: Issue 5621: Improve rehearsal mark position at beginning of staff. (issue 553290043 by lemzw...@googlemail.com)
On 2019/12/14 22:42:05, dak wrote: A callback function, if necessary due to early evaluation otherwise, a pure/unpure container ? See https://codereview.appspot.com/547340043/ . https://codereview.appspot.com/553290043/
Drop undocumented lilymidi and lilysong (issue 571250043 by jonas.hahnf...@gmail.com)
See: https://sourceforge.net/p/testlilyissues/issues/1245/ This is the state of festival. https://codereview.appspot.com/571250043/
Re: Perception of LilyPond development status
Urs Liska writes: > Any LilyPond dev who does have a Facebook account might have a look at > this interesting, although somewhat sad, discussion. I think it gives > a clear picture of how our current state of development is perceived > by users: > > https://www.facebook.com/groups/gnulilypond/permalink/10157762793383529/ The problem with the "obsolete version of Guile" is that Guile development is falling apart. The only person actually working on the development version of Guile is Andy Wingo. He does not participate on the Guile developer list, he does not bother with bug reports, he does not take input and does whatever he currently is interested in without communicating it, and frequently breaking master. What he is interested in is basically compiler/optimization development. He is not interested in fixing the performance and design problems with Guile 2+'s string implementation and design. There are about a dozen developers (probably less by now) cleaning up on the stable branch, but they cannot do significant independent development since they cannot coordinate with the development version. This has been the case for 2.2, and it's more so for 2.3. I don't see that there is a viable way for LilyPond to move forward to "current" versions of Guile which have become completely unpredictable as a target as well as as a platform. I think there will not be much of a way around forking 1.8 and making that work for us as long as no well-performing string-interface is available that would efficiently facilitate the C/Scheme string passing density of LilyPond. Maybe we can coordinate something with Thien-Thi Nguyen who has been keeping the Guile-1.8 branch tip in the official Guile repository from bitrot due to Texinfo and language changes. -- David Kastrup
Re: Issue 5621: Improve rehearsal mark position at beginning of staff. (issue 553290043 by lemzw...@googlemail.com)
nine.fierce.ball...@gmail.com writes: > On 2019/12/14 16:47:15, Dan Eble wrote: >> I think it would be better for a RehearsalMark to be center-aligned at > a bar >> line, but left-aligned at a key signature or clef (maybe generalized > to anything >> with break-align-anchor-alignment = RIGHT?). I don't know if it's > currently >> possible to define that, but it's probably worth thinking through what > it would >> require. > > I'm on a path to making this possible. I don't know if I'll have > anything to show today; if not, perhaps Monday. > > https://codereview.appspot.com/553290043/ A callback function, if necessary due to early evaluation otherwise, a pure/unpure container ? -- David Kastrup
Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)
> On 14 Dec 2019, at 09:54, lemzwerg--- via Discussions on LilyPond development
> wrote:
>
> LGTM, thanks!
>
> https://codereview.appspot.com/553310045/
>
The C++11 range for statement is nice too, if the iterator self is not
addressed. For example, in beam.cc:
for (auto& s: stems) {
Interval positions = Stem::head_positions(s);
…
}
Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)
On 2019/12/14 18:23:08, lilypond_de-wolff.org wrote: Great job, one remark: Although the patch for ly/music-functions-init.ly is a good patch, I do not think it should be part of this patch-set. Jaap It's part of the commit titled "comments." What do you suggest I do instead? https://codereview.appspot.com/553310045/
Re: Issue 5621: Improve rehearsal mark position at beginning of staff. (issue 553290043 by lemzw...@googlemail.com)
On 2019/12/14 16:47:15, Dan Eble wrote: I think it would be better for a RehearsalMark to be center-aligned at a bar line, but left-aligned at a key signature or clef (maybe generalized to anything with break-align-anchor-alignment = RIGHT?). I don't know if it's currently possible to define that, but it's probably worth thinking through what it would require. I'm on a path to making this possible. I don't know if I'll have anything to show today; if not, perhaps Monday. https://codereview.appspot.com/553290043/
Re: Issue 5621: Improve rehearsal mark position at beginning of staff. (issue 553290043 by lemzw...@googlemail.com)
On 2019/12/14 16:47:15, Dan Eble wrote: I think it would be better for a RehearsalMark to be center-aligned at a bar line, but left-aligned at a key signature or clef (maybe generalized to anything with break-align-anchor-alignment = RIGHT?). I don't know if it's currently possible to define that, but it's probably worth thinking through what it would require. What might work is a new option (possibly made the default?) for self-alignment-X that uses the opposite of the reference grob's break-align-anchor-alignment. https://codereview.appspot.com/553290043/
Perception of LilyPond development status
Any LilyPond dev who does have a Facebook account might have a look at this interesting, although somewhat sad, discussion. I think it gives a clear picture of how our current state of development is perceived by users: https://www.facebook.com/groups/gnulilypond/permalink/10157762793383529/ Urs
Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)
> On 14 Dec 2019, at 13:07, d...@gnu.org wrote: > > I don't want to get your enthusiasm up prematurely, but I think that the > GUB GCC versions we need(?)/use for PowerPC might not be entirely great > with C++11 though they'll likely support it when given explicitly on the > command line. From what I recall, GCC never supported C++11 as default, but skipped directly to C++14, which is the current default. The implementation of C++11 was long and troublesome, and would be better to avoid if possible on earlier compilers.
RE: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)
Great job, one remark: Although the patch for ly/music-functions-init.ly is a good patch, I do not think it should be part of this patch-set. Jaap
Re: Issue 5621: Improve rehearsal mark position at beginning of staff. (issue 553290043 by lemzw...@googlemail.com)
Doesn't this shift _everything_ that one might try to align relative to a clef, not just rehearsal marks? What about key signatures? The break-align-symbols for RehearsalMark are (staff-bar key-signature clef). This change won't do anything for the alignment of a rehearsal mark that attaches itself to a key signature. I think it would be better for a RehearsalMark to be center-aligned at a bar line, but left-aligned at a key signature or clef (maybe generalized to anything with break-align-anchor-alignment = RIGHT?). I don't know if it's currently possible to define that, but it's probably worth thinking through what it would require. https://codereview.appspot.com/553290043/
Re: Patchy email
David Kastrup writes: > Knut Petersen writes: > >> On 26.07.19 20:36, David Kastrup wrote: >>> Unless Knut is also running patchy now that he has commit access (and perhaps didn't have a clean master?). (I don't want to cast aspersions, but it might be a genuine mistake if it was Knut). Knut? >>> I rather doubt that it was Knut since I mentioned the procedures to him >>> right now and you said that you pushed the patch in question anyway (so >>> it's very unlikely that he'd run the patchy subsequently responsible for >>> promoting it to master). >> I never used patchy. According to my memories and according to my logs >> pushing the commits to staging was done right and successful. >> >> But yes, there is a local branch master on my system. I never thought that >> there is a clone of the lilypond repository without a local master as >> >>git clone git://git.sv.gnu.org/lilypond.git >> >> >> clones the repository and checks out 'master'. Sorry for the mess. >> >> It's clear that 7583351fbf2f08a4d1f3f0b075fe8b691adc0b95 needs >> to be fixed. >> >> What happened to the musicxml2ly patch? It vanished from staging. >> Shall I push it again? > > It didn't pass patchy testing on my computer with failures in the > musicxml files. So it appears to have a problem with, uh, Python > 2.7.16+ (according to python --version on my current Ubuntu). If you > need more pointers, I can try getting useful logs. 20 weeks delay for a mail to reach the list must be some sort of record. Good thing that I had Knut in Cc. -- David Kastrup
Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)
On 2019/12/14 10:18:33, hahnjo wrote: Fabulous, thanks for putting this together! I don't want to get your enthusiasm up prematurely, but I think that the GUB GCC versions we need(?)/use for PowerPC might not be entirely great with C++11 though they'll likely support it when given explicitly on the command line. So extensive changes may require several rebases/merges/rewrites before we are ready to put them into mainline (we don't have a separate GUB for post-2.19 work). Or we just say "to heck with it" and just assume that we don't run across bad C++11 support. That being said, one obvious contender for C++11 might be the std::vector class which we still double currently, and I think part of the reason may be that the data() member function is not guaranteed to be present before C++11. Because of the merge/rebase thing, I don't know how much of a good idea it would be to tackle this now, but it's certainly something worth doing once we are all-in on C++11. https://codereview.appspot.com/553310045/
Fix regtests about Footnote (issue 549320043 by thomasmorle...@gmail.com)
Reviewers: ,
Description:
Fix regtests about Footnote
Several regtest about FootnoteItem/Spanner contained overrides
without specifying the context.
Footnote_engraver lives in Score-context, though. Thus the
Score-context is added to the overrides in:
input/regression/footnote-auto-numbering-vertical-order.ly
input/regression/footnote-auto-numbering.ly
input/regression/footnote-spanner.ly
input/regression/in-note.ly
Regtest-diffs are expected.
Please review this at https://codereview.appspot.com/549320043/
Affected files (+17, -17 lines):
M input/regression/footnote-auto-numbering.ly
M input/regression/footnote-auto-numbering-vertical-order.ly
M input/regression/footnote-spanner.ly
M input/regression/in-note.ly
Index: input/regression/footnote-auto-numbering-vertical-order.ly
diff --git a/input/regression/footnote-auto-numbering-vertical-order.ly
b/input/regression/footnote-auto-numbering-vertical-order.ly
index
a7c86686eafeb6330b3e2588b8bb06eb5d38805f..780d8f2c3c22d8c2220577f3c047861ffad02436
100644
--- a/input/regression/footnote-auto-numbering-vertical-order.ly
+++ b/input/regression/footnote-auto-numbering-vertical-order.ly
@@ -30,28 +30,28 @@ in the correct vertical order.
<<
\new Staff \relative {
d'4 e
-\once \override FootnoteItem.numbering-assertion-function =
+\once \override Score.FootnoteItem.numbering-assertion-function =
#(lambda (grob) (make-footnote-numbering-assertion-function 0))
< f \footnote #'(1 . -1) \markup { n } a c >
-\once \override FootnoteSpanner.numbering-assertion-function =
+\once \override Score.FootnoteSpanner.numbering-assertion-function
=
#(simultaneous-footnote-numbering-assertion-function 2 4)
a8-\footnote #'(1 . 1) \markup { p } \<
-\footnote #'(1 . 1) \markup { o } [ b c d ] a4 b c\f |
d a b c |\break
d,4 e
-\once \override FootnoteItem.numbering-assertion-function =
+\once \override Score.FootnoteItem.numbering-assertion-function =
#(lambda (grob) (make-footnote-numbering-assertion-function 6))
< f \footnote #'(1 . -1) \markup { n } a c >
-\once \override FootnoteSpanner.numbering-assertion-function =
+\once \override Score.FootnoteSpanner.numbering-assertion-function
=
#(simultaneous-footnote-numbering-assertion-function 8 10)
a8-\footnote #'(1 . 1) \markup { p } \<
-\footnote #'(1 . 1) \markup { o } [ b c d ] a4 b c |
d a b c\f |\pageBreak
d,4 e
-\once \override FootnoteItem.numbering-assertion-function =
+\once \override Score.FootnoteItem.numbering-assertion-function =
#(lambda (grob) (make-footnote-numbering-assertion-function 12))
< f \footnote #'(1 . -1) \markup { n } a c >
-\once \override FootnoteSpanner.numbering-assertion-function =
+\once \override Score.FootnoteSpanner.numbering-assertion-function
=
#(simultaneous-footnote-numbering-assertion-function 14 16)
a8-\footnote #'(1 . 1) \markup { p } \<
-\single\footnote #'(1 . 1) \markup { o } Beam [ b c d ] a4 b c |
@@ -59,28 +59,28 @@ in the correct vertical order.
}
\new Staff \relative {
d'4 e
-\once \override FootnoteItem.numbering-assertion-function =
+\once \override Score.FootnoteItem.numbering-assertion-function =
#(lambda (grob) (make-footnote-numbering-assertion-function 1))
< f \footnote #'(1 . -1) \markup { n } a c >
-\once \override FootnoteSpanner.numbering-assertion-function =
+\once \override Score.FootnoteSpanner.numbering-assertion-function
=
#(simultaneous-footnote-numbering-assertion-function 3 5)
a8-\single\footnote #'(1 . 1) \markup { p } Hairpin \<
-\footnote #'(1 . 1) \markup { o } [ b c d ] a4 b c\f |
d a b c |\break
d,4 e
-\once \override FootnoteItem.numbering-assertion-function =
+\once \override Score.FootnoteItem.numbering-assertion-function =
#(lambda (grob) (make-footnote-numbering-assertion-function 7))
< f \footnote #'(1 . -1) \markup { n } a c >
-\once \override FootnoteSpanner.numbering-assertion-function =
+\once \override Score.FootnoteSpanner.numbering-assertion-function
=
#(simultaneous-footnote-numbering-assertion-function 9 11)
a8-\footnote #'(1 . 1) \markup { p } \<
-\footnote #'(1 . 1) \markup { o } [ b c d ] a4 b c |
d a b c\f |\pageBreak
d,4 e
-\once \override FootnoteItem.numbering-assertion-function =
+\once \override Score.FootnoteItem.numbering-assertion-function =
#(lambda (grob) (make-footnote-numbering-assertion-function 13))
< f \footnote #'(1 . -1) \markup { n } a c >
-\once \override FootnoteSpanner.numbering-assertion-function =
+\once \override
Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)
Fabulous, thanks for putting this together! https://codereview.appspot.com/553310045/
Re: Issue 5639: compile with -std=c++11 (issue 553310045 by nine.fierce.ball...@gmail.com)
LGTM, thanks! https://codereview.appspot.com/553310045/
