With a proper algorithm to get correct asymptotic
behavior. The overhead of this method becomes
noticeable (though not terribly large) with a lot
of modules: mainly due to dependency sorting.
Also take a look at times for
May be more than I thought before; OptIt says that this line
Object elt2 = it2.next ();
is a hot spot.
committed * Up-To-Date 1.11 core/manifest.mf
committed * Up-To-Date 1.11
committed * Up-To-Date 1.64
committed * Up-To-Date 1.49
committed * Up-To-Date 1.17
committed * Up-To-Date 1.25
committed * Up-To-Date 1.90 openide/openide-spec-vers.properties
committed * Up-To-Date 1.121
committed * Up-To-Date 1.42
committed * Up-To-Date 1.60
committed * Up-To-Date 1.9
committed * Up-To-Date 1.112
added * Up-To-Date 1.1
In topological_sort_27286 branch (branch point is BLD200301070100)
there is a bit improved version of Utilities.topologicalSort that does
cycle detection and removes the necessity for topologicalSortError
method. On the other hand it introduces new exception that is thrown
in case a cycle is detected.
Reopened to let Jesse evaluate the new version and decide whether it
is better than the original.
Does the silence means that the branch should be integrated? Ok, I'll
do that tomorrow.
Created attachment 8487 [details]
Description of the algorithm to detect "strongly connected components" in the graph (czech)
Sorry, I saw your work but did not get a chance to pay more attention.
I guess it is good - briefly looked at the branch. Did not try to
understand all of TopologicalSortException in detail, but will assume
it is right - tests look good.
Missing @since on TSE.
Also need to update all core + openide clients (incl. FolderList.main
which still uses old partialSort due to richer error reporting - can
now be replaced).
Thanks for comments, I'll integrate it.
new revision: 1.95
new revision: 1.127;
new revision: 1.63
new revision: 1.2
new revision: 1.119;
cvs diff: TopologicalSortException.java is a new entry, no
new revision: 1.5
new revision: 1.68
new revision: 1.53