On Mon, Mar 21, 2011 at 11:18 PM, Keith OHara
<address@hidden> wrote:
On Mon, 21 Mar 2011 23:06:12 -0700, Joe Neeman <
address@hidden> wrote:
Unfortunately, if I protect the assignment to the property with an if
(!pure), I am letting the page-breaking planning rely on the user-requested
affinities, and then changing them for the page-layout phase. The boolean
'pure' asks explicitly that we keep the state unchanged, but there was
always an implicit expectation that certain properties are unchanging.
I don't quite understand this comment. The only effect of set_property is to
prevent the warning from being triggered more than once per system. In fact,
the layout would be completely unchanged even if you removed the whole
if(after_affinity > before_affinity) block. So why does it matter if we
condition set_property on something?
In a typical case, the effect is after->set_property("staff-affinity", DOWN)
and then when get_spacing_spec is called to determine the next spring, working through the (non)staffs in the system, it will look up the staff affinity we just set for use as before_affinity, thus the next spring is changed. The code in the if(after_affinity>before_affinity) block does change the output for the example at the head of issue 1555.
Ok, good point. In that case, a better way to avoid too many warnings might be just to add a static bool to check if a warning has already been issued.
Joe