Re: lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
LGTM. Carl http://codereview.appspot.com/5553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: lilypond-book: Fix links in texinfo output (issue 2224). (issue 5557056)
LGTM Thanks, Julien! Carl http://codereview.appspot.com/5557056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Makes sure dynamics don't budge for tuplet brackets. (issue 5555046)
LGTM
If you run it through fixcc.py we won't get the trailing whitespace
warning.
http://codereview.appspot.com/046/diff/1/lily/tuplet-bracket.cc
File lily/tuplet-bracket.cc (right):
http://codereview.appspot.com/046/diff/1/lily/tuplet-bracket.cc#newcode660
lily/tuplet-bracket.cc:660: {
blanks
http://codereview.appspot.com/046/diff/1/lily/tuplet-bracket.cc#newcode668
lily/tuplet-bracket.cc:668:
blanks
http://codereview.appspot.com/046/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-book: Fix links in texinfo output (issue 2224). (issue 5557056)
Reviewers: Reinhold,
Message:
Please review.
Description:
lilypond-book:
Fix links in texinfo output (issue 2224).
Also, specify filename and ext for all snippets.
Please review this at http://codereview.appspot.com/5557056/
Affected files:
M python/book_snippets.py
M python/book_texinfo.py
Index: python/book_snippets.py
diff --git a/python/book_snippets.py b/python/book_snippets.py
index
e5a43110ffa268ae6733d09e7c96dc768503ef61..7e5e94686352fd413148dc7f01eabf7ca64c3f50
100644
--- a/python/book_snippets.py
+++ b/python/book_snippets.py
@@ -329,6 +329,8 @@ class IncludeSnippet (Snippet):
class LilypondSnippet (Snippet):
def __init__ (self, type, match, formatter, line_number,
global_options):
Snippet.__init__ (self, type, match, formatter, line_number,
global_options)
+self.filename = ''
+self.ext = '.ly'
os = match.group ('options')
self.parse_snippet_options (os, self.type)
@@ -651,7 +653,10 @@ printing diff against existing file." % filename)
def additional_files_to_consider (self, base, full):
return []
def additional_files_required (self, base, full):
-return []
+result = [];
+if self.ext != '.ly':
+result.append (base + self.ext)
+return result
def all_output_files (self, output_dir, output_dir_files):
@@ -803,7 +808,6 @@ class LilypondFileSnippet (LilypondSnippet):
def __init__ (self, type, match, formatter, line_number,
global_options):
LilypondSnippet.__init__ (self, type, match, formatter,
line_number, global_options)
self.filename = self.substring ('filename')
-self.ext = os.path.splitext (os.path.basename (self.filename))[1]
self.contents = file (BookBase.find_file (self.filename,
global_options.include_path,
global_options.original_dir)).read ()
@@ -838,6 +842,7 @@ class MusicXMLFileSnippet (LilypondFileSnippet):
LilypondFileSnippet.__init__ (self, type, match, formatter,
line_number, global_options)
self.compressed = False
self.converted_ly = None
+self.ext = os.path.splitext (os.path.basename (self.filename))[1]
self.musicxml_options_dict = {
'verbose': '--verbose',
'lxml': '--lxml',
@@ -881,14 +886,6 @@ class MusicXMLFileSnippet (LilypondFileSnippet):
return ('\\sourcefilename \"%s\"\n\\sourcefileline 0\n%s'
% (name, self.converted_ly))
-def additional_files_required (self, base, full):
-result = [];
-if self.compressed:
-result.append (base + '.mxl')
-else:
-result.append (base + '.xml')
-return result
-
def write_ly (self):
base = self.basename ()
path = os.path.join (self.global_options.lily_output_dir, base)
Index: python/book_texinfo.py
diff --git a/python/book_texinfo.py b/python/book_texinfo.py
index
ca9ee31754f84dfe6adfd57d510dc2c292577957..234092ee4b2fed204d53e98629a4ae6335d63fa8
100644
--- a/python/book_texinfo.py
+++ b/python/book_texinfo.py
@@ -114,7 +114,7 @@ TexInfo_output = {
OUTPUTIMAGE: r'''@noindent
@ifinfo
-@image{%(info_image_path)s,,,%(alt)s,%(ext)s}
+@image{%(info_image_path)s,,,%(alt)s,}
@end ifinfo
@html
@@ -313,19 +313,17 @@ class BookTexinfoOutputFormat
(BookBase.BookOutputFormat):
def output_info (self, basename, snippet):
str = ''
rep = snippet.get_replacements ();
+rep['base'] = basename
+rep['filename'] = os.path.basename (snippet.filename)
+rep['ext'] = snippet.ext
for image in snippet.get_images ():
rep1 = copy.copy (rep)
-(rep1['base'], rep1['ext']) = os.path.splitext (image)
+rep1['base'] = os.path.splitext (image)[0]
rep1['image'] = image
-
-# URG, makeinfo implicitly prepends dot to extension.
-# Specifying no extension is most robust.
-rep1['ext'] = ''
rep1['alt'] = snippet.option_dict[ALT]
rep1['info_image_path'] = os.path.join
(self.global_options.info_images_dir, rep1['base'])
str += self.output[OUTPUTIMAGE] % rep1
-rep['base'] = basename
str += self.output[OUTPUT] % rep
return str
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-book: Group line-width settings together (issue 2222). (issue 5553056)
Reviewers: Reinhold,
Message:
Please review.
Description:
lilypond-book:
Group line-width settings together (issue ).
Also, specify filename and ext for all snippets.
Please review this at http://codereview.appspot.com/5553056/
Affected files:
M python/book_snippets.py
Index: python/book_snippets.py
diff --git a/python/book_snippets.py b/python/book_snippets.py
index
e5a43110ffa268ae6733d09e7c96dc768503ef61..127453d6afa6f79c9c84db7e6792926f9001a8f0
100644
--- a/python/book_snippets.py
+++ b/python/book_snippets.py
@@ -109,11 +109,19 @@ snippet_options = {
},
##
+# TODO: Remove the 1mm additional padding in the line-width
+# once lilypond creates tighter cropped images!
PAPER: {
PAPERSIZE: r'''#(set-paper-size "%(papersize)s")''',
INDENT: r'''indent = %(indent)s''',
-LINE_WIDTH: r'''line-width = %(line-width)s''',
-QUOTE: r'''line-width = %(line-width)s - 2.0
* %(exampleindent)s''',
+LINE_WIDTH: r'''line-width = %(line-width)s
+ %% offset the left padding, also add 1mm as lilypond creates cropped
+ %% images with a little space on the right
+ line-width = #(- line-width (* mm %(padding_mm)f) (* mm 1))''',
+QUOTE: r'''line-width = %(line-width)s - 2.0 * %(exampleindent)s
+ %% offset the left padding, also add 1mm as lilypond creates cropped
+ %% images with a little space on the right
+ line-width = #(- line-width (* mm %(padding_mm)f) (* mm 1))''',
RAGGED_RIGHT: r'''ragged-right = ##t''',
NORAGGED_RIGHT: r'''ragged-right = ##f''',
},
@@ -164,8 +172,6 @@ def classic_lilypond_book_compatibility (key, value):
return (None, None)
-# TODO: Remove the 1mm additional padding in the line-width, once lilypond
-# creates tighter cropped images!
PREAMBLE_LY = ''' Generated by %(program_name)s
Options: [%(option_string)s]
\\include "lilypond-book-preamble.ly"
@@ -179,9 +185,6 @@ PREAMBLE_LY = ''' Generated by %(program_name)s
\paper {
%(paper_string)s
- %% offset the left padding, also add 1mm as lilypond creates cropped
- %% images with a little space on the right
- line-width = #(- line-width (* mm %(padding_mm)f) (* mm 1))
}
\layout {
@@ -329,6 +332,8 @@ class IncludeSnippet (Snippet):
class LilypondSnippet (Snippet):
def __init__ (self, type, match, formatter, line_number,
global_options):
Snippet.__init__ (self, type, match, formatter, line_number,
global_options)
+self.filename = ''
+self.ext = '.ly'
os = match.group ('options')
self.parse_snippet_options (os, self.type)
@@ -498,6 +503,7 @@ class LilypondSnippet (Snippet):
override[EXAMPLEINDENT] = r'0.4\in'
override[LINE_WIDTH] = '5\\in'
override.update (self.formatter.default_snippet_options)
+override['padding_mm'] = self.global_options.padding_mm
option_string = ','.join (self.get_outputrelevant_option_strings
())
compose_dict = {}
@@ -651,7 +657,10 @@ printing diff against existing file." % filename)
def additional_files_to_consider (self, base, full):
return []
def additional_files_required (self, base, full):
-return []
+result = [];
+if self.ext != '.ly':
+result.append (base + self.ext)
+return result
def all_output_files (self, output_dir, output_dir_files):
@@ -803,7 +812,6 @@ class LilypondFileSnippet (LilypondSnippet):
def __init__ (self, type, match, formatter, line_number,
global_options):
LilypondSnippet.__init__ (self, type, match, formatter,
line_number, global_options)
self.filename = self.substring ('filename')
-self.ext = os.path.splitext (os.path.basename (self.filename))[1]
self.contents = file (BookBase.find_file (self.filename,
global_options.include_path,
global_options.original_dir)).read ()
@@ -838,6 +846,7 @@ class MusicXMLFileSnippet (LilypondFileSnippet):
LilypondFileSnippet.__init__ (self, type, match, formatter,
line_number, global_options)
self.compressed = False
self.converted_ly = None
+self.ext = os.path.splitext (os.path.basename (self.filename))[1]
self.musicxml_options_dict = {
'verbose': '--verbose',
'lxml': '--lxml',
@@ -881,14 +890,6 @@ class MusicXMLFileSnippet (LilypondFileSnippet):
return ('\\sourcefilename \"%s\"\n\\sourcefileline 0\n%s'
% (name, self.converted_ly))
-def additional_files_required (self, base, full):
-result = [];
-if self.compressed:
-result.append (base + '.mxl')
-else:
-result.append (base + '.xml')
-return result
-
def write_ly (self):
base = self.basename ()
path = os.path.join (self.global_options.lily_output_dir, base)
___
lilypond-devel mailing list
lilypond-d
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
Makes sure dynamics don't budge for tuplet brackets. (issue 5555046)
LGTM http://codereview.appspot.com/046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
Le 17/01/2012 21:31, Graham Percival disait : On Tue, Jan 17, 2012 at 08:24:35PM +, janek.lilyp...@gmail.com wrote: could we change this (and other similar) prefix so that it doesn't contain a slash? I mean, change dev/ to dev- or something like that. The slash confused me a lot, because it's also used to separate a remote name from the branch name, like in origin/master. I'm sure that if we will adopt "dev/blahblah" naming, many people will mistakenly believe that "dev" is something like "origin", and they will be very confused. Good point! I like it. Thanks to git-completion, I don't have to type the 20 characters when switching off/to our translators' branch... and got used to it. Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements rhythmic-music-iterator (issue 5554048)
The tuplet-iterator.cc has a process method that uses similar logic as that above: it does parts of what the report_music function does, because as you correctly state, the function does very little. LGTM - if you can, please adopt this patch so that you can coordinate getting it and others connected to it into the source. http://codereview.appspot.com/5554048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements rhythmic-music-iterator (issue 5554048)
On 2012/01/18 15:55:35, dak wrote:
On 2012/01/18 15:28:42, http://mike_apollinemike.com wrote:
> I don't think there's a risk that one engraver in a context will get
a
different
> version of an event than another engraver in a context. This would
require
the
> NoteEvent to be reported more than once.
It would merely require using the same music expression more than once
without
copying it. Music expressions are frontend material. I am not really
comfortable messing with them. Now it is true that if you put stuff
in a music
variable and access this using \var, you get a copy. And music
functions in
general are not expected to worry about stomping over their arguments
destructively because of that.
But I still have a hard time believing that every Music variable is
guaranteed
to never have anybody ever look at it again once it has been seen by
an iterator
once.
No need to mess with virtual functions actually since this is all inside
of the rhythmic iterator (one could override the report function
non-virtually, but there is little point since it does almost nothing).
The following puts together all of the collected stuff.
void
Rhythmic_music_iterator::process (Moment m)
{
if (last_processed_mom_ < Moment (0))
{
descend_to_bottom_context ();
Stream_event *ev = get_music ()->to_event ();
SCM arts = ev->get_property ("articulations");
Context *c = get_outlet ();
if (scm_is_pair (arts))
{
ev->set_property ("articulations", SCM_EOL);
c->event_source ()->broadcast (ev);
for (; scm_is_pair (arts); arts = scm_cdr (arts))
c->event_source ()->broadcast (unsmob_stream_event (scm_car
(arts)));
}
else
c->event_source ()->broadcast (ev);
ev->unprotect ();
}
Simple_music_iterator::process (m);
}
http://codereview.appspot.com/5554048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements rhythmic-music-iterator (issue 5554048)
On 2012/01/18 15:28:42, mike_apollinemike.com wrote: I don't think there's a risk that one engraver in a context will get a different version of an event than another engraver in a context. This would require the NoteEvent to be reported more than once. It would merely require using the same music expression more than once without copying it. Music expressions are frontend material. I am not really comfortable messing with them. Now it is true that if you put stuff in a music variable and access this using \var, you get a copy. And music functions in general are not expected to worry about stomping over their arguments destructively because of that. But I still have a hard time believing that every Music variable is guaranteed to never have anybody ever look at it again once it has been seen by an iterator once. http://codereview.appspot.com/5554048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc#newcode284
lily/stem.cc:284: string style = robust_symbol2string
(heads[0]->get_property ("style"), "default");
A bit fussy. You can safely check the symbol without converting to a
string.
SCM style = heads[0]->get_property ("style");
return style != ly_symbol2scm ("kievan") && ...
http://codereview.appspot.com/4951062/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements rhythmic-music-iterator (issue 5554048)
On Jan 18, 2012, at 3:53 PM, d...@gnu.org wrote: > Where would be the point? If I plan to touch up the stream event before > broadcasting it, I can't use the everything-included report_event > anyway. If I plan to touch up the music event in a manner equivalent to > deleting the articulations, I can just delete the articulations instead. > In either case, the original music event would behave differently after > having once visited the iterator. > I don't think there's a risk that one engraver in a context will get a different version of an event than another engraver in a context. This would require the NoteEvent to be reported more than once. This is why I don't think setting articulations to SCM_EOL will matter. Have you had the chance to apply my patch set along with your work to see if it works? Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements rhythmic-music-iterator (issue 5554048)
On 2012/01/18 14:53:28, dak wrote: Then rhythmic_iterator could just override it. Better yet, EventChord could just override it, and we would not need the rhythmic iterator at all. Well, it is not really "better yet" since the current case is the simple and straightforward one, so it should be the music iterator default. So I guess I'll see whether I can fudge this into the Rhythmic iterator after all. http://codereview.appspot.com/5554048/ ___ 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)
http://codereview.appspot.com/5540058/diff/3003/Documentation/changes.tely File Documentation/changes.tely (right): http://codereview.appspot.com/5540058/diff/3003/Documentation/changes.tely#newcode67 Documentation/changes.tely:67: \override Flag #'color = #red g8 Please put the note on a new line. http://codereview.appspot.com/5540058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements rhythmic-music-iterator (issue 5554048)
On 2012/01/18 14:36:57, MikeSol wrote: On 2012/01/18 14:27:53, dak wrote: > Are iterators allowed to change their input? I'm not sure if they're allowed by design, but I know they're allowed to proliferate input that wasn't there before. I don't know what you mean by "proliferate input" as this verb is intransitive. If you mean generating new input: sure. I am worried by it changing the input. If it gets iterated in a different context again, information will be gone. One solution is to just set a property in the event "ignore-articulations". Where would be the point? If I plan to touch up the stream event before broadcasting it, I can't use the everything-included report_event anyway. If I plan to touch up the music event in a manner equivalent to deleting the articulations, I can just delete the articulations instead. In either case, the original music event would behave differently after having once visited the iterator. So I guess I'll take your patch and just do a bit of copying of what report_event does. It is pretty much equivalent to my messing around with an additional optional boolean argument to report_event, but less hidden. Perhaps it would be cleanest to make report_event a virtual function? Then rhythmic_iterator could just override it. Better yet, EventChord could just override it, and we would not need the rhythmic iterator at all. http://codereview.appspot.com/5554048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements rhythmic-music-iterator (issue 5554048)
On 2012/01/18 14:27:53, dak wrote:
http://codereview.appspot.com/5554048/diff/5001/lily/rhythmic-music-iterator.cc
File lily/rhythmic-music-iterator.cc (right):
http://codereview.appspot.com/5554048/diff/5001/lily/rhythmic-music-iterator.cc#newcode42
lily/rhythmic-music-iterator.cc:42: get_music ()->set_property
("articulations",
SCM_EOL);
I am not actually comfortable with clearing articulations in the
original music
event rather than its eventized copy.
Are iterators allowed to change their input?
I'm not sure if they're allowed by design, but I know they're allowed to
proliferate input that wasn't there before.
One solution is to just set a property in the event
"ignore-articulations". That way, when the new-fingering-engraver gets
the event, it can check if this is set before it touches articulations.
http://codereview.appspot.com/5554048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements rhythmic-music-iterator (issue 5554048)
http://codereview.appspot.com/5554048/diff/5001/lily/rhythmic-music-iterator.cc
File lily/rhythmic-music-iterator.cc (right):
http://codereview.appspot.com/5554048/diff/5001/lily/rhythmic-music-iterator.cc#newcode42
lily/rhythmic-music-iterator.cc:42: get_music ()->set_property
("articulations", SCM_EOL);
I am not actually comfortable with clearing articulations in the
original music event rather than its eventized copy.
Are iterators allowed to change their input?
http://codereview.appspot.com/5554048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implements rhythmic-music-iterator (issue 5554048)
Reviewers: dak, http://codereview.appspot.com/5554048/diff/2001/lily/rhythmic-music-iterator.cc File lily/rhythmic-music-iterator.cc (right): http://codereview.appspot.com/5554048/diff/2001/lily/rhythmic-music-iterator.cc#newcode41 lily/rhythmic-music-iterator.cc:41: report_event (get_music ()); On 2012/01/18 13:38:39, dak wrote: I suppose that one has to clear "articulations" here (after fetching them), or they will get treated by both report_event as well as the rhythmic iterator. Good call. A new patch set is up that fixes this. It adds some extra verbage, but it makes sure that: a) Notes are reported without their articulations; and b) Articulations are reported after notes. This should prevent the new-fingering-engraver from seeing the articulations. Furthermore, given the way that the music stream currently looks, articulations are placed after notes in an event chord. In theory this shouldn't matter, but in case it does, this puts the loop after the first report_event. Description: Implements rhythmic-music-iterator Please review this at http://codereview.appspot.com/5554048/ Affected files: A lily/include/rhythmic-music-iterator.hh A lily/rhythmic-music-iterator.cc M scm/define-music-types.scm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build: Strict error checking from makeinfo and texi2html (issue 2219). (issue 5554043)
Have you run make doc with these changes? -- Phil Holmes I did but forgot make check, so that will delay the review some more until errors are fixed there. Thanks, Julien http://codereview.appspot.com/5554043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Implements rhythmic-music-iterator (issue 5554048)
http://codereview.appspot.com/5554048/diff/2001/lily/rhythmic-music-iterator.cc File lily/rhythmic-music-iterator.cc (right): http://codereview.appspot.com/5554048/diff/2001/lily/rhythmic-music-iterator.cc#newcode41 lily/rhythmic-music-iterator.cc:41: report_event (get_music ()); I suppose that one has to clear "articulations" here (after fetching them), or they will get treated by both report_event as well as the rhythmic iterator. Since it would be awkward to actually mess with the Music event, one will likely not be able to call report_event, but instead call to_event, and then take the articulations from there. As a result, one would not be calling report_event in the loop either. And one would likely have to descend_to_context (and other report_event stuff) manually. http://codereview.appspot.com/5554048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Doc: NR Update section on Footnotes (issue 5543064)
LGTM http://codereview.appspot.com/5543064/ ___ 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)
LGTM http://codereview.appspot.com/5540058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
Francisco Vila writes: >>> It would seem that rerunning scripts/auxiliar/update-with-convert-ly.sh >>> after merging the translation might have fixed that problem this time. >>> >>> I am not sure it would work in all such cases. >>> >>> I don't have a better suggestion than doing a test run before pushing a >>> translation merge. >> >> You are right. I tested in a system and pushed from another. That made >> the mess. Sorry. >> >> Now testing again. > > I have patched Staging but still testing. I have cherry-picked your patch to the HEAD of lilypond/translation, repeated the merge, and rebased staging on the results. Let's hope that this was all. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Broadcast articulations not in EventChord (issue 5528111)
Reviewers: MikeSol,
Message:
On 2012/01/17 17:42:38, MikeSol wrote:
I would advise not handling it this way - the function to_event is
supposed to
take music and return an event. In this patch, it is taking music,
returning an
event, and maybe broadcasting music and/or sending it to a context.
I'd recommend creating a new iterator, rhythmic-music-iterator, that
inherits
from Simple_music_iterator.
I have reduced the impact on strange areas: it is now just
send_to_context and its caller report_event that take an optional
argument changing the behavior.
I don't see how a rhythmic-music-iterator would help here since the
rhythmic events need to get handled either way, whether they are called
inside of an EventChord or not. The problem is that the _default_
behavior of articulations needs to be that they just get _removed_ from
events and broadcast in parallel. Only inside of EventChord are they
allowed to stay associated with the individual event carrying them.
That's the way things work currently. It is just that this unwrapping
and parallel broadcasting is currently wired into the parser, where
_everything_ gets wrapped in an EventChord (except when it isn't, like
inside of a chord), just in two different manners depending on whether
we are in-chord or not.
So if we are not wrapping non-chord notes in EventChord, this difference
needs to get established elsewhere if the input is to retain its
meaning. And that means the default behavior needs to be unwrapping,
while EventChord refrains from it.
I don't see that a rhythmic-music-iterator would help since it gets to
play at a time when the distinction of EventChord-or-not must already
have had its effect.
Description:
Broadcast articulations not in EventChord
This is in preparation for issue 2070.
Should not cause any differences in output with current parser.
Please review this at http://codereview.appspot.com/5528111/
Affected files:
M lily/event-chord-iterator.cc
M lily/include/music-iterator.hh
M lily/include/music.hh
M lily/music-iterator.cc
M lily/music.cc
Index: lily/event-chord-iterator.cc
diff --git a/lily/event-chord-iterator.cc b/lily/event-chord-iterator.cc
index
899287a0036b4ccdf78a0c6638bd56254f40..015385a0559ddae265db490d3faec4141286b177
100644
--- a/lily/event-chord-iterator.cc
+++ b/lily/event-chord-iterator.cc
@@ -47,7 +47,7 @@ Event_chord_iterator::process (Moment m)
scm_is_pair (s); s = scm_cdr (s))
{
Music *mus = unsmob_music (scm_car (s));
- report_event (mus);
+ report_event (mus, true);
}
for (SCM s = get_music ()->get_property ("events");
scm_is_pair (s); s = scm_cdr (s))
Index: lily/include/music-iterator.hh
diff --git a/lily/include/music-iterator.hh b/lily/include/music-iterator.hh
index
a34e3009037120f66baeeda9104d27a753ffe43a..490b64380f61fd53476b2aed648035a1870288bf
100644
--- a/lily/include/music-iterator.hh
+++ b/lily/include/music-iterator.hh
@@ -72,7 +72,7 @@ public:
Moment music_get_length () const;
Moment music_start_mom () const;
Music_iterator ();
- void report_event (Music *);
+ void report_event (Music *, bool keep_articulations = false);
Context *get_outlet () const;
void set_context (Context *);
static SCM get_static_get_iterator (Music *mus);
Index: lily/include/music.hh
diff --git a/lily/include/music.hh b/lily/include/music.hh
index
83cc5ff4c3148a4add8d1c7b165bc46a0bfe8829..e194b8fafbffcf66c3ecab0e536e6e96f4c944e1
100644
--- a/lily/include/music.hh
+++ b/lily/include/music.hh
@@ -55,7 +55,7 @@ public:
void compress (Moment factor);
// Broadcast the event in a context's event-source.
- void send_to_context (Context *c);
+ void send_to_context (Context *c, bool keep_articulations = false);
DECLARE_SCHEME_CALLBACK (duration_length_callback, (SCM));
Index: lily/music-iterator.cc
diff --git a/lily/music-iterator.cc b/lily/music-iterator.cc
index
c076b7ad65867e9e9b3cdb9266ae0748c1dd7586..ee6dcfa730d9a207f4964162135e650b9e478691
100644
--- a/lily/music-iterator.cc
+++ b/lily/music-iterator.cc
@@ -170,7 +170,7 @@ Music_iterator::descend_to_bottom_context ()
}
void
-Music_iterator::report_event (Music *m)
+Music_iterator::report_event (Music *m, bool keep_articulations)
{
descend_to_bottom_context ();
@@ -180,7 +180,7 @@ Music_iterator::report_event (Music *m)
if (!m->is_mus_type ("event"))
m->origin ()->programming_error ("Sending non-event to context");
- m->send_to_context (get_outlet ());
+ m->send_to_context (get_outlet (), keep_articulations);
}
IMPLEMENT_CTOR_CALLBACK (Music_iterator);
Index: lily/music.cc
diff --git a/lily/music.cc b/lily/music.cc
index
d8609ace96e2e6b56af077898edc1b0e7284a859..7aaae452a9d6af02814bacf11b96d7663b6d4b57
100644
--- a/lily/music.cc
+++ b/lily/music.cc
@@ -306,10 +306,23 @@ Music::to_event () const
}
void
-Music::send_to_context (Context *c)
+Music::send_to_context (Context *c, bool kee
Re: Broadcast articulations not in EventChord (issue 5528111)
I still think this patch goes outside the model of the way these things are usually designed in LilyPond. I'm not saying that LilyPond's design paradigm is objectively good or bad (I truly have no idea, as I know nothing about any other piece of software), but I think it's best to follow it whenever possible. Currently, this patch is making a modification to music-iterator, the base class from which all others inherit. Normally, be it an iterator, engraver, or grob, whenever a new functionality is needed in LilyPond, a new X is created (where X is iterator, engraver, or grob). There are only a few rare cases where the base class has to be modified (i.e. adding color to a grob, which effects every grob). I'll send you a sketch of a patch that's more in line with the way these things are coded in the current LilyPond style. There's no guarantee that it'll work, but it'll give you an idea of how to modify this one. Cheers http://codereview.appspot.com/5528111/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
>> It would seem that rerunning scripts/auxiliar/update-with-convert-ly.sh >> after merging the translation might have fixed that problem this time. >> >> I am not sure it would work in all such cases. >> >> I don't have a better suggestion than doing a test run before pushing a >> translation merge. > > You are right. I tested in a system and pushed from another. That made > the mess. Sorry. > > Now testing again. I have patched Staging but still testing. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
2012/1/18 David Kastrup : > Culprit would be > commit 44f3e55e3c283ccfdcb32af3ba3f45ec8580ca23 > Author: Yoshiki Sawada > Date: Sun Jan 15 09:00:54 2012 +0900 > > Doc-ja: Adding and updating NR > > Doc-ja: Adding and updating NR. > > > merged in from the translation branch. > > This is somewhat unfortunate: the newly created translation refers to a > version that has been semi-fixed after a syntax change by running > scripts/auxiliar/update-with-convert-ly.sh, and corrected afterwards. > > It would seem that rerunning scripts/auxiliar/update-with-convert-ly.sh > after merging the translation might have fixed that problem this time. > > I am not sure it would work in all such cases. > > I don't have a better suggestion than doing a test run before pushing a > translation merge. You are right. I tested in a system and pushed from another. That made the mess. Sorry. Now testing again. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
Graham Percival writes: > On Wed, Jan 18, 2012 at 02:20:09AM -0800, > lilypond.patchy.gra...@gmail.com wrote: >> *** FAILED BUILD *** >> >> nice make doc -j3 CPU_COUNT=3 >> >> Previous good commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117 >> >> Current broken commit: b667b7fe1bf651b7373014204edbe0e68f17326e > > > /main/large-tmp/lilypond-autobuild/build/out/lybook-db/d5/lily-6e11c268.ly:1115:4: > error: unknown escaped string: `\autoFootnoteGrob' I'll try my merge&rebase fu on this one. It is the translation merge, and it might possibly work to rerun convert-ly. My current computer is far too slow to do a DOC rebuild in any reasonable amount of time, so I'll be pushing the result of that work unchecked, leaving that job to Patchy again. Expect an hour or so. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
Graham Percival writes: > On Wed, Jan 18, 2012 at 02:20:09AM -0800, > lilypond.patchy.gra...@gmail.com wrote: >> *** FAILED BUILD *** >> >> nice make doc -j3 CPU_COUNT=3 >> >> Previous good commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117 >> >> Current broken commit: b667b7fe1bf651b7373014204edbe0e68f17326e > > > /main/large-tmp/lilypond-autobuild/build/out/lybook-db/d5/lily-6e11c268.ly:1115:4: > error: unknown escaped string: `\autoFootnoteGrob' Culprit would be commit 44f3e55e3c283ccfdcb32af3ba3f45ec8580ca23 Author: Yoshiki Sawada Date: Sun Jan 15 09:00:54 2012 +0900 Doc-ja: Adding and updating NR Doc-ja: Adding and updating NR. merged in from the translation branch. This is somewhat unfortunate: the newly created translation refers to a version that has been semi-fixed after a syntax change by running scripts/auxiliar/update-with-convert-ly.sh, and corrected afterwards. It would seem that rerunning scripts/auxiliar/update-with-convert-ly.sh after merging the translation might have fixed that problem this time. I am not sure it would work in all such cases. I don't have a better suggestion than doing a test run before pushing a translation merge. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On 2012/01/17 21:31:01, janek wrote: http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi File Documentation/contributor/source-code.itexi (right): http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode297 Documentation/contributor/source-code.itexi:297: git branch dev/cg There is one possible downside of tracking master explicitly (if i understand correctly how this works): if someone makes a mistake and calls 'git push' while being on local branch which tracks master, this would result in commits pushed to master. Not quite. "git push" pushes all tracking branches with a name that is the same in the local repository as well as in the remote repository. So if you have a local branch "master" tracking origin/master, this will get pushed upstream when saying "git push" even if the currently checked-out branch is a different one. I only push with explicit branch specifications for that reason. Got bitten more than once. http://codereview.appspot.com/5539062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
On Wed, Jan 18, 2012 at 02:20:09AM -0800, lilypond.patchy.gra...@gmail.com wrote: > *** FAILED BUILD *** > > nice make doc -j3 CPU_COUNT=3 > > Previous good commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117 > > Current broken commit: b667b7fe1bf651b7373014204edbe0e68f17326e /main/large-tmp/lilypond-autobuild/build/out/lybook-db/d5/lily-6e11c268.ly:1115:4: error: unknown escaped string: `\autoFootnoteGrob' - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2100: Explanation of branches for CG (issue 5539062)
Janek Warchoł writes: > 2012/1/17 Graham Percival : >>> http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode297 >>> Documentation/contributor/source-code.itexi:297: git branch dev/cg >>> I think it would be good to be verbose, because it will give people more >>> information about using git (and they won't have to ask certain >>> questions). In this case i would suggest >>> >>> git branch dev/cg --track origin/master >> >> But we don't want it to track origin/master, do we? People should >> merge from master manually (covered in this section). > > If i understand git manual correctly, --track only tells git from > which remote branch it should pull. It doesn't tell git to pull > automatically. Yes. > I've created a branch with --track, i'll see if anything happens to it > automatically. When you check out the branch, git tells you something like "Your branch is xxx commits ahead of ...". Nothing happens to the branch, but you get informational stuff like that sometimes. >> ... but *this* confuses me. How can git switch to a remote branch? >> Aren't all branches local? I mean, whenever you switch to a >> "remote" branch, doesn't that just create a local copy of the remote >> branch, then put you on that local branch? > > Yes, i think it works like that (and still these are called "remote > branches"). My wording was misleading. It does not really work like that. When you checkout a remote branch, you get put on a detached HEAD. Whatever you do will get lost (except from your repository's reflog) when you switch to another branch. git checkout origin is the same as git checkout origin~0 In either case, what you do subsequently has no reference except the current HEAD. It's scratch pad work. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patchy email
lilypond.patchy.gra...@gmail.com writes: > Begin LilyPond compile, commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117 > > Merged staging, now at: b667b7fe1bf651b7373014204edbe0e68f17326e > > Success:./autogen.sh --noconfigure > > Success:../configure --disable-optimising > > Success:nice make clean -j3 CPU_COUNT=3 > > Success:nice make -j3 CPU_COUNT=3 > > Success:nice make test -j3 CPU_COUNT=3 > > *** FAILED BUILD *** > > nice make doc -j3 CPU_COUNT=3 > > Previous good commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117 > > Current broken commit: b667b7fe1bf651b7373014204edbe0e68f17326e Possibly stale dependencies: diff --git a/lily/column-description.cc b/lily/column-description.cc deleted file mode 100644 index 20ecc75..000 --- a/lily/column-description.cc +++ /dev/null Maybe we should have a separate target for removing them. I can't vouch that this is the problem: I just glanced over the diff, and that was what caught my eye. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Patchy email
Begin LilyPond compile, commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117 Merged staging, now at: b667b7fe1bf651b7373014204edbe0e68f17326e Success:./autogen.sh --noconfigure Success:../configure --disable-optimising Success:nice make clean -j3 CPU_COUNT=3 Success:nice make -j3 CPU_COUNT=3 Success:nice make test -j3 CPU_COUNT=3 *** FAILED BUILD *** nice make doc -j3 CPU_COUNT=3 Previous good commit: 11cf086eaba246f043d553a8bafcdbf1b47b9117 Current broken commit: b667b7fe1bf651b7373014204edbe0e68f17326e ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build: Strict error checking from makeinfo and texi2html (issue2219). (issue 5554043)
- Original Message - From: To: Cc: ; Sent: Tuesday, January 17, 2012 11:13 PM Subject: Build: Strict error checking from makeinfo and texi2html (issue2219). (issue 5554043) Reviewers: , Description: Build: Strict error checking from makeinfo and texi2html (issue 2219). Run makeinfo and texi2html with --error-limit=0. Please review this at http://codereview.appspot.com/5554043/ Affected files: M make/doc-i18n-root-vars.make M stepmake/stepmake/texinfo-vars.make Index: make/doc-i18n-root-vars.make diff --git a/make/doc-i18n-root-vars.make b/make/doc-i18n-root-vars.make index 8c20f494bde0106e624edd30e2a9c140267dcd84..654969ea9536b3fdcc29b53da983026a56eef7fa 100644 --- a/make/doc-i18n-root-vars.make +++ b/make/doc-i18n-root-vars.make @@ -31,7 +31,7 @@ DOCUMENTATION_INCLUDES = \ -I $(top-build-dir)/Documentation/$(outdir) LILYPOND_BOOK_INCLUDES += $(DOCUMENTATION_INCLUDES) -MAKEINFO_FLAGS += --force --enable-encoding $(DOCUMENTATION_INCLUDES) +MAKEINFO_FLAGS += --enable-encoding $(DOCUMENTATION_INCLUDES) MAKEINFO = LANG= $(MAKEINFO_PROGRAM) $(MAKEINFO_FLAGS) # texi2html xref map files Index: stepmake/stepmake/texinfo-vars.make diff --git a/stepmake/stepmake/texinfo-vars.make b/stepmake/stepmake/texinfo-vars.make index 2f2d801ab1210e1bc784306df498c5e84d5b553f..d16e7d63a3319d4f9587a149c0e83f5287a3f1c2 100644 --- a/stepmake/stepmake/texinfo-vars.make +++ b/stepmake/stepmake/texinfo-vars.make @@ -33,7 +33,7 @@ TEXINFO_PAPERSIZE_OPTION= $(if $(findstring $(PAPERSIZE),a4),,-t @afourpaper) DOCUMENTATION_INCLUDES += -I $(top-src-dir)/Documentation -MAKEINFO_FLAGS += --enable-encoding $(DOCUMENTATION_INCLUDES) +MAKEINFO_FLAGS += --enable-encoding --error-limit=0 $(DOCUMENTATION_INCLUDES) MAKEINFO = LANG= $(MAKEINFO_PROGRAM) $(MAKEINFO_FLAGS) # texi2html xref map files @@ -53,7 +53,7 @@ TEXI2HTML_INIT --init-file=$(top-src-dir)/Documentation/lilypond-texi2html.ini TEXI2HTML_SPLIT = --prefix=index --split=section TEXI2HTML_INCLUDES += --I=$(src-dir) --I=$(outdir) $(DOCUMENTATION_INCLUDES) --I=$(XREF_MAPS_DIR) -TEXI2HTML_FLAGS += $(TEXI2HTML_INCLUDES) $(TEXI2HTML_INIT) $(TEXI2HTML_LANG) +TEXI2HTML_FLAGS += --error-limit=0 $(TEXI2HTML_INCLUDES) $(TEXI2HTML_INIT) $(TEXI2HTML_LANG) TEXI2HTML = TOP_SRC_DIR=$(top-src-dir) PERL_UNICODE=SD $(TEXI2HTML_PROGRAM) ### Have you run make doc with these changes? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
