Menu
▾
▴
1 Attachments
#673 problem with order of \consists
Originally created by: *anonymous
Originally created by: lemzw...@googlemail.com
Originally owned by: tdanielsmusic
\version "2.11.56"
\header { texidoc = "
The order of engravers and translators specified with @code{\consists}
should be irrelevant.
Here is a counterexample.
" }
\layout
{
\context {
\Score
\remove "Default_bar_line_engraver"
\remove "Timing_translator"
}
\context {
\Staff
\consists "Default_bar_line_engraver"
\consists "Timing_translator"
}
}
\relative {
c4 c c c |
}
Originally posted by: hanw...@gmail.com
I don't understand the point of this report. The interpretation system is inherently
sequential, and therefore ordering of engreavers within a context matters,
unfortunately. Maybe you mean something else, but i'm not sure what.
Status: Invalid
Originally posted by: lemzw...@googlemail.com
I mean exactly this. In case the order is important, it should be documented
accordingly. In particular, it is not obvious at all that the above have to be
ordered, and it is not fun to find this out the hard way. Are there any guides on
this topic?
I changed this report to be a documentation bug.
Labels: -Type-Defect Type-Documentation
Status: Accepted
Originally posted by: gpermus@gmail.com
Sounds fair. This is too specific for LM 6, but it definitely belongs in NR 3.
If you could suggest exactly where, and write some sample text, Trevor can add it
much faster than he would otherwise.
Originally posted by: lemzw...@googlemail.com
If Han-Wen (or someone else) can give me pointers, I could write this.
Originally posted by: hanw...@gmail.com
What pointers are you looking for exacltly?
Context *
Context_def::instantiate (SCM ops)
is the function that creats the context with its list of engravers. The order does
not matter, except in some special cases (which I can't remember from the top of my
head), where
- one engraver writes a property, and the other reads it (probably what happened here)
- one engraver creates a grob, and another must catch it before the catch-all case is
reached. Some of these are doc'ed in ly/engraver-init.ly
%% must come before Script_column_engraver.
\consists "New_fingering_engraver"
Originally posted by: lemzw...@googlemail.com
(No comment was entered for this change.)
Labels: -Priority-Medium Priority-Low
Originally posted by: pkx1...@hotmail.com
On 27/04/2010 13:38, Kieren MacMillan wrote:
> Hi Graham and James:
>
>> James is ready, but you don't need to send an actual patch.
>
> Reviewing the situation, I'm not sure I *need* to send a patch: the Learning [!!] page
>
> <http://lilypond.org/doc/v2.13/Documentation/learning/adding-and-removing-engravers#Adding-and-removing-engravers>
>
> has a link at the bottom to the Notation page
>
> <http://lilypond.org/doc/v2.13/Documentation/notation/modifying-context-plug_002dins>
>
> which, in turn, has the clear and helpful note
>
> "Usually the order in which the engravers are specified does not matter, but in a few special cases the order is important, for example where one engraver writes a property and another reads it, or where one engraver creates a grob and another must process it. The order in which the engravers are specified is the order in which they are called to carry out their processing.
>
> The following orderings are important: the Bar_engraver must normally be first, and the New_fingering_engraver must come before the Script_column_engraver. There may be others with ordering dependencies."
>
> So what should we add to either page to make it clearer?
>
> Thanks,
> Kieren.
Originally posted by: pkx1...@hotmail.com
On 27/04/2010 14:04, Graham Percival wrote:
> Talking about
> https://code.google.com/p/lilypond/issues/detail?id=673
> problem with order of \consists
>
>
> On Tue, Apr 27, 2010 at 1:38 PM, Kieren MacMillan
> <kieren_macmillan@sympatico.ca> wrote:
>> Reviewing the situation, I'm not sure I *need* to send a patch: the Learning [!!] page
>>
>> <http://lilypond.org/doc/v2.13/Documentation/learning/adding-and-removing-engravers#Adding-and-removing-engravers>
>>
>> has a link at the bottom to the Notation page
>>
>> <http://lilypond.org/doc/v2.13/Documentation/notation/modifying-context-plug_002dins>
>>
>> which, in turn, has the clear and helpful note
>>
>> "Usually the order in which the engravers are specified does not matter, but in a few special cases the order is important, for example where one engraver writes a property and another reads it, or where one engraver creates a grob and another must process it. The order in which the engravers are specified is the order in which they are called to carry out their processing.
>>
>> The following orderings are important: the Bar_engraver must normally be first, and the New_fingering_engraver must come before the Script_column_engraver. There may be others with ordering dependencies."
>>
>> So what should we add to either page to make it clearer?
>
> Don't change anything on the Learning page.
>
> For the Notation page, there's four options:
>
> 1) Add a sentence about default_bar_line_engraver and
> timing_translator (or whatever Werner was talking about on 673). I
> know we've already said "there order may matter; here's one example,
> but there may be others", but we might as well list this case since it
> came up.
>
> 2) Do some trawling through the IR and/or code (as per Han-Wen's
> comment 5 in the issue) and try to discover all dependency chains of
> engravers, then list all those in Notation. If you go to this much
> effort, we might as well make a separate section (well,
> unnumberedsubsubsec) in the docs for these dependency chains.
>
> 3) Do #1, but put it in a new unnumberedsubsubsec for better visibility.
>
> 4) Pester some code people into adding "this context/engraver depends
> on context/engravers foo band bar" into the code documentation, such
> that this info will automatically get into the IR. Oh, maybe modify
> the IR-generation functions to read this new info.
>
> umm, in doxygen terms, I'm thinking of something like
> \depends
> but I don't know offhand how this might fit into the IR-generation stuff.
>
>
> hmm... I'm thinking that we should do 3, then add 4 to the tracker. 4
> could be a fantastic project for a Frog that was thinking about
> improving the IR... it's a relatively small change, and frankly
> relatively unimportant (so it doesn't matter if it doesn't get done
> for 2 years), but OTOH it forces them to learn a lot about the
> IR-generation routines. If there's ever any serious effort to improve
> the IR (and I know people have been talking about this for years),
> then this makes a good "first hurdle" so we can see whether people are
> willing to "walk the walk" instead of just talking. :)
>
>
> At this stage, I think the doc change is up to you, Kieren: you've
> done at least 100 times as much IR-reading / tweaking as I have, so I
> value your opinion on this stuff more than my own. Decide whether you
> want #1, 2, or 3 (after waiting for potential comments), then email
> the new text to James.
>
> James: we haven't talked about adding new unnumberedsubsubsec yet, but
> this is a good time to do it since it's not urgent.
>
>
> For #4, we'll wait for comments (or immediate offers of help, haha),
> and then add it to the tracker as a postponed item.
>
> Cheers,
> - Graham
>
Originally posted by: pkx1...@gmail.com
(No comment was entered for this change.)
Labels: -Priority-Low
Originally posted by: jakob.be...@gmail.com
How about this text for the Notation page at
http://lilypond.org/doc/v2.15/Documentation/notation/modifying-context-plug_002dins
"Note that the order of the \consits specifications is important in this example; the Default_bar_line_engraver must be specified *after* the Timing_translator in order for the former to be able to place the bar lines correctly."
and then, the very last paragraph changed to
"Other than the example above, the following orderings are important: the Bar_engraver must normally be first, and the New_fingering_engraver must come before the Script_column_engraver. There may be others with ordering dependencies."
Originally posted by: lemzw...@googlemail.com
I'm worried by the `there may be others with ordering dependencies'. Ideally, the dependency order gets computed automatically since everything else is essentially documentation nightmare. What about adding a `must-come-after' documentation property to the engraver definitions themselves? This could then be simply emitted in the `internals' reference.
Originally posted by: tdanielsmusic
There are no more dependencies mentioned in ly/engraver-init.ly
than the ones already mentioned in the Known issues and the one
Werner noted. I don't think this needs any more effort expending
than to add this extra one to the warning. Perhaps we could point
to ly/engraver-init.ly and suggest people follow the ordering of
contexts they see there, just in case there are dependencies,
but I think even this is a step too far.
@Werner: if you want to push for the change to the engraver definitions
I suggest you open a new issue for this. Discovering if there are
any more dependencies is a major task requiring someone to go through
all the engraver code looking for them.
I'll wait a day or two for comments; if there are none I'll make the
simple doc change I propose and close this issue.
Owner: tdanielsmusic
Status: Started
Originally posted by: tdanielsmusic
Doc: Order of engravers within context matters (673)
Mention all known cases where the order matters.
Information taken from comments in ly/engraver-init.ly.
http://codereview.appspot.com/6448063
Labels: Patch-new
Originally posted by: lemzw...@googlemail.com
I think a reference to engraver-init.ly is fine. Thanks for the patch.
Originally posted by: ColinPKC...@gmail.com
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-countdown
Originally posted by: ColinPKC...@gmail.com
Counted down to 20120731, please push.
Labels: -Patch-countdown Patch-push
Originally posted by: tdanielsmusic
Pushed to staging as
[r47abfd11dbf3902963836c42db1c38a7137af16e]
Labels: -Patch-push Fixed_2_15_42
Status: Fixed
Originally posted by: Elu...@gmail.com
(No comment was entered for this change.)
Status: Verified