engraver question: how to define an array to store events?
Hello list,
while trying to get more insight into the engraver stuff, I encountered a
problem. I hope I can explain it:
I need some kind of a array of vectors:
vectorStream_event* slot_[max];
where I can store events later on by calling
slot_[i].push_back (event);
The index i lies in a fixed range from 0 to some value max, but it
isn't processed sequentially, so the calculations could start with i=4,
then comes i=0 etc.
As far as I understand c++, I cannot access i=4 directly if i=0...3
weren't accessed before.
So I tried to initialize the vector within initialize () as follows:
void
My_engraver::initialize ()
{
static int const max = 12;
vectorStream_event* slot_[max];
for (int i = 0; i max; i++)
slot_[i] = 0;
};
but then slot_[] and max are not accessible in process_music ();
When I move the declarations to
class My_engraver : public Engraver
{
.
.
.
private:
static int const max = 12;
vectorStream_event* slot_[max];
.
.
.
}
void
My_engraver::initialize ()
{
for (int i = 0; i max; i++)
slot_[i] = 0;
};
then I got
error: no match for 'operator=' in
'((My_engraver*)this)-My_engraver::slot_[i] = 0'
How can this be solved? Or is there a better approach to store events in
an array
the way I described above?
Thanks in advance!
Marc
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: pitch to string conversion in c++
Am 16.09.2011 10:43, schrieb David Kastrup: Marc Hohlm...@hohlart.de writes: [...] Unnecessary copying. Better do Pitch *current_pitch = unsmob_pitch (event-get_property (pitch)); string pitchstring = current_pitch-to_string (); Perfect. Thanks! Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110921
On Di., 20. Sep. 2011 05:29:32 CEST, Colin Campbell c...@shaw.ca wrote: Issue 1890: Compiler warnings in make on 64-bit systems - R 5039043 Cancel that patch countdown. The patch introduces more warnings than it fixes... Cheers, Reinhold ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix 155: parentheses include accidentals and dots. (issue 5047048)
LGTM. http://codereview.appspot.com/5047048/diff/8001/scm/output-lib.scm File scm/output-lib.scm (right): http://codereview.appspot.com/5047048/diff/8001/scm/output-lib.scm#newcode626 scm/output-lib.scm:626: (foo (display calculating pure y extent)) ¿Qué es? http://codereview.appspot.com/5047048/diff/8001/scm/output-lib.scm#newcode639 scm/output-lib.scm:639: (let ((syms (ly:grob-property g 'parenthesis-friends '())) 80 char maximum when possible - you can list the arguments underneath. http://codereview.appspot.com/5047048/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110921
Joe Neeman joenee...@gmail.com writes:
On Mon, Sep 19, 2011 at 9:35 PM, David Kastrup d...@gnu.org wrote:
Colin Campbell c...@shaw.ca writes:
Issue 935: Enhancement: optional arguments in music functions - R
5023044
Cancel countdown. I am still fuzzing with avoiding O(n^2) rules for n
syntax classes, and trying to cater for multiple optional arguments in a
row. Doing both is a challenge requiring quite a bit of cleanup, and
applying the current patch would be a step backward. Hope to get
something working soon. I have a working version right now, but don't
like to leave ~80 shift/reduce conflicts (basically 2n with n being the
number of terminal symbols that may start an argument).
Have you considered adding a special syntax for optional arguments?
Like \foo[opt]{mandatory} in tex...
Not really interesting since it won't cover the syntax of existing
commands like \relative c' c.
I am making progress, but it's not really pretty. Basically if one
avoids O(n^2) rules and uses one rule to bind them all, then you can't
specialcase something like [music] music namely an optional music
command before a mandatory one. You need operator priorities to sort
this out. Now we don't much care what [music] music ends up as (it is
not smart syntax), but we do care what [pitch] music ends up with. If
optional arguments are greedy, something like [music] music has the
potential to take quite a bit of lookahead, if they are deterring,
however, [pitch] music won't work since pitch would be flushed out into
music (a pitch specification can always be interpreted as music). With
several optional arguments, one would presumably like to have them
filled left-to-right. Operator priorities for resolving shift/reduce
concern themselves with the lookahead symbol. If I look ahead into the
following music stream, I need to define operator precendence for
anything that can follow. That's just not feasible.
I am still gaming the LALR(1) system. I'll likely come up with
something workable, but it is really much more work for the bounty than
I had intended.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110921
On Di., 20. Sep. 2011 05:29:32 CEST, Colin Campbell c...@shaw.ca wrote: Issue 1890: Compiler warnings in make on 64-bit systems - R 5039043 Cancel that patch countdown. The patch introduces more warnings than it fixes... Cheers, Reinhold ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
lilypond-book-preamble: Automatically set the eps backend, since we require it anyway (issue 5038045)
passes make and reg tests http://codereview.appspot.com/5038045/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
Graham Percival wrote Tuesday, September 20, 2011 12:09 AM 1. Find a different patch management tool 2. Find a different patch and issue management tool 3. Write a few python scripts to make our lives better I favor the last option. So do I * 1-5 hours: automatically switch any Patch-review to Patch-needs_work if there are any non-LGTM comments. Hmm. There are often comments which don't necessarily imply disapproval (or approval for that matter). I think we need two keywords if this is to be automated: LGTM - thoroughly checked and approved for pushing LBTM (or whatever) - definitely not to be pushed, needs further work Then a single LBTM would automatically switch to Patch-review. A single LGTM automatically switches to Patch-push (unless countermanded by another comment with LBTM). Comments without either keyword have no effect. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1410 / Virus Database: 1520/3907 - Release Date: 09/19/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: building faillure
- Original Message - From: Bernardo Barros bernardobarr...@gmail.com To: Phil Holmes m...@philholmes.net Cc: lilypond-user lilypond-u...@gnu.org Sent: Monday, September 19, 2011 6:48 PM Subject: Re: building faillure Here it is, thanks (Copying to devel. Problem is a build failure on Fedora. Original text is on user). What seems to be happening with your system is that it's making the object files in a different order from mine. I have a line: Considering target file `out/general-scheme.o' and as a result of this I get: Considering target file `out/version.hh'. File `out/version.hh' does not exist. [snip lines] Finished prerequisites of target file `out/version.hh'. Must remake target `out/version.hh'. /usr/bin/python /home/phil/lilypond-git/stepmake/bin/make-version.py /home/phil/lilypond-git/lily/../VERSION out/version.hh For me, this happens before: Considering target file `out/relocate.o'. which is the line causing your build to fail, since relocate.cc has this line: #include version.hh which, at this point on your system, has not yet been built. I'm hoping Graham or someone who understands the build system will step in here, but I think you'll be able to temporarily fix this by editing lily/GNUmakefile. See the lines: $(outdir)/general-scheme.o: $(outdir)/version.hh $(outdir)/lily-guile.o: $(outdir)/version.hh $(outdir)/lily-version.o: $(outdir)/version.hh Add this below it: $(outdir)/relocate.o: $(outdir)/version.hh Let me know how you get on. Graham: git grep version.hh gives: lily/general-scheme.cc:#include version.hh lily/lexer.ll:#include version.hh lily/lily-guile.cc:#include version.hh lily/lily-version.cc:#include version.hh lily/main.cc:#include version.hh lily/relocate.cc:#include version.hh lily/warn-scheme.cc:#include version.hh I think it could make the build system more robust to make ordering by adding lexer.ll, main.cc, relocate.cc and warn-scheme.cc to the target list for version.hh? -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
Hey! I'm currently writing a doc entry that explains how to use replacements. I have a few questions: Where do you think I should put it? In NR 1.8.1 or 1.8.2? Do you think I have to move the table from the regtest to the Appendix A (and keep the rest of the regtest as a regtest)? Bertrand PS: I'm also writing a changelog entry. http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1780 remove scheme format calls with no destination parameter - deprecated in Guile V2 (issue 4974078)
Thanks for applying these! Sorry to bother you again with indentation, but you don't have to replace spaces with tabulators in scripts/musicxml2ly.ly . We decided that the rule for Python is 4 spaces per indentation level. For more infos, see: http://lilypond.org/~graham/gop/gop_1.html#GOP-1-_002d-python-formatting Thanks, Bertrand http://codereview.appspot.com/4974078/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
On 2011/09/20 10:18:41, Bertrand Bordage wrote: Hey! I'm currently writing a doc entry that explains how to use replacements. I have a few questions: Where do you think I should put it? In NR 1.8.1 or 1.8.2? Hmm.. I'd say 3.3.3 actually http://lilypond.org/doc/v2.14/Documentation/notation/text-encoding 1.8.x are how to format text (bold italic etc) not to use special chars which this seems to be and which NR 3.3.3 is all about. Do you think I have to move the table from the regtest to the Appendix A (and keep the rest of the regtest as a regtest)? I am not experienced enough to answer this, but which Appendix A did you intend? A new one or add to an existing as I cannot see where this would be appropriate. Bertrand PS: I'm also writing a changelog entry. http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
On 2011/09/20 12:07:31, J_lowe wrote: Where do you think I should put it? In NR 1.8.1 or 1.8.2? Hmm.. I'd say 3.3.3 actually Oh, yes! This is better. Do you think I have to move the table from the regtest to the Appendix A (and keep the rest of the regtest as a regtest)? I am not experienced enough to answer this, but which Appendix A did you intend? A new one or add to an existing as I cannot see where this would be appropriate. In a new one called Special characters, just after Text markup list commands. http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
On 11-09-20 02:32 AM, Trevor Daniels wrote: Graham Percival wrote Tuesday, September 20, 2011 12:09 AM 1. Find a different patch management tool 2. Find a different patch and issue management tool 3. Write a few python scripts to make our lives better I favor the last option. So do I * 1-5 hours: automatically switch any Patch-review to Patch-needs_work if there are any non-LGTM comments. Hmm. There are often comments which don't necessarily imply disapproval (or approval for that matter). I think we need two keywords if this is to be automated: LGTM - thoroughly checked and approved for pushing LBTM (or whatever) - definitely not to be pushed, needs further work Then a single LBTM would automatically switch to Patch-review. A single LGTM automatically switches to Patch-push (unless countermanded by another comment with LBTM). Comments without either keyword have no effect. Trevor The remaining case is where there are no comments when a countdown expires. I've been taking that as silence implying consent, but with no assurance that anyone has actually reviewed the patch. 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: T1780 remove scheme format calls with no destination parameter - deprecated in Guile V2 (issue 4974078)
On 2011/09/20 10:49:28, Bertrand Bordage wrote: Thanks for applying these! Sorry to bother you again with indentation, but you don't have to replace spaces don't have to == don't need to, I assume you mean you shouldn't with tabulators in scripts/musicxml2ly.ly . We decided that the rule for Python is 4 spaces per indentation level. For more infos, see: http://lilypond.org/%7Egraham/gop/gop_1.html#GOP-1-_002d-python-formatting Thanks, Bertrand New patch-set uploaded with tabs in musicxml2ly.py converted to spaces. Ian http://codereview.appspot.com/4974078/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: T1780 remove scheme format calls with no destination parameter - deprecated in Guile V2 (issue 4974078)
LGTM. On 2011/09/20 14:15:53, Ian Hulin (gmail) wrote: don't have to == don't need to, I assume you mean you shouldn't with tabulators in scripts/musicxml2ly.ly . Yes, this was a subtle DON'T DO IT! :) http://codereview.appspot.com/4974078/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: building faillure
Phil: I can confirm your solution avoided the problem, thanks a bunch! ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
New patch set including some documentation work. http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: building faillure
- Original Message - From: Bernardo Barros bernardobarr...@gmail.com To: Phil Holmes m...@philholmes.net Cc: lilypond-user lilypond-u...@gnu.org; Devel lilypond-devel@gnu.org Sent: Tuesday, September 20, 2011 5:11 PM Subject: Re: building faillure Phil: I can confirm your solution avoided the problem, thanks a bunch! Think I'll add this to the tracker tomorrow (unless someone gets there first) - we should probably register this as an Issue to fix. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
A few comments following a quick look at the doc changes
Trevor
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely#newcode1591
Documentation/notation/input.itely:1591: @cindex UTF-8
Better to index these under the appropriate subsubsec
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely#newcode1597
Documentation/notation/input.itely:1597: @end menu
I think I'd prefer the order to be:
* Text encoding::
* Unicode::
* ASCII aliases::
That way we work from the general to the more specific,
rather than the other way round.
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely#newcode1625
Documentation/notation/input.itely:1625: See the complete @ref{List of
special characters}.
Should also have a See also:
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely#newcode1636
Documentation/notation/input.itely:1636: @end lilypond
Didn't we discuss earlier using \include?
If this works it should be mentioned too.
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
Hmm, I don't understand one comment, but I agree with the others. Thanks, Bertrand http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely File Documentation/notation/input.itely (right): http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely#newcode1636 Documentation/notation/input.itely:1636: @end lilypond What do you mean? http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: building faillure
- Original Message - From: Phil Holmes m...@philholmes.net To: Bernardo Barros bernardobarr...@gmail.com Cc: Devel lilypond-devel@gnu.org; lilypond-user lilypond-u...@gnu.org Sent: Tuesday, September 20, 2011 5:32 PM Subject: Re: building faillure - Original Message - From: Bernardo Barros bernardobarr...@gmail.com To: Phil Holmes m...@philholmes.net Cc: lilypond-user lilypond-u...@gnu.org; Devel lilypond-devel@gnu.org Sent: Tuesday, September 20, 2011 5:11 PM Subject: Re: building faillure Phil: I can confirm your solution avoided the problem, thanks a bunch! Think I'll add this to the tracker tomorrow (unless someone gets there first) - we should probably register this as an Issue to fix. Added as http://code.google.com/p/lilypond/issues/detail?id=1906 I can easily make the fix, if no-one disagrees with this approach. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
Hi Neil, 2011/9/14 n.putt...@gmail.com: http://codereview.appspot.com/4951062/diff/11001/input/regression/kievan-notes.ly File input/regression/kievan-notes.ly (right): http://codereview.appspot.com/4951062/diff/11001/input/regression/kievan-notes.ly#newcode11 input/regression/kievan-notes.ly:11: \override NoteHead #'stencil = #ly:text-interface::print NoteHead doesn't have an interface for 'text, so this regression test will spit out warnings when compiled (to see run it with -dcheck-internal-types). The canonical method is to use grob::interpret-markup, but this is still rather hackish. It would be preferable to add the infrastructure which switches the glyphs (if possible, a 'style setting). I'm not sure what is your opinion on this patch currently. Do you agree to push it if it doesn't break make, make doc and regtests? Do you agree with my comment no.7 http://code.google.com/p/lilypond/issues/detail?id=1873#c7 ? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: GOP-PROP 13: patch management tools
2011/9/20 Graham Percival gra...@percival-music.ca: On Tue, Sep 20, 2011 at 02:08:42AM +0200, Reinhold Kainhofer wrote: Am Tuesday, 20. September 2011, 01:09:20 schrieb Graham Percival: ** Different patch and issue managment tools * 1-3 hours: write a script that checks that every Patch-new can apply to master, compiles correctly, and creates a regtest comparison so the local human can check it and make it Patch-review instead. If there’s a problem before the regtest comparison, the script automatically changes it to Patch-needs_work. The problem is that if someone pushes a broken commit, it will cause all patches to Patch-needs_work, even if the patch is not to blame... That's why the script would/should check that master compiles, before trying any of the patches. Naturally, if master fails, it sends a panic email to lilypond-devel. Dear developer, Master failed. You are well advised to run screaming in horror. yours sincerely, Fieldmarshal BugTracker At this point, I'm not endorsing any particular behavior of these scripts; I'm just saying that the python gdata modules gives us an enormous amount of power to automate whatever we want to automate. I think we should pursue this option, rather than trying to move to different hosting tool(s). 2011/9/20 Colin Campbell c...@shaw.ca: As the Patch Meister in question, it would be nice to have a guaranteed link between the tracker and Rietveld, such that every patch on Rietveld has a corresponding tracker number. ATM, it is pretty much impossible to find a list of lilypond=-related patches on Rietveld without doing a search on each developer's login, where they are known to the Patch Meister. Given the one-to-one link, we're looking in a single, well-understood place, and finding everything related to issues (bugs and enhancements) with associated patches (bug fixes and proposed enhancements). My impression is that the main problem is the duplicancy of data and e-mail threads. Over and over again i'm getting lost, for example: where did i saw that complaint from Neil about patch adding Kievan notation? was it posted as a comment on Rietveld, a comment to google tracker issue (which one it was? tracker issues usually contain link to rietveld, but rietveld issues often don't contain links to tracker), or maybe an e-mail in a general thread that started before tracker and rietveld issues were created? Maybe it was sent in that thread, but only to me? I struggle to keep my inbox clean (in other words: if i don't have anything to do with a thread, archivize or delete it - this means that every thread present in my inbox requires some action from me. It gets difficult when there are three threads about the same topic...). One thing comes to my mind: there is some code revieving tool on Google Code. I remember that i saw it being used in some other project. It's a bit hidden, but i managed to found some info: http://code.google.com/p/support/wiki/CodeReviews Looks that we need to add our source code to the Google Code to be able to use that. I think this may be worth considering. Could we add our source to Google Code and see what we can do then? Another thing: i'd consider adding a policy about separating discussion about code and notation: comments on issue tracker should be about notation/features (i.e. what should the output be? What syntax do we want to use?) and all comments about code itself (is the indentation correct? Does it pass regtests?) should be done at code revieving tool. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: regtests about very small differencies
Hi Reinhold all, 2011/9/12 Reinhold Kainhofer reinh...@kainhofer.com: Am Monday, 12. September 2011, 12:01:25 schrieb Janek Warchoł: I'm going to fix an issue where a note is misplaced by about 0.07 staffspace. I'll add a regtest for this, but how will we make sure that it won't be overlooked in the future? When we watch a regtest comparison, it shows us the output in a quite low-resolution rasterized form; it will be impossible to spot the difference. I can also think of some more issues that i'm planning to fix which involve such small changes. Look at how beam-quanting (input/regression/beam-quant-standard.ly) does it: It prints the position of the beams, so that all changes in the position will lead to a change in the displayed text, which will be detectable in the regtests. Interesting idea. However, somehow i don't like it... I didn't respond so long because i didn't know how to justify my dislike, but now i have a nice example. This solution is of no use when there's a change in shape rather than position. See images attached to comment #2 here: http://code.google.com/p/lilypond/issues/detail?id=1898#c2 - it's impossible to spot the difference in that case unless the resolution is really big. My idea of solving this problem: add information about the resolution at which a regtest should be compiled (and displayed to the user in the comparison) to the ly file. For example add a header field: resolution = #1000 Only a handful regtests would need those, every other would be compiled at default resolution. How do you like it? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Unifies mensural ligatures with blot-diameter. (issue 5030053)
2011/9/19 bordage.bertr...@gmail.com: On 2011/09/18 21:47:04, janek wrote: I think LGTM, but it would be great if you'd add a regtest to demonstrate what this patch is fixing. I don't think so. mensural-ligatures.ly contains every case fixed by this patch. True. However, your changes are very subtle and extremely easy to overlook. I'm sure that if someone looked at the regtest comparison without knowing what to look for, he would miss it entirely and think that nothing changed. If I make a regtest to show such tiny graphical differences, then we would need to do the same thing for almost every graphical object... I seriously consider adding dedicated regtests for all such tiny graphical differencies. Please see this thread for a more detailed discussion about it: http://lists.gnu.org/archive/html/lilypond-devel/2011-09/msg00308.html http://codereview.appspot.com/5030053/diff/9001/lily/mensural-ligature.cc#newcode79 lily/mensural-ligature.cc:79: stencil = Lookup::beam (corrected_slope, width * 0.5, staff_space, blotdiameter); What does this do? (sorry for a stupid question) This is making a beam with round corners (blotdiameter is the radius of the round corner). These beams are used to represent the flexa (the big 'slide' at the end of the before/after PNGs). Ah, so Lookup::beam () prints a beam sybol! Nice. http://codereview.appspot.com/5030053/diff/9001/lily/mensural-ligature.cc#newcode201 lily/mensural-ligature.cc:201: (noteheads.sM2ligmensural).extent (Y_AXIS).length () * 0.5 I don't get it - why is this commented? Because the stems of these noteheads are not inside their Y-extent. This comment shows how this should ideally work. ok, i understand now. thanks, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A few remarks concerning \relative
Hi David (and Graham too),
2011/9/13 David Kastrup d...@gnu.org:
Graham Percival gra...@percival-music.ca writes:
On Tue, Sep 13, 2011 at 01:23:19AM +0200, David Kastrup wrote:
It's tutorial-speak at its best. I don't understand either your
unhappiness nor your displeasure.
The tutorial is not the place for musings or cleverness. The goal is
to get people started writing music with the minimum amount of fuss.
I don't think that the minimum amount of fun and curiosity is going to
help the motivation.
This tip should go in @ref{Suggestions for writing files}, and of
course in the Notation reference. If you really think it should be
earlier, we could discuss a rewrite of Learning 2.4.3 Absolute note
names, to be more general (alterate note entry? relative and
absolute modes revisised?) and adding this tip. But I would like to
discuss that patch on Rietveld before it's pushed.
I am not going to put up a patch on Rietveld and am not writing any more
documentation for this. I don't have the resources to put up a fight
for user appeal. It is enough of a chore to make Lilypond useful for
myself. I won't fight an upstream battle for others.
Hmm. It would be a pity if such a nice discovery would get lost.
Would you like me to put a patch about this for review?
thanks,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
2011/9/20 Janek Warchoł janek.lilyp...@gmail.com: I'm not sure what is your opinion on this patch currently. Do you agree to push it if it doesn't break make, make doc and regtests? Do you agree with my comment no.7 http://code.google.com/p/lilypond/issues/detail?id=1873#c7 ? Yes. I'm running make doc with the patch applied at the moment. Will report any problems. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110921
On Mon, Sep 19, 2011 at 09:29:32PM -0600, Colin Campbell wrote: For 22:00 MDT Wednesday September 21, and *far* too early for an Autumnal equinox! As an experiment, I have changed all (hopefully?) of these issues from Patch-review to Patch-countdown. You can see the complete list here: http://code.google.com/p/lilypond/issues/list?can=2q=Patch%3Dcountdown To avoid cluttering up bug-lilypond, I manually un-checked the send email option at the bottom of the email. I think this would be useful for any automatic issue handling scripts, so I wanted to see if it would work well. Colin: please double-check that I didn't miss anything? I can hear the water boiling so I'd better grab it befor eit spills over onto the stove. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
bookOutputName broken
hi David,
LilyPond barfs at
\book
{
\bookOutputName foo
{ a' }
}
git bisect gave me commit
24fdf0d37cec73564162324ab74ed5e3a6824e8c
to blame.
I don't know what to do, could you help me?
p
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
2011/9/20 Neil Puttock n.putt...@gmail.com: I'm running make doc with the patch applied at the moment. Will report any problems. There's nothing wrong with the patch as far as I can tell. Make doc completes successfully here. The only thing that's missing is an entry in Documentation/notation/notation-appendices.itely to show the glyphs. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: do we want special versions of the accidentals for use with text?
2011/9/13 Werner LEMBERG w...@gnu.org: I think the solution is to create a shorter variaton of accidental glyphs; an example in the attachment. How do you like this idea? Do you think all accidentals should have shorter versions, or would it be overkill to create for example a shorter version of 3-stemmed sharp or arrowed flat? Basically, I like the idea. However, it is an illusion IMHO to believe that such glyphs will fit all text fonts. True. Still, i think that shorter accidentals will be an improvement. For figured bass, the situation is different: Here we use LilyPond's digit font, which is completely under our control, and having accidentals fitting those digits better is a good thing. I will prepare shorter versions of accidentals. Would you help me with writing code that employs them? I did a quick glance at the code (chord-name-engraver, figured-bass-engraver) but i don't know where to start. cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely
File Documentation/notation/input.itely (right):
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely#newcode1636
Documentation/notation/input.itely:1636: @end lilypond
On 2011/09/20 17:09:48, Bertrand Bordage wrote:
What do you mean?
See comments 25 and 26.
If this works (I presume it does):
germanHTML = #(add-text-replacements! '((ss; . ß)
[...]))
frenchLigatures = [...]
\paper {
\germanHTML
\frenchLigatures
}
it would be good to use this form in the snippet and
comment that the definitions can be placed in ly files
which can be \included.
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A few remarks concerning \relative
Janek Warchoł janek.lilyp...@gmail.com writes: Hi David (and Graham too), I am not going to put up a patch on Rietveld and am not writing any more documentation for this. I don't have the resources to put up a fight for user appeal. It is enough of a chore to make Lilypond useful for myself. I won't fight an upstream battle for others. Hmm. It would be a pity if such a nice discovery would get lost. Would you like me to put a patch about this for review? That's between you and Graham. I am not going to figure a way around his solid disapproval. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bookOutputName broken
On 20 September 2011 21:50, Benkő Pál benko@gmail.com wrote:
I don't know what to do, could you help me?
The attached patch works for me (haven't run make check on it though).
Cheers,
Neil
From f6f1ad62263b4dfb5f518da71891d3a0b30c89a3 Mon Sep 17 00:00:00 2001
From: Neil Puttock n.putt...@gmail.com
Date: Tue, 20 Sep 2011 22:18:55 +0100
Subject: [PATCH] parser.yy: Allow embedded_scm inside \book and \bookpart
---
lily/parser.yy |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lily/parser.yy b/lily/parser.yy
index 02c99e2..df3067b 100644
--- a/lily/parser.yy
+++ b/lily/parser.yy
@@ -791,6 +791,7 @@ book_body:
| book_body lilypond_header {
$$-header_ = $2;
}
+ | book_body embedded_scm { }
| book_body error {
$$-paper_ = 0;
$$-scores_ = SCM_EOL;
@@ -843,6 +844,7 @@ bookpart_body:
| bookpart_body lilypond_header {
$$-header_ = $2;
}
+ | bookpart_body embedded_scm { }
| bookpart_body error {
$$-paper_ = 0;
$$-scores_ = SCM_EOL;
--
1.7.4.1
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: we need organizers
2011/9/11 Graham Percival gra...@percival-music.ca: Does anybody here feel like organizing tasks? We have a lot of delayed maintenance stuff that is going to come back and bite us in an unpleasant manner. 3) a full regression test examination: it's been about 5 years since anybody actually looked at all the regtests. (we've been doing comparisons, but not looking at all 1000+ regtests) Phil wrote a very nice web app that makes it easy to do this -- it randomly gives you regtests, you give feedback, it makes reports, etc... but that was back in January or February, and it went nowhere because nobody wanted to organize getting volunteers to go through them. What a shame! This web app would be perfect for a 10 minutes a day coffee break thing; we could easily have a dozen casual volunteers verify the entire regtests in a month or two. (with each regtest being examined by at least 3 people!) 4) documenting every regtest. IIRC the last time we (tried to) make sure that all features in the regtests were in the main documentation was back in the 2.11 days. Again, the bulk of this work is simply recruiting and organizing volunteers; we don't need one person to volunteer to examine all 1008 regtests. Once that job is done, it will be very easy to keep the documentation up-to-date; we just run something like git diff -u -r release/2.14.0-1 -r release/2.15.11-1 \ input/regression/ to find out what new/changed features needs updating. But that only works if we have a stable base to work from... I might be willing to do this (since there are no other volunteers). Can i see this web app? 1) Neil has volunteered to handle LSR - 2.14. Great! 2) James has offered to reclassify issues. Great! Is there anything that should be done with regard to these two or do you post them as examples only? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bookOutputName broken
Benkő Pál benko@gmail.com writes:
hi David,
LilyPond barfs at
\book
{
\bookOutputName foo
{ a' }
}
git bisect gave me commit
24fdf0d37cec73564162324ab74ed5e3a6824e8c
to blame.
I don't know what to do, could you help me?
The easiest thing to do is to revert the patch. After all, we are
shortly before release.
The patch replaces music functions returning void music with Scheme
functions that make much more sense in this context. However, a book
block strangely does not even permit Scheme expressions inside, but has
no problem with void music.
This is rather braindead and probably an oversight. But doing a proper
and thorough testing of all music functions I replaced is going to be
work, and as one can see, more important than checking that the function
does the same work as before (that's rather obvious) will be that its
usual mode of employment is in locations where Scheme functions can be
called just as well as music functions. This was a bulk replacement,
and going through with a finer comb than the regtests is
time-consuming. So reverting the commit and registering it as
patch-needs-work would likely be the prudent thing to do.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bookOutputName broken
Neil Puttock n.putt...@gmail.com writes: On 20 September 2011 21:50, Benkő Pál benko@gmail.com wrote: I don't know what to do, could you help me? The attached patch works for me (haven't run make check on it though). That would pretty much be what I would consider a proper fix and making Lilypond behave more like the user (not just David-on-a-code-wrangling-spree) would expect. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
bordage.bertr...@gmail.com Tuesday, September 20, 2011 11:18 AM Do you think I have to move the table from the regtest to the Appendix A (and keep the rest of the regtest as a regtest)? Yes. Between the current A10 and A11 looks a good place. Trevor - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1410 / Virus Database: 1520/3908 - Release Date: 09/20/11 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely File Documentation/notation/input.itely (right): http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/input.itely#newcode1636 Documentation/notation/input.itely:1636: @end lilypond Yes, unfortunately, this isn't simple. I didn't find any technical way to achieve this. http://codereview.appspot.com/4553056/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: A few remarks concerning \relative
On Tue, Sep 20, 2011 at 10:33:51PM +0200, Janek Warchoł wrote:
Hi David (and Graham too),
2011/9/13 David Kastrup d...@gnu.org:
Graham Percival gra...@percival-music.ca writes:
This tip should go in @ref{Suggestions for writing files}, and of
course in the Notation reference. If you really think it should be
earlier, we could discuss a rewrite of Learning 2.4.3 Absolute note
names, to be more general (alterate note entry? relative and
absolute modes revisised?) and adding this tip. But I would like to
discuss that patch on Rietveld before it's pushed.
Hmm. It would be a pity if such a nice discovery would get lost.
Would you like me to put a patch about this for review?
Sure, that would be nice. From what I recall of the original
patch, it could go verbatim in Notation 1.1.1 Relative octave
entry.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: building faillure
On Tue, Sep 20, 2011 at 10:08:26AM +0100, Phil Holmes wrote: $(outdir)/general-scheme.o: $(outdir)/version.hh $(outdir)/lily-guile.o: $(outdir)/version.hh $(outdir)/lily-version.o: $(outdir)/version.hh ... Graham: git grep version.hh gives: lily/general-scheme.cc:#include version.hh lily/lexer.ll:#include version.hh lily/lily-guile.cc:#include version.hh lily/lily-version.cc:#include version.hh lily/main.cc:#include version.hh lily/relocate.cc:#include version.hh lily/warn-scheme.cc:#include version.hh I think it could make the build system more robust to make ordering by adding lexer.ll, main.cc, relocate.cc and warn-scheme.cc to the target list for version.hh? Yes please. Add the lines, check that you can compile from scratch, then push directly. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: New alist to replace special characters. (issue 4553056)
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/notation-appendices.itely
File Documentation/notation/notation-appendices.itely (right):
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/notation-appendices.itely#newcode909
Documentation/notation/notation-appendices.itely:909: @example
blank line before @example and after @end example
http://codereview.appspot.com/4553056/diff/103001/Documentation/notation/notation-appendices.itely#newcode912
Documentation/notation/notation-appendices.itely:912: to a @code{\paper}
block. See @ref{ASCII aliases} for more details.
We're not allowed to write
see @ref{} for more details
according to the texinfo spec. Please change to:
For more details, see @ref{}.
Come to think of it, rewrite the whole paragraph to keep the @example
after the text:
The following special characters references can be used; for more
details, see @ref{ASCII aliases}.
@example
...
@end example
http://codereview.appspot.com/4553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Lilypond-book: Improve options handling by processing everything in one place (issue 5030044)
LGTM http://codereview.appspot.com/5030044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement optional music function arguments (issue 5023044)
Next round. Getting past shift/reduce conflicts required adding precendences to every terminal token that can start the last non-optional argument. But the resulting grammar is O(n): adding more elements to it is quite straightforward. http://codereview.appspot.com/5023044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Implement optional music function arguments (issue 5023044)
I'd be lying if I said I understood everything going on here, but I think I get the gist. I like moving this way! I like the approach of simplifying things. I like having optional predicates, and optional predicates with defaults. I will trust you that it is O(n) and that all the shift-reduce conflicts have been resolved. I'm not a parser expert, so it doesn't mean much coming from me, but I think this looks good. http://codereview.appspot.com/5023044/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: PATCH: Countdown to 20110921
On 11-09-20 02:38 PM, Graham Percival wrote: On Mon, Sep 19, 2011 at 09:29:32PM -0600, Colin Campbell wrote: For 22:00 MDT Wednesday September 21, and *far* too early for an Autumnal equinox! As an experiment, I have changed all (hopefully?) of these issues from Patch-review to Patch-countdown. You can see the complete list here: http://code.google.com/p/lilypond/issues/list?can=2q=Patch%3Dcountdown To avoid cluttering up bug-lilypond, I manually un-checked the send email option at the bottom of the email. I think this would be useful for any automatic issue handling scripts, so I wanted to see if it would work well. Colin: please double-check that I didn't miss anything? I can hear the water boiling so I'd better grab it befor eit spills over onto the stove. Cheers, - Graham Found a couple of others, Graham. This will make patch batch day a good bit easier; I used to open all the issues, R and T, from the previous batch in a browser, then review them one by each for changes. This will at least allow me to do it all in a browser. 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: Glyphs for Kievan Notation (issue 4951062)
Unfortunately, I cannot get my documentation to build. As was suggested earlier, I nuked my build folder and redid everything from the beginning (configure.sh, make all, touch, make doc). However, make doc errors out with the following message: Calculating line breaks... Segmentation fault command failed: /home/sasha/lilypond-git/build/out/bin/lilypond -dbackend=eps --formats=ps,png,pdf -dinclude-eps-fonts -dgs-load-fonts --header=doctitle --header=doctitlecs --header=doctitlede --header=doctitlees --header=doctitlefr --header=doctitlehu --header=doctitleit --header=doctitleja --header=doctitlenl --header=doctitlezh --header=texidoc --header=texidoccs --header=texidocde --header=texidoces --header=texidocfr --header=texidochu --header=texidocit --header=texidocja --header=texidocnl --header=texidoczh -dcheck-internal-types -ddump-signatures -danti-alias-factor=2 -I /home/sasha/lilypond-git/build/out/lybook-db -I /home/sasha/lilypond-git/build/Documentation -I /home/sasha/lilypond-git/Documentation -I /home/sasha/lilypond-git/build/Documentation/out-www -I /home/sasha/lilypond-git/input -I /home/sasha/lilypond-git/Documentation -I /home/sasha/lilypond-git/Documentation/snippets -I /home/sasha/lilypond-git/input/regression -I /home/sasha/lilypond-git/Documentation/included -I /home/sasha/lilypond-git/build/mf/out -I /home/sasha/lilypond-git/build/mf/out -I /home/sasha/lilypond-git/Documentation/pictures -I /home/sasha/lilypond-git/build/Documentation/pictures/out-www --formats=eps --verbose -deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir /home/sasha/lilypond-git/build/out/lybook-db/snippet-names-5304161007275961614.ly Child returned 139 make[2]: *** [out-www/notation.texi] Error 1 make[2]: Leaving directory `/home/sasha/lilypond-git/build/Documentation' make[1]: *** [WWW-1] Error 2 make[1]: Leaving directory `/home/sasha/lilypond-git/build' make: *** [doc-stage-1] Error 2 Does anyone have any idea what could be going on? The only thing that's missing is an entry in Documentation/notation/notation-appendices.itely to show the glyphs. OK. I'll work on notation-appendices.itely. Aleks ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
On Tue, Sep 20, 2011 at 10:27:02PM -0400, Aleksandr Andreev wrote: /home/sasha/lilypond-git/build/out/lybook-db/snippet-names-5304161007275961614.ly Does anyone have any idea what could be going on? What's in the above file? It'll probably contain 5-10 other filenames; one of those is the failing file. If you find the failing file, you can see the syntax that caused the error in lilypond, and then you can (relatively) easily investigate why that syntax causes a problem. This process can be automated relatively easily (relatively easily meaning 2-10 hours of python and build system work); that was the whole point of http://lilypond.org/doc/v2.15/Documentation/contributor/gop_002dprop-9-_002d-behavior-of-make-doc Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fixes missing images in big website page (issue 4963046)
LGTM. A quick test showed no problems in make doc. I didn't get pictures in make website, but then I tried make website without the patch applied, and I still didn't get pictures... evidently I don't have my desktop set up to create the full website any more. So that's not a reason to distrust this patch. http://codereview.appspot.com/4963046/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Results of make check between 2.15.11-1 and 2.15.12-1
Hello, This is really just an experiment to see if it worked as I wanted but also if it is something that is useful? I couldn't workout the git command to rewind it all the way back to the 'merge branch release/unstable' for 2.15.11-1 so I used gitk and found that commit and simply right-click and selected 'reset master branch to here'. This seemed to work and git status showed I was 65 commits behind and gitk looked like I would expect - with the top commit in the list the one back at 2.15.11-1. At that point did a configure, make and a make test-baseline in my out of tree 'build' dir. Then I did a simple 'git pull -r' and this put gitk all the way back to the last 'merge branch release/unstable' commit for 2.15.12-1 and then I ran (in my out of tree build dir) rm mf/out/* ; make ; make check and got the following output which I have zipped and attached here: http://lilypond-stuff.1065243.n5.nabble.com/Make-check-for-diffs-between-2-15-11-1-and-2-15-12-1-td4825102.html Unzip and point your browser at the index.html (it was the smallest file size - 1mb zipped, 6mb unzipped - I could get and the quickest way I could think of to disseminate the information). 1. Was this the correct work flow? 2. Is this useful at all? -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Results of make check between 2.15.11-1 and 2.15.12-1
On Sep 21, 2011, at 6:45 AM, Peekay Ex wrote: Hello, This is really just an experiment to see if it worked as I wanted but also if it is something that is useful? I couldn't workout the git command to rewind it all the way back to the 'merge branch release/unstable' for 2.15.11-1 so I used gitk and found that commit and simply right-click and selected 'reset master branch to here'. This seemed to work and git status showed I was 65 commits behind and gitk looked like I would expect - with the top commit in the list the one back at 2.15.11-1. At that point did a configure, make and a make test-baseline in my out of tree 'build' dir. Then I did a simple 'git pull -r' and this put gitk all the way back to the last 'merge branch release/unstable' commit for 2.15.12-1 and then I ran (in my out of tree build dir) rm mf/out/* ; make ; make check and got the following output which I have zipped and attached here: http://lilypond-stuff.1065243.n5.nabble.com/Make-check-for-diffs-between-2-15-11-1-and-2-15-12-1-td4825102.html Unzip and point your browser at the index.html (it was the smallest file size - 1mb zipped, 6mb unzipped - I could get and the quickest way I could think of to disseminate the information). 1. Was this the correct work flow? 2. Is this useful at all? Hey James, With respect to #2, it depends what you want to see. make check only shows differences with respect to grobs whose extents and/or offsets have changed in LilyPond. Their physical placement on the page may change without being registered and, inversely, a change may be registered without their moving. My experience dictates is great for testing most changes to LilyPond, but bad for testing the effect of Y-extent / offset work on the visual output (remembers back to stem patch...shudders...). In this case, a pixel by pixel comparison would be better. So, in sum, my response is that it depends what you want. As for your workflow, it makes sense - this will certainly get you baselines and comparisons in the places in time that you want them. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Doc: Added note to CG about disable-optimizing
http://codereview.appspot.com/5081048/ This is for Tracker 1905 Added sentence to add --disable-optimising for ./autogen.sh or ../configure when doing regression testing -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
