Re: [Haskell] [Haskell, FP] Anduril Industries is Hiring
Hi Travis, It would be helpful if you said a) where this was and b) if remote work is possible. On 5 April 2018 at 15:01, Travis Whitaker wrote: > Anduril Industries (https://www.anduril.com) is hiring. TL;DR: Come write > Haskell, Rust, and Nix (and some C++ when necessary) to make autonomous > robots and drones go! > > We're a team of software and hardware engineers from various backgrounds > (game development, computer graphics, financial technology, government > intelligence, biotechnology) working to improve the state of defense > technology. Our strategy involves focusing on product development instead of > traditional governmental processes. By funding product development ourselves > instead of relying on government funds, we're able to create more focused > products faster and with significantly fewer resources. By leveraging > hardware and techniques that have only recently become feasible to deploy at > scale (e.g. GPGPU computing), we can significantly advance the state of the > defense technology market. > > We're searching for generally competent, mathematically inclined software > engineers, and we're especially interested in those with experience in > computer vision (first principles techniques and machine learning), sensor > fusion, detection and tracking, and statistical parameter estimation. Our > team is increasingly applying functional programming and related > technologies; we run Haskell and Rust code in production and use Nix to > achieve reproducible build environments and keep deployment, CI, and > cross-compilation sane. > > If you like functional programming, interfacing with hardware, and solving > problems in detection, tracking, and autonomous vehicle control (land and > air), drop me a line at tra...@anduril.com > > > ___ > Haskell mailing list > Haskell@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANNOUNCE: servant-pandoc 0.5.0.0
I'm pleased to announce the latest release of the servant-pandoc library: https://hackage.haskell.org/package/servant-pandoc-0.5.0.0 servant-pandoc allows you to take the documentation created with servant-docs and use Pandoc to convert it into whichever format you want (rather than the Markdown generated by servant-docs). The main changes in this release are to provide compatibility with servant-docs-0.11.1; specifically, servant-pandoc now emits all the information that servant-docs does with the same configuration options. As such, there are behavioural changes which necessitated the major version bump. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANNOUNCE: streaming-conduit
I've recently found myself really enjoying using Michael Thompson's [streaming] library for, well, streaming data. However, a lot of packages that I want to use already use conduit for all their streaming needs. As such, I've just written the [streaming-conduit] library to convert between the two (rather than just switching this project to conduit entirely as I couldn't find a simple way to just stream data from a PostgreSQL database). I make no guarantees at this stage of performance, and it's quite possible that - especially for the asStream and asConduit functions - that they may not interoperate cleanly with monadic operations. [streaming]: https://hackage.haskell.org/package/streaming [streaming-conduit]: https://hackage.haskell.org/package/streaming-conduit -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz 2999.19.0.0
I've just released a new version of my Haskell bindings to the Graphviz graph visualisation toolkit. Note that the major version bump is solely because I had to remove what I thought was a useful feature (trying to allow you to do things like `"a" --> ["b", "c", "d"]` in Monadic graphs by automagically converting the "a" into ["a"]) turned out not to work in practice (as people will typically use this with literal values, but when combined with OverloadedStrings results in GHC getting confused as to what the type is). So unless you actually managed to use this functionality, then the API remains the same as 2999.18.* and you should just be able to bump your upper versions in your .cabal files (which you all do, right)? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [Haskell] Haskell Tools
Is there support for anything except Atom at this time? I'm also unsure of what I need to install on my local machine if I want to try it out (do I need the daemon? or is the cli tool sufficient?). On 6 April 2017 at 17:03, Boldizsár Németh wrote: > Dear Haskellers, > > I'm happy to announce a new tool for refactoring Haskell source code. > Check it out: http://haskelltools.org/ > > Best Regards, > Boldizsár Németh > ___ > Haskell mailing list > Haskell@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [Haskell] I repeat my Question becaue I not really sure to do it right
On 28 August 2016 at 22:40, wrote: > This is Leksah http://leksah.org/ > Please excuse my false name for it > And the Question is why can I install it. What error messages do you have when you try? From here, this is what you need to do: https://github.com/leksah/leksah/wiki/download > cabal install gtk2hs-buildtools > cabal install leksah > > excuse me. > Mungo1981 > > Gesendet: Sonntag, 28. August 2016 um 13:49 Uhr > Von: "Ivan Lazar Miljenovic" > An: cc...@web.de > Cc: "Haskell List" > Betreff: Re: [Haskell] I repeat my Question becaue I not really sure to do > it right > On 28 August 2016 at 20:43, wrote: >> Ok Haskell is good. >> Ok Laska is great. >> And my Ubuntu Studio ist rubish >> So I try to install Laska on Ubuntu Studio >> But when I do this, i will get a long list of dependecies >> which could not reallise >> So I not know what should I do > > Which question? > > What is Laska that you're having trouble installing it? > >> >> Mungo1981 >> >> _______ >> Haskell mailing list >> Haskell@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell >> > > > > -- > Ivan Lazar Miljenovic > ivan.miljeno...@gmail.com > http://IvanMiljenovic.wordpress.com > > ___ > Haskell mailing list > Haskell@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: [Haskell] I repeat my Question becaue I not really sure to do it right
On 28 August 2016 at 20:43, wrote: > Ok Haskell is good. > Ok Laska is great. > And my Ubuntu Studio ist rubish > So I try to install Laska on Ubuntu Studio > But when I do this, i will get a long list of dependecies > which could not reallise > So I not know what should I do Which question? What is Laska that you're having trouble installing it? > > Mungo1981 > > ___ > Haskell mailing list > Haskell@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell > -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANNOUNCE: testbench-0.1.0.0
I've just released a new library onto Hackage that aims to help you writing comparison-oriented benchmarks by: a) reducing the duplication found when using criterion directly b) let you test your benchmarked values/functions to ensure that they have the same result/satisfy a given predicate c) provide more comparison-oriented output I've written more about it here: https://ivanmiljenovic.wordpress.com/2016/05/23/test-your-benchmarks/ Or you could go straight to the Hackage page here: http://hackage.haskell.org/package/testbench -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANNOUNCE: unordered-graphs
I have a relatively hacked-together graph library that uses unordered-containers as a backend available if anyone finds it interesting/useful: http://hackage.haskell.org/package/unordered-graphs It's primarily developed just for my own needs and thus I'm not sure how much future work I'll be doing on it, but I'm willing to accept pull requests. This library was semi-experimental in that I also tried a few things out with it: * Polymorphic node type * Fixed auto-generated edge type: this is because (node,node, label) triples (ala fgl) do not provide sufficient information to be able to distinguish between multiple edges, etc. * Type parameter to determine whether the graph is directed or undirected. * Typeclass to allow you to determine the type/output of a a match (I didn't end up actually using this, as the one time I needed to do a match I found the extra polymorphism caused problems; it also isn't comprehensive as I didn't write all that many instances.) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.18.0.0
This is my "sorry it took so long" release: I'd like to apologise to all the people that have been nagging^W gently asking me when a GHC 7.10.*-compatible release would be available that it's taken me until now to do this, but I'm finally pleased to be able to say that you can now use my graphviz library to generate/parse Dot code and visualise graphs using the Graphviz suite of tools. As part of this version release, graphviz is now developed using git and can be found on GitHub: https://github.com/ivan-m/graphviz The major version bump is due to an extra attribute being made available, so in most (all?) cases you can safely version bump your existing dependencies. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANNOUNCE: fgl-5.5.2.0 and fgl-arbitrary-0.2.0.0
I'm pleased to announce that I've (finally!) just released version 5.5.2.0 of [fgl]. Major changes in this release include a test suite, refactorings, code clean-ups and the following potentially breaking changes (in that they were previously unspecified or incorrect): - `nodeRange` and `nodeRangeM` for the various graph data structures erroneously returned `(0,0)` for empty graphs (making them indistinguishable from graphs containing the single node `0`). They now match the default implementation of throwing an error. - The behaviour of `delLEdge` when dealing with multiple edges was unspecified; it now deletes only a single edge and the new function `delAllLEdge` deletes all edges matching the one provided. All changes can be found in the changelog. [fgl]: https://hackage.haskell.org/package/fgl Along with this I'm releasing version 0.2.0.0 of [fgl-arbitrary] (i.e. the "I finally build against the version on Hackage" release). [fgl-arbitrary]: https://hackage.haskell.org/package/fgl-arbitrary -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] To all users of FGL
As you may now, for the past few months I've been (finally!) cleaning up FGL, adding tests, etc. One of the issues that has arisen with this is that the behaviour of the delLEdge [1] function is not well specified when dealing with multiple edges. Specifically, the documentation states that the purpose is to "Remove *an* LEdge from the Graph." (emphasis added)... but the behaviour when dealing with multiple edges is to remove *all* such edges from the graph. The current version on GitHub is to instead just delete a single such labelled edge, with a new function "delAllLEdge" that replicates the current behaviour. Before releasing this change, however, I wanted to make sure that I wouldn't break people's code if they rely upon this functionality; I did try and search through GitHub to see who - if anyone - is using this function, but primarily found various copies of fgl embedded into other people's repositories. As such, please check your code and let me know if this change in behaviour might affect you (if this is the case, I might let delLEdge keep the current behaviour and have a new function delete just one edge). [1]: http://hackage.haskell.org/package/fgl-5.5.1.0/docs/Data-Graph-Inductive-Graph.html#v:delLEdge -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANNOUNCE: fgl-arbitrary
I've just released the first version of fgl-arbitrary [1], which provides Arbitrary instances for fgl graphs for use with QuickCheck. Also provided are some wrapper newtypes to produce specific types of graphs, and also the ability to generate just valid node and edge lists for use with other graph-like data structures. [1]: http://hackage.haskell.org/package/fgl-arbitrary -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANNOUNCE: fgl 5.5.1.0
I'm pleased to announce that - after being pestered about it for the past few months ;-) - I've released a new version of the Functional Graph Library that should* now be compatible with GHC 7.10. fgl is now developed on GitHub: https://github.com/haskell/fgl * In that I can't test it on my own machines -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANNOUNCE: monad-levels
I'm pleased to announce the first release of my new monad-levels library (aka Yet Another Monad Transformer Library ;-) http://hackage.haskell.org/package/monad-levels I've written more about the motivations of the library here: https://ivanmiljenovic.wordpress.com/2015/02/02/monadic-yak-shaving/ -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Drastic Prelude changes imminent
On 27 January 2015 at 21:52, Augustsson, Lennart wrote: > If you didn’t know that, e.g., the type of foldr is changing, check out the > thread https://www.haskell.org/pipermail/libraries/2015-January/024777.html. This seems to refer to your previous message, with no actual thread present and no mention of what the type of foldr is changing *to* (or what all the other bridge-breaking is going to be); is there an actual list of what these changes are? > > > > > This email and any attachments are confidential and may also be privileged. > If you are not the intended recipient, please delete all copies and notify > the sender immediately. You may wish to refer to the incorporation details > of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at > http://www.standardchartered.com/en/incorporation-details.html > > Insofar as this communication contains any market commentary, the market > commentary has been prepared by a sales and/or trading desk of Standard > Chartered Bank or its affiliate. It is not and does not constitute research > material, independent research, recommendation or financial advice. Any > market commentary is for information purpose only and shall not be relied > for any other purpose, and is subject to the relevant disclaimers available > at > http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx. > > Please visit > http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx > for important information with respect to derivative products. > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: buildable-0.1.0.0
Have you ever wanted to deal with the builders for various data types
in a polymorphic/overloaded fashion? I'm needing to do so and
couldn't find any existing code that did so, so I decided to rectify
this: http://hackage.haskell.org/package/buildable
As a (very contrived) example:
λ> build ((365 :: Dec Int) <| fromValue (Char7 ' ') |> (365 ::
BigEndian Int16) |> (" omega=𝟂 " :: Utf8 String) |> Utf16 (LE
("hello" :: LT.Text))) :: SB.ByteString
"365 \SOHm omega=\240\157\159\130 h\NULe\NULl\NULl\NULo\NUL"
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.17.0.0
It's taken me over a year, but I'm pleased to announce the latest version of my graph visualisation (via the Graphviz suite of tools) library: http://hackage.haskell.org/package/graphviz You can read all the changes in the Changelog (now linked to from the Hackage page, thanks to the magic of Hackage 2.0! :o), but here are some explicit non-API changes that people should probably be made aware of: * Parsing is currently about 8x slower than previously... because I suggested something two years ago to Malcolm Wallace on what seemed to make polyparse faster; he then released that change as part of polyparse-1.9 a year ago, but now when I do proper benchmarks (rather than the extremely limited ones I did then) I find that my changes actually make it _slower_ in real world usage. Whoops! I'm still using polyparse-1.9 in the hopes that Malcolm is able to release a point-fix release to revert my suggestion. * I'm not sure when it happened, but upstream Graphviz seems to have changed the behaviour of `dot -Tcanon` such that nodes are now interspersed among the edges (and I have been told that it's just a pretty-printer and that it's behaviour should not matter). As such, it is highly recommended that people only use the Generalised representation for parsing unless they're very sure of their input sources. One other change that people might find useful: if I ever again take so long (i.e. 4 major version releases of upstream) to update graphviz such that the various Attribute definitions are no longer valid and fail to parse, there's now (semi-experimental) support for having unrecognised attributes be parsed as an UnknownAttribute instead; but most of the other functions aren't aware of this functionality and thus you might need to duplicate a lot of code if you want to use this with other features like round-tripping. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: fgl-5.5.0.0
I'm pleased to announce a new version of the functional graph library: http://hackage.haskell.org/package/fgl-5.5.0.0 The main change in this version: proper Show, Read and Eq instances for both graph implementations. Previously, Data.Graph.Inductive.Tree had a pretty-printed Show output; now both it and PatriciaTree have Show and Read instances via the mkGraph function, and Eq via deriving (I'm not sure how well this will work because as I write this I realise it may not deal with multiple edges that well... I guess I'll be doing an updated version tomorrow after getting some sleep ;p). The previous Show behaviour of Tree is now available as a pretty-printing function for all DynGraph instances. The PatriciaTree implementation is now exported and used by default, because as far as I'm aware it will always perform better. Finally, the Data.Graph.Inductive.Graphviz module has been removed; if you want to visualise your fgl graph, please see my graphviz package on Hackage (cheap plug? moi?). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Newbie
On 8 March 2013 11:56, Brandon Allbery wrote:
> On Thu, Mar 7, 2013 at 7:45 PM, Dan Lior wrote:
>>
>> 1) Is this the right place for newbies to post questions about Haskell?
>
>
>
> This is most a list for announcements; beginn...@haskell.org is better for
> these kinds of questions, and haskell-c...@haskell.org for general
> discussion.
>
>> pred :: Int -> Int
>> pred 0 = 0
>> pred n+1 = n
>
>
> n+k patterns were part of Haskell '98, but removed from Haskell 2010. You
> may be able to use the pragma
>
> {-# LANGUAGE NPlusKPatterns #-}
>
> to turn them back on.
Even then, you need to have "pred (n+1) = n".
>
> --
> brandon s allbery kf8nh sine nomine associates
> allber...@gmail.com ballb...@sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
>
> _______
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.16.0.0
I'm pleased to announce that I've finally tracked down all the pesky little bugs that prevented me from releasing version 2999.16.0.0 of my graphviz library, that helps you use the Graphviz suite of tools to visualise graphs. The important changes are: * Add support for Graphviz-2.30.0: - New attributes: + `Area` + `Head_LP` + `LayerListSep` + `LayerSelect` + `Tail_LP` + `XLP` - `BgColor`, `Color` and `FillColor` now take a list of colors with optional weightings. - Layer handling now supports layer sub-ranges. - Added the voronoi-based option to `Overlap`. - Added the `Striped` and `Wedged` styles. * Updates to attributes and their values: - The following attributes have had their values changed to better reflect what they represent: + `FontPath` takes a `Path` value. + `Layout` takes a `GraphvizCommand` (and thus `GraphvizCommand` has been moved to `Data.GraphViz.Attributes.Complete`). - Added `MDS` to `Model` (which had somehow been overlooked). - Various attributes now have defaults added/updated/removed if wrong. - Removed the following deprecated attributes: + `ShapeFile` + `Z` * Now any value that has a defined default can be parsed when the Dot code just has `attribute=""` (which `dot -Tcanon` is fond of doing to "reset" attributes). * `GraphvizCommand` now defines `Sfdp` (which had somehow been overlooked up till now). * The `canonicalise` and related functions have been re-written; whilst there might be some cases where their behaviour does not fully match how `dot -Tcanon` and `tred` behave (due to the interaction of various attributes), the new implementation is much more sane. * Use temporary files rather than pipes when running dot, etc. Makes it more portable, and also avoids issues where dot, etc. use 100% CPU when a graph is passed in via stdin. Original patch by Henning Thielemann. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Cabal update failed
On 2 January 2013 23:07, Chernin, Nadav wrote: > Hello all, please help me with cabal updating. > > When i run: > > cabal update –v3 > > I get this message: > > Downloading the latest package list from hackage.haskell.org > > Sending: > > GET /packages/archive/00-index.tar.gz HTTP/1.1 > > Host: hackage.haskell.org > > User-Agent: cabal-install/0.10.2 > > Creating new connection to hackage.haskell.org > > cabal: failed > > Thanks in advance, Nadav > > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell > Can you manually run: wget http://hackage.haskell.org/packages/archive/00-index.tar.gz ? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.15.0.0
After much prodding and poking by end-users for the past few months, I'm finally able to announce a GHC-7.6.1 compatible release of my Haskell bindings to the Graphviz graph visualisation toolkit: http://hackage.haskell.org/package/graphviz-2999.15.0.0 (It took me so long to release a version that allowed bytestring-0.10.* as I was waiting for upstream to get back to me about an inconsistency I found; in the end I decided to just try and cope with how it seems to work.) The list of changes since the last release are: * The repository is now hosted at http://hub.darcs.net/ivanm/graphviz, and using the bug-tracker there. * Updates to various `Attribute` definitions: - The list of available shapes has been expanded to take into account the new synthetic biology shapes. - The `Size` and `FontNames` attributes now have specified data types. - The optional start and end points for `Spline`s were previously the wrong way round; this has now been fixed. - Explicitly only print 2-dimensional `Point` values for `Rect` and `DPoint` (previously only 2-dimensional values where parsed, but it was possible to print a 3-dimensional value). - HTML-like labels previously disallowed empty textual label components when parsing; spotted by Daniel Hummel. * `GraphvizParams` now lets you specify whether a "cluster" is actually a cluster or a sub-graph. Requested by Gabor Greif. * Fixed an error where printing edges whose attributes contained a `ColorScheme` attribute, that attribute would stay in the state and the old color scheme would override the _parent's_ state. * Previously, some malformed attributes were accepted when being parsed as they silently became parsed as an `UnknownAttribute`. Now, attributes where the attribute name and the equal sign are successfully parsed **but** the value of the attribute is _not_ successfully parse will throw an unrecoverable error. **Note**: this does mean that some Dot graphs that are accepted by Graphviz (as they separate tokenizing from parsing; as such something like `"0.1"` is successfully accepted as an integer, specifically `0`) are no longer accepted when parsing them in. * Miscellaneous parsing improvements: - Whilst not specified anywhere, Graphviz seems to treat empty quotes as values for attributes expecting a number as their default; as such, this is now taken into account when parsing. - `DPoint` values can now parse an optional `+` prefix. - Whitespaces after commas in HSV colors are now accepted. * Error messages from parsing are improved to help you track down where the parsing error occurred (in that it's easier to find which attribute failed to parse, etc.). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: pretty-tree
For a project I'm working on, I got sick of writing out trees by hand. Data.Tree has a drawTree function, but whilst it's better than nothing, I prefer a more top-down "traditional" approach to drawing trees. So I wrote a package to do just that: http://hackage.haskell.org/package/pretty-tree (I didn't think to check whether diagrams had capabilities to do so until after I finished, though in this case I prefer a textual approach anyway.) I'm more than happy to consider adding other forms of drawing trees (though off-hand I can't think of any), or of course you can send me patches since I'm taking advantage of the nice new shiny hub.darcs.net (thanks Darcs team!). I was going to put an example here but it only really comes out nicely if you're using a monospaced font, so have a look at the Haddock docs for the module once Hackage builds it (in hindsight, I should probably have come up with better labels before releasing the package... oh well :) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: GHC version 7.6.1
On 7 September 2012 02:05, Ian Lynagh wrote: > >= > The (Interactive) Glasgow Haskell Compiler -- version 7.6.1 >= > > The GHC Team is pleased to announce a new major release of GHC, 7.6.1. > > Here are some of the highlights of the 7.6 branch since 7.4: > > * Polymorphic kinds and data promotion are now fully implemented and > supported features. > > * Windows 64bit is now a supported platform. > > * It is now possible to defer type errors until runtime using the > -fdefer-type-errors flag. Is this flag reversible in ghci, so I can :set it to check what's going wrong with some code and then :unset it again? > > * The RTS now supports changing the number of capabilities at runtime > with Control.Concurrent.setNumCapabilities. > > Full release notes are here: > > http://www.haskell.org/ghc/docs/7.6.1/html/users_guide/release-7-6-1.html > > How to get it > ~ > > The easy way is to go to the web page, which should be self-explanatory: > > http://www.haskell.org/ghc/ > > We supply binary builds in the native package format for many > platforms, and the source distribution is available from the same > place. > > Packages will appear as they are built - if the package for your > system isn't available yet, please try again later. > > > Background > ~~ > > Haskell is a standard lazy functional programming language. > > GHC is a state-of-the-art programming suite for Haskell. Included is > an optimising compiler generating good code for a variety of > platforms, together with an interactive system for convenient, quick > development. The distribution includes space and time profiling > facilities, a large collection of libraries, and support for various > language extensions, including concurrency, exceptions, and foreign > language interfaces (C, whatever). GHC is distributed under a > BSD-style open source license. > > A wide variety of Haskell related resources (tutorials, libraries, > specifications, documentation, compilers, interpreters, references, > contact information, links to research groups) are available from the > Haskell home page (see below). > > > On-line GHC-related resources > ~~ > > Relevant URLs on the World-Wide Web: > > GHC home page http://www.haskell.org/ghc/ > GHC developers' home page http://hackage.haskell.org/trac/ghc/ > Haskell home page http://www.haskell.org/ > > > Supported Platforms > ~~~ > > The list of platforms we support, and the people responsible for them, > is here: > >http://hackage.haskell.org/trac/ghc/wiki/Contributors > > Ports to other platforms are possible with varying degrees of > difficulty. The Building Guide describes how to go about porting to a > new platform: > > http://hackage.haskell.org/trac/ghc/wiki/Building > > > Developers > ~~ > > We welcome new contributors. Instructions on accessing our source > code repository, and getting started with hacking on GHC, are > available from the GHC's developer's site run by Trac: > > http://hackage.haskell.org/trac/ghc/ > > > Mailing lists > ~ > > We run mailing lists for GHC users and bug reports; to subscribe, use > the web interfaces at > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs > > There are several other haskell and ghc-related mailing lists on > www.haskell.org; for the full list, see > > http://www.haskell.org/mailman/listinfo/ > > Some GHC developers hang out on #haskell on IRC, too: > > http://www.haskell.org/haskellwiki/IRC_channel > > Please report bugs using our bug tracking system. Instructions on > reporting bugs can be found here: > > http://www.haskell.org/ghc/reportabug > > > ___ > Haskell mailing list > Haskell@haskell.org > http://www.haskell.org/mailman/listinfo/haskell -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: ghc-vis
On 1 September 2012 17:27, Dennis Felsing wrote: > Hello, > > I'm pleased to announce the relase of ghc-vis. This package provides a > way to visualize live data structures in GHCi, similar to GHCi's :print > and vacuum-cairo. Evaluation is not forced and you can interact with the > visualized data structures. This allows seeing Haskell's lazy evaluation > and sharing in action. Hopefully it will be useful for teaching Haskell > and understanding and debugging data structures. > > Currently there's a linear view and a graph view using GraphViz. If you > want to see some examples of how it looks head to > > http://felsin9.de/nnis/ghc-vis/ > > or just give it a try like this: > > $ cabal install ghc-vis > $ echo ":script $HOME/.cabal/share/ghc-vis-0.2.1/ghci" >> ~/.ghci > $ ghci > GHCi, version 7.4.2: http://www.haskell.org/ghc/ :? for help > λ> :vis > λ> let a = [1..3] > λ> :view a > λ> let b = cycle a > λ> :view b > λ> :view "foo" ++ "bar" > λ> :eval t1 > λ> :switch > > On Hackage: http://hackage.haskell.org/package/ghc-vis > > I'm happy to hear about bugs, feature requests and other thoughts. > > Dennis In terms of your usage of graphviz, I have a couple of suggestions (as it's maintainer ;-) on how you can improve your code: * As of graphviz-2999.14.1.0, I've introduced isGraphvizInstalled and quitWithoutGraphviz to try and prevent closed pipe errors when you try to call dot when it isn't installed * I suggest you use either hGetDot or hGetStrict from Data.GraphViz.Commands.IO rather than hGetContents in your GHC.Vis.Graph.dg function (maybe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: planar-graph-1.0
On 28 April 2012 11:34, Christian Höner zu Siederdissen wrote: > Hi, > > one minor correction: >> This probably won't be of many use to people > for bioinformatics I'd disagree ;-) I'll take a look at your library. > > (for example, RNA /secondary/ structure forms a planar graph) I stand corrected! -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: planar-graph-1.0
I uploaded this [1] yesterday, posted the blog article [2] about it... but forgot to send a message to the lists! [1]: http://hackage.haskell.org/package/planar-graph [2]: http://ivanmiljenovic.wordpress.com/2012/04/27/announcing-planar-graph/ planar-graph is an implementation of, strangely enough, planar graphs (that is, a graph that contains an embedding on a surface, can be drawn with no edge crossings and has a specific ordering of edges). It handles graphs on planes and spheres, but I'm not sure about other surfaces (and there seems to be little demand for such). This probably won't be of many use to people, but as I described in the blog post, I've been using this as a test bed for graph library design (specifically usage of abstract node/edge identifiers, using half-edges and the serialisation/encoding setup). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Types of when and unless in Control.Monad
On 22 April 2012 21:39, Christian Höner zu Siederdissen wrote: > * Julian Gilbey [22.04.2012 09:22]: >> On Sat, Apr 21, 2012 at 08:28:27PM -0500, Strake wrote: >> > On 21/04/2012, Andreas Abel wrote: >> > > to avoid silly "return ()" statements like in >> > > >> > > when cond $ do >> > > monadicComputationWhoseResultIWantToDiscard >> > > return () >> > >> > (when cond ∘ void) monadicComputationWhoseResultIWantToDiscard >> > or >> > when cond $ () <$ monadicComputationWhoseResultIWantToDiscard >> >> How is that simpler than >> >> when cond monadicComputationWhoseResultIWantToDiscard >> >> which it would be with the suggested new type? >> >> Julian > > Wouldn't "when_" and "unless_" or similar be better? I'd probably like > to have the compiler annoy me, since it is not clear that I want to > discard the result. If I really want to discard, I should have to make > it clear as there is probably a good reason for the inner function to > return a result in the first place? Agreed; I'm not sure if I agree with having such functionality (Henning makes some good points), but if people deem it desirable then I think it would be better to have them with new names for the reasons you state. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: graphviz-2999.13.0.0
I should have pointed out that for most people, there should be minimal to no API change with this release; the only change I needed to make in my own code was that a type-class I had defined in Graphalyze was removed as it provided the impetus for the ToGraphID class mentioned below. On 19 April 2012 22:52, Ivan Lazar Miljenovic wrote: > I'm hoping the second part of the version number isn't ominous, but > I've just uploaded the latest release in my bindings for the Graphviz > suite of graph visualisation tools. > > The changes in this release are: > > * Added support for the `osage` and `patchwork` visualisation tools, > available as of Graphviz-2.28.0. > > * Updated attributes as of Graphviz-2.28.0: > > - `SVG` colors are now supported, and the support for different > colors has been revamped. > > - `overlap=false` is now equivalent to `overlap=prism` and the > `RemoveOverlaps` option has been removed. > > - `LabelScheme` and `Rotation` are new attributes for use with > `sfdp`. > > - `Scale` is a new attribute for use with `twopi`. > > - Add new italics, bold, underline, superscript and subscript > options for HTML-like labels. > > - `LHeight` and `LWidth` for getting the height and width of the > root graph and clusters. > > * Updated attributes from the current development branch of Graphviz > (i.e. 2.29.*). Please note that these will probably not work yet, > but are implemented now for future-proofing. > > - A new style for edges: `Tapered`. > > - `XLabel` allows you to specify labels external to a node or > edge. `ForceLabels` allow you to specify that these should be > drawn even when they will cause overlaps. > > - `ImagePath` allows you to specify where to search for images. > > - HTML-like labels now support `ID` values as well as horizontal > and vertical rules. > > - `BgColor` and `FillColor` now take a list of colors: this allows > gradient fills for graphs, clusters and nodes. The `Radial` > style and `GradientAngle` are also used for this purpose. > > - `FillColor` is now used by edges to set the color of any arrows. > > - [WebP](http://en.wikipedia.org/wiki/WebP) output support added. > > * Other attribute changes: > > - Use a specified data type for the `Ordering` attribute rather > than an arbitrary `Text` value, and provide a documented wrapper > in `Data.GraphViz.Attributes`. > > - `Bb` has been renamed `BoundingBox`. > > - `ID` now only takes `EscString` (a type alias for `Text`) values > rather than arbitrary `Label`s. > > - The `Data.GraphViz.Attributes.HTML` module has had all values > re-named and is now meant to be imported qualified. It is also > no longer re-exported from `Data.GraphViz.Attributes.Complete`. > > * The `ToGraphID` class provides a common wrapper to help create > cluster identifiers, etc. > > * Cabal's `Test-Suite` functionality is now used. As part of this, > the `Data.GraphViz.Testing` module and sub-modules are no longer > exported by the library. > > * The new `Benchmark` support in Cabal-1.14 is now used for the > benchmark script. > > * Dropped support for base-3. > > * The `Data.GraphViz.State` module is no longer exposed, as there's no > need for users to use it. > > * Bugfixes: > > - Some corner cases in canonicalisation prevented it from being > idempotent. > > - The `TestParsing` script will no longer crash and refuse to > continue if an IO-based error (e.g. unable to successfully call > `dot`) occurs. > > - A typo was spotted by **Gabor Greif**. > > -- > Ivan Lazar Miljenovic > ivan.miljeno...@gmail.com > http://IvanMiljenovic.wordpress.com -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.13.0.0
I'm hoping the second part of the version number isn't ominous, but I've just uploaded the latest release in my bindings for the Graphviz suite of graph visualisation tools. The changes in this release are: * Added support for the `osage` and `patchwork` visualisation tools, available as of Graphviz-2.28.0. * Updated attributes as of Graphviz-2.28.0: - `SVG` colors are now supported, and the support for different colors has been revamped. - `overlap=false` is now equivalent to `overlap=prism` and the `RemoveOverlaps` option has been removed. - `LabelScheme` and `Rotation` are new attributes for use with `sfdp`. - `Scale` is a new attribute for use with `twopi`. - Add new italics, bold, underline, superscript and subscript options for HTML-like labels. - `LHeight` and `LWidth` for getting the height and width of the root graph and clusters. * Updated attributes from the current development branch of Graphviz (i.e. 2.29.*). Please note that these will probably not work yet, but are implemented now for future-proofing. - A new style for edges: `Tapered`. - `XLabel` allows you to specify labels external to a node or edge. `ForceLabels` allow you to specify that these should be drawn even when they will cause overlaps. - `ImagePath` allows you to specify where to search for images. - HTML-like labels now support `ID` values as well as horizontal and vertical rules. - `BgColor` and `FillColor` now take a list of colors: this allows gradient fills for graphs, clusters and nodes. The `Radial` style and `GradientAngle` are also used for this purpose. - `FillColor` is now used by edges to set the color of any arrows. - [WebP](http://en.wikipedia.org/wiki/WebP) output support added. * Other attribute changes: - Use a specified data type for the `Ordering` attribute rather than an arbitrary `Text` value, and provide a documented wrapper in `Data.GraphViz.Attributes`. - `Bb` has been renamed `BoundingBox`. - `ID` now only takes `EscString` (a type alias for `Text`) values rather than arbitrary `Label`s. - The `Data.GraphViz.Attributes.HTML` module has had all values re-named and is now meant to be imported qualified. It is also no longer re-exported from `Data.GraphViz.Attributes.Complete`. * The `ToGraphID` class provides a common wrapper to help create cluster identifiers, etc. * Cabal's `Test-Suite` functionality is now used. As part of this, the `Data.GraphViz.Testing` module and sub-modules are no longer exported by the library. * The new `Benchmark` support in Cabal-1.14 is now used for the benchmark script. * Dropped support for base-3. * The `Data.GraphViz.State` module is no longer exposed, as there's no need for users to use it. * Bugfixes: - Some corner cases in canonicalisation prevented it from being idempotent. - The `TestParsing` script will no longer crash and refuse to continue if an IO-based error (e.g. unable to successfully call `dot`) occurs. - A typo was spotted by **Gabor Greif**. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] cabal conflicting rules
On 25 October 2011 09:34, Ben Millwood wrote: > Here's the advice I use on when to use what to install cabal packages: > > http://www.vex.net/~trebla/haskell/sicp.xhtml > > I think it's a bit overcautious, but rather that than the alternative. > It's worth a read even if you don't follow the advice in the end. I think the choice of which advice to follows boil down to something rather simple: how good is the quality of Haskell packages in your distribution? My main experience at the time of writing my blog post was with Gentoo, which had rather good support, especially for the popular packages (might be a bit behind for not-so-common ones, but easily bumped if a user asked it). Quite a few problems then arose with users trying to mix-and-match system packages with user packages, when there was no need to do so. But in distributions that _don't_ have good Haskell support (e.g. I'm currently using Exherbo, and mix-and-match system and user packages because the system packages are rather limited; I've been meaning to try and add native Cabal support to the package manager to fix this for about a year now, but I'm not looking forward to hacking in C++ :p), then it may make more sense to use user-packages only... _if_ you understand the limitations this has. Package managers for distributions are typically better suited for resolving dependencies (especially if you give them specific information like "containers isn't meant to be user-upgradeable" and which version of containers comes with which version of GHC) and are able to uninstall packages, which cabal-install can't do yet. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] getting started
On 29 September 2011 19:14, haskell wrote: > i have hugs i am installing haskell-platform > when i run in hugs using :load it does nothing Just loading a file doesn't do anything, you have to give it a command to do. Run "main" or something inside hugs. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] getting started
On 29 September 2011 00:15, haskell wrote: > yes i h ave seen this and learn your haskell for great god and wiki books can > you tell me the firat script that works so i can tell what is the problem You want a simple working program? Put the following into a file called Hello.hs main = putStrLn "Hello World!" If you have GHC installed, then run "ghc --make Hello.hs" and then run the resulting Hello executable ( run "./Hello" on *nix, double-click the "Hello.exe" on Windows). For hugs I'm not too sure, but you should be able to do "hugs Hello.hs" and inside that just type in "main" (without quotes). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] [ANNOUNCE] network-address-0.2.0
On 8 September 2011 23:05, Ben Millwood wrote: > On Wed, Sep 7, 2011 at 1:03 PM, Sebastian Nowicki wrote: >> The next release will likely be v1.0.0 as there isn't much to add. I'd >> like to keep the API stable in that version, I welcome any feedback >> regarding the API (or otherwise). > > The main problem is lacking an effective way to parse addresses from > strings - the readAddress interface is unsafe and doesn't give the > remainder of the string. Consider using the ReadS convention, > providing a function readsAddress :: String -> [(a,String)] which > provides all possible parses (usually at most one) and the remainder > of the string. Then users can parse addresses followed by other data > easily. There is one, in the Address class; readAddress just uses readsAddress. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] [ANNOUNCE] network-address-0.2.0
On 8 September 2011 12:19, Conrad Parker wrote: > > given that readAddress can parse the output of showAddress, and > readSubnet can parse the output of showSubnet, is there any reason not > to use these for the implementation of Show and Read instances? My guess is that since showAddress and readsAddress are class-based, there might be some defaulting issues if you use them. Also, unless the constructor isn't exported, isn't it usually preferable to have Show and Read instances produce/use actual values directly? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.12.0.0
It's been a while in coming (I started work on this at the end of last year!) but I am pleased to announce the latest version of my graphviz library [1], which acts as a wrapper around the Graphviz [2] suite of graph visualisation utilities. [1] : http://projects.haskell.org/graphviz/ http://hackage.haskell.org/package/graphviz [2]: http://graphviz.org Major changes in this release (see the changelog [3] for a complete listing): * A large focus on increasing usability: - Examples for all Dot representations against an existing Dot graph - Cut-down, easier to use Attribute wrapper (all Attributes still available from Data.GraphViz.Attributes.Complete if you need any of the others). - graphElemsToDot helps visualise non-FGL graphs (if you can list all nodes and edges, you can visualise it!) * Two new Dot representations: - One that allows graph-based operations (based upon FGL) - Another based upon Andy Gill's dotgen [4] (with permission!) for easier embedding of relatively static graphs. * Pure Haskell implementations of `dot -Tcanon` and `tred`. * Now based upon Text rather than String, which improves performance for both printing and parsing and also enforces UTF-8 encoding. * Now easier to do custom I/O with Dot graphs. [3]: http://projects.haskell.org/graphviz/changelog.html [4]: http://hackage.haskell.org/package/dotgen Unfortunately, this release is largely backwards incompatible in some ways, but not too much. Specifically, it didn't take me long to migrate over Graphalyze [5] and SourceGraph [6], and most of that time was spent changing over to the new, nicer functions for creating Attributes. [5]: http://hackage.haskell.org/package/Graphalyze [6]: http://hackage.haskell.org/package/SourceGraph Please let me know if there are any other API improvements that you'd like to see to improve usage. I am planning a tutorial (half of the reason why this release took so long is that I kept thinking "this functionality would be useful for the tutorial!"; this includes the graph-based representation, the re-implementation of tred and canonicalisation, etc.), which should be out in the next month or so (I'm considering adding nicer syntax for record labels first). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: string-qq-0.0.2
2011/6/28 Jean-Marie Gaillourdet :
> Hi Audrey,
>
> are you aware that Haskell already supports multi-line strings?
>
> foo = "This is a\
> \multi-line\
> \string!"
>
> See Section 2.6 of http://haskell.org/onlinereport/lexemes.html
I've used this approach for multi-line strings; note first of all that
to make the examples equivalent you would need to add '\n' twice to
your definition of foo. However, even without that it's rather
annoying to use and can be difficult to typeset correctly (though that
admittedly could be due to the indentation support in haskell-mode not
being up to par as it refuses to indent subsequent lines properly
after the String).
Another alternative would be:
foo = unlines
[ "This is a"
, "multi-line"
, "string!"
]
Though it too can be a bit cumbersome.
>
> Regards,
> Jean
>
> On 25.06.11 22:55, 唐鳳 wrote:
>> Hi all,
>>
>> I've just released string-qq 0.0.2 to Hackage:
>>
>> http://hackage.haskell.org/package/string-qq
>>
>> The main interface is the "s" quasi-quoter:
>>
>> foo :: IsString a => a
>> foo = [s|
>> This is a
>> multi-line
>> string!
>> |]
>>
>> It allows simple multi-line strings of any IsString type (Text, String,
>> ByteString, etc),
>> with no interpolation at all, except that the leading newline is trimmed and
>> "\r\n" sequences are converted to "\n".
>>
>> It's compatible with both GHC6 and GHC7; for GHC6, write [$s|…|] instead of
>> [s|…|].
>>
>> Suggestions and feedback are most welcome. :-)
>>
>> Cheers,
>> Audrey
>>
>> ___
>> Haskell mailing list
>> Haskell@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell
>
>
> --
> Jean-Marie Gaillourdet
>
> blog: gaillourdet.net
> {email, xmpp, jabber, ichat, gimix, gtalk}: j...@gaillourdet.net
>
> ___
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
IvanMiljenovic.wordpress.com
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: wl-pprint-text 1.0.0.0
And lo, the people of Haskell hath declared that the text [1] library was to be the One True Way of dealing with textual data (unless, of course, you're annoyed about it using UTF-16 instead of UTF-8). And yet there was much sadness in the land, for there was no pretty-printing library available to produce said Text values, meaning that it was difficult for supplicants to produce the formatting their form of praise required. A voice then spake: make ye a new pretty-printing library aimed specifically for Text values. But thou shall not use the API from pretty [2], as it is rather limited. Instead, the design of wl-pprint [3] looks Real Good! It has more combinators available, can neatly deal with wrapping lists, and also has support for producing output for both humans and the machines that serve us so well! Thus were mighty energies aimed at producing such a library. Many were the hour at which toil was spent on this task, but at long last the task was completed. Yet great evil (i.e. programmer laziness) befell the great task, and it lay hidden for many a moon. However, with much effort the project was recovered, and is now available for all! [4] Some changes were regrettably required to achieve this task. The most important of which was that it was discovered that wl-pprint may not be as perfect as all that, in that documents of no content were treated poorly. However, spects of the pretty package were able to redeem themselves by supplying the necessary functionality. However, the great task was able to extend upon that which was there before, by invoking the almighty powers of the Monad. TL;DR: wl-pprint-text is a pretty-printing package for lazy Text values based upon the API of wl-pprint. It however deals with the nil document better than wl-pprint does, and also has a version where all the comibnators are lifted into a Monad, primarily so that it can be used within a State Monad. [1]: http://hackage.haskell.org/package/text [2]: http://hackage.haskell.org/package/pretty [3]: http://hackage.haskell.org/package/wl-pprint [4]: http://hackage.haskell.org/package/wl-pprint-text -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Announcing Djinn, version 2004-12-11, a coding wizard
On 7 April 2011 14:35, Martin wrote: > > flow 0 y = y > flow z flow x, y = flow z+x, y This doesn't appear to be a valid function definition... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANN: Yi 0.6.3
On 29 March 2011 12:19, Brandon S Allbery KF8NH wrote: >> No, my meaning was that the reasoning of "I don't need to specify this >> as a dependency since it's part of the Platform" isn't sound since not >> everyone has the Platform. > > The point of the Platform is to provide a baseline. So you *are* saying it > is pointless, because you want packages to confirm to a different baseline. My impression that the Platform was a baseline in regards to "what do I need to get started to develop with Haskell?", and not in terms of specifying dependencies. After all, we still need to specify a dependency on `base' in .cabal files, even though it comes with GHC and other compilers (let alone the Platform)? Consider also people who just want to use software written in Haskell but aren't developers, especially those that use distros like Gentoo that build from source (either by default or optionally for non-packaged software) rather than using pre-built binaries: they aren't going to want to know/care about the Platform, they just want their package manager to get the minimal dependencies that are required to build and install that piece of software. As such, being explicit about build tools is beneficial in this regard (e.g. when gtk2hs was cabalised, how much fun was had when cabal-install couldn't work out that it needed to install gtk2hs-buildtools to get the extra build tools it needed?). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANN: Yi 0.6.3
On 29 March 2011 12:10, Brandon S Allbery KF8NH wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 3/28/11 17:06 , Ivan Lazar Miljenovic wrote: >> On 29 March 2011 06:40, Jeff Wheeler wrote: >>> Oh, my bad. I removed this because alex is included in the Platform, >>> so it seemed like it'd always be available. I'll add it back. >> >> Not *everyone* has the Platform installed! (I prefer to install ghc >> and then just the libraries I need via my package manager). > > So you're saying that the Platform is pointless? I think there's some > miscommunication going on somewhere, if we're all going to pretend it > doesn't exist. No, my meaning was that the reasoning of "I don't need to specify this as a dependency since it's part of the Platform" isn't sound since not everyone has the Platform. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANN: Yi 0.6.3
On 29 March 2011 06:40, Jeff Wheeler wrote: > On Mon, Mar 28, 2011 at 7:33 AM, Edward Amsden wrote: >>> * mention alex in the cabal file (I don't remember the syntax but there is >>> a way to specify tools needed to build). >> build-tools: alex >> >> in the library/executable section > > Oh, my bad. I removed this because alex is included in the Platform, > so it seemed like it'd always be available. I'll add it back. Not *everyone* has the Platform installed! (I prefer to install ghc and then just the libraries I need via my package manager). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Literate Haskell editing with Emacs and MMM: the $ operator
On 26 January 2011 06:07, Julian Gilbey wrote: > I've been editing literate (LaTeX-based) Haskell code using Emacs and > MMM-mode, using the instructions posted in > http://www.haskell.org/pipermail/haskell/2006-April/017855.html > > There's one annoyance, however: the $ operator in Haskell code ends up > being interpreted as the beginning of math mode, completely messing up > any font-lock colo(u)ring. > > Has anyone else found this, and has anyone come up with a good > solution? Last time I tried this, I ended up inserting extra $ just to fix up the syntax highlighting :s Maybe try something like http://www.loveshack.ukfsn.org/emacs/haskell-latex.el instead? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] letter?
On 17 December 2010 22:39, Simon Peyton-Jones wrote: > Did someone forget to renew www.haskell.org? Who does this? > > Also plain http://haskell.org/ used to work, but doesn't any more. > > I'm sure lots of people have noticed this, but it'd be good if someone posted > a summary of what's being done about it. Both work fine here (just checked)... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.11.0.0
I am pleased to announce version 2999.11.0.0 of graphviz [1], my Haskell bindings to the Graphviz suite of graph visualisation tools [2]. [1]: http://hackage.haskell.org/package/graphviz [2]: http://graphviz.org/ This release is mostly backwards-compatible (unless you dealt directly with Point and LayerList values); the changes are: * Improved documentation, including examples of how to use `GraphvizParams` values (since several people indicated that they found them confusing) * Addition of the `Labellable` class (and its method `toLabel`) to make it easier to construct labels. * Backslashes (i.e. the `\` character) are now escaped/unescaped properly (bug spotted by Han Joosten). As part of this: - Dot-specific escapes such as `\N` are now also handled correctly, so the slash does not need to be escaped. - Newline (`'\n'`) characters in labels, etc. are escaped to centred-newlines in Dot code, but not unescaped. * `Point` values can now have the optional third dimension and end in a `!` to indicate that that position should be used (as input to Graphviz). * `LayerList` uses `LayerID` values, and now has a proper `shrink` implementation in the test suite. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Graphalyze-0.11.0.0 and SourceGraph-0.7.0.0
I am pleased to announce the 0.7.0.0 release of my graph-theoretic source code analysis tool SourceGraph [1], and the library it uses Graphalyze 0.11.0.0 [2]. [1]: http://hackage.haskell.org/package/SourceGraph [2]: http://hackage.haskell.org/package/Graphalyze Changes in SourceGraph (apart from those resulting from improvements to Graphalyze): * Edge widths are now log-based rather than being the number of function calls; this avoids having absurdly thick edges. * Source files that were not able to be parsed are now listed both to stderror and in the resulting report (thus helping you work out why you're missing some code) * Also builds with Cabal-1.10; whilst I do not currently have GHC 7 installed anywhere and thus can't test this, I know of no reason why SourceGraph cannot be built with GHC 7 (unless it uses a library that isn't buildable on GHC 7 that I have no control over). Changes in Graphalyze: * Legends can now contain text-only fields rather than just graphs; also, the title of each legend is now displayed first rather than what it describes. * To fix a bug spotted by Han Joosten, the reports currently use Posix-style path separators even on Windows (otherwise, HTML documents produced on Windows were not in a state to be uploaded elsewhere). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell Weekly News: Issue 155 - October 20, 2010 (Originally posted to Haskell-Cafe)
On 22 October 2010 21:53, Johan Tibell wrote: > On Fri, Oct 22, 2010 at 10:41 AM, Colin Paul Adams > wrote: >> I do. But note I also subscribe to the cafe. >> >> The annoying thing is people cross-post to both lists, which IS >> spamming, IMHO. > > A good email client (like Gmail), deals with this without a problem by > collapsing the two emails into one. GMail does tend to abuse stuff like this as well. However, if you check your mailing list subscription settings you can also get it to only send one email when you're subscribed to multiple lists IIRC. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: "New FGL" naming survey
For those interested, the overall results are in: http://ivanmiljenovic.wordpress.com/2010/07/25/results-of-fgl-naming-survey/ Ivan Miljenovic writes: > Thank you for all the people who have voted; we so far have 42 results > in about 12 hours. > > Some indication of the results so far: > > * 62% prefer inductive-graphs > > * 62% have indicated that they use fgl or do some graph-related stuff > (no correlation, just an interesting coincidence; I have not as yet > done the number crunching to tell what the most popular name is for > people that actually use fgl or other graph stuff). > > * Someone stated that ponies smell sweaty... not sure how that's > relevant, but OK. > > * At least two people prefer the new name as it isn't an acronym (one > because acronyms aren't needed and the term functional is redundant, > the other because the term "graph" isn't directly in the package > name). > > * Martin Erwig himself said that he thinks we should keep using the name > "fgl". > > So, keep the votes coming in (I actually didn't expect this many already)! > > On 14 July 2010 00:24, Ivan Lazar Miljenovic > wrote: >> Whether or not the new FGL that Thomas Bereknyei and I are working on >> should keep the name was a semi-hot issue when we first mentioned the >> fact that we were working on a new version about a month ago. As such, >> I've created a survey here to try and find out what the Haskell >> community overall thinks we should call it: >> https://spreadsheets.google.com/viewform?formkey=dGpzMmFnUWY3Uktodk5wdHlLQk5kT1E6MA >> >> More info can be found on the actual survey page. >> >> -- >> Ivan Lazar Miljenovic >> ivan.miljeno...@gmail.com >> IvanMiljenovic.wordpress.com >> -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUNCE: container-classes-0.0.0.0
I was in a bit of a rush to send this email earlier before the table got packed up from in front of me, so I forgot to mention these little tidbits: * container-classes uses MPTCs+fundeps to define the classes rather than type families. My initial preference would have been to use an associated type, except that due to the lack of superclass constraints then the various *Functor type classes would have to have extra constraints of the form "Value (c a) ~ a" in every single type signature (and for every single value being used, so 3 extra constraints of this form for zip3, etc.). I felt that this verbosity was a bit too much and thus declined. Furthermore, I would have needed to use an MPTC for the *Functor type-classes anyway as I would have to state the value type somewhere in the class to ensure it was properly constrained. However, once superclass constraints become available (which will probably be 6.16 at the earliest from what I've been told) then I'll switch it to using type families (assuming the library is still being used of course). * Container uses Monad as a super-class to avoid re-defining mempty and mappend, though it does have (++) = mappend, so that's there for all those people wanting to infiltrate Caleskell-style ideas into Haskell proper... * Someone's asked me why I don't define a Traversable-like class. The reason is is that I haven't gotten around to it yet ;-) (as well as a great many other things). Ivan Lazar Miljenovic writes: > I'm pleased to announce the fruits of my labours during AusHac [1]: > version 0.0.0.0 of the container-classes library [2] I was talking about > in my last blog post [3]. > > [1]: http://www.haskell.org/haskellwiki/AusHac2010 > [2]: http://hackage.haskell.org/package/container-classes > [3]: http://ivanmiljenovic.wordpress.com/2010/07/14/data-oriented-hierarchies/ > > The purposes of this library is two-fold: > > * As a library writer, let your users choose which data structure they > want to use rather than whichever one you decided upon when writing > the library (e.g. you use lists predominantly, but your users may want > to use Sets; by outputting a generic Container value yoru users don't > need to keep using Set.fromList and Set.toList). > > * When writing your own code and you realise that you're using the wrong > data structure for your purposes, if you used this library (correctly) > then the amount of work you need to do to swap data structures is > minimised. > > This current version is only a first draft. As such, I would appreciate > feedback on the API. Currently, it provides its own definitions of all > list-oriented functions in the Prelude plus a few more (e.g. partition), > and list instances of all the classes. > > In terms of definitions, most class methods have default definitions in > terms of fold. Furthermore, as much as possible I've defined them using > a build/fold setup outlined in the paper "A Short Cut to Deforestation" > by Andrew Gill, John Launchbury and Simon Peyton Jones (however I > haven't yet defined the rules to get this used yet). However, the > current list instances use the pre-defined versions in the Prelude and > Data.List; I'm not sure if I should keep it this way or - where > equivalent - use the pre-defined ones so that hopefully conversions from > lists to other data types would also be removed without needing > intermediary data structures. > > I also plan on adding more instances and a Lookup class for Maps, etc. > However, we have to start packing up the room now and so my hacking is > at an end for this weekend :( -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: container-classes-0.0.0.0
I'm pleased to announce the fruits of my labours during AusHac [1]: version 0.0.0.0 of the container-classes library [2] I was talking about in my last blog post [3]. [1]: http://www.haskell.org/haskellwiki/AusHac2010 [2]: http://hackage.haskell.org/package/container-classes [3]: http://ivanmiljenovic.wordpress.com/2010/07/14/data-oriented-hierarchies/ The purposes of this library is two-fold: * As a library writer, let your users choose which data structure they want to use rather than whichever one you decided upon when writing the library (e.g. you use lists predominantly, but your users may want to use Sets; by outputting a generic Container value yoru users don't need to keep using Set.fromList and Set.toList). * When writing your own code and you realise that you're using the wrong data structure for your purposes, if you used this library (correctly) then the amount of work you need to do to swap data structures is minimised. This current version is only a first draft. As such, I would appreciate feedback on the API. Currently, it provides its own definitions of all list-oriented functions in the Prelude plus a few more (e.g. partition), and list instances of all the classes. In terms of definitions, most class methods have default definitions in terms of fold. Furthermore, as much as possible I've defined them using a build/fold setup outlined in the paper "A Short Cut to Deforestation" by Andrew Gill, John Launchbury and Simon Peyton Jones (however I haven't yet defined the rules to get this used yet). However, the current list instances use the pre-defined versions in the Prelude and Data.List; I'm not sure if I should keep it this way or - where equivalent - use the pre-defined ones so that hopefully conversions from lists to other data types would also be removed without needing intermediary data structures. I also plan on adding more instances and a Lookup class for Maps, etc. However, we have to start packing up the room now and so my hacking is at an end for this weekend :( -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] "New FGL" naming survey
Whether or not the new FGL that Thomas Bereknyei and I are working on should keep the name was a semi-hot issue when we first mentioned the fact that we were working on a new version about a month ago. As such, I've created a survey here to try and find out what the Haskell community overall thinks we should call it: https://spreadsheets.google.com/viewform?formkey=dGpzMmFnUWY3Uktodk5wdHlLQk5kT1E6MA More info can be found on the actual survey page. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUNCE: fgl-5.4.2.3
A couple of points I meant to make here but forgot (I was busy hacking on this and my other three graph-related packages for over a week now, and especially this past weekend it cut into my sleeping...): * Apart from bug-fixes, I don't intend on touching the 5.4 series any more. That said, I believe that this version is suitable for replacing 5.4.2.2 in the platform (what's the process on that?). * After I get my generic graph class sorted out at AusHac this coming weekend, I intend to make a 5.5.0.0 release which extends the classes in this new library; this will probably _not_ be suitable for the platform and is intended to serve as a stepping stone to the replacement library Thomas Bereknyei and I are working on. With that last point: Thomas and I are willing to call this new version/replacement something like "inductive-graphs" if that is the preference of the community. Does anyone know of a website that would let us have a survey we can use to determine which option people would prefer? Note that even if we give it a new name (rather than just a new major version number), we still intend on using the Data.Graph.Inductive module namespace (as it makes even more sense with the new name), so there will still be clashes between this new version and fgl. Ivan Lazar Miljenovic writes: > I'm pleased to present the first new release of fgl [1] since Thomas > Bereknyei took over maintaining it from Martin Erwig. > > [1] http://hackage.haskell.org/package/fgl > > Before people start panicking, rioting, etc., please check the version > number: this is just a bug-fix release, and not the complete re-write > version which we've been talking about (since we got a little > sidetracked, etc.). As such, the API hasn't changed, and this should > fit right in to packages already using fgl (sorry to all those people > who followed my advice and put "fgl == 5.4.2.2" in the build-depends > fields of their packages' .cabal files, but I didn't expect to make > another 5.4.y release). > > The exact change that has been made is to fix a bug pointed out to me by > Tristan Allwood, in that Data.Graph.Inductive.PatriciaTree didn't > support multiple edges (and furthermore this wasn't specified in the > documentation). This has now been rectified. As an indication of what > these changes mean, see this sample call graph produced by my > SourceGraph program; when using PatriciaTree from fgl-5.4.2.2 the lines > were all the same thickness; now there is among other things a loop of > width 32 on getExp and a line of width 7 from getExp to maybeEnt. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: ANNOUCE: graphviz-2999.10.0.0
Something I forgot to mention (yes, I forgot to mention something here as well as for the fgl announcement): I sent out an email during the week asking people what they'd prefer in terms of semantics as a pure Haskell implementation for "dot -Tcanon". I didn't end up getting around to implementing this yet (as I wanted to get all these packages out first and I'm still reverse-engineering all the corner cases dealing with what happens to nodes in a cluster that has the same name as another cluster), but the infrastructure for doing so is all there so there may be a 2999.10.1.0 release soon with this feature. Ivan Lazar Miljenovic writes: > I'm pleased to announce a new version of my graphviz [1] library that > provides bindings to the Graphviz [2] suite of tools for visualising > graphs. > > [1]: http://hackage.haskell.org/package/graphviz > [2]: http://graphviz.org/ > > Changes in this release: > > * I followed my own advice and put in bounds on the version of FGL it > used... > > * Conversion of FGL-style graphs to `DotRepr` values is now achieved > using the new `GraphvizParams` configuration type. This allows us > to define a single parameter that stores all the conversion > functions to pass around rather than having to pass around several > functions. This also allows all the non-clustered and clustered > functions to be collapsed together, whereas what used to be handled > by the primed functions is now achieved by using the > `setDirectedness` function. > > There are three default `GraphvizParams` available: > > - `defaultParams` provides some sensible defaults (no attributes > or clustering). > > - `nonClusteredParams` is an alias of `defaultParams` where the > clustering type is explicitly set to be `()` for cases where you > don't want any clustering at all (whereas `defaultParams` allows > you to set your own clustering functions). > > - `blankParams` sets all fields to be `undefined`; this is useful > for situations where you have functions that will set some > values for you and there is no sensible default you can use > (mainly for the clustering function). > > * Expansion of the `DotRepr` class: > > - More common functions are now defined as methods (`getID`, > etc.). > > - The ability to get more information about the structure of the > `DotRepr` graph, as well as where all the `DotNode`s are, etc. > > - `graphNodes` now returns `DotNode`s defined only as part of > `DotEdge`s, and will also merge duplicate `DotNode`s together. > > - `graphNodes` and `graphEdges` also return `GlobalAttributes` > that apply to them. > > * The `Point` type now only has one constructor: `Point Double > Double`. The `Int`-only constructor was present due to historical > purposes and I thought that the `Pos` value for a `DotNode` would > always be a pair of `Int`s; this turns out not to be the case (and > accounted for some bugs in older versions of my SourceGraph tool; it's > taken me this long to remember to fix this...). > > * `SortV` and `PrismOverlap` now only take `Word16` values rather than > `Int`s, as they're not meant to allow negative values (the choice of > using `Word16` rather than `Word` was arbitrary, and because it's > unlikely those values will be large enough to require the larger > values available in `Word`). > > * `NodeCluster` has been generalised to not have to take an `LNode` > for the node type; the type alias `LNodeCluster` is available if you > still want this. > > * Several documentation typos fixed, including one spotted by Kevin > Quick. > > * The test-suite now allows running individual tests. > > -- > Ivan Lazar Miljenovic > ivan.miljeno...@gmail.com > IvanMiljenovic.wordpress.com -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: SourceGraph-0.6.1.1 and Graphalyze-0.10.0.0
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/codeCore.svg (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.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUCE: graphviz-2999.10.0.0
I'm pleased to announce a new version of my graphviz [1] library that provides bindings to the Graphviz [2] suite of tools for visualising graphs. [1]: http://hackage.haskell.org/package/graphviz [2]: http://graphviz.org/ Changes in this release: * I followed my own advice and put in bounds on the version of FGL it used... * Conversion of FGL-style graphs to `DotRepr` values is now achieved using the new `GraphvizParams` configuration type. This allows us to define a single parameter that stores all the conversion functions to pass around rather than having to pass around several functions. This also allows all the non-clustered and clustered functions to be collapsed together, whereas what used to be handled by the primed functions is now achieved by using the `setDirectedness` function. There are three default `GraphvizParams` available: - `defaultParams` provides some sensible defaults (no attributes or clustering). - `nonClusteredParams` is an alias of `defaultParams` where the clustering type is explicitly set to be `()` for cases where you don't want any clustering at all (whereas `defaultParams` allows you to set your own clustering functions). - `blankParams` sets all fields to be `undefined`; this is useful for situations where you have functions that will set some values for you and there is no sensible default you can use (mainly for the clustering function). * Expansion of the `DotRepr` class: - More common functions are now defined as methods (`getID`, etc.). - The ability to get more information about the structure of the `DotRepr` graph, as well as where all the `DotNode`s are, etc. - `graphNodes` now returns `DotNode`s defined only as part of `DotEdge`s, and will also merge duplicate `DotNode`s together. - `graphNodes` and `graphEdges` also return `GlobalAttributes` that apply to them. * The `Point` type now only has one constructor: `Point Double Double`. The `Int`-only constructor was present due to historical purposes and I thought that the `Pos` value for a `DotNode` would always be a pair of `Int`s; this turns out not to be the case (and accounted for some bugs in older versions of my SourceGraph tool; it's taken me this long to remember to fix this...). * `SortV` and `PrismOverlap` now only take `Word16` values rather than `Int`s, as they're not meant to allow negative values (the choice of using `Word16` rather than `Word` was arbitrary, and because it's unlikely those values will be large enough to require the larger values available in `Word`). * `NodeCluster` has been generalised to not have to take an `LNode` for the node type; the type alias `LNodeCluster` is available if you still want this. * Several documentation typos fixed, including one spotted by Kevin Quick. * The test-suite now allows running individual tests. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: fgl-5.4.2.3
I'm pleased to present the first new release of fgl [1] since Thomas Bereknyei took over maintaining it from Martin Erwig. [1] http://hackage.haskell.org/package/fgl Before people start panicking, rioting, etc., please check the version number: this is just a bug-fix release, and not the complete re-write version which we've been talking about (since we got a little sidetracked, etc.). As such, the API hasn't changed, and this should fit right in to packages already using fgl (sorry to all those people who followed my advice and put "fgl == 5.4.2.2" in the build-depends fields of their packages' .cabal files, but I didn't expect to make another 5.4.y release). The exact change that has been made is to fix a bug pointed out to me by Tristan Allwood, in that Data.Graph.Inductive.PatriciaTree didn't support multiple edges (and furthermore this wasn't specified in the documentation). This has now been rectified. As an indication of what these changes mean, see this sample call graph produced by my SourceGraph program; when using PatriciaTree from fgl-5.4.2.2 the lines were all the same thickness; now there is among other things a loop of width 32 on getExp and a line of width 7 from getExp to maybeEnt. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] ANN: HaRe-0.6, now on Hackage
Chris BROWN writes: > Dear Haskellers, > > As part of our project on Refactoring Functional Programs > > http://www.cs.kent.ac.uk/projects/refactor-fp/ > > we are pleased to announce the availability of HaRe 0.6 on Hackage. > > http://hackage.haskell.org/package/HaRe-0.6 Congratulations! One comment on your .cabal file: it's usually preferred to write "base >= 3 && <5" rather than "base >= 3 && <= 4". -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Sifflet visual programming language, release 0.1.7
Henning Thielemann writes: > gdwe...@iue.edu schrieb: >> Sifflet 0.1.7 is now available on Hackage. >> This release has some changes in its package dependencies, >> notably for fgl. >> >> New in This Release >> --- >> >> - Due to anticipated changes in the API for fgl, >> Sifflet now requires fgl < 5.4.2.3. >> - Similarly, I have added upper bounds on versions >> of some other packages that Sifflet depends on. > > I'm uncertain whether fgl conforms to the package versioning policy, but > if it does, then changes in its Cabal file should not bother sifflet. > Thus upper bound fgl < 5.4.3 should be restrictive enough. Well, it definitely will be following the PVP from now on. As for that restriction, it doesn't make any difference; we might make a 5.5 transition/compatability release at some point but that's about it. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: [Haskell-cafe] Please check your dependencies on fgl
Ian Lynagh writes: > On Mon, Jun 07, 2010 at 11:50:44AM -0700, Donald Bruce Stewart wrote: > >> A complete rewrite with a new maintainer: fgl-awesome > > In 10 years time, we don't want to have > fgl > fgl-awesome > fgl-great > fgl-joe > which all do the same thing, and have an unclear relationship to each > other. Definitely (though hopefully we wouldn't pick names like "fgl-awesome" anyway...). > I think the important question is: Once the new FGL is finished, will > there be a good reason (other than backwards compatibility) for people > to use the current FGL? > > If yes, then different names should be used. Otherwise, no matter how > different the API is, keeping the same name is the right thing to do. And this is why we're going to request the community's input on our API design: to try and avoid the situation where there's a specific reason to keep using the old one. As it stands, the only real advantage that I can think of is that the new version uses extensions, the old version doesn't (and hence is more compatible). > So if there is consensus that the new design is a better fgl, I think it > ought to keep the name. Which is what we're trying to build (the consensus, that is). Don has started a wiki page with the arguments here, and I've already added my 2c: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Please check your dependencies on fgl
Christian Maeder writes: > Ivan Lazar Miljenovic schrieb: >>> Although parsec-3 can be used as an replacement for parsec-2 it would >>> have been better, they had different names (as argued elsewhere for the >>> haskell platform). >> >> I'm sorry, I don't recall this discussion: care to summarise? > > http://www.haskell.org/pipermail/libraries/2010-March/013101.html I've read through that thread, but I remain unconvinced. First of all, I think there are a few misconceptions raised there (e.g. the gitit discussion is because John Macfarlane doesn't want to use Parsec-3 for Pandoc because it used to be slow and because it isn't available in Debian; this latter point shouldn't be a concern for most software IMHO; secondly, if the documentation of the 2.x series was better, then why not improve the documentation of the 3.y series?). Maintaining Haskell98 compatability may be a valid concern (I don't know how valid it is to most people, but I can see some people preferring it). _Why_ should a library remain fixed at a particular version (unless of course you are convinced it is perfect)? By creating a new package, people will keep using the old version which will eventually bit-rot rather than upgrading. There are also a few other differences between the situations here: * A lot more packages use parsec than fgl, such that the conversion process is more difficult (whereas for those packages on Hackage that use fgl, over half have already responded that they'll fix the dependency problem such that the version update won't be a problem). * The most common reason given for not upgrading to parsec-3 was efficiency; we're going to work hard to make sure that the speeds are comparable if not better (since for the most part the data structure is the same, it's just the overall API that differs in terms of how function names, etc.). * Many people liked parsec-2; the common opinion on #haskell, etc. seems to be that fgl is full of warts and many people (such as Cale) prefer to use one-off custom graph implementations (e.g. IntMap IntSet) rather than use fgl. A lot of the changes we're making to fgl comes from taking into account what people don't like about the current layout of fgl. >> With fgl, the actual changes aren't that big on the user side of things >> if they want to keep using the defaults (it's not a drop-in replacement, >> but the _way_ to use it remains unchanged). > > I usually don't want to make even small changes at installation time. But this isn't an installation time change, it's a build/develop time change. >> The big difference is when people want to make custom instances; >> however, as far as I know no-one has created any custom instances for >> FGL's classes. > > Well, I've created a custom instance: > http://trac.informatik.uni-bremen.de:8080/hets/browser/trunk/Common/Lib/Graph.hs > and our hets project is not a hackageDB package. This looks very similar to what is currently called Data.Graph.Inductive.PatriciaTree; is there any particular reason for using your own custom variant? One thing you may like from the new fgl: proper Show, Read and Eq instances being available for graphs (since I know some people are annoyed that fgl currently doesn't have any method of serialising the graph for storage/transmission; so much so that someone has even resorted to converting the graph to/from Dot format and using that for serialisation). >> But by keeping the old fgl around as a separate package, there is then >> no real incentive to change/upgrade. If, however, we re-use the package >> name then it will be more obvious that there is a new and (hopefully) >> improved version available. > > Your "incentive" would be a "small annoyance" for me since it would > force me to change the dependency to "fgl < ..." until I find time to > test our code with the newer fgl version (without possible other > changes). It's a very simple change, however (and arguably you and everyone should always use bounded dependencies anyway just in case of this kind of problem). Arguably, changing the code may involve more time to take into account the new API. However, we aim to have sufficient advantages to the new version of fgl that people would _want_ to change. > (I still haven't updated from tabular-0.1.0.2 to tabular-0.2.x, yet.) Wow, considering that tabular-0.2.1.0 (the first in the 0.2.x series) came out over a year ago and you still haven't upgraded is a little surprising... As a compromise, we might consider not uploading the new version of fgl to hackage (or having the developmental version use a new name, similar to how darcs has darcs-beta for testing releases) and get
[Haskell] Re: Please check your dependencies on fgl
Christian Maeder writes: > Ivan Lazar Miljenovic schrieb: >> We considered giving it a new name (fgl', etc.) but figured that in the >> long term this wouldn't be advantagous. We feel that the situation is >> analogous to QuickCheck: when the new version came out most people kept >> using the old one until slowly the momentum shifted and more people >> started using the new version (without checking in depth, Roel's Hackage >> mirror reports QC-2.x now has 153 reverse dependencies as opposed to 127 >> reverse dependencies for QC-1.y). >> >> If we changed the name, then the "emotional attachment" that the Haskell >> community has to FGL being the de-facto graph library means that people >> would keep using the old version. Whilst we also face the possible >> problems of people not liking the old version and thus automatically >> dismissing the new version, I think this is a much more unlikely >> scenario. > > I'm afraid you'll destroy the "emotational attachment" to fgl by > annoying incompatibilities (and possibly interfering new bugs). > > Although parsec-3 can be used as an replacement for parsec-2 it would > have been better, they had different names (as argued elsewhere for the > haskell platform). I'm sorry, I don't recall this discussion: care to summarise? With fgl, the actual changes aren't that big on the user side of things if they want to keep using the defaults (it's not a drop-in replacement, but the _way_ to use it remains unchanged). The big difference is when people want to make custom instances; however, as far as I know no-one has created any custom instances for FGL's classes. > Changing a dependency in a cabal file is a small problem. > Those (unaware), who only mention "fgl", will fall over an > incompatibility (usually at installation time!) and simple say "fgl < > ..." unless they are willing to change their code then. > > Those who already have "fgl < ..." need to find an advertisement of a > "new and better fgl" anyway and can choose when to change their code. But by keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade. If, however, we re-use the package name then it will be more obvious that there is a new and (hopefully) improved version available. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] Please check your dependencies on fgl
Oh, great, the email _did_ go out on the mailing lists (what with haskell.org being down I wasn't sure it would). Don Stewart writes: > ivan.miljenovic: >> Thomas Bereknyei are currently re-writing fgl (just about completely >> from scratch) and we plan to make an initial release to get feedback >> on the API in the next few weeks. >> >> However, I'm sending this email out now to warn people that I highly >> doubt any code that was written for the current version of fgl >> (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the >> new version. > > How about you give the library a different name then -- so as not to > break all those programs? > > A complete rewrite with a new maintainer: fgl-awesome We considered giving it a new name (fgl', etc.) but figured that in the long term this wouldn't be advantagous. We feel that the situation is analogous to QuickCheck: when the new version came out most people kept using the old one until slowly the momentum shifted and more people started using the new version (without checking in depth, Roel's Hackage mirror reports QC-2.x now has 153 reverse dependencies as opposed to 127 reverse dependencies for QC-1.y). If we changed the name, then the "emotional attachment" that the Haskell community has to FGL being the de-facto graph library means that people would keep using the old version. Whilst we also face the possible problems of people not liking the old version and thus automatically dismissing the new version, I think this is a much more unlikely scenario. The overall philosophy is remaining the same: we're just updating the implementation (letting people pick the Node type rather than hard-coding it to Int, letting people constrain the label types and also providing more scope for optimisations). As such, the new version is incompatible with the old one; however, if you're only _using_ FGL (as opposed to making a new instance of the graph types), then the actual changes to using the new version should be minimal (especially if you're using it internally in which case you can hard-code the various types in and not have to worry about the type family usage at all). As I said, I've directly emailed the maintainers of the packages that have open-ended dependencies on FGL and thus would have compilation problems when we release the new version[s]; 7 out of 12 of those maintainers have already responded within less than 24 hours so I don't think this is likely to be a problem unless some new package is uploaded in the near future without proper ranged dependencies. So as to give you even more of a heads up, here are some more overall plans Thomas and I have for FGL: * FGL will still focus on inductive graphs; however the two current classes are being combined since it doesn't make much sense in general to have a graph that can be decomposed using match but can't be composed using & (there might be specific cases where this is true such as considering the Cabal package dependency "graph"; however this is likely to be defined internally within some project so users should just be careful about how they use it to ensure they don't add arbitrary nodes/edges that don't make sense; note that the new Show and Read instances take advantage of this by using Contexts as the basis of this instance). * The ability to have proper Eq, Show and Read instances for graphs with pre-defined helper functions implementors can use (currently Data.Graph.Inductive.Tree has a "pretty" output for Show but no Read instance, and graphs cannot have equality due to overlapping instance problems). * Splitting the library up into the base classes + sample instances (the fgl package) and a separate fgl-algorithms package (analogous to Dan Doel's vector-algorithms; this will be comprised of what is currently in the Data.Graph.Inductive.Query.* modules as well as the Data.Graph.Analysis.Algorithms.* modules in my Graphalyze library. The Data.Graph.Inductive.Graphviz module will also be scrapped in favour of my graphviz library. * By default, fgl will ship with two default instances: the one currently in Data.Graph.Inductive.PatriciaTree and also a generic Map-based one that lets people choose their own Node type (i.e. the key type in the Map). Any other suitable instances that we can think of (e.g. Thomas has the beginnings of a vector-based one) we'll ship in separate packages (e.g. fgl-vector). If anyone has a good reason to object to any of these plans, we are willing to be persuaded out of them. This is why the 6.z series of fgl will be "technology previews" to slowly build up what FGL does and gauge the reaction of the Haskell community. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Gtk2Hs version 0.11.0 released
Bulat Ziganshin writes: > Hello Axel, > > Thursday, May 27, 2010, 10:13:45 PM, you wrote: > >> http://code.haskell.org/gtk2hs/INSTALL > > thank you. and what if i deploy my gtk2hs application via hackage? > is it enough for user to run "cabal install myapp" to install my app > and all runtime gtk/gtk2hs libraries she need to run it? They would need to install gtk2hs-buildtools and alex themselves to be able to build gtk and associated libraries, as well as have the appropriate C header files from gtk+ installed. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Gtk2Hs version 0.11.0 released
Bulat Ziganshin writes: > Hello Axel, > > Thursday, May 27, 2010, 9:50:57 PM, you wrote: > >>> does it mean that i can just issue "cabal install gtk" with any 6.10.* >>> or 6.12.* version and it will be compiled automatically? overall, can > >> Maybe I'm missing the point of your question, though. > > for example, i can't use previous gtk2hs version with ghc 6.10.4 on > windows because there is no prebuilt library and i'm not brave enough > to compile it myself. is it true that gtk2hs 0.11 should automatically > compile with any ghc 6.10/6.12 on windows and we no more need prebuilt > installers? Well, you still need the C library and headers installed... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz 2999.9.0.0
I'm pleased to announce the latest version of my graphviz library that provides Haskell bindings to the Graphviz graph visualisation suite. There are numerous changes in this release, the most important of which are: * graphviz now has an FAQ and an improved README as well as its own homepage: http://projects.haskell.org/graphviz/ (as prompted by Eric Kow). * Add support for record labels; values are automatically escaped/unescaped. The `Record` and `MRecord` shapes have been added for use with these labels. Requested by Minh Thu and Eric Kow. * Add support for HTML-like values (this replaces the wrong and completely broken URL datatype). Strings are automatically escaped/unescaped. * Various parsing improvements (including a slight parsing speed increase!). In particular, graphviz is now able to parse almost all Dot graphs found on my system (including samples shipped with Graphviz, Linux kernel documentation and various other package documentations). A list of the breakages and why: * /usr/share/sgml/docbook/xsl-stylesheets/roundtrip/template.dot seems to be a binary file and thus can't be read. * /usr/share/graphviz/graphs/directed/Latin1.gv uses Latin1 encoding; at the moment graphviz uses the system's locale encoding (or whatever GHC < 6.10 defaults to). * /usr/share/doc/boost-*/html/libs/graph/example/graphviz_test.dot (various boost versions) has subgraphs in edges; graphviz currently can't cope with these. * /usr/src/linux-2.6.33-gentoo-r1/Documentation/blockdev/drbd/drbd-connection-state-overview.dot uses incorrect syntax for the "minlen" attribute (it is meant to be an integer but actually contains a floating point value). The plans for the next release (which I don't plan on even starting for a while) are to focus on improving printing and parsing performance, using a state-based printer and parser (as part of Dot syntax is state-based) and force usage of UTF-8 (via text or utf8-string). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: AusHac2010
Dreading the end of ZuriHac? Wish the Haskellian camaraderie could continue? Well, if you're able to make your way to Sydney, Australia between the 16th and 18th of July, then AusHac2010 is for _you_! It will be held at the School of Computer Science and Engineering at the University of New South Wales (thanks to Manuel Chakravarty and Ben Lippmeier for offering to organise the rooms!). If you are wanting to attend the inaugural Australian Hackathon, please register at http://axman6.wufoo.com/forms/aushac-2010-sign-up/ . For more information, see http://www.haskell.org/haskellwiki/AusHac2010 We will shortly be adding an extended version of the "Who" table; please also add your details there as well as which projects you would be interested in hacking in. Hoping to see you there! -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] ANNOUNCE: SourceGraph-0.6.0.2
Niklas Broberg writes: > Because it's been so many relatively small releases of late that I > haven't wanted to spam the lists. :-) I for one say spam away! Especially with a change like 1.5 -> 1.6. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: SourceGraph-0.6.0.2
I've just uploaded a new version that works with haskell-src-exts-1.6.0 (all it needed was to increase the upper bound in the cabal file! \o/). On another note, anyone know why Niklas Broberg hasn't been making any release statements recently to say what the changes are, etc. for haskell-src-exts? Ivan Lazar Miljenovic writes: > I realised soon after I sent the announcement email that there was a bug > in one of the new "subtle" features that I didn't list, namely the > background shading of directories in import visualisation. As such, > SourceGraph 0.6.0.1 contains this fix. > > There were also two other features in 0.6.0.0 that I forgot to mention: > > * SourceGraph will (well, should; I haven't managed to come across a > situation where it occurs anyway) no longer throw a fit if Graphviz > throws an error when visualising a graph; instead it will just put an > error message into the generated report. > > * The generated Dot code is also saved in the SourceGraph/graphs/ > subdirectory, so you can tweak the call graphs of your programs. > > Ivan Lazar Miljenovic writes: > >> I'm pleased to announce the latest releases of SourceGraph [1] and >> Graphalyze [2]. >> >> [1]: http://hackage.haskell.org/package/SourceGraph >> [2]: http://hackage.haskell.org/package/Graphalyze >> >> SourceGraph is a program that performs static code analysis on Haskell >> projects on the by applying graph theoretic techniques to the project's >> call graph. Graphalyze is a library for analysing discrete data using >> graph theory, and as such performs the heavy lifting for SourceGraph. >> >> Sample analysis reports generated by SourceGraph are available at >> http://code.haskell.org/~ivanm/Sample_SourceGraph/SampleReports.html . >> I will also be demoing SourceGraph at PEPM [3] in Madrid on 19 January. >> >> [3]: http://www.program-transformation.org/PEPM10/ >> >> Changes since the previous version include: >> >> * Now supports "implicitly exported" entities (as requested by Curt >> Sampson). This includes instantiated class methods from other >> modules and functions, etc. that start with an underscore (see >> http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html >> for more information). >> >> * All inaccessible entities are now reported, not just those that were >> root nodes in the call graph. >> >> * Edges are now colour-coded based upon whether they are part of a >> clique, cycle or a chain. >> >> * Level-based analyses: visualise how deep an entity is from those >> exported entities. >> >> * A re-done TODO that lists in detail what is planned for SourceGraph. >> >> * Lots of under-the-hood changes that don't sound as interesting as the >> above :-( -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: SourceGraph-0.6.0.1
I realised soon after I sent the announcement email that there was a bug in one of the new "subtle" features that I didn't list, namely the background shading of directories in import visualisation. As such, SourceGraph 0.6.0.1 contains this fix. There were also two other features in 0.6.0.0 that I forgot to mention: * SourceGraph will (well, should; I haven't managed to come across a situation where it occurs anyway) no longer throw a fit if Graphviz throws an error when visualising a graph; instead it will just put an error message into the generated report. * The generated Dot code is also saved in the SourceGraph/graphs/ subdirectory, so you can tweak the call graphs of your programs. Ivan Lazar Miljenovic writes: > I'm pleased to announce the latest releases of SourceGraph [1] and > Graphalyze [2]. > > [1]: http://hackage.haskell.org/package/SourceGraph > [2]: http://hackage.haskell.org/package/Graphalyze > > SourceGraph is a program that performs static code analysis on Haskell > projects on the by applying graph theoretic techniques to the project's > call graph. Graphalyze is a library for analysing discrete data using > graph theory, and as such performs the heavy lifting for SourceGraph. > > Sample analysis reports generated by SourceGraph are available at > http://code.haskell.org/~ivanm/Sample_SourceGraph/SampleReports.html . > I will also be demoing SourceGraph at PEPM [3] in Madrid on 19 January. > > [3]: http://www.program-transformation.org/PEPM10/ > > Changes since the previous version include: > > * Now supports "implicitly exported" entities (as requested by Curt > Sampson). This includes instantiated class methods from other > modules and functions, etc. that start with an underscore (see > http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html > for more information). > > * All inaccessible entities are now reported, not just those that were > root nodes in the call graph. > > * Edges are now colour-coded based upon whether they are part of a > clique, cycle or a chain. > > * Level-based analyses: visualise how deep an entity is from those > exported entities. > > * A re-done TODO that lists in detail what is planned for SourceGraph. > > * Lots of under-the-hood changes that don't sound as interesting as the > above :-( -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: SourceGraph-0.6.0.0 and Graphalyze-0.9.0.0
I'm pleased to announce the latest releases of SourceGraph [1] and Graphalyze [2]. [1]: http://hackage.haskell.org/package/SourceGraph [2]: http://hackage.haskell.org/package/Graphalyze SourceGraph is a program that performs static code analysis on Haskell projects on the by applying graph theoretic techniques to the project's call graph. Graphalyze is a library for analysing discrete data using graph theory, and as such performs the heavy lifting for SourceGraph. Sample analysis reports generated by SourceGraph are available at http://code.haskell.org/~ivanm/Sample_SourceGraph/SampleReports.html . I will also be demoing SourceGraph at PEPM [3] in Madrid on 19 January. [3]: http://www.program-transformation.org/PEPM10/ Changes since the previous version include: * Now supports "implicitly exported" entities (as requested by Curt Sampson). This includes instantiated class methods from other modules and functions, etc. that start with an underscore (see http://www.haskell.org/ghc/docs/latest/html/users_guide/options-sanity.html for more information). * All inaccessible entities are now reported, not just those that were root nodes in the call graph. * Edges are now colour-coded based upon whether they are part of a clique, cycle or a chain. * Level-based analyses: visualise how deep an entity is from those exported entities. * A re-done TODO that lists in detail what is planned for SourceGraph. * Lots of under-the-hood changes that don't sound as interesting as the above :-( -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.8.0.0
I am pleased to announce the latest release of my graphviz [1] library, which provides bindings and helper functions for use with the Graphviz [2] suite of graph visualisation programs. [1] http://hackage.haskell.org/package/graphviz [2] http://www.graphviz.org/ For the most part, this release has a compatible API with the 2999.7.0.0 version; the only exceptions to this are the runGraphviz and runGraphvizCommand functions in Data.GraphViz.Commands; I released after the last release that it might be useful to have these return the filenames of the files created rather than just indicating success, especially when using addExtension (from the same module) to add the correct extension to a provided filename. The rest of the changes to this release are: * Added support for generalised DotGraphs; this optional representation removes the restriction of ordering of Dot statements. This allows for greater flexibility of how to specify Dot code. As an offshoot from this, most relevant functions now utilise a new DotRepr class that work with both DotGraphs and the new GDotGraphs; this shouldn't affect any code already in use. * With the prompting of Noam Lewis, the augmentation functions have been revamped in two ways: - Now contains support for multiple edges. - The ability to perform "manual" augmentation if greater control is desired. * Add a preview function to quickly render and visualise an FGL graph using the Xlib canvas. * Added a pseudo-inverse of the FGL -> Dot functions (a graph is created, but the original node and edge labels are unrecoverable). * The Printing and Parsing modules have been moved (from Data.GraphViz.Types to Data.GraphViz). In the near future, this library is also likely to contain support for record shapes for graph nodes thanks to Minh Thu. If you want/require any additional features in graphviz, you too can do what countless (well, OK, not actually countless per-se) people like Noam and Thu have done: bug me to do it or send me a patch! ;-) (I hope that I don't have to make yet another release soon fixing an obvious flaw as soon as I actually start using this release myself...) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.7.0.0
I'm pleased to announce the latest version of my Haskell bindings to the Graphviz [1] suite of tools for visualising graphs. As usual, it is available from Hackage [2]. [1] http://graphviz.org/ [2] http://hackage.haskell.org/package/graphviz Changes in this release include: * Updated and extended functions to interact with the Graphviz tools. This now includes: - a better listing of available output types; - distinguishing file outputs from canvas outputs; - ability to automatically add the correct file extension to file outputs - Return any errors if calling Graphviz failed rather than just printing them to stderr * Improved Color support: - fixed ColorScheme values - explicitly named X11 colors - conversion to/from values from the colour library * Removed OrientationGraph; problems with distinguishing it when parsing from node-based Orientation values; its functionality is duplicated by Rotate. * By default, the generated Dot code is now no longer indented; you can now use the prettyPrint functions in Data.GraphViz to produce readable Dot code. * Added a testsuite; this is buildable by building with --flags=test. Numerous printing and parsing bugs were picked up with this. Plans for the next release: * Determine how to deal with encodings, since Graphviz uses UTF-8 by default; the hSetEncoding function in GHC-6.12 would be ideal, but backwards-incompatible. * Add a generic version of the types in Data.GraphViz.Types that would let people have more fine-grained control over the layout of their graphs by removing the ordering restriction used. Note that this will _not_ be the default, just an option for those that want it. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Graphalyze-0.8.0.0 and SourceGraph-0.5.5.0
To keep Joe Fredette happy [1] this time, I've combined these two announcements into one. [1] http://sequence.complete.org/hwn/20091003 I'm pleased to announce the latest versions of Graphalyze [2] and SourceGraph [3]. The only change to Graphalyze has been the addition of Legend support (which necessitated a slight change in the data structures used, hence the large version bump) but SourceGraph contains more substantial changes. [2] http://hackage.haskell.org/package/Graphalyze-0.8.0.0 [3] http://hackage.haskell.org/package/SourceGraph-0.5.5.0 Changes to SourceGraph include: * A legend so that you know what all the fancy symbols, etc. actually mean. * Class instances now drawn correctly. * Better colour support. * Clean up printing of cliques, etc. I've also put some sample SourceGraph reports online at http://code.haskell.org/~ivanm/Sample_SourceGraph/SampleReports.html so that you can see what kind of results it produces. Enjoy! -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: SourceGraph 0.5.2.0
Yes, this is yet another SourceGraph announcement, this time for version 0.5.2.0 [1]. [1] http://hackage.haskell.org/package/SourceGraph-0.5.2.0 The changes in this release are as follows: * Shift overall analysis to the top and per-module analysis to the end, as suggested by Duncan Coutts. * Graph drawing fixups: instances are now drawn correctly, and the module graph now has modules located in the correct directory. * Improve some graph drawing aspects (node margins, colours for module graphs, etc.). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: SourceGraph 0.5.1.0
This is an updated version of my graph-theoretic static analysis tool for Haskell, SourceGraph. This version is available from http://hackage.haskell.org/package/SourceGraph-0.5.1.0 (now with docs on the Hackage page!). This version provides the ability to pass in a single Haskell source file rather than a Cabal file for analysis purposes. Note that the Cabal version is still preferred as it is better able to determine the project name and which modules are exported: when using a single source file, that file is presumed to be the only exported module and its module name is used as the overall project name. This feature was requested by Curt Sampson. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] ANNOUNCE: SourceGraph-0.5.0.0
Colin Paul Adams writes: Compare the version in the subject to the version you're trying to install... >>>>>> "Ivan" == Ivan Lazar Miljenovic writes: > > Ivan> I'd appreciate it if people could give SourceGraph a whirl > > Fails to install (Linux x86_64): > > Data/Graph/Analysis/Utils.hs:207:43: > Ambiguous occurrence `dotizeGraph' > It could refer to either `Data.Graph.Analysis.Utils.dotizeGraph', defined > at Data/Graph/Analysis/Utils.hs:199:0 > or `Data.GraphViz.dotizeGraph', imported from > Data.GraphViz at Data/Graph/Analysis/Utils.hs:81:0-19 > > Data/Graph/Analysis/Utils.hs:220:18: > Not in scope: data constructor `PointList' > cabal: Error: some packages failed to install: > Graphalyze-0.5 failed during the building phase. The exception was: > exit: ExitFailure 1 > SourceGraph-0.3 depends on Graphalyze-0.5 which failed to install. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] ANNOUNCE: Graphalyze-0.7.0.0
Eugene Kirpichov writes: > Ivan, could you please mention some examples of things you can do with > the library here in the mailing list? I am intrigued by the idea. Couldn't you wait until you read my announcement email for SourceGraph? :p Other ideas I had for this kind of analysis: * Examine the internal structure of a company/department/etc. in terms of the employee hierarchy. * Who-knows-who: analyse address books (whether it's traditional, email, Facebook, etc.); this is related to the six-degree problem. > > 2009/9/29 Ivan Lazar Miljenovic : >> Graphalyze [1] is a library for using graph-theoretic techniques to >> analyse the relationships inherent within discrete data. It was >> originally written for my Honours thesis [2] last year, and I have now >> started updating it. >> >> [1] http://hackage.haskell.org/package/Graphalyze >> [2] >> http://ivanmiljenovic.wordpress.com/2008/11/03/graph-theoretic-analysis-of-relationships-within-discrete-data/ >> >> Graphalyze provides helper functions to import discrete data, analyse it >> using various algorithms (a dodgy term, I know, but I couldn't think of >> a better one) and then create a report with the results. >> >> The main changes since the previous version are: >> >> * The ability to have graphs with edge labels. >> >> * More of a focus on applying changes to the overall information state >> of the data rather than just extracting the graph and applying a >> function to it. >> >> * Usage of the updated features in the graphviz library >> (http://hackage.haskell.org/package/graphviz) to visualise graphs. >> >> Changes to come: >> >> * Re-do the reporting framework to use more of a pretty-printing >> approach and make it more customisable. >> >> -- >> Ivan Lazar Miljenovic >> ivan.miljeno...@gmail.com >> IvanMiljenovic.wordpress.com >> ___ >> Haskell-Cafe mailing list >> haskell-c...@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: SourceGraph-0.5.0.0
SourceGraph [1] is a tool to statically analyse your Haskell code by applying graph-theoretic techniques on the call graph. It utilised the Graphalyze [2] library to do so, both of which were originally written as part of my Honours thesis last year [3]. [1] http://hackage.haskell.org/package/SourceGraph [2] http://hackage.haskell.org/package/Graphalyze [3] http://ivanmiljenovic.wordpress.com/2008/11/03/graph-theoretic-analysis-of-relationships-within-discrete-data/ I have been meaning to update SourceGraph since last year, but was waiting for improvements to the graphviz [4] library first. Now that these are done and I have fewer excuses, I've started to improve upon it. [4] http://hackage.haskell.org/package/graphviz When I first released SourceGraph last year, several people (e.g. Gwern) wanted support for CPP and command-line options. Unfortunately, I haven't yet gotten around to that; what I have done is added support for type classes and data structures, something I originally said I wasn't going to do. This support isn't perfect, especially when dealing with type classes from outside the scope of the code base, but in most cases works (except that the virtual instance functions don't always get positioned in the correct spots for some reason). The produced graphs are now also much prettier, with various colours and shapes being used. The useful features that SourceGraph offers include: * Visualisation of each module, the relations between modules and the entire code base. * Finds functions that are exported from a module that isn't in exposed in the .cabal file. * Alternate module splits. Please note that SourceGraph is _not_ a refactoring tool: it is designed to give you the programmer more information about what is in your code. I'd appreciate it if people could give SourceGraph a whirl and at least check how well the conversion from Haskell code to the graph is, as I'm not that sure how well I've converted haskel-src-ext's [5] internal state to SourceGraph's state. Please note that there are already various aspects that I know don't work properly; these can be found in the ParsingProblems.txt file (KnownProblems.txt contains other non-parsing problems that I'm aware of). In particular, TH, etc. aren't supported. [5] http://hackage.haskell.org/package/haskell-src-exts-1.1.4 To use SourceGraph after it's been installed, at a prompt do the following: > SourceGraph path/to/project.cabal The resulting report will then be found in a directory called "SourceGraph" in the same directory as the cabal file. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Graphalyze-0.7.0.0
Graphalyze [1] is a library for using graph-theoretic techniques to analyse the relationships inherent within discrete data. It was originally written for my Honours thesis [2] last year, and I have now started updating it. [1] http://hackage.haskell.org/package/Graphalyze [2] http://ivanmiljenovic.wordpress.com/2008/11/03/graph-theoretic-analysis-of-relationships-within-discrete-data/ Graphalyze provides helper functions to import discrete data, analyse it using various algorithms (a dodgy term, I know, but I couldn't think of a better one) and then create a report with the results. The main changes since the previous version are: * The ability to have graphs with edge labels. * More of a focus on applying changes to the overall information state of the data rather than just extracting the graph and applying a function to it. * Usage of the updated features in the graphviz library (http://hackage.haskell.org/package/graphviz) to visualise graphs. Changes to come: * Re-do the reporting framework to use more of a pretty-printing approach and make it more customisable. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.6.0.0
I'm pleased to announce version 2999.6.0.0 [1] of the graphviz library, which provides bindings to the GraphViz [2] suite of tools for drawing graphs. [1] http://hackage.haskell.org/package/graphviz-2999.6.0.0 [2] http://www.graphviz.org/ Changes since the previous version are: * Remove some Shape aliases and change capitalisation of others. * Properly parse and print IDs of clusters. * Allow NodeCluster values have node types different from the LNode they come from. Since the node type is only used for passing to the function to create the appropriate Attributes for that node, this can mean avoiding having to apply a transformation function before getting the attributes if you have a composite type for node value/cluster. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.5.1.1
I'm pleased to announce version 2999.5.1.1 [1] of the graphviz library, which provides bindings to the GraphViz [2] suite of tools for drawing graphs. [1] http://hackage.haskell.org/package/graphviz-2999.5.1.1 [2] http://www.graphviz.org/ This is yet another bugfix release, fixing the problem spotted by Kathleen Fisher where Dot keywords need to be explicitly quoted if used as labels, etc. Once again, this is done automagically with no change to the API. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.5.1.0
I'm pleased to announce version 2999.5.1.0 [1] of the graphviz library, which provides bindings to the GraphViz [2] suite of tools for drawing graphs. [1] http://hackage.haskell.org/package/graphviz-2999.5.1.0 [2] http://www.graphviz.org/ This is mainly a bug-fix release; as such, there is no API change (though if you use the graphvizWithHandle function in Data.GraphViz.Commands, you should ensure that your Handle -> IO a function closes the Handle when done). Changes in this release are: * Potentially fixed the graphvizWithHandle bug where warnings would be emitted about Handles not being closed correctly or too early; correct approach spotted by Nikolas Mayr. * Fixed up Parsing of various Attribute sub-values, especially Point and Spline (and hence Pos, which uses them). * Pre-process out comments and join together multi-line strings before parsing. * Properly parse Doubles like ".2". -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.5.0.0
I am pleased to announce version 2999.5.0.0 [1] of the graphviz [2] package for Haskell. This is what I like to think of as the "Hey, this is almost getting to be a decent library!" version :p [1] http://hackage.haskell.org/packages/archive/graphviz/2999.5.0.0/graphviz-2999.5.0.0.tar.gz [2] http://hackage.haskell.org/package/graphviz The graphviz package provides bindings to the GraphViz [3] suite of programs by providing the ability to generate and parse GraphViz's Dot [4] language as well as wrappers around the tools themselves. [3] http://www.graphviz.org/ [4] http://www.graphviz.org/doc/info/lang.html This is an almost complete re-write of the previously released version (2999.1.0.2): I do not mean that this version was re-written from scratch, but substantial portions of the library have been improved or replaced. As such, current users of this library will unfortunately have to update their code that uses it. The major changes (becuase there's probably heaps of smaller changes I've forgotten about) are: * Parsing and printing of Dot code was re-written to use the new ParseDot and PrintDot classes rather than the old Parseable class and the Show class. What this means for the end-user is that quotation problems should finally all be resolved (I hope...). In particular, proper quotation of String values is now done automagically: if it is found that the String to be printed requires quoting (because it does not match the format required for non-quoted String values), then quotes within the String are escaped and the entire String is quoted. As part of this, the Data.GraphViz.ParserCombinators module has been moved to Data.GraphViz.Types.Parsing. * Re-write the various Dot* datatypes in Data.GraphViz.Types. Sub-graphs/clusters are now their own entity rather than being part of DotNode and the Node ID type is now a type parameter rather than being just Int. Sub-graphs/clusters can now also be parsed. DotGraph and DotSubGraph now both contain a "DotStatements" value, which in turn contains global attributes, subgraphs, nodes and edges. * The various conversion functions in Data.GraphViz now come in two flavours: the unprimed versions take in a Bool indicating if the graph is directed or not; the primed versions attempt to automatically detect this. Also add cluster support for the graph -> dot -> graph conversion-style functions, as requested by Nikolas Mayr. * Allow custom arrow types as supported by GraphViz; as requested by Han Joosten. * Fixed a bug in HSV-style Color values where Int was used instead of Double; spotted by Michael deLorimier. * Properly resolved the situation initially spotted by Neil Brown: Matthew Sackman was following Dot terminology for an edge `a -> b' when using "head" for `b' and "tail" for `a' (this is presumably because the head/tail of the arrow are at those nodes). DotEdge now uses "from" and "to" avoid ambiguity; the various Attribute values still follow upstream usage. This should hopefully be the last update that is such an intrusive change. The next release will most likely contain updates on how to specify a particular output to use (including variants), with most of the rest remain as-is. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.1.0.2
This is a bug release that fixes a bug spotted by Srihari Ramanathan where the Dot representation of Color values were double-quoted when they shouldn't have been. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2999.1.0.1
This is a bug-fix release to fix the various Attribute-related problems in the previous release (2999.0.0.0) spotted mainly by Zsolt Dollenstein. Please disregard version 2999.1.0.0; it had a small bug. Similarly, people should avoid using 2999.0.0.0 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 2999.1.0.0 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.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] 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.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: graphviz-2009.5.1
I'd like to announce version 2009.5.1[1] of the graphviz[2] library, less than a week since Matthew Sackman passed maintainership onto me[3]. The graphviz library provides a Haskell interface to the GraphViz[4] program. [1] http://hackage.haskell.org/packages/archive/graphviz/2009.5.1/graphviz-2009.5.1.tar.gz [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/graphviz [3] http://www.mail-archive.com/haskell@haskell.org/msg21994.html [4] http://graphviz.org Major changes with this release are: * Supports polyparse >= 1.1 (the previous version didn't work with 1.3). * Requires base == 4.* (i.e. GHC 6.10.*) due to the new exception handling. * Includes functions from my Graphalyze [5] library for actually running the various GraphViz commands, etc. * Slight API breakages: - dirCommand, undirCommand and commandFor no longer return String, but GraphvizCommand - Data.GraphViz.ParserCombinators is no longer exported by the Cabal file, since I see no need for anyone to require acccess to this. If this is a problem for you, please let me know and I'll re-export it. * A lot more Haddock documentation. * A darcs repository is now available [6]. Patches are welcome! [5] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Graphalyze [6] http://code.haskell.org/graphviz Plans for the future: * Add support for Data.Graph-style graphs (maybe even making it generic such that custom graph types can be used). * Allow the user to choose whether the graph is directed or undirected. * Include all attributes offered by the Dot language. * Remove (or at least minimise) usage of extensions to increase portability. Oh, and to pre-empt Don, this is already available in the Gentoo-Haskell overlay ;-) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Graphalyze-0.5 and SourceGraph-0.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've just submitted my thesis this morning (w00t!!!) and as such I'm announcing the latest versions of Graphalyze [1,2] and SourceGraph [3,4], which fix a couple of bugs in the previous versions (these bugs were fixed whilst waiting for my supervisor to finish reading through my draft, and as such I had to re-write bits of my thesis that talked about the limitations of the software :s ). [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Graphalyze [2] http://code.haskell.org/Graphalyze [3] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SourceGraph [4] http://code.haskell.org/SourceGraph Briefly, SourceGraph is a utility that uses the Graphalyze library to analyse Cabalized Haskell software. Its input/output is rather restrictive at the moment: it takes a single argument, which is the path to a .cabal file, and then produces an HTML report in: /SourceGraph/.html This report contains visualisation of the code for each module, for the imports (similar to what graphmod [5] does) as well as the entire code base. Furthermore, the entire code base is also visualised with functions grouped by the modules they're defined in, as well some simple analyses (such as comparing the export list to what functions are actually roots, similar to the output for top-level functions returned by GHC when using -fwarn-unused-binds). Main changes in Graphalyze since version 0.4: * When writing my thesis, I found some obvious silly mistakes (such as copying the rootsOf function definition to leavesOf, but not changing the function definition). * Images in the document representation are now inline elements. * When using Pandoc [6] for document generation, the size of generated graphs is now customisable on a per-format basis; furthermore, for web pages graph visualisations link to larger versions. Also, graph visualisations can now be created in a sub-directory. Main changes in SourceGraph since version 0.2: * Now uses Cabal 1.6 * Improve visual layout of generated HTML report (still no CSS though). * "Smarter" analysis: don't show trivial analysis results, and when analysing the entire code base don't return cliques, etc. that contain functions all in the same module (as they would have been reported in the per-module section). Note, however, that the parsing limitations for version 0.2 still apply: cpp is still as-yet unsupported (as I'm not sure what I'll do about choosing cpp flags); Template Haskell, HaRP and HXML are still ignored and functions in class declarations/records are still ignored (the former because it's ambiguous which actual function you want, the latter because they're boring :p ). Also, SourceGraph is _still_ not a refactoring tool ;-) If anyone's interested, I'll soon be uploading the final version of my thesis to my blog. Also, if anyone is interested in hacking on any of this, feel free! I'll probably leave it for a while (I'm going to be doing Java coding over summer, blech :s ), but I intend to come back to it later on. - -- Ivan Lazar Miljenovic [EMAIL PROTECTED] IvanMiljenovic.wordpress.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkOcaAACgkQfEfFJ9JhvyjhIwCeM9VXsJeSVK2CdWURJDer6zoA A5YAoIfayHtjpw0qt/gyPZhhhypOwzSh =x+/X -END PGP SIGNATURE- ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Graphalyze-0.4 and SourceGraph-0.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 12 Oct 2008 20:01:32 -0400 Gwern Branwen <[EMAIL PROTECTED]> wrote:> > 'K. So SourceGraph doesn't do any error reporting? I'll keep that in mind. In this case, it isn't SourceGraph's fault: Haskell-Src-Exts can't parse it. Maybe it doesn't parse CPP stuff properly? I'm not sure how I can get SourceGraph to parse files only after they've been pre-processed... The other option is that, once I've read the file and before I try parsing it, I do a bit of manual pre-processing of my own and simply filter out all lines that start with a '#' (i.e. remove all CPP annotations). The possible problem that I can think with this is that if there are two versions of a function foo defined within an #ifdef block, then that function will be listed twice (using nub might fix this but I'm not sure), or else if a function is optionally defined because you're not importing something (as appears to be the case with Gwern's XSelection module), then you have the situation where it's not possible to tell if it's using the external or internal one. - - -- Ivan Lazar Miljenovic [EMAIL PROTECTED] IvanMiljenovic.wordpress.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjy9FoACgkQfEfFJ9Jhvyie+QCeOYA3MFoi41M+9PRC7F0KXPWL 3+0An2TsyRv26EO8a5AbdOGALzqHpYpD =/COZ -END PGP SIGNATURE- ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] ANNOUNCE: Graphalyze-0.4 and SourceGraph-0.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, 12 Oct 2008 13:24:40 -0400 Gwern Branwen <[EMAIL PROTECTED]> wrote: > > However, I happened to want to look at the output for one of my modules, > XMonad.Util.XSelection - and it simply isn't there. Most of the XMC modules > seem to be there, but that one isn't. It's in the cabal file, SourceGraph did > not output any errors or warnings, but XSelection is not mentioned in the > HTML output nor are any PNGs generated with regard to it. See: H. that means that SourceGraph isn't able to parse it and dies silently. I'll have a look at myself later and try to find out why. - -- Ivan Lazar Miljenovic [EMAIL PROTECTED] IvanMiljenovic.wordpress.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjygdoACgkQfEfFJ9JhvyigPACfejpPr5vYnSOxCFg6DQTfnk2U cpIAnAhh7fzI9OtzPAXYxPpDg66UZzeD =upq7 -END PGP SIGNATURE- ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Graphalyze-0.4 and SourceGraph-0.2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'd like to announce version 0.4 of my Graphalyze library [1] and 0.2 of my
SourceGraph programme [2].
[1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Graphalyze
[2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/SourceGraph
This should fix the bugs reported by Gwern Branwen, Magnus Therning (thanks to
Niklas Broberg for stating the correct version for Haskell-Src-Exts) and
Christopher Hinson. No really new features are included in this release. I
was planning on fixing this and releasing it sooner but - to utilise what seems
to be a current meme [3] - "I accidentally my Gentoo" on Tuesday night and only
fixed it yesterday.
[3] http://encyclopediadramatica.com/I_accidentally_X
Since I'm more awake now than I was when I made the initial release, here's a
run-down of what SourceGraph is:
SourceGraph is a programme designed to help you analyse the static complexity
of your Haskell code when represented as a graph. At the moment, it does the
following (M == for each module, I = for imports, C = the whole codebase):
* Visualise it {M,I,C}
* See a "collapsed" visualisation {M}
* Proposed module/directory layout using two different algorithms {I,C}
* See the "core" visualisation (recursively strip off roots/leaves) {M}
* Calculate the Cyclomatic complexity [4] {M,I,C}
* Root analysis (compare what's exported to what actually is a root) {M,I,C}
* Determine how many components you have, to see if you should split {M,I,C}
* Clique Analysis (find co-recursive functions) {M,C}
* Cycle analysis (non-cliques) {M,I,C}
* Chain detection (e.g. "straight-line" functions/imports) {M,I,C}
[4] http://en.wikipedia.org/wiki/Cyclomatic_complexity
Current limitations:
* An automatic refactoring tool: SourceGraph gives *you* information on how you
might want to possibly refactor your code. It's not smart: it can't tell
that you've clumped functions foo and bar in the same module because they do
similar things or because it's a utility module, even though they're not
related. For automatic refactoring, see something like HaRe [5].
* SourceGraph ignore's "data-based" functions, i.e. record-functions and
class/instance declarations, as it's too confusing (IMHO) which actual
function you mean (if you see "show" being called, is it for Int, Double, or
something else?).
* Despite using Haskell-Src-Exts, some extensions (e.g. TH) are ignored, mainly
because I have no idea how they work and nothing to test it on. GHC
extensions should be supported (read the parser won't choke on them) though.
* Reporting output is currently rather limited:
- The report will be generated in a subdirectory called "SourceGraph" of the
codebase directory; this is currently hardwired in.
- It will produce an all-in-one html file report, with no fancy CSS magic to
make it look pretty. Ideally, it would produce a split-file, and allow you
to choose output format.
- Large graphs are shrunk down to being a maximum of 15"x10". Ideally, I'd
like to extend this later so that large graphs will have a shrunk version
in the graph, which link to a larger version (note though that these graphs
get very large very fast).
- The output of individual function names, etc. could be improved.
[5] http://www.cs.kent.ac.uk/projects/refactor-fp/hare.html
SourceGraph can be installed with cabal-install. Once you've done so, you can
analyse a cabalized library/application Foo as follows:
$ SourceGraph /path/to/codebase/Foo.cabal
Report generated at: /path/to/codebase/SourceGraph/Foo.html
This has been written as part of my mathematics Honours Thesis,
"Graph-Theoretic Analysis of the Relationships in Discrete Data". Since I've
actually got to write the thesis up now, I won't be making any more releases
for a while. After uni is over for the semester though, I hope to tidy it up
and extend it.
If you want to check the code out yourselves, there's also darcs repositories
for Graphalyze [6] and SourceGraph [7].
[6] http://code.haskell.org/Graphalyze
[7] http://code.haskell.org/SourceGraph/
Note that whilst Graphalyze is fully documented, etc., the internals of
SourceGraph are a bit fugly (mainly due to time constraints).
Enjoy!
- --
Ivan Lazar Miljenovic
[EMAIL PROTECTED]
IvanMiljenovic.wordpress.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkjyAacACgkQfEfFJ9JhvyiHEACfVVuRk2FR3ZQiJ6H18FFK/de/
sukAn0tuCLwqxmzlQvWicQKQ3qEJKC1K
=HRUK
-END PGP SIGNATURE-
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: [Haskell-cafe] ANNOUNCE: graphviz-2008.9.20
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, 20 Sep 2008 23:38:16 -0700 Don Stewart <[EMAIL PROTECTED]> wrote: > > And by now you know where which distro has it: > > http://aur.archlinux.org/packages.php?ID=18343 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 [EMAIL PROTECTED] IvanMiljenovic.wordpress.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjV7aAACgkQfEfFJ9Jhvyjj1gCfakJfsQX6g8FTc4kY2jDBogVl v/EAn31XYRa98GVY7Nz1G+cfOZ8tegJz =iDT/ -END PGP SIGNATURE- ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
