- Libraries - Haskell.org

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

23 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

Data.Map, Data.IntMap documentation
by Andriy Palamarchuk 19 Mar '08

19 Mar '08

Improved, fixed documentation for Data.Map, Data.IntMap. Moved time complexity Big-O values to the end of function descriptions. Added examples. For the initial review I submitted only changes for Data.Map. I'll update IntMap for the final review. Deadline - August 27 (two weeks). Ticket: http://hackage.haskell.org/trac/ghc/ticket/1611 Haddock output: http://hackage.haskell.org/trac/ghc/attachment/ticket/1611/Data-Map.html?fo… The module source and diff are also attached to the ticket. Andriy ____________________________________________________________________________________ Pinpoint customers who are looking for what you sell. http://searchmarketing.yahoo.com/

17 50

haskell.org is accepted to GSoC
by Malcolm Wallace 18 Mar '08

18 Mar '08

Google announced last night that Haskell.org has been accepted as a mentoring organisation for this year's Summer of Code (amongst 175 Open Source organisations). http://code.google.com/soc/2008/ The game is on! Student applications open at 1900 UTC on Mon 24th March, and close at 2400 UTC on Mon 31st March. In the meantime, my _strong_ suggestion is for students to search for ideas amongst the many lists available on the web: http://hackage.haskell.org/trac/summer-of-code/ http://haskell.org/haskellwiki/Hac_2007_II/Projects http://haskell.org/haskellwiki/Hac4/Projects and when crafting your proposal: * post it to an appropriate mailing list for comments e.g. haskell-cafe, libraries, wxHaskell, cabal-devel (prefix your subject line with [GSoC] to make it easy to find) * use feedback from the list to improve your proposal. Potential mentors will rank your final submitted proposal based on your ability and commitment to engage with the wider Haskell community, in addition to technical merit. Proposals that will benefit the entire Haskell world will generally be ranked more highly than niche projects with only a few potential users. So things like Cabal-hacking, darcs-hacking, compiler-hacking, are good, as are new libraries to do tasks that are in high demand. (This is not an exhaustive list.) Regards, Malcolm

1 0

Cabal's configure doesn't notice missing headers
by Valery V. Vorotyntsev 18 Mar '08

18 Mar '08

Hi, while installing zlib[1] from hackage, I've discovered possible Cabal's misbehaviour. There was no `zlib.h' in my system. runhaskell Setup configure went fine, with no complaints. It was only during build step when missing header had been noticed and an error reported. apt-get install zlib1g-dev; and zlib cabal package installation succeeded, but... Closer to my question. `zlib.h' _is_ mentioned in zlib.cabal: includes: zlib.h According to documentation[2], `includes' "field applies to both header files that are already installed on the system and to those coming with the package to be isntalled." [NB the typo] I think that Cabal should complain of missing headers during configuration step. At least of the ones explicitly mentioned in `includes:' field. 1. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib-0.4.0.4 2. http://www.haskell.org/cabal/release/latest/doc/users-guide/x30.html#buildi… -- vvv

2 1