We originally intended to start pushing ranger code into trunk shortly
after the start of stage 1, but of course.. delays, delays :-)
So here is the latest status/changes since last fall and our proposed
time-line going forward. I'll do the executive summary here, and more
details at each submission stage.
1) multi-range support - Imminent
We have moved the representation of our multi-range class from wide-int
to trees, and merged it with the value_range class . There is now a
base class which "recognizes" a 1 sub-range case as a special legacy
mode which supports ANTI_RANGE and incorporates the original value_range
code. Multi-range is fully interoperable/compatible with value_range
code now and all existing code which uses value_range still operates
exactly the same as it did.. its just slightly different under the covers.
range-ops has been returned to working in multi-range mode again now
that its compatible with value_range. Any consumer working with ranges
can switch to multi-range by switching to the multi-range API.
This code is currently going through a complete fedora build, and
assuming that passes, Aldy will be submitting it for trunk along with
various details and performance results in the coming week or so.
2) Ranger - Mid August
The on-demand ranger has been substantially simplified, with well
defined components contained in just a few source files. It is queued
up for trunk submission after the multi-range code goes in..
Initially, we plan to enable it for a few client passes which we will
describe at submission time (mostly the same passes as last years
presentation discussed) , along with a VRP pass which will run
immediately before EVRP called RVRP. It uses the same dom-walking
infrastructure that EVRP uses, but it still has a lack of relational
processing (to be addressed next)
At submission time I'll provide the details, as well as performance and
shortcomings once it has also passed thru a fedora build cycle. This
will also include the test suite adjustment strategy.
3) Equivalency/Relational Processing - Mid September(?)
Finally, the relation code will come, probably in mid September. The
proof of concept oracle prototype looked good, so I'm re-working parts
of it for performance in production code.
Once the relation code is in place, we will work on whatever remaining
differences there are between EVRP and the new RVRP pass.
- with RVRP running immediately before EVRP, we can identify anything
EVRP finds of significance that is missed.
- We can also run RVRP immediately after EVRP and identify things
RVRP gets which EVRP does not.
-------------
We know we get immediate benefit from multiple passes when they are
switched to ranger, and we'd like to get that enabled ASAP allowing the
code to be rigorously exercised during the rest of stage 1.
The RVRP pass will be a work in progress, and it is 100% self contained
in one file, simply operating as a ranger client just like the other
passes. If we reach the end of stage 1, and for whatever unforeseen
reason RVRP is not performing satisfactorily enough to replace EVRP, we
simply turn it off. If it is operating well enough, then we turn of
EVRP. We can decide towards the end fo the stage.
Thats a quick synopsis of the current ranger work. Over the next 2
months we hope to get all of the components into trunk and available for
general use.
Andrew & Aldy
