[Haskell-cafe] ANNOUNCE: graphviz-29188.8.131.52
Ivan Lazar Miljenovic
ivan.miljenovic at gmail.com
Mon Jul 20 09:08:49 EDT 2009
This is a bug-fix release to fix the various Attribute-related problems
in the previous release (29184.108.40.206) spotted mainly by Zsolt
Dollenstein. Please disregard version 29220.127.116.11; it had a small bug.
Similarly, people should avoid using 2918.104.22.168 unless they don't use
any Either-based Attributes.
The problem (which took me a while to realise) was that whilst I was
using Either to denote that an attribute could take one of two different
types of values (e.g. Bool and String) and the parsing for that worked.
However, since I was using Show (I know it's bad, it was on my TODO,
remember?) to generate the Dot code, then whenever one of these values
was converted then either Left or Right would appear, and GraphViz
doesn't seem to like that for some reason...
I also took the opportunity to define custom types for more Attributes
(as they only accept certain String values). Furthermore, GraphViz
states that attributes that can accept a boolean value are set to True
when the attribute is listed on its own; the library now does this even
for those Attributes that use a custom type that combines Bool with
something else. One other small change is that the Color Attribute now
takes in a list of Colors; if you only want one, use a singleton list
(it was either that or a custom datatype that takes either a single
Color or a list of Colors...).
Note that 2922.214.171.124 accidentally only had singleton Color values for
the Color Attribute rather than a list, hence the quick version bump.
Nothing else has changed in the library apart from the Attributes.
Regarding my request in the previous email about the possible new layout
of the DotGraph datatype:
How many people actually build DotGraphs by hand or pull them apart by
hand? If there were getNodes :: DotGraph -> [Node] and getEdges ::
DotGraph -> [Edge] functions available, would you accept an all-in-one
data type that just contains a generic list of statements and thus
follows upstream more closely? Even leaving aside parsing, this would
allow for greater flexibility for creating wild and wacky graphs or for
a monadic interface or something for building DotGraphs (which someone
has asked me for, but which at the moment I have no idea how to do...).
Ivan Lazar Miljenovic
Ivan.Miljenovic at gmail.com
More information about the Haskell-Cafe