>> 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
> 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.
>> 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
___
>> > 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
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
>> (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 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
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 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 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
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
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
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 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 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:
>
> > 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 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
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
> 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
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://
- 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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
- 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
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
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
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
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
- 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
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
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
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
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
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
48 matches
Mail list logo
