Issue 1521 in lilypond: transition between full-length and shortened stems
Status: Accepted Owner: Labels: Type-Enhancement Priority-Medium Patch-review New issue 1521 by percival.music.ca: transition between full-length and shortened stems http://code.google.com/p/lilypond/issues/detail?id=1521 Janek prepared an excellent report, with two alternate patches, to improve our stem handling. http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00391.html We'll put a final patch on Reitveld when the developer community has decided on which notation they prefer. The patch-review label here refers to reviewing+discussion the type of output we want, rather than looking at an actual patch. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1477 in lilypond: suppress output for expected warnings
Comment #4 on issue 1477 by carl.d.s...@gmail.com: suppress output for expected warnings http://code.google.com/p/lilypond/issues/detail?id=1477 Many of the regtests are demonstrating a lack of segfaults on inappropriate input. Such cases *should* have warnings, IMO. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Windows versions have problems with accents in path
% Hi,
%
% The latest Windows versions have problems with accents
% (national characters) in the path or file name.
% MIDI is produced (if there is a \midi block), but no pdf.
%
% Take the following simple example, and put it into a folder called
% kórus (it means choir in Hungarian).
\version 2.13.50
\relative g' {
g1
}
% In the log it says this:
% Converting to `/kórus/example.pdf'...failed (0): gs: Invalid string in
argument vector at 10: Invalid byte sequence in conversion input
%
% This problem is present in the following Windows versions:
% 2.13.47, 2.13.48, 2.13.49, 2.13.50
% (Version 2.13.46 was OK.)
%
%
% Zoltan
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1522 in lilypond: Windows - problem with accented characters in file name
Status: Accepted Owner: Labels: Type-Build Priority-Critical Regression OpSys-Windows New issue 1522 by philehol...@googlemail.com: Windows - problem with accented characters in file name http://code.google.com/p/lilypond/issues/detail?id=1522 Zoltan Selyem reports: The latest Windows versions have problems with accents (national characters) in the path or file name. MIDI is produced (if there is a \midi block), but no pdf. A simple example gives: Converting to `/kórus/example.pdf'...failed (0): gs: Invalid string in argument vector at 10: Invalid byte sequence in conversion input He reports it as a regression between 13.46 and 13.47. Eluze reports: 2.13.47 and above have the error mentioned if the *file* has an accent. if the accent is only in the folder name it works! (Vista) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Windows versions have problems with accents in path
Zoltan Selyem s...@elte.hu wrote in message
news:1636763079.20110220144...@elte.hu...
% Hi,
%
% The latest Windows versions have problems with accents
% (national characters) in the path or file name.
% MIDI is produced (if there is a \midi block), but no pdf.
%
% Take the following simple example, and put it into a folder called
% kórus (it means choir in Hungarian).
\version 2.13.50
\relative g' {
g1
}
% In the log it says this:
% Converting to `/kórus/example.pdf'...failed (0): gs: Invalid string in
argument vector at 10: Invalid byte sequence in conversion input
%
% This problem is present in the following Windows versions:
% 2.13.47, 2.13.48, 2.13.49, 2.13.50
% (Version 2.13.46 was OK.)
%
%
% Zoltan
Thanks. http://code.google.com/p/lilypond/issues/detail?id=1522
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1523 in lilypond: Parenthesizing breath marks
Status: Accepted Owner: Labels: Type-Defect Priority-Low New issue 1523 by philehol...@googlemail.com: Parenthesizing breath marks http://code.google.com/p/lilypond/issues/detail?id=1523 Zoltan Selyem reports: Parenthesizing breath marks doesn't work as expected. The parentheses are next to the breath mark, not around it. This didn't work at all in 2.12 - no output was produced. The first version for which a parenthesis is produced at all is 13.41. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Slur + phrasing slur + line break
Selyem Zoltán s...@elte.hu wrote in message
news:879034749.20110220144...@elte.hu...
% Hi,
%
% After line breaks normal slurs begin before the key signature,
% and phrasing slurs begin after the key signature,
% therefore they cross each other.
%
% This is my main problem. However, it would also be great
% if they didn't cross each other in the first measure, either.
%
% It is also interesting why the first pair of slurs is up,
% and the second pair down, when the notes are the same...
\version 2.13.50
\paper { ragged-right = ##t }
\relative ges' {
\key des \major
\phrasingSlurDashed
ges4\(( f ges as |
bes as ges) f\) |
ges\(( f ges as | \break
bes as ges) f\)
}
%
%
% Zoltan
This looks very much like
http://code.google.com/p/lilypond/issues/detail?id=427
--
Phil Holmes
Bug Squad
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1524 in lilypond: Beaming eighth notes in threes in 3/4 time
Status: Accepted
Owner:
Labels: Type-Defect Priority-Critical
New issue 1524 by colinpkc...@gmail.com: Beaming eighth notes in threes in
3/4 time
http://code.google.com/p/lilypond/issues/detail?id=1524
Because of special rules regarding 3/4 time, grouping eighth notes in
threes is producing wrong results.
Reported by Nick Payne:
Shouldn't this example have the notes in the second bar beamed three
together and three together? What I'm getting is three, then one, then two:
\version 2.13.50
\relative c' {
\time 3/4
c8 c c c c c
\set beamExceptions = #'((end . (((1 . 8) . (3 3)
c c c c c c
}
Attachments:
test.preview.png 2.1 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1525 in lilypond: Autobeaming can require zero-length beat
Status: Accepted
Owner:
Labels: Type-Defect Priority-Critical
New issue 1525 by colinpkc...@gmail.com: Autobeaming can require
zero-length beat
http://code.google.com/p/lilypond/issues/detail?id=1525
Note that this may be related to issue 1524.
Report by Phil:
I'm no expert on this, but have just given the docs a good read, and the
Notation Ref says:
By default baseMoment is set to one over the denominator of the time
signature - so in this case, it's a quarter note. You're trying to set
beams on eighth note boundaries, so it won't work. You also need to add
\set Timing.beamExceptions = #'() to stop beamExcpetions taking over. That
said, I still think there may be a bug here, and would welcome a comment
from a beamMeister. The following gives the attached image:
\relative c' {
\time 3/4
c8 c c c c c
\set Timing.baseMoment = #(ly:make-moment 1 8)
\set Timing.beamExceptions = #'()
\set Timing.beatStructure = #'(3 3)
c c c c c c
\set Timing.beatStructure = #'(0 3 3)
c c c c c c
}
Carl:
This is also a bug. One should never need to make a zero-length beat to
affect autobeaming behavior. I don't know if it's the same bug or another
bug.
Phil's code is exactly what I would have written as the way to solve the
original request (except that I would have reversed the order of the
beamExceptions and beatStructure settings. I don't know why it didn't work.
Again, it may be an issue of the special rule for beaming 3/4 time.
If nobody else does it in the meantime, I'll investigate when I get the
time.
Attachments:
BeamExceptions.png 3.3 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1524 in lilypond: Beaming eighth notes in threes in 3/4 time
Comment #1 on issue 1524 by k-ohara5...@oco.net: Beaming eighth notes in
threes in 3/4 time
http://code.google.com/p/lilypond/issues/detail?id=1524
The built-in rule to end beams a beat seems to be active for the end of the
second beat (even though it shouldn't be). Workaround is to say 'please
let beams go across all three beats' :
\relative c' {
\time 3/4
c8 c c c c c
\set beatStructure = #'(3) % - workaround
\set beamExceptions = #'((end . (((1 . 8) . (3 3)
c c c c c c
}
Attachments:
1524.png 1.3 KB
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1513 in lilypond: Figured bass extenders do not line up
Comment #4 on issue 1513 by k-ohara5...@oco.net: Figured bass extenders do
not line up
http://code.google.com/p/lilypond/issues/detail?id=1513
I am surprised that the extender line broke at all. This construction
seems to be a leftover from temporarily turning off extenders to reprint
the natural after a line break.
Putting the line break back in, we see that ver 2.12.3 does not align the
extenders. It seems the alignment was accidental.
If we follow the advice of the manual, and have the FiguredBass timing
match that of the note columns above, we get a continuous extender line.
\new FiguredBass \figuremode{
_!2 \ext _!2 \ext % --remove this \ext to repeat natural (if line
breaks here)
_!4 \ext _!4 \ext _!2 |
}
The change in alignment is similar to closed issue 1438.
Attachments:
1513_stable.png 1.0 KB
1513_corrected.png 961 bytes
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1525 in lilypond: Autobeaming can require zero-length beat
Updates: Status: Fixed Owner: Carl.D.Sorensen Labels: fixed_2_13_51 Comment #1 on issue 1525 by carl.d.s...@gmail.com: Autobeaming can require zero-length beat http://code.google.com/p/lilypond/issues/detail?id=1525 Fixed in commit 5a3913b52a5ca1746e5e78b9c81de59fc57074ef Regtest in commit 70c0396d43070284d04f92aed43340388f1d343e ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1526 in lilypond: buliding only english docs
Status: Accepted Owner: Labels: Type-Build Priority-Medium Maintainability New issue 1526 by percival.music.ca: buliding only english docs http://code.google.com/p/lilypond/issues/detail?id=1526 When doc writers are working, they almost never want to have the translations built as well. It would be nice if this was possible. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1512 in lilypond: Page-label.ly regtest failure
Comment #4 on issue 1512 by k-ohara5...@oco.net: Page-label.ly regtest failure http://code.google.com/p/lilypond/issues/detail?id=1512 Comment 3 seems to show this as a duplicate of issue 997. Was Neil waiting for a second opinion before pushing the Duplicate button? (I can't push that button, under my login.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1477 in lilypond: suppress output for expected warnings
Comment #5 on issue 1477 by percival.music.ca: suppress output for expected warnings http://code.google.com/p/lilypond/issues/detail?id=1477 Colin: this is a longstanding complaint. The good news is that I've finally gotten around to adding it as issue 1526. The bad news is that everybody is petrified to touch the build system, so it'll most likely never get fixed. Carl: a segfault will stop the test (or doc) build, so it'll be really obvious. Besides that, we run diffs on the console output, so unless the message was buried in the 80%+ false positive text diffs, it could be found in the regtests comparison. Eventually we want to enable #(warnings-as-errors #t) in the regtests to make this even more obvious. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1523 in lilypond: Parenthesizing breath marks
Updates: Status: Invalid Comment #2 on issue 1523 by percival.music.ca: Parenthesizing breath marks http://code.google.com/p/lilypond/issues/detail?id=1523 Issues need sample code. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: abandoned bug reports
On Fri, Feb 18, 2011 at 11:24:48AM +0200, Dmytro O. Redchuk wrote: On Tue 15 Feb 2011, 18:26 Graham Percival wrote: (and do you have your email setup with the filtering we recommend in the CG?) No, actually it looks like this: i am flagging (shift+f in mutt) as important another new (which possibly discusses new issue which has not been added to the tracker yet) thread, reading all thread's messages thoroughly (for, yes, 30 seconds to let's say 90 seconds depending on the topic, the thread, my workload, conditions around me etc) and deciding whether i _possibly can_ deal with this problem or it is _too hard for me_ (next time is possible too). Hmm. If you get mail with fetchmail, I recommend adding this to your .procmailrc. If you're using imap, then I'm sure that gmail can do this kind of filtering for you already. :0 * ^List-ID: LilyPond Bug Reports bug-lilypond.gnu.org * @googlecode.com 0bug-lilypond-ignore Filtering out all those automatic messages cuts the messages to bug-lilypond by half, making it much easier to spot new issues. If i think i can (so, i am ~60 or more percents sure that i understand this issue and it is valid issue -- and there is no discussion with opposite opinions between people) -- i start to test it (sometimes i've added modified snippet, simplified or enhanced) and then add it to the tracker. If i think that i don't understand what's they're talking about -- i skip this thread (have it flagged, with a hope that sometime in the future i'll have better mood or conditions). Hmm. My hope is that the bug squad members *don't* do this. If you spend all 15 minutes dealing with issues that you understand, that's fine. But if you spend 5 minutes dealing with stuff you understand, then please spend 10 minutes dealing with stuff you *don't* understand. The way to deal with them is pretty easy! Look at the checklist: 5. If anything is unclear, ask the user for more information. That's it -- you've handled the email. After processing all threads this way -- i look into issues to verify. Please no. If there are any emails left -- ANY emails at all -- then process them. Dealing with emails takes COMPLETE priority over verifying issues. Remember that dealing with an email can just mean hitting reply and writing I'm sorry, but I do not understand this report. Can be please be more specific? Why do you think that the current output is incorrect? or something like that. Oh, well, regarding email setup in the CG: no, i didn't follow it. I have set up (mutt: local delivery + imap/google) a bunch of folders/filters/hooks, i don't want to register another google account, i am pretty happy with that what i have. I've read some 5 or 7 times that section, found it quite reasonable and helpful but decided that my own layout is good enough. ok. Just please adjust your priorities as mentioned above. Emails first. Writing I don't understand is a completely acceptable way to handle an email. Finish all emails before verifying issues. Of course, this goes for all the other bug squad members, too. And i think oh well somebody will understand this having spent much less effort, probably. Please don't do this. I'm asking for 15 minutes, once a week; nothing more, nothing less. If you've already spent that time, then of course don't do any more effort. But if you have time remaining, then please spend that remaining time trying to understand any remaining emails. (if your 15 minutes end while you're still in the middle of reading an email, that's fine -- just stop reading the email and abandon it for the next person! If you have a stopwatch or kitchen timer, I encourage you to do that. Pretend that you're boiling an egg[1]. Set your timer for 15 minutes, start handling emails, and when the timer beeps, immediately stop what you're doing!) [1] why yes, I'm a single male who doesn't know how long it takes to boil an egg. :) Would be great if: * ... bug-lilypond would be for reports, not discussions. Sometimes it's quite difficult to separate, but would be really _great_ if every kind person followed the rule (i invented it right now): If unsure [i mean not 93 or more percents sure] that this is a bug -- discuss in lilypond-user, or lilypond-devel *please*. As long as people don't change the subject line, I don't think this is a problem. If you see a long discussion, then quickly check through all the emails. If you see an email saying thanks, added as issue 1234, then stop reading and delete the whole email thread. * ... every issue report in the tracker would contain code to verify with. Yes, absolutely! My hope was that when bug squad members worked on verifying issues, they'd realize how important this was, and get pickier about making sure that their issue reports have sample code. That hasn't happened yet, but I'm still hopefuly. ps. About [in]competence -- working with issues can be good practice and
Re: Issue 1445 in lilypond: Doc: Snippet addition in NR 2.1 Vocal music
Updates: Labels: Patch-new Comment #2 on issue 1445 by percival.music.ca: Doc: Snippet addition in NR 2.1 Vocal music http://code.google.com/p/lilypond/issues/detail?id=1445 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1527 in lilypond: exact modal inversion
Status: Accepted Owner: Labels: Type-Enhancement Priority-Medium Patch-new New issue 1527 by percival.music.ca: exact modal inversion http://code.google.com/p/lilypond/issues/detail?id=1527 http://codereview.appspot.com/4173065/ ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1528 in lilypond: clarinet key names
Status: Accepted Owner: Labels: Type-Defect Priority-Medium Patch-new New issue 1528 by percival.music.ca: clarinet key names http://code.google.com/p/lilypond/issues/detail?id=1528 http://codereview.appspot.com/4182071 - still needs convert-ly work ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1477 in lilypond: suppress output for expected warnings
Comment #6 on issue 1477 by carl.d.s...@gmail.com: suppress output for expected warnings http://code.google.com/p/lilypond/issues/detail?id=1477 Graham: I've not made myself clear. We get an issue that causes a segfault, e.g. we're using skipTypesetting, and we've skipped all the music in the score. This causes a segfault. When we fix it, we issue a warning that says you've skipped all the music in the score. And that's what we want to have happen; we don't want it just go on and produce no output. So now, we need to have a regtest, and the regtest should produce a warning instead of a segfault. So we shouldn't have a policy of no warnings on regtests, or we won't be able to have good regtests for corner cases. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1477 in lilypond: suppress output for expected warnings
Comment #7 on issue 1477 by percival.music.ca: suppress output for expected warnings http://code.google.com/p/lilypond/issues/detail?id=1477 We'll have a separate directory for regtests which deliberately print console output. I know I mentioned that somewhere, although I can't find it immediately. It was probably just an email buried in a long thread somewhere. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1524 in lilypond: Beaming eighth notes in threes in 3/4 time
Updates: Status: Fixed Owner: Carl.D.Sorensen Labels: fixed_2_13_51 Comment #2 on issue 1524 by carl.d.s...@gmail.com: Beaming eighth notes in threes in 3/4 time http://code.google.com/p/lilypond/issues/detail?id=1524 Fixed in commit c1695321ac192515a7ddbcd10e259accfc333dc5 A regtest is also included. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1513 in lilypond: Figured bass extenders do not line up
Comment #5 on issue 1513 by carl.d.s...@gmail.com: Figured bass extenders do not line up http://code.google.com/p/lilypond/issues/detail?id=1513 Keith's comment above would certainly indicate to me that this should not be critical. It might even be invalid, because the sample code doesn't follow the NR recommended practice. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1477 in lilypond: suppress output for expected warnings
Comment #8 on issue 1477 by hanw...@gmail.com: suppress output for expected warnings http://code.google.com/p/lilypond/issues/detail?id=1477 'the regtest comparison is quite verbose, and generally contains tons of false warnings' Warnings are part of the functionality of the program, so they should be tested, rather than papered over. If you find that the regtest comparison generates false, diffs, can we adopt an issue to fix those false diffs instead? When running 'make test', most if not all warning output is diverted into log files anyway, so there isn't really a way to see those warnings; what are you complaining of exactly? To be more clear: I am proposing that the regtest is taken out of the scope of whatever this issue is about. I am fine with whatever you do to the docs, although I remain skeptical that you can build an effective warning suppression system without polluting the C++ code with lots of extra infrastructure. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Issue 1529 in lilypond: filename changing should not trigger a regtests comparison
Status: Accepted Owner: Labels: Type-Build Priority-Low Maintainability New issue 1529 by percival.music.ca: filename changing should not trigger a regtests comparison http://code.google.com/p/lilypond/issues/detail?id=1529 The regtest comparison looks at the console output of lilypond, but this means that whenever we a changed regtest, the filename changes, and then we get tons of useless -Writing to... +Writing to... see here for example: http://lilypond.org/test/v2.13.50-1/compare-v2.13.49-1/index.html It would be nice if these could be suppressed or ignored in the diff. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1477 in lilypond: suppress output for expected warnings
Comment #9 on issue 1477 by percival.music.ca: suppress output for expected warnings http://code.google.com/p/lilypond/issues/detail?id=1477 Sure! issue 1248 already exists for the weird Unbound variable: open-file warnings. I've just added issue 1529 for the filename diffs. NB: these are false diffs in the sense that the diff command is failing; there is definitely different console output. However, the difference in the console output is not helpful. (other than the open-file thing, which is just mysterious and bad) I'll take a look at the make test output. BTW -- although I personally added this issue to the tracker, it was raised by Werner and David: http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00378.html this particular case isn't just me being a whiny sod. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 737 in lilypond: Enhancement: support for footnotes and/or endnotes.
Updates: Owner: --- Labels: Patch-new Comment #1 on issue 737 by percival.music.ca: Enhancement: support for footnotes and/or endnotes. http://code.google.com/p/lilypond/issues/detail?id=737 Patch here: http://lists.gnu.org/archive/html/lilypond-devel/2011-02/msg00555.html ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1524 in lilypond: Beaming eighth notes in threes in 3/4 time
Updates: Status: Verified Comment #3 on issue 1524 by colinpkc...@gmail.com: Beaming eighth notes in threes in 3/4 time http://code.google.com/p/lilypond/issues/detail?id=1524 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1525 in lilypond: Autobeaming can require zero-length beat
Updates: Status: Verified Comment #2 on issue 1525 by colinpkc...@gmail.com: Autobeaming can require zero-length beat http://code.google.com/p/lilypond/issues/detail?id=1525 (No comment was entered for this change.) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1477 in lilypond: suppress output for expected warnings
Comment #11 on issue 1477 by percival.music.ca: suppress output for expected warnings http://code.google.com/p/lilypond/issues/detail?id=1477 Han-Wen - addition to comment 9: there's also weird linebreaks in some song- files (the linebreaks keep on appearing and disappearing between versions, issue 1507) ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1489 in lilypond: regtests should (normally) end on a barline
Updates: Status: Invalid Labels: -Frog -Maintainability Comment #2 on issue 1489 by percival.music.ca: regtests should (normally) end on a barline http://code.google.com/p/lilypond/issues/detail?id=1489 I am unable to find an example of the alleged spacing problem. I honestly thought that I had been seeing lots of changed regtests which didn't end on barlines, but I've now looked through every regtest comparison from 2.13.50 to 2.13.30, and I can't find a single comparison which had a significant number of such things. My sincere apologies to everybody involved, especially Janek. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1522 in lilypond: Windows - problem with accented characters in file name
Comment #1 on issue 1522 by pnorcks: Windows - problem with accented characters in file name http://code.google.com/p/lilypond/issues/detail?id=1522 Completely untested, but the only commit that appears to affect file names (between 2.13.46 and 2.13.47) is this one: http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=11d5b22d4eb69696b43e576db3d16793dd166d93 ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1522 in lilypond: Windows - problem with accented characters in file name
Comment #2 on issue 1522 by percival.music.ca: Windows - problem with accented characters in file name http://code.google.com/p/lilypond/issues/detail?id=1522 I assumed that the problem would have been in GUB -- but I see that I haven't done a git push --tags so nobody can see what changes we had. I'll do that when I'm at university tomorrow. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
