On Sunday, 29 March 2015 at 15:40:56 UTC, Andrei Alexandrescu wrote:
> One other informative graph that should be much easier to generate is the direct imports graph (no transitivity).

I had a go at it, and I have something for that now. This graph should show what std.regex imports. I'm not sure if anything is missing from the module info. I imagine there's a template which might need insantiating first in order to add in import line, and I'm not sure if the ModuleInfo will include all the scoped imports or not. I assume it does.

https://i.imgur.com/r1TZVKO.png

I added an extra method named 'addModuleWithDirectDepdencies' for adding a module to the set of modules and just its direct dependencies, not the transitive dependencies. Then I added an extra set to the structure for tracking which modules are supposed to be leaf nodes in the graph, and made the DOT functions check for that.

I had to add the leaf checking, as the dependencies could be importing each other, and the structure was only storing nodes, not edges. I should maybe make the structures store just a directed graph, but whatever.

On Sunday, 29 March 2015 at 16:18:40 UTC, w0rp wrote:
> I had to add the leaf checking, as the dependencies could be importing each other, and the structure was only storing nodes, not edges. I should maybe make the structures store just a directed graph, but whatever.

Thinking about it a little more, I should probably change the API for classes and modules so the functions which write the DOT files take just a directed graph, and provide functions for building the directed graphs. Then you can play with the directed graphs as much as you want. I have a directed graph type already in my container library which would be suitable.

On 3/29/15 9:18 AM, w0rp wrote:
> On Sunday, 29 March 2015 at 15:40:56 UTC, Andrei Alexandrescu wrote:
>> One other informative graph that should be much easier to generate is
>> the direct imports graph (no transitivity).
>
> I had a go at it, and I have something for that now. This graph should
> show what std.regex imports. I'm not sure if anything is missing from
> the module info. I imagine there's a template which might need
> insantiating first in order to add in import line, and I'm not sure if
> the ModuleInfo will include all the scoped imports or not. I assume it
> does.
>
> https://i.imgur.com/r1TZVKO.png
>
> I added an extra method named 'addModuleWithDirectDepdencies' for adding
> a module to the set of modules and just its direct dependencies, not the
> transitive dependencies. Then I added an extra set to the structure for
> tracking which modules are supposed to be leaf nodes in the graph, and
> made the DOT functions check for that.
>
> I had to add the leaf checking, as the dependencies could be importing
> each other, and the structure was only storing nodes, not edges. I
> should maybe make the structures store just a directed graph, but whatever.

Awesome. Two more ideas:

* imports in unittest mode vs. not (will show how good we are at making imports local)

* direct imports but followed transitively, e.g. the graph for std.regex' imports would show the imports of the modules imported etc.


Andrei

On Sun, Mar 29, 2015 at 03:44:02PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> * direct imports but followed transitively, e.g. the graph for std.regex' imports would show the imports of the modules imported etc.
[...]

That would be interesting to see! It would be a great help in reducing unnecessary dependencies between Phobos modules.


T

-- 
They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill

I have just updated my reposistory so instead of using a ClassHierarchyInfo type for class diagrams and a ModuleDependencyInfo type for module diagrams, now digraph types are used, coming from my container library. I had to update my container library a little to get it to work, as I had some problems with const and immutable types, but I needed to fix those issues anyway. So now class diagrams use Digraph!(const(ClassInfo)) and module diagrams use Digraph!(const(ModuleInfo*)).

I have made some implementation changes for my container library, but the API for the graphs should be the same, and it is documented here.

https://w0rp.com/project/dstruct/dstruct/graph/

So now you can play around with the graphs directly if you want, so you can say manually that module foo imports bar, when the helper functions can't figure it out. I'm not exactly sure what kind of graph you were after Andrei, as I have one thing for direct imports and another for everything transitively, but you can probably make whatever it is happen in a few ways. The actual method for it is pretty short, so I'll paste the whole thing here. (Adding an edge twice does effectively nothing, as the edges aren't weighted here.)

void addModuleWithDependencies(Dependencies strategy = Dependencies.all)
(ref ModuleGraph graph, const(ModuleInfo*) mod) {
    graph.addVertex(mod);

    // Add the imported modules.
    foreach(importedModule; mod.importedModules) {
        static if (strategy == Dependencies.all) {
            if (!graph.hasEdge(mod, importedModule)) {
                graph.addEdge(mod, importedModule);

                // Add recursive dependencies.
                graph.addModuleWithDependencies(importedModule);
            }
        } else {
            graph.addEdge(mod, importedModule);
        }
    }
}

ModuleGraph is just an alias for the Digraph type mentioned before. I think my only pain point is that there's no way, at least that I know of, to just get ModuleInfo for a given module. I have to use a foreach over all modules until I find the module I'm after. It works, though.