January 2009 - Libraries

Arch Haskell News: Jan 11 2009
by Don Stewart 14 Jan '09

14 Jan '09

Arch Haskell News: Jan 11 2009 Hey all, welcome to the first Arch Haskell News of 2009. (News about Haskell on the Arch Linux platform). Arch now has 827 Haskell packages in AUR. That’s an increase of 93 new packages in the last 48 days, or 1.9 new Haskell apps and libraries a day over the holiday season. Well done everyone!. Noteworthy * lhc-0.6.20081127: “LHC Haskell Compiler” * cabal2arch-0.4.2: “Create Arch Linux packages from Cabal packages” * timberc-1.0.2: “The Timber Compiler.” * haskell-x11-1.4.5: “A binding to the X11 graphics library” * haskell-curl-1.3.2.2: “Haskell binding to libcurl” * alex-2.3.1: “Alex is a tool for generating lexical analysers in Haskel * haskell-bytestring-trie-0.1: “Efficient map from strings to values.” * haskell-llvm-0.5.0.1: “Bindings to the LLVM compiler toolkit” * tetris-0.27178: “A 2-D clone of Tetris” * haskell-network-bytestring-0.1.1.4: “Fast and memory efficient low-level networking” * haskell-hdbc-1.1.6: “Haskell Database Connectivity” http://archhaskell.wordpress.com/2009/01/11/arch-haskell-news-jan-11-2009/ Other news: * llvm support, http://archhaskell.wordpress.com/2009/01/11/llvm-haskell-bindings/ * new hdbc release, http://archhaskell.wordpress.com/2009/01/11/hdbc-haskell-database-suite-upd… * salvia, new web framework, supported http://archhaskell.wordpress.com/2009/01/11/new-haskell-web-framework-salvi… Bring on 2009 and the era of ubiquitous Haskell! -- Don

2 2

Policy change for regex libraries
by Chris Kuklewicz 13 Jan '09

13 Jan '09

Before I go and add or change anything in the Haskell regex-posix library, I wanted to get some feedback. regex-posix provides Text.Regex.Posix, and is built on the regex-base package. regex-posix is also used as the backend for Text.Regex (the regex-compat package does this). I do not intend to change the behavior of the old Text.Regex API. The main issue is the behavior when returning a list of all matches of a Regex against a target text. I no longer think the current behavior is the right choice when it comes to zero-length matches. The current behavior is to return non-overlapping matches with the caveat that after the first zero-length match the search is ended. Note that the zero-length match may be occur at the end position of a previous non-zero-length match. Notably, no one has complained about this policy. But I no longer like it. So here are a few of my ideas of what to change it to: 0) No change, not worth the effort. 1) return the zero-length match, skip forward 1 character, and continue searching. If the consumer wishes the old policy they can truncate the list. This could also be filtered to resemble option 2 below. 2) Mimic "sed". It seems "sed" has a policy where a zero-length match is forbidden to occur at the end position of a non-zero-length match. "sed" does not stop with the first zero-length match. 3) implement additional execution options, so the user can choose a policy. The default policy choice left with the current behavior. 4) implement additional execution options, so the user can choose a policy. The default policy choice set to he behavior in (1). 5) Return valid matches starting from all positions, including overlapping matches. This I really do not like and one can run the search starting one character after the start of the last match to get this information. Matching "0123" and replacing all matches with themselves wrapped in angle brackets. The policies of 0, 1, and 2 above lead to (computed partly by hand): regex of "[0123]?" 0): "<0><1><2><3><>" 1): "<0><1><2><3><>" 2): "<0><1><2><3>" regex of "[012]?" 0): "<0><1><2>3<>" 1): "<0><1><2>3<>" 2): "<0><1><2>3<>" regex of "[013]?" 0): "<0><1><>23" 1): "<0><1><>2<3><>" 2): "<0><1>2<3>" regex of "[023]?" 0): "<0><>123" 1): "<0><>1<2><3><>" 2): "<0>1<2><3>" regex of "[123]?" 0): "<>0123" 1): "<>0<1><2><3><>" 2): "<>0<1><2><3>" regex of "[03]?" 0): "<0><>123" 1): "<0><>1<>2<3><>" 2): "<0>1<>2<3>" regex of "[03]?" 0): "<0><>123" 1): "<0><>1<>2<3><>" 2): "<0>1<>2<3>" regex of "[12]?" 0): "<>0123" 1): "<>0<1><2><>3<>" 2): "<>0<1><2>3<>" I am leaning to simply changing it from policy 0 to policy 1. Are there any objections? Perhaps I should set a deadline? Now where is that library policy... -- Chris

3 6

Missing -lrt for shm* functions in the unix package
by Don Stewart 13 Jan '09

13 Jan '09

