[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Sketch for broken beams with consistent slopes (issue 4961041)
From: |
Han-Wen Nienhuys |
Subject: |
Re: Sketch for broken beams with consistent slopes (issue 4961041) |
Date: |
Tue, 4 Oct 2011 10:26:46 -0300 |
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.
--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen
Re: Sketch for broken beams with consistent slopes (issue 4961041), pkx166h, 2011/10/03
Re: Sketch for broken beams with consistent slopes (issue 4961041), pkx166h, 2011/10/05
Re: Sketch for broken beams with consistent slopes (issue 4961041), pkx166h, 2011/10/06
Re: Sketch for broken beams with consistent slopes (issue 4961041), n . puttock, 2011/10/20