ANNOUNCE: graphviz-2008.9.20

The latest version of Matthew Sackman's Haskell bindings to Graphviz [1] are now available on Hackage [2]. The reason there's a new release only two weeks after the previous one is that I've made some extensions to it (hence why I'm writing the announcement) that Matthew has kindly included. Since Matthew doesn't recall writing an announcement for graphviz before, here is a brief synopsis of what it does. The Graphviz program is probably _the_ way of drawing graphs (note: this is graph-theory graphs, not function plotting). As it stands, there are currently at least four different Haskell bindings available for Graphviz that I've managed: * The inbuilt Graphviz module in FGL [3] * graphviz (which this announcement is for) * dotgen [4] * A really simple generator by Duncan Coutts [5] In addition to this, the following utilities on Hackage output graphs in Graphviz's .dot format (either using one of the above libraries or their own parser): * prof2dot : converts profiling information to .dot [custom, I think] [6] * flow2Dot : convert textual descriptions to .dot [also custom, I think] [7] * graphmod : draw the dependencies between Haskell modules [uses dotgen] [8] As it can be seen, there's a plethora of possible ways of creating .dot graphs in Haskell. What seperates the graphviz package from the others is: * It uses FGL graphs, rather than passing through lists of nodes and edges manually (of course, if you're not doing any other graph-related activity you might not want to use an FGL graph), whilst providing more control than the default FGL module. * A large list of attributes that can be used are available: http://hackage.haskell.org/packages/archive/graphviz/2008.9.20/doc/html/Data... * A "sane" interface that provides a large degree of customizability (don't specify the attributes manually for each node/edge/etc., just pass through a function that will create the attribute you want). * Limited parsing of .dot format (note that as yet it can't convert a parsed DotGraph into an FGL graph). * The graphToGraph function allows you to pass a graph through Graphviz and then extract out positional information and combine it with the original graph. There are some things things that graphviz can't do, such as drawing undirected graphs and clusters (which dotgen can)... at least until now. The changes that I have made provide the additional functionality to graphviz: * Differentiate between undirected and directed graphs. Whilst FGL represents undirected graphs with a directed graph by duplicating all edges (an undirected edge {1,2} is represented by the two edges (1,2) and (2,1)), you don't really want to draw a graph this way. Furthermore, many reports say that graphviz's "neato" command is better at drawing undirected graphs than the normal "dot" command is. Thus, graphviz will now draw only one edge out of every directed pair. To do so, however, requires that the edge labels are an instance of Ord: if this is a problem for you, please contact either Matthew or myself and we'll see what else we can do (this is required because it's assumed that if two edges (1,2) and (2,1) are meant to represent the undirected edge {1,2}, then their labels must be the same). * Add clustering support. Graphs can be drawn (but as yet not parsed) to provide nested clustering support to arbitrary depth. To do so, you need to provide a function (LNode a -> NodeCluster c a), where NodeCluster is the following recursive data type that indicates in which subcluster a node in the graph belongs: data NodeCluster c a = N (LNode a) | C c (NodeCluster c a) The c type represents the cluster label, and is the parameter by which cluster attributes are assigned. Note that c has to be an instance of Ord. Clusters are not parseable, because there's no clear way of how to convert a cluster to an FGL graph. The interface for graphviz remains unchanged, so you can safely upgrade to this version. Here is an example function of how the library can be used to draw an FGL graph to a (very plain) Graphviz graph (well, it will convert it to the DotGraph datatype, which when shown produces the .dot graph code): graphviz :: (Graph g, Show a, Ord b, Show b) => String -> g a b -> DotGraph graphviz title g = graphToDot g attrs nattrs eattrs where attrs = [Label title] nattrs (_,a) = [Label (show a)] eattrs (_,_,b) = [Label (show b)] Enjoy! [1] http://graphviz.org/ [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphviz [3] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/fgl [4] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dotgen [5] http://haskell.org/~duncan/WriteDotGraph.hs [6] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/prof2dot [7] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/flow2dot [8] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphmod -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

ivan.miljenovic:
The latest version of Matthew Sackman's Haskell bindings to Graphviz [1] are now available on Hackage [2]. The reason there's a new release only two weeks after the previous one is that I've made some extensions to it (hence why I'm writing the announcement) that Matthew has kindly included.
And by now you know where which distro has it: http://aur.archlinux.org/packages.php?ID=18343 See also, http://archhaskell.wordpress.com/2008/09/20/arch-haskell-news-sep-20-2008/ :) -- Don

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Sat, 20 Sep 2008 23:38:16 -0700
Don Stewart
And by now you know where which distro has it:
I'm sorry, Don, but you're late... Gentoo had it last night (as soon as Matthew told me he uploaded it to Hackage)! ;-) - -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjV7aAACgkQfEfFJ9Jhvyjj1gCfakJfsQX6g8FTc4kY2jDBogVl v/EAn31XYRa98GVY7Nz1G+cfOZ8tegJz =iDT/ -----END PGP SIGNATURE-----

