Re: bug rating
On Thu, Dec 10, 2009 at 08:22:32AM +0100, Werner LEMBERG wrote: > is it correct that all fixes, regardless of its annoyance, get a `low > priority' in case it won't become part of the next `milestone' > release? That's not quite correct. There's no functional difference between Postponed, Low, and Medium. In the case of your recent two issues, I more-or-less assigned them randomly between Medium and Low. If you'd entered them yourself as both Medium, or both Low, I wouldn't have said anything. We essentially only have two levels: stop-stable-release, and not-stop-stable-release. > I consider this categorization a bit coarse, Yes and no. I'd rather move to having 4 levels: - High: should be fixed ASAP (crashes, regression failures) - Medium: will stop a stable release. (I'd consider maybe 10% of the current "medium" items to be medium on this scale) - Low: the normal priority. Sorry, but we just don't have many bug fixers! I favor honesty over trying to make users happy about assigning their pet issue a "higher priority" flag that nobody pays attention to. - Postponed: there's every indication that nobody will touch this for the next year or more. but so far I've been waiting for feedback about my Regression-bugs email. > and I would like to see at least one more level to mark bugs as > `annoying' or something like that. I disagree here. Every bug is "annoying" to the person who reported it. This would only lead to arguments over what's more annoying. I'm sure that somebody considers our lack of a handheld media CSS for the new website to be horrible! Do bug fixers look at the priority levels? Shortly after I posted the links to the grid view, IIRC two people started working on regressions, so maybe this is starting to happen. But I doubt there's any difference in how Frogs consider items between medium and low priority. Their main interest is "how hard will it be to fix?", not "does somebody find this annoying". Don't misunderstand me: I think it would be great to rank bugs based on severity, annoyance, or "how ugly does it look". But that won't happen until we double or triple the bug fixers -- both doubling their numbers, but most importantly doubling their knowledge of lilypond architecture. Let me turn this around: you are one of our top 10 bug hunters. If you had no previous connection to any of the issues, how would you decide which bug(s) to work on? Would you seriously just start working on whichever item *I* said was most important / most annoying ? or would you try to find an item that appealed to *you* personally? Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bug rating
Graham Percival wrote: > Let me turn this around: you are one of our top 10 bug > hunters. If you had no previous connection to any of the > issues, how would you decide which bug(s) to work on? Would > you seriously just start working on whichever item *I* said > was most important / most annoying ? or would you try to > find an item that appealed to *you* personally? I think I side with Werner on this one. There are 336 open issues in the tracker. And something like #379, which most of us would agree looks hideous*, is given priority `low', while something like #887, which involves point-and-click of all things, is given priority `medium'. *http://lilypond.googlecode.com/issues/attachment?aid=-7427108513750415230&name=line-break-slurs.PNG If I were looking for issues to tackle, I might entirely overlook #379, buried under a hundred other "higher" priority issues like point-and-click. But the issues that Werner is talking about, these are the bugs that serious typesetters will find themselves invariably colliding with. Someone typesetting real scores for a real publisher will have an easier time accepting a point-and-click/special-character limitation, but will find a bug like #379 simply unacceptable. And if the only workaround involves tweaking every slur manually, then they'll turn to a different program. Personally, I don't think `priority'* or `annoying' captures it. I would label them `embarrassing', because they're holding LilyPond back from looking really professional. And I think that the harshness of that label carries an even bigger incentive to get rid of them (somehwat like the flashing-text pink boxes on the new website). *http://lists.gnu.org/archive/html/lilypond-devel/2009-07/msg00082.html - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bug rating
On Thu, Dec 10, 2009 at 02:15:21AM -0800, Mark Polesky wrote: > Graham Percival wrote: > > > Let me turn this around: you are one of our top 10 bug > > hunters. If you had no previous connection to any of the > > issues, how would you decide which bug(s) to work on? Would > > you seriously just start working on whichever item *I* said > > was most important / most annoying ? or would you try to > > find an item that appealed to *you* personally? > > I think I side with Werner on this one. There are 336 open > issues in the tracker. And something like #379, which most of > us would agree looks hideous*, is given priority `low', while > something like #887, which involves point-and-click of all > things, is given priority `medium'. Okkkaay. 379 is now medium. 887 is now low. Nobody is working on fixing them, but hey, as long as those deck chairs look good, who cares which vertical direction the titanic is moving in! (admittedly, both issues are marked as "started", which makes this a very rare pair of issues indeed!) > Personally, I don't think `priority'* or `annoying' captures > it. I would label them `embarrassing', because they're > holding LilyPond back from looking really professional. But if nobody is working on fixing them, who cares what the label is?!?! The low vs. medium priority has historically been a mixture of "bug severity" and "order that somebody might try to fix it in". If somebody wants to go through all 350 bugs that are low and medium, and prioritize them according to "how ugly do they look", I don't care. Talking about this is SERIOUSLY in "rearranging the deck chairs while the titanic sinks" territory (in case you didn't catch the earlier reference). I don't know of any bug fixers who are sitting around twiddling their thumbs. Instead, they're trying to learn enough about the internals to fix the issue they're already working on. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bug rating
Graham Percival writes: > On Thu, Dec 10, 2009 at 02:15:21AM -0800, Mark Polesky wrote: > >> Personally, I don't think `priority'* or `annoying' captures it. I >> would label them `embarrassing', because they're holding LilyPond >> back from looking really professional. > > But if nobody is working on fixing them, who cares what the label > is?!?! Huh? Who cares about the label of a bug that is already being fixed? -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build failure on OS X: "error: template class without a name"
I'm using: OS X 10.6.2 MacPorts 1.8.1 gcc 4.2.1 XQuartz 2.3.4 (Xtools? That's an abandoned project, isn't it? I think you meant XQuartz.) I installed all dependencies with MacPorts. thSoft ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build failure on OS X: "error: template class without a name"
Oh yeah, maybe you meant Xcode. Yes, I use the standard Snow Leopard Xcode, v3.2.1. thSoft ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Can't compile docs
Le mercredi 09 décembre 2009 à 22:59 +, Trevor Daniels a écrit : > /home/trevor/lilypond-git/scripts/build/out/www_post LilyPond > 2.13.9 ./out-www "offline" > Mirroring... > Traceback (most recent call last): > File "/home/trevor/lilypond-git/scripts/build/out/www_post", line 67, > in > map (os.mkdir, [os.path.join (out_root, d) for d in dirs]) > OSError: [Errno 2] No such file or directory: > 'out-www/offline-root/Documentation/automated-engraving' I doubt I understand why this happens. Could you insert the following in www_post.py at line 60 (just after dirs.sort()), run 'make doc' again (I don't care whether you make doc-clean first, it shouldn't matter) and send us build stdout/stderr starting from www_post.py invocation? print dirs Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Cannot make doc
Le mercredi 09 décembre 2009 à 20:19 +0100, Francisco Vila a écrit : > Thank you, now I have upgraded texi2html to v1.82 and have been able > to complete the process. Ah, if you used a version older than 1.82, it probably doesn't normalize the node names the same way. > I uncompressed it from the deb package[1] > because I can no longer compile it: > > make[2]: Entering directory `/home/fravd/source/texi2html/po_messages' > /usr/bin/xgettext --default-domain=texi2html --directory=.. \ > --add-comments=TRANSLATORS: --language=Perl -k__ -k\/usr/bin/make_ > -k%__ -k__x -k__n:1,2 -k__nx:1,2 -k__xn:1,2 -kN__ \ > --files-from=./POTFILES.in \ > --copyright-holder='Free Software Foundation, Inc.' \ > --msgid-bugs-address='' > /usr/bin/xgettext: warning: The option --msgid-bugs-address was not specified. > If you are using a `Makevars' file, please specify > the MSGID_BUGS_ADDRESS variable there; > otherwise please > specify an --msgid-bugs-address command line > option. > ../texi2html.pl:5963: invalid variable interpolation at "@" > make[2]: *** [texi2html.pot-update] Error 1 > make[2]: Leaving directory `/home/fravd/source/texi2html/po_messages' > make[1]: *** [texi2html.pot] Error 2 > make[1]: Leaving directory `/home/fravd/source/texi2html/po_messages' > make: *** [all-recursive] Error 1 Please report this directly to texi2html-...@nongnu.org including your system configuration. > [1]http://packages.ubuntu.com/lucid/all/texi2html/download > The dirty hack was to uncompress the data/ directory from the .deb package > with > > $ sudo tar -xvzf data.tar.gz -C / > > Installing the package the standard way does not work, either; I need > to upgrade dpkg and libc6 as well. Would rebuilding a .deb from the source package (.src.deb or whatever it is named) help, and sending it to Ubuntu texi2html package maintainer help? If you don't know how to build a .deb package, please request him/her directly. > I think this is too much for a > single-file perl script. I understand your feeeling, but a bug compilation or packaging bug is still a bug to be reported to the people responsible for handling it. Best, John signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bug rating
> If you'd entered them yourself as both Medium, or both > Low, I wouldn't have said anything. OK. > - Low: the normal priority. Sorry, but we just don't have many bug > fixers! I favor honesty over trying to make users happy about > assigning their pet issue a "higher priority" flag that nobody > pays attention to. Mhmm. Let's pretend that I'm Joe Neeman, and I have some time to fix something (and I actually know what I'm doing). Wouldn't it be helpful if I could check the priority flag of the bugs to find something I should work on more urgently than other things? For example, the Savannah bugzilla allows users to `rate' bugs. The higher the score, the more people would like to have this bug fixed. > Every bug is "annoying" to the person who reported it. No. I have reported a lot of bugs which are of minor importance but indicate a typographical shortcoming. > I'm sure that somebody considers our lack of a handheld media CSS > for the new website to be horrible! Uff. You are comparing apples with oranges. I'm talking about lilypond itself and not the infrastructure around it. > Do bug fixers look at the priority levels? [...] But I doubt > there's any difference in how Frogs consider items between medium > and low priority. Whether a bug is easy to fix or not is completely unrelated. The classification system should somehow indicate the importance. > Their main interest is "how hard will it be to fix?", not "does > somebody find this annoying". Then we need a second tag which takes care of this. > Let me turn this around: you are one of our top 10 bug hunters. If > you had no previous connection to any of the issues, how would you > decide which bug(s) to work on? Good question. Since the tagging doesn't indicate severeness, I think I had to wade through all reports manually. > Would you seriously just start working on whichever item *I* said > was most important / most annoying? or would you try to find an item > that appealed to *you* personally? I think I would do something inbetween. If I could handle two issues of similar `easiness', I would fix the more urgent one. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Update & announcement
Le jeudi 10 décembre 2009 à 03:44 +, Graham Percival a écrit :
> On Wed, Dec 09, 2009 at 11:11:20AM +0100, John Mandereau wrote:
> > 4 lines of Texinfo multiplied by the number of languages, which
> > completely changes the deal.
>
> It's still only a few minutes.
This can hardly be done properly in a few minutes for all languages
without error, I'm sure this takes more than 20 minutes.
> If the change is done badly, then the docs stop building.
... as any other doc edit.
> It would be nice if we *didn't* have to require a specific
> versioin of texi2html.
I don't understand this remark: what the mao can we do about texi2html
customization interface being a moving target, after having decided to
require CVS snaphots while at the same time much development has been
done on texi2html to allow it replace makeinfo?
> We'd have to tell writers "use @lilysection{foo} to start a new
> section, unless you want to have a different title instead of the
> node name, in which case do @node{foo} @section{foo}".
As all other existing docs would look like this, this wouldn't be such a
big deal.
> Look, lilypond does *not* have a good record of "clever,
> time-saving" build stuff. Yesterday I had to spent 15 minutes
> figuring out how to add ja to the tarball for 2.12.3, because
> somebody thought it would be cute to get the language list from
> python/something.py, and they'd commented out the "ja" from line
> 123 in that file.
Sorry, but release 2.12 happened by surprise while I was integrating
Japanese docs. I've never been able to build GUB, so I didn't and still
don't have an easy way to run an equivalent of dist-check.
> Take Trevor -- by any stretch of the imagination, he's an ideal
> contributor/developer. Can he build the docs? No. Ok, maybe
> this is a one-off error... but could he identify the problem? No.
> Having asked us about the problem, could well tell me? Not as far
> as I know; the only way to debug build errors is to skim through
> literally hundreds of lines of warnings and errors, and look for
> some unfamiliar warnings+errors. That is *incredibly* frustrating
> for people who want to help out.
Han-Wen and/or I already told you that if we want sources that always
compile for doc editors, we must create a dedicated branch. If you
don't want to listen to this argument, I don't see the point of
complaining on the inherent unstability of master branch.
> You're about to say "yeah, but this is a really simple thing that
> has nothing to do with the doc-building problems". I call BS.
> It's yet one more complication. And again, we have a *terrible*
> record of "oh, this will make things easier" garbage that doesn't
> work. By your own admission, you're going to be busy working on
> your phd soon.
If you really want to know, I'm already busy working on my PhD, but I
just realized that mastering the bureaucracy for setting the PhD joint
supervision between France and Italy and settling down in Italy, take
almost more energy. As things go, I might finally have a health
insurance in January, allowing me to be Italian residence, which I must
do before February to have the right to stay in Italy.
> That means that *I'll* be left explaining things
> to new contributors, trying to fix whatever build problems there
> are, trying to make it work in texi2html 1.84 or 2.0 or whatever
> number they give it when they intergrate it into texinfo... etc.
No, I already told that I'll still be available, even after January, to
reply on the mailing lists, but not to the extent of contributing . I
have 5 to 15 hours to spend for LilyPond a week, and most of this time
has been eaten on the mailing lists (I strive to maximize the accuracy
of my replies, which takes time) and integrating translations, so I had
to left over work on the build system.
> If the waf system was working... mao, if anybody was *working* on
> the waf system... and it had a good logging system for the
> doc-builds, good warnings, etc... then I'd consider it. If the
> current build system was working, and had been working continually
> for the past 3 months, I'd consider it. Oh, and what happened to
> the plan of merging the init files? Has that also been abandoned?
I was just answering a request from Dénes, I never proposed to implement
myself in the coming days, but it seemed important enough to me to bring
this publicly.
> I don't think I can express how unhappy I am with the build
> situation without going off into a huge curse-filled rant that
> wouldn't do anybody any good. So let's just pretend I did that,
> and know that I am /seriously/ pissed off at the stepmake system,
> the python scripts, the translations, and everybody who worked on
> this stuff in the past.
If you actually went into such a rant, this wouldn't make our docs build
system better or worse in any way. The translations are solidly
inegrated in LilyPond, and we have the build system we have, there is no
magic wand, nor any fairy
Re: bug rating
On 12/10/09 3:29 AM, "Graham Percival" wrote: > On Thu, Dec 10, 2009 at 02:15:21AM -0800, Mark Polesky wrote: >> Graham Percival wrote: >> > But if nobody is working on fixing them, who cares what the label > is?!?! > > The low vs. medium priority has historically been a mixture of > "bug severity" and "order that somebody might try to fix it in". > If somebody wants to go through all 350 bugs that are low and > medium, and prioritize them according to "how ugly do they look", > I don't care. > > Talking about this is SERIOUSLY in "rearranging the deck chairs > while the titanic sinks" territory (in case you didn't catch the > earlier reference). I don't know of any bug fixers who are > sitting around twiddling their thumbs. Instead, they're trying to > learn enough about the internals to fix the issue they're already > working on. As long as we're talking rearranging the deck chairs, in the hopes that a better arrangement will provide better guidance to those who can hardly wait to get started fixing a problem, I'd like to suggest that the importance of a bug is related to at least three factors (drawing inspiration from the RPN of FMEA : http://en.wikipedia.org/wiki/Failure_mode_and_effects_analysis): 1. Severity of the Bug. In descending order of severity, I can think of the following: Stops execution (i.e. Segfault) -- 10; Musically wrong output -- 8; Obviously ugly output -- 4 to 7; Minor nitpick errors -- 1 to 3. 2. Probability of occurrence of the bug. In descending order: Occurs in virtually all scores -- 10; Commonly occurs in scores -- 7; Occurs only rarely in very specific conditions -- 1 to 3, depending on the number of conditions that need to be met. 3. Difficulty of working around. In descending order: No known workaroundp -- 10; Workaround requires customization for every particular case (e.g. changing shape of slurs) -- 8; Workaround requires standard code at each occurrence (no customization required) -- 4-6, depending on code; Workaround requires code to be added once in the file -- 1-3. The overall Bug Priority Number would then show up as the product of the Severity, Probability, and Difficulty values. Of course, I'm not proposing that anybody stop fixing bugs in order to perform this calculation. I just wanted to get the thought in this thread in case we ever want to seriously approach this in the future Actually, I think that much of the disagreement about bug priorities comes because different people are thinking about different aspects of the bug. The one common point we have now is that segfaults get high priority. Thanks, Carl ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bug rating
Werner LEMBERG wrote: Wouldn't it be helpful if I could check the priority flag of the bugs to find something I should work on more urgently than other things? For example, the Savannah bugzilla allows users to `rate' bugs. The higher the score, the more people would like to have this bug fixed. That's actually possible, although not very prominently advertized. (Well, in fact it could be worse. Once you open a specific bug, you can request these "notifications" with several links.) It is a "vote [aka star, aka subscribe] for this bug" feature (first column in the bug list, if you're logged in), and you can show and sort by the "Stars" count column with "..." on the upper right. http://code.google.com/p/lilypond/issues/list?can=2&q=&sort=-stars&colspec=ID%20Type%20Status%20Priority%20Milestone%20Owner%20Summary%20Stars It's not too exciting, though, for now: Out of 336 bugs, only 18 have a voting count of > 3, with maximum 7, and about 50 have 3. And I suppose one vote is automatically assigned to the one who opened the bug. ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bug rating
On Thu, Dec 10, 2009 at 02:22:17PM +0100, Werner LEMBERG wrote: > > > - Low: the normal priority. Sorry, but we just don't have many bug > > fixers! I favor honesty over trying to make users happy about > > assigning their pet issue a "higher priority" flag that nobody > > pays attention to. > > Mhmm. Let's pretend that I'm Joe Neeman, and I have some time to fix > something (and I actually know what I'm doing). Wouldn't it be > helpful if I could check the priority flag of the bugs to find > something I should work on more urgently than other things? Yes. I'm sorry, I overreacted initially. If you would like to change the priority between postponed, low, and medium issues -- either raising the priority of a postponed or low one, or lowering the priority of a low or medium one -- go ahead. The current rankings between those three levels are not at all consistent or meaningful. My attitude (which has probably somewhat carried over to Valentin and James) was that as long as we had open high- and regression-priority issues, it didn't really matter what happened lower down. That was a mistake. The release list for 2.14 already contains an item to check existing bugs to see if they've been fixed without updating the database; perhaps I could ask the bug meisters to also re-evaluate the issue's priorities. I don't think we need an "annoying" tag; better classification between postponed/low/medium should be sufficient. The "is it easy to fix" tag is already indicated with the new Frog tag. Granted, nobody has looked at the code-related issues with this in mind, but if anybody wants to do this, the framework is there. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: [PATCH] Update & announcement
On Thu, Dec 10, 2009 at 03:09:28PM +0100, John Mandereau wrote: > I was just answering a request from Dénes, I never proposed to implement > myself in the coming days, but it seemed important enough to me to bring > this publicly. Ok. Let's just agree to disagree: you think it's important, but I don't think it's important. If somebody (be it you or Denes) writes a patch, I'm willing to test it on GUB. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bug rating
> If you would like to change the priority between postponed, low, and > medium issues -- either raising the priority of a postponed or low > one, or lowering the priority of a low or medium one -- go ahead. I'll eventually do that for my own bugs. However, it's basically the job of the bugmeister to handle this gracefully while adding the bug into the database. > The release list for 2.14 already contains an item to check existing > bugs to see if they've been fixed without updating the database; > perhaps I could ask the bug meisters to also re-evaluate the issue's > priorities. Yeah. > I don't think we need an "annoying" tag; better classification > between postponed/low/medium should be sufficient. Regarding the classification I disagree -- I still think it's too coarse --, but indeed there are more important things to do than to adjust the categories separately. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bug rating
> 1. Severity of the Bug. > 2. Probability of occurrence of the bug. > 3. Difficulty of working around. Very nice! > Of course, I'm not proposing that anybody stop fixing bugs in order > to perform this calculation. I just wanted to get the thought in > this thread in case we ever want to seriously approach this in the > future I suggest that we add just a two tags (with, say, three levels each) which covers 2. and 3. Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix Tracker 918, Add extra RemoveEmpty*StaffContext functions to support "Frenched" scores (issue165096)
Hi Ian,
LGTM, apart from some formatting issues and a few incorrect \version
numbers.
Can you sort out the naming of the new regression tests? For
consistency with the existing test, I'd advise amending them as follows:
hara-kiri-drumstaff.ly
hara-kiri-rhythmicstaff.ly
hara-kiri-tabstaff.ly
Cheers,
Neil
http://codereview.appspot.com/165096/diff/1/2
File input/regression/hara-kiri-drums.ly (right):
http://codereview.appspot.com/165096/diff/1/2#newcode1
input/regression/hara-kiri-drums.ly:1: \version "2.13.8"
2.13.9
http://codereview.appspot.com/165096/diff/1/2#newcode2
input/regression/hara-kiri-drums.ly:2: \header { texidoc =
I know you've just copied the existing example, but it is a bit messy;
it would be preferable to tidy things up here:
\header {
texidoc = "Hara-kiri ...
http://codereview.appspot.com/165096/diff/1/2#newcode14
input/regression/hara-kiri-drums.ly:14:
trailing whitespace
http://codereview.appspot.com/165096/diff/1/2#newcode18
input/regression/hara-kiri-drums.ly:18: ragged-right= ##t
ragged-right =
http://codereview.appspot.com/165096/diff/1/2#newcode26
input/regression/hara-kiri-drums.ly:26: \new DrumStaff \drummode { sn4
sn sn sn \break s1 \break sn4 sn sn sn \break sn sn sn sn}
\drummode {
sn4 sn sn sn \break
s1 break
sn4 sn sn sn \break
sn4 sn sn sn
}
etc.
http://codereview.appspot.com/165096/diff/1/3
File input/regression/hara-kiri-percent-repeat.ly (left):
http://codereview.appspot.com/165096/diff/1/3#oldcode8
input/regression/hara-kiri-percent-repeat.ly:8: \new Staff { c''1 c''
\break c'' c'' }
<<
\new Staff
etc.
http://codereview.appspot.com/165096/diff/1/3
File input/regression/hara-kiri-percent-repeat.ly (right):
http://codereview.appspot.com/165096/diff/1/3#newcode1
input/regression/hara-kiri-percent-repeat.ly:1: \version "2.13.8"
2.13.9
http://codereview.appspot.com/165096/diff/1/3#newcode4
input/regression/hara-kiri-percent-repeat.ly:4: texidoc = "Staves,
RhythmicStaves, TabStaves and DrumStaves with percent repeats are not
suppressed."
line too long
http://codereview.appspot.com/165096/diff/1/3#newcode10
input/regression/hara-kiri-percent-repeat.ly:10: \new TabStaff \repeat
percent 4 {c1}
\repeat percent 4 { c1 }
http://codereview.appspot.com/165096/diff/1/3#newcode11
input/regression/hara-kiri-percent-repeat.ly:11: \new DrumStaff
\drummode { \repeat percent 4 {hh1} }
{ hh1 }
http://codereview.appspot.com/165096/diff/1/3#newcode16
input/regression/hara-kiri-percent-repeat.ly:16: \context {
\RemoveEmptyStaffContext }
indent two spaces only:
\layout {
\context { \RemoveEmptyStaffContext }
http://codereview.appspot.com/165096/diff/1/4
File input/regression/hara-kiri-rhythmicstaves.ly (right):
http://codereview.appspot.com/165096/diff/1/4#newcode1
input/regression/hara-kiri-rhythmicstaves.ly:1: \version "2.13.5"
2.13.9
http://codereview.appspot.com/165096/diff/1/4#newcode2
input/regression/hara-kiri-rhythmicstaves.ly:2: \header { texidoc =
same formatting nitpicks as hara-kiri-percent-repeat.ly
http://codereview.appspot.com/165096/diff/1/4#newcode14
input/regression/hara-kiri-rhythmicstaves.ly:14:
trailing whitespace
http://codereview.appspot.com/165096/diff/1/5
File input/regression/hara-kiri-tabs.ly (right):
http://codereview.appspot.com/165096/diff/1/5#newcode1
input/regression/hara-kiri-tabs.ly:1: \version "2.13.5"
2.13.9
http://codereview.appspot.com/165096/diff/1/5#newcode3
input/regression/hara-kiri-tabs.ly:3: \header { texidoc =
same formatting nitpicks as hara-kiri-percent-repeat.ly
http://codereview.appspot.com/165096/diff/1/5#newcode15
input/regression/hara-kiri-tabs.ly:15: This example was done with a
pianostaff, which has fixed distance
This can be removed, since it's not true (and hasn't been for a long
time)
http://codereview.appspot.com/165096/diff/1/5#newcode18
input/regression/hara-kiri-tabs.ly:18:
trailing whitespace
http://codereview.appspot.com/165096/diff/1/6
File ly/engraver-init.ly (left):
http://codereview.appspot.com/165096/diff/1/6#oldcode1013
ly/engraver-init.ly:1013: RemoveEmptyRhythmicStaffContext= \context {
RemoveEmptyRhythmicStaffContext = \context {
http://codereview.appspot.com/165096/diff/1/6
File ly/engraver-init.ly (right):
http://codereview.appspot.com/165096/diff/1/6#newcode1012
ly/engraver-init.ly:1012: % Add RemoveEmpty*StaffContext function
definitions here
Remove this.
http://codereview.appspot.com/165096/diff/1/6#newcode1014
ly/engraver-init.ly:1014: RemoveEmptyDrumStaffContext= \context {
RemoveEmptyDrumStaffContext = \context {
http://codereview.appspot.com/165096/diff/1/6#newcode1028
ly/engraver-init.ly:1028: RemoveEmptyTabStaffContext= \context {
RemoveEmptyTabStaffContext = \context {
http://codereview.appspot.com/165096
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: the guide for contributors, or the guide for a contributor?
2009/12/8 Graham Percival : > I was amused by the recent "punctuation fix" commit: I've always > considered the CG to be "the guide for contributors", or "the > contributors's [sic] guide". In modern English, the latter is > abbreviated (condensed?) into "the contributors' guide". Easily amused, I see. :) Though I agree with your comments, I elected for "contributor's" simply because it required fewer changes. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Build failure on OS X: "error: template class without a name"
2009/12/9 Harmath Dénes : > Apparently, this got discussed in: > > http://www.mail-archive.com/fink-us...@lists.sourceforge.net/msg28916.html > http://www.mail-archive.com/fink-us...@lists.sourceforge.net/msg29280.html > > but without solution. Can this be filed as a bug? Is there a workaround? Have you tried the suggested fix from the second thread? Something like sed -i 's|__vector|lily_vector|g' flower/include/std-vector.hh might be worth a try. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: TextSpanners don't work in Dynamics context
2009/12/8 Werner LEMBERG : > > See issue #926. This makes the Dynamics context quite useless. Fixed in git. Cheers, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: accent and marcato shouldn't be quantized
2009/12/9 Trevor Daniels : > > Mark Polesky wrote Wednesday, December 09, 2009 9:05 AM >> > >> Wow. It's been just over 94 (and a half) *days* since my last transmission >> here. If > anyone is curious, I am still alive, > > Hi Mark - good to hear it ;) +1 I was beginning to wonder whether you'd suffered from burnout, such was the rate of patch production. :) > I wouldn't object, but we'd need a consensus from a > reasonable number of developers. No objections here. Regards, Neil ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: accent and marcato shouldn't be quantized
Neil Puttock wrote: > No objections here. Okay, I'll write a patch. But I just thought of something. Should the `espressivo' script also be de-quantized, since it's (in some ways) an extension of the accent sign? I'm not aware of any mention of the `espressivo' sign in any notation reference book, and humorously, the only meaningful hits when googling for "espressivo sign" are all from LP. Does anyone have a reference? If I don't hear from anyone, I'm leaning towards de-quantizing it too. Opinions? Thanks - Mark ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: accent and marcato shouldn't be quantized
On Thu, Dec 10, 2009 at 06:56:47PM -0800, Mark Polesky wrote:
> Okay, I'll write a patch. But I just thought of something.
> Should the `espressivo' script also be de-quantized, since
> it's (in some ways) an extension of the accent sign? I'm
> not aware of any mention of the `espressivo' sign in any
> notation reference book, and humorously, the only meaningful
> hits when googling for "espressivo sign" are all from LP.
It was added as a short-cut hack for
<< c1 {s4\< s s\> s\!} >>
I was somewhat surprised that the patch was accepted in the first
place, although part of the reason might have been because it was
a relatively new contributor. (IIRC -- this was 4 or 5 years
ago)
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: bug rating
On Thu, Dec 10, 2009 at 07:44:59PM +0100, Werner LEMBERG wrote: > > > Of course, I'm not proposing that anybody stop fixing bugs in order > > to perform this calculation. I just wanted to get the thought in > > this thread in case we ever want to seriously approach this in the > > future > > I suggest that we add just a two tags (with, say, three levels each) > which covers 2. and 3. In case it wasn't clear, I oppose this kind of thing; having four levels of bug priority is enough for lilypond. If we had a huge development team working on code to control the LHC, I'd definitely go with Carl's suggestions. One of the beauties of google code issues, in comparison to savannah and sourceforge's bug trackers, is the simplicity. I'm not going to throw that away by hacking extra lables onto it. Cheers, - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: accent and marcato shouldn't be quantized
Graham Percival wrote:
> It was added as a short-cut hack for
> << c1 {s4\< s s\> s\!} >>
So then I assume you're okay with me de-quantizing the
espressivo as well. Is the attached patch okay to apply, or
do I need to do anything described in CG 8.7 "Adding or
modifying features"? Should I add a @item to changes.tely?
- Mark
From 6194e64ca72ccd2ea98eee7d94a9af061ce97653 Mon Sep 17 00:00:00 2001
From: Mark Polesky
Date: Thu, 10 Dec 2009 20:35:36 -0800
Subject: [PATCH] script.scm: De-quantize accent, espressivo, and marcato scripts.
---
scm/script.scm |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/scm/script.scm b/scm/script.scm
index 652bbd6..731c7ea 100644
--- a/scm/script.scm
+++ b/scm/script.scm
@@ -21,7 +21,6 @@
. (
(avoid-slur . around)
(padding . 0.20)
- (quantize-position . #t)
(script-stencil . (feta . ("sforzato" . "sforzato")))
(side-relative-direction . ,DOWN)))
("accentus"
@@ -83,7 +82,6 @@
. (
(avoid-slur . around)
(padding . 0.20)
- (quantize-position . #t)
(script-stencil . (feta . ("espr" . "espr")))
(side-relative-direction . ,DOWN)))
@@ -146,7 +144,6 @@
(padding . 0.20)
(avoid-slur . inside)
;;(staff-padding . ())
- (quantize-position . #t)
(side-relative-direction . ,DOWN)))
("mordent"
. (
--
1.6.3.3
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: TextSpanners don't work in Dynamics context
>> See issue #926. This makes the Dynamics context quite useless. > > Fixed in git. Thanks! Werner ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
