March 2008 - Libraries

There are too many error handling conventions used in library code!
by dons＠cse.unsw.edu.au 13 Aug '11

13 Aug '11

This article on the 8 different error handling strategies various common Haskell libs use: http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways-to-report-err… got me thinking: we need to standardise/recommend a small set of methods for library error handling. The lack of consistent error reporting between libs results in verbose code, as we're not able to use a single error handling technique when gluing together code from different libs (i.e. we can't just use Maybe or Either/ErrorT). (It's always nice when you *can* use, say, a Maybe monad to glue code from a number of sources, but eventually you reach code with a different error system, and the Maybe monad breaks down). So, some questions I think we can tackle: * can we identify error handling strategies from the list that should not be used anymore? (throwDyn?) * can we move some of the outlying libraries to a more consistent error framework? * do we need more support for gluing together our different error systems? (it should be easier to glue code using , say, Maybe/Either). * what role does MonadError play here, as a generic error handler? * can we make precise recommendations about which error strategies to use? -- Don

11 16

Arrow without `>>>'
by Valery V. Vorotyntsev 03 Sep '08

03 Sep '08

Hi, friends, I've built GHC from darcs, and... Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' method? 1. http://darcs.haskell.org/packages/base/Control/Arrow.hs $ ghci GHCi, version 6.9.20080104: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m + Control.Arrow Prelude Control.Arrow> :i Arrow class (Control.Category.Category a) => Arrow a where arr :: (b -> c) -> a b c pure :: (b -> c) -> a b c first :: a b c -> a (b, d) (c, d) second :: a b c -> a (d, b) (d, c) (***) :: a b c -> a b' c' -> a (b, b') (c, c') (&&&) :: a b c -> a b c' -> a b (c, c') -- Defined in Control.Arrow instance Arrow (->) -- Defined in Control.Arrow instance (Monad m) => Arrow (Kleisli m) -- Defined in Control.Arrow Prelude Control.Arrow> Leaving GHCi. I can't build[2] arrows-0.3 package without `>>>' in Arrow. 2. vvv@fun:~/src/arrows$ darcs w { hunk ./Control/Arrow/Operations.hs 36 +import Control.Category ((>>>)) hunk ./Control/Arrow/Transformer/CoState.hs 23 +import Control.Category ((>>>)) } vvv@fun:~/src/arrows$ runhaskell Setup build Preprocessing library arrows-0.3... Building arrows-0.3... [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:29:7: `>>>' is not a (visible) method of class `Arrow' The question arises "should I?", but this is one of lambdabot's[3] depencies. 3. http://code.haskell.org/lambdabot/ Thanks a lot! -- vvv

4 5

building a helper binary with cabal
by Evan Martin 18 May '08

18 May '08

[resent after subscribing to the list] I'm working on a package that requires building a helper binary as part of its install process. This binary is written in C (with good reason), and on a Debian system would be installed into a path like /usr/lib/myproject/mybinary, because it's only used internally by the main program binary. My setup is up to this point: > gccProgram :: Program > gccProgram = simpleProgram "gcc" > type BuildHook = PackageDescription -> LocalBuildInfo > -> UserHooks -> BuildFlags -> IO () > creplChildBuild :: BuildHook -> BuildHook > creplChildBuild oldhook desc buildinfo hooks flags = do > oldhook desc buildinfo hooks flags > rawSystemProgramConf (buildVerbose flags) gccProgram (buildPrograms flags) > ["child.c", "-o", buildDir buildinfo </> "child", "-ldl"] > buildHooks = simpleUserHooks { > hookedPrograms = [gccProgram], > buildHook = creplChildBuild (buildHook simpleUserHooks) > } > main = defaultMainWithHooks buildHooks However, it's unclear to me how to set up the install rule that would copy that binary into the appropriate place. Any tips? It seems I want to grab the "install" hook, but from there how do I specify where to install the file? There seem to be no helper functions to facilitate installing. (I appreciate that all of this is pretty new. So if it's not possible for me to do what I want, take it as an example of the sort of thing I'd like for Cabal to support...)

2 8

QuickCheck properties for IntSet
by David Benbennick 02 May '08

02 May '08

Here's a patch to IntSet.hs that adds many QuickCheck properties. It adds properties testing almost all of the public interface of IntSet, and also properties testing that the data type invariants are never broken. (The patch doesn't test the Data, Eq, Monoid, Read, or Typeable instances.) Also, this patch removes a helper function, foldlStrict, and replaces it with calls to Data.List.foldl'. I have two questions: 1) Is this the right way to submit patches? 2) Is there a good reason that IntSet doesn't use "deriving Eq", and instead manually implements the Eq instance?

5 21

Re: Takusen. PostrgeSQL inserts - are they possible ?
by Alistair Bayley 31 Mar '08

31 Mar '08

> execCommand db "INSERT INTO dmlTest.t (realVal, dblVal) VALUES (?,?)" > [newBindVal (10.1::Float), newBindVal (1023.6::Double)] > > or something like: > > dmlStatement = "INSERT INTO dmlTest.t (realVal, dblVal) VALUES (?,?)" > bindTypes = [bindType (undefined::Float), bindType (undefined::Double)] > bindParams = [bindP (10.1::Float), bindP (1023::Double)] > in > withPreparedStatement (prepareCommand "test" (sql dmlStatement) > bindTypes) $ \pstmt -> > withBoundStatement pstmt bindParams $ \bstmt -> execDML bstmt > > lead to the "Segmentation fault/access violation in generated code" crash. You are right; there are gaps in the docs for the DML operations. However, there is a note in the first section ("Usage"): - for a DML command with bind variables: cmdbind "insert into ..." [bindP ..., bindP ...] e.g. cmdbind "INSERT INTO dmlTest.t (realVal, dblVal) VALUES (?,?)" [ bindP (10.1::Float), bindP (1023::Double)] Let me know if this works for you or not. If you want to use the withPreparedStatement+withBoundStatement combo, then you need to be aware that the bound statement has already been executed when it is passed to the action that is the last argument of withBoundStatement (this seems to be a significant omission from the docs). So, you don't need to do execDML bstmt; a return () should suffice. Alistair

1 0

Character escape codes in Parsec
by Tim Chevalier 31 Mar '08

31 Mar '08

Hi all, I'm using the version of Text.ParserCombinators.Parsec.Token that ships with GHC 6.8.2. I'm trying to use the stringLiteral parser that makeTokenParser uses by default to parse strings that may contain hex ASCII escape codes of the form: \x [hex-digit] [hex-digit] For example, "\x0a" should parse to "\n". On the other hand, "\x0aE" should parse to "\nE". I don't get this behavior with Parsec, though: "\x0aE" parses to "\174". I can tell from looking at the source that a hex escape code is defined to be "\x" followed by an arbitrary-length sequence of hex digits. I think this is wrong, because in ASCII, such an escape sequence has exactly two digits. I can't exactly tell from looking at the source, but is the default token parser in Parsec supposed to be parsing ASCII strings? If so, isn't this a bug in Parsec? If not, and it's meant to be able to handle Unicode or something, I think the documentation should be clearer. I'd much welcome any enlightenment. Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "and the things I'm working on are invisible to everyone"--Meg Hutchinson

2 3

[hackagedb] plugins-1.1 FTBFS
by Valery V. Vorotyntsev 31 Mar '08

31 Mar '08

Hi, `plugins-1.1.tar.gz', available at HackageDB page[1], fails to configure. The darcs version[2] installs successfully. 1. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/plugins 2. http://code.haskell.org/~dons/code/hs-plugins What can we do to fix .tar.gz source distribution? -- vvv

2 2

ANNOUNCE: Cabal-1.4 release candidate
by Duncan Coutts 30 Mar '08

30 Mar '08

Hi everyone, == Cabal-1.4 release candidate == The first release candidate of Cabal-1.4 is out: http://haskell.org/cabal/release/cabal-1.3.10/Cabal-1.3.10.tar.gz Please test and report bugs: http://hackage.haskell.org/trac/hackage/ The aim for the Cabal-1.4 release is to get various fixes and improvements into the hands of developers and to support a release of cabal-install. == cabal-install == A snapshot of cabal-install is available: http://haskell.org/cabal/release/cabal-install-0.4.6.tar.gz It requires the zlib and HTTP packages (both are available from hackage). Bug reports should go in the same trac as above. cabal-install is intended to be the standard command line interface to the whole Cabal/Hackage system. It replaces the "runhaskell Setup.hs" interface and a few other tools you may or may not have heard of (cabal-setup, cabal-upload, cabal-get). cabal-install is usable now and we will be making a proper release some time after the Cabal-1.4 release. == Compatibility == We have tried to preserve compatibility with all packages that worked with the Cabal-1.2.x series. That is, packages that can be built using Cabal (including custom Setup.hs scripts) but not packages that directly import and use the Cabal API. Packages that directly import and use the Cabal api will need updating. This affects packages that build distro packages for example, rpm debs etc. Currently we know of three packages on hackage where their Setup.hs scripts compile with 1.2 but fail to compile with 1.4. We expect to make one further change before the Cabal-1.4 release that will fix two of those packages. The one remaining package, Takusen, will require an update to be able to work with both Cabal-1.2.x and 1.4.x. A patch has been sent to the maintainers of Takusen. == Remaining issues == There are a couple issues we expect to fix before the Cabal-1.4.0 release: * stricter decoding of UTF-8 in .cabal files (we'll borrow the code from the utf8-string package) * compatibility with the couple Setup.hs scripts that use the function Distribution.PackageDescription.writeHookedBuildInfo There are also a few bug fixes and enhancements we think we can probably do in the 1.4.x stable series without breaking any APIs: http://hackage.haskell.org/trac/hackage/query?status=new&status=assigned& status=reopened&group=component&milestone=Cabal-1.4&order=priority == Credits == On behalf of the Cabal hackers and the community generally I'd like to thank the large number of people who have contributed patches during this development series. Previously I was rather worried that we were not getting enough contributors to fix bugs and do new feature development, but now I'm very pleased. :-) == Get involved == Of course there's still a lot to do! We have big plans for Cabal-2.0, cabal-install and the Hackage website. So if you're interested in helping out with this core infrastructure project then: * subscribe to the cabal-devel mailing list: http://www.haskell.org/mailman/listinfo/cabal-devel * grab the source: http://haskell.org/cabal/code.html * read the guide to the source code: http://hackage.haskell.org/trac/hackage/wiki/SourceGuide * take a look at our list of bugs and feature requests: http://hackage.haskell.org/trac/hackage/report/12 especially the easy tickets: http://hackage.haskell.org/trac/hackage/report/13 Duncan (wearing his Cabal release manager hat)

1 0

Libraries need a new owner
by Adrian Hey 28 Mar '08

28 Mar '08

Hello Folks, As some of you will be aware, I have been working on various Map implementations that currently live here.. http://code.haskell.org/collections/collections-ghc6.8 The libs in question being Data.Tree.AVL, Data.Trie.General and a few other bits like Data.COrdering and the AVL based Data.Map/Set clones. Well, I have decided to stop work on these. So they need a new owner if they're going to go anywhere. If anyone is interested in the job then I suggest they contact myself or Jean-Philippe Bernardy. Of course I will be happy to provide any help or advise anyone who takes over these libs may feel they need from me. I might even contribute a few patches from time to time myself :-) Thanks -- Adrian Hey

4 12

inotify bindings
by Duncan Coutts 26 Mar '08

26 Mar '08

Hi Adam, Could you give us a comparison of the existing hinotify package and your new system-inotify package? http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hinotify-0.2 http://hackage.haskell.org/cgi-bin/hackage-scripts/package/system-inotify-0… What are the key differences? Do you think we could merge the best ideas and have a single package or are the approaches incompatible in some way? Thanks. Duncan

4 4