On Sun, Aug 28, 2011 at 03:19:00AM +0100, Graham Percival wrote:
> On Sat, Aug 27, 2011 at 05:14:00PM +0100, Phil Holmes wrote:
> > This afternoon I've done a fresh pull, make and make doc. Make doc
> > failed with this:
>
> Indeed. It needed to run
> scripts/auxiliar/makelsr.py
> I've just do
On Sat, Aug 27, 2011 at 05:14:00PM +0100, Phil Holmes wrote:
> This afternoon I've done a fresh pull, make and make doc. Make doc
> failed with this:
Indeed. It needed to run
scripts/auxiliar/makelsr.py
I've just done that, and will push once the build successfully
finishes.
I noticed a bunc
On 2011-08-27, at 04:20 , pkx1...@gmail.com wrote:
> passes make and reg tests
>
> http://codereview.appspot.com/4923048/
You could clean up Skyline::distance by pulling lines 532-548 into their own
function and letting Skyline::distance call it with different options:
if (horizon_padding !=
Carl Sorensen writes:
> On 8/27/11 4:41 PM, "David Kastrup" wrote:
>
>> David Kastrup writes:
>>
>>> Previously #{ ... #} created only sequential music. This changes it to
>>> accept everything an assignment accepts. Incompatibility to before:
>>> #{ #} returns a void music expression, #{ mu
LGTM
Patch applied and it fixes documents originally showing collisions
between double-lined breves, bar-lines and accidentals.
Cheers,
Ian
http://codereview.appspot.com/4931043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu
On 2011-08-27, at 04:04 , pkx1...@gmail.com wrote:
> When I try to patch to current tree (27 Aug) I get
>
> --snip--
> --snip--
>
> Make succeeds though, and reg tests pass too.
>
> So I have set this patch to 'review' as I don't know the significance of
> these patch messages.
>
> http://cod
On 8/27/11 4:41 PM, "David Kastrup" wrote:
> David Kastrup writes:
>
>> Previously #{ ... #} created only sequential music. This changes it to
>> accept everything an assignment accepts. Incompatibility to before:
>> #{ #} returns a void music expression, #{ music #} does not create a
>> sequ
David Kastrup writes:
> Previously #{ ... #} created only sequential music. This changes it to
> accept everything an assignment accepts. Incompatibility to before:
> #{ #} returns a void music expression, #{ music #} does not create a
> sequential music list but just a single music event,
> on
Previously #{ ... #} created only sequential music. This changes it to
accept everything an assignment accepts. Incompatibility to before:
#{ #} returns a void music expression, #{ music #} does not create a
sequential music list but just a single music event,
only #{ music music ... #} works ju
lgtm
http://codereview.appspot.com/4867043/diff/1/lily/beam.cc
File lily/beam.cc (right):
http://codereview.appspot.com/4867043/diff/1/lily/beam.cc#newcode1797
lily/beam.cc:1797: Beam::middle_stem_estimation (Grob *me, Direction
dir)
As far as I can tell, this function estimates the range of st
Pushed as aaacb8cdd5bc029a8d0c87f90b817d97fcd5ad80. Thanks to everyone
for their help!
Cheers,
MS
http://codereview.appspot.com/4898044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
On Aug 27, 2011, at 4:40 AM, Colin Campbell wrote:
>
>
> Issue 1235: Accidental overlays stem - R 4898044: Fixes heights and pure
> heights of stems.
>
> Issue 1114: A later note's stem can be to the left of an earlier note's stem
> - R Issue 4898044: Fixes heights and pure heights of stems.
This afternoon I've done a fresh pull, make and make doc. Make doc failed
with this:
command failed: /home/phil/lilypond-git/build/out/bin/lilypond -dbackend=eps
[snip lots of options]
"/home/phil/lilypond-git/build/out/lybook-db/snippet-names-828948788.ly"
Then:
fatal error: failed files:
On Aug 27, 2011, at 4:23 PM, hanw...@gmail.com wrote:
> I read through this patch, but I can't tell what it does or is supposed
> to do. Maybe one of our pure gurus should look at this. Joe?
>
On an immediate level, it fixes Issue 910.
On a more long-term level, it lays down some code that wi
Pushed as f0978ed121192fee9bdf2453a325d98693148acf.
Cheers,
MS
http://codereview.appspot.com/4922042/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
I read through this patch, but I can't tell what it does or is supposed
to do. Maybe one of our pure gurus should look at this. Joe?
http://codereview.appspot.com/4917046/diff/1/lily/align-interface.cc
File lily/align-interface.cc (right):
http://codereview.appspot.com/4917046/diff/1/lily/ali
LGTM
On Thu, Aug 25, 2011 at 4:29 AM, wrote:
> Reviewers: ,
>
> Message:
> Hey all,
>
> This patch changes the name of several variables that I'll need to work
> on my beam slope stuff. If any developers are working on
> beam-quanting.cc and would like me to wait until their patch is pushed,
>
Carl Sorensen writes:
> On 8/27/11 7:44 AM, "David Kastrup" wrote:
>
>> Carl Sorensen writes:
>>
>>> On 8/27/11 7:21 AM, "David Kastrup" wrote:
>>>
Janek Warchoł writes:
> I wonder if this solution would yield good results: keep beam slope
> before and after break identic
On 8/27/11 7:44 AM, "David Kastrup" wrote:
> Carl Sorensen writes:
>
>> On 8/27/11 7:21 AM, "David Kastrup" wrote:
>>
>>> Janek Warchoł writes:
>>>
I wonder if this solution would yield good results: keep beam slope
before and after break identical (except for some beam quanting,
Carl Sorensen writes:
> On 8/27/11 7:21 AM, "David Kastrup" wrote:
>
>> Janek Warchoł writes:
>>
>>> I wonder if this solution would yield good results: keep beam slope
>>> before and after break identical (except for some beam quanting,
>>> perhaps, but that's less than 0.3 ss), but modify st
On 8/27/11 7:21 AM, "David Kastrup" wrote:
> Janek Warchoł writes:
>
>> I wonder if this solution would yield good results: keep beam slope
>> before and after break identical (except for some beam quanting,
>> perhaps, but that's less than 0.3 ss), but modify stem lengths: make
>> them as l
Janek Warchoł writes:
> I wonder if this solution would yield good results: keep beam slope
> before and after break identical (except for some beam quanting,
> perhaps, but that's less than 0.3 ss), but modify stem lengths: make
> them as long as they would be if there were no beam on the other
I wonder if this solution would yield good results: keep beam slope
before and after break identical (except for some beam quanting,
perhaps, but that's less than 0.3 ss), but modify stem lengths: make
them as long as they would be if there were no beam on the other side
of the break.
cheers,
Jane
On 8/27/11 6:45 AM, "Jan Nieuwenhuizen" wrote:
> Janek Warchoł writes:
>
>>> However, almost always it is Much Better (TM) to use the benchmarking
>>> approach: find how the great masters solved the situation and program
>>> LilyPond to do that. Is this documented somewhere, by the way?
>>
>>
On Aug 27, 2011, at 10:40 AM, pkx1...@gmail.com wrote:
> ok, this passes make but I get a lot of reg tests show up but I cannot
> see any diffs at all (i.e no 'green' shadows that indicate the changes).
> Either it's unbelievably subtle or something else is triggering the reg
> tests to show up.
http://codereview.appspot.com/4964041/diff/3001/make/website.make
File make/website.make (right):
http://codereview.appspot.com/4964041/diff/3001/make/website.make#newcode57
make/website.make:57: ### only update this when the language compiles
correctly!
On 2011/08/27 09:55:25, PhilEHolmes wrote
Janek Warchoł writes:
>> However, almost always it is Much Better (TM) to use the benchmarking
>> approach: find how the great masters solved the situation and program
>> LilyPond to do that. Is this documented somewhere, by the way?
>
> Sorry, i don't understand: do you say that we should use la
2011/8/23 Jan Nieuwenhuizen :
> To pull that to a meta-level: sometimes it makes sense to program
> LilyPond to do that which is obvious.
>
> However, almost always it is Much Better (TM) to use the benchmarking
> approach: find how the great masters solved the situation and program
> LilyPond to d
2011/8/22 Han-Wen Nienhuys :
> 2011/8/22 Janek Warchoł :
>> I wholeheartedly disagree, i think that this issue isn't negligible
>> (or did i misunderstood you, Han-Wen?).
>
> My impression is that the patch was not actually changing output.
> If it was intended to, I couldn't tell from a read of th
Am Saturday, 27. August 2011, 10:14:28 schrieb pkx1...@gmail.com:
> patching today's tree (27 Aug) I get
>
> --snip--
> jlowe@jlowe-lilybuntu2:~/lilypond-git$ patch -p1 <
> ../Desktop/issue224052_2001.diff
> patching file input/regression/figured-bass-continuation-center.ly
> patching file input/r
- Original Message -
From: "Jean-Charles Malahieude"
To: ; ;
;
Sent: Saturday, August 27, 2011 11:35 AM
Subject: Re: Fixes missing images in big website page (issue 4964041)
Le 27/08/2011 11:55, philehol...@googlemail.com disait :
This may be a repeat of what's in my reply, but two
Le 27/08/2011 11:55, philehol...@googlemail.com disait :
This may be a repeat of what's in my reply, but two places is better
than none?
I'm trying to get rid of the hard-coded languages in website build,
so that making changes to the language list involves only a single
change in the source fil
This may be a repeat of what's in my reply, but two places is better
than none?
I'm trying to get rid of the hard-coded languages in website build, so
that making changes to the language list involves only a single change
in the source files, rather than multiple ones. This is issue 1795 (but
se
New patch set uploaded.
http://codereview.appspot.com/4636081/diff/42001/lily/stem-tremolo.cc
File lily/stem-tremolo.cc (right):
http://codereview.appspot.com/4636081/diff/42001/lily/stem-tremolo.cc#newcode61
lily/stem-tremolo.cc:61: return scm_from_double ((Stem::duration_log
(stem) >= 3 && ge
passes make and reg tests
http://codereview.appspot.com/4961041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
passes make and reg tests
http://codereview.appspot.com/4894052/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
ok, this passes make but I get a lot of reg tests show up but I cannot
see any diffs at all (i.e no 'green' shadows that indicate the changes).
Either it's unbelievably subtle or something else is triggering the reg
tests to show up. They are to big to post them all here but he diffs
that show up
passes make and reg tests
http://codereview.appspot.com/4921050/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
passes make and reg tests
http://codereview.appspot.com/4923048/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
patching today's tree (27 Aug) I get
--snip--
jlowe@jlowe-lilybuntu2:~/lilypond-git$ patch -p1 <
../Desktop/issue224052_2001.diff
patching file input/regression/figured-bass-continuation-center.ly
patching file input/regression/figured-bass-figureorder-position.ly
patching file input/regression/f
passes make and reg tests
http://codereview.appspot.com/4931043/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
When I try to patch to current tree (27 Aug) I get
--snip--
patching file lily/part-combine-iterator.cc
Hunk #2 succeeded at 138 with fuzz 1.
Hunk #4 FAILED at 390.
Hunk #5 FAILED at 412.
2 out of 5 hunks FAILED -- saving rejects to file
lily/part-combine-iterator.cc.rej
patching file ly/music-fu
passes make and reg tests
http://codereview.appspot.com/4893044/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
43 matches
Mail list logo