Re: 2.16 release candidate 3 imminent
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 21, 2012, at 10:15 PM, David Kastrup wrote:
m...@apollinemike.com m...@apollinemike.com writes:
On Jan 21, 2012, at 7:58 PM, David Kastrup wrote:
that all articulation events will be pulled out of NoteEvents or
RestEvents and broadcast at the iterator level.
There is such a thing as a chord articulation.
Why couldn't this distinction be captured via a different event name?
ChordArticulationEvent versus ArticulationEvent, for example.
Where would be the point?
To not make the distinction in the parser.
It is different input anyway, so the distinction is already there in the
input. If you would drop that distinction in the rules that early, you
would end up with chords being allowed as chord constituents.
I think that changing the parser should be a last resort if we can't
figure out a way to represent information through different event
classes.
I have trouble understanding what you call parser here.
What would really help are some before/after examples (ly code and/or
music streams and/or brief text like before the patch, you could not
do X, after, you can or this patch will allow me to experiment with
implementing X) would help a great deal. As if it were going into
the Change Log, for example.
It's a bit hard since the whole design (perfected by the
rhythmic-music-event) was intended to make no user-visible difference.
The music expression has just become predictable. You get an EventChord
iff ... has been in the input. You get articulations on NoteEvent
for pitch-postevent regardless whether or not this is part of a chord.
Why can't we treat c as shorthand for c?
Because inside of chords, it isn't a shorthand for c. And music
functions like \tweak need to work inside of chords as well (\tweak
currently even _fails_ if you apply it to c where LilyPond considers it
a shorthand for c and the corresponding passage in the NR is _really_
embarrassing to LilyPond as a system). See
URL:http://code.google.com/p/lilypond/issues/detail?id=2037#c3 for an
approach to make c as c work which ultimately went up in flames. It
is not like I did not seriously try that approach. It is a total
maintenance nightmare (and has logical fallacies you can't really iron
out) unless you forbid music functions inside of chords altogether.
It also makes user level programming tasks at the input side (and that's
really what music functions are) much harder and more intransparent if
you don't have predictable relations between input and music
expressions, and if you have to strip multiple layers before getting at
the information you actually wanted and that was straightforward in the
input.
Music expressions _represent_ the input, as opposed to stream events
which represent the typesetting task.
Having a compulsory wrapping around singletons is just as predictable
as no wrapping at all.
Except that inside of chords, there is no such wrapping, and a music
function does not know in advance where it is going to get used.
As for articulations being on a NoteEvent whether or not this is part
of a chord, I agree that this is a very good idea, but I think this
can be accomplished by wrapping everything in an event chord and
farming out the work to iterators.
Uh, we _are_ farming this out to the rhythmic event iterator. That was
its point. It was the missing link.
If you use \displayMusic on something that you might want to put into a
chord, you don't get wrong input. Tacking around a construct does
not change the structure of its inside. It is not necessary to tack
around a construct to make a \tweak work (which is a user-visible
change).
Why couldn't tweak make this distinction in the music function itself?
Why should it? Why should we strive to make programming a reliably
working music function as hard as possible?
The music function could check if its input is an EventChord and, if
so, feed it the first entry in the 'elements list of the EventChord.
This seems like a less intrusive change than changing the parser.
And what if there is more than one element?
Anyway, see above for an attempt to make a less intrusive change and get
inside chord functions work with the same argument parsing semantics as
normal music functions (after all, one does not know the difference).
It failed. A special inside-of-chord-mode for parsing music function
arguments is a total maintenance hog. Nobody will understand the code,
and more importantly, nobody will understand the behavior.
I have been deadlocked for about a month on further parser work by this.
You can use #{ #} for constructing material that ends up _inside_ of a
chord. Something like
\displayLilyMusic \displayLilyMusic ##{ c-. #}
does not go up in flames but just does what one would expect.
This is indeed an interesting case. Again, though, I would expect
this to fail, precisely because #{#} manipulates the
Re: music font
Graham Percival gra...@percival-music.ca writes: On Sun, Jan 22, 2012 at 12:05:46AM +0100, Xavier Scheuer wrote: I am not a developer, just a simple user. But I must say I am a bit disappointed no developer (except Janek) replied to your e-mail. And I'm a bit disappointed that you keep on whining about developers not doing what you want them to do. It simply is not my area of expertise, so it does not make sense for me to shift resources from my fulltime unpaid work on LilyPond to it. I'll have achieved more at the time my money and goodwill runs out when focusing on those parts I am most productive at. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music font
Thanks Janek for your suggestion. I'm looking at the gonville readme but it will take me some time to understand, I'll let you know. Of course I've tried some shortcuts before, I opened lilypond font (the 20pt weight) in a font-editor, modified some glyphs and dropped an otf replacing the old one. The result from lilypond seems unchanged but the output window says me this: [...] Interpretazione della musica... errore di programmazione: Errore FreeType: SFNT font table missing continua, incrociare le dita errore di programmazione: Errore FreeType: SFNT font table missing continua, incrociare le dita errore di programmazione: Errore FreeType: SFNT font table missing continua, incrociare le dita [...] roughly translated in english should be [...] processing music... programming error: FreeType Error: SFNT font table missing keep going, cross your fingers [...] as Janek says, the only way out seems to be trough the gonville source files. Il giorno 18/gen/2012, alle ore 00.27, Janek Warchoł ha scritto: 2012/1/9 Emilio Grazzi i...@emiliograzzi.com: Hi you all, i'm a (typo)graphic designer from Italy and i'm about to finish my dissertation about typography inside musical notation. I would like to apply my result inside lilypond like it was for the gonville font ( http://www.chiark.greenend.org.uk/~sgtatham/gonville/ ). The problem is that i'm not skilled in python, i use to create and modify each glyph with tools such fontlab, it drops out .otf fonts... From what i understand about Gonville, Python is not needed. It was only a means to create Gonville font files. It should be possible to change Lily default font files for your files, but i don't have any experience with that. Have you tried following the instructions in Gonville readme, but with your otf font files? hope this helps, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music font
Il 22/01/2012 09:40, Emilio Grazzi ha scritto: [...] Interpretazione della musica... errore di programmazione: Errore FreeType: SFNT font table missing continua, incrociare le dita errore di programmazione: Errore FreeType: SFNT font table missing continua, incrociare le dita errore di programmazione: Errore FreeType: SFNT font table missing continua, incrociare le dita [...] roughly translated in english should be Emilio, you can use this command and get the english output: LANG=C lilypond file.ly Or you can use Lilypond»Engrave custom in the latest version of Frescobaldi. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
After reading through this e-mail, I'm ok with the patch with one caveat about regtests (see below). On Jan 22, 2012, at 9:08 AM, David Kastrup wrote: Music expressions _represent_ the input, as opposed to stream events which represent the typesetting task. If this is truly the distinction, then I understand the need for the change. I didn't realize that music expressions needed to be one-to-one and onto representations of the input. And you currently _can't_, I repeat _can't_ write a music function (unless it gets a music argument created by the parser instead of just passed in from elsewhere) that can work like the input c inside of a chord as well as outside. Because outside, you need to produce c, and inside, you need to produce c. But without a music argument? No. Writing a music function called as \semitonesabovec #5 (or something like that) that will work both inside as well as outside of chords is just _impossible_ right now. It will be trivial afterwards. This is the part that I have the most trouble imagining, not because I don't trust you, but because I don't follow the code well enough to know how it would result in this. I'd like to see regtests in one of these commits that uses two or three simple functions in the form \foo c and \foo c that show this distinction. I thought that any music function could look through its argument, see if was an event chord or a note event, and act on it accordingly. So, for example (in pseudocode): #(define (bar music) (do-some-stuff-to music)) foo = #(define-music-function (parser location music) (if (eqv? (ly:music-property music 'name) 'EventChord) (bar (car (ly:music-property music 'elements))) (bar music))) The idea that a music function would be unmakable before this commit and makable after is, in my mind, the most solid argument for making this change. Like I say above, I'd need to see this in a regtest. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
I'd like to see regtests in one of these commits that uses two or three simple functions in the form \foo c and \foo c that show this distinction. I thought that any music function could look through its argument, see if was an event chord or a note event, and act on it accordingly. but the argument is the same, it's the environment of the function result that's different. the point is to not have to write two versions of each function, one to be used within chords and one outside. p ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
m...@apollinemike.com m...@apollinemike.com writes: After reading through this e-mail, I'm ok with the patch with one caveat about regtests (see below). On Jan 22, 2012, at 9:08 AM, David Kastrup wrote: Music expressions _represent_ the input, as opposed to stream events which represent the typesetting task. If this is truly the distinction, then I understand the need for the change. I didn't realize that music expressions needed to be one-to-one and onto representations of the input. And you currently _can't_, I repeat _can't_ write a music function (unless it gets a music argument created by the parser instead of just passed in from elsewhere) that can work like the input c inside of a chord as well as outside. Because outside, you need to produce c, and inside, you need to produce c. But without a music argument? No. Writing a music function called as \semitonesabovec #5 (or something like that) that will work both inside as well as outside of chords is just _impossible_ right now. It will be trivial afterwards. This is the part that I have the most trouble imagining, not because I don't trust you, but because I don't follow the code well enough to know how it would result in this. I'd like to see regtests in one of these commits that uses two or three simple functions in the form \foo c and \foo c that show this distinction. I thought that any music function could look through its argument, Please reread the above paragraph, in particular where I say without a music argument. see if was an event chord or a note event, and act on it accordingly. Without an argument you can look at, you can't choose your action accordingly. #(define-music-function (parser location music) (if (eqv? (ly:music-property music 'name) 'EventChord) (bar (car (ly:music-property music 'elements))) (bar music))) _Without_ a music argument. The idea that a music function would be unmakable before this commit and makable after is, in my mind, the most solid argument for making this change. Like I say above, I'd need to see this in a regtest. You can make a music function that will either work in chord context, or in music list context. And it can ask its music argument which of the two it is. I think \parenthesize does that. But that only works if there _is_ a music argument. It is possible that the operation of the music function parenthesize can be simplified in future, but it may require special behavior on EventChord anyway. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Jan 22, 2012, at 10:25 AM, David Kastrup wrote: Please reread the above paragraph, in particular where I say without a music argument. Sorry - I missed that. This is exactly the type of function that I'd like to see in the regtests. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
Am 21.01.2012 20:17, schrieb Carl Sorensen: On 1/21/12 11:47 AM, Marc Hohlm...@hohlart.de wrote: I must admit that I am lost here and do not quite understand what's going on, but will there be any difference between c\3 e\2 g\1 and c e g\3\2\1 once these changes are implemented? The latter would not display anything anywhere. Great! I'm not sure you actually will find it great (although I think it is more consistent). If we don't want to have string numbers show up in the music, but we need them for the tabstaff, right now we can do c e g\3\2\1 In the future,c e g\3\2\1 won't assign the string numbers to the tabstaff. (And in fact, I can't find this usage documented in the NR). Yes, I stumbled upon it while we were discussing some other problems concerning tablature, and I used this method to prevent the sting numbers showing up. \override StringNumber #'stencil = ##f yielded in errors (but I think this has changed recently), and simply setting \override StringNumber #'transparent = ##t still influenced the spacing for obvious reasons. Instead, as would be done regularly in lilypond, we would do \once \override StringNumber #'stencil = ##f c\3 e\2 g\1 This is consistent with how things are handled in lilypond, so I think we ought to move in this direction. As setting the stencil to false seems to work now, I agree with you that this is the more lilypondish way to go. Thanks for your explanations! Regards, Marc ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
m...@apollinemike.com m...@apollinemike.com writes:
After reading through this e-mail, I'm ok with the patch with one
caveat about regtests (see below).
On Jan 22, 2012, at 9:08 AM, David Kastrup wrote:
Music expressions _represent_ the input, as opposed to stream events
which represent the typesetting task.
If this is truly the distinction, then I understand the need for the
change. I didn't realize that music expressions needed to be
one-to-one and onto representations of the input.
They are an intermediate level. They don't _need_ to be anything.
Music functions are a useful tool for manipulating music at a level much
closer to input than stream events are. They are employed in _several_
layers in the parser: for postevents, for base material, inside of
chords. If they can do their work context independent, you don't need
to make them cater for different contexts.
In the context of writing music functions, #{ ... #} is a useful tool.
Since it fires up its own parser, its result is not context dependent.
You can't, for that reason, currently employ it usefully in chord
context.
If I write
myC =
#(define-music-function (parser location) () #{ c #})
then I can't currently write
\myC4 or similar. It would just not work. And there is no way to
define this function, #{ #} or not, in a manner that could work both in
chords as well as outside (without a Rhythmic Event iterator).
This is the part that I have the most trouble imagining, not because I
don't trust you, but because I don't follow the code well enough to
know how it would result in this. I'd like to see regtests in one of
these commits that uses two or three simple functions in the form \foo
c and \foo c that show this distinction.
Is the above simple enough?
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
David Kastrup d...@gnu.org writes:
If I write
myC =
#(define-music-function (parser location) () #{ c #})
then I can't currently write
\myC4 or similar. It would just not work. And there is no way to
define this function, #{ #} or not, in a manner that could work both in
chords as well as outside (without a Rhythmic Event iterator).
This is the part that I have the most trouble imagining, not because I
don't trust you, but because I don't follow the code well enough to
know how it would result in this. I'd like to see regtests in one of
these commits that uses two or three simple functions in the form \foo
c and \foo c that show this distinction.
Is the above simple enough?
If it isn't, try
myC=c
No need to even stoop to music functions. In this case, \myC will not
work without the change in parsing.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
If I write
myC =
#(define-music-function (parser location) () #{ c #})
then I can't currently write
\myC4 or similar. It would just not work. And there is no way to
define this function, #{ #} or not, in a manner that could work both in
chords as well as outside (without a Rhythmic Event iterator).
This is the part that I have the most trouble imagining, not because I
don't trust you, but because I don't follow the code well enough to
know how it would result in this. I'd like to see regtests in one of
these commits that uses two or three simple functions in the form \foo
c and \foo c that show this distinction.
Is the above simple enough?
If it isn't, try
myC=c
No need to even stoop to music functions. In this case, \myC will not
work without the change in parsing.
Actually, neither will it with the change. But it will be a one-liner
to make it work when it was impossible previously. I'll do that
one-liner presently.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
David Kastrup d...@gnu.org writes:
If I write
myC =
#(define-music-function (parser location) () #{ c #})
then I can't currently write
\myC4 or similar. It would just not work. And there is no way to
define this function, #{ #} or not, in a manner that could work both in
chords as well as outside (without a Rhythmic Event iterator).
myC=c
No need to even stoop to music functions. In this case, \myC will not
work without the change in parsing.
Actually, neither will it with the change. But it will be a one-liner
to make it work when it was impossible previously. I'll do that
one-liner presently.
Well, it was a bit more juggling in order to make sure that the parser
complains when an unsuitable music identifier gets used inside of
chords.
URL:http://codereview.appspot.com/5440084/diff2/19032:14005/lily/parser.yy
But it still was a _trivial_ change to make. It would have been trivial
before that, admittedly, but there would have been no obvious way to
actually set the music identifier to a value that could be used here, so
there would have been little point in doing so.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
I have to go in hold the horses mode now since I have a deadline for a LilyPond talk paper URL:http://chemnitzer.linux-tage.de/2012/info/index?cookielang=en coming up today (I already bargained an extension), and I need to get that finished in order to get it into print. So please accept my apologies that I can't defend this patch further today. It does not mean that I am not serious about it, and I definitely believe that if Graham double-checks the comments on this patch, he'll find the reason for our difference in test results. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
music-cause
Anybody actually using the music-cause? Inside of LilyPond, the only appearance (apart from its declaration) would be /* ES TODO: This is a temporary fix. Stream_events should not be aware of music. */ e-set_property (music-cause, self_scm ()); It would likely have some minor benefits in memory usage if this would be retired since the music events could be garbage collected after conversion to stream events. It is also conceptually cleaner. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music-cause
On Sun, Jan 22, 2012 at 11:49:06AM +0100, David Kastrup wrote: Anybody actually using the music-cause? Inside of LilyPond, the only appearance (apart from its declaration) would be /* ES TODO: This is a temporary fix. Stream_events should not be aware of music. */ e-set_property (music-cause, self_scm ()); If it's used anywhere, it would be here: http://lilypond.org/website/pdf/thesis-erik-sandberg It may have been added just so he could produce some graphs or tables or something? I know that I have a ton of graph-producing code in Artifastring and Vivi like that. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: music-cause
Graham Percival gra...@percival-music.ca writes: On Sun, Jan 22, 2012 at 11:49:06AM +0100, David Kastrup wrote: Anybody actually using the music-cause? Inside of LilyPond, the only appearance (apart from its declaration) would be /* ES TODO: This is a temporary fix. Stream_events should not be aware of music. */ e-set_property (music-cause, self_scm ()); If it's used anywhere, it would be here: http://lilypond.org/website/pdf/thesis-erik-sandberg It may have been added just so he could produce some graphs or tables or something? I know that I have a ton of graph-producing code in Artifastring and Vivi like that. Seems somewhat pointless since events take the whole mutable property list of their originating music event anyway. If you need more for tracking, you could just do maketrackable = #(define-music-function (parser location m) (music-map (lambda (m) (set! ly:music-property 'music-cause m) m) m)) and call that on your music before processing. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
checking 2240 (was: 2.16 release candidate 3 imminent)
On Sun, Jan 22, 2012 at 11:35:55AM +0100, David Kastrup wrote: So please accept my apologies that I can't defend this patch further today. It does not mean that I am not serious about it, and I definitely believe that if Graham double-checks the comments on this patch, he'll find the reason for our difference in test results. We seem to have a failure to communicate here. I shall be blunt, although I am not angry with you. I will not be doing any manual investigations about 2240 (or any other patch, for that matter). Part of the reason that we're in this miss is that we keep on saying oh, I'll do it manually just this once. If we had gotten serious about automating development tasks a year ago, we'd have saved at least 100 hours of developer time. I'm totally serious about that estimate; if anything I think I'm being conservative. I will therefore not do any manual fiddling around to test a patch or staging. Anything that fails the automatic process is rejected; if the process needs to be fixed, then fix the process. With respect to this patch, you have 4 options: - modify Patchy to do the appropriate build stuff. - recruit somebody else to modify Patchy for you. (I don't want to put Mike on the spot, but a week ago I sent him this same email and he fixed the relevant problem in Patchy, so he might be willing to modify Patchy for this) - skip the review process by manually marking it as Patch-review yourself. I do not object to this, but be aware that you are therefore vouching for the patch in a much more serious way. - abandon the patch. Choice is yours. (although of course there is no problem if nothing happens on this for a few days while you do other things) - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240 (was: 2.16 release candidate 3 imminent)
On Jan 22, 2012, at 12:44 PM, Graham Percival wrote: (I don't want to put Mike on the spot, but a week ago I sent him this same email and he fixed the relevant problem in Patchy, so he might be willing to modify Patchy for this) See spot run! Run spot run! I have compositions coming out the ears - will be able to work on LilyPond actively in a weekish. Cheers, MS ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
Graham Percival gra...@percival-music.ca writes: On Sun, Jan 22, 2012 at 11:35:55AM +0100, David Kastrup wrote: So please accept my apologies that I can't defend this patch further today. It does not mean that I am not serious about it, and I definitely believe that if Graham double-checks the comments on this patch, he'll find the reason for our difference in test results. We seem to have a failure to communicate here. I shall be blunt, although I am not angry with you. I will not be doing any manual investigations about 2240 (or any other patch, for that matter). If you have indeed stale files in your tree due to the stupid Rietveld way of working, you better not do automatic investigations about any other patch, either, until you have removed them. I will therefore not do any manual fiddling around to test a patch or staging. Anything that fails the automatic process is rejected; if the process needs to be fixed, then fix the process. _You_ refuse to run git clean because you don't want to risk having to run make test-baseline too often (it probably would not be affected). So you are not working with clean directories, and previous tests mess up the result. With respect to this patch, you have 4 options: - modify Patchy to do the appropriate build stuff. - recruit somebody else to modify Patchy for you. (I don't want to put Mike on the spot, but a week ago I sent him this same email and he fixed the relevant problem in Patchy, so he might be willing to modify Patchy for this) - skip the review process by manually marking it as Patch-review yourself. I do not object to this, but be aware that you are therefore vouching for the patch in a much more serious way. - abandon the patch. I am skipping the review in this case. I tested it back and forth on my system, and it is clear that this is a case of the automatic tests going wrong, very likely because of a dirty work tree left from a previous test and an error from git apply due to not actually fully applying the patch because of those residues getting left in place. If you don't remove the stale files from your work tree eventually, your test results will diverge further and further from reality. And you'll get problems whenever you test a patch that contains new files. Any revisions to those files will never make it from the Rietveld patch into your tree. -- David Kastrup ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 21/01/2012 2:48 PM, Graham Percival wrote: On Sat, Jan 21, 2012 at 02:28:15PM -0500, Julien Rioux wrote: I've already done so locally, and looking at the result of lilypond-book regtests, we already have new regressions: ok, good to know! I'm sure that you've done this already, but make sure that you actually try those version in 2.14.0 or 2.12.3 or whatever -- I wouldn't want to blindly assume that those tests actually worked when they were added to git. - Graham Well, as it turns out, I could not find any version on the website where those regtests looked normal. It looks like the lilypond-book regtests had not been checked in a long time. I also could not be bothered to compile 2.14 or older and try them. Nevermind, I fixed what I saw as obvious problems. Most of the fixes are really straight forward so if that's ok I'll push to staging directly. Can I push patches on the countdown for Jan 22 by now? -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Spelling fixes in comments and documentation (issue 5562043)
All these changes are very minor and harmless. Changes in translated files lay on English comments. http://codereview.appspot.com/5562043/diff/1/Documentation/po/cs.po File Documentation/po/cs.po (right): http://codereview.appspot.com/5562043/diff/1/Documentation/po/cs.po#newcode10524 Documentation/po/cs.po:10524: #~ msgstr Dudelsack-Definitionen Do not bother about spelling of deprecated strings. Harmless, but useless. http://codereview.appspot.com/5562043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix beaming-pattern for compound meters (issue 5545067)
Hi Carl, is this patch obsolete and replaced by http://codereview.appspot.com/5556054 ? If so, please close this issue. thanks, Janek http://codereview.appspot.com/5545067/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Fix issue 2228: Add option for strictBeatBeaming (issue 5556054)
LGTM. I'm not sure if the word flags should be used here. http://codereview.appspot.com/5556054/diff/2001/input/regression/beamlet-point-toward-beat.ly File input/regression/beamlet-point-toward-beat.ly (right): http://codereview.appspot.com/5556054/diff/2001/input/regression/beamlet-point-toward-beat.ly#newcode6 input/regression/beamlet-point-toward-beat.ly:6: belong. The first beam avoids sticking out flags (the default); sticking out beamlets i think? http://codereview.appspot.com/5556054/diff/2001/scm/define-context-properties.scm File scm/define-context-properties.scm (right): http://codereview.appspot.com/5556054/diff/2001/scm/define-context-properties.scm#newcode480 scm/define-context-properties.scm:480: beat structure even if it causes flags to hang out?) even if it causes flags ...beamlets? http://codereview.appspot.com/5556054/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On Sun, Jan 22, 2012 at 11:25:39AM -0500, Julien Rioux wrote: Well, as it turns out, I could not find any version on the website where those regtests looked normal. It looks like the lilypond-book regtests had not been checked in a long time. That's what I suspected. I also could not be bothered to compile 2.14 or older and try them. Nevermind, I fixed what I saw as obvious problems. Most of the fixes are really straight forward so if that's ok I'll push to staging directly. Sure, go ahead. Can I push patches on the countdown for Jan 22 by now? Colin's in Alberta, so he's 2 hours behind you. :) His last email didn't specify an exact time, but IIRC he generally uses 20:00 MST. I think it would be nice to wait until he gives the ok. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Some notes on 2240
I am currently writing a talk paper on recent developments in LilyPond
which contains a few developments that have not in good conscience
happened on more than my computer. I don't want to hold up 2240 on
them, however. I currently have
commit 8180dc91c26431e05913576cedfb9d92d64ce439
Author: David Kastrup d...@gnu.org
Date: Sun Jan 22 18:39:59 2012 +0100
parser.yy: strip music-wrapper-music inside of EventChord
This makes things like
fis \transpose c g fis
work.
commit 751aa4192c75e3bf2436bf2053e041f7d33a6d7d
Author: David Kastrup d...@gnu.org
Date: Sun Jan 22 15:08:37 2012 +0100
parser.yy: avoid creating empty articulations
on top of what is already in the review. The second one of those is
uncontroversial (it checks event lists to be non-empty before setting
the articulations property with them in order to avoid unnecessarily
set properties) and would usually just get pushed to staging without
review which is what I'll do when pushing 2240.
The top one would be actually useful in current LilyPond but would
likely look different in the parser (it changes the Event Chord
iterator). I'll put it up for review soonish, but it will be blocked on
2240.
Both problems were apparent while writing the article. The second in
results of \displayMusic, the first when presenting the example
tonika=fis'
{ \tonika \transpose c g \tonika }
(something which breaks in multiple ways in current LilyPond). Back to
writing.
--
David Kastrup
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
make doc problem
Hi all! Not only that I can no longer use -j on a first build (it is OK on the next builds), which means 40' for a make doc LANGS='fr' and about 2 hours for all languages, I now have to make doc-clean in order to view a corrected typo. I've tried a touch masterfile.tely before make doc but it doesn't change anything. Does anybody else experiment this as well? Cheers, Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Glyphs for Kievan Notation (issue 4951062)
http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc File lily/stem.cc (right): http://codereview.appspot.com/4951062/diff/99002/lily/stem.cc#newcode284 lily/stem.cc:284: string style = robust_symbol2string (heads[0]-get_property (style), default); I think Aleksandr is right. See http://lilypond.org/doc/v2.15/Documentation/contributor/comparison http://codereview.appspot.com/4951062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
- Original Message - From: Jean-Charles Malahieude lily...@orange.fr To: Lily Bugs bug-lilyp...@gnu.org; lilypond-devel lilypond-devel@gnu.org; Julien Rioux jri...@physics.utoronto.ca Sent: Sunday, January 22, 2012 6:19 PM Subject: make doc problem Hi all! Not only that I can no longer use -j on a first build (it is OK on the next builds), which means 40' for a make doc LANGS='fr' and about 2 hours for all languages, I now have to make doc-clean in order to view a corrected typo. I've tried a touch masterfile.tely before make doc but it doesn't change anything. Does anybody else experiment this as well? Cheers, Jean-Charles I've run a few with -j9 CPU_COUNT=9 this afternoon with no problems. The only oddity I've noticed is that make doc make doc now seems to rebuild a lot of files the second run. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 1:19 PM, Jean-Charles Malahieude wrote: Hi all! Not only that I can no longer use -j on a first build (it is OK on the next builds), which means 40' for a make doc LANGS='fr' and about 2 hours for all languages, I now have to make doc-clean in order to view a corrected typo. I've tried a touch masterfile.tely before make doc but it doesn't change anything. Does anybody else experiment this as well? Cheers, Jean-Charles Hi Jean-Charles, I can't run -j, I have a single core. Can you please report more precisely why you can no longer use it? The second issue I have not seen. If I correct a typo in a file in Documentation then make doc will rebuild it. OK I should check Documentation/fr right now... Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 1:30 PM, Phil Holmes wrote: I've run a few with -j9 CPU_COUNT=9 this afternoon with no problems. The only oddity I've noticed is that make doc make doc now seems to rebuild a lot of files the second run. -- Phil Holmes I've hit a roadblock with issue 2125 which attempted to fix that make doc; make doc problem. With that patch, on my machine the second make doc reports `nothing to be done'. So it works on my machine but not yours and I haven't quite figured it out yet. Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
- Original Message - From: Julien Rioux jri...@physics.utoronto.ca To: Phil Holmes m...@philholmes.net Cc: Jean-Charles Malahieude lily...@orange.fr; LilyPond Bugs bug-lilyp...@gnu.org; LilyPond Devel lilypond-devel@gnu.org Sent: Sunday, January 22, 2012 6:35 PM Subject: Re: make doc problem On 22/01/2012 1:30 PM, Phil Holmes wrote: I've run a few with -j9 CPU_COUNT=9 this afternoon with no problems. The only oddity I've noticed is that make doc make doc now seems to rebuild a lot of files the second run. -- Phil Holmes I've hit a roadblock with issue 2125 which attempted to fix that make doc; make doc problem. With that patch, on my machine the second make doc reports `nothing to be done'. So it works on my machine but not yours and I haven't quite figured it out yet. Regards, Julien Please shout if you want logfiles or testing. I can run tests fairly quickly if I've got my lily machine up and running. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
Hi, 2012/1/22 David Kastrup d...@gnu.org: Graham Percival gra...@percival-music.ca writes: With respect to this patch, you have 4 options: - modify Patchy to do the appropriate build stuff. - recruit somebody else to modify Patchy for you. [...] [Patchy's automated testing got confused by stale files in its work tree and will not be accurate in a timely manner. If you are testing from a Rietveld patch (actually any patch), please use git apply --index for applying the patch so that git sees newly added files in the worktree and will remove them when you do git reset --hard] How to modify Patchy? In an old e-mail i've found a link to what looks like Patchy source code https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py and i'm preparing a patch addressing David's advice, but i haven't found how patches for Patchy are announced, reviewed and pushed. Do i need to create a github account? cheers, Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
On Sun, Jan 22, 2012 at 07:58:09PM +0100, Janek Warchoł wrote: In an old e-mail i've found a link to what looks like Patchy source code https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py Correct. and i'm preparing a patch addressing David's advice, but i haven't found how patches for Patchy are announced, reviewed and pushed. Do i need to create a github account? Ideally you'd create a github account and then I can let you push directly. Otherwise, just send me or Mike a patch and we can push it for you. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 1:32 PM, Julien Rioux wrote: The second issue I have not seen. If I correct a typo in a file in Documentation then make doc will rebuild it. OK I should check Documentation/fr right now... When I edit Documentation/fr/essay/literature.itely and issue a make doc from within build/Documentation/fr then Documentation/fr/essay.tely is recompiled. I can see the result in Documentation/fr/out-www/essay/* and in Documentation/out-www/essay.fr.* [1] Please report in more details the problems that you encounter, e.g. which file are you modifying and how are you calling make. Thanks, Regards, Julien [1] Big side note: It doesn't work flawlessly: notation.tely and a bunch of other manuals are also recompiled when they shouldn't, since I didn't touch any of their source files. This problem I trace back to the CHAIN_RULE in make/ly-rules.make, which I didn't dare touch up to now. This rule states that web depends on usage depends on notation depends on... etc. so that only one instance of lilypond-book is running at once on any given manual. As a side-effect it means that manuals depend on each other when that isn't in fact the case. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 2:11 PM, Jean-Charles Malahieude wrote: What I've done to check is: open Documentation/fr/usage/running.itely add the five X at the beginning of the first text line XCe chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. save it and make -j3 doc LANGS='fr' File out-www/offline-root/Documentation/usage/running-lilypond.fr.html still shows Ce chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. -- Jean-Charles You're right, I forgot that I caused that. Give me a moment I will push the fix to staging... Regards, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
2012/1/22 Graham Percival gra...@percival-music.ca: On Sun, Jan 22, 2012 at 07:58:09PM +0100, Janek Warchoł wrote: i'm preparing a patch addressing David's advice, but i haven't found how patches for Patchy are announced, reviewed and pushed. Do i need to create a github account? Ideally you'd create a github account Done: janek-warchol and then I can let you push directly. No review? I hope i won't screw anything up. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 2:15 PM, Julien Rioux wrote: On 22/01/2012 2:11 PM, Jean-Charles Malahieude wrote: What I've done to check is: open Documentation/fr/usage/running.itely add the five X at the beginning of the first text line XCe chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. save it and make -j3 doc LANGS='fr' File out-www/offline-root/Documentation/usage/running-lilypond.fr.html still shows Ce chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. -- Jean-Charles You're right, I forgot that I caused that. Give me a moment I will push the fix to staging... Regards, Julien Done: 930dbeff8f5d31faa9654365c8ed84a30e489e83 Hope this fixes it for you as well. Thanks, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
One quick question: Patchy checks patches one at a time, doesn't it? I.e. applies a patch (doesn't commit), tests, unapplies and moves to another patch? Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
On Sun, Jan 22, 2012 at 08:16:59PM +0100, Janek Warchoł wrote: 2012/1/22 Graham Percival gra...@percival-music.ca: Ideally you'd create a github account Done: janek-warchol and then I can let you push directly. No review? I hope i won't screw anything up. ok, you have push ability now. You don't need to use it unless you want to; you can send a patch for people to look at. - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
Le 22/01/2012 20:22, Julien Rioux disait : On 22/01/2012 2:15 PM, Julien Rioux wrote: On 22/01/2012 2:11 PM, Jean-Charles Malahieude wrote: What I've done to check is: open Documentation/fr/usage/running.itely add the five X at the beginning of the first text line XCe chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. save it and make -j3 doc LANGS='fr' File out-www/offline-root/Documentation/usage/running-lilypond.fr.html still shows Ce chapitre passe en revue ce qui se passe lorsque vous lancez LilyPond. -- Jean-Charles You're right, I forgot that I caused that. Give me a moment I will push the fix to staging... Regards, Julien Done: 930dbeff8f5d31faa9654365c8ed84a30e489e83 Hope this fixes it for you as well. Yes, many thanks! -- Jean-Charles ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
On Sun, Jan 22, 2012 at 08:43:26PM +0100, Janek Warchoł wrote: One quick question: Patchy checks patches one at a time, doesn't it? I.e. applies a patch (doesn't commit), tests, unapplies and moves to another patch? ... why are you asking this question? Is the source code really *that* hard to read? It's 18 lines! https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py#L282 for patch in patches: issue_id = patch[0] patch_filename = patch[1] title = patch[2] print Trying %i with %s % (issue_id, patch_filename) try: autoCompile.configure() autoCompile.patch(patch_filename) autoCompile.build(quick_make=True, issue_id=issue_id) autoCompile.regtest_check(issue_id) autoCompile.copy_regtests(issue_id) autoCompile.make_regtest_show_script(issue_id, title) # reverse stuff autoCompile.patch(patch_filename, reverse=True) autoCompile.regtest_clean(issue_id) autoCompile.clean(issue_id) except Exception as err: print Problem with issue %i % issue_id print err - Graham ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
On 22/01/2012 2:38 PM, David Kastrup wrote: Julien Riouxjri...@physics.utoronto.ca writes: I can't run -j, I have a single core. This is factually incorrect. You can run -j just fine, but you can't expect much of a speedup. On a single-core machine, make -j 2 typically gives you a speedup of maybe 15% (given sufficient memory) since the CPU can keep busy on processing a second job when the other job is waiting for the disk to provide new input. More importantly, you'll get to see the same kind of problems that the true multi-core people experience when using -j. So very much recommended for testing. Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. -- Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
2012/1/22 Graham Percival gra...@percival-music.ca: why are you asking this question? Is the source code really *that* hard to read? It's 18 lines! Hey, i'm not a pro programmer. There are so many brilliant programmers here that my self-confidence is quite low; this is second time i read Python and first time i read building scripts. And i don't want to do some stupid mistake, break Patchy and cause unexpected damage to origin/staging and/or origin/master, which would result in more problems that i'm trying to solve. https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py#L282 for patch in patches: issue_id = patch[0] patch_filename = patch[1] title = patch[2] print Trying %i with %s % (issue_id, patch_filename) try: autoCompile.configure() autoCompile.patch(patch_filename) autoCompile.build(quick_make=True, issue_id=issue_id) autoCompile.regtest_check(issue_id) autoCompile.copy_regtests(issue_id) autoCompile.make_regtest_show_script(issue_id, title) # reverse stuff autoCompile.patch(patch_filename, reverse=True) autoCompile.regtest_clean(issue_id) autoCompile.clean(issue_id) except Exception as err: print Problem with issue %i % issue_id print err Yes, i've read this 2 times. If i didn't i wouldn't ask the question. Janek. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
On 22/01/2012 3:00 PM, Janek Warchoł wrote: 2012/1/22 Graham Percivalgra...@percival-music.ca: why are you asking this question? Is the source code really *that* hard to read? It's 18 lines! Hey, i'm not a pro programmer. There are so many brilliant programmers here that my self-confidence is quite low; this is second time i read Python and first time i read building scripts. And i don't want to do some stupid mistake, break Patchy and cause unexpected damage to origin/staging and/or origin/master, which would result in more problems that i'm trying to solve. https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py#L282 for patch in patches: issue_id = patch[0] patch_filename = patch[1] title = patch[2] print Trying %i with %s % (issue_id, patch_filename) try: autoCompile.configure() autoCompile.patch(patch_filename) autoCompile.build(quick_make=True, issue_id=issue_id) autoCompile.regtest_check(issue_id) autoCompile.copy_regtests(issue_id) autoCompile.make_regtest_show_script(issue_id, title) # reverse stuff autoCompile.patch(patch_filename, reverse=True) autoCompile.regtest_clean(issue_id) autoCompile.clean(issue_id) except Exception as err: print Problem with issue %i % issue_id print err Yes, i've read this 2 times. If i didn't i wouldn't ask the question. Janek. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel Hi Janek, The autoCompile.patch part is defined here: https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py#L140 You'll see that the code uses git apply filename.patch and git apply --reverse filename.patch I think that is what you would like to modify following the suggestions on this thread. Cheers, Julien ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: make doc problem
Hello, On 22 January 2012 20:05, David Kastrup d...@gnu.org wrote: Julien Rioux jri...@physics.utoronto.ca writes: Thanks, you're quite right CPU is not the limiting factor for the build. Disk access and usage of swap when compiling input/regression/collated-files slows down the build to a crawl for me. If it is really usage of swap: getting more memory will be by far the cheapest method of speeding up your computer much more than buying a faster CPU ever could. getting an SSD will also help if you have run out of memory slots to fill. -- -- James ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: checking 2240
Hi Julien, 2012/1/22 Julien Rioux jri...@physics.utoronto.ca: Hi Janek, The autoCompile.patch part is defined here: https://github.com/gperciva/lilypond-extra/blob/master/patches/compile_lilypond_test.py#L140 You'll see that the code uses git apply filename.patch and git apply --reverse filename.patch I think that is what you would like to modify following the suggestions on this thread. Yes, i've done changes already. Currently i'm stuck at telling github to create a nicely formatted patch file which i could send for review :/ thanks :) Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
a patch for Patchy (was: Re: checking 2240)
Hi, i don't see a way to create a patch file using github, so i've send Graham a pull request and i hope it will be ok. The changes i suggest can be seen here: https://github.com/janek-warchol/lilypond-extra/commit/301c42579299d62fb24af4fa0ea950b158649da3 Graham, if you don't want to bother about pull requests, review these changes and i'll push directly to your repository. Janek PS thanks again for your e-mail, Julien, you encouraged me not to be stopped by strange github features ;) ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: 2.16 release candidate 3 imminent
On 12-01-22 10:19 AM, Graham Percival wrote: On Sun, Jan 22, 2012 at 11:25:39AM -0500, Julien Rioux wrote: Well, as it turns out, I could not find any version on the website where those regtests looked normal. It looks like the lilypond-book regtests had not been checked in a long time. That's what I suspected. I also could not be bothered to compile 2.14 or older and try them. Nevermind, I fixed what I saw as obvious problems. Most of the fixes are really straight forward so if that's ok I'll push to staging directly. Sure, go ahead. Can I push patches on the countdown for Jan 22 by now? Colin's in Alberta, so he's 2 hours behind you. :) His last email didn't specify an exact time, but IIRC he generally uses 20:00 MST. I think it would be nice to wait until he gives the ok. - Graham Go ahead, Julien: with Graham's blessing, there's no need to wait for a few hours. 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: a patch for Patchy (was: Re: checking 2240)
2012/1/22 Janek Warchoł janek.lilyp...@gmail.com: suggested changes for Patchy, which should help dealing with untracked files like in issue 2240, are here: https://github.com/janek-warchol/lilypond-extra/commit/301c42579299d62fb24af4fa0ea950b158649da3 This patch fails, Patchy exits with lily@gperciva-desktop:~/src/lilypond-extra/patches$ ./test-patches.py Trying issue 803 Found patch: (803, '/home/lily/src/lilypond-extra/patches/issue5564043_1.diff', 'correction needed for the German translation of convert-ly') Trying 803 with /home/lily/src/lilypond-extra/patches/issue5564043_1.diff fatal: --index outside a repository Problem with issue 803 Failed patch: /home/lily/src/lilypond-extra/patches/issue5564043_1.diff my discussion about this with Graham and Julien is here https://github.com/gperciva/lilypond-extra/pull/8# Help in solving this will be appreciated. I'm going offline now, see you tomorrow evening. Janek ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
User vs Developer: Round 2 (and half-time?) (was: Re: music font)
This is a split reply from the thread music font. http://lists.gnu.org/archive/html/lilypond-devel/2012-01/msg00752.html The title is a reference to the fist Users versus developers flame war of which I appear to be also at the origin. http://lists.gnu.org/archive/html/lilypond-user/2009-05/msg00551.html Dear Graham, dear Developers, On 22 January 2012 00:35, Graham Percival gra...@percival-music.ca wrote: And I'm a bit disappointed that you keep on whining about developers not doing what you want them to do. Argh, bitten by the red ants' queen! I guess I asked for it. I am not your slave. The fact that I have volunteered thousands of hours working on lilypond does not make me your slave. I am really sorry if I have hurt some of you, that was not my intention. I did not crawl out of my mother's womb knowing about lilypond internals, or even about programming at all. Any knowledge I have was from hard work: reading source code, reading public emails on the list archives, and learning about programming in general. I am a bit dissapointed that *you* have not done that. Please do not consider users as under men. We use LilyPond—probably more often than some developers—and hence are fully aware of its strengths, but also of its missing features, most annoying bugs, etc. Yes I am a simple user, not developing, programming and doing all this hard work. I admit I have currently higher priorities than learning Scheme, C++, etc. I *use* LilyPond, I try to help in a certain way (see below), I promote LilyPond around me and make scores for my university orchestra using LilyPond. I do not pretend to the title of Lead Developer, Release Meister or whatever. If we report issues, regressions and make new features requests, it is not simply because we wallow in keep on whining or because we take a sadistic pleasure in giving some more work to the developers. I use LilyPond quite often, I try to help users both on the French users mailing list and on the international one. I report bugs, regressions, make new feature request, both from my experience with LilyPond and making the link between Developers/Users from the international lists and French Users on lilypond-user-fr (by announcing in French new features, fixed issues, important ongoing discussions French user might be concerned about, but also in the reverse way, by transmitting upstream issues discovered by French users or popular requests in the French users community). Yesterday I posted several messages on different LilyPond mailing lists. I replied to some users' questions/issues, I reported a regression bug type-critical and… I started a fight with Graham! I received at the same time thanks you from users (in English and French) and infuriation from devel. I received also acknowledgements and congratulations about the quality of the score I made with LilyPond from musicians of my orchestra. You want something done? Do it yourself. That's what open source means -- you have the legal right to do it yourself. It does not mean that other people are obligated to do it for you. I understand LilyPond is an open source project, lead by volunteers. That's why I do not complaint when I have to send by three times a bug report because it was first lost/forgotten, why I never *demand* developers to fix an issue, even if it is one that is really annoying my ego in almost every score I typeset. Sometimes when an issue has been unfixed for years and when I see people often being troubled by this issue I post a message stating it and thus moving this issue from the bottom of the pile. And sometimes a kind developer see this issue and start fixing it! :-) You have la liberté, not royauté. Users usually never get any kind of acknowledgements or sign of gratitude from developers for volunteering [also] few hours trying to help other users, reporting back issues/requests, trying to make the link between high skilled developers and lambda user. I expressed my deep feelings. Yes I was disappointed, like when I see a reply like a RTFM smack in the face of a new user, or as a no as only-argument answer to a request/suggestion. My main goal was to attract attention to Emilio's nice project of music font with LilyPond. I attracted Graham's attention on me instead. I guess my message was as much discouraging (or even more) as being told each time you make a suggestion You want something done? Do it yourself. Learn programming!. I do not want to fight with some developers. I think we all have the same objective: to improve LilyPond. And each one has its own way to contribute, at different levels and different implications. I would be delighted to offer our finest Belgian beer to LilyPond developers which I could meet at FOSDEM 2012. I am afraid my student budget does not allow me to pay developers to work full time on LilyPond. Cheers, Whining Xavier -- Xavier Scheuer x.sche...@gmail.com
Re: Glyphs for Kievan Notation (issue 4951062)
Regarding comments by Jan: I guess it should be 2.5 staff_space or something I changed the depth and height parameters as you suggested. However, I do not see any difference, in the reg tests or in my test files. Are we sure that the entire glyph has to fit within the char_box, including the stem? Regarding comments by Neil and Bertrand: I rewrote Stem::is_normal_stem the way Neil suggested. Looking at the code in Stem.cc, it appears that both ways are being used to check the style property. I don't know which is the more correct. http://codereview.appspot.com/4951062/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
PATCH: Countdown completed
With my apologies for clearing the send email flag on the individual issues, the following have had their countdown, and are ready to push: 2231 Critical mtsolo Tuplet bracket makes space for dynamic but dynamic is placed underneath bracket 2228 Critical Carl.D.Sorensen Some users prefer to minimize partial beams rather than beam by the beat Regression 2224 Critical julien.rioux LM: clickable examples in the docs have stopped working. Regression Critical julien.rioux lilypond-book fails with html input Regression 2171 Enhancement mtsoloPatch: Implements DOM-id property for grobs. 2092 Maintainability Carl.D.Sorensen lily-git.tcl should using a working branch 1985 Scripts musicxml2ly: group-symbol none leads to bus error 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
PATCH: Countdown to 20120124
For 20:00 Tuesday, January 24, 2012 Critical: Issue 2240 http://code.google.com/p/lilypond/issues/detail?id=2240: Patch: Don't wrap EventChord around rhythmic events by default. - R 5440084 http://codereview.appspot.com/5440084/ Documentation: Issue 2238 http://code.google.com/p/lilypond/issues/detail?id=2238: Patch: Spelling fixes in comments and documentation - R 5562043 http://codereview.appspot.com/5562043/ 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
