Stefan,
On 21 January 2012 07:23, Stefan Weil wrote:
> Am 21.01.2012 00:10, schrieb Pavel Roskin:
>>
>> On Fri, 20 Jan 2012 17:58:47 +0100
>> Stefan Weil wrote:
>>>
>>> Hi,
>>> tre
>>>
>>> my last two patches were sent inline (with git send-email),
>>> but I just learned that they should have be
LGTM, but I can't speak to the translation stuff. Depending on what
Francisco says (or has said), you might want to split this into two
separate patches: one for non-translation stuff, and one for
translations.
http://codereview.appspot.com/5562043/
_
LGTM, please push directly to staging.
As a general rule, any spelling fixes like this can be pushed directly
(as long as they don't involve translations).
http://codereview.appspot.com/5561053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
h
Reviewers: Graham Percival,
Message:
Thanks
author Stefan Weil
Thu, 19 Jan 2012 21:39:31 + (22:39 +0100)
committer
James Lowe
Sat, 21 Jan 2012 13:27:19 + (13:27 +)
commit cf9cf627cf5f7d6b82db3cfb4b1829c7ef4508ae
James
Description:
Fix spelling in input/regression/*.ly
Stefan,
On 21 January 2012 07:23, Stefan Weil wrote:
> Am 21.01.2012 00:10, schrieb Pavel Roskin:
>>
>> On Fri, 20 Jan 2012 17:58:47 +0100
>> Stefan Weil wrote:
>>>
>>> Hi,
>>> tre
>>>
>>> my last two patches were sent inline (with git send-email),
>>> but I just learned that they should have be
All release-Critical issues have patches which are either on a
current countdown, have been on a previous countdown, or don't
make sense to be on a countdown at all and will thus be pushed in
a few hours.
Unless any problem are found with the current countdown'ing
patches, 2.15.27 release candidat
Graham Percival writes:
> All release-Critical issues have patches which are either on a
> current countdown, have been on a previous countdown, or don't
> make sense to be on a countdown at all and will thus be pushed in
> a few hours.
>
> Unless any problem are found with the current countdown'
On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote:
> I would very much prefer the work on Issue 2240 (aka 2070) to make it
> into 2.16. It is a significant API change that should not occur during
> a stable release series, and it paves the way for making the music
> function work conti
On 1/21/12 9:45 AM, "Graham Percival" wrote:
>On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote:
>> I would very much prefer the work on Issue 2240 (aka 2070) to make it
>> into 2.16. It is a significant API change that should not occur during
>> a stable release series, and it paves
Carl Sorensen byu.edu> writes:
> On 1/21/12 9:45 AM, "Graham Percival" percival-music.ca> wrote:
> >On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote:
> >> I would very much prefer the work on Issue 2240 (aka 2070) to make it
> >> into 2.16. It is a significant API change
> >
> >IM
On Sat, Jan 21, 2012 at 05:02:32PM +, Carl Sorensen wrote:
> On 1/21/12 9:45 AM, "Graham Percival" wrote:
>
> >IMO, significant API changes should not happen right before a
> >release. Version numbers are cheap; why not have 2.18 in March
> >2012? Backporting is a huge hassle.
>
> Earlier,
On 1/21/12 10:24 AM, "Graham Percival" wrote:
>On Sat, Jan 21, 2012 at 05:02:32PM +, Carl Sorensen wrote:
>> On 1/21/12 9:45 AM, "Graham Percival" wrote:
>>
>> >IMO, significant API changes should not happen right before a
>> >release. Version numbers are cheap; why not have 2.18 in March
On Jan 21, 2012, at 6:14 PM, Keith OHara wrote:
> Carl Sorensen byu.edu> writes:
>
>> On 1/21/12 9:45 AM, "Graham Percival" percival-music.ca> wrote:
>>> On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote:
I would very much prefer the work on Issue 2240 (aka 2070) to make it
>>>
Carl Sorensen writes:
> On 1/21/12 9:45 AM, "Graham Percival" wrote:
>
>>On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote:
>>> I would very much prefer the work on Issue 2240 (aka 2070) to make it
>>> into 2.16. It is a significant API change that should not occur during
>>> a stab
On 1/21/12 10:37 AM, "David Kastrup" wrote:
>
>I have actually found out that I promised too much about string numbers
>appearing on isolated notes: since the string number events _are_
>listened to (likely by the tabstaff engraver team), the rhythmic music
>iterator _does_ broadcast them instea
"m...@apollinemike.com" writes:
> On Jan 21, 2012, at 6:14 PM, Keith OHara wrote:
>
>> Carl Sorensen byu.edu> writes:
>>
>>> On 1/21/12 9:45 AM, "Graham Percival" percival-music.ca> wrote:
On Sat, Jan 21, 2012 at 05:27:00PM +0100, David Kastrup wrote:
> I would very much prefer the wo
Hi Mike,
i apologize for the delay; i focused on other things that seemed more
urgent to me.
On 2012/01/11 12:27:10, mike_apollinemike.com wrote:
[explanation of the patch]
I'm not sure how/where to include this info in the source: if you can
think of a
good way to phrase it that would mak
Carl Sorensen writes:
> On 1/21/12 10:37 AM, "David Kastrup" wrote:
>
>
>>
>>I have actually found out that I promised too much about string numbers
>>appearing on isolated notes: since the string number events _are_
>>listened to (likely by the tabstaff engraver team), the rhythmic music
>>iter
On 1/21/12 11:16 AM, "David Kastrup" wrote:
>Carl Sorensen writes:
>
>> On 1/21/12 10:37 AM, "David Kastrup" wrote:
>>
>>
>>>
>>>I have actually found out that I promised too much about string numbers
>>>appearing on isolated notes: since the string number events _are_
>>>listened to (likely by
Hi Julien,
could you please explain to me how your patch fixes this issue? I've
read it but don't understand why it works :(
thanks,
Janek
http://codereview.appspot.com/5553056/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gn
I believe the problem had to do with filename extensions; as such, I
think the following three places constitute the actual fix for .
But he also cleaned up a few other little bits, which seems sensible and
ok since it's a pretty small patch.
http://codereview.appspot.com/5553056/diff/1/pyth
Am 21.01.2012 18:44, schrieb Carl Sorensen:
On 1/21/12 10:37 AM, "David Kastrup" wrote:
I have actually found out that I promised too much about string numbers
appearing on isolated notes: since the string number events _are_
listened to (likely by the tabstaff engraver team), the rhythmic mu
On Jan 21, 2012, at 7:12 PM, David Kastrup wrote:
> If you wrote note^postevent previously, the postevent ended up in
> "articulations" of the NoteEvent when written inside of a chord, or as
> an EventChord companion when not written in a chord. Now it ends up in
> "articulations", period.
>
I
Marc Hohl writes:
> Am 21.01.2012 18:44, schrieb Carl Sorensen:
>> On 1/21/12 10:37 AM, "David Kastrup" wrote:
>>
>>
>>> I have actually found out that I promised too much about string numbers
>>> appearing on isolated notes: since the string number events _are_
>>> listened to (likely by the ta
Am 21.01.2012 19:41, schrieb David Kastrup:
Marc Hohl writes:
Am 21.01.2012 18:44, schrieb Carl Sorensen:
On 1/21/12 10:37 AM, "David Kastrup" wrote:
I have actually found out that I promised too much about string numbers
appearing on isolated notes: since the string number events _are_
2012/1/21 :
> I believe the problem had to do with filename extensions; as such, I
> think the following three places constitute the actual fix for .
Do i understand correctly that line 336
http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#newcode336
adds .ly extension to s
"m...@apollinemike.com" writes:
> On Jan 21, 2012, at 7:12 PM, David Kastrup wrote:
>
>> If you wrote note^postevent previously, the postevent ended up in
>> "articulations" of the NoteEvent when written inside of a chord, or as
>> an EventChord companion when not written in a chord. Now it ends
Le 21/01/2012 17:19, Graham Percival disait :
All release-Critical issues have patches which are either on a
current countdown, have been on a previous countdown, or don't
make sense to be on a countdown at all and will thus be pushed in
a few hours.
Unless any problem are found with the current
There were actually two issues. The second was discovered after fixing
the first. I intend to push as two separate commits explaining each.
http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py
File python/book_snippets.py (left):
http://codereview.appspot.com/5553056/diff/1/pyth
On 1/21/12 11:47 AM, "Marc Hohl" 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 anyt
On 21/01/2012 11:19 AM, Graham Percival wrote:
Unless any problem are found with the current countdown'ing
patches, 2.15.27 release candidate 3 will probably come out on
Monday.
Once the fix for (lilypond-book fails with html input) is in, I'll
fix 2223 (Regtests for lilypond-book are not
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
On Jan 21, 2012, at 7:58 PM, David Kastrup wrote:
>>
>> I absolutely agree that everything should be in an articulations list,
>> but I think this can be done while preserving event chords. It just
>> means that EventChords will no longer contain articulation events and
>> that all articulation
Some questions and concerns.
thanks,
Janek
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl
File scripts/auxiliar/lily-git.tcl (right):
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode222
scripts/auxiliar/lily-git.tcl:222: pro
"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.
Thanks for explanations, Julien!
Janek
http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py
File python/book_snippets.py (left):
http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode184
python/book_snippets.py:184: line-width = #(- line-width (* mm
%(paddi
Thanks for explanations, Julien!
Janek
http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py
File python/book_snippets.py (left):
http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode184
python/book_snippets.py:184: line-width = #(- line-width (* mm
%(paddi
On Sat, Jan 21, 2012 at 4:18 PM, wrote:
> On 2012/01/21 19:14:15, Julien Rioux wrote:
>>
>> Here was the first problem: line-width is being adjusted. This is written to
>> the
>> .ly file generated by lilypond-book, but it is not clear whether
>> %(paper_string)s above will contain a definition
So the problem was that by default tupletBracket doesn't have
outside-staff-priority (because we want it to be placed on staff lines
sometimes), and the code failed to check for that?
But i don't see how this patch solved the same problem with
outside-staff-priority set to something:
{ % this p
On Jan 21, 2012, at 11:02 PM, janek.lilyp...@gmail.com wrote:
> So the problem was that by default tupletBracket doesn't have
> outside-staff-priority (because we want it to be placed on staff lines
> sometimes), and the code failed to check for that?
>
> But i don't see how this patch solved the
Hello
On 21 January 2012 21:12, wrote:
> Some questions and concerns.
While I don't understand any of this really, isn't lily-git.tcl
supposed to be for git-idiots (like me) who don't even want to think
about branches? :)
Just wondering if Janek is 'overthinking' this - apologies if not.
Also
On Jan 21, 2012, at 10:15 PM, David Kastrup wrote:
> "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
Et un coup de pied dans la fourmilière !
On 9 January 2012 22:02, Emilio Grazzi wrote:
> 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
Reviewers: ,
Message:
Simpler formatting of convert-ly error messages, with improved
partitioning of translatable parts.
Description:
convert-ly: Better formatted error messages (issue 803).
Please review this at http://codereview.appspot.com/5564043/
Affected files:
M python/convertrules.py
Reviewers: ,
Message:
Simple patch to issue a warning when the \version string is malformed.
Description:
convert-ly: Handle malformed \version string (issue 2044).
Please review this at http://codereview.appspot.com/5563047/
Affected files:
M scripts/convert-ly.py
Index: scripts/convert-l
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
LGTM, please push directly to staging
http://codereview.appspot.com/5563047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Sat, Jan 21, 2012 at 6:36 PM, wrote:
> LGTM, please push directly to staging
>
> http://codereview.appspot.com/5563047/
I noticed that there is already an InvalidVersion exception, so I am
going to use that and push the result.
Thanks,
Julien
___
LGTM in general. Some comments though.
Plus: The example in the comment above will now compile, but it will be
missing the additional padding...
Another thing about the hard-coded .ly extension: I would leave the
extension extraction in the file snippet class, so that the base class
sets a defau
Thanks for reviewing it.
Regards,
Julien
http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py
File python/book_snippets.py (left):
http://codereview.appspot.com/5553056/diff/1/python/book_snippets.py#oldcode806
python/book_snippets.py:806: self.ext = os.path.splitext
(os.path.b
2012/1/21 Graham Percival :
> All release-Critical issues have patches which are either on a
> current countdown, have been on a previous countdown, or don't
> make sense to be on a countdown at all and will thus be pushed in
> a few hours.
>
> Unless any problem are found with the current countdow
2012/1/21 James :
> Hello
>
> On 21 January 2012 21:12, wrote:
>> Some questions and concerns.
>
> While I don't understand any of this really, isn't lily-git.tcl
> supposed to be for git-idiots (like me) who don't even want to think
> about branches? :)
That's exactly why they should work thems
On 1/21/12 5:36 PM, "Janek Warchoł" wrote:
>2012/1/21 James :
>> Hello
>>
>> On 21 January 2012 21:12, wrote:
>>> Some questions and concerns.
>>
>> While I don't understand any of this really, isn't lily-git.tcl
>> supposed to be for git-idiots (like me) who don't even want to think
>> about b
2012/1/21 m...@apollinemike.com :
> On Jan 21, 2012, at 11:02 PM, janek.lilyp...@gmail.com wrote:
>> { % this produced wrong output in 2.15.26, but now is ok:
>> \override TupletBracket #'outside-staff-priority = #3
>> \times 2/3 {c''4\ff c'' c''}
>> }
>
> The idea is that if outside-staff-prio
Nice review.
I will make changes in response to your comments.
Thanks,
Carl
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl
File scripts/auxiliar/lily-git.tcl (right):
http://codereview.appspot.com/5504092/diff/14001/scripts/auxiliar/lily-git.tcl#newcode222
sc
The patches listed below have had no updates since before December, and
in a couple of cases, the last update was me asking if the patch was
still being developed. Would the owners please review their patches,
and mark them abandoned if applicable, closing any Rietveld item as
necessary, or up
56 matches
Mail list logo
