Graham, you wrote Wednesday, August 31, 2011 6:11 AM
On Tue, Aug 30, 2011 at 11:25:27PM +0100, Trevor Daniels wrote:
Graham, you wrote Tuesday, August 30, 2011 2:43 AM
>LARGE PATCHES
>
>SHORT PATCHES
I think just CODE PATCHES for these. It's
hard to think of a meaningful difference.
Numbe
On Tue, Aug 30, 2011 at 11:25:27PM +0100, Trevor Daniels wrote:
>
> Graham, you wrote Tuesday, August 30, 2011 2:43 AM
>
> >LARGE PATCHES
> >
> >SHORT PATCHES
>
> I think just CODE PATCHES for these. It's
> hard to think of a meaningful difference.
> Number of affected files, number of changed
Graham, you wrote Tuesday, August 30, 2011 2:43 AM
Rather, I'd like to have a clearer format for the countdowns. I'm
thinking of something like this:
SYNTAX CHANGES
tick
MAINTAINABILITY
tick
LARGE PATCHES
SHORT PATCHES
I think just CODE PATCHES for these. It's
hard to think of a m
Am Dienstag, 30. August 2011, 19:40:31 schrieb Mike Solomon:
> In this case, it seems like the property should be called positions and not
> length. Length presupposes that the begin position remains constant and
> the end chagnes, whereas positions should take a pair that gives the
> bottom and t
Mike Solomon wrote Tuesday, August 30, 2011 6:40 PM
In this case, it seems like the property should
be called positions and not length.
Why, if it's a length?
Length presupposes that the begin position remains
constant
Exactly. That's why it's easy to understand. It
conveys exactly t
Mike Solomon writes:
> On Aug 30, 2011, at 7:17 PM, Keith OHara wrote:
>
>> Mike Solomon ufl.edu> writes:
>>
>>> As I stated in a previous mail, it is easy to re-instate
>>> a length property in the stem-interface and then
>>> build it into either Stem::internal_height or Stem::print.
>>> I
On Aug 30, 2011, at 7:17 PM, Keith OHara wrote:
> Mike Solomon ufl.edu> writes:
>
>> As I stated in a previous mail, it is easy to re-instate
>> a length property in the stem-interface and then
>> build it into either Stem::internal_height or Stem::print.
>> I have no problem with this.
>>
>
Mike Solomon ufl.edu> writes:
> As I stated in a previous mail, it is easy to re-instate
> a length property in the stem-interface and then
> build it into either Stem::internal_height or Stem::print.
> I have no problem with this.
>
The KEEP LENGTH option is the best,
because 'length and 'Y
On Aug 30, 2011, at 4:14 PM, Dmytro O. Redchuk wrote:
> On Tue 30 Aug 2011, 16:08 Mike Solomon wrote:
>> Currently, the stem stencil function is doable in Scheme, which means that
>> the result from 2.15.8 can be achieved via :
> Thank you for your work! I've "bookmarked" this hint/thread, of cour
Mike, you wrote Tuesday, August 30, 2011 3:41 PM
As I stated in a previous mail, it is easy to
re-instate a length property in the stem-interface
and then build it into either Stem::internal_height
or Stem::print. I have no problem with this.
I'd vote for this. Let's see what others thin
On Aug 30, 2011, at 3:04 PM, Trevor Daniels wrote:
>
> Mike Solomon wrote Tuesday, August 30, 2011 12:45 PM
>
>> I believe that Trevor is claiming that #(stem::length 5) is worse from a
>> UI-perspective than #5.
>
> Yes.
>> I think he is right insofar as stem::length means there are more t
On Tue 30 Aug 2011, 16:08 Mike Solomon wrote:
> Currently, the stem stencil function is doable in Scheme, which means that
> the result from 2.15.8 can be achieved via :
Thank you for your work! I've "bookmarked" this hint/thread, of course.
I am still wondering, is stem the single grob so far, wh
On Aug 30, 2011, at 2:31 PM, Dmytro O. Redchuk wrote:
> On Tue 30 Aug 2011, 15:02 I wrote:
>> Being a user, I often used to override 'Y-extent for some specific purposes:
>>
>> {
>> \override Stem #'Y-extent = #'(-10 . 0)
>> c''_\fermata
>> }
> Oh, yes, 2.15.9 changes stem's length.
>
> 2.15.8
On Aug 30, 2011, at 1:53 PM, Graham Percival wrote:
> On Tue, Aug 30, 2011 at 01:45:20PM +0200, Mike Solomon wrote:
>> In current master, #'Y-extent = #(stem::length 5) does exactly what #'length
>> = #5 did a week ago.
>
> There is essentially no different in going frmo
> \override Stem #'leng
Mike Solomon wrote Tuesday, August 30, 2011 12:45 PM
I believe that Trevor is claiming that
#(stem::length 5) is worse from a UI-perspective
than #5.
Yes.
I think he is right insofar as stem::length
means there are more things to type,
No. That's not the point. A user wanting to
ch
On Tue 30 Aug 2011, 15:02 I wrote:
> Being a user, I often used to override 'Y-extent for some specific purposes:
>
> {
> \override Stem #'Y-extent = #'(-10 . 0)
> c''_\fermata
> }
Oh, yes, 2.15.9 changes stem's length.
2.15.8 and below did not change it.
2.15.8 and below changed grob's _ext
On Tue 30 Aug 2011, 12:53 Graham Percival wrote:
> On Tue, Aug 30, 2011 at 01:45:20PM +0200, Mike Solomon wrote:
> > In current master, #'Y-extent = #(stem::length 5) does exactly what
> > #'length = #5 did a week ago.
>
> There is essentially no different in going frmo
> \override Stem #'lengt
On Tue, Aug 30, 2011 at 01:45:20PM +0200, Mike Solomon wrote:
> In current master, #'Y-extent = #(stem::length 5) does exactly what #'length
> = #5 did a week ago.
There is essentially no different in going frmo
\override Stem #'length = #5
to
\override Stem #'Y-extent = #5
as far as users a
On Aug 30, 2011, at 1:27 PM, Graham Percival wrote:
> On Tue, Aug 30, 2011 at 01:07:46PM +0200, Mike Solomon wrote:
>> Bad: the user has to use a new syntax - instead of \override Stem #'length =
>> #5, they need to type \override Stem #'Y-extent = #(stem::length 5)
>
> What's the difference (fr
On Tue, Aug 30, 2011 at 01:07:46PM +0200, Mike Solomon wrote:
> Bad: the user has to use a new syntax - instead of \override Stem #'length =
> #5, they need to type \override Stem #'Y-extent = #(stem::length 5)
What's the difference (from your end) between #(stem::length 5)
and #5 ?
> A mid-way
On Aug 30, 2011, at 12:06 PM, Trevor Daniels wrote:
>
> Mike Solomon wrote Monday, August 29, 2011 9:11 AM
>
>> On Mon, Aug 29, 2011 at 07:45:04AM +, tdanielsmu...@googlemail.com wrote:
>>
>>> I can't say I like this change: it makes a complex user
>>> interface more complex. Shouldn't we
Mike Solomon wrote Monday, August 29, 2011 9:11 AM
On Mon, Aug 29, 2011 at 07:45:04AM +,
tdanielsmu...@googlemail.com wrote:
I can't say I like this change: it makes a complex user
interface more complex. Shouldn't we be moving in the
opposite direction?
I disagree.
[snip descriptio
On Mon, Aug 29, 2011 at 11:32:16PM +0100, Trevor Daniels wrote:
>
> Indeed. Perhaps we could make a clearer distinction
> between patches that must be reviewed, like those
> which cause syntax changes, those which add new
> features and those by relative newcomers, and those
> that should simply
Graham Percival wrote Monday, August 29, 2011 9:55 AM
On Mon, Aug 29, 2011 at 09:15:54AM +0100, Trevor Daniels wrote:
If you force patches through at the present rate
they're not going to be carefully reviewed.
I'm open to suggestions. The development team is producing
approximately 20 pa
Am Montag, 29. August 2011, 11:56:17 schrieb Janek Warchoł:
> From my point of view, commit messages, descriptions in tracker and on
> Rietveld are essential. Some patches have no description and i cannot
> say anything about them.
+1. Also, Rietveld descriptions like "Fix 1234" are NOT useful a
2011/8/29 Graham Percival :
> On Mon, Aug 29, 2011 at 09:15:54AM +0100, Trevor Daniels wrote:
>>
>> I've given up looking at code-change patch count-downs.
> ...
>> If you force patches through at the present rate
>> they're not going to be carefully reviewed.
>
> I'm open to suggestions. The deve
On Aug 29, 2011, at 10:55 AM, Graham Percival wrote:
> On Mon, Aug 29, 2011 at 09:15:54AM +0100, Trevor Daniels wrote:
>>
>> Graham Percival wrote Monday, August 29, 2011 8:53 AM
>>
>>> Moral of the story? pay more attention to patch countdowns, I
>>
>> I've given up looking at code-change pa
On Mon, Aug 29, 2011 at 09:15:54AM +0100, Trevor Daniels wrote:
>
> Graham Percival wrote Monday, August 29, 2011 8:53 AM
>
> >Moral of the story? pay more attention to patch countdowns, I
>
> I've given up looking at code-change patch count-downs.
...
> If you force patches through at the pres
Graham Percival wrote Monday, August 29, 2011 8:53 AM
Moral of the story? pay more attention to patch countdowns, I
I've given up looking at code-change patch count-downs.
There's no way I can spare the time required. Each
one requires the time to understand the area of code,
analyse the pa
On Aug 29, 2011, at 9:53 AM, Graham Percival wrote:
> On Mon, Aug 29, 2011 at 07:45:04AM +, tdanielsmu...@googlemail.com wrote:
>> I can't say I like this change: it makes a complex user
>> interface more complex. Shouldn't we be moving in the
>> opposite direction?
>
I disagree.
There used
On Mon, Aug 29, 2011 at 07:45:04AM +, tdanielsmu...@googlemail.com wrote:
> I can't say I like this change: it makes a complex user
> interface more complex. Shouldn't we be moving in the
> opposite direction?
On general principle I agree, but I believe that this patch simply
brings the docs
I can't say I like this change: it makes a complex user
interface more complex. Shouldn't we be moving in the
opposite direction?
http://codereview.appspot.com/4965053/diff/4001/Documentation/learning/tweaks.itely
File Documentation/learning/tweaks.itely (right):
http://codereview.appspot.com/
On 11-08-28 03:05 PM, Mike Solomon wrote:
On Aug 28, 2011, at 7:23 PM, mts...@gmail.com wrote:
Hey all,
I got a clean doc build with this newest patch set - please confirm.
Cheers,
MS
http://codereview.appspot.com/4965053/
A heads up to everyone that I'm going on vacation on Thursday for t
On Aug 28, 2011, at 7:23 PM, mts...@gmail.com wrote:
> Hey all,
>
> I got a clean doc build with this newest patch set - please confirm.
>
> Cheers,
> MS
>
> http://codereview.appspot.com/4965053/
>
A heads up to everyone that I'm going on vacation on Thursday for two weeks and
that I'll be
Hey all,
I got a clean doc build with this newest patch set - please confirm.
Cheers,
MS
http://codereview.appspot.com/4965053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Ha...how about that.
I'll look into it when I get back, but good to know that the docs are
compilable without this patch applied.
Cheers,
MS
http://codereview.appspot.com/4965053/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.g
New patch set uploaded - haven't finished building docs yet, but I think
this will go through to the end. Will report back in a couple hours
(make doc nearly done, but I have to leave the house).
Cheers,
MS
http://codereview.appspot.com/4965053/
___
amusingly, I have no trouble compiling the docs without this patch, but
it fails with this patch applied:
/main/src/lilypond/build/out/lybook-db/b5/lily-2dcca534.ly:1097:9:
warning: no viable initial configuration found: may not find good beam
slope
<
c ees>8 f g
Segmentation fau
Reviewers: ,
Message:
This gets rid of Stem #'length in the docs. I haven't run make doc yet,
but I will right after this and will report back in a couple hours with
a new patch that makes any additional necessary changes.
Cheers,
MS
Description:
Gets rid of length in the docs.
Please review
39 matches
Mail list logo