ivan.miljenovic:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, 20 Sep 2008 23:38:16 -0700 Don Stewart
wrote: And by now you know where which distro has it:
I'm sorry, Don, but you're late... Gentoo had it last night (as soon as Matthew told me he uploaded it to Hackage)! ;-)
Mwhaha. Game on! -- Don

Ivan Lazar Miljenovic wrote:
On Sat, 20 Sep 2008 23:38:16 -0700 Don Stewart
wrote: And by now you know where which distro has it:
I'm sorry, Don, but you're late... Gentoo had it last night (as soon as Matthew told me he uploaded it to Hackage)! ;-)
I'm sorry, I'm confused... 1. How is putting something into a Cabal package different from just handing somebody the source code and telling them to run ghc --make? 2. If we already have a Cabal package, why do we also need seperate packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform? 3. Why isn't any of this explained in print anywhere?

Excerpts from Andrew Coppin's message of Sun Sep 21 02:44:10 -0500 2008:
1. How is putting something into a Cabal package different from just handing somebody the source code and telling them to run ghc --make?
Cabal can handle things for you like when your package depends on external data files; when cabal compiles the code it autogenerates a module which you import that will give you the path name to where-ever it is installed, which is nifty in case you for example are uploading a language for an interpreter and want to store the languages' prelude somewhere. It also allows for more tight constraints on dependent package versions i.e. with it you can specify the exact package and version you need to build (for example, parsec < 2.1 && > 3.0 which a few packages do.) With --make you would have to include a lot of -hide-package flags and a lot of other things, too. It is also naturally the easiest way to actually install libraries since it will register that library with ghc-pkg for you.
2. If we already have a Cabal package, why do we also need seperate packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?
Having these packages available as native packages for a package manager lets you distribute applications easier for example; if someone just wants to install <appname> from say, the archlinux user repository (which is source-based, mind you - the official repo is binary based,) it may also depend on parsec, haskell98, HTTP, etc.. Having these packages available natively to the manager means it can track the dependencies and install the application by itself - this is useful for example if someone just wants to use a haskell application but they don't code haskell (example: darcs or pandoc.) Of course, if you are doing haskell development, the best possible way to go (IMO) full-blown cabal install since you will always get the most up-to-date code - plus mixing and matching native package managers and e.g. cabal install doesn't really work well IME; for example if you want to install alex from macports, it will automatically install ghc too, even if you actually have it installed, but you didn't install it through macports (I just used the .dmg file that Manual Chak. made.) Likewise you may want to get something and it might depend on the HTTP library - it could very well already be installed via cabal-install, but the native manager won't dig into GHC to find out and will instead just work based on what it knows is installed in its package database. Austin

Austin Seipp wrote:
Cabal can handle things for you like when your package depends on external data files; when cabal compiles the code it autogenerates a module which you import that will give you the path name to where-ever it is installed, which is nifty in case you for example are uploading a language for an interpreter and want to store the languages' prelude somewhere.
OK, fair enough. I'm unlikely to ever need this personally, but it has utility.
It also allows for more tight constraints on dependent package versions i.e. with it you can specify the exact package and version you need to build (for example, parsec < 2.1 && > 3.0 which a few packages do.) With --make you would have to include a lot of -hide-package flags and a lot of other things, too.
So you're saying that using Cabal allows you to check that all your build dependencies are already installed? (Certainly just building something with GHC means that if some package isn't installed, you're going to have a hard time figuring out what's missing.)
It is also naturally the easiest way to actually install libraries since it will register that library with ghc-pkg for you.
Mmm, OK.
2. If we already have a Cabal package, why do we also need seperate packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?
Having these packages available as native packages for a package manager lets you distribute applications easier for example; if someone just wants to install <appname> from say, the archlinux user repository (which is source-based, mind you - the official repo is binary based,) it may also depend on parsec, haskell98, HTTP, etc.. Having these packages available natively to the manager means it can track the dependencies and install the application by itself - this is useful for example if someone just wants to use a haskell application but they don't code haskell (example: darcs or pandoc.)
Of course, if you are doing haskell development, the best possible way to go (IMO) full-blown cabal install.
Having native packages for stand-alone applications such as Darcs makes sense to me - after all, you don't need to install GCC just to use (say) KEdit, so why would you need to install GHC and build Darcs from source just to use it? However, managing individual Haskell libraries via the local package management system seems slightly redundant to me.

andrewcoppin:
Ivan Lazar Miljenovic wrote:
On Sat, 20 Sep 2008 23:38:16 -0700 Don Stewart
wrote: And by now you know where which distro has it:
I'm sorry, Don, but you're late... Gentoo had it last night (as soon as Matthew told me he uploaded it to Hackage)! ;-)
I'm sorry, I'm confused...
1. How is putting something into a Cabal package different from just handing somebody the source code and telling them to run ghc --make?
2. If we already have a Cabal package, why do we also need seperate packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?
3. Why isn't any of this explained in print anywhere?
It's all about users. To see more of the philosophy here, check out, Haskell: Batteries Included http://www.cse.unsw.edu.au/~dons/papers/CPJS08.html Ubiquitous, easy, complete Haskell. -- Don

