I can push it if you send me the .patch, Aleksandr.
cheers,
Janek
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Graham Percival writes:
> On Fri, Jun 22, 2012 at 08:58:13AM +, julien.ri...@gmail.com wrote:
>> I just did a git am using his patch, but I'll amend the commit before
>> pushing. Do we need some license statement from Rodolfo?
>
> No; lilypond is not FSF-copyright-assigned, so nothing is need
LGTM, this can be pushed directly to staging.
http://codereview.appspot.com/6335049/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Fri, Jun 22, 2012 at 08:58:13AM +, julien.ri...@gmail.com wrote:
> I just did a git am using his patch, but I'll amend the commit before
> pushing. Do we need some license statement from Rodolfo?
No; lilypond is not FSF-copyright-assigned, so nothing is needed.
But thanks for checking!
- G
On 6/23/12 18:09 , d...@gnu.org wrote:
On 2012/05/13 05:43:17, dak wrote:
On 2012/05/13 02:29:54, choan.galvez wrote:
> tenor-ukulele-tuning and baritone-ukulele-tuning fixed, the string
order was
> reversed.
In the user group, a more extensive change was/is discussed that could
also be
w
On 2012/05/13 05:43:17, dak wrote:
On 2012/05/13 02:29:54, choan.galvez wrote:
> tenor-ukulele-tuning and baritone-ukulele-tuning fixed, the string
order was
> reversed.
In the user group, a more extensive change was/is discussed that could
also be
worthwhile. This patch here, in contrast
Reviewers: ,
Message:
Please review.
Description:
Removing 'fragment' from ancient.itely
Issue 2619.
Please review this at http://codereview.appspot.com/6335049/
Affected files:
M Documentation/notation/ancient.itely
Index: Documentation/notation/ancient.itely
diff --git a/Documentat
On Sat, Jun 23, 2012 at 3:19 PM, wrote:
> I was going to have the removal of 'fragment' reviewed in this issue,
> per Trevor's recommendation. Or shall I open a separate issue for that?
It would make sense to use the same Rietveld issue for reviewing that
if both changes were pushed at the same
On 2012/06/23 05:37:05, janek wrote:
pushed as a10311ff02578de9f979dc6ad83ba9535f8e4e4c.
Aleksandr, please close this Rietveld issue.
thanks!
Janek,
I was going to have the removal of 'fragment' reviewed in this issue,
per Trevor's recommendation. Or shall I open a separate issue for that?
Am 23.06.2012 11:06, schrieb Benkő Pál:
hi Marc,
http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm
File scm/bar-line.scm (right):
http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm#newcode83
scm/bar-line.scm:83: (define (make-colon-bar-line grob)
I'm afraid this defun do
hi Marc,
>> http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm
>> File scm/bar-line.scm (right):
>>
>> http://codereview.appspot.com/6305115/diff/1/scm/bar-line.scm#newcode83
>> scm/bar-line.scm:83: (define (make-colon-bar-line grob)
>> I'm afraid this defun doesn't match the relevant p
Am 22.06.2012 10:49, schrieb David Kastrup:
Marc Hohl writes:
You are only overriding line-positions. While the bar line printer will
see that this now contains a value and heeds it, this does not magically
affect the (now ignored) line-count property.
Ah, I see, thanks for the explanation.
John Mandereau writes:
> Il giorno mar, 19/06/2012 alle 00.07 +0200, David Kastrup ha scritto:
>> > This should be fixed now.
>>
>> It isn't.
>
> OK, default configuration should always be loaded, so when new options
> are created existing setups don't break. Does my last push to
> lilypond-ext
Am 22.06.2012 11:33, schrieb David Kastrup:
Marc Hohl writes:
Ok, but in lily/bar-line.cc, Bar_line::compound_barline, the number
of lines is computed by
int lines = Staff_symbol_referencer::line_count (me)
which is defined as
int
Staff_symbol_referencer::line_count (Grob *me)
{
Grob *st
14 matches
Mail list logo