The module System.Posix.SharedMem was silently disabling the shm_* functions due to failing configuration tests on linux (needs the -lrt lib). This patch adds -lrt to the configure test/ buildinfo. -- Don Mon Jan 12 15:07:58 PST 2009 Don Stewart <dons(a)galois.com> * Add check for -lrt to get the shm* functions. Subst. in buildinfo New patches: [Add check for -lrt to get the shm* functions. Subst. in buildinfo Don Stewart <dons(a)galois.com>**20090112230758] hunk ./configure.ac 30 AC_CHECK_FUNCS([nanosleep]) AC_CHECK_FUNCS([ptsname]) AC_CHECK_FUNCS([setitimer]) + +# Avoid adding rt if absent or unneeded +AC_CHECK_LIB(rt, shm_open, [EXTRA_LIBS="$EXTRA_LIBS rt" CFLAGS="$CFLAGS -lrt"]) + +# needs -lrt on linux AC_CHECK_FUNCS([shm_open shm_unlink]) FP_CHECK_CONSTS([SIGABRT SIGALRM SIGBUS SIGCHLD SIGCONT SIGFPE SIGHUP SIGILL SIGINT SIGKILL SIGPIPE SIGQUIT SIGSEGV SIGSTOP SIGTERM SIGTSTP SIGTTIN SIGTTOU SIGUSR1 SIGUSR2 SIGPOLL SIGPROF SIGSYS SIGTRAP SIGURG SIGVTALRM SIGXCPU SIGXFSZ SIG_BLOCK SIG_SETMASK SIG_UNBLOCK], [ Context: [Avoid using IOError internals Ian Lynagh <igloo(a)earth.li>**20090104173221] [fix pthread linkage problem for openbsd Matthias Kilian <kili(a)outback.escape.de>**20081129000638 This should make my openbsd build slave happy when SplitObjs=NO. May be useful for other BSDs and even Linux, regardless wether you need -pthread or -lpthread. Time will tell... ] [catch up with exception changes Simon Marlow <marlowsd(a)gmail.com>**20080927135428] [Bump version number to 2.3.1.0 Ian Lynagh <igloo(a)earth.li>**20080920160248] [TAG 6.10 branch has been forked Ian Lynagh <igloo(a)earth.li>**20080919123439] [follow library changes Ian Lynagh <igloo(a)earth.li>**20080903223616] [add category field Ross Paterson <ross(a)soi.city.ac.uk>**20080824003014] [We now depend on concurrent (split off from base) Ian Lynagh <igloo(a)earth.li>**20080824135158] [Fix the build when CONST_SIGPOLL == -1 Ian Lynagh <igloo(a)earth.li>**20080823160346 We were defining, but not using, sigPOLL ] [Fix warnings in the unix package Ian Lynagh <igloo(a)earth.li>**20080821120138] [move some stuff here from System.Directory, now the dependencies are reversed Simon Marlow <marlowsd(a)gmail.com>**20080821144754] [Follow extensible exceptions changes Ian Lynagh <igloo(a)earth.li>**20080623193152] [Allow C's unsetenv to return either void or int Ian Lynagh <igloo(a)earth.li>**20080703190603 Fixes, and patch from donn in, trac #2352. ] [Avoid using deprecated flags Ian Lynagh <igloo(a)earth.li>**20080616145425] [move __hscore_{mkstemp,getrlimit,setrlimit} here from base Ross Paterson <ross(a)soi.city.ac.uk>**20080615224248] [TAG 2008-05-28 Ian Lynagh <igloo(a)earth.li>**20080528004441] Patch bundle hash: dd0767ff90044fe756b71c7e1bf58467ba9d7203

1 0

haskell-platform mailing list
by Duncan Coutts 13 Jan '09

13 Jan '09

Hi all, If you are interested in helping out with the haskell platform project then we invite you to subscribe to the haskell-platform mailing list. http://projects.haskell.org/cgi-bin/mailman/listinfo/haskell-platform This mailing list is for discussing practical stuff. We expect to discuss policy questions on the libraries mailing list. Issues like which packages to pick, what package QA standards to use etc would be discussed on the libraries mailing list. Those issues are for the community as a whole. Building and coordinating the actual releases will be done via the haskell-platform mailing list. Duncan

1 0

different flavours of Monad Template Library
by Henning Thielemann 13 Jan '09

13 Jan '09

