March 2007 - Libraries

ANN: IPv6 support for network
by Bryan O'Sullivan 08 Mar '07

08 Mar '07

I've added enough IPv6 support to the network package that I can run the attached test program successfully, in the following manner: $ runghc NetTest.hs fec0::1:215:c5ff:fee2:451a HTTP/1.1 200 OK Date: Thu, 08 Mar 2007 07:56:20 GMT Server: Apache/2.2.3 (Fedora) [...etc...] The changes required were very minor: Network.BSD: New getAddrInfo and getNameInfo functions logically replace getHostByName and getHostByAddr, respectively. Network.Socket: The SockAddr ADT has acquired a new, um, whatever it is that ADTs acquire (a branch? a case?), called SockAddrInet6. Functions that work with SockAddrs are now SockAddrInet6-savvy. Network.Socket: New typeclass, HostAddr, allows definition of inet_ntop over HostAddress and HostAddress6 types. Documentation isn't yet 100% complete, but it should be pretty clear what's going on. I've bumped the library version in the .cabal file, just to make sure people don't confuse it with the regular network library. To fetch: darcs get --partial http://darcs.serpentine.com/network6 Please take a look and let me know if you have any comments. If things look sane, I'll do the remaining doco and formally submit my changes. <b

2 1

Re: Proposal: Add First and Last wrappers around Maybe to Data.Monoid
by Jeffrey Yasskin 07 Mar '07

07 Mar '07

On 3/4/07, David Menendez <zednenem(a)psualum.com> wrote: > Jeffrey Yasskin writes: > > > I've created http://hackage.haskell.org/trac/ghc/ticket/1189 to > > suggest adding two Monoid instances around Maybe that, instead of > > accumulating things like most monoids, just pick the first or last > > piece of data they see. > > Rather than have two wrappers, I say make the a Monoid instance for > Maybe using a left-biased choice (like the MonadPlus instance). > > Then we would get right-biased choice for free with the Dual wrapper. That's a reasonable idea, but I chose against it in the proposal because it arbitrarily picks one of the two sensible monoids for Maybe, which I'm worried will confuse users, especially since Haddock doesn't currently provide documentation for instances. Also, (getDual . foldMap (Dual . f)) is less readable than (getLast . foldMap (Last . f)). On the other hand, maybe the usual case is to just want any result, rather than specifically the left-most or right-most one, in which case providing the instance for Maybe directly saves typing. Thanks for the comment, Jeffrey

5 5

ANN: New release of regex packages
by Chris Kuklewicz 07 Mar '07

07 Mar '07

