| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
|
|
Hopefully this will eliminate some of the random crashes
on exit that people were seeing.
|
|
Using <> means the source directory isn't searched, which causes
trouble with the scons build, which doesn't put the source directory
into the include path. Most of aptitude follows this convention, but
these two files have trouble with it.
|
|
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 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.
|
|
This is preparation for a future where it will be used more generally
than just in the resolver.
|
|
the upgrade fixing resolver tab.
Instead, we just ensure that the first solution is generated. The main
symptom of this bug was that if you ran out of solutions, then loosened
a constraint so that new solutions were available, a new solution would
be produced immediately.
|
|
working on before acting on any of them.
This fixes crashes caused by the fact that acting on a choice could
cause the tree store to be torn down and rebuilt. When we were
operating on iterators of the store, this meant that the next item
we operated on would access freed memory and crash.
|
|
Now that the resolver continuations run in the foreground thread, this
was causing irreconcilable deadlocks (since the foreground thread would
be waiting for someone to post the return result, which could only
happen when the foreground thread finished running the continuation and
polled for new posted thunks).
|
|
|
|
|
|
This eliminates a whole class of bugs caused by calling into resolver
routines from the background thread. The specific one I ran into here
was that the resolver thread is shut down by join()ing it while its
global lock is held, and it's hard to avoid that -- but most resolver
routines want to take the global lock, so calling them from the
background thread risks a deadlock.
There is a loophole here: you can safely use the resolver manager in
the background thread if you know that no-one else is accessing it.
The command line frontend uses this to simplify its code.
|
|
|
|
I swear I made some of these changes in the last commit; I halfway
suspect that "hg record" glitched.
|
|
std::wstring.
This way we don't have to do several useless conversions to and from
UTF-8.
|
|
I feel like this makes things a little cluttered, but the short
descriptions are also very useful.
|
|
attached to a resolver tab.
This was causing icons and colors of items in a solution to fail to
update when the state of the items was changed (since the callbacks
that trigger this were connected to the global resolver, not the one
specific to the tab).
|
|
|
|
signals to its manager.
|
|
|
|
package. (Closes: #525898)
|
|
selection list and work on that.
This fixes the warnings that were getting spewed about how we were
modifying the list during iteration.
|
|
|
|
Before, the resolver would be automatically started sometimes even
though the user hadn't pushed the "find next solution" button. This
is now fixed: solutions won't be computed until the user is ready for
them (that's important so that their rejections/approvals are
reflected in any solution that gets generated).
|
|
boldface.
|
|
|
|
for action preference icons.
|
|
markup is used more consistent.
I'm not sure the current markup is what we want, but at least it's the
same everywhere and there are now fewer places to change if I decide to
rip it out.
|
|
Eliminated the previous/next holdover from the curses interface: it
made sense there because of the limited real estate and input
mechanisms, but in the GTK+ frontend it's much better to have a list
of the already-generated solutions and a button to make a new solution.
There are still a bunch of loose ends. The display of the current
solution doesn't adapt well to being narrow -- I think the "action"
column should be nuked and merged with "name", but I'm not sure what
else to do there. Display of actions is somewhat inconsistent. It
would be nice to unify them, but we should do that with an eye to the
fact that differing renders are also useful. At the very least, use
of text styles should be straightened out: I'm not sure that showing
version numbers in a larger font works, but we should either do it
everywhere or nowhere. It's scattershoot now partly because I wanted
to throw lots of stuff at the wall and see what stuck. I also would
not bet much money on the behavior being absolutely correct.
|
|
fact that if all the dependencies are fixed, the resolver tab will go away on its own.
This fixes a double-free bug that was crashing the program.
|
|
modify them.
Arguably we should have better UI here, but at least the capability is
visible now.
|
|
Actually, I bet they could be static (doesn't really matter, though).
|
|
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.
|
|
|
|
choice_sets, rather than manually storing the different types of choices in the solution object.
This has two beneficial effects. First, it should make it a bit easier
to add a new choice type, although many parts of the program will still
have to be touched. Perhaps more importantly, this provides a cleaner
conceptual model of what the resolver does: it finds "choice points"
(that is to say, dependencies that need to be solved) and makes choices
at them.
This commit sneaks in a few optimizations that I came across in the
process of rewiring all the resolver logic. The big one is that testing
whether a solution violates a user constraint now requires steps
proportional to the size of the solution, not to the number of user
constraints. (each step is logarithmic in the number of constraints,
but that's still a big improvement)
|
|
preview tab if it was an upgrade resolver.
|
|
be upgraded.
This is done by creating a special resolver tab, in which the initial
state consists of all the upgrades that the safe upgrader could figure
out. The user can then work towards a resolution to these dependencies.
If the cache is closed while this resolver tab is open, it will be
disabled until a new safe upgrade is calculated, and then filled in with
that upgrade's information.
This commit also tweaks the "number to install" message to also show
how many upgrades are available. But it's still not really
satisfactory. I might just go for "N upgrades out of M available
upgrades" even at the cost of nested ngettext() calls (the horror!)
|
|
Because "hg record" can't split diff hunks, some places that need
logging are bound up in another pending commit, unfortunately.
|
|
|
|
solution, and showing an explanation of the whole solution.
The button text and tooltips still need some work IMO.
|
|
|
|
solution by type into its own method.
|
|
|
|
Since copying a slot is not a thread-safe operation, this commit
introduces a "safe_slot" object that hides the slot behind a pointer
and uses thread-safe reference counting to manage it. This should
make it OK to pass slots between threads as long as the slot is only
actually invoked in the thread that "owns" it. (or the slot is safe
to pass around anyway)
|
|
|
|
http://dev.graffit.net/aptitude/trac/ticket/5 .
|
|
to run in the background.
The new code is based on the code from the curses UI, but adapted to
the land of GTK+. This was accomplished with two main changes:
(a) Instead of trying to store a resolver state and solution in the
object and to use that to update, we update the display whenever
the state change signal fires. This means that we're always
up-to-date with the resolver state (eliminating the various cases
where the resolver and the view would get out of sync).
Also, we now always use the resolver state to figure out which
solution is current rather than retrieving the state twice. This
avoids a potential race condition that could have led to an
inconsistent state display.
(b) Run the resolver in the background the same way the curses UI
does, and use GTK-specific code to post the result to the main
thread.
|
|
appropriate.
|
|
My idea earlier was that it might somehow be "safer" to have the signal
emitted manually by the caller. In practice, though, this just led to
a situation where every caller had the same boilerplate to invoke a
callback. So now I emit the signal directly in the backend; much
cleaner.
|
|
|
