ANNOUNCE: graphviz-2999.0.0.0
I am pleased to announce a new release of the graphviz package for Haskell, which provides bindings to the GraphViz [1] suite of tools. [1] http://www.graphviz.org/ Probably the biggest and most important change in this release is that AFAICT, all 152 attributes utilised/supported by GraphViz [2] are now specified and supported by this library. However, I'm not fully sure how well the parsing of these attributes will turn out; if you notice a bug/problem then please let me know. [2] http://graphviz.org/doc/info/attrs.html I've specified this as being the first in the 2999.0 series of releases. I will switch to 3000.0 when the generic graph class has been released and graphviz switched to using it rather than just FGL. One other future change that I'm considering is to improve the parsing ability of the Dot language. At the moment, graphviz assumes the following layout is followed: * Graph attributes * Nodes with their attributes (clusters are supported only for creation, not parsing). * Edges with their attributes. To match the behaviour of upstream, this will need to be changed into just a list of statements, where a statement is one of five things [3]: * A Node * An Edge * An attribute (either for the graph overall, nodes or for edges) * "ID '=' ID" (not quite sure what this is; some kind of assignment) * A subgraph (clusters are a specific type of subraph) As the way of defining an attribute for a specific grouping of nodes/edges/subgraphs is to have them all listed after the attribute definition (whereas those beforehand do not have this attribute), the imperative nature of the Dot language does not allow us to split these statements up as we currently do. [3] http://graphviz.org/doc/info/lang.html As such, I'm asking which of the following two choices people would prefer: 1. Follow upstream so that it can fully parse a Dot graph 2. Keep it as it is, so that it is possible to consider all edges, etc. easily. Other major changes to this release: ==================================== * Fixed a bug where the Show instance and read function for DotEdge had the from/to nodes the wrong way round. This was not immediately noticed since the Graph -> DotGraph functions created them the wrong way round, so for those users who only used these this was not apparent. Spotted by Neil Brown. * Greatly improved Attribute usage: almost all attributes are now covered with allowed values. * Extend DotGraph to include whether a graph is strict or not and if it has an ID. Also move the directedGraph field. * Make "Dot" refer to the actual dot command and DotArrow refer to the ArrowType (rather than DotCmd and Dot as before). * Make the Data.GraphViz.ParserCombinators module available to end users again, but not re-exported by Data.GraphViz; it has a warning message up the top not to be used. It is there purely for documentative purposes. * Use extensible-exceptions so that base < 4 is once again supported. * Follow the PVP rather than using dates for versions: http://www.haskell.org/haskellwiki/Package_versioning_policy Note that this means that any library/application using more than a trivial sub-set of graphviz will most likely need to be updated. However, now that the PVP is being followed it should be easier to tell in future when updates will be required. Other items I'm wanting to do in future releases: ================================================= * Allow user to choose whether or not the graph is meant to be directed or undirected. * Improve parsing to fully (or at least follow more closely) support Dot. * Improve clustering/subgraph support. * Use a PrettyPrinter rather than Show to generate Dot output. * Improve Output support. * Find and fix the handle closing bug with graphvizWithHandle. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
Hi, On Sat, Jul 18, 2009 at 10:23 AM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:
I am pleased to announce a new release of the graphviz package for Haskell, which provides bindings to the GraphViz [1] suite of tools.
Nice work! As the way of defining an attribute for a specific grouping of
nodes/edges/subgraphs is to have them all listed after the attribute
definition (whereas those beforehand do not have this attribute), the imperative nature of the Dot language does not allow us to split these statements up as we currently do.
[3] http://graphviz.org/doc/info/lang.html
As such, I'm asking which of the following two choices people would prefer: 1. Follow upstream so that it can fully parse a Dot graph 2. Keep it as it is, so that it is possible to consider all edges, etc. easily.
I would vote for the second one since I think that is the most widely used feature of this package. Cheers, Zsolt
Two clarifications I'd like to add to my previous announcement (both of
which were prompted by Zsolt :p ):
1. Some Attribute values take something like (Either Bool String); this
is used when upstream indicates that two different types of values
are allowed. Typically in this kind of situation, the allowed String
values are limited to a few specific values, so the usage of Either
typically indicates that they should be replaced with a custom value
type.
2. When considering the new representation of DotGraph, this isn't
limited to just people who wish to parse Dot code: if you want to do
anything out of the ordinary/fancy, then unfortunately you will need
this imperative usage (as the indicated way to have global attributes
to a graph but not to its subgraphs is to list all the subgraphs, and
then define the graph attribute).
For an example of this, consider the layout of Andy Gill's dotgen
library [1]. If you look at the internals, he does consider graphs
to be a list of statements. This amongst other things allows him to
have a monadic interface for building graphs with much greater
flexibility in what you can do, whereas graphviz limits you to either
converting a pre-existing graph or else creating one within the
limits of specifying it as a list of global attributes, a list of
nodes/clusters and a list of edges between the nodes.
[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dotgen
What I'm considering is that if I internally represent DotGraph as a
list of statements, then I will have getNodes and getEdges functions
to extract the nodes and edges (with their attributes) out. This
also simplifies some of the definitions, as a subgraph/cluster is
then also just a list of statements.
Zsolt Dollenstein
Hi,
On Sat, Jul 18, 2009 at 10:23 AM, Ivan Lazar Miljenovic < ivan.miljenovic@gmail.com> wrote:
I am pleased to announce a new release of the graphviz package for Haskell, which provides bindings to the GraphViz [1] suite of tools.
Nice work!
As the way of defining an attribute for a specific grouping of
nodes/edges/subgraphs is to have them all listed after the attribute
definition (whereas those beforehand do not have this attribute), the imperative nature of the Dot language does not allow us to split these statements up as we currently do.
[3] http://graphviz.org/doc/info/lang.html
As such, I'm asking which of the following two choices people would prefer: 1. Follow upstream so that it can fully parse a Dot graph 2. Keep it as it is, so that it is possible to consider all edges, etc. easily.
I would vote for the second one since I think that is the most widely used feature of this package.
Cheers, Zsolt
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
On Jul 19, 2009, at 04:13 , Ivan Lazar Miljenovic wrote:
1. Some Attribute values take something like (Either Bool String); this is used when upstream indicates that two different types of values are allowed. Typically in this kind of situation, the allowed String values are limited to a few specific values, so the usage of Either typically indicates that they should be replaced with a custom value type.
Shouldn't String then be replaced by a sum type? In fact, as described this would subsume the Either as well.
-- replace Either Bool String: AttrN are the strings, AltValue the bool data upstreamValue = AttrA | AttrB | AltValue
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
2009/7/20 Brandon S. Allbery KF8NH
Shouldn't String then be replaced by a sum type? In fact, as described this would subsume the Either as well.
-- replace Either Bool String: AttrN are the strings, AltValue the bool data upstreamValue = AttrA | AttrB | AltValue
Yes, as I said. I didn't for a few reasons: 1. I was running out of time and wanted to make a release on the weekend (I'm heading overseas in just over a week and have a fair few things to do before then). In future, this will probably be improved. 2. I forgot to replace those ones with the custom constructors :s Though IIRC, most of those that still have Either are those which probably aren't likely to be used, etc. Note also that (and this is also a problem with using Either) I have to think of a way to parse the values with a possible Bool field properly, since if a Bool is a valid value then just the attribute name is equivalent to name = true. At the moment, most attributes use a parseField function (that consumes the attribute name, the equals sign and then parses and returns the result) but those with just Bool attributes use a slight variant where if there is no equals sign, then True is returned. This will obviously not work too well with sum types :s.
-- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com Pablo Picasso - "Computers are useless. They can only give you answers." - http://www.brainyquote.com/quotes/authors/p/pablo_picasso.html
participants (4)
-
Brandon S. Allbery KF8NH -
Ivan Lazar Miljenovic -
Ivan Miljenovic
-
Zsolt Dollenstein