I would like to announce new versions of the regex-* packages. This announcement covers: Version Package Description 0.83 regex-base -- Type Classes and generic instances 0.90 regex-compat -- Uses regex-posix to provide old API 0.91 regex-dfa -- backend, pure haskell, no submatch capture 0.90 regex-parsec -- backend, pure haskell 0.91 regex-pcre -- backend, links against libpcre 0.91 regex-posix -- backend, links against standard c library 0.92 regex-tdfa -- backend, pure haskell (Posix semantics) 0.91 regex-tre -- backend, links against libtre (currently buggy) These all compile, install, and run a few test correctly. Most notably, I consider regex-tdfa to be of useful quality now. Summary of changes and recommendations: * all packages: ** import Text.Regex.XXX exposes (getVersion_Text_Regex_XXX :: Data.Version) which allows programs to access the current version number of the package ** LICENSE file provided (all are 3 clause BSD except regex-dfa is LGPL) * regex-base: ** BUGFIX: one of the RegexContext instances used tail unsafely ** RegexMaker now has makeRegexM and makeRegexOptsM for better error handling ** Extract has new instances for (Seq Char) and (ByteString.Lazy), as well as the previous [Char] and ByteString instances * all backends: ** Now support [Char], (Seq Char), ByteString, and ByteString.Lazy ** CHANGE: The (=~~) monadic match operators now use makeRegexM and will call 'fail' when a regular expression cannot be parsed. ** CHANGE: (import Text.Regex.BACKEND) now re-exports (module Text.Regex.Base) * regex-dfa: ** BUGFIX: No longer hangs on repeated nullable subpatterns * regex-tdfa: ** New backend in pure haskell that provides true Posix semantics ** Runs with excellent memory usage ** I recommend this backend for Posix extended regular expressions (leftmost longest). * regex-compat: No other changes, still uses regex-posix underneath, not recommended * regex-parsec: No other changes, I recommend regex-tdfa or regex-pcre instead * regex-pcre: No other changes, best provider of Perl's left-biased regular expressions * regex-posix: No other changes, very slow (on OS X the underlying C library is buggy) * regex-tre: No other changes, underlying libtre version 0.7.5 is still buggy Dependencies: All of the above packages have been updated to depend on regex-base>=0.80. I have only tested with GHC 6.6 on Mac OS X 10.4.8 (PPC, 32bit). Porting the backends to other Haskell compilers should be possible, though they may not support the polymorphic type class API that regex-base provides. Porting to GHC 6.4 should work once the support for (Seq Char) and ByteString[.Lazy] has been edited or externally obtained. I think only regex-tdfa actually uses bang patterns at the moment, and those could also be removed when porting. Where to get more information and the packages themselves: There is a slowly developing wiki page at http://haskell.org/haskellwiki/Regular_expressions for holding more documentation relating to these packages. I have uploaded tar.gz sources for each of the packages to hackage: http://hackage.haskell.org/packages/hackage.html They are listed under the "Text" Category: http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Text Development and bug fixes continue in the darcs repositories under http://darcs.haskell.org/packages/regex-unstable/ To checkout one of the above versions with darcs you can use commands like darcs get --partial --tag=0.83 regex-base where the --tag=0.83 may be omitted to get the latest unstable version To install the packages once you have the source: For regex-pcre and regex-tre (and perhaps regex-posix) you might need to edit the end of cabal file to provide Include and Lib directories to the corresponding C library. # Compile Setup.hs for better startup speed ghc --make Setup.hs -o setup # I use my own path and "--user" .I recommend doing this to avoid overwriting # the global regex-* from GHC 6.6 ./setup configure --enable-library-profiling --prefix=YOUR_PATH --user ./setup build ./setup install Producing haddock documentation may not work and may not be up to date, with the important exception of regex-base. Future Plans: * regex-base: add support for generalized indices instead of the current Int * regex-tdfa: Improve DFA algorithm and further limit memory allocation. Try to improve performance of ByteString.Lazy matching. Cheers, Chris Kuklewicz

2 5

Want to poke at the network package a bit
by Bryan O'Sullivan 07 Mar '07

07 Mar '07

As part of a project I'm working on, I have a need to add some IPv6 support to the network library. I'd like to clean up the haddocks (or indeed write some in the first place) as I go. But before I start, I notice that the source has some peculiarities, such as explicit line number pragmas that are all wrong, making the process of finding errors unnecessarily interesting. Is there any reason I shouldn't nuke them as I go? <b

3 3

[hoelz@wisc.edu: [Haskell] Haskell Xlib bindings]
by dons＠cse.unsw.edu.au 06 Mar '07

06 Mar '07

This question is best asked on the libraries(a)haskell.org list, so I'll forward it there. Failing that, best to contact the maintainer of the xlib package. Cheers, Don ----- Forwarded message from Rob Hoelz <hoelz(a)wisc.edu> ----- Date: Sun, 04 Feb 2007 16:00:44 -0600 From: Rob Hoelz <hoelz(a)wisc.edu> To: haskell(a)haskell.org Subject: [Haskell] Haskell Xlib bindings Hello everyone, This question probably belongs in GUI, but I tried posting there a week ago and have yet to get a response. My question is this: Why do the Haskell Xlib bindings have no way to extract the property event from an event pointer? For example, the following functions are available: get_KeyEvent, get_ButtonEvent, get_MotionEvent, etc. but there's no get_PropertyEvent. Why was this left out? It seems pretty critical to the functionality of an Xlib program to someone who's been programming in C with Xlib for quite some time. Thanks, Robert Hoelz _______________________________________________ Haskell mailing list Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell ----- End forwarded message -----

4 6

ANN: Bugfixes for regex-posix and regex-pcre ByteString use
by Chris Kuklewicz 06 Mar '07

06 Mar '07

