Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm File scm/bar-line.scm (right): http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm#newcode225 scm/bar-line.scm:225: (define-public bar-glyph-alist '()) This interface definition is asking for trouble. It is an important feature of LilyPond that if you use standard commands, their effects to not bleed over from one run to the next. Information-carrying data structures, for that reason, should be initialized in a .ly file loaded from init.ly. Even then, the basic data structure should be one that can be replaced by overwriting with a saved copy. That means that hash-tables have to be either read/only, or start out as _empty_ in a session (hash tables defined in the init.ly session get cleared at the end of session IIRC). http://codereview.appspot.com/6498052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On 29 sept. 2012, at 19:54, m...@mikesolomon.org wrote:
On 29 sept. 2012, at 19:53, Keith OHara k-ohara5...@oco.net wrote:
On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org
m...@mikesolomon.org wrote:
The way you're using tentative is almost exactly how pure properties are
used in LilyPond.
Specifically, 'pure-height being the estimated vertical extent before
line-breaking, while 'height is its extent after line-breaking.
If there are distinct properties to describe the position at different
stages, then each property can be evaluated just once (as HanWen suggested,
and as Mike agreed 100%).
More thinking. I'm not enthusiastic about stages - it is a top down approach
that locks us into certain points of evaluation. What if we decided to add or
get rid of a stage? Would we need to create things like unpure-pure-containers
for various stages? What qualifies as a stage? Could users make custom stages?
Furthermore, the idea of properties being pure in LilyPond is impossible to
police. The code almost guarantees that won't be pure, as once the dim_cache_
of a grob is filled, it gives that value instead of the result of a function
call (see Grob::pure_relative_y_coordinate, specifically line 350 of grob.cc as
of 9e605a1bb6644d89cf110f20cb6d46bb0339fca7). I like Keith's idea of
tentative and permanent. The model I'm thinking of is:
--) LilyPond evaluates all callbacks as permanent unless tentative is
explicitly asked for.
--) Permanent properties are stashed in a cache that cannot be erased.
--) Tentative properties may (i.e. heights) or may not (i.e. color) be cached
depending on how we choose to optimize LilyPond. It is the responsibility of
the coder, if she wants an uncached property, to wipe the cache.
--) Most importantly, all notions of pure callbacks disappear. It is the job
of functions to police themselves. For example, a function Grob::has_full_x
can be created to determine if a grob has an X position with respect to the
system. It'd check to see if the dim_cache_[X_AXIS].offset_ of a Paper_column
pointing to a real location in memory. The answer will be false if
System::break_into_pieces has been called and true otherwise. Then, we could
do something like:
MAKE_SCHEME_CALLBACK_WITH_OPTARGS (Slur, height, 1, 2, );
SCM
Slur::height (SCM smob, SCM begscm, SCM endscm)
{
Grob *me = unsmob_grob (smob);
if (me-has_full_x ())
return permanent_height (me);
int beg = robust_scm2int (begscm, 0);
int end = robust_scm2int (endscm, 0);
return tentative_height (me, beg, end);
}
This'd allow to entirely get rid of all the pure callback lists as well as
unpure-pure-containers.
--) Both permanent and tentative properties can result in calls to
set_property, set_object, translate_axis, and suicide. All setters should be
used sparingly and internally to cache values (like we do for minimum
translations, for example). We can police this via warnings and errors.
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
m...@mikesolomon.org m...@mikesolomon.org writes: On 29 sept. 2012, at 19:54, m...@mikesolomon.org wrote: On 29 sept. 2012, at 19:53, Keith OHara k-ohara5...@oco.net wrote: On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org m...@mikesolomon.org wrote: The way you're using tentative is almost exactly how pure properties are used in LilyPond. Specifically, 'pure-height being the estimated vertical extent before line-breaking, while 'height is its extent after line-breaking. If there are distinct properties to describe the position at different stages, then each property can be evaluated just once (as HanWen suggested, and as Mike agreed 100%). More thinking. I'm not enthusiastic about stages - it is a top down approach that locks us into certain points of evaluation. What if we decided to add or get rid of a stage? Would we need to create things like unpure-pure-containers for various stages? What qualifies as a stage? Dependencies, I should guess. A stage is where we break circular dependencies. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Provide \hide and \omit functions for transparent and void glyphs(issue 6575048)
Werner LEMBERG w...@gnu.org writes: I prefer \single to \next. \justOne \onlyOne ? It is, in a way, a complement to \once, so I would want to avoid multiple-word approaches leading to CamelCase. Had someone already suggested \here? Yes. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
Am 30.09.2012 04:11, schrieb k-ohara5...@oco.net: Now looking at the log files, I do get undead errors for our regression test 'bar-line-define-bar-glyph.ly' but not from any other files that I tried. (I don't know why the scripts from `make check` did not flag it.) Keith, thanks for your work on this! It makes it much easier for me to see which file causes errors, especially in this case where these 'undead objects' messages seem to float around very randomly. There are four messages, but the particular undead objects vary from run to run. I can confirm that. When I compile the regtest above two times, the errors disappear. When I compile another file and the regtest afterwards, I get different messages. It looks as there are dynamics and/or articulations involved, which is strange because neither the regtest nor the files I compiled in between have anything of that kind. I must admit that I am an absolute newbie with regard to C++ debugging. Can anyone help me here? I don't know where these undead objects come from – the function (add-bar-glyph-print-procedure ...) used in the regtest is used in scm/bar-line.scm, too, and seems to cause no problems there. Regards, Marc http://codereview.appspot.com/6498052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
Am 30.09.2012 10:01, schrieb d...@gnu.org: http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm File scm/bar-line.scm (right): http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm#newcode225 scm/bar-line.scm:225: (define-public bar-glyph-alist '()) This interface definition is asking for trouble. It is an important feature of LilyPond that if you use standard commands, their effects to not bleed over from one run to the next. Information-carrying data structures, for that reason, should be initialized in a .ly file loaded from init.ly. Even then, the basic data structure should be one that can be replaced by overwriting with a saved copy. That means that hash-tables have to be either read/only, or start out as _empty_ in a session (hash tables defined in the init.ly session get cleared at the end of session IIRC). I am not sure if I understand you correctly. Do you propose that the initialisation of the alists should be moved to ly/init.ly and that's it, more or less? Regards, Marc http://codereview.appspot.com/6498052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
On 30 sept. 2012, at 10:25, Marc Hohl m...@hohlart.de wrote: Am 30.09.2012 04:11, schrieb k-ohara5...@oco.net: Now looking at the log files, I do get undead errors for our regression test 'bar-line-define-bar-glyph.ly' but not from any other files that I tried. (I don't know why the scripts from `make check` did not flag it.) Keith, thanks for your work on this! It makes it much easier for me to see which file causes errors, especially in this case where these 'undead objects' messages seem to float around very randomly. There are four messages, but the particular undead objects vary from run to run. I can confirm that. When I compile the regtest above two times, the errors disappear. When I compile another file and the regtest afterwards, I get different messages. It looks as there are dynamics and/or articulations involved, which is strange because neither the regtest nor the files I compiled in between have anything of that kind. I must admit that I am an absolute newbie with regard to C++ debugging. Can anyone help me here? I don't know where these undead objects come from – the function (add-bar-glyph-print-procedure ...) used in the regtest is used in scm/bar-line.scm, too, and seems to cause no problems there. Regards, Marc These messages are annoying...they often have to do with marking objects for garbage collection (print_smob and mark_smob functions). Given that you're not creating any new smobs in this patch, it is tough to see where things may be going wrong. You can, however, do all sorts of stuff with the message itself to get more useful info. It gets printed out in scm/lily.scm, so you can modify the printout to get more information about the object. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
Am 30.09.2012 10:01, schrieb d...@gnu.org: http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm File scm/bar-line.scm (right): http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm#newcode225 scm/bar-line.scm:225: (define-public bar-glyph-alist '()) This interface definition is asking for trouble. It is an important feature of LilyPond that if you use standard commands, their effects to not bleed over from one run to the next. Information-carrying data structures, for that reason, should be initialized in a .ly file loaded from init.ly. Even then, the basic data structure should be one that can be replaced by overwriting with a saved copy. That means that hash-tables have to be either read/only, or start out as _empty_ in a session (hash tables defined in the init.ly session get cleared at the end of session IIRC). http://codereview.appspot.com/6498052/ Update: a 'git grep (define-public .* '()) shows scm/bar-line.scm:(define-public bar-glyph-alist '()) scm/bar-line.scm:(define-public span-bar-glyph-alist '()) scm/bar-line.scm:(define-public volta-bracket-allow-volta-hook-list '()) scm/define-context-properties.scm:(define-public all-translation-properties '()) scm/define-note-names.scm:(define-public pitchnames '()) scm/lily.scm:(define-public lilypond-declarations '()) scm/midi.scm:(define-public absolute-volume-alist '()) scm/midi.scm:(define-public instrument-equalizer-alist '()) Since the faulty regtest adds a function to the list provided by (define-public bar-glyph-print-procedures `()) I assume that *this* declaration should be moved to ly/init.ly? Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
On 2012/09/30 08:33:16, marc wrote: Am 30.09.2012 10:01, schrieb d...@gnu.org: http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm File scm/bar-line.scm (right): http://codereview.appspot.com/6498052/diff/32001/scm/bar-line.scm#newcode225 scm/bar-line.scm:225: (define-public bar-glyph-alist '()) This interface definition is asking for trouble. It is an important feature of LilyPond that if you use standard commands, their effects to not bleed over from one run to the next. Information-carrying data structures, for that reason, should be initialized in a .ly file loaded from init.ly. Even then, the basic data structure should be one that can be replaced by overwriting with a saved copy. That means that hash-tables have to be either read/only, or start out as _empty_ in a session (hash tables defined in the init.ly session get cleared at the end of session IIRC). I am not sure if I understand you correctly. Do you propose that the initialisation of the alists should be moved to ly/init.ly and that's it, more or less? First, the define-public is asking for trouble. You are exposing an internal Scheme data structure to users and make it overwritable by the user. If the user follows this invitation, the effects will bleed over from session to session. Never do that. Consider _everything_ written in a .scm file as readonly conceptually. For an alist, you might want to define a _function_ returning the initial list, and the accessors should not be modifying it destructively (adding to the front of an alist does not change the original alist). Then you assign this initial value to a session variable in something included in init.ly, like #(define bar-glyph-alist (initial-bar-glyph-alist)) Your functions working with bar-glyph-alist have to take the version of bar-glyph-alist defined in the parser module. That means that when you call them from .ly files, you'll likely need to pass bar-glyph-alist from the .ly file into your Scheme function. Or get them via ly:parser-lookup via the parser variable. If you put a new bar line definition into a.ly, and when calling lilypond a.ly b.ly it is available in b.ly, then you have done something wrong. http://codereview.appspot.com/6498052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
David Kastrup d...@gnu.org writes: m...@mikesolomon.org m...@mikesolomon.org writes: On 29 sept. 2012, at 19:54, m...@mikesolomon.org wrote: On 29 sept. 2012, at 19:53, Keith OHara k-ohara5...@oco.net wrote: On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org m...@mikesolomon.org wrote: The way you're using tentative is almost exactly how pure properties are used in LilyPond. Specifically, 'pure-height being the estimated vertical extent before line-breaking, while 'height is its extent after line-breaking. If there are distinct properties to describe the position at different stages, then each property can be evaluated just once (as HanWen suggested, and as Mike agreed 100%). More thinking. I'm not enthusiastic about stages - it is a top down approach that locks us into certain points of evaluation. What if we decided to add or get rid of a stage? Would we need to create things like unpure-pure-containers for various stages? What qualifies as a stage? Dependencies, I should guess. A stage is where we break circular dependencies. Basically, a grob says I want to have this and that information for making my positioning and LilyPond says You can't get it right now. Then the grob says ok, I'll do a tentative positioning, and LilyPond will come back with more information later and ask again. Now the problem here is when we are getting oscillation or even just a converging process. If there is convergence involved, we are better off calculation the _relation_ between the positionings. In a linear optimization problem, those define the surface plane of a simplex (which has possible solutions inside, impossible solutions outside, and where we are looking for the furthest distance from 0 as the goal of optimization) as a constraint. Intersecting with other surfaces/constraints gives us the total solution space, and travelling outside along its edges (which are the intersection of two planes) moves us to the optimal solution. Doing this iteratively means jumping around on the inside of the simplex. Each jump may be quite faster than determining the active boundaries of the simplex, but of course the simplex method focuses on _those_ pairings of parameters/positioning which are actually valid tradeoffs. And since it is an efficient method, it does not get confused when the heuristics go wrong. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On 30 sept. 2012, at 11:39, David Kastrup d...@gnu.org wrote: David Kastrup d...@gnu.org writes: m...@mikesolomon.org m...@mikesolomon.org writes: On 29 sept. 2012, at 19:54, m...@mikesolomon.org wrote: On 29 sept. 2012, at 19:53, Keith OHara k-ohara5...@oco.net wrote: On Sat, 29 Sep 2012 10:30:32 -0700, m...@mikesolomon.org m...@mikesolomon.org wrote: The way you're using tentative is almost exactly how pure properties are used in LilyPond. Specifically, 'pure-height being the estimated vertical extent before line-breaking, while 'height is its extent after line-breaking. If there are distinct properties to describe the position at different stages, then each property can be evaluated just once (as HanWen suggested, and as Mike agreed 100%). More thinking. I'm not enthusiastic about stages - it is a top down approach that locks us into certain points of evaluation. What if we decided to add or get rid of a stage? Would we need to create things like unpure-pure-containers for various stages? What qualifies as a stage? Dependencies, I should guess. A stage is where we break circular dependencies. Basically, a grob says I want to have this and that information for making my positioning and LilyPond says You can't get it right now. Then the grob says ok, I'll do a tentative positioning, and LilyPond will come back with more information later and ask again. Now the problem here is when we are getting oscillation or even just a converging process. If there is convergence involved, we are better off calculation the _relation_ between the positionings. In a linear optimization problem, those define the surface plane of a simplex (which has possible solutions inside, impossible solutions outside, and where we are looking for the furthest distance from 0 as the goal of optimization) as a constraint. Intersecting with other surfaces/constraints gives us the total solution space, and travelling outside along its edges (which are the intersection of two planes) moves us to the optimal solution. Doing this iteratively means jumping around on the inside of the simplex. Each jump may be quite faster than determining the active boundaries of the simplex, but of course the simplex method focuses on _those_ pairings of parameters/positioning which are actually valid tradeoffs. And since it is an efficient method, it does not get confused when the heuristics go wrong. I'm not completely sure that I follow what you're saying (I don't know anything about the internals of the simplex method) but if you mean that recalculating tentative property values may result in a series of values that doesn't converge towards anything, then yes, you are right. Most tentative properties will likely have convergent behavior, meaning that as more information becomes available, they'll get closer and closer to actual properties. However, there is no systematic way to enforce this. I've spent a lot of time thinking about making linear programming possible in LilyPond and have come to the conclusion that aspects of LilyPond's logic make it such that decisions are not linear. The classic is: --) We do outside staff positioning, at which point element A gets shifted up. --) Element B, not being able to be placed between element A and the staff, gets placed above element A. --) We redo outside staff positioning after cross-staff-grobs' vertical skylines are calculated. --) Element A is now shifted higher up. --) Element B is now able to be stashed between element A and the staff. That is a leap in heights (we go from having element B in the skyline to not). So discussing convergence is really difficult - I think the best we can do are heuristics to decide when to settle on ok-enough values. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Recent LSR + Tarball checkin
Hello, I noticed that one of the changes in one of the snippets shows - \consists Mark_engraver + \consists Mark_engraver \consists Staff_collecting_engraver Is there a significance/preference using quotes or not? James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Recent LSR + Tarball checkin
James pkx1...@gmail.com writes: Hello, I noticed that one of the changes in one of the snippets shows - \consists Mark_engraver + \consists Mark_engraver \consists Staff_collecting_engraver Is there a significance/preference using quotes or not? URL:http://lilypond.org/doc/v2.16/Documentation/contributor/lilypond-formatting All engravers should have double-quotes around them: \consists Spans_arpeggio_engraver LilyPond does not strictly require this, but it is a useful convention to follow. Whatever a useful convention may be, that's our current rule. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
Hi, interesting discussion, i learn a lot. On Sun, Sep 30, 2012 at 11:39 AM, David Kastrup d...@gnu.org wrote: Basically, a grob says I want to have this and that information for making my positioning and LilyPond says You can't get it right now. Then the grob says ok, I'll do a tentative positioning, and LilyPond will come back with more information later and ask again. I have no idea whether there are any not-very-experienced developers (or users) following this thread, but if they are, i'm sure this is a very nice and helpful explanation for them :) cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On 30 sept. 2012, at 14:16, Janek Warchoł janek.lilyp...@gmail.com wrote: Hi, interesting discussion, i learn a lot. On Sun, Sep 30, 2012 at 11:39 AM, David Kastrup d...@gnu.org wrote: Basically, a grob says I want to have this and that information for making my positioning and LilyPond says You can't get it right now. Then the grob says ok, I'll do a tentative positioning, and LilyPond will come back with more information later and ask again. I have no idea whether there are any not-very-experienced developers (or users) following this thread, but if they are, i'm sure this is a very nice and helpful explanation for them :) cheers, Janek Just to clarify things for anyone following the thread: this is not currently how LilyPond works, but I'm assuming what you're proposing is a suggestion for a model. It's an interesting idea for grobs to ping a sort of central hive (LilyPond in your text above) to know what information they can access and when. This'd require a major change to the architecture - currently, grobs specify in their request whether they want tentative or permanent information via the use of functions like Grob::pure_relative_y_coordinate versus Grob::relative_coordinate. I'm worried about having a sort of centralized brain that tells grobs what they can and can't know - sounds Kafka-esque. I like the decentralized model where grobs, via their callbacks, self-police for what information they need from other grobs and when it's ok to get it. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds tick mark to scripts (issue 6568055)
On Sat, Sep 29, 2012 at 7:46 PM, Phil Holmes m...@philholmes.net wrote:
Well, in the current version of the NR, the guidance for changing the breath
sign is:
\override BreathingSign #'text = \markup {\musicglyph
#scripts.caesura.straight}
Hmm. I wouldn't do it this way, it feels not Lilypondish to me (e.g.
a dedicated command is easier to maintain - you can redefine it if
necessary and there are no compatibility problems). But this is just
my opinion (may be worth discussing separately though, as part of
GLISS).
I don't insist on moving the baseline; discussing this further seems
to be unproductive, so let's do it your way :)
thanks for your work and your patience!
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
m...@mikesolomon.org m...@mikesolomon.org writes: On 30 sept. 2012, at 14:16, Janek Warchoł janek.lilyp...@gmail.com wrote: Hi, interesting discussion, i learn a lot. On Sun, Sep 30, 2012 at 11:39 AM, David Kastrup d...@gnu.org wrote: Basically, a grob says I want to have this and that information for making my positioning and LilyPond says You can't get it right now. Then the grob says ok, I'll do a tentative positioning, and LilyPond will come back with more information later and ask again. Just to clarify things for anyone following the thread: this is not currently how LilyPond works, but I'm assuming what you're proposing is a suggestion for a model. It's an interesting idea for grobs to ping a sort of central hive (LilyPond in your text above) to know what information they can access and when. This'd require a major change to the architecture - currently, grobs specify in their request whether they want tentative or permanent information via the use of functions like Grob::pure_relative_y_coordinate versus Grob::relative_coordinate. I'm worried about having a sort of centralized brain that tells grobs what they can and can't know - sounds Kafka-esque. I like the decentralized model where grobs, via their callbacks, self-police for what information they need from other grobs and when it's ok to get it. I have my doubts that you can do a sensible circular dependency resolution strategy in a purely local manner. In fact, the current pure/unpure distinction is based on before/after linebreaking, a centralized operation. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
On 30 sept. 2012, at 14:29, David Kastrup d...@gnu.org wrote: m...@mikesolomon.org m...@mikesolomon.org writes: On 30 sept. 2012, at 14:16, Janek Warchoł janek.lilyp...@gmail.com wrote: Hi, interesting discussion, i learn a lot. On Sun, Sep 30, 2012 at 11:39 AM, David Kastrup d...@gnu.org wrote: Basically, a grob says I want to have this and that information for making my positioning and LilyPond says You can't get it right now. Then the grob says ok, I'll do a tentative positioning, and LilyPond will come back with more information later and ask again. Just to clarify things for anyone following the thread: this is not currently how LilyPond works, but I'm assuming what you're proposing is a suggestion for a model. It's an interesting idea for grobs to ping a sort of central hive (LilyPond in your text above) to know what information they can access and when. This'd require a major change to the architecture - currently, grobs specify in their request whether they want tentative or permanent information via the use of functions like Grob::pure_relative_y_coordinate versus Grob::relative_coordinate. I'm worried about having a sort of centralized brain that tells grobs what they can and can't know - sounds Kafka-esque. I like the decentralized model where grobs, via their callbacks, self-police for what information they need from other grobs and when it's ok to get it. I have my doubts that you can do a sensible circular dependency resolution strategy in a purely local manner. In fact, the current pure/unpure distinction is based on before/after linebreaking, a centralized operation. It is true that line-breaking is a centralized option based on what the toplevel-book-handler is, but it should be as lightweight as possible. I think that the smaller we can keep paper-book.cc and paper-score.cc, the better. I've been saying this for a couple years, but I'd prefer for Book and PaperScore to be grobs so that even they could use the callback model. At that point, line breaking could just be controlled by callbacks. This would also pave the way for better Prob / Grob integration - it is currently difficult to get toplevel markups and systems to play nicely because they are outside of this callback model. The current pure/unpure distinction is based on what people ask for and when. Pure offsets and extents are used until the dim_cache_ is filled, at which point real offsets and extents are used. As a convention this is before and after line breaking, but there are places where pure properties are requested after linebreaking and non-pure properties are requested before. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Project - Eliminating grob parents and outside-staff-priority
m...@mikesolomon.org m...@mikesolomon.org writes: It is true that line-breaking is a centralized option based on what the toplevel-book-handler is, but it should be as lightweight as possible. I think that the smaller we can keep paper-book.cc and paper-score.cc, the better. I've been saying this for a couple years, but I'd prefer for Book and PaperScore to be grobs so that even they could use the callback model. At that point, line breaking could just be controlled by callbacks. Distributing algorithms in that manner without central control/arbitration means O(n^2) complexity at least. It tends to lend itself better to parallelizing, but when your average system does not have thousands of processors, that advantage remains very limited. Of course, a half-baked not-well-understood global hackery touching stuff in lots of indiscriminate places is not what this is about. The interdependencies need to be stated as local relations, of course. It is just that the resolution is to be done globally. Of course this necessitates that the dependencies are formulated in a _systematic_ manner and in the same way everywhere, using well-crafted interfaces/ways of specification rather than in willy-nilly adhoc jumbles of callbacks. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch-testing-problem
2012/9/29 Keith OHara k-ohara5...@oco.net: Thomas Morley thomasmorley65 at googlemail.com writes: I wanted to test Marc's bar-line-patch somewhat closer, but I have a problem, not knowing what to do. git apply --index 0001-bar-line.patch error: patch failed: Documentation/snippets/adding-orchestral-cues-to-a-vocal-score.ly:4 error: Documentation/snippets/adding-orchestral-cues-to-a-vocal-score.ly: patch does not apply patch does not apply means that the code you have as a starting point is significantly different from the starting point of the patch. Phil ran an LSR update recently, which changes Documentation/snippets/* Marc's patch also changes many of those same files. Phil's LSR update was in commit 5c42908f1c8d0a5c1d88851a2d793ca55476612c so you can go back to the state just before, git checkout 5c42908f^ and then apply Marc's patch. Marc will probably rebase his patch pretty soon and repost it so that the diff applies to the codebase after the LSR update. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel Hi Keith, thanks for your advice. After git checkout 5c42908f^ I ran `make' and `make test-baseline' and was able to apply Marc's patch successfully. :) After doing that I ran a new `make'. And a new error arises after trying to do `make check' Terminal returns: [ ... ] Child returned 1 Error ignored by lilylib Error trapped by lilypond-book Please see /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log make[2]: *** [out-test/collated-files.texi] Error 1 make[2]: Leaving directory `/home/harm/lilypond-git/build/input/regression' make[1]: *** [local-test] Error 2 make[1]: Leaving directory `/home/harm/lilypond-git/build/input/regression' make: *** [test] Error 2 Looking at: /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log The file contains nothing else than: GNU LilyPond 2.17.4 Obviously I did sth wrong and again I've no clue what and how to proceed. Do you have another hint? Sorry, to ask again and again stupid questions, but on my own, I can see only two alternatives: Deleting all /Documantation/snippets from the patch and then apply it to current master or to stop any reviewing work as far as /Documentation/snippets are concerned in any way. -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch-testing-problem
Thomas, On 30 September 2012 15:16, Thomas Morley thomasmorle...@googlemail.com wrote: 2012/9/29 Keith OHara k-ohara5...@oco.net: Thomas Morley thomasmorley65 at googlemail.com writes: I wanted to test Marc's bar-line-patch somewhat closer, but I have a problem, not knowing what to do. git apply --index 0001-bar-line.patch error: patch failed: Documentation/snippets/adding-orchestral-cues-to-a-vocal-score.ly:4 error: Documentation/snippets/adding-orchestral-cues-to-a-vocal-score.ly: patch does not apply patch does not apply means that the code you have as a starting point is significantly different from the starting point of the patch. Phil ran an LSR update recently, which changes Documentation/snippets/* Marc's patch also changes many of those same files. Phil's LSR update was in commit 5c42908f1c8d0a5c1d88851a2d793ca55476612c so you can go back to the state just before, git checkout 5c42908f^ and then apply Marc's patch. Marc will probably rebase his patch pretty soon and repost it so that the diff applies to the codebase after the LSR update. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel Hi Keith, thanks for your advice. After git checkout 5c42908f^ I ran `make' and `make test-baseline' and was able to apply Marc's patch successfully. :) After doing that I ran a new `make'. And a new error arises after trying to do `make check' Terminal returns: [ ... ] Child returned 1 Error ignored by lilylib Error trapped by lilypond-book Please see /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log make[2]: *** [out-test/collated-files.texi] Error 1 make[2]: Leaving directory `/home/harm/lilypond-git/build/input/regression' make[1]: *** [local-test] Error 2 make[1]: Leaving directory `/home/harm/lilypond-git/build/input/regression' make: *** [test] Error 2 Looking at: /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log The file contains nothing else than: GNU LilyPond 2.17.4 Obviously I did sth wrong and again I've no clue what and how to proceed. Why do you think you did something wrong? That was exactly what I got when I tested the patch originally. You need to find the problem of why it failed to compile. See http://code.google.com/p/lilypond/issues/detail?id=2790#c33 Did you get the same problem? Do you have another hint? Sorry, to ask again and again stupid questions, but on my own, I can see only two alternatives: Deleting all /Documantation/snippets from the patch and then apply it to current master or to stop any reviewing work as far as /Documentation/snippets are concerned in any way. I don't really understand this, I assume you mean just to troubleshoot yourself on your own local git. James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds tick mark to scripts (issue 6568055)
Hello,
On 30 September 2012 13:27, Janek Warchoł janek.lilyp...@gmail.com wrote:
On Sat, Sep 29, 2012 at 7:46 PM, Phil Holmes m...@philholmes.net wrote:
Well, in the current version of the NR, the guidance for changing the breath
sign is:
\override BreathingSign #'text = \markup {\musicglyph
#scripts.caesura.straight}
Hmm. I wouldn't do it this way,
How would you do it?
James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch-testing-problem
2012/9/30 James pkx1...@gmail.com: Thomas, On 30 September 2012 15:16, Thomas Morley thomasmorle...@googlemail.com wrote: 2012/9/29 Keith OHara k-ohara5...@oco.net: Thomas Morley thomasmorley65 at googlemail.com writes: I wanted to test Marc's bar-line-patch somewhat closer, but I have a problem, not knowing what to do. git apply --index 0001-bar-line.patch error: patch failed: Documentation/snippets/adding-orchestral-cues-to-a-vocal-score.ly:4 error: Documentation/snippets/adding-orchestral-cues-to-a-vocal-score.ly: patch does not apply patch does not apply means that the code you have as a starting point is significantly different from the starting point of the patch. Phil ran an LSR update recently, which changes Documentation/snippets/* Marc's patch also changes many of those same files. Phil's LSR update was in commit 5c42908f1c8d0a5c1d88851a2d793ca55476612c so you can go back to the state just before, git checkout 5c42908f^ and then apply Marc's patch. Marc will probably rebase his patch pretty soon and repost it so that the diff applies to the codebase after the LSR update. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel Hi Keith, thanks for your advice. After git checkout 5c42908f^ I ran `make' and `make test-baseline' and was able to apply Marc's patch successfully. :) After doing that I ran a new `make'. And a new error arises after trying to do `make check' Terminal returns: [ ... ] Child returned 1 Error ignored by lilylib Error trapped by lilypond-book Please see /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log make[2]: *** [out-test/collated-files.texi] Error 1 make[2]: Leaving directory `/home/harm/lilypond-git/build/input/regression' make[1]: *** [local-test] Error 2 make[1]: Leaving directory `/home/harm/lilypond-git/build/input/regression' make: *** [test] Error 2 Looking at: /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log The file contains nothing else than: GNU LilyPond 2.17.4 Obviously I did sth wrong and again I've no clue what and how to proceed. Why do you think you did something wrong? Well, I'm still a newbie with this kind of tasks. If sth crashes my first thought is, damn, what did _I_ wrong. That was exactly what I got when I tested the patch originally. You need to find the problem of why it failed to compile. See http://code.google.com/p/lilypond/issues/detail?id=2790#c33 Did you get the same problem? I couldn't comprehend your own work. But after typing 'make check' the first two lines the terminal returns are: For tracking crashes: use grep sourcefilename `grep -L systems.texi out/lybook-testdb/*/*log|sed s/log/ly/g` Trying to enter this (in the build-directory) returns: \sourcefilename /home/harm/lilypond-git/input/regression/instrument-name-volta.ly This is exactly the file Marc mentioned here: http://codereview.appspot.com/6498052/#msg13 Do you have another hint? Sorry, to ask again and again stupid questions, but on my own, I can see only two alternatives: Deleting all /Documantation/snippets from the patch and then apply it to current master or to stop any reviewing work as far as /Documentation/snippets are concerned in any way. I don't really understand this, I assume you mean just to troubleshoot yourself on your own local git. Yes! Take the other statements more as an expression of my frustration not beeing able to solve the occuring problems on my own. Regards, Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Patch-testing-problem
Hello, On 30 September 2012 16:06, Thomas Morley thomasmorle...@googlemail.com wrote: ... Please see /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log make[2]: *** [out-test/collated-files.texi] Error 1 make[2]: Leaving directory `/home/harm/lilypond-git/build/input/regression' make[1]: *** [local-test] Error 2 make[1]: Leaving directory `/home/harm/lilypond-git/build/input/regression' make: *** [test] Error 2 Looking at: /home/harm/lilypond-git/build/out/lybook-testdb/snippet-names--154320194.log The file contains nothing else than: GNU LilyPond 2.17.4 Obviously I did sth wrong and again I've no clue what and how to proceed. Why do you think you did something wrong? Well, I'm still a newbie with this kind of tasks. If sth crashes my first thought is, damn, what did _I_ wrong. That was exactly what I got when I tested the patch originally. You need to find the problem of why it failed to compile. See http://code.google.com/p/lilypond/issues/detail?id=2790#c33 Did you get the same problem? I couldn't comprehend your own work. The problem is that not all errors are the same - I am no expert but after testing patches for the last year or so, you get a feel for this I guess. Phil's work (et al) has helped simplify the log, but if you see http://code.google.com/p/lilypond/issues/detail?id=2790#c16 for instance, this was a differnet kind of failure and was easy to spot simply because the log file references did point to a .ly file. This instance here is different and so it was trickier to follow the chain, in fact I couldn't. Phil's suggestion of looking at the latest file generated is a good one, but I simply use basic grep commands grep -r -C 10 Error for instance, in the top level of the build dir. I get a ton of hits, but the -C makes it easy to see if the return is just a comment of the string 'Error' or a function call, rather than a log file. The trick here is to know the error message being generated in the log file, fatal is one, or you can just do Processing files and the -C gives you a few lines above and below so you can see a completed file or an error. But after typing 'make check' the first two lines the terminal returns are: For tracking crashes: use grep sourcefilename `grep -L systems.texi out/lybook-testdb/*/*log|sed s/log/ly/g` I can't comment on that but it seems awfully complicated. Trying to enter this (in the build-directory) returns: \sourcefilename /home/harm/lilypond-git/input/regression/instrument-name-volta.ly This is exactly the file Marc mentioned here: http://codereview.appspot.com/6498052/#msg13 OK but that ly file will also occur in a snippet*.log file. So you can cross reference I guess but that would need another grep search. I guess I am just used to looking at lines and lines of output to use a simpler grep command, but not all crashes/compilation failures are the same and don't generate the same error messages even if the initial crash message looks the same. At least from my experience. However the offending log file *will* contain the error message (as if you had run lilypond-book on the individual snippet) Hence my comment --snip-- lily-7dccbf09.log:programming error: number of pages is out of bounds lily-7dccbf09.log:programming error: tried to space systems on a bad number of pages lily-7dccbf09.log:programming error: number of pages is out of bounds lily-7dccbf09.log:programming error: tried to space systems on a bad number of pages --snip-- The file 'lily-7dccbf09.log' contained the error message (from the grep command) and also in that log was the name of the snippet. James James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
verify regression tests
Hello list, I got strange results with the regression tests, and studying the CG more carefully, I spotted some differences: http://lilypond.org/doc/v2.17/Documentation/contributor/regtest-comparison says that you should do make test-baseline make check [changed the code; if needed 'make'] make test-redo make check (the latter is rather implicitly hidden in the text) After all looks good, do a make test-clean make check to restore the system to a clean state. http://lilypond.org/doc/v2.17/Documentation/contributor/verify-regression-tests is more overviewish, but it lacks the final make check which is needed after make test-clean, IIUC. I can cook up a patch for that, but I want to make sure that the changes are correct. Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
Am 30.09.2012 11:02, schrieb d...@gnu.org: [...] First, the define-public is asking for trouble. You are exposing an internal Scheme data structure to users and make it overwritable by the user. If the user follows this invitation, the effects will bleed over from session to session. Never do that. Ok. Consider _everything_ written in a .scm file as readonly conceptually. For an alist, you might want to define a _function_ returning the initial list, and the accessors should not be modifying it destructively (adding to the front of an alist does not change the original alist). Then you assign this initial value to a session variable in something included in init.ly, like #(define bar-glyph-alist (initial-bar-glyph-alist)) Ok. Your functions working with bar-glyph-alist have to take the version of bar-glyph-alist defined in the parser module. That means that when you call them from .ly files, you'll likely need to pass bar-glyph-alist from the .ly file into your Scheme function. Or get them via ly:parser-lookup via the parser variable. I am not sure whether I understand this completely, but I'll give it a try. If you put a new bar line definition into a.ly, and when calling lilypond a.ly b.ly it is available in b.ly, then you have done something wrong. I did this and can confirm that a bar line defined in a.ly *is* available in b.ly. So I have to replace all three public alists in bar-line.scm the way you described it above. [OT: it seems that I have a strong attraction to problems that look not very difficult at first glance and turn out to involve *a lot of* changes and obstacles until they get solved. On the other hand, this is a *perfect* way to learn about the internals of lilypond – in such situations where everything breaks, I remember Jan working on GUB during Waltrop and his statement when the compilation broke again: That's nice. I admire such a serenity and try to adopt it in situations where I am about to throw the computer out of the window ;-) I am not in this state yet, but I am working on it...] Regards, Marc http://codereview.appspot.com/6498052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
On 2012/09/30 19:44:49, marc wrote: Am 30.09.2012 11:02, schrieb d...@gnu.org: [...] First, the define-public is asking for trouble. You are exposing an internal Scheme data structure to users and make it overwritable by the user. If the user follows this invitation, the effects will bleed over from session to session. Never do that. Ok. No, it's not ok. Hold your horses, this is another case too stupid for documenting and walking people through. Give me two days, and then you replace your define-public for the alists with define-session, and that's it. The rest of the code stays as it is. I'll make define-session do everything that is needed. Just that it is possible to learn all the internals of LilyPond session does not mean that it makes sense that you are required to do so just in order to accomplish a simple task. http://codereview.appspot.com/6498052/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Adds tick mark to scripts (issue 6568055)
On Sun, Sep 30, 2012 at 4:32 PM, James pkx1...@gmail.com wrote:
On 30 September 2012 13:27, Janek Warchoł janek.lilyp...@gmail.com wrote:
On Sat, Sep 29, 2012 at 7:46 PM, Phil Holmes m...@philholmes.net wrote:
Well, in the current version of the NR, the guidance for changing the breath
sign is:
\override BreathingSign #'text = \markup {\musicglyph
#scripts.caesura.straight}
Hmm. I wouldn't do it this way,
How would you do it?
Like i described in my previous email - with a dedicated command:
straightBreathe = {
\override BreathingSign #'text = \markup {\musicglyph
#scripts.caesura.straight}
\breathe
}
or have just the override inside the variable, like a style setting:
straightBreathe = {
\override BreathingSign #'text = \markup {\musicglyph
#scripts.caesura.straight}
}
This way, if we ever change the name of the glyph or something like
that, we would just redefine this command and everything will /just
work/ - without convert-ly at all.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Issue 2869: Regularize lyrics lexer mode (issue 6594047)
I don't feel competent to speak about the code (and if i started asking questions, it would take ages to answer them all), but the idea of the change definitely LGTM. http://codereview.appspot.com/6594047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bar-line interface part 2/2: New bar line definition standard (issue 6498052)
2012/9/30 d...@gnu.org: On 2012/09/30 19:44:49, marc wrote: Am 30.09.2012 11:02, schrieb d...@gnu.org: [...] First, the define-public is asking for trouble. You are exposing an internal Scheme data structure to users and make it overwritable by the user. If the user follows this invitation, the effects will bleed over from session to session. Never do that. Ok. No, it's not ok. Hold your horses, this is another case too stupid for documenting and walking people through. Give me two days, and then you replace your define-public for the alists with define-session, and that's it. The rest of the code stays as it is. I'll make define-session do everything that is needed. That would be very nice. I can think of several functions/definitions currently destructively changing internal Scheme data structures. Perhaps they would work as expected then. -Harm ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request
On Mon, Sep 24, 2012 at 12:37:32PM +0100, Phil Holmes wrote:
Not necessarily. An alternative would be:
\beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 8 8 ] }
\beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 ] }
or maybe:
\beaming {
{ 8 [ 8 8 8 ] 8 [ 8 8 8 8 8 ] }
{ 8 [ 8 8 8 ] 8 [ 8 8 8 ] }
}
It's probably easier to keep track of what's happening (in terms
of programming) if there's a single command call; otherwise it
wouldn't be clear if both beamings were supposed to apply, or
whether the second one should clear the first one.
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown to 20121002
For 20:00 MDT (unless Mrs Patch Nanny has me recording choir parts, which could go later!) Tuesday October 2nd Documentation: Issue 2722 http://code.google.com/p/lilypond/issues/detail?id=2722: NR 2.4.1 Default tablatures harmonics notes in Staff are one octave lower - R 6588049 http://codereview.appspot.com/6588049/ Issue 2844 http://code.google.com/p/lilypond/issues/detail?id=2844: Patch: Doc: Improve documentation of \glissando. - R6567059 http://codereview.appspot.com/6567059/ Enhancement: Issue 2859 http://code.google.com/p/lilypond/issues/detail?id=2859: Patch: Provide \hide and \no functions for transparent and void glyphs - R 6575048 http://codereview.appspot.com/6575048/ Issue 2868 http://code.google.com/p/lilypond/issues/detail?id=2868: Patch: Various clean-ups in stems and beams. - R 6584045 http://codereview.appspot.com/6584045/ Issue 2869 http://code.google.com/p/lilypond/issues/detail?id=2869: Patch: Regularize lyrics lexer mode - R 6594047 http://codereview.appspot.com/6594047/ Cheers, Colin -- I've learned that you shouldn't go through life with a catcher's mitt on both hands. You need to be able to throw something back. -Maya Angelou, poet (1928- ) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request
\beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 8 8 ] }
\beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 ] }
or maybe:
\beaming {
{ 8 [ 8 8 8 ] 8 [ 8 8 8 8 8 ] }
{ 8 [ 8 8 8 ] 8 [ 8 8 8 ] }
}
It's probably easier to keep track of what's happening (in terms
of programming) if there's a single command call; otherwise it
wouldn't be clear if both beamings were supposed to apply, or
whether the second one should clear the first one.
Since the second entry doesn't clear the first one (because the number
of beats in entries is different) I'm against this additional,
artificial grouping.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Feature request
Werner LEMBERG w...@gnu.org writes:
\beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 8 8 ] }
\beaming { 8 [ 8 8 8 ] 8 [ 8 8 8 ] }
or maybe:
\beaming {
{ 8 [ 8 8 8 ] 8 [ 8 8 8 8 8 ] }
{ 8 [ 8 8 8 ] 8 [ 8 8 8 ] }
}
It's probably easier to keep track of what's happening (in terms
of programming) if there's a single command call; otherwise it
wouldn't be clear if both beamings were supposed to apply, or
whether the second one should clear the first one.
Since the second entry doesn't clear the first one (because the number
of beats in entries is different) I'm against this additional,
artificial grouping.
At the current point of time, we are bikeshedding. Please note that the
implementation of this feature does not depend on naked rhythms, it
should work just the same as
\beaming { c8 [ c c c ] c [ c c c c c ] }
so if people care about the details, they can significantly increase the
impact of their opinion by writing the implementation.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
