Structure the HTML summary hierarchically

[fingolfin]

Right now, we get a table with lines like these:

/Users/alexk/GITREPS/gap-fork/grp/basic.gd  50  69/137
/Users/alexk/GITREPS/gap-fork/grp/basicfp.gi    25  25/100
...
/Users/alexk/GITREPS/gap-fork/lib/zmodnze.gi    0   0/106
/Users/alexk/GITREPS/gap-fork/pkg/4ti2Interface/PackageInfo.g   0   0/1
/Users/alexk/GITREPS/gap-fork/pkg/AutoDoc/PackageInfo.g 0   0/1
...
/Users/alexk/GITREPS/gap-fork/prim/irredsol.gi  0   0/258
/Users/alexk/GITREPS/gap-fork/prim/primitiv.gi  29  177/599
/Users/alexk/GITREPS/gap-fork/small/id10/idgrp10.g  0   0/86
/Users/alexk/GITREPS/gap-fork/small/id2/idgrp2.g    52  113/216

To make navigation easier, it would be nice to hide the commen prefix /Users/alexk/GITREPS/gap-fork/. Moreover, the file hierarchy could be reflected visually, in the simplest case by using some kind of indention. A fancier way to display it could be an outliner resp. a tree view (you know, something like https://github.com/jonmiles/bootstrap-treeview). Then one could also use that to show aggregated data per subdirectory. E.g.:

/Users/alexk/GITREPS/gap-fork/      TOTAL VALUES DISPLAY HERE
   grp
       basic.gd
       basic.gi
      ...
   pkg
     4ti2Interface
   small
      ...

[ChrisJefferson]

This seems like a sensible idea, but the treeview might be beyond my html skills (at least right now).

If someone edited an output page of profilining by hand to look like how they wanted (make sure there is a nested directory somewhere, so 2-level branching works), then I'd be happy to translate that into code if it looked good (of course, direct patches are welcome too).

[fingolfin]

Hmm, it is not completely clear to me how the hierarchy would interact with sorting. One option is that sorting preserves the hierarchy; then everything in grp is sorted separately from everything in pkg.
Another option is to do something akin to what happens right now: Sort everything, ignoring hierarchy.

Which do we prefer, and why? To me, it would be fine to preserve the hierarchy; I work "per directory" in my brain anyway. But perhaps others would prefer the the current behavior, e.g. to be easily able to count all files with coverage less than 5% and stuff like that...

Hrm.

[ChrisJefferson]

My main use of sorting is just to find the files that were 'hot', when profiling. Doing per-directory sorting would still make it easy to drill down and find the hot files (in fact, perhaps when profiling, sorting by CPU time would be a better default sort than filename).

[olexandr-konovalov]

I would like to have directories at the top level, and then be able to sort within each directory by filename, coverage % and number of lines.

Current behaviour allows me to sort and easily see files with low coverage, but their list is polluted with files from packages, including even PackageInfo.g files.

Maybe an option to specify directories to include/exclude in the report as a workaround?

[ChrisJefferson]

There is already a simple way of filtering which files are displayed, you can pass an argument to OutputAnnotated.. which is a directory, and only files in that directory will be outputted (the directory is just treated as a filename prefix). A more advanced filtering would be easy to do.

[olexandr-konovalov]

I'd like to have more advanced, like list of directories to include or maybe exclude. One directory is not enough since we may want lib, grp, small etc.

[fingolfin]

I think this should be discussed in separate issues, though, else it'll be forgotten / lost.

[fingolfin]

Getting a hierarchical view with HTML + CSS is easy. It is even possible to use CSS (no JavaScript) to let the user hide/show the "contents" of a directory with a mouse click.

The hardest part of this seems to be to adapt the table sorting code to respect the grouping. But of course even that shouldn't be that hard.

My current idea is to do this:

1. Group the data to look roughly like this: http://dev.quendi.de/coverage-total-mod.html
2. Generate "group ids" which change whenever the depth changes. In the demo html I linke above, the first line would be group id 1, the second one with "grp/" would be group id 2, then all the files in it would have group id 3, then the line with "lib/" group id 4 and so on. The group id would be stored as a class attribute (probably on the row)
3. adapt the sorting code to honor the group id.

I can work on tweaknig the sorting code, but I don't feel comfortable messing too much with the code in profiling which generates the HTML code, so perhaps Chris wants to work on that? You may want to first merge PR #23, which supplies the colors and some other tweaks.