I'm pleased to announce updated versions of SourceGraph [1] (my graph-theoretic static analysis tool for Haskell) and Graphalyze [2] (a library for graph-theoretic analysis of relationships in discrete data). [1]: http://hackage.haskell.org/package/SourceGraph [2]: http://hackage.haskell.org/package/Graphalyze This version of SourceGraph now (should) only consider executables listed in .cabal files as being buildable, and both packages have been updated to use the latest versions of fgl (as well as following my own advice in putting an upper bound on the version of fgl being used...), graphviz and haskell-src-exts (SourceGraph only). Please note that SourceGraph-0.6.1.0 was a version I forgot to upload (and just realised this when I wondered why it wasn't appearing on Hackage...). The big change that should be apparent with this version of SourceGraph is that thanks to the changes I just made to the newly-uploaded fgl-5.4.2.3, multiple edges are finally being handled/visualised properly; for example see the nice thick lines in http://code.haskell.org/~ivanm/Sample_SourceGraph/SourceGraph/graphs/codeCor... (which represents among other things 32 recursive calls within getExp and 7 calls from getExp to maybeEnt). I forgot to put this in the TODOs, but here are my future plans for these packages. They're rather ambitious and I have no idea when I'll get around to them, but for all intents the only work I'm going to do on them until I do these splitting up goals is bug-fixes, etc. Graphalyze ---------- Graphalyze is going to fade away: I'm going to integrate its data -> graph conversion utilities into either my new graph library I'm going to work on during AusHack or into the successor for fgl Thomas Bereknyei and are working on (whatever we'll end up calling it), the Data.Graph.Analysis.Algorithms modules into graph-algorithms and fgl-algorithms packages and the reporting stuff into its own reporting library with different backends (pandoc, blaze, etc.). SourceGraph ----------- I want to split out and formalise the whole call-graph definitions and concepts into its own library and have sub-libraries for different languages to be able to have their own code -> call-graph conversions (so it can also be used for language-c, language-python, etc.). SourceGraph itself would then be more flexible in terms of what languages it can deal with (so it might even be possible to integrate C source files in a Haskell package into the call graph!). -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com