| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Closes: #651748
|
|
Hopefully this will eliminate some of the random crashes
on exit that people were seeing.
|
|
There are various problems with log4cxx, especially that it seems to be
unreliable and leads to random crashes. It might be a good idea to
eventually move to a different framework or roll our own. Decreasing
the number of explicit dependencies on log4cxx is a good way to do
that.
|
|
This was part of the initial design of the resolver, but it
turned out to be unnecessary in practice, and the problem it
tried to solve is actually quite difficult, so I never finished
the implementation.
|
|
underestimated because the "maximum" cost isn't actually maximal.
The algorithm that was at fault started with the highest possible cost
and incrementally lower-bounded it with the costs in the solver set,
to compute the lower-bound of the whole solver set.
That was the idea, anyway. It probably worked right when tiers had
exactly two elements and there was a sensibly-defined highest tier.
But now that means we start with
(MAX, 0, 0, ...)
and then lower-bound with, say,
(10, 1, 5, 4)
to get
(10, 0, 0, ...)
and, well, you see how that goes. The fix is a bit of a hack but will
do what I need here (producing a conflict if there are no solvers and
the lower-bound of all the solvers' costs otherwise).
|
|
solution deferred or discarded into helper functions.
The discard helper function existed already but wasn't being used
consistently.
In addition to making the code cleaner and more readable, this will
make it easier to enforce a "ceiling" on solution costs, discarding
solutions that go over the ceiling in one or more components.
|
|
The only remaining references to tiers are in backwards-compatibility
code; the "safety" cost component is composed of several "tiers" whose
values can be configured.
|
|
is based on "cost" instead.
|
|
Although the concept of a "tier" is useful (to distinguish changes
in the tier from the things being changed), the actual data type isn't
needed. We can just store an operation that computes the tier of a
step given a minimal tier.
Throwing out tier objects yields several benefits. It makes the code
somewhat simpler by reducing the number of complex object types
floating around. It will make it easier to clean up the nomenclature
by talking about costs instead of tiers. And it will make it easier
to impose a "cost ceiling", just by virtue of making the cost-tracking
subsystem simpler.
|
|
Not even compiled because I don't seem to have a full development
environment installed on this machine yet (oops).
|
|
cause a step to be discarded.
This is another part of the groundwork for more configurable solution
search criteria: the client of the resolver will be able to say that
steps in which particular tier components exceed a given level should
be discarded; consolidating all the ad-hoc tests into a single routine
is the first step to implementing that feature.
|
|
tier operations.
This didn't actually make it faster, but I think it does make things a bit clearer.
|
|
this is the first step towards being able to minimize the number of changes meeting a criterion.
The biggest change for this is that the new cost objects (tier operations)
are not totally ordered, so various places that used to take a maximum
now take a least-upper-bound instead; similarly for minimum and
greatest-lower-bound. Still to do: find a sound way to allow the resolver
to add together costs instead of upper-bounding them: "this change
will force us to remove 10 packages".
The new code seems to be a little too slow -- probably it lost some
optimizations by accident. It does seem to be correct, though.
|
|
promotions in a step when we come back to it.
|
|
Mostly this just removes typedefs from the universe-specific tier types
and adds #includes for tier.h. The tier limits object was rewritten
somewhat more, to account for the new terminology ("levels") and to make
the integers explciitly represent structural levels, not tiers.
|
|
the current run of aptitude started. (Closes: #556042)
This is done by filtering them out of the initial set of dependencies
that the root node is initialized with.
NOTE: I still need to convince myself that we can't somehow end up
reactivating a dependency that should have been skipped. However,
we might really need to legitimately activate it...something to think
over, anyway. (I particularly suspect that the weird behavior of
Conflicts might be a problem)
|
|
|
|
done with it.
If the tier of the solver set is not high enough for us to extract any
useful information, there's no point in calculating the reasons for
that tier.
|
|
|
|
7c43f786ebba
|
|
|
|
8ff97afb1605
|
|
13ac768ed385
|
|
|
|
exact matches (including matches to the dependency).
Necessary because deferrals due to violating an approval constraint
only apply when a version is chosen to solve the same dependency.
This is just one other way that approval constraints are wonky. I'm
thinking that it might be good on multiple levels to throw them out:
they're a bit counterintuitive, they tend to produce unstable results
(the set of legal successors can vary depending on which dependency
is chosen as the next one to resolve, for instance), and because they
mean that deferrals happen on a per-dependency basis, they need a lot
of careful code and a lot of extra memory allocation to get right.
I'm not sure what would replace them, though.
|
|
It wasn't taking into account the actions themselves, or promotions
that only included them.
This fixes the big glaring problem with the new code, namely that it
was spinning off indefinitely (because depending on the order in which
some normally idempotent things were applied, they would trip this bug
and miss the fact that a line of reasoning was supposed to be chopped
off). There's still one odd problem, where I get different results
each time I run it, probably because of some other order dependency.
|
|
|
|
pointers.
This should make log files a lot more reproducible.
|
|
dependencies.
|
|
|
|
Necessary for the sake of correctness: otherwise, set_step_tier doesn't
know whether a step is "closed" and hence whether it should be put back
on the pending list.
An alternative would be to have an explicit flag on a step that gets
set when it's "closed"; then we could throw deferred steps out of the
pending tier entirely, which would be nice and would save a little
time.
|
|
Two bugs here: it wasn't being set back to the minimum tier, and it was
being set directly rather than via set_step_tier().
|
|
viable candidate (below the deferral tier), clear the "finished" flag.
This avoids a problem where if a deferral was retracted after the
resolver had run out of solutions, we wouldn't find any more answers.
|
|
call recompute_step_tier() on that step.
Necessary since the step might still be waiting to be examined.
|
|
|
|
There is a cost in memory to this change. But the win in terms of
speed is *huge*. How huge? Well, when compiled without optimization,
the new code is now 4-5 times faster than the previous code *with*
optimization and something like 20-30 times faster than 0.5.2.
|
|
shouldn't pass a temporary there, ever.
Turned up with valgrind.
|
|
This is another step towards switching to a more efficient representation.
|
|
In addition to eliminating that code, this change should make it easier
to change the representation of dep_solvers (since I won't have to
figure out how to memory-manage whatever-it-is).
|
|
a solver.
If a solver's tier is below the step's tier, the sanity-check was
claiming that the global promotion which had raised the step's tier
should also apply to the solver, even if it didn't contain that solver.
Fixed by restricting that test to (correctly) only consider promotions
containing the solver in question.
|
|
child are picked up by the others.
|
|
Some dependencies legitimately list a solver twice; we already should
handle this gracefully, and it isn't actually a sign of brokenness
elsewhere.
|
|
These are expensive and compiled out by default, but useful for
empirically verifying that the resolver isn't going wrong. Right
now it is.
|
|
Previously some of these were being thrown away, because the code was
keeping promotions that were strictly less than the maximum tier (oops).
|
|
|
|
Choices that install a different version of the source of a dependency
should cause solvers of that dependency to be deferred.
|
|
Hopefully this is a bit more scalable.
|
|
the queue.
This was causing steps to be processed multiple times.
|
|
|
|
Makes it easier to write a much simpler renderer.
|
