On Oct 4, 2011, at 3:26 PM, Han-Wen Nienhuys wrote:
> You skipped the cosmetic patch that folds together the (SCM, SCM)
> callbacks into one big quanting callback.
>
> I assume this is the real patch,
>
> + if (consistent_broken_slope_)
> + {
> + Interval normalized_endpoints = robust_scm2interval
> (beam_->get_property ("normalized-endpoints"), Interval (0, 1));
> + Real y_length = final_positions[RIGHT] - final_positions[LEFT];
> +
> + final_positions[LEFT] += normalized_endpoints[LEFT] * y_length;
> + final_positions[RIGHT] -= (1 - normalized_endpoints[RIGHT]) * y_length;
> + }
>
>
> am I correct?
>
>
> On Tue, Oct 4, 2011 at 6:57 AM, Mike Solomon <mike...@ufl.edu> wrote:
>
>> Hey all,
>>
>> The cosmetic stuff is pushed to current master and I've posted a new slope
>> patch on Rietveld that applies cleanly to current master.
>>
>> The only concern I have is that, running regtests this morning, I am getting
>> sporadic differences in graphviz.log. These have appeared since I pushed
>> the cosmetic patch. Does anyone know where these could be coming from?
>> Perhaps an uninitialized variable? Everything else builds cleanly with no
>> warnings, but for some reason, this is persistent.
>
> graphviz draws dependencies between grobs, so if you change the
> internal dependencies of properties, it may shift things around.
>
What's odd is that the chart didn't change - just the order that things were
printed. As this normally shouldn't change in a deterministic system, I wanted
to give the heads up. Lemme know if others spot the same fishy behavior.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
