code call-graphs for warzone

[kage]

AFAIK DoxyGen does the same thing, but with additional call-graphs and documentation support... Or did I miss something about Gonzui & Co.?

ah damn. if i'd known doxygen does callgraphs and various other things with graphviz, i'd never bothered modding egypt.

[cybersphinx]

AFAIK DoxyGen does the same thing, but with additional call-graphs and documentation support... Or did I miss something about Gonzui & Co.?

It does? All I've every seen it used for was for documenting functions etc. with comments in the source. And from the examples I've found I miss the "show every place in the code where a function is used" that's in gonzui, and one of the essential features to navigate through the code (in contrast to documenting the code, what (I thought) doxygen does).

And generating the docs on every commit would be total overkill, as the code doesn't progress fast enough to justify such a load for the server. And several commits are just very small fixups which wouldn't change the structure at all.

Gonzui doesn't create documentation, it just indexes function calls etc. And a commit hook doesn't have to call gonzui-update directly, just set a flag for a cron job to run it (since SVN activity is quite irregular).

And in the end the tool, whatever it is, has to be used by those who do the actual coding...

I don't see a direct connection to coding and those that do it, except for doxygen needing its comments to be really useful. My intention was to have the code online and easily browseable, since that'll help make it more accessible. Personally, vim+cscope does the same for me, and I can easily run gonzui locally. But it might be useful for people to get to know the code and make it easier to contribute something.

And no, I'm not saying gonzui is the best and doxygen is crap, I just found gonzui easily does what I want, and doxygen doesn't. Perhaps doxygen can do everything I want as well as gonzui, but it isn't advertised well then. The focus for doxygen is just different, it generates static documentation, while gonzui indexes code and generates its results dynamically. Perhaps there is some other tool that's better than both and I just didn't find it yet...

[DevUrandom]

I am not fully sure, but I think DoxyGen supports generating 2 styles of callgraphs: Calling and Being-Called ((by) this function). It surely has some code-markup-with-links functionality.
Whatever you think is good, I would stile like to have a server generating the Doxy from SVN once a week.
What someone wants to setup in addition... I don't (yet) care.

[Rman Virgil]

...........

* As far as proprietary tools - Western Wares "CC-Rider" is pretty awesome... I'm using the fully functional demo (only time constrained) and it has quite an impressive feature set. But of course I am not gonna spring 5 Benjys for a licence as sweet as it is. Still interesting to see the full scope of what can be done to nav and doc the source - very inspireing, personally.

* To my pea-brain, "CC-Ryder" can do what both do, (Doxygen & Gonzui) and then some. 
.........

* Neglected to provide a link HERE

