| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
|
|
is above another tier without actually computing an intermediate value.
The tier operation code was the only thing that looked at all like a new
cost center in a profiling run (which makes sense since that's really
all that changed in the build that's slower). This might help a little;
the "take an upper bound and compare" trick is played a lot at the
moment.
|
|
It looks at a quick glance like I was wrong about the efficiency issues;
it may have just been due to comparing a non-optimized build to an
optimized build.
|
|
user level with a negative index in a tier operation.
|
|
|
|
|
|
|
|
modifies a negative index in the user tiers array.
|
|
The rule in this system is that you can increase tier levels either
by adding positive numbers to them or by lower-bounding them. Any given
slot in the tier has to be managed using only one of these operations,
but different slots can be managed using different operations. This
allows support for the new "add to tier" operation, while maintaining
the ability to do the old "increase to level" operation (both for
backwards-compatibility and for supporting pin priorities).
Currently the unit tests fail; this needs to be fixed.
|
|
|
|
objects.
|
|
|
|
|
|
The comment at the top of tier_operation cheerily asserted that these
two operations formed a specific partial order. They don't. Each of
them *individually* does, but there is no natural ordering between
them: for instance, "increase to 100" takes 5 to 100 and 105 to 105;
"add 5" takes 5 to 10 and 105 to 110. Worse, they aren't closed under
composition, since order matters and it isn't stored in an operation
(and can't be without making operations contain a whole chain of
compositions).
The effect I was trying to get with increase-tier can be achieved,
albeit not in a backwards-compatible way, by adding levelwise upper
bounds to tier objects at a higher level (i.e., in the resolver).
The point here is to be able to have a tier that, for instance, is
0 if there are no removed packages and 1 if there are *any* removed
packages (i.e., it doesn't distinguish between different numbers of
removals in the same way that the current removal tier doesn't).
|
|
|
|
|
|
This needs a unit test and an operator<<.
|
|
It's a bit awkward that it uses tiers to represent its components; on
the other hand, its components are *almost* exactly tiers. Something
to ponder.
|
