Issue 1275 in lilypond: name+email for lily-git.tcl
Status: Accepted Owner: Labels: Type-Other Priority-Medium Maintainability Frog New issue 1275 by percival.music.ca: name+email for lily-git.tcl http://code.google.com/p/lilypond/issues/detail?id=1275 It would be nice if lily-git.tcl had a "setup" button (which is triggered automatically the first time it runs) which prompted the user for his name and email address (for commit author purposes). Frog: 2 hours, assuming no previous experience with tcl. I'd really like a frog to tackle this one, because it directly helps other frogs. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead to Ghostscript error in latest git
On 9/26/10 9:20 AM, "Trevor Daniels" wrote: > > > Carl Sorensen wrote Sunday, September 26, 2010 1:51 PM > >> Problems with a git build are reported on -devel, with a reference >> to a >> commit SHA1. > > Hm. Not sure a Bug Squad member should be expected to > determine the SHA1, if a bug is reported on -bug. > Forwarding to -dev should be sufficient. > I agree here. Then a developer can email the reporter if the bug can't be duplicated to get more information. Thanks, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1274 in lilypond: convert-ly does not warn about #'dash-period = #-1 for LyricHyphen
Updates:
Labels: -Type-Scripts -Priority-Critical -Regression Type-Enhancement
Priority-Medium
Comment #4 on issue 1274 by n.puttock: convert-ly does not warn about
#'dash-period = #-1 for LyricHyphen
http://code.google.com/p/lilypond/issues/detail?id=1274
But the IR says it should? ("3.1.57 LyricHyphen" -- 3.1.56 in the IR for
2.12.3)
There's only one description for a property, but for convenience, several
grobs may use the same property even if they use different code to handle
the property's behaviour. I agree it's confusing, but (AFAICT) there's
never been any deliberate support for hiding hyphens using
negative 'dash-period.
I see the behaviour in 2.12.3 isn't as strange as I originally thought:
it's an arithmetical fluke based on the span points, which are wider due to
the default position of the semibreve in the second bar. In 2.13, Joe
tweaked the code which sets the extra space in single-note bars, so the
notes are closer.
Whether the hyphens appear or not with negative 'dash-period is a matter of
luck dependent on the space calculated between hyphens. The following
snippets have no hyphens in 2.13.34:
\score {
\relative c'' {
c1 c8 c c c c c c c
}
\addlyrics {
la -- la
}
\layout {
\context {
\Lyrics
\override LyricHyphen #'dash-period = #-1
}
}
}
\score {
\relative c'' {
\override Score.NonMusicalPaperColumn #'full-measure-extra-space = #5
c1 c1
}
\addlyrics {
la -- la
}
\layout {
ragged-right = ##f
\context {
\Lyrics
\override LyricHyphen #'dash-period = #-1
}
}
}
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead toGhostscripterror in latest git
"Trevor Daniels" writes: > Phil Holmes wrote Sunday, September 26, 2010 6:26 PM > > >> - Original Message - >> From: "Trevor Daniels" >> >>> BTW, please don't reply to messages in newsgroups. >>> I don't subscribe to any and that makes them very >>> messy for me to reply to. >> >> >> Tricky. I _only_ use a newsreader for bugs and devel and so can't >> reply by mail to send it to the group and the original poster. > > Well, I had to copy out the message and reenter > appropriate email addresses to reply to yours. > Can't you do the same? With Emacs, it is a matter of doing C-c C-t after F . The followup will then be both sent to the nntp server as well as to the poster, marked as a "courtesy copy". -- David Kastrup ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead toGhostscripterror in latest git
Phil Holmes wrote Sunday, September 26, 2010 6:26 PM - Original Message - From: "Trevor Daniels" BTW, please don't reply to messages in newsgroups. I don't subscribe to any and that makes them very messy for me to reply to. Tricky. I _only_ use a newsreader for bugs and devel and so can't reply by mail to send it to the group and the original poster. Well, I had to copy out the message and reenter appropriate email addresses to reply to yours. Can't you do the same? Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead toGhostscripterror in latest git
- Original Message - From: "Trevor Daniels" [snip] Trevor BTW, please don't reply to messages in newsgroups. I don't subscribe to any and that makes them very messy for me to reply to. Tricky. I _only_ use a newsreader for bugs and devel and so can't reply by mail to send it to the group and the original poster. -- Phil Holmes ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Fw: Issue 1273 in lilypond: Woodwind Diagrams lead toGhostscripterror in latest git
Phil Holmes wrote" wrote in message news:i7ntha$vm...@dough.gmane.org... "Trevor Daniels" wrote in message news:f867cc5a71fc42b7b9f90fbb44692...@trevorlaptop... Carl Sorensen wrote Sunday, September 26, 2010 1:51 PM On 9/26/10 3:14 AM, "Trevor Daniels" wrote: Carl wrote Also, please note that we don't file bugs on any versions not yet released, because there really isn't a 2.13.35 yet. Why not? A bug which happened to have been noticed in a version compiled from git might have existed for some time. We don't expect the Bug Squad to do this research, do we? We expect the Bug Squad to test on the latest development release. OK. I see one of the actions for a Bug Squad member is to generate a png file demonstrating the problem. This clearly would demonstrate whether a problem which happened to be noticed in a git build was present in the latest GUB release. So I was wrong - we _do_ expect them to do this research. Presumably they should forward the report to -dev if the bug does not show in the latest GUB release. The original report said "does not work with lates git Lilypond 2.13.35 but works on 2.13.34-1". So my interpretation of this is that there is no bug on any release that most Bug Squad members could test to or generate output from. Yes, that's fine. I wasn't concerned with this particular issue, which was quite clear, but with the general procedure to deal with the case when a bug is reported on -bug which has been observed in a git build. This case is not covered explicitly in the CG. It seems it should either be forwarded to -dev or made the subject of a new issue depending on whether or not the bug manifests itself in the latest GUB build. Checking that and carrying out the appropriate action is a Bug Squad responsibility. Trevor BTW, please don't reply to messages in newsgroups. I don't subscribe to any and that makes them very messy for me to reply to. ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead to Ghostscripterror in latest git
"Graham Percival" wrote in message news:20100926170646.gc31...@futoi... On Sun, Sep 26, 2010 at 05:48:37PM +0100, Phil Holmes wrote: So nothing for a Bug Squad member to do Not quite -- you can (and should) mark such issues as Invalid as soon as they appear. 1) it wasn't added by a Bug Squad member or developer 2) it's not clearly a real bug. Two strikes and you're out. :) Cheers, - Graham It had already been marked Invalid by Carl, so nothing to do _at that point_ :-) It's three. -- Phil Holmes Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead to Ghostscripterror in latest git
On Sun, Sep 26, 2010 at 06:06:46PM +0100, Graham Percival wrote: > On Sun, Sep 26, 2010 at 05:48:37PM +0100, Phil Holmes wrote: > > >OK. I see one of the actions for a Bug Squad member > > >is to generate a png file demonstrating the problem. > > Overall, the task of the Bug Squad is to make sure that a claimed > bug is a real problem, and not just a user error. Wait, that was a bad summary. Let me try again: Overall, the task of the Bug Squad is to make sure that any issue in the tracker is a real problem, and to give feedback to bug reporters in a timely fashion (ideally within 24 hours). I know that we're not meeting that goal, but a few people are still learning the ropes. Certainly by the end of this year, I want the Bug Squad to be fulfilling that job. Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead to Ghostscripterror in latest git
On Sun, Sep 26, 2010 at 05:48:37PM +0100, Phil Holmes wrote: > "Trevor Daniels" wrote in message > news:f867cc5a71fc42b7b9f90fbb44692...@trevorlaptop... > > > >>We expect the Bug Squad to test on the latest development release. > > > >OK. I see one of the actions for a Bug Squad member > >is to generate a png file demonstrating the problem. Overall, the task of the Bug Squad is to make sure that a claimed bug is a real problem, and not just a user error. > >So I was wrong - we _do_ expect them to do this research. > >Presumably they should forward the report to -dev if the > >bug does not show in the latest GUB release. > > The original report said "does not work with lates git Lilypond > 2.13.35 but works on 2.13.34-1". So my interpretation of this is > that there is no bug on any release that most Bug Squad members > could test to or generate output from. Correct. To emphasize this point, we absolutely do not expect any Bug Squad member to compile source code. > So nothing for a Bug Squad member to do Not quite -- you can (and should) mark such issues as Invalid as soon as they appear. 1) it wasn't added by a Bug Squad member or developer 2) it's not clearly a real bug. Two strikes and you're out. :) Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead to Ghostscript error in latest git
On Sun, Sep 26, 2010 at 10:14:46AM +0100, Trevor Daniels wrote: > Carl wrote > > >Comment #2 on issue 1273 by Carl.D.Sorensen: Woodwind Diagrams > >lead to Ghostscript error in latest git > >http://code.google.com/p/lilypond/issues/detail?id=1273 > > >Also, please note that we don't file bugs on any versions not yet > >released, because there really isn't a 2.13.35 yet. > > Why not? A bug which happened to have been noticed in > a version compiled from git might have existed for some > time. We don't expect the Bug Squad to do this research, > do we? We expect the Bug Squad to check a reported bug in the latest official GUB build. We disregard bug reports from git versions (especially ghostscript-related oens) because most of the time those problems are related to somebody's specific system (in this case, the version of ghostscript) that aren't reproducable in GUB. Now, if somebody honestly has a build problem and reports the problem clearly, that's fine (and can be added as a type-Build issue). Cheers, - Graham ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead to Ghostscript error in latest git
Comment #3 on issue 1273 by percival.music.ca: Woodwind Diagrams lead to Ghostscript error in latest git http://code.google.com/p/lilypond/issues/detail?id=1273 Absolutely correct Carl, although I suggest a link to our official current bug page: http://lilypond.org/bug-reports ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead to Ghostscripterror in latest git
"Trevor Daniels" wrote in message news:f867cc5a71fc42b7b9f90fbb44692...@trevorlaptop... Carl Sorensen wrote Sunday, September 26, 2010 1:51 PM On 9/26/10 3:14 AM, "Trevor Daniels" wrote: Carl wrote Also, please note that we don't file bugs on any versions not yet released, because there really isn't a 2.13.35 yet. Why not? A bug which happened to have been noticed in a version compiled from git might have existed for some time. We don't expect the Bug Squad to do this research, do we? We expect the Bug Squad to test on the latest development release. OK. I see one of the actions for a Bug Squad member is to generate a png file demonstrating the problem. This clearly would demonstrate whether a problem which happened to be noticed in a git build was present in the latest GUB release. So I was wrong - we _do_ expect them to do this research. Presumably they should forward the report to -dev if the bug does not show in the latest GUB release. The original report said "does not work with lates git Lilypond 2.13.35 but works on 2.13.34-1". So my interpretation of this is that there is no bug on any release that most Bug Squad members could test to or generate output from. So nothing for a Bug Squad member to do - it's at this point solely an issue for the developers. If it appears in the released 13.35 then a bug report should appear on .bug and a Bug squad member will do the necessary to get it into the tracker. -- Phil Holmes Bug Squad ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: MetronomeMark #'break-align-symbols sometimes fails
On 26 September 2010 12:09, Xavier Scheuer wrote: > MetronomeMark #'break-align-symbols seems to fail with everything > (clef, left-edge, staff-bar, ...) except key-signature and > time-signature I'm afraid this is partly due to the way I fixed the bad alignment when key signatures are present (using Item::break_visible). I'm not sure what we can do about it though; while it's clearly a dubious hack to be checking break-visibility in the engraver (for Clef, it seems to be too early), there doesn't seem to be a sane alternative unless we defer the choice of alignment until later. Cheers, Neil ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1274 in lilypond: convert-ly does not warn about #'dash-period = #-1 for LyricHyphen
Comment #3 on issue 1274 by brownian.box: convert-ly does not warn about
#'dash-period = #-1 for LyricHyphen
http://code.google.com/p/lilypond/issues/detail?id=1274
This is a weird one, since it shouldn't work in 2.12.3
But the IR says it should? ("3.1.57 LyricHyphen" -- 3.1.56 in the IR for
2.12.3)
Well, great, i'm lost .-)
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead to Ghostscript error in latest git
Carl Sorensen wrote Sunday, September 26, 2010 1:51 PM On 9/26/10 3:14 AM, "Trevor Daniels" wrote: Carl wrote Also, please note that we don't file bugs on any versions not yet released, because there really isn't a 2.13.35 yet. Why not? A bug which happened to have been noticed in a version compiled from git might have existed for some time. We don't expect the Bug Squad to do this research, do we? We expect the Bug Squad to test on the latest development release. OK. I see one of the actions for a Bug Squad member is to generate a png file demonstrating the problem. This clearly would demonstrate whether a problem which happened to be noticed in a git build was present in the latest GUB release. So I was wrong - we _do_ expect them to do this research. Presumably they should forward the report to -dev if the bug does not show in the latest GUB release. Might be worth making this clear in the CG, as at present it's just a side effect of the actions in 7.5 Adding issues to the tracker. Problems with a git build are reported on -devel, with a reference to a commit SHA1. Hm. Not sure a Bug Squad member should be expected to determine the SHA1, if a bug is reported on -bug. Forwarding to -dev should be sufficient. Carl Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: MetronomeMark #'break-align-symbols sometimes fails
Hi all, When this gets fixed, I'm happy to up my sponsorship by C$50 -- this has definitely turned out to be more work than it first appeared. Thanks, Kieren. On 2010-Sep-26, at 08:43, Carl Sorensen wrote: > > > > On 9/26/10 5:09 AM, "Xavier Scheuer" wrote: > >> Hi Jan! >> >> No, I'm *not* obsessed with Tempo indications placement >> (or maybe, am I?)... ;-p >> Actually this time the issue was reported on the French-speaking >> mailing list, I'm just relaying it. >> >> MetronomeMark #'break-align-symbols seems to fail with everything >> (clef, left-edge, staff-bar, ...) except key-signature and >> time-signature. >> >> This (kind of) reopens issue #684, isn't it? > > No, please make a new issue. You have a new test file. > > Thanks, > > Carl > > > ___ > lilypond-devel mailing list > lilypond-de...@gnu.org > http://lists.gnu.org/mailman/listinfo/lilypond-devel > ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead to Ghostscript error in latest git
On 9/26/10 3:14 AM, "Trevor Daniels" wrote: > Carl wrote > >> Comment #2 on issue 1273 by Carl.D.Sorensen: Woodwind Diagrams >> lead to Ghostscript error in latest git >> http://code.google.com/p/lilypond/issues/detail?id=1273 > >> Also, please note that we don't file bugs on any versions not yet >> released, because there really isn't a 2.13.35 yet. > > Why not? A bug which happened to have been noticed in > a version compiled from git might have existed for some > time. We don't expect the Bug Squad to do this research, > do we? We expect the Bug Squad to test on the latest development release. This report said the code worked properly on the latest development release (2.13.34-1), but not in 2.13.35. But there *isn't* a 2.13.35. 2.13.35 is whatever I build on my machine based on latest git. It's a moving target. Problems with a git build are reported on -devel, with a reference to a commit SHA1. That way we can track it down, and hopefully get it fixed before a development release happens. Thanks, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: MetronomeMark #'break-align-symbols sometimes fails
On 9/26/10 5:09 AM, "Xavier Scheuer" wrote: > Hi Jan! > > No, I'm *not* obsessed with Tempo indications placement > (or maybe, am I?)... ;-p > Actually this time the issue was reported on the French-speaking > mailing list, I'm just relaying it. > > MetronomeMark #'break-align-symbols seems to fail with everything > (clef, left-edge, staff-bar, ...) except key-signature and > time-signature. > > This (kind of) reopens issue #684, isn't it? No, please make a new issue. You have a new test file. Thanks, Carl ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
MetronomeMark #'break-align-symbols sometimes fails
Hi Jan!
No, I'm *not* obsessed with Tempo indications placement
(or maybe, am I?)... ;-p
Actually this time the issue was reported on the French-speaking
mailing list, I'm just relaying it.
MetronomeMark #'break-align-symbols seems to fail with everything
(clef, left-edge, staff-bar, ...) except key-signature and
time-signature.
This (kind of) reopens issue #684, isn't it?
Sorry to come again with that. Many thanks for you attention
Cheers,
Xavier
\score {
\new Staff {
\tempo "MetronomeMark #'break-align-symbols"
\repeat unfold 8 c'1 \break
\override Score.MetronomeMark #'break-align-symbols = #'(clef)
\tempo "Clef does not work"
\repeat unfold 8 c'1 \break
\key g \major
\override Score.MetronomeMark #'break-align-symbols = #'(key-signature)
\tempo "KeySignature works (as well as TimeSignature)"
\repeat unfold 8 c'1 \break
\override Score.MetronomeMark #'break-align-symbols = #'(left-edge)
\tempo "Left-edge does not work"
\repeat unfold 8 c'1 \break
\override Score.MetronomeMark #'break-align-symbols = #'(staff-bar)
\tempo "Staff-bar does not work"
\repeat unfold 8 c'1 \break
}
}
--
Xavier Scheuer
___
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1150 in lilypond: RehearsalMark at start of line should not be printed above the clef
Comment #7 on issue 1150 by x.scheuer: RehearsalMark at start of line should not be printed above the clef http://code.google.com/p/lilypond/issues/detail?id=1150 Anyway, can't we use Neil's RehearsalMark #'X-offset = #shift-right-at-line-begin or RehearsalMark #'after-line-breaking = #(lambda (grob) ;; apply shift (shift-right-at-line-begin grob) ;; call default callback (ly:side-position-interface::move-to-extremal-staff grob)) as a solution (at least temporary)? It is indeed better than current behaviour, although there is no clear "solid reference" or "common practice", as pointed by Reinhold's list (BTW thank you Reinhold). Cheers, Xavier ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
Re: Issue 1273 in lilypond: Woodwind Diagrams lead to Ghostscript error in latest git
Carl wrote Comment #2 on issue 1273 by Carl.D.Sorensen: Woodwind Diagrams lead to Ghostscript error in latest git http://code.google.com/p/lilypond/issues/detail?id=1273 Also, please note that we don't file bugs on any versions not yet released, because there really isn't a 2.13.35 yet. Why not? A bug which happened to have been noticed in a version compiled from git might have existed for some time. We don't expect the Bug Squad to do this research, do we? Trevor ___ bug-lilypond mailing list bug-lilypond@gnu.org http://lists.gnu.org/mailman/listinfo/bug-lilypond