* IF i had a coders passion like I have for a handful of other artistic disciplines, (which I don't, but if i did), i'd be sorely tempted to drop 5 Benjamins on the Deluxe Edition of "CC-Rider" just to thorughly satisfy that passion in the most effective way available tool-wise..... that's how impressive the Free Demo has struck me. But that's just my readily acknowledged, irrelevant, PoV.... (I also have nothing against folks making a fair buck from the fruits of their labors. Fact is, one of the core arguments for OSS, code re-usability, has yet to pan-out in reality, truth be known - or is it taboo to utter that ?)

[cybersphinx]

Found another way to generate callgraphs: ncc plus codeviz. You can give it a starting function and the desired call depth, though there seem to be no tools to automate that. And Warzone's current main function is way too large to get a meaningful graph...

I played a bit with doxygen, it complements gonzui nicely. As far as setting up one or both of those, I could do that (with access to a suitable server).

Requirements (everything tested on the trunk, so space requirements are per branch):
gonzui:
- runs its own http-server with search engine
- first run checks out SVN, generating the index needs about one minute on my machine (2GHz),
- needs space for an SVN checkout and about 60 MB for its index
- needs ruby and SVN installed

doxygen:
- generates static pages
- first run needs about 30 minutes (with callgraphs), update about one minute
- generates 120 MB in 17000 files (needing 170 MB on my ext3 partition, in addition to the source itself, but it could use gonzui's copy)
- needs graphviz for callgraphs

one of the core arguments for OSS, code re-usability, has yet to pan-out in reality

Well, to reuse code it has to be written in a reusable way, but most (application) projects aren't focussed on that... But there's a whole category of reusable code, and quite successful I'd say: libraries.

And for a wider definition of "reusability", if you have a binary that's incompatible to your system (too old, 32bit instead of 64...), if it's closed source you cannot do anything (except wait for an emulator to become available and hardware to get fast enough for that emulated program to run at acceptable speed - dosbox, for example). An open source application can be adapted, given enough time/money (well, unless it's written in pure assembler or something).

[kage]

one of the core arguments for OSS, code re-usability, has yet to pan-out in reality

er... "libc".

aside from that, somewhere between 1/3 and 1/2 of the 757 shared libraries on my system are used by more than one program, with the benefits of shared memory if that library is used by multiple processes at once.

the reason you don't see foss developers using the kde codebase every time they want to design a mouse driver is because most of them are very pragmatic programmers (with the exception of the "desktop environment" people): if your code is sufficiently specialized enough for your problemspace, then you need not bother making it reusable, since if it were reusable, then it'd take five times as long for you to write the code, would probably be very slow, probably have a lot more bugs (most of which would be untestable in your application), and may have one person come along in 50 years to try to use your code for a radically different project. if your code is specialized, then it'll be much easier for people to come and tweak to create forks of your project (in a sense, "less is more").

in other words, foss developers generally won't make code reusable in the broadest sense unless they see the possibility of useful reuse: somewhat opposite of what many java developers are doing, such as creating a fully user-programmable image processing library that has been found to do many common tasks very slowly (45 minutes to iterate over an image, check each per-pixel instruction to execute, per color channel instructions, etc -- the same outcome could be achieved in 2 seconds for code specifically designed to complete that task).

edit: just reread sphinx' post (i was tired the first read through) -- in complete agreement. in most of the ways that matter to users, foss very successfully reuses code. a lot of the "best practices" and "maximum modularity" stuff you'll learn about in programming classes (at least high school and intro college classes in the united states) are effective in that they allow a corporation to hire you, have you write some code then have someone else continue the work with a very shallow learning curve, as well as the possibility of building a new program with "blocks" from a set of extremely distinct and unrelated programs, but the corporate types mostly care about what gets done, not how long it takes or how many gigabytes of ram you now have to add (they're pragmatists too: buying an extra 3 high-end servers is exceptionally cheaper than paying programmers to write efficient code each time they need a new utility).

[DevUrandom]

I think DoxyGen can also use dot _instead_ of GraphViz, but I am not entirely sure.
But whatever... I would love to get this onto this server... Kamaze?

Can't your Gonzui be setup to integrate into an Apache server?

[cybersphinx]

I think DoxyGen can also use dot _instead_ of GraphViz, but I am not entirely sure.

On Debian, the graphviz package contains /usr/bin/dot.

Can't your Gonzui be setup to integrate into an Apache server?

No, it runs its own http-server with search engine on a separate port. lxr uses apache, but it also needs mod_perl, a database (mysql or postgresql) and the corresponding perl interface library (and I have to find out how to set it up, the last time I tried I didn't succeed).

Edit: Example for lxr (Mozilla source).

As doxygen is static, it could also be generated locally and then just uploaded. With an intelligent tool like sitecopy or rsync, updates shouldn't be a problem, but uploading the initial 120MB would take hours for me...

[Rman Virgil]

..............................>

Kage and Cybersphinx:

* Essentially, I appreciate what you are both saying (edified by your PoVs and, as usual, inspired to go further in my journey of understanding - which is a big part of why I've been in the WZ mix since '99 - learning, life-long learning) and, for what it's worth, agree.

* While my quip was intended to express my position compactly it has the same downside as any compression (save for world class poetry) - it makes sacrifices.

* I don't want to high-jack this thread with a detailed explanation but I do want to respond more fully.

* My PoV on Code Reuseability  is covered beautifully by 2 of my code mentors:  Joel Spolsky and Matt Palmer

* I believe you will not be disappointed by looking 'em up - they've been successful pros for many years and they both write exceedingly well to boot - code & the English language.


Cybersphinx: Looks like a sweet marriage of apps - complementary functionalities (which is a big part of what impressed me about "CC-Rider"....and here you are able to do it without having to spend $500 + (US)... that is pretty dang kwel as well.)

[DevUrandom]

Hmm... I wonder what the "use dot" setting in DoxyGen is for, then... Or what it uses when it doesn't use dot.
But at least the DoxyGen part should be very easy to setup on this server... At least I can't imagine what problems could occur. Install SVN and DoxyGen and setup a cronjob to run them once a week... At least that's it from my naive point of view...

[kage]

graphviz contains a number of tools that will take dot language as input, and process it differently, either with intentionally different output (undirected vs directed graphs), or using different heuristics designed for special cases (e.g. the fdp utility is used to generate extremely complex undirected graphs without chewing up all your ram). my guess is that "use dot" might be in some way connected to this -- where you can substitute it with an arbitrary dot-language processor, but then, i haven't looked into the setting.

[DevUrandom]

Found some info:
http://www.stack.nl/~dimitri/doxygen/diagrams.html

Doxygen has built-in support to generate inheritance diagrams for C++ classes.

Doxygen can use the "dot" tool from graphviz 1.5 to generate more advanced diagrams and graphs.

So it seems as if GraphViz is not needed. (And I disliked the dot output. I found the built-in graphs visualy more appealing...)

[Rman Virgil]

Found some info:
http://www.stack.nl/~dimitri/doxygen/diagrams.html

So it seems as if GraphViz is not needed. (And I disliked the dot output. I found the built-in graphs visualy more appealing...)

* Not a 100% sure Dev, but you may still need to use dot if you wanna use a text editor.

l8r rv

[kage]

given that most of the diagrams i've seen have curved lines, and a few other dot-ish type features, it suggests that the built-in implementation is more than a quick hack (which would probably have straightlines, be limited to box-shaped nodes, etc). it's quite possible that doxygen was statically linked against the graphviz library, with default internal settings optimized for ultra-small graphs, and if not possible through graphviz configuration alone, a few small tweaks designed to prevent any possible overlap of edges as long as the graph always had few enough nodes and a strict "one parent" nature.