- Haskell-Cafe - Haskell.org

FFI problem - possibility of CStringLen overflow?
by Robin Green 20 Jul '09

20 Jul '09

While rewriting cautious-file to use ByteStrings and FFI just now, I came across this potential problem: Why does the FFI specification define CStringLen as (Ptr CChar, Int)? As the FFI specification itself notes, Haskell 98 implementors are allowed to have a quite small range for Int (only up to 2^29-1) - so you could in principle have a very large String which cannot be represented as a CStringLen, or a very large CString which cannot be represented as a CStringLen. They would take up wads of memory, so this has probably never happened yet, but it's in principle possible, no? If so, what are the implications of this for code correctness? -- Robin

3 2

ANNOUNCE: graphviz-2999.1.0.1
by Ivan Lazar Miljenovic 20 Jul '09

20 Jul '09

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.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

1 0

Typeclass default implementation in subclasses
by Andy Gimblett 20 Jul '09

20 Jul '09

Hi all, This email is literate Haskell. I have a question about default implementations of typeclasses. > {-# LANGUAGE TypeSynonymInstances #-} > module Thing where > import Text.PrettyPrint.HughesPJ Let say I want to pretty-print some values, enclosed in double quotes. The natural thing to do (within the HughesPJ pretty-printing framework, anyway - and that's where I am in this problem's wider context) is: > ppQuote :: Show a => a -> Doc > ppQuote = doubleQuotes . text . show Now, this works nicely for (say) Int: > x :: Int > x = 1 *Thing> ppQuote x "1" But less nicely for String and Char, because their Show instances already insert double/single quotes respectively: > y :: String > y = "hello" > z :: Char > z = 'a' *Thing> ppQuote y ""hello"" *Thing> ppQuote z "'a'" I don't want this. I'd like them to be "hello" and "a" respectively. So I thought I'd create a typeclass, whose default implementation is as above... > class (Show a) => Quotable a where > quote :: a -> Doc > quote = ppQuote ... but with specialised instances for String and Char (the former seems to need the TypeSynonymInstances extension?): > instance Quotable String where > quote = text . show -- don't need the doubleQuotes call for String > instance Quotable Char where > quote c = quote [c] -- just lift it to String Unfortunately, while this works great for String and Char... *Thing> quote y "hello" *Thing> quote z "a" ... the "default implementation" mechanism doesn't work as I'd expect/hope: *Thing> quote x <interactive>:1:0: No instance for (Quotable Int) arising from a use of `quote' at <interactive>:1:0-6 Possible fix: add an instance declaration for (Quotable Int) In the expression: quote x In the definition of `it': it = quote x What I would _like_ would be for the compiler to say "OK, the Quotable class depends on the Show class, and Int is an instance of Show so Int is also an instance of Quotable, having the default implementation (since there isn't a specialised one for it)" - but clearly it doesn't. Please can someone tell me why this doesn't happen, and if there is a way of making it happen? Also, if there's a more sensible way of attacking this whole problem, I'd be curious to hear it. I should perhaps add that this isn't a huge problem for me, because my instances will in practice tend to be String and Char anyway, and one can of course add Quotable instances for anything else easily enough - but I'm curious now I've come this far. :-) Many thanks! -Andy

2 1

SpecConstr difficulties
by Reiner Pope 20 Jul '09

20 Jul '09

Hi everyone, I've been having some trouble getting SpecConstr to work as I want it to. The following example (see end of email) came up in some code I was playing around with. The loops g1 and g2 both compute the same thing: the maximum element of the "list" (which has been fused away) of numbers from 1 to 10. Since 'maximum' is a foldl1 not a foldl, I use a strict Maybe type as an accumulator. The Maybe gets filled after the first element is seen, so the Maybe is a Just for almost the entire running of the loop. It would be good to have this recognised by SpecConstr, to create an optimised loop for the Just case. This does indeed happen for g1, but not for g2. My difficulty is that I am only able to produce code similar to g2, i.e. where the pattern matching is in a separate function, 'expose', because the 'expose' function is implemented in a type-class, like in stream-fusion. Is there some way to keep the SpecConstr while leaving the 'expose' as a separate function? Here is the code: > {-# LANGUAGE BangPatterns #-} > > module Test(ans1,ans2) where > > import Prelude hiding(Maybe(..)) > > data Maybe a = Just !a | Nothing > > Nothing `mapp` Just b = Just b > Just a `mapp` Just b = Just (max a b) > > ans1 = g1 Nothing (0::Int) > > g1 m !n = case m of > Nothing -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) > Just x -> if n > 10 then m else g1 (m `mapp` Just n) (n+1) > > ans2 = g2 Nothing (0::Int) > > g2 m !n = expose m (if n > 10 then m else g2 (m `mapp` Just n) (n+1)) > expose Nothing b = b > expose (Just a) b = a `seq` b On a similar note, when I was having difficulties with this problem, I started to wonder if it would be possible to come up with a more direct way to tell GHC, "do SpecConstr on this variable". From reading the source code of the stream-fusion package, it seems that the current way of doing this is with 'expose' functions like I wrote below. Could we instead have a {-# SPECCONSTR #-} pragma, to be used on function arguments, like: foo {-# SPECCONSTR #-} x y {-# SPECCONSTR #-} z = ... This pragma should say to the GHC something like "ignore conditions H2, H5 and H6 of the SpecConstr paper, for this function and this argument". Cheers, Reiner

1 0

ICFP contest write-up
by Rafael Gustavo da Cunha Pereira Pinto 20 Jul '09

20 Jul '09

For all Portuguese reading haskellers, I am describing my ICFP 2009 contest write-up on my blog. Feel free to comment. http://rafaelgcpp.blogspot.com/search/label/ICFP2009 For the non-Portuguese readers, Google translation tools do a lousy job, but it is still readable. Regards Rafael Gustavo da Cunha Pereira Pinto

1 0

ANN: cautious-file 0.1.1: Ways to write a file cautiously, to avoid data loss
by Robin Green 20 Jul '09

20 Jul '09

I'm pleased to announce the first public release of cautious-file: http://hackage.haskell.org/package/cautious-file This library currently provides a writeFile function that is intended to have three advantages over Prelude.writeFile: 1. There was a controversy a few months ago about the new Linux filesystem ext4, and how existing applications which write certain files naively might expose their users to the risk of data loss after a crash or power failure. (Actually, it turns out that this is not a new issue - certain other filesystems or filesystem mount options can cause similar issues, but few people made a fuss about it.) cautious-file uses the recommended way of writing a file on POSIX (more or less). On non-POSIX systems (i.e. Windows), it tries to do something sensible, but it may not be the best way to do it, and I've only ran the tests on Linux. 2. With almost any filesystem or operating system, saving a file by overwriting it exposes the user to the risk of data loss if there is a crash or power failure. cautious-file creates a temporary file first and only overwrites the file when it has finished writing (on POSIX systems with sane filesystems, at least). 3. Prelude.writeFile is supposed to lock files so that they at least cannot be written to simultaneously in multiple threads. This is good for safety, but might lead to avoidable problems with IO exceptions when one thread tries to open a file for writing which is still being written to by another thread. Again, the use of a randomly-named temporary file avoids this problem (not with certainty, but with a high probability, which is good enough for some applications). It does not prevent all file-related race conditions (nothing with its type signature could!), but if you are sure you don't care which thread wins, you should be able to use cautious-file's writeFile. A variant, writeFileWithBackup, also allows you to supply a custom backup computation to backup old copy(ies) of the destination file (which is not necessary with Prelude.writeFile, because you can just do it before you call Prelude.writeFile, but is necessary with cautious-file). cautious-file is obviously not appropriate for all circumstances - for instance, it's not needed for writing truly temporary files. But of course if it's close to what you need, you can adapt it (and send me a patch if you like). There is a test runner that can be run by running "runhaskell Setup.lhs test" or "cabal test" in a built copy of the source distribution. The tests do not actually verify that data loss doesn't happen if there's a crash! Indeed, attention should be drawn to the standard BSD license - despite the name "cautious-file", there is no warranty. If in doubt, I suggest you take a close look at the source code - it's very short. I'd appreciate comments, patches, pointers to Haskell code that does the same thing already, etc. Thanks, -- Robin

2 2

was: Debugging methods for haskell structured data types the right way in haskell
by Fernan Bolando 20 Jul '09

20 Jul '09

On Sun, Jul 19, 2009 at 7:40 AM, wren ng thornton<wren(a)freegeek.org> wrote: > Fernan Bolando wrote: >> >> The intention is z0 is a system parameter and database, it contains a >> set of info needed to define a particular simulation >> >> it looks like ( [n,m...], [m,o,p]) >> >> n is is a list info settings for the circuit analysis >> m is a list of statistics for the circuits that is need in sub-sequent >> calculation >> m is a list of circuit settings like temperature etc. >> o is a list of matrix solution for non-linear newton raphson >> p is a list of matrix solution for time dependent calculations > > > This would be better as, > > > data SystemParameterDatabase = SystemParameterDatabase > { infoSettings :: InfoSettings > , statistics :: Statistics > , settings :: Settings > , nlnr :: [Matrix Double] > , timeDependent :: [Matrix Double] > } > > data InfoSettings = InfoSettings > { pMSET :: MSET > , aSetting :: A > , bSetting :: B > ... > } > > data Statistics = Statistics > { aStatistic :: A > , anotherStatistic :: A > , bStatistic :: B > ... > } > > data Settings = Settings > { temperature :: Kelvin > , etc :: Etc > } > ... > > > A single-constructor ADT, especially with the labeled-fields syntax, is > pretty close to C structs; no need to reinvent them and give yourself > headaches. > > > Really, the only thing you should be using lists for is a variable-length > sequence of elements drawn from the same type and distinguished only by > their position in the sequence. Whenever the length is fixed or the > (semantic) type of elements can be distinguished from one another (or > altered by pushing/popping the list), then a list is not what you want to be > using because it doesn't capture the intention of the type (and therefore > allows unintelligible values of the type, and inappropriate transformations > on the type). > > -- > Live well, > ~wren This is the kind of code recommendations I was looking. thanks -- http://www.fernski.com

2 1

Problem resizing widget contained in window
by Jeff Heard 20 Jul '09

20 Jul '09

I created a window, like so: Gtk.windowSetTitle win name Gtk.widgetSetName win "Hieroglyph" Gtk.onDestroy win (exitWith ExitSuccess) Gtk.windowSetDefaultSize win w h Gtk.containerResizeChildren win And an GLDrawingArea like so: config ← Gtk.glConfigNew [Gtk.GLModeRGBA, Gtk.GLModeMultiSample, Gtk.GLModeDouble, Gtk.GLModeDepth, Gtk.GLModeAlpha] area ← Gtk.glDrawingAreaNew config Gtk.onRealize area ◊ GL.drawBuffer $= GL.BackBuffers Gtk.onExpose area (λ_ → renderOnExpose bus ≫ return True) and finally show it like this: Gtk.containerAdd win area Gtk.widgetShowAll win Now, if someone resizes the window, the GLArea does not appear to resize along with it. Did I screw something up? -- Jeff

2 1

ANNOUNCE: graphviz-2999.0.0.0
by Ivan Lazar Miljenovic 20 Jul '09

20 Jul '09

I am pleased to announce a new release of the graphviz package for Haskell, which provides bindings to the GraphViz [1] suite of tools. [1] http://www.graphviz.org/ Probably the biggest and most important change in this release is that AFAICT, all 152 attributes utilised/supported by GraphViz [2] are now specified and supported by this library. However, I'm not fully sure how well the parsing of these attributes will turn out; if you notice a bug/problem then please let me know. [2] http://graphviz.org/doc/info/attrs.html I've specified this as being the first in the 2999.0 series of releases. I will switch to 3000.0 when the generic graph class has been released and graphviz switched to using it rather than just FGL. One other future change that I'm considering is to improve the parsing ability of the Dot language. At the moment, graphviz assumes the following layout is followed: * Graph attributes * Nodes with their attributes (clusters are supported only for creation, not parsing). * Edges with their attributes. To match the behaviour of upstream, this will need to be changed into just a list of statements, where a statement is one of five things [3]: * A Node * An Edge * An attribute (either for the graph overall, nodes or for edges) * "ID '=' ID" (not quite sure what this is; some kind of assignment) * A subgraph (clusters are a specific type of subraph) As the way of defining an attribute for a specific grouping of nodes/edges/subgraphs is to have them all listed after the attribute definition (whereas those beforehand do not have this attribute), the imperative nature of the Dot language does not allow us to split these statements up as we currently do. [3] http://graphviz.org/doc/info/lang.html As such, I'm asking which of the following two choices people would prefer: 1. Follow upstream so that it can fully parse a Dot graph 2. Keep it as it is, so that it is possible to consider all edges, etc. easily. Other major changes to this release: ==================================== * Fixed a bug where the Show instance and read function for DotEdge had the from/to nodes the wrong way round. This was not immediately noticed since the Graph -> DotGraph functions created them the wrong way round, so for those users who only used these this was not apparent. Spotted by Neil Brown. * Greatly improved Attribute usage: almost all attributes are now covered with allowed values. * Extend DotGraph to include whether a graph is strict or not and if it has an ID. Also move the directedGraph field. * Make "Dot" refer to the actual dot command and DotArrow refer to the ArrowType (rather than DotCmd and Dot as before). * Make the Data.GraphViz.ParserCombinators module available to end users again, but not re-exported by Data.GraphViz; it has a warning message up the top not to be used. It is there purely for documentative purposes. * Use extensible-exceptions so that base < 4 is once again supported. * Follow the PVP rather than using dates for versions: http://www.haskell.org/haskellwiki/Package_versioning_policy Note that this means that any library/application using more than a trivial sub-set of graphviz will most likely need to be updated. However, now that the PVP is being followed it should be easier to tell in future when updates will be required. Other items I'm wanting to do in future releases: ================================================= * Allow user to choose whether or not the graph is meant to be directed or undirected. * Improve parsing to fully (or at least follow more closely) support Dot. * Improve clustering/subgraph support. * Use a PrettyPrinter rather than Show to generate Dot output. * Improve Output support. * Find and fix the handle closing bug with graphvizWithHandle. -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com

4 4

ANN: AC-Vector, AC-Colour and AC-EasyRaster-GTK
by roconnor＠theorem.ca 19 Jul '09

19 Jul '09

> Max Rabkin wrote: >> On Sat, Jul 4, 2009 at 8:38 PM, Andrew >> Coppin<andrewcoppin at btinternet.com> wrote: >> >>> A few reasons: >>> >>> 1. I never knew it existed. ;-) >>> >> >> A good reason. However, it's good to do a quick search over Hackage >> before uploading (or before writing) so you know what's out there. >> >> Also, if you hadn't used an "AC-" prefix, you'd have had a name >> collision. Is there a particular reason why you want your name in the >> package name rather than just the author field? >> I find it amazing that you independently chose to spell colour with a `u'. It makes me feel better about my choice. >>> 2. It's mind-blowingly complex. >>> >> >> Colour *is* complex. Which is why I'm so glad Russell O'Connor did all >> the hard work for me :) >> > > Well, no, because now I'm going to have to spend a few hours trying to > find out what CIE is before I can even use that library. > > I think really it's just aimed at a different problem. It looks like > it's trying to specify actual real-world colours. [It's news to me that > this isn't fundamentally impossible...] I'm only trying to specify > colours on a computer screen. And as we all know, computer screens > aren't calibrated in any way, and the same RGB value looks different on > each display. But then, I'm only trying to write a fractal generator, so > CIE specifications are somewhat overkill here. ;-) You can use by lib without worrying about the CIE. You can use my library without ever importing or using the word CIE. However, the CIE stuff is there for those who need it. Perhaps I (maybe with some help) need to make a tutorial on the haskell wiki to try to make it less intimidating. >>> 3. It doesn't appear to provide arithmetic over colours. >>> >> >> It provides darken, blend and addition (though addition is called >> mappend rather than (+)). signum, abs and fromInteger don't make a >> huge amount of sense for colours. >> > > Yeah, I implemented signum and so forth for colours and vectors, but > they're not particularly meaningful... [Insert remark here about > Haskell's numeric class hierachy.] > > So mappend gives you colour addition [with the perplexing comments about > "gamut", presumably some kind of small mammal?], but there's no > subtraction? No multiplication? No linear blending? Linear blending is done by the affineCombo function. I think the darken function will do what you mean by multiplication Colour subtraction can be done by adding (using mappend) a colour that has been darkend by a factor of (-1). I don't believe there is any demand for a colour subtraction fuction, so I don't have a name for it. I suppose these sorts of questions can be put nicely into a short tutorial on the wiki. >>> 4. It's parameterised over the component type; my library is hard-coded > to >>> specific types for speed. >>> >> >> My feeling would be to trust the specializer until it lets me down. >> Has it let you down in the past? >> > > Heh, my colour library includes a custom floor implementation that talks > to the GHC primops directly because calling floor is too slow... > > [In case that sounds like idle talk, I had a program go from 10 seconds > to less than 1 second just by using this function. There's a few tickets > about it on the GHC Trac.] Certainly speed is an issue that I haven't tackled yet since I don't know too much about how to optimized Haskell code. I was thinking of sprinkling in some SPECIALIZE pragmas and maybe adding some RULES to make operations more effecient. For example we could have a rule to rewrite floor to some sort of GHC specific fast floor function. (Although that rule probably deserves to be in some sort of more general location). Any help in this direction would be appricated (perferably while keeping things as portable as possible). This all being said, the major problem my code solves is doing blending in a linear colour space. This necessarily make converting to non-linear sRGB for output much slower. So for people who want speed over proper blending, then probably AC-Colour is the package they need to reach for. Essentially the two packages do fill different niches! >> BTW, the EasyRaster package looks useful. >> I haven't looked at EasyRaster yet, but I got excited when I saw it announced. :) -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

10 18