Re: Sketch for broken beams with consistent slopes (issue 4961041)

[Mike Solomon]

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 <address@hidden> 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