I got a bug report from the #haskell IRC channel last night that empty ByteStrings were broken. The new bugfixed versions of the affected packages are: regex-posix-0.92 regex-posix-0.72 regex-pcre-0.92 regex-pcre-0.81 All the above have been uploaded to http://hackage.haskell.org/ and are available via darcs (see below). Details: regex-posix-0.92 replaces the "unstable" regex-posix-0.91 that I announced yesterday. The bug fix also applied to ByteString.Lazy repository: http://darcs.haskell.org/packages/regex-unstable/regex-posix/ regex-posix-0.72 replaces the regex-posix-0.71 that came with GHC 6.6 repository: http://darcs.haskell.org/packages/regex-posix/ The repository version is setup to compile alongside GHC in some way that I cannot easily package, so the tarball on hackage has edited Wrap.hsc and cabal files. regex-pcre-0.92 replaces the "unstable" regex-pcre-0.91 that I announced yesterday. The bug fix also applied to ByteString.Lazy repository: http://darcs.haskell.org/packages/regex-unstable/regex-pcre/ regex-pcre-0.81 replaces the "stable" regex-pcre-0.80 that is compatible with the regex-base-0.71 supplied with GHC or regex-base-0.72 that I announced yesterday. repository: http://darcs.haskell.org/packages/regex-pcre/

1 0

ANN: regex-base version 0.72
by Chris Kuklewicz 05 Mar '07

05 Mar '07

The version 0.71 of regex-base supplied with GHC 6.6 has a bug in Text.Regex.Base.Context: > instance (RegexLike a b) => RegexContext a b (MatchResult b) where that essentially uses 'tail' where it should not, and this may even be using tail on an empty list. This has been patched in the just announced unstable version of regex-base 0.83 and this message announces that the stable repository at http://darcs.haskell.org/packages/regex-base/ now has version 0.72 which is just 0.71 with this bug fixed. For the eventual GHC 6.6.1 release, the supplied version of regex-base should either be conservatively updated to 0.72 or updated to the slightly more convenient regex-unstable/regex-base version (currently 0.83). Cheer, Chris Kuklewicz

1 0

Is Read / Show for serialization or pretty printing?
by Shae Matijs Erisson 05 Mar '07

05 Mar '07

HAppS development during the ghc6.4 era required Read/Show for serialization, and binary serialization isn't yet popular for HAppS. Because of that, SURI.hs (Show URI) was added to HAppS to wrap Network.URI. I vaguely recall that Network.URI's Show instance was rewritten for GHC 6.6, but the current instance is more for pretty-printing than serialization. To make a long story short, Network.URI does not use derived Read and Show instances, and that causes problems when trying to get invertible serialization. The fix in our opinion is to switch to derived Read and Show instances for Network.URI. Shae & Lemmih -- I've tried to teach people autodidactism, | ScannedInAvian.com but it seems they always have to learn it for themselves.| Shae Matijs Erisson

4 3

Issues with System.Posix.Files
by David Brown 05 Mar '07

05 Mar '07

Hi, I'm writing some code to use System.Posix.Files to restore a filesystem. I've discovered a few missing things. - There is a createDevice, but the mode values needed to pass to this call aren't exported (blockSpecialMode, characterSpecialMode). - In fact, it would be nice to be able to have fileTypeModes exported as well as each of the types. One would assume that someone using System.Posix wishes to access things at this kind of level. Thanks, David Brown

3 3

Cabal, Hackage, and License-File
by John Goerzen 04 Mar '07

04 Mar '07

Hello, In my packages, I typically use a format with: * COPYRIGHT: the collection of copyright statements * COPYING: My license * 3rd-party-licenses/*: Licenses for contributed code Now, most of my packages these days don't have 3rd-party-licenses. But there is a problem with Cabal's sdist. It doesn't put files into the generated tarball that it doesn't know about. On a project of any reasonable size, there may be two dozen people that hold copyrights on parts of it. It's not practical to keep that all up-to-date in the .cabal file, IMHO. That's why I have the COPYRIGHT file. The license file is useless without it. So what do I do here to make sure that all the license docs wind up in the generated tar.gz? In case you're wondering, I don't like to hack up the COPYING file with all the local copyright stuff. Just makes it more annoying to have all that in the license file. -- John

2 1