Re: Change \transpose to \relative in ancient.itely (issue 7538043)

LGTM https://codereview.appspot.com/7538043/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

On 12 mars 2013, at 00:38, thomasmorle...@googlemail.com wrote: > Hi Mike, > > sorry to have some more nit-picks. > > > https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm > File scm/output-lib.scm (right): > > https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.s

Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

On 2013/03/11 23:38:17, thomasmorley65 wrote: https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm#newcode1052 scm/output-lib.scm:1052: 1.0 I'd do the scaling here. ly:stencil-scale would be superfluous than. Either scaling-method will change the direction of constante-hairpin

Re: Adds Ferneyhough hairpins to LilyPond. (issue 7615043)

Hi Mike, sorry to have some more nit-picks. https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm File scm/output-lib.scm (right): https://codereview.appspot.com/7615043/diff/15001/scm/output-lib.scm#newcode1051 scm/output-lib.scm:1051: 0.1 Hard-coded thickness. Why not multiply

Re: Freezing for 2.18

On Mon, Mar 11, 2013 at 7:59 PM, Werner LEMBERG wrote: > As said before, it's probably best if all developers actually use the > `stable' code since noone likes to switch between branches (due to the > enormous compilation hurdles). You mean having to recompile each time when you switch from stab

PATCHES: Countdown for March 14 - 19:00 GMT

Hello *Countdown – March 14th 2013 – 19:00 GMT* 3204 Crash David Kastrup Push articulate: can't compile music containing alternat

Re: Freezing for 2.18

> Last time around, we released 2.17.0 in the _wake_ of releasing > 2.16.0, and only _then_ the extensive skyline patches were placed > into 2.17 and 2.17.1 was released with them. That worked reasonably > well. We don't have the resources for parallel development and > testing, and it does not

Re: Freezing for 2.18

James writes: > On 11 March 2013 16:34, m...@mikesolomon.org wrote >> >> I like the idea of freezing right away and releasing after two >> weeks of critical-bug-free lily. What is difficult for me is >> setting the freeze down the line without being able to wrap up >> work f

Re: Freezing for 2.18

Hello, On 11 March 2013 16:34, m...@mikesolomon.org wrote: > On 11 mars 2013, at 16:32, "Trevor Daniels" wrote: > > > > > David Kastrup wrote Sunday, March 10, 2013 5:32 PM > > > >> 2.16 is growing old. > >> > >> So I want to see 2.18 soon. That means we need to stabilize work that > >> has al

Re: Freezing for 2.18

"Phil Holmes" writes: > - Original Message - > From: > To: "Trevor Daniels" > Cc: "David Kastrup" ; > Sent: Monday, March 11, 2013 4:34 PM > Subject: Re: Freezing for 2.18 >> >> I like the idea of freezing right away and releasing after two weeks >> of critical-bug-free lily. What is

Re: Freezing for 2.18

"m...@mikesolomon.org" writes: > On 11 mars 2013, at 16:32, "Trevor Daniels" wrote: >> >> I'd also like to propose we adopt the same controls as we did for >> 2.16, if David is willing, since that also worked well. That way >> we'll get a clear plan - what must be fixed, what must be documente

Re: Freezing for 2.18

- Original Message - From: To: "Trevor Daniels" Cc: "David Kastrup" ; Sent: Monday, March 11, 2013 4:34 PM Subject: Re: Freezing for 2.18 I like the idea of freezing right away and releasing after two weeks of critical-bug-free lily. What is difficult for me is setting the freeze d

Re: Freezing for 2.18

On 11 mars 2013, at 16:32, "Trevor Daniels" wrote: > > David Kastrup wrote Sunday, March 10, 2013 5:32 PM > >> 2.16 is growing old. >> >> So I want to see 2.18 soon. That means we need to stabilize work that >> has already been done and cut down on experiments in the master branch. > > Agree

Re: Freezing for 2.18

"Trevor Daniels" writes: > David Kastrup wrote Sunday, March 10, 2013 5:32 PM > >> At any rate, I'd like to aim for 2.18 at about the end of May, and >> getting into serious freeze at the end of April. A focus on bug >> fixes, in particular bugs introduced in the 2.17 development cycle, >> sho

Re: Freezing for 2.18

David Kastrup wrote Sunday, March 10, 2013 5:32 PM > 2.16 is growing old. > > So I want to see 2.18 soon. That means we need to stabilize work that > has already been done and cut down on experiments in the master branch. Agreed. > Stabilizing means more or less accepting the current feature

Re: Freezing for 2.18

Janek Warchoł writes: > On Mon, Mar 11, 2013 at 3:53 PM, David Kastrup wrote: >> Uh Janek? We have _never_ made a branch for stable releases until >> after we reached a state of convergence. The problem is that in >> order to get a stable release from a wobbly starting base, we need >> testers

Re: Freezing for 2.18

On Mon, Mar 11, 2013 at 3:53 PM, David Kastrup wrote: > Uh Janek? We have _never_ made a branch for stable releases until after > we reached a state of convergence. The problem is that in order to get > a stable release from a wobbly starting base, we need testers. If all > developers move on t