I see now at least three MTL libraries at hackage, namely mtl mmtl mtl-tf They all define both the example data types and according type classes in modules with the same name. This way you can only use one of these packages in all packages you import. However the data types are defined the same way in the packages, only the classes differ. I wished, there would be one package defining only the datatypes, say "mtl-data", and three ones with the names "mtl", "mmtl", "mtl-tf" that define their classes with corresponding instances. These classes should be in different modules, so you can use different class frameworks in the same project. The data type package would be useful on its own and could be run on the simplest Haskell compilers, since no functional dependencies are required. However there is the compatibility problem: Currently Control.Monad.State exports also the MonadState class, which would no longer work. Maybe we can reserve Control.Monad.State for mtl, which exports Control.Monad.State.Data.Lazy from mtl-data and Control.Monad.State.Class from mtl. I assume that mmtl and mtl-tf are not as much used as mtl, such that it would not too bad to break compatibility for them. They could no longer export Control.Monad.State, but instead the user of mmtl has to import Control.Monad.State.Data from mtl-data. The class file of mmtl could be named Control.Monad.Modular.State.Class. (Replace "State" by "Writer", "Reader" and so on, and "mmtl" by "mtl-tf" in order to get all names that need to be adapted.)

4 23

Re: different flavours of Monad Transformer Library (fwd)
by Mauro J. Jaskelioff 13 Jan '09

13 Jan '09

Hi, sorry for the late reply, I have no problem with your proposal (mtl-data). I'd prefer to have all the liftings in the same package, though (and not just separate the ones with FD). I also like Ross' idea of monads being synonyms for transformers at Id. It removes lots of repeated code. Wrt portability, I'm working an another experimental monad transformer library (http://www.cs.nott.ac.uk/~mjj/monatron ) which, unlike mmtl, does not try to be backwards compatible with mtl. It contains a core with full functionality (except operation overloading) which should work in Haskell 98+Rank2Functors. Lack of operation overloading means you have to be explicit about the liftings. (for example, declare you want the operation 'catch' lifted through 2 monad transformers) With other extensions (FD, multiparameter classes, etc.) you also get operation overloading. All the best, - Mauro Henning Thielemann wrote: > > I don't know whether you are on the libraries(a)haskell.org list ... > > ---------- Forwarded message ---------- > Date: Sun, 4 Jan 2009 23:50:28 +0000 > From: Ross Paterson <ross(a)soi.city.ac.uk> > To: libraries(a)haskell.org > Subject: Re: different flavours of Monad Template Library > > On Sun, Jan 04, 2009 at 11:22:15PM +0100, Henning Thielemann wrote: >> I see now at least three MTL libraries at hackage, namely >> mtl >> mmtl >> mtl-tf >> >> They all define both the example data types and according type classes >> in modules with the same name. This way you can only use one of these >> packages in all packages you import. However the data types are defined >> the same way in the packages, only the classes differ. >> >> I wished, there would be one package defining only the datatypes, say >> "mtl-data", and three ones with the names "mtl", "mmtl", "mtl-tf" that >> define their classes with corresponding instances. These classes should >> be in different modules, so you can use different class frameworks in >> the >> same project. The data type package would be useful on its own and could >> be run on the simplest Haskell compilers, since no functional >> dependencies are required. > > I agree. I had a go at such a restructuring of mtl a while ago: > > http://darcs.haskell.org/packages/transformers/ > http://darcs.haskell.org/packages/mtl-split/ > > The first is a Haskell 98 package that defines the monad transformers, > operations and liftings, like the mtl-data suggestion. The second adds > the FD-based classes. It's close to complete compatibility with mtl, > except that State is a synonym for StateT Identity etc. The main > problem was haddock's limitations with inter-package re-exports. > >> However there is the compatibility problem: Currently >> Control.Monad.State exports also the MonadState class, which would no >> longer work. Maybe we can reserve Control.Monad.State for mtl, which >> exports Control.Monad.State.Data.Lazy from mtl-data and >> Control.Monad.State.Class from mtl. > > I used Control.Monad.Trans.State.Lazy for the transformer. > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://www.haskell.org/mailman/listinfo/libraries This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.

4 3

MonadPlus instance for ContT
by Wolfgang Jeltsch 13 Jan '09

13 Jan '09

Hello, I wonder why there isn’t a MonadPlus instance for ContT. In my opinion, this one would be natural: > instance (MonadPlus monad) => MonadPlus (ContT result monad) where > > mzero = ContT $ return mzero > > ContT cont1 `mplus` ContT cont2 = ContT $ liftM2 mplus cont1 cont2 return and liftM2 are the ones of (->) (o -> monad result). What do you think? Best wishes, Wolfgang

2 2

Announcing Haskell protocol-buffers 1.4.0 (the smashing recursive edition)
by Chris Kuklewicz 10 Jan '09

10 Jan '09

