| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
one of the prropagations.
|
|
information from it to *all* of its parents.
|
|
One of the log messages I chose conflicts with the "processing" line
emitted at the start of a search step, so I had to tweak the regular
expression the log parser uses to recognize search steps.
|
|
same install as long as it was done for the same dependency, and use them to inject promotions related to approval user constraints.
Approvals are violated by search steps that choose a different solution
to a dependency than the approved one. So to represent these in the
condition of a promotion, we have to be able to match installing a
particular version *but only if the install was for a particular dep*.
In other words, install_version choices now have four levels of
specificity:
(no dep) -> (unscoped) -> (dep-scoped) -> (from-dep-source)
Choices with no dep "contain" any other choice that installs the same
version, and so do choices that are unscoped (but have a dep). Choices
that are dep-scoped "contain" choices that have the same dep (so no-dep
choices are out, but some unscoped choices can match). Choices in the
from-dep-source category "contain" choices that have the same dep and
that are also from-dep-source.
This commit adds the code necessary to represent these extra types
of choices, to manipulate them in the resolver, and to parse them in
the log analyzer. It also uses these new abilities to generate
promotions to the "defer" tier when successors violate a user
constraint.
|
|
lines.
This should make it a bit clearer what's happening in complicated
search trees.
|
|
|
|
|
|
solutions are marked in the output graph.
|
|
them if there weren't any normal propagations.
|
|
|
|
This led to an infinite loop if there were any backpropagations (since
the step parameter closes a cycle).
|
|
|
|
format.
|
|
|
|
|
|
|
|
|
|
clouds.
|
|
Currently this is turned on whenever promotions are being shown. It's
not 100% clear to me that it actually works.
|
|
This is in preparation for backpropagating conflict/promotion
information, and in fact much of the code for that is already
implemented in this commit (just not activated yet). I decided to
use integer references into a deque to keep things a little more
compact instead of having a huge number of structures on the heap: the
resolver is already memory-hungry enough, no need to make things even
worse.
|
|
|
|
already-seen promotions.
This didn't actually make anything faster on my test cases -- maybe
this isn't actually the bottleneck? Anyway, this should make the
code perform better in the face of large numbers of promotions.
|
|
of a search trace.
|
|
|
|
only attach new promotions to output steps.
To do this, I had to split the runs during the parse rather than in a
post-processing step; otherwise the seen-promotions set would have
carried over. (I could have just reset a few state variables, but this
is cleaner anyway)
Ideally I would actually track whether a promotion was redundant and
only show non-redundant ones, but that takes a lot more code.
|
|
|
|
comparisons are to be performed.
|
|
and making them bold.
This shows up much better on black&white printers, and it's what I
wanted to do when it was clear that bolding was too little; I hadn't
figured out how to do it until now.
|
|
Sometimes several edges are forced before the resolver outputs a new
Processing line; they were all being linked as successors to the
starting solution, when in fact they represent a *sequence* of steps.
|
|
display dep information in the tree view.
|
|
|
|
These can, by design, force the search down in score or even to a
higher tier, so some apparent anomalies make more sense when the
forced steps are indicated. Currently they're bolded and (because
that's not very visible) also displayed in green.
|
|
render .dot files, and also overhaul the Dot interface to allow a more streamlined renderer.
The changes to Dot alter how attributes are defined: attribute
operations are now represented explicitly, and have their own
mini-language with functions to create attributes and operators to
apply them to objects or combine them. The main motivation for
this is the new combinator `thenDo`, which takes a Boolean value
and an operation, returning a new operation that does nothing if
the Boolean is "false" and is equivalent to the operation is the
Boolean is "true".
|
|
Should save time hunting around to figure out which file is which in
the future.
|
|
|
|
|
|
|
|
the format of images that are inserted into the dot graph).
|
|
|
|
|
|
the convenience operators.
|
|
|
|
|
|
|
|
to select the steps to display.
The whole file is always loaded, so we can display stats about how many
nodes we aren't displaying; this is just a UI tweak, to filter excessive
information, and not an optimization.
TODO: add options to root the tree at a given node, and to actually
drop / skip nodes entirely.
|
|
to generate Dot renderings of the resolution process.
|
|
plain integers.
This allows us to classify solutions in a more fine-grained way. In
particular, it provides a not-horrible way to integrate apt pin
priorities into the resolver's decisions, by making them a subordinate
level of ranking to the main tiering system.
The current plan is that the first level of tiering is the only one the
user sees (by default) and the only one that can be directly configured.
The subordinate levels are filled in automatically (pin priorities are
all I have in mind now, but I don't discount the possibility of
introducing more levels in the future).
|
|
|
|
|
|
from the log file.
This drastically cuts down on the memory usage of the viewer, and
provides a nice speed boost too. Loading larger log files will be practical now.
It would be nice if we could use a hashtable for the strings, but how
to do that? Probably too much work for a little tool like this.
|
