headers
Carl Sorensen | 1 May 2011 02:24

Re: Backporting / stable

On 4/30/11 4:51 PM, "mike <at> apollinemike.com" <mike <at> apollinemike.com> wrote:

> On Apr 30, 2011, at 8:03 AM, Graham Percival wrote:
> 
>> On Sat, Apr 30, 2011 at 08:52:42AM -0600, Carl Sorensen wrote:
>>> On 4/30/11 8:49 AM, "Graham Percival" <graham <at> percival-music.ca> wrote:
>>> 
>>>> We don't need to be sure that we're clear.  All we need... or at
>>>> least, all I want before uploading the official 2.14.0... is for
>>>> one week without *known* Critical bugs.
>>> 
>>> Right, but we haven't had that happen with the beaming since
>>> beam-collision-engraver was added.
>> 
>> I'm pretty certain that we've had at least one 7-day period
>> without new Critical bugs -- the only probablem was that such
>> periods coincided with having old Critical bugs around.
>> 
>> I'll admit that our record so far is still less than 48 hours of
>> critical-bug-free-ness.  But once we *do* have some bugs in the
>> system, we can go for days and days without any new critical bugs
>> being reported.  If we'd been a bit faster in fixing some bugs, or
>> a bit luckier and having a Critical bug report a few days later...
>> or luckier in having critical bugs being reported earlier, and
>> then getting fixed earlier... then I think we could have had 2.14
>> by now.
>> 
>>>> Well, I'm on vacation for most of May, so we're looking at a June
>>>> release at the earliest, in any case.
>>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
mike@apollinemike.com | 1 May 2011 02:45

Re: Fixes issues 1639 and 1640. (issue4457042)

On Apr 30, 2011, at 3:49 PM, mike <at> apollinemike.com wrote:

> On Apr 30, 2011, at 3:45 PM, Carl.D.Sorensen <at> gmail.com wrote:
> 
>> Regtest for 1640?
>> 
>> 
>> 
>> http://codereview.appspot.com/4457042/
> 
> Added.

Pushed as 475a1f94b5733476d746d2c012809f3f2e6f0fcc.

Cheers,
MS
Permalink | Reply | 0 comments |
headers
mtsolo | 1 May 2011 02:49
Picon

Another fix candidate for issue 1613. (issue4426072)

Reviewers: ,

Message:
This is a significant rewrite of one chunk of of beam.cc that fixes
issue 1613.

I won't have the time to run the regtests today to think if it breaks
anything, but I have run it on several test files and it seems to yield
good results.  Please look it over and let me know what you think!

Cheers,
MS

Description:
Another fix candidate for issue 1613.

Please review this at http://codereview.appspot.com/4426072/

Affected files:
   M lily/beam.cc

Index: lily/beam.cc
diff --git a/lily/beam.cc b/lily/beam.cc
index  
938567984ecc81f2b96889bec0c0432c0f99e09c..31f6cc9339ae90466d8aeb7a69e97e4f26224b3a  
100644
--- a/lily/beam.cc
+++ b/lily/beam.cc
 <at>  <at>  -1182,13 +1182,6  <at>  <at>  Beam::shift_region_to_valid (SCM grob, SCM posns)
        feasible_left_point.intersect (flp);
(Continue reading)

Permalink | Reply | 9 comments |
headers
Carl.D.Sorensen | 1 May 2011 02:56
Picon

Re: Another fix candidate for issue 1613. (issue4426072)

Looks good to me -- just a comment on a variable name.

http://codereview.appspot.com/4426072/diff/1001/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/4426072/diff/1001/lily/beam.cc#newcode1272
lily/beam.cc:1272: Interval vorboten;
We shouldn't use german words for variable names, I think.  English is
the standard code language for lilypond.

And if we do, we should spell it properly -- I'm pretty sure the
spelling is verboten.

Perhaps "disallowed"?

http://codereview.appspot.com/4426072/
Permalink | Reply | 0 comments |
headers
mtsolo | 1 May 2011 03:36
Picon

Re: Another fix candidate for issue 1613. (issue4426072)

Sorry about that...back to German 101!

