- Libraries - Haskell.org

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

30 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 30 Mar '08

30 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 29 Mar '08

29 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 27 Mar '08

27 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 25 Mar '08

25 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

Cabal semantics for multiple compilers
by Yitzchak Gale 25 Mar '08

25 Mar '08

In anticipation of the upcoming release of the Mac OS X Tiger installer for GHC 6.8.2, the following questions arise: I currently have GHC 6.8.2 installed via MacPorts in /opt/local. When I use Cabal to install packages manually, they install into /usr/local. I think that is the correct behavior - if that package someday becomes a supported port, the port will install into /opt/local and I don't want to conflict with that. In general, I leave the entire /opt/local tree under the control of the automated port system. Now, what will happen when I install a second copy of GHC 6.8.2 into /usr/local using the installer? First question: What will --with-compiler=ghc-6.8.2 now mean if I forget to specify the full path? Will Cabal do something reasonable and not get confused? (Will it not get confused if I do remember to specify the full path?) Second question: When I install packages, both copies of GHC 6.8.2 will want to install them into /usr/local. Cabal uses directory names like "ghc-6.8.2" to keep installations for different compilers separate from each other. But what if both of the compilers are called "ghc-6.8.2"? Thanks, Yitz

2 5

Defunct packages (was: inotify bindings)
by Niklas Broberg 22 Mar '08

22 Mar '08

> Sorry about that. Can you delete system-inotify from Hackage? Probably > best not to have two, almost identical, packages. Putting this in a more general perspective - how do you mark a package in Hackage defunct? If there's a newer package with the same name superceding an older one then it's not a problem. But if you have no newer package, what then? To be specific, I'm wondering what to do with the hspr package that will be discontinued in the new upcoming HSP release. It would be great to have a flag somewhere that marks it deprecated. Cheers, /Niklas

3 4

Re: GetOpt bug causing it to mistakenly reject options as ambiguous
by Eelis van der Weegen 22 Mar '08

22 Mar '08

Eelis van der Weegen wrote: > There is a bug in System.Console.GetOpt causing > it to mistakenly reject options as ambiguous. Two weeks have passed since I reported this, with no response thus far. Does nobody care about fixing an easily reproducable, easily fixable bug? If so, would it not be more appropriate if the "Maintainer" field in the GetOpt Haddock docs said "N/A" instead of "libraries(a)haskell.org"? Eelis

4 4

ANN: Takusen 0.8.1
by Alistair Bayley 21 Mar '08

21 Mar '08

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Takusen-0.8.1 This is a fairly minor bugfix release. although there are some API changes. Mainly, we've re-exported a lot of the types from Database.InternalEnumerator in Database.Enumerator. This will hopefully address a common complaint that it's impossible to always write type sigs for functions doing database stuff. We've also tidied up some of the exports; there was stuff exposed that shouldn't have been. There's an outstanding bug involving datetime parameter marshaling in ODBC, which I have not had time to resolve (parameters after the datetime parameter get mangled somehow). I will be on holiday for a few weeks, so this will not be addressed by me for some time. Caveat user. The test suite highlights it, should someone else feel sufficiently motivated; I've been testing against PostgreSQL. Alistair

2 1

[ANN] Memory mapped files for POSIX and Windows
by Gracjan Polak 19 Mar '08

19 Mar '08

Hi all, I just uploaded mmap to hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/mmap The package provides memory mapping abstractions for both POSIX and Windows systems like Vista, Linux and Mac OSX. This library provides a wrapper to mmap(2) or MapViewOfFile, allowing files or devices to be lazily loaded into memory as strict or lazy ByteStrings, ForeignPtrs or even plain Ptrs, using the virtual memory subsystem to do on-demand loading. Modifications are also supported. Package includes a cp-like copy utility that uses different mechanisms to copy contents of file. Here come some statistics from using it on 90MB file: Windows: Prelude copy: 10.453 sec ByteString copy: 0.625 sec ByteString.Lazy copy: 0.516 sec MMap copy: 0.281 sec MMap copy lazy: 0.250 sec Linux: Prelude copy: 3.332 sec ByteString copy: 0.280 sec ByteString.Lazy copy: 0.292 sec MMap copy: 0.264 sec MMap copy lazy: 0.200 sec Mac OSX ppc Tiger 10.4 Prelude copy: 5.719 sec ByteString copy: 0.701 sec ByteString.Lazy copy: 0.864 sec MMap copy: 1.073 sec MMap copy lazy: 1.414 sec Hardware is different on those systems, so only relative comparison makes sense. Memory mapping provides significant advantages on Windows and Linux, not so on Mac OSX. Seems like mmap on Mac is not very well implemented. Any feedback is welcome! -- Gracjan

4 7