Re: Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)
Thanks for the ping, it's been a long time! Sadly, I haven't used
lilypond for years. I tried to update my patch, but I cannot spend too
much time on it.
I see that my change to engraver.cc is no longer needed, as there is a
check there that was missing back at the time. The change to
engraver-scheme.cc still applies, but I see that the comments here
indicate that it's incomplete and doesn't provide much value.
I have no recollection what I was doing with ly:engraver-make-grob, so I
googled to that symbol and found an implementation of ambitus at
http://lilypond.org/doc/v2.19/Documentation/snippets/contexts-and-engravers
I replaced "Ambitus" with "Ambituus" and I see the check added in
engraver.cc being triggered ("programming error: No grob definition
found for `Ambituus’") but the segfault happens not in
ly_engraver_make_grob but in Item::spanned_rank_interval.
So I think this patch is irrelevant and can be discarded.
https://codereview.appspot.com/5715053/
Re: Move add-grob-definition from a snippet to scm/translation-functions.scm (issue 6128048)
Reviewers: dak, c_sorensen_byu.edu, Message: OK, the problem I wanted to address is to have a documented way to define new grobs. I hoped that moving add-grob-definition to a "public place" would be a good start. If it's not, sorry for the noise. Description: Move add-grob-definition from a snippet to scm/translation-functions.scm add-grob-definition should be public, as that's the "official" way to create a new grob in Scheme. Please review this at http://codereview.appspot.com/6128048/ Affected files: M input/regression/scheme-text-spanner.ly M scm/translation-functions.scm Index: input/regression/scheme-text-spanner.ly diff --git a/input/regression/scheme-text-spanner.ly b/input/regression/scheme-text-spanner.ly index c0204d55c71865f3c35ae69d28387916725b9adf..87314ec0dbcc0451fdaec8aa9a75e6c043fcb539 100644 --- a/input/regression/scheme-text-spanner.ly +++ b/input/regression/scheme-text-spanner.ly @@ -12,31 +12,6 @@ in scheme." music-event StreamEvent)) -#(define (add-grob-definition grob-name grob-entry) - (let* ((meta-entry (assoc-get 'meta grob-entry)) - (class(assoc-get 'class meta-entry)) - (ifaces-entry (assoc-get 'interfaces meta-entry))) - (set-object-property! grob-name 'translation-type? list?) - (set-object-property! grob-name 'is-grob? #t) - (set! ifaces-entry (append (case class - ((Item) '(item-interface)) - ((Spanner) '(spanner-interface)) - ((Paper_column) '((item-interface - paper-column-interface))) - ((System) '((system-interface - spanner-interface))) - (else '(unknown-interface))) -ifaces-entry)) - (set! ifaces-entry (uniq-list (sort ifaces-entry symbolindex a535497962c07b9ae8ca5d79d1faf3901d1b7e10..959ab8517e3e7cc1d9f328d75175d1ff113ff72c 100644 --- a/scm/translation-functions.scm +++ b/scm/translation-functions.scm @@ -701,3 +701,31 @@ with the subordinate symbols being interfaces." `(cons ',(car form) ,(loop (cdr form) forms)) forms))) + + +;; create grob in Scheme + +(define-public (add-grob-definition grob-name grob-entry) + (let* ((meta-entry (assoc-get 'meta grob-entry)) + (class(assoc-get 'class meta-entry)) + (ifaces-entry (assoc-get 'interfaces meta-entry))) +(set-object-property! grob-name 'translation-type? list?) +(set-object-property! grob-name 'is-grob? #t) +(set! ifaces-entry (append (case class + ((Item) '(item-interface)) + ((Spanner) '(spanner-interface)) + ((Paper_column) '((item-interface + paper-column-interface))) + ((System) '((system-interface + spanner-interface))) + (else '(unknown-interface))) + ifaces-entry)) +(set! ifaces-entry (uniq-list (sort ifaces-entry symbolhttps://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Add an example implementation of cross-staff stems (issue 5882053)
OK, I'll use make-engraver in the next revision. I guess I'll need to strip all Lilypond 2.14 compatibility stuff if this snippet is to be a part of the Lilypond documentation. I missed scheme engravers because I was looking for "\consists #" on one line, my bad. http://codereview.appspot.com/5882053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Add an example implementation of cross-staff stems (issue 5882053)
Reviewers: , Message: This is also the first use of a scheme engraver in input/regression. Description: Add an example implementation of cross-staff stems Please review this at http://codereview.appspot.com/5882053/ Affected files: A input/regression/stem-cross-staff-engraver.ly ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: simplify example for unpure-pure containers (issue 5623044)
I mean, why is this needed? \remove "Stem_engraver" Stems must be fixing the problem somehow. http://codereview.appspot.com/5623044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)
I'm not getting any interesting information: ... [/usr/local/share/lilypond/2.15.32/ly/context-mods-init.ly] [/usr/local/share/lilypond/2.15.32/ly/engraver-init.ly]] [bad.ly] Interpreting music... [/usr/local/share/lilypond/2.15.32/fonts/otf/emmentaler-20.otf] fatal error: failed files: "bad.ly" Sure, I can move the programming_error() call before scm_throw() and print whatever I want. I just want to follow the coding style of Lilypond. And the existing style is such that scm_throw() is only used twice, both for more serious errors in the input. http://codereview.appspot.com/5715053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)
There are only two calls to scm_throw in Lilypond, and I could not find out whether it should be added to engraver.cc or engraver-scheme.cc. I added it to the former so that other callers to Engraver::internal_make_grob could benefit. I could not figure out how to catch an exception. Without catching, I'm getting: GNU LilyPond 2.15.32 Processing `bad.ly' Parsing... Interpreting music... fatal error: failed files: "bad.ly" The warning "cannot create grob" is not shown, and neither is the name of the grob that caused it. I could put is before the exception, but this is different from the style on the existing code. http://codereview.appspot.com/5715053/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: simplify example for unpure-pure containers (issue 5623044)
Since nobody is interested, I'm closing this issue. http://codereview.appspot.com/5623044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Fix crash when unknown grob name is passed to ly:engraver-make-grob (issue 5715053)
Reviewers: ,
Message:
I've seen it many times that Lilypond would crash during my experiments
with Scheme code. This time I decided to track it down. It's my first
ever fix to the C++ code in Lilypond, so please check my coding style.
Description:
Fix crash when unknown grob name is passed to ly:engraver-make-grob
Please review this at http://codereview.appspot.com/5715053/
Affected files:
M lily/engraver-scheme.cc
M lily/engraver.cc
Index: lily/engraver-scheme.cc
diff --git a/lily/engraver-scheme.cc b/lily/engraver-scheme.cc
index
8789171d7eafdd640c573c5b19cbd46ee3685102..bfc40f613cab8928f383f9a383c9e0b76d87fb51
100644
--- a/lily/engraver-scheme.cc
+++ b/lily/engraver-scheme.cc
@@ -35,7 +35,13 @@ LY_DEFINE
(ly_engraver_make_grob, "ly:engraver-make-grob",
internal_make_grob (grob_name, cause,
ly_symbol2string (grob_name).c_str (),
"scheme", 0, "scheme");
- return g->self_scm ();
+ if (g)
+return g->self_scm ();
+ else
+{
+ programming_error ("cannot create grob");
+ return SCM_EOL;
+}
}
LY_DEFINE (ly_engraver_announce_end_grob, "ly:engraver-announce-end-grob",
Index: lily/engraver.cc
diff --git a/lily/engraver.cc b/lily/engraver.cc
index
b8bf1234c04d625fe36c635c38aa3bad1a24c85b..e0da6d96e8dc042c9c38f0c0a37eff8a81abd75c
100644
--- a/lily/engraver.cc
+++ b/lily/engraver.cc
@@ -118,6 +118,8 @@ Engraver::internal_make_grob (SCM symbol,
#endif
SCM props = updated_grob_properties (context (), symbol);
+ if (props == SCM_EOL)
+return 0;
Grob *grob = 0;
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc: simplify example for unpure-pure containers (issue 5623044)
To be honest, there are many things I don't understand. In fact, I
reduced the example to understand it better.
Why is horizontal spacing affected even though the purity affects the
Y-axis only? Why do stems fix the spacing? Why doesn't this cause the
spacing problem:
\override NoteHead #'text = \markup { "o" }
\override NoteHead #'stencil = #ly:text-interface::print
But this does cause the problem:
\override NoteHead #'text = \markup { "o" }
\override NoteHead #'stencil =
#(lambda (grob) (ly:text-interface::print grob))
Cannot it happen a simple change would make Lilypond recognize lambda
expressions as pure functions, breaking this example? Maybe I removed
some future-proofing?
Perhaps some answers to those questions could be used to improve the
documentation.
http://codereview.appspot.com/5623044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: simplify example for unpure-pure containers (issue 5623044)
Reviewers: ,
Message:
The example could be much simpler and still show the problem being
addressed by the unpure-pure containers.
Description:
Doc: simplify example for unpure-pure containers
Use of ly:event-property only confuses matters. Squares are never used.
Draw circles unconditionally, make them empty inside (which would make
the wrong output easier to discern) and name the macros roundNotes and
smartRoundNotes. No need to define a separate Scheme function, a
one-line lambda in stencil definition is enough.
Don't remove Stem_engraver, just use whole notes and adjust the time
signature.
Please review this at http://codereview.appspot.com/5623044/
Affected files:
M Documentation/notation/changing-defaults.itely
Index: Documentation/notation/changing-defaults.itely
diff --git a/Documentation/notation/changing-defaults.itely
b/Documentation/notation/changing-defaults.itely
index
68aa8b8c4943a78b3d9a247d26679f991cc8d8b1..7fa9f19f80d9f5cc8b8972f90a08419d99dbcc11
100644
--- a/Documentation/notation/changing-defaults.itely
+++ b/Documentation/notation/changing-defaults.itely
@@ -3752,32 +3752,26 @@ value which is then used for fine-tuning much later
during the spacing
process.
@lilypond[verbatim,quote,ragged-right]
-#(define (square-line-circle-space grob)
-(let* ((pitch (ly:event-property (ly:grob-property grob 'cause) 'pitch))
- (notename (ly:pitch-notename pitch)))
- (if (= 0 (modulo notename 2))
- (make-circle-stencil 0.5 0.0 #t)
- (make-filled-box-stencil '(0 . 1.0)
- '(-0.5 . 0.5)
-
-squareLineCircleSpace = {
- \override NoteHead #'stencil = #square-line-circle-space
+roundNotes = {
+ \override NoteHead #'stencil =
+ #(lambda (grob) (make-circle-stencil 0.5 0.1 #f))
}
-smartSquareLineCircleSpace = {
- \squareLineCircleSpace
+smartRoundNotes = {
+ \roundNotes
\override NoteHead #'Y-extent =
#(ly:make-unpure-pure-container
ly:grob::stencil-height
(lambda (grob start end) (ly:grob::stencil-height grob)))
}
-\new Voice \with { \remove "Stem_engraver" }
+\new Voice
\relative c'' {
- \squareLineCircleSpace
- cis4 ces cisis c
- \smartSquareLineCircleSpace
- cis4 ces cisis c
+ \time 4/1
+ \roundNotes
+ cis1 ces cisis c
+ \smartRoundNotes
+ cis1 ces cisis c
}
@end lilypond
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Typo fixes (issue 5622049)
Just let me know which files should be left untouched and I'll submit the patch without changes to those files. http://codereview.appspot.com/5622049/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Typo fixes (issue 5622049)
Reviewers: ,
Message:
Too bad I only reviewed the "unpure-pure containers" documentation
(issue 2040) after it was committed.
Description:
Typo fixes
Fix unneeded "ll" in "canceled", "canceling" and "labeled". Replace
"and" with "an" in the documentation about unpure-pure containers.
Please review this at http://codereview.appspot.com/5622049/
Affected files:
M Documentation/contributor/issues.itexi
M Documentation/hu/learning/fundamental.itely
M Documentation/learning/fundamental.itely
M Documentation/music-glossary.tely
M Documentation/nl/learning/fundamental.itely
M Documentation/notation/changing-defaults.itely
M input/regression/cue-clef.ly
M lily/dynamic-engraver.cc
M scm/music-functions.scm
Index: Documentation/contributor/issues.itexi
diff --git a/Documentation/contributor/issues.itexi
b/Documentation/contributor/issues.itexi
index
86976fd3242f450e6f3da96f91e78b2551f0702c..2316f95855d30eebde70d21afd1c44797b7f5640
100644
--- a/Documentation/contributor/issues.itexi
+++ b/Documentation/contributor/issues.itexi
@@ -672,7 +672,7 @@ Performance: performance issue.
If you particularly want to add a label not in the list, go
ahead, but this is not recommended, except when an issue is marked
-as fixed. In this case it should be labelled fixed_mm_MM_ss,
+as fixed. In this case it should be labeled fixed_mm_MM_ss,
where mm is major version, MM minor version and ss current
release.
Index: Documentation/hu/learning/fundamental.itely
diff --git a/Documentation/hu/learning/fundamental.itely
b/Documentation/hu/learning/fundamental.itely
index
3004a17d0c65183bbdec36144dcfa053ec4341f6..2dc6fd71a966461fa7c9f25e1327313093c17fb6
100644
--- a/Documentation/hu/learning/fundamental.itely
+++ b/Documentation/hu/learning/fundamental.itely
@@ -1864,7 +1864,7 @@ is specified, no error message is produced, but the
expected
action will not take place. For example, the
@code{instrumentName} clearly lives in the @code{Staff} context, since
it is the staff that is to be named.
-In this example the first staff is labelled, but not the second,
+In this example the first staff is labeled, but not the second,
because we omitted the context name.
@lilypond[quote,verbatim,ragged-right]
Index: Documentation/learning/fundamental.itely
diff --git a/Documentation/learning/fundamental.itely
b/Documentation/learning/fundamental.itely
index
03eb7a2332548b4572148bab70c5f1190b848d05..423f6ee41f5e50a8c764baba1b86ec19dbc30e37
100644
--- a/Documentation/learning/fundamental.itely
+++ b/Documentation/learning/fundamental.itely
@@ -1714,7 +1714,7 @@ is specified, no error message is produced, but the
expected
action will not take place. For example, the
@code{instrumentName} clearly lives in the @code{Staff} context, since
it is the staff that is to be named.
-In this example the first staff is labelled, but not the second,
+In this example the first staff is labeled, but not the second,
because we omitted the context name.
@lilypond[quote,verbatim,ragged-right]
Index: Documentation/music-glossary.tely
diff --git a/Documentation/music-glossary.tely
b/Documentation/music-glossary.tely
index
b2df038dc722d5ec91047f054db0d7c9e0ccfe1f..ce41f4ec7d593b1ee11a222191162d3c8c69d8ab
100644
--- a/Documentation/music-glossary.tely
+++ b/Documentation/music-glossary.tely
@@ -5882,7 +5882,7 @@ or bracket) to indicate that the music is to be
played in a different octave:
For longer passages, it may be more practical to mark the octave change at
the
beginning with a phrase (see the list below for examples), but without a
bracket
or extender line. Then, when the music returns to the written pitch, the
octave
-change is cancelled with the word @notation{loco} (q.v.).
+change is canceled with the word @notation{loco} (q.v.).
To parallel the list above:
Index: Documentation/nl/learning/fundamental.itely
diff --git a/Documentation/nl/learning/fundamental.itely
b/Documentation/nl/learning/fundamental.itely
index
9f33f9a1da8a6d04ac36fa84b829813df72a6a6c..7c4e50896e39ca3a4c415bb51d68ff396e921ade
100644
--- a/Documentation/nl/learning/fundamental.itely
+++ b/Documentation/nl/learning/fundamental.itely
@@ -1736,7 +1736,7 @@ is specified, no error message is produced, but the
expected
action will not take place. For example, the
@code{instrumentName} clearly lives in the @code{Staff} context, since
it is the staff that is to be named.
-In this example the first staff is labelled, but not the second,
+In this example the first staff is labeled, but not the second,
because we omitted the context name.
@lilypond[quote,verbatim,ragged-right]
Index: Documentation/notation/changing-defaults.itely
diff --git a/Documentation/notation/changing-defaults.itely
b/Documentation/notation/changing-defaults.itely
index
68aa8b8c4943a78b3d9a247d26679f991cc8d8b1..1db53e061fdde7efb5039453b770738ea32ec668
100644
--- a/Documentation/notation/changing-defaults.itely
+++ b/Documen
Re: changes.tely: mention Flag changes, remove duplicate "does" (issue 5540058)
On 2012/01/18 15:13:47, Neil Puttock wrote: http://codereview.appspot.com/5540058/diff/3003/Documentation/changes.tely Done http://codereview.appspot.com/5540058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
changes.tely: mention Flag changes, remove duplicate "does" (issue 5540058)
Reviewers: ,
Message:
The changelog doesn't mention the issue I have to deal with all the
time, namely splitting Flag from Stem. If not that change, I would be
able to use Lilypond 2.14.2 and the development version without
convert-ly on the same sources. It should definitely be mentioned. An
example is added to show how the flag can be colored now.
Also, there was a duplicate "does" in the section about grace notes.
Description:
changes.tely: mention Flag changes, remove duplicate "does"
Please review this at http://codereview.appspot.com/5540058/
Affected files:
M Documentation/changes.tely
Index: Documentation/changes.tely
diff --git a/Documentation/changes.tely b/Documentation/changes.tely
index
50f2022cb29c087161107d3d1c074a52f692e37e..ef61eaeb8866ada482cdd598d33cc32572fe1cba
100644
--- a/Documentation/changes.tely
+++ b/Documentation/changes.tely
@@ -208,9 +208,16 @@ c4_\< c c^\> c c1_\p
@item
+Flags are now treated as separate objects rather than as stem parts.
+@lilypond[fragment,quote,relative=2]
+\override Flag #'color = #red g8
+@end lilypond
+
+
+@item
Appoggiaturas and acciaccaturas now also work inside a slur, not only
inside
a phrasing slur. Also, a function @code{\slashedGrace} was added that does
-does not use a slur from the acciaccatura note.
+not use a slur from the acciaccatura note.
@lilypond[fragment,quote,relative=2]
c4( \appoggiatura e8 d4 \acciaccatura e8 d4 \slashedGrace e8 c4)
@end lilypond
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Docs: Explain the difference between ritardando and rallentando (issue 5544075)
Reviewers: ,
Message:
The description for rallentando only said that it's an Italian word.
Provide better descriptions for ritardando and rallentando, contrast
them to each other and add references in both directions.
Description:
Docs: Explain the difference between ritardando and rallentando
Please review this at http://codereview.appspot.com/5544075/
Affected files:
M Documentation/music-glossary.tely
Index: Documentation/music-glossary.tely
diff --git a/Documentation/music-glossary.tely
b/Documentation/music-glossary.tely
index
5f113dda908f83874e7e4ff89ba346948dde190d..b2df038dc722d5ec91047f054db0d7c9e0ccfe1f
100644
--- a/Documentation/music-glossary.tely
+++ b/Documentation/music-glossary.tely
@@ -6644,7 +6644,10 @@ DK: rallentando,
S: rallentando,
FI: rallerdando, hidastuen.
-[Italian] A performance indication, abbreviated @notation{rall.}
+[Italian: @q{slowing down}]
+
+Slackening in speed, more gradual than @ref{ritardando}. Abbreviated
+to @notation{rall.}
@seealso
@ref{ritardando}.
@@ -6770,11 +6773,13 @@ DK: ritardando,
S: ritardando,
FI: ritardando, hidastuen,
-Gradually slackening in speed. Mostly abbreviated to @notation{rit.} or
-@notation{ritard}.
+[Italian: @q{lagging}]
+
+Gradual slowing down, more pronounced than @ref{rallentando}. Mostly
+abbreviated to @notation{rit.} or @notation{ritard}.
@seealso
-No cross-references.
+@ref{rallentando}.
@node ritenuto
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: changes.tely: mention Flag changes, remove duplicate "does" (issue 5540058)
OK, my mistake, I didn't read the comments on top of changes.tely. The fixed patch is attached as patch set 2. http://codereview.appspot.com/5540058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc search: update to version 2.15, use it in the "site:" part (issue 5530043)
I don't think I can close this. I see gray "Can't Edit" over "Publish+Mail Comments". I tried adding my gnu.org address as an alias in gmail but it changed nothing. Sorry for not being able to participate more in the discussion! http://codereview.appspot.com/5530043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Doc search: update to version 2.15, use it in the "site:" part (issue 5530043)
I totally share your sentiment, but we depend on an external entity here, which we cannot control. Suppose we go from 2.15.x to 2.17.x and put the documentation under "v2.17". For some time, Google won't have the new location in its index, so the search would get nothing. It would be better to keep "v2.15" in the search for a while and have a redirection from "v2.15" to "v2.17". Speaking of redirections, I would prefer that Lilypond had just two versions of its documentation online - latest "stable" and latest "development". "v2.12" and "v2.14" shoould redirect to "stable", "v2.15" should redirect to "development". That would solve the issue with hardcoded version numbers and keep Google happy. http://codereview.appspot.com/5530043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
