On Wed, Nov 24, 2010 at 11:30 PM, Mark Polesky markpole...@yahoo.com wrote:
I'm a little puzzled by your recent patch 1b832d7
Doc: clean up @file{} entries. In the commit description,
you say you're escaping such characters as `.', `/' or
`-'. But the only thing I see in the diff are some 900
Hi Reinhold,
it looks quite good; I only have minor comments so hopefully someone
more experienced than me will have more to say :)
http://codereview.appspot.com/3285042/diff/1/lily/part-combine-engraver.cc
File lily/part-combine-engraver.cc (right):
On 2010/11/25 00:10:01, Neil Puttock wrote:
That sounds OK to me.
Here's a new patch set; I've only changed the number-or-pair definition.
Thanks!
Valentin.
http://codereview.appspot.com/3248042/
___
lilypond-devel mailing list
On 2010/11/25 12:24:44, Valentin Villenave wrote:
On 2010/11/24 00:10:01, Neil Puttock wrote:
The indentation inside language-pitch-names is artificially
compressed, e.g.,
That allowed me to make git regard the file as renamed instead of
rewritten. But
you're right, I've fixed the
On 2010/11/25 11:42:40, Valentin Villenave wrote:
On 2010/11/25 00:10:01, Neil Puttock wrote:
That sounds OK to me.
In scm/translation-functions.scm, I'd prefer to see the argument called
count, not count-or-range. The property is timeUnitCount, IIUC.
The count can either be a number or a
Valentin Villenave wrote:
I did do my homework and have a look at the texinfo
manual, but I thought this was just escaped characters.
Either way, the syntax wasn't quite consistent since there
were some refs with @/ escaping, others without and this
wasn't mentioned in the CG at all. (dots
Reviewers: carl.d.sorensen_gmail.com, Neil Puttock,
Message:
On 2010/11/24 18:05:42, Neil Puttock wrote:
ly_string2scm(0));
ly_string2scm (0)
Fixed and pushed.
Description:
FiguredBass: Extenders for figures of different width should still stop
at the same position
FB extenders use the
Another thought re the conditional (define-module) idea, if it's (if)
making the guile compilation barf, we could try using (cond) or
(cond-expand) instead.
Ian
http://codereview.appspot.com/2219044/diff/25001/scm/display-lily.scm
File scm/display-lily.scm (right):
Currently, lilypond simply ignores all ties that cannot be created, e.g. c~ d.
This is very bad, since the user will not notice that there was a problem with
the tie at all (unless he checks the score very carefully).
Here is a patch that prints out a warning for all ties that are discarded:
LGTM.
Carl
http://codereview.appspot.com/3310042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
http://codereview.appspot.com/3310042/diff/2001/input/regression/tie-unfinished.ly
File input/regression/tie-unfinished.ly (right):
http://codereview.appspot.com/3310042/diff/2001/input/regression/tie-unfinished.ly#newcode6
input/regression/tie-unfinished.ly:6: be created, lilypond prints out a
http://codereview.appspot.com/3285042/diff/1/input/regression/part-combine-text-wait.ly
File input/regression/part-combine-text-wait.ly (right):
http://codereview.appspot.com/3285042/diff/1/input/regression/part-combine-text-wait.ly#newcode10
input/regression/part-combine-text-wait.ly:10:
On 25 November 2010 17:45, Phil Holmes m...@philholmes.net wrote:
It wouldn't take me long to write a C# program (less than a day, I'd guess)
that reproduced quite a lot of the regtest checker functionality and did a
pixel-by-pixel check for image changes. I've done the latter bit in about
On 2010/11/25 11:42:40, Valentin Villenave wrote:
Here's a new patch set; I've only changed the number-or-pair
definition.
Don't forget to change the docstring in lily.scm.
Cheers,
Neil
http://codereview.appspot.com/3248042/
___
lilypond-devel
Hi Reinhold,
I think there's some scope for reducing code duplication in the engraver
and parser-clef.scm.
Cheers,
Neil
http://codereview.appspot.com/2726043/diff/1/input/regression/cue-clef.ly
File input/regression/cue-clef.ly (right):
On 2010/11/25 15:19:17, Carl wrote:
They may be a bit heavier now, but the amount of storage that the
language
alists take is insignificant compared to LilyPond's overall memory
usage. I
don't see a problem at all.
It's not just about memory usage: isn't it possible that the lookup time
On 2010/11/25 22:50:53, Valentin Villenave wrote:
It's not just about memory usage: isn't it possible that the lookup
time for
every pitches might be increased, even just by a tiny amount? (Not
that I could
measure it in any way, but I'm wondering.)
No, since the underlying method for
On 2010/11/22 18:51:55, Reinhold wrote:
Why do you define two different variables count-markup and
range-markup here,
one of which is always #f?
I would simply create one count-markup, defined as (if (pair?
count-or-range)
(create markup for range) (create markup for count)).
Then you don't
On 2010/11/25 23:05:48, Neil Puttock wrote:
No, since the underlying method for setting the language hasn't
changed: the
language sublist retrieved from the master list is copied into a fresh
hash
table, so the lexer never accesses the list directly.
Oh, I didn't know Guile had any notion
On Thu, Nov 25, 2010 at 05:45:36PM -, Phil Holmes wrote:
It wouldn't take me long to write a C# program (less than a day, I'd
guess) that reproduced quite a lot of the regtest checker
functionality and did a pixel-by-pixel check for image changes.
Hmm. It shouldn't take a huge amount of
On Thu, Nov 25, 2010 at 07:30:20AM -0800, Mark Polesky wrote:
Valentin Villenave wrote:
No, I did consider discussing it but since the diff was
almost 400Ko I couldn't send it so I just pushed it on the
translations/ branch.
Can you post to Rietveld? That's the preferred code sharing
On 26 November 2010 00:00, Graham Percival gra...@percival-music.ca wrote:
Hmm. It shouldn't take a huge amount of time to compare each pair
of regtest images -- they're named, so you'd be comparing
something like 500 pairs of .png images. (Neil: were you thinking
of something else?)
I
On 2010/11/25 23:10:49, Valentin Villenave wrote:
On 2010/11/22 18:51:55, Reinhold wrote:
Why do you define two different variables count-markup and
range-markup here,
one of which is always #f?
I would simply create one count-markup, defined as (if (pair?
count-or-range)
(create markup
http://codereview.appspot.com/3248042/diff/23001/input/regression/metronome-range.ly
File input/regression/metronome-range.ly (right):
http://codereview.appspot.com/3248042/diff/23001/input/regression/metronome-range.ly#newcode3
input/regression/metronome-range.ly:3: \header{
\header {
On Fri, Nov 26, 2010 at 12:14:17AM +, Neil Puttock wrote:
On 26 November 2010 00:00, Graham Percival gra...@percival-music.ca wrote:
Hmm. It shouldn't take a huge amount of time to compare each pair
of regtest images -- they're named, so you'd be comparing
something like 500 pairs of
On 2010/11/26 00:17:43, Neil Puttock wrote:
texidoc =
Indeed. I just pasted it from another metronome-*.ly regtest.
Here's a suitable display-lily-music method. Thanks for your help, it's
very much appreciated!
Cheers,
Valentin.
http://codereview.appspot.com/3248042/
On Fri, Nov 26, 2010 at 1:11 AM, Graham Percival
gra...@percival-music.ca wrote:
On Thu, Nov 25, 2010 at 07:30:20AM -0800, Mark Polesky wrote:
Can you post to Rietveld? That's the preferred code sharing
location.
Let me see... A 300-Ko patch that affects 100 files? No way. I'm
barely able to
On Thu, Nov 25, 2010 at 12:45 PM, Phil Holmes m...@philholmes.net wrote:
It wouldn't take me long to write a C# program (less than a day, I'd guess)
that reproduced quite a lot of the regtest checker functionality and did a
pixel-by-pixel check for image changes. I've done the latter bit in
On Fri, Nov 26, 2010 at 02:40:35AM +0100, Valentin Villenave wrote:
On Fri, Nov 26, 2010 at 1:11 AM, Graham Percival
gra...@percival-music.ca wrote:
On Thu, Nov 25, 2010 at 07:30:20AM -0800, Mark Polesky wrote:
Can you post to Rietveld? That's the preferred code sharing
location.
Let
On Fri, Nov 26, 2010 at 02:15:22AM -0500, Han-Wen Nienhuys wrote:
The reason I did not do it originally is that it moves the comparison
farther away from lilypond itself and pixel-per-pixel changes are not
calibrated for the size of the symbols: a large symbol moving place
will generate a much
On Fri, Nov 26, 2010 at 2:21 AM, Graham Percival
gra...@percival-music.ca wrote:
On Fri, Nov 26, 2010 at 02:15:22AM -0500, Han-Wen Nienhuys wrote:
The reason I did not do it originally is that it moves the comparison
farther away from lilypond itself and pixel-per-pixel changes are not
Valentin Villenave wrote Friday, November 26, 2010 1:40 AM
On Fri, Nov 26, 2010 at 1:11 AM, Graham Percival
I don't think that @/ is appropriate. Certainly not for a short
@file{filename.ext}. I'm willing to entertain the notion of using
them inside a
32 matches
Mail list logo