Hello, What is protocol-buffers? Google's "..language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more." http://code.google.com/apis/protocolbuffers/docs/overview.html What is Haskell protocol-buffers? This provides a program 'hprotoc' which compiles a ".proto" file defining messages to Haskell modules, and the protocol-buffers API to access them and convert back and forth to the binary wire protocol, and protocol-buffers-descriptors which are messages which describe ".proto" files and allow for runtime reflection of annotated message definitions. The big addition to this version (which is 1.4.0) over the previous version (which was 1.2.0) is for when modules are in a dependency loop. The most common reason this happens is whenever a message is extended in the same proto file but outside of the message itself (e.g. at the top level). This was salved in previous versions by telling the user to create boilerplate header files (a .hs-boot file) and add a few {-# SOURCE #-} pragmas. This was primitive, and could not cover all the corner cases. Those days are gone. The new version of hprotoc uses the cutting edge version of haskell-src-exts (4.8.0) to generate not only the Haskell modules but also the hs-boot files and {-# SOURCE #-} pragmas! This is truly a glorious way to start the New Year. But wait, there is more! If a more than two messages define extensions of each other in a strongly connected dependency graph then the hs-boot files are not enough. For these strange cases hprotoc will now generate modules ending with 'Key.hs that separately define the extensions. You do not need to lift a finger, you never need to import these modules yourself, this all exists behind the scenes. Also, hprotoc goes way out its way to reduce the number of .hs-boot and 'Key.hs files, and it uses only a minimal set of {-# SOURCE #-} pragmas. It is so painless that if I did not put this into this announcement you might not even know. Now all generated should compile with no changes or additions. Of course, hprotoc still generates nothing for services and methods. Where to get the new shiny packages? hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers http://hackage.haskell.org/cgi-bin/hackage-scripts/package/protocol-buffers… http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hprotoc And you will need haskell-src-exts, version 0.4.8, by Niklas Broberg: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haskell-src-exts… (past version do not work and future versions will probably change enough to break compilation of hprotoc) Happy New Year, Chris Kuklewicz

1 0

Re: Bug in network library, uncaught exception when dealing with ipv6 sockets
by Thomas Hartman 09 Jan '09

09 Jan '09

ok. http://hackage.haskell.org/trac/ghc/ticket/2927 2009/1/8 Thomas Hartman <tphyahoo(a)gmail.com>: > ok. > > http://hackage.haskell.org/trac/ghc/ticket/2927 > > 2009/1/8 Don Stewart <dons(a)galois.com>: >> tphyahoo: >>> >>> There is an uncaught exception in the network library which is causing >>> my HAppS demo website >>> >>> http://happstutorial.com >> >> If it is the Haskell network library, could you submit a patch there? >> >> -- Don >> >

1 0

Bug in network library, uncaught exception when dealing with ipv6 sockets
by Thomas Hartman 09 Jan '09

09 Jan '09

There is an uncaught exception in the network library which is causing my HAppS demo website http://happstutorial.com to crash every couple of days. This has affected other people using HAppS as well, as described on postings to the HAppS users list. The bug, and workarounds, is described at http://code.google.com/p/happs/issues/detail?id=40 This message is to suggest a fix for the issue. The problem seems to me to be localized in the following bit of code, from -- http://hackage.haskell.org/packages/archive/network/2.2.0.1/doc/html/src/Ne… *************************** #if defined(IPV6_SOCKET_SUPPORT) accept sock@(MkSocket _ AF_INET6 _ _ _) = do (sock', addr) <- Socket.accept sock (Just peer, _) <- getNameInfo [] True False addr handle <- socketToHandle sock' ReadWriteMode (PortNumber port) <- socketPort sock' return (handle, peer, port) #endif *************************** The problem is that getNameInfo can give rise to an IO exception, which should be caught at the library level. An exception IS caught at the library level when fetching peer for ipv4 packets, as follows. Since the code can never crash when fetching peer for ipv4 packets, it seems to me it shouldn't be allowed to crash when fetching peer for ipv6 packets either. ip v4 packet code: *************************** accept sock@(MkSocket _ AF_INET _ _ _) = do ~(sock', (SockAddrInet port haddr)) <- Socket.accept sock peer <- catchIO (do (HostEntry peer _ _ _) <- getHostByAddr AF_INET haddr return peer ) (\e -> inet_ntoa haddr) -- if getHostByName fails, we fall back to the IP address handle <- socketToHandle sock' ReadWriteMode return (handle, peer, port) *************************** My suggestion for fixing for ipv6 is as follows, basically having similar error catching as for ipv4. *************************** #if defined(IPV6_SOCKET_SUPPORT) accept sock@(MkSocket _ AF_INET6 _ _ _) = do (sock', addr@((SockAddrInet port haddr) )) <- Socket.accept sock (Just peer, _) <- catchIO ( getNameInfo [] True False addr ) (\e -> do peerAsIp <- inet_ntoa haddr return (Just peerAsIp, undefined)) handle <- socketToHandle sock' ReadWriteMode (PortNumber port) <- socketPort sock' return (handle, peer, port) #endif *************************** Des this seem reasonable? Of course, please advise if I should repost this issue to the ghc bugtracker, or similar. Thanks also to Matt Elder for being very generous with his time in helping me diagnose this. And also thanks to the others on the above-linked HAppS bug thread. Thomas.

2 2