To be pushed after 00:01 PST on Monday Aug 15. I know there's a
lot of big things in here to review, but we need to tackle them!
CG: revise CG instructions for commit access
http://code.google.com/p/lilypond/issues/detail?id=1824
http://codereview.appspot.com/4898058/
Lilypond-book music runs o
On Aug 20, 2011, at 12:02 AM, Neil Puttock wrote:
> On 18 August 2011 13:44, Mike Solomon wrote:
>
>> What about pure-container ?
>
unpure-pure-container ?
Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mail
On Aug 19, 2011, at 11:58 PM, n.putt...@gmail.com wrote:
>
>
> http://codereview.appspot.com/4808082/diff/13002/lily/tuplet-bracket.cc#newcode283
> lily/tuplet-bracket.cc:283: SCM scm_x_span = me->get_property
> ("X-positions");
> I seem to recall we discussed the option of splitting control-po
Han-Wen Nienhuys writes:
> Given that Cmake has a large following (examples include KDE and
> LLVM), I'd be comfortable with switching to that.
Interesting; have you ever used Cmake?
Last time I looked (migrated a cmake project to autotools), Cmake did
only have proprietary documentation (I hear
Hi everyone,
sorry for disappearing without a notice... I'm back and digging my
way through e-mails.
I've created myself a dedicated mailbox for Lily purposes:
janek.lilyp...@gmail.com - please use it instead of this one!
thanks,
Janek
PS please add janek.lilyp...@gmail.com to the tracker and w
- Original Message -
From: "Janek Warchol"
To:
Sent: Saturday, August 20, 2011 1:22 PM
Subject: changing e-mail address
Hi everyone,
sorry for disappearing without a notice... I'm back and digging my
way through e-mails.
I've created myself a dedicated mailbox for Lily purposes:
ja
2011/8/20 Phil Holmes :
> - Original Message - From: "Janek Warchol"
>
>
>> PS please add janek.lilyp...@gmail.com to the tracker and wherever
>> else is needed.
>
>
> That's a bit easier to remember than the lemniskata one :-)
Indeed :)
> You want me to delete the old one from the track
2011/8/16 Graham Percival :
> We're up to 59 patches now, plus 17 patches on the "plz review; no
> known problems" list. We're losing ground quickly, and this will
> soon become a serious problem for developers and contributors (if
> it isn't already).
> I see three options, none of which fill me
LGTM
2011/8/16 Graham Percival :
> Minor update for clarity and discussion from the past few days.
> We're aiming to accept the final proposal on Thursday.
> http://lilypond.org/~graham/gop/gop_8.html
>
>
> ** Proposal summary
>
> Let’s get rid of priorities. We will simply describe bugs in
> neut
Hi Aleksandr,
i'm finally back to this.
How much experience do you have with git and Lily source code? I ask
because i don't know how detailed explanations should i provide :)
I've looked at the metafont code you provided. It won't be hard to
include it in Feta font as a separate group of glyphs
- Original Message -
From: "Janek Warchoł"
To: "Phil Holmes"
Cc:
Sent: Saturday, August 20, 2011 1:30 PM
Subject: Re: changing e-mail address
2011/8/20 Phil Holmes :
- Original Message - From: "Janek Warchol"
PS please add janek.lilyp...@gmail.com to the tracker and wher
On Sat, Aug 20, 2011 at 11:06:29AM +0200, Jan Nieuwenhuizen wrote:
> Han-Wen Nienhuys writes:
>
> > Given that Cmake has a large following (examples include KDE and
> > LLVM), I'd be comfortable with switching to that.
>
> Interesting; have you ever used Cmake?
I migrated Marsyas (a moderately-s
Op 19-08-11 10:19, Mike Solomon schreef:
On Aug 19, 2011, at 10:04 AM, Sandor Spruit wrote:
[snip]
- In what version, exactly, did Lilypond drop the use of groups (svg:g) in its
output?
LilyPond still uses groups. grep "OK, thanks. I stand corrected. Let me rephase my comment. When looking
a
I think Reinhold's commit cfcb9efdbd7c6600fc89fc912ba80529010b31e7 has
broken make doc. I've just done a clean build (fresh build directory) and
get this at the end of a failed make doc:
LILYPOND_VERSION=2.15.9 /usr/bin/python
/home/phil/lilypond-git/scripts/lilypond-book.py -I
/home/phil/li
Dear friends, I forward this from the poppler team.
Amigos, os reenvío esto que me llega del equipo de Poppler.
-- Mensaje reenviado --
De: "evince"
Fecha: 20/08/2011 12:22
Asunto: [Bug 503290] too thick barlines from GNU LilyPond PDF
Para:
https://bugzilla.gnome.org/show_bug.cgi
Le 20/08/2011 16:26, Phil Holmes disait :
I think Reinhold's commit cfcb9efdbd7c6600fc89fc912ba80529010b31e7
has broken make doc. I've just done a clean build (fresh build
directory) and get this at the end of a failed make doc:
[...]
I had made a fresh build and make doc before pushing, and h
On Sat, Aug 20, 2011 at 03:26:48PM +0100, Phil Holmes wrote:
> File "/home/phil/lilypond-git/scripts/lilypond-book.py", line 624, in main
>files = do_options ()
> File "/home/phil/lilypond-git/scripts/lilypond-book.py", line 610,
> in do_options
>print imp.load_source ("book_custom_packag
Hi Phil,
Am Saturday, 20. August 2011, 16:26:48 schrieb Phil Holmes:
> I think Reinhold's commit cfcb9efdbd7c6600fc89fc912ba80529010b31e7 has
> broken make doc. I've just done a clean build (fresh build directory) and
> get this at the end of a failed make doc:
[...]
> Traceback (most recent call
On 2011-08-18, at 10:11 , Carl Sorensen wrote:
> On 8/17/11 10:41 PM, "Dan Eble" wrote:
>
>> What I have so far is a backtrace:
>> http://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00494.html
>> and a large amount of input spread across many files, which is why I chose to
>> review t
Carl Sorensen writes:
> On 8/19/11 10:15 AM, "David Kastrup" wrote:
>>
>> Up to now, \once \revert is not really documented nor used. I have not
>> yet dug through the existing code in order to figure out what it does if
>> anything (most likely ignoring \once, but not sure).
>
> I would expec
Le 20/08/2011 17:26, Jean-Charles Malahieude disait :
Le 20/08/2011 16:26, Phil Holmes disait :
I think Reinhold's commit cfcb9efdbd7c6600fc89fc912ba80529010b31e7
has broken make doc. I've just done a clean build (fresh build
directory) and get this at the end of a failed make doc:
[...]
I ha
Am Saturday, 20. August 2011, 19:29:38 schrieb Dan Eble:
> On 2011-08-18, at 10:11 , Carl Sorensen wrote:
> > On 8/17/11 10:41 PM, "Dan Eble" wrote:
> >> What I have so far is a backtrace:
> >> http://lists.gnu.org/archive/html/lilypond-devel/2011-08/msg00494.html
> >>
> >> and a large amount of
On Aug 20, 2011, at 12:39 AM, n.putt...@gmail.com wrote:
>
> http://codereview.appspot.com/4894052/diff/9001/input/regression/pure-closure.ly
> File input/regression/pure-closure.ly (right):
>
> http://codereview.appspot.com/4894052/diff/9001/input/regression/pure-closure.ly#newcode18
> input/r
For several weeks now, I've been working in fits and starts, with lots of
dead ends, on the oldest bug in the LilyPond issue tracker -- issue #11
Beamlet on wrong side of tuplet sixteenth.
The good news is, I think I have a fix for that bug (and it's only 5 years
old).
But before I push a pat
that we can reproduce it somehow).
Be my guest.
1. extract http://faithful.be/sheet-music/dfe-books-20110820.tar.bz2
2. edit the top-level Makefile to set the LILYPOND variable
3. make PraiseAndPrayer PARTS=piano
Once the output directories are created you should be able to run it again
with
Reviewers: ,
Message:
Hey all,
I've been thinking about Neil's comment regarding a better interface for
cross-staff stems. While this patch has nothing to do with stems per
se, it lays down the framework for dealing with cross-staff stems via a
test-case with SpanBar grobs (which are like cross
Can you send a test case without dots (i.e. \times 4/5 { c8 [ c16 c8 c16 c8 c8
] } to see if that's changed in the new patch ?
Cheers,
MS
On Aug 20, 2011, at 10:47 PM, Carl Sorensen wrote:
> For several weeks now, I've been working in fits and starts, with lots of
> dead ends, on the oldest bug
- Original Message -
From: "Graham Percival"
To: "Phil Holmes"
Cc: "Devel"
Sent: Saturday, August 20, 2011 6:22 PM
Subject: Re: Make doc is broken
On Sat, Aug 20, 2011 at 03:26:48PM +0100, Phil Holmes wrote:
File "/home/phil/lilypond-git/scripts/lilypond-book.py", line 624, in
mai
It looks good.
Is this also working with complex cases such as { \times 4/5 { a8 a32 a8
a16. a8 a8 } } ?
I think (not sure) the beamlets should be: 32 to the right, 16. to the left.
Bertrand
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://
> The good news is, I think I have a fix for that bug (and it's only 5
> years old).
Great!
> But before I push a patch for review, I'd like to verify that the
> beamlet is in the right position on all of notes in the attached
> png.
Making the beamlet always point to the dot looks OK.
Wha
Why is there an @example in the NR-3.2 titling change:
6810d727b278d15825eecb2b497d1a966241d4eb
James spent a lot of work to allow us to easily create small,
complete-"page", @lilypond. In fact, this is done on line 617 of
that same file!
Please revert that doc change and put it on Rietveld for
On Fri, Aug 19, 2011 at 10:29:12AM +0200, Werner LEMBERG wrote:
>
> > No, it is not safe. Your changes will be elminated the next time
> > Neil (or Valentin, or anybody who cares about LSR) does a "full
> > import". Historically, this only happens every 3-4 months, but it
> > should be happening
On Fri, Aug 19, 2011 at 07:32:20AM +0200, Werner LEMBERG wrote:
>
> > Please read:
> > http://lilypond.org/doc/v2.15/Documentation/contributor/lilypond-formatting
> > in particular the point about #.
...
> I interpret as being used for inline samples and the like.
Ah, good point! I glanced at th
On 8/20/11 4:16 PM, "Graham Percival" wrote:
> Hmm. I still have no clue about the difference between #t and
> #foo, which certainly emphasizes that there *is* confusion.
#t is a Scheme value, as is foo
##t is a lilypond input value to get the scheme value #t
#foo is a lilypond input value t
On Fri, Aug 19, 2011 at 07:32:20AM +0200, Werner LEMBERG wrote:
>
> > I'm also not convinced that the "insert breakpoints after slashes"
> > is a great change. This makes the documentation source look
> > really cludgy; is there no way that the breakpoints could be
> > specified automatically?
>
On Sat, Aug 20, 2011 at 04:21:38PM -0600, Carl Sorensen wrote:
> On 8/20/11 4:16 PM, "Graham Percival" wrote:
>
> > Hmm. I still have no clue about the difference between #t and
> > #foo, which certainly emphasizes that there *is* confusion.
>
> #t is a Scheme value, as is foo
>
> ##t is a lil
On 8/20/11 3:40 PM, "Werner LEMBERG" wrote:
>
> What about
>
> O. O O. O
> || ||
> | -| | -|
> ++--++
>
> Does this work correctly also?
Yes. See attached PNG.
>
On 8/20/11 2:53 PM, "Mike Solomon" wrote:
> Can you send a test case without dots (i.e. \ti
Reviewers: ,
Message:
I believe that this fixes issue 11.
Please review.
Thanks,
Carl
Description:
Fix issue 11 -- beamlet points in wrong direction on tuplet
Please review this at http://codereview.appspot.com/4941041/
Affected files:
A input/regression/beamlet-test.ly
M lily/auto-bea
Graham Percival wrote Saturday, August 20, 2011 11:29 PM
So we need either #foo and ##t or foo and #t. We should never
mix those.
Don't tell me; tell the documentation.
It's already partially covered:
http://www.lilypond.org/doc/v2.15/Documentation/learning/modifying-context-properties
T
On 8/19/11 2:57 PM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> On 8/19/11 10:15 AM, "David Kastrup" wrote:
>>>
>>> Up to now, \once \revert is not really documented nor used. I have not
>>> yet dug through the existing code in order to figure out what it does if
>>> anything (most l
Graham Percival percival-music.ca> writes:
> I know there's a lot of big things in here to review,
I should make it two issues fewer.
These two were on the list finished Friday, I've just not been on linux to push.
> % (single patch does both issues)
> accidentaled notes too far from the barl
> On 2011-08-20, at 16:00 , Reinhold Kainhofer wrote:
>
>> So, basically, you are saying that whenever you run "make X" through color,
>> it
>> will crash, but it will not crash in any other cases?
>> Are you sure this is not a problem of color together with make (I had some
>> strange problem
>> (2) The next time makelsr gets called, start with the status at
>> commit 12345678 as a base, *not* with HEAD. Doing so, later
>> fixes to the snippets within lilypond's git repository are
>> saved.
>
> can you do this automatically in a python script, assuming a
> complete ignoran
On Sun, Aug 21, 2011 at 06:55:02AM +0200, Werner LEMBERG wrote:
>
> > I think it's overkill, though.
>
> Is it? You want to silently override fixes to the better?
If somebody edits a file specifically marked
%% DO NOT EDIT this file manually; it is automatically
%% generated from LSR http://lsr
>> > I'm also not convinced that the "insert breakpoints after
>> > slashes" is a great change. This makes the documentation source
>> > look really cludgy; is there no way that the breakpoints could be
>> > specified automatically?
>>
>> No, there isn't.
>
> Hmm. The next question would be "how
>> So we need either #foo and ##t or foo and #t. We should never mix those.
>
> Don't tell me; tell the documentation.
It's already there.
> Or are there any other volunteers?
Obviously, I volunteered to walk over all instances to clean this
up...
Werner
___
> Under this architecture, \once means "if the \once set is empty,
> copy it from the current context properties"
>
> \override means "apply the override to the context set. If the
> \once set is not empty, also apply it to the \once set".
>
> \revert means "apply the revert to the context set.
>> Is it? You want to silently override fixes to the better?
>
> If somebody edits a file specifically marked
> %% DO NOT EDIT this file manually; it is automatically
> %% generated from LSR http://lsr.dsi.unimi.it
> ?
Hehe, you have a point.
>> BTW, what about using git tags to mark the commit
48 matches
Mail list logo