Re: Freezing for 2.18

Janek Warchoł writes: > On Mon, Mar 11, 2013 at 3:37 PM, David Kastrup wrote: >> >>> Add some doc updates and translations if they are available, or make >>> them known issues if not. As Janek says, anything else goes into a >>> branch. >> >> That's exactly what the disagreement is about. This

Re: Freezing for 2.18

On Mon, Mar 11, 2013 at 3:37 PM, David Kastrup wrote: > >> Add some doc updates and translations if they are available, or make >> them known issues if not. As Janek says, anything else goes into a >> branch. > > That's exactly what the disagreement is about. This "anything else goes > into a bra

Re: Freezing for 2.18

Colin Hall writes: > Janek Warchoł writes: > >> On Mon, Mar 11, 2013 at 1:59 PM, David Kastrup wrote: >>> So I see us at a crossroads here: either we decide we want to have a >>> stable release in a reasonable point of time in the near future, or we >>> decide we don't want to plan for a stable

Re: Freezing for 2.18

Hi, On Mon, Mar 11, 2013 at 3:06 PM, David Kastrup wrote: > Janek Warchoł writes: > >> On Mon, Mar 11, 2013 at 1:59 PM, David Kastrup wrote: >>> So I see us at a crossroads here: either we decide we want to have a >>> stable release in a reasonable point of time in the near future, or we >>> de

Re: Freezing for 2.18

Janek Warchoł writes: > On Mon, Mar 11, 2013 at 1:59 PM, David Kastrup wrote: >> So I see us at a crossroads here: either we decide we want to have a >> stable release in a reasonable point of time in the near future, or we >> decide we don't want to plan for a stable release anytime soon. >> >>

Re: Freezing for 2.18

Janek Warchoł writes: > On Mon, Mar 11, 2013 at 1:59 PM, David Kastrup wrote: >> You see me as "one person imposing a limit" because I brought up the >> issue of a stable release here. But I did not bring up the issue out of >> spite and malice but because I realized that the kind of open-ended

Re: Freezing for 2.18

On Mon, Mar 11, 2013 at 1:59 PM, David Kastrup wrote: > You see me as "one person imposing a limit" because I brought up the > issue of a stable release here. But I did not bring up the issue out of > spite and malice but because I realized that the kind of open-ended > changes not leading to any

Re: Freezing for 2.18

"m...@mikesolomon.org" writes: > On 10 mars 2013, at 22:30, David Kastrup wrote: > >> Werner LEMBERG writes: >> So, to resume, I agree that a freeze is important. When the freeze kicks in, I'd rather that we say something like "no new big projects starting on date X will be par

Re: Freezing for 2.18

On 10 mars 2013, at 22:30, David Kastrup wrote: > Werner LEMBERG writes: > >>> So, to resume, I agree that a freeze is important. When the freeze >>> kicks in, I'd rather that we say something like "no new big projects >>> starting on date X will be part of 2.18" so that developers can plan >>

strange behaviour of DynamicText alignment

Hi, when trying to generalize our alignment methods, i've noticed that DynamicTexts are not placed as i would expect them. Among others, there are two widely used alignment callbacks: aligned-on-xy-parent and xy-aligned-on-self. xy-aligned-on-self aligns desired point of the grob (i.e. its cente

strange behaviour of relative_coordinate

Hi, I'm poking around self-alignment-interface and functions that work with extents, offsets etc. I've found a Grob method relative_coordinate (Grob const *refp, Axis a) and i suppose its purpose is to return the offset between me and refp along axis a. So far so good, but i've noticed that it

Re: Allows minimum-length to work for end-of-line spanners. (issue 7453046)

On 2013/03/10 00:32:43, mike7 wrote: >> > Why is this override needed for the regtest? The other overrides > are >> > obvious user-accessible overrides for triggering the tested >> > functionality. >> > >> > But should _this_ override not be the default? >> > >> > https://codereview.appspot.com

Re: Lilypond.org down

it's up now 2013/3/11 Phil Holmes > For me, and for > http://www.**downforeveryoneorjustme.com/. > Guess we wait a while and then try to contact the admin. > > -- > Phil Holmes > > > > __**_ > lilypond-devel m

Re: GUB error with unpure-pure-container.cc

- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: "Devel" Sent: Monday, March 11, 2013 8:02 AM Subject: Re: GUB error with unpure-pure-container.cc "Phil Holmes" writes: I accidentally mucked up some of my GUB set up, so have been essentially rebuilding from scratc

Lilypond.org down

For me, and for http://www.downforeveryoneorjustme.com/. Guess we wait a while and then try to contact the admin. -- Phil Holmes ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: GUB error with unpure-pure-container.cc

"Phil Holmes" writes: > I accidentally mucked up some of my GUB set up, so have been > essentially rebuilding from scratch. In doing so, I get this error: > > /home/gub/gub/target/darwin-ppc/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/unpure-pure-container.cc:140: > error: