Re: [Haskell-cafe] darcs patch dependencies in dot format
On 05/13/2012 03:13 AM, Felipe Almeida Lessa wrote: Truly amazing! I wonder it would fare with larger repositories. =) It does not scale well. I have not looked into optimization at all. For example the algorithm to compute the transitive reduction is very naive and brute force. Somehow related questions are: What am I going to do with a dot-graph, that has more than 500 vertices? Is there an intelligent way to reduce the graph? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] darcs patch dependencies in dot format
On 13/05/12 14:55, Sönke Hahn wrote: Somehow related questions are: What am I going to do with a dot-graph, that has more than 500 vertices? Is there an intelligent way to reduce the graph? Setting the `concentrate' parameter to true helps, but dot does not work well with massive graphs. Francesco. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] darcs patch dependencies in dot format
On 13/05/12 15:13, Francesco Mazzoli wrote: On 13/05/12 14:55, Sönke Hahn wrote: Somehow related questions are: What am I going to do with a dot-graph, that has more than 500 vertices? Is there an intelligent way to reduce the graph? Setting the `concentrate' parameter to true helps, but dot does not work well with massive graphs. Actually, neato doesn't work well with massive graph - and neither do the other algorithms provided by GraphViz. dot is just the file format. I found Gephi (https://gephi.org/) quite good when I had to visualize big graphs, and it supports dot files so you can try it out easily. Francesco. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bug in SYB, SYB-documentation or GHC-API (or I messed up somewhere)
Hi Philip, On Fri, May 11, 2012 at 5:12 PM, Philip K. F. Hölzenspies p...@st-andrews.ac.uk wrote: However, it turns out that this never leads to an evaluation of extTyNamesLoc. I've come as far as to see that, since Located a is a synonym for GenLocated SrcSpan a, the type we're looking for really has a binary constructor, thus we should use ext2Q. This made things work: We first modify the function we apply to Located things: extTyNamesLoc :: (Data loc, Data a) = SrcSpan - GenLocated loc a - OccurrenceTable extTyNamesLoc l (L l' x) = case cast l' of Just l'' - extTyNames l'' x Nothing - extTyNames l x Do you really need this? Can't you use the definition of `extTyNamesLoc` shown previously, and redefine `extTyNames` to use `ext2Q`, as in: extTyNames l x = (extTyNamesDef l x `mkQ` extTyNamesTy l `ext2Q` extTyNamesLoc l) x ? Cheers, Pedro ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