Am Sonntag, 21. September 2008 09:44 schrieb Andrew Coppin:
[…]
2. If we already have a Cabal package, why do we also need seperate packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?
If I want to install gtk2hs on Debian, I’d like gtk (the C library) to be automatically installed. And I want Debian’s gtk package because this is the one, other Debian-packaged software uses. And a Debian user installing an application written in Haskell wants to use the Debian package manager.
[…]
Best wishes, Wolfgang

Austin: Of course, if you are doing haskell development, the best possible way
to go (IMO) full-blown cabal install since you will always get the most up-to-date code
Let's say I go and compile a library from sources and install it through
Cabal.
How can I update the binary version of the library Cabal installed after
recompiling the library using newer/modified sources?
Cetin
2008/9/23 Wolfgang Jeltsch
Am Sonntag, 21. September 2008 09:44 schrieb Andrew Coppin:
[…]
2. If we already have a Cabal package, why do we also need seperate packages for Arch, Gentoo, Debian...? Isn't Cabal cross-platform?
If I want to install gtk2hs on Debian, I'd like gtk (the C library) to be automatically installed. And I want Debian's gtk package because this is the one, other Debian-packaged software uses.
And a Debian user installing an application written in Haskell wants to use the Debian package manager.
[…]
Best wishes, Wolfgang _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Excerpts from Cetin Sert's message of Tue Sep 23 05:55:21 -0500 2008:
Let's say I go and compile a library from sources and install it through Cabal. How can I update the binary version of the library Cabal installed after recompiling the library using newer/modified sources?
I'm not quite sure I understand the question - if you for example install foo 0.1 using cabal, and then you want foo 0.2, you just install it with the same procedures. In this case, the higher version number means the other is 'shadowed' by it, and if you explicitly need to use foo 0.1, you can either specify this as a constraint of the form:
build-depends: foo == 0.1
in the package's .cabal file, or you will have to explicitly pass ghc/ghci the flag:
-hide-package foo-0.2
Otherwise, GHC will default to building anything that depends on foo against the newest version. OTOH, if you for example install foo 0.1 from stable sources, then checkout the HEAD version which is also listed as v0.1 in the .cabal file, reinstalling it will simply overwrite the old version entirely. Does that answer your query? Austin

2008/9/23 Cetin Sert
Austin:
Let's say I go and compile a library from sources and install it through Cabal. How can I update the binary version of the library Cabal installed after recompiling the library using newer/modified sources?
That should happen automatically with cabal-install if the version number in the .cabal file has changed. There doesn't seem to be a good way of forcing cabal-install to recreate a build (eg, if you want to rebuild/reinstall with profiling). I think you need to unregister the package manually first. :-( D -- Dougal Stanton dougal@dougalstanton.net // http://www.dougalstanton.net

Excerpts from Dougal Stanton's message of Tue Sep 23 06:09:58 -0500 2008:
That should happen automatically with cabal-install if the version number in the .cabal file has changed.
There doesn't seem to be a good way of forcing cabal-install to recreate a build (eg, if you want to rebuild/reinstall with profiling). I think you need to unregister the package manually first. :-(
With cabal-install 0.5.2, you simply have to pass the '--reinstall' flag to the 'install' command and it will reconfigure, rebuild and reinstall the packages with whatever flags you specify. Austin

Does that answer your query?
Yep it does, ^__^ Thank you very much.
Cetin
2008/9/23 Austin Seipp
Excerpts from Dougal Stanton's message of Tue Sep 23 06:09:58 -0500 2008:
That should happen automatically with cabal-install if the version number in the .cabal file has changed.
There doesn't seem to be a good way of forcing cabal-install to recreate a build (eg, if you want to rebuild/reinstall with profiling). I think you need to unregister the package manually first. :-(
With cabal-install 0.5.2, you simply have to pass the '--reinstall' flag to the 'install' command and it will reconfigure, rebuild and reinstall the packages with whatever flags you specify.
Austin _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

A reminder:
When I wanted to upgrade to yi 0.4.6.2, I needed to download the new package
list first
cabal update #download list of new packages
cabal upgrade #install newer versions of all packages
see "cabal help upgrade" for more, for upgrading a single package
cabal upgrade yi
Regards,
CS
2008/9/23 Cetin Sert
Does that answer your query?
Yep it does, ^__^ Thank you very much.
Cetin
2008/9/23 Austin Seipp
Excerpts from Dougal Stanton's message of Tue Sep 23 06:09:58 -0500 2008:
That should happen automatically with cabal-install if the version number in the .cabal file has changed.
There doesn't seem to be a good way of forcing cabal-install to recreate a build (eg, if you want to rebuild/reinstall with profiling). I think you need to unregister the package manually first. :-(
With cabal-install 0.5.2, you simply have to pass the '--reinstall' flag to the 'install' command and it will reconfigure, rebuild and reinstall the packages with whatever flags you specify.
Austin _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (8)
-
Andrew Coppin
-
Austin Seipp
-
Cetin Sert
-
Don Stewart
-
Dougal Stanton
-
Ivan Lazar Miljenovic
-
Ivan Miljenovic
-
Wolfgang Jeltsch