mike apollinemike.com apollinemike.com> writes:
> >> > On 2012/06/12 12:49:45, dak wrote:
> >> > > http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc
> >> > > File lily/grob.cc (right):
> >> > >
> >> > >
> > http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc#newcode472
> >>
http://codereview.appspot.com/6303065/diff/9001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/6303065/diff/9001/lily/stem.cc#newcode710
lily/stem.cc:710: if (calc_beam && !beam && !unsmob_stencil
(me->get_property ("stencil")))
On 2012/06/11 16:33:27, Keith wrote:
If you
On 15 juin 2012, at 09:33, d...@gnu.org wrote:
> On 2012/06/12 13:22:10, dak wrote:
>> On 2012/06/12 12:54:40, MikeSol wrote:
>> > On 2012/06/12 12:49:45, dak wrote:
>> > > http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc
>> > > File lily/grob.cc (right):
>> > >
>> > >
> http://coder
On 2012/06/12 13:22:10, dak wrote:
On 2012/06/12 12:54:40, MikeSol wrote:
> On 2012/06/12 12:49:45, dak wrote:
> > http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc
> > File lily/grob.cc (right):
> >
> >
http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc#newcode472
> > li
On 2012/06/12 13:47:34, MikeSol wrote:
On 2012/06/12 13:43:09, dak wrote:
> If a type is named "Interval", it needs to be employed as an
Interval, not as
> something totally different that relies on implementation details.
>
> Otherwise type abstraction makes code _less_ maintainable rather
On 2012/06/12 13:43:09, dak wrote:
Here is a code example from beam.cc:
Interval weights (1 - multiplier, multiplier);
if (feather_dir != LEFT)
weights.swap ();
This is _hogwash_. weights is not an _interval_ here, but a pair of
numbers.
Swapping the bounds of a
Here is a code example from beam.cc:
Interval weights (1 - multiplier, multiplier);
if (feather_dir != LEFT)
weights.swap ();
This is _hogwash_. weights is not an _interval_ here, but a pair of
numbers. Swapping the bounds of an interval does not even make _sense_.
Where
On 2012/06/12 13:22:10, dak wrote:
On 2012/06/12 12:54:40, MikeSol wrote:
> On 2012/06/12 12:49:45, dak wrote:
> > http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc
> > File lily/grob.cc (right):
> >
> >
http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc#newcode472
> > li
On 2012/06/12 12:54:40, MikeSol wrote:
On 2012/06/12 12:49:45, dak wrote:
> http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc
> File lily/grob.cc (right):
>
>
http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc#newcode472
> lily/grob.cc:472: real_ext[d] += offset;
> On 201
On 2012/06/12 12:49:45, dak wrote:
http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc
File lily/grob.cc (right):
http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc#newcode472
lily/grob.cc:472: real_ext[d] += offset;
On 2012/06/12 12:32:37, dak wrote:
> I don't understand
http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc
File lily/grob.cc (right):
http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc#newcode472
lily/grob.cc:472: real_ext[d] += offset;
On 2012/06/12 12:32:37, dak wrote:
I don't understand this. The only way to get a nan from
On 2012/06/12 12:32:37, dak wrote:
http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc
File lily/grob.cc (right):
http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc#newcode472
lily/grob.cc:472: real_ext[d] += offset;
I don't understand this. The only way to get a nan fro
http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc
File lily/grob.cc (right):
http://codereview.appspot.com/6303065/diff/10003/lily/grob.cc#newcode472
lily/grob.cc:472: real_ext[d] += offset;
I don't understand this. The only way to get a nan from adding an
offset to infinity is by a
LGTM if you re-read the comment before you push.
http://codereview.appspot.com/6303065/diff/9001/lily/stem.cc
File lily/stem.cc (right):
http://codereview.appspot.com/6303065/diff/9001/lily/stem.cc#newcode707
lily/stem.cc:707: return an empty interval when there is no beam.
The comment doesn't
On 2012/06/11 07:48:34, dak wrote:
On 2012/06/11 07:24:33, MikeSol wrote:
> On 2012/06/11 07:10:48, dak wrote:
>
> > Personally, I consider it an accident waiting to happen if downing
the
stencil
> > is not enough to suppress its consideration.
> >
> > _Iff_ there is a situation where it is rea
On 2012/06/11 07:24:33, MikeSol wrote:
On 2012/06/11 07:10:48, dak wrote:
> Personally, I consider it an accident waiting to happen if downing
the stencil
> is not enough to suppress its consideration.
>
> _Iff_ there is a situation where it is really required to have a
non-zero
> height,
On 2012/06/11 07:10:48, dak wrote:
On 2012/06/11 05:34:23, MikeSol wrote:
> This shows a case where stem height cannot be determined by stem
stencil
> presence. The first version of the patch works under the assumption
that
> information about height cannot be gleaned from the stencil and
On 2012/06/11 05:34:23, MikeSol wrote:
This shows a case where stem height cannot be determined by stem
stencil
presence. The first version of the patch works under the assumption
that
information about height cannot be gleaned from the stencil and must
be made
explicit through overrides.
On 2012/06/10 18:22:50, MikeSol wrote:
Another way of going about this would be changing the Stem::height
function so
that it returned an empty interval for stencil-less stems.
I'd consider that eminently reasonable. It makes much more sense to me
than having to wipe out some non-sensical re
Reviewers: ,
Message:
Another way of going about this would be changing the Stem::height
function so that it returned an empty interval for stencil-less stems.
Then the overrides wouldn't be necessary. It's a design question more
than anything else.
Description:
Sets TabVoice Stem height to ##f
20 matches
Mail list logo
