iris-aiandClaude Opus 5
a271795408
Three commits on iris #18, now at `08c9d5a`. `aea878d` fixes the ignored `redrawing_one_widget_does_not_move_what_scrolls_ around_it`, and the bisect this document reported for it was a red herring: `95fb4f9` cannot be the cause, since the failing tree has no `Masked` in it. The cause was `redraw` skipping a dirty widget's second ask whenever the offer and the final box were the same *length*. It also closed three of the four unreduced shrinker leads and two of the three depth-6 oracle seeds; the two that are left are written up with their reductions. `60367d8` stops `Holds::through` allowing for a rounding that did not happen, which compounded down a chain of widgets each taking the whole of its parent. `08c9d5a` makes `Fixed::mul` drop to the step below (Bryan: truncation is preferable at this point), with the two short-circuits priced against the old multiply. Measured against the float head in `iris-float-cmp`, which is the comparison that was asked for: 1,800M instructions and 715M cycles against 1,761M and 688M, from 1,915M and 777M -- three quarters of the instruction gap and two thirds of the cycle gap closed. The float pair's work counters differ and the fixed-point pair's twenty-five are identical, so only the second number is same-work-at-a-different-speed; both are in the table. Also recorded: `cycles:u` returns garbage readings in this VM the way `instructions:u` does, and a whole set of three can be garbage at once; `tabs` is no longer a byte-identical render and why; and Bryan's idea of composing in `i64` and narrowing only when storing, with what is already protected, what is not, and the test that would say it worked. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>