http://codereview.appspot.com/4426072/diff/1001/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/4426072/diff/1001/lily/beam.cc#newcode1272
lily/beam.cc:1272: Interval vorboten;
On 2011/05/01 00:56:39, Carl wrote:
> We shouldn't use german words for variable names, I think.  English is
the
> standard code language for lilypond.

> And if we do, we should spell it properly -- I'm pretty sure the
spelling is
> verboten.

> Perhaps "disallowed"?

Changed and a new patchset uploaded.

http://codereview.appspot.com/4426072/
Permalink | Reply | 0 comments |
headers
Han-Wen Nienhuys | 1 May 2011 04:44
Picon

Re: Another fix candidate for issue 1613. (issue4426072)

Can you document what this is doing?

My idea was to have a datatype

class RealSubset {
  // Starts out as full interval
  Real_subset();

  // Remove an interval
  remove(Interval v);

  // Return sorted, non-overlapping list of allowed intervals
  vector<Interval> allowed() const;

  // implement with list or tree of non-overlapping intervals
}

You create such an object, remove the extents of all collisions (duly
transformed to be corresponding to left beam edge).  Finally, pick the
center of the most sensible interval from allowed(), one which is not
too small and as close as possible to the original left Y.

On Sat, Apr 30, 2011 at 9:49 PM,  <mtsolo <at> gmail.com> wrote:
> Reviewers: ,
>
> Message:
> This is a significant rewrite of one chunk of of beam.cc that fixes
> issue 1613.
>
> I won't have the time to run the regtests today to think if it breaks
(Continue reading)

Permalink | Reply | 0 comments |
headers
mtsolo | 1 May 2011 06:29
Picon

Re: Another fix candidate for issue 1613. (issue4426072)

On 2011/05/01 02:44:31, hanwenn wrote:
> Can you document what this is doing?

> My idea was to have a datatype

> class RealSubset {
>    // Starts out as full interval
>    Real_subset();

>    // Remove an interval
>    remove(Interval v);

>    // Return sorted, non-overlapping list of allowed intervals
>    vector<Interval> allowed() const;

>    // implement with list or tree of non-overlapping intervals
> }

> You create such an object, remove the extents of all collisions (duly
> transformed to be corresponding to left beam edge).  Finally, pick the
> center of the most sensible interval from allowed(), one which is not
> too small and as close as possible to the original left Y.

Hey Han-Wen,

I put some more comments in a new patch in hopes that it is enough to
help you make an implementation of the type of thing you're talking
about.  Conversely, if you think that the patch in its current state is
admissible, let me know.
(Continue reading)

Permalink | Reply | 0 comments |
headers
tdanielsmusic | 1 May 2011 09:57

Re: Avoid repeats of 'staff-affinity' warning; change text. (issue4278058)

LGTM

http://codereview.appspot.com/4278058/
Permalink | Reply | 0 comments |
headers
Trevor Daniels | 1 May 2011 10:20
Picon

Re: Backporting / stable


Carl Sorensen wrote Saturday, April 30, 2011 1:59 PM

> So it appears that the biggest source of Critical bugs, and the 
> thing that
> is holding up release of 2.14, is the beam-collision-engraver.
>
> Should we try to remove the beam-collision-engraver from 2.14.0? 
> Or should
> we wait for it to settle itself out and make it part of 2.14.0?  I 
> can see
> arguments for both.

It's such a great feature we should do our best to
include it in 2.14.  While we definitely don't want
to release 2.14 with known critical bugs, more bugs
are likely to show up as soon as 2.14 is in widespread
use.  Fixing them is what 2.14.1 is for, so I would
not be too demanding in our criteria for 2.14.0.

Trevor
Permalink | Reply | 2 comments |
headers
hanwenn | 1 May 2011 14:24
Picon

Re: Another fix candidate for issue 1613. (issue4426072)


http://codereview.appspot.com/4426072/diff/4002/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/4426072/diff/4002/lily/beam.cc#newcode1329
lily/beam.cc:1329: while (dirty);
this looks fishy; what guarantees that the loop will terminate?

   forbidden is

     [ (-inf, 2), (1, inf) ]

this will loop forever?

http://codereview.appspot.com/4426072/
Permalink | Reply | 1 comment |

Gmane