[Aptitude-devel] Resolver status.

[Daniel Burrows]

  I've been working on the resolver today, and here's what's left on my
working TODO.  Basically, I'm at the point where the problems are
getting smaller and more concrete; unless something ambushes me, I
expect that it should be fairly clear sailing from here to working code.

  Once all this is done, I can start tracking down the hordes of bugs
I've probably introduced, and once that's done I can see whether the
speed actually improved and how much I've increased the memory
footprint.


* After creating a step, add references to it in the global choice->step
  reverse mapping.

* When adding a promotion, set its validity condition (the promotion_set
  already arranges for it to be zapped when it becomes invalid).

* Maybe add a generalized way of attaching side effects to expressions?
  It seems like there are lots of places where we just want to
  instrument an expression, but leave the original expression around for
  use in building up larger expressions.  It would be nice if we could
  have the instrumenting be a member variable (i.e., not add an extra
  pointer indirection the way promotion_set does).

* For the side-effecting expressions that keep the state up to date, add
  a failsafe flag that ensures that they don't fire after we're done
  with them.
 
Also: currently the validity conditions are also the
  side-effecters.  Maybe separate them so we don't hold side effects
  around longer than we should?

* Those side-effecting expressions need to *make* things deferred, not
  just cancel deferrals.  We have no other mechanism for deferring
  solvers, and it would be unnecessarily redundant to introduce a second
  one.

* Since I seem to be going in the direction of defining step tiers
  purely in terms of solver tiers, steps shouldn't have their own tier
  validity constraints.  It's redundant (the individual solvers have the
  same effect).

* Remove steps from the global index when they've already been processed
  (had successors generated or were returned as a solution), so we don't
  bother updating their tier when new promotions are added.

* Write the top-level driver.

* Remove the old resolver code.

* Make it all compile.

* Write a test that verifies that dep-scoped choices are handled
  correctly in the promotion set?  (although I'm not sure those are
  needed any more)

* Write a test case for the choice-indexed set.

* Make handling tier changes more incremental?  e.g., store dep solvers
  according to their tier, maybe also maintain a list of deps sorted by
  tier?


  Daniel