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
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
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
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
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
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
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/4894052/
___
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/4961041/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
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
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
- Original Message -
From: Jean-Charles Malahieude lily...@orange.fr
To: philehol...@googlemail.com; percival.music...@gmail.com;
lilypond-devel@gnu.org; re...@codereview.appspotmail.com
Sent: Saturday, August 27, 2011 11:35 AM
Subject: Re: Fixes missing images in big website page
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
2011/8/22 Han-Wen Nienhuys hanw...@gmail.com:
2011/8/22 Janek Warchoł janek.lilyp...@gmail.com:
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,
2011/8/23 Jan Nieuwenhuizen jann...@gnu.org:
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
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 layer
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
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.
On 8/27/11 6:45 AM, Jan Nieuwenhuizen jann...@gnu.org 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?
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,
Janek Warchoł janek.lilyp...@gmail.com 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
Carl Sorensen c_soren...@byu.edu writes:
On 8/27/11 7:21 AM, David Kastrup d...@gnu.org wrote:
Janek Warchoł janek.lilyp...@gmail.com 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
On 8/27/11 7:44 AM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
On 8/27/11 7:21 AM, David Kastrup d...@gnu.org wrote:
Janek Warchoł janek.lilyp...@gmail.com writes:
I wonder if this solution would yield good results: keep beam slope
before and after
Carl Sorensen c_soren...@byu.edu writes:
On 8/27/11 7:44 AM, David Kastrup d...@gnu.org wrote:
Carl Sorensen c_soren...@byu.edu writes:
On 8/27/11 7:21 AM, David Kastrup d...@gnu.org wrote:
Janek Warchoł janek.lilyp...@gmail.com writes:
I wonder if this solution would yield good
LGTM
On Thu, Aug 25, 2011 at 4:29 AM, mts...@gmail.com 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
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):
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
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 will
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: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.
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
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
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
David Kastrup d...@gnu.org 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
On 8/27/11 4:41 PM, David Kastrup d...@gnu.org wrote:
David Kastrup d...@gnu.org 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
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.
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
Carl Sorensen c_soren...@byu.edu writes:
On 8/27/11 4:41 PM, David Kastrup d...@gnu.org wrote:
David Kastrup d...@gnu.org writes:
Previously #{ ... #} created only sequential music. This changes it to
accept everything an assignment accepts. Incompatibility to before:
#{ #} returns a
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 !=
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 bunch
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 done that,
41 matches
Mail list logo
