- Libraries - Haskell.org

darcs patch: Don't test for rl_completion_word_break_hook with -lreadline if we're using GNUreadline.framework.
by Judah Jacobson 29 Nov '07

29 Nov '07

Looking over some buildbot logs, I realized the following issue with the readline configure script: It always adds an extra -lreadline when checking for rl_completion_word_break_hook, despite the fact that sometimes we want to link with -framework GNUreadline. Thanks, -Judah * Don't test for rl_completion_word_break_hook with -lreadline if we're using GNUreadline.framework. M ./configure.ac -2 +2

1 0

Supporting various versions of Cabal
by Alistair Bayley 29 Nov '07

29 Nov '07

Hello, Is there a story for supporting various versions of Cabal in a package? For Takusen we now have three different Setup.lhs files, for Cabal versions 1.1.4, 1.1.6.2, and 1.2. I'm not sure I want to discard the Setup scripts for the older versions, as this allows users with older installations to use Takusen without being forced to upgrade their Cabal package. However, I'm also conscious that latest Cabal works with versions of ghc back to 6.4 (if not earlier), so is this a non-issue? Is it reasonable to require users to upgrade Cabal to a newer version than the one that ships with their compiler, just to get your package to build? Thanks, Alistair

2 1

Cabal and extra-ghci-libraries
by Olivier Boudry 28 Nov '07

28 Nov '07

Hi all, Is there a way to specifiy extra-ghci-libraries in the Cabal file? I found a bug report ( http://www.haskell.org/pipermail/cvs-libraries/2006-January/004778.html) saying that extra-ghci-libraries is now defined in Distribution.InstalledPackageInfo and that parsing code has been added, but it's not recognized if I add it to the cabal file. I built Exif for Windows and cannot use it in ghci (dll load error). The library is named libexif and the dll libexif-12.dll. I can workaround the problem by unregistering the module, adding extra-ghci-libraries to dist\installed-pkg-config and re-registering it again. But it would be easier if I could define the extra-ghci-libraries directly in the Cabal file. I modified the cabal file by just adding extra-ghci-libraries to it, but Cabal don't recognise that name: ... Ghc-options: -O2 -Wall extra-libraries: exif extra-ghci-libraries: libexif-12 include-dirs: C:/msys/1.0/local/include ... When configuring I get this: ... Warning: Unknown fields: extra-ghci-libraries (line 19) Fields allowed in this section: name, version, cabal-version, build-type, license, license-file, copyright, maintainer, build-depends, stability, homepage, package-url, synopsis, description, category, author, tested-with, data-files, extra-source-files, extra-tmp-files I'm using ghc-6.8.1 (the distributed version) and Cabal-1.2.2.0 Thanks, Olivier.

1 0

Re: [Haskell-cafe] expanded standard lib
by Bjorn Bringert 22 Nov '07

22 Nov '07

On Nov 19, 2007, at 23:13 , Henning Thielemann wrote: > > On Mon, 19 Nov 2007, Brandon S. Allbery KF8NH wrote: > >> On Nov 19, 2007, at 15:47 , Radosław Grzanka wrote: >> >>> If you look at the stability tag of ghc libraries you will see >>> that a >>> lot of them are marked as "provisional" (Network.URI for example) or >>> "experimental" (Control.Monad.Trans). >> >> This may not refer to what most people care about; the "experimental" >> stability of Control.Monad.Trans is related to its use of fundeps and >> undecidable instances, and the possibility (likelihood?) of its being >> switched to type families (which "shouldn't" change its user-visible >> interface, as I understand it). > > I like to see MTL split into a Haskell98 part and an advanced part. I > mostly use functionality which would nicely fit into a Haskell98 > interface > and find it annoying that by importing MTL my code becomes less > portable. Yes! Please! /Björn

7 8

Re: [Haskell-cafe] Stream fusion for Hackage
by Ross Paterson 22 Nov '07

22 Nov '07

[redirected from haskell-cafe] On Sat, Nov 17, 2007 at 06:31:08PM -0800, Don Stewart wrote: > Just a quick announce: the stream fusion library for lists, > that Duncan Coutts, Roman Leshchinskiy and I worked on earlier this year > is now available on Hackage as a standalone package: > > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/stream-fusion-0.… The module Data.Stream clashes with a module in the Stream package (originally from the arrows package), and I think the latter is a more widely used notion of stream. Would you consider renaming Data.Stream and Control.Monad.Stream?

9 17

ANNOUNCE: Important bug fix for regex-pcre ByteStrings.
by ChrisK 20 Nov '07

20 Nov '07

Greetings, There are new version 0.82 and 0.93 of regex-posix. If you use regex-posix with Data.ByteString then you should upgrade to obtain a fix for a crash error. There are new version of regex-pcre available on hackage and the two darcs repositories: http://darcs.haskell.org/packages/regex-pcre/ for "stable" version 0.82 and http://darcs.haskell.org/packages/regex-unstable/regex-pcre/ for "unstable" version 0.93 The new version regex-pcre-0.82 replaces the broken version 0.81 The new version regex-pcre-0.93 replaces the broken version 0.92 I apologize for the error. I took the address of the ByteString to give to the pcre library by using unsafeUseAsCStringLen. I had not appreciated that this can return a null pointer for an empty ByteString. My code caught this null pointer and reported it, however, and so a good error message sent in by a user allowed me to quickly find and hopefully fix it. For version 0.92 the error also applied to Lazy ByteStrings. In case anyone is curious, the fixed code checks the pointer returned by unsafeUseAsCStringLen and replaces a null pointer to a non-null pointer to a private private bytestring "myEmpty" with the length set to 0 by "trim": > {-# INLINE asCStringLen #-} > asCStringLen :: ByteString -> (CStringLen -> IO a) -> IO a > asCStringLen s op = B.unsafeUseAsCStringLen s checked > where checked cs@(ptr,_) | ptr == nullPtr = B.unsafeUseAsCStringLen myEmpty (op . trim) > | otherwise = op cs > myEmpty = B.pack [0] > trim (ptr,_) = (ptr,0) This fix is motivated by desiring to ensure asCStringLen never passes a null pointer to "op" and that no memory copy operations are used. The safe "useAsCString(Len)" do not appear capable of returning a null pointer. Only "unsafeUseAsCString(Len)" on an empty bytestring might return a null pointer. -- Chris

1 0

PROPOSAL: Restrict the type of (^), (^^), and add genericPower, genericPower'
by Ian Lynagh 19 Nov '07

19 Nov '07

Hi all, This got a warm reception when I mentioned it in http://www.haskell.org/pipermail/haskell-cafe/2007-June/027557.html so I'm formally proposing it now. It's trac #1902: http://hackage.haskell.org/trac/ghc/ticket/1902 Note that this is a divergence from Haskell 98 (but the libraries already have a handful of small divergences, and Haskell' is just around the corner...). In my opinion, (^) has the wrong type. Just as we have, for example, (!!) :: [a] -> Int -> a genericIndex :: (Integral b) => [a] -> b -> a we should also have (^) :: (Num a) => a -> Int -> a genericPower :: (Num a, Integral b) => a -> b -> a (or some other function name). The same goes for (^^) (genericPower'). In my experience this would remove 99.9% of all defaulting (mostly where you write things like x^12 and 8^12), which means it's easier to get -Wall clean without having to put :: Int annotations everywhere. The impact to GHC's bootlibs and extralibs is minimal. In most cases we have things like 2^15, where Int is clearly fine, although it happens to be defaulted to Integer currently. In Data.Complex we have 2 cases of e^(2::Int) which can now be beautified. There are several cases where the type is inferred to be Int anyway. There are 3 files where we really do have an Integer, and it does matter. They are all for parsing numbers of the form 18e43, in base/Text/Read/Lex.hs, parsec/Text/ParserCombinators/Parsec/Token.hs and haskell-src/Language/Haskell/Lexer.hs. Initial deadline: 1 Dec 2007. Thanks Ian

8 15

haddock - links with fragments messed up
by apfelmus 18 Nov '07

18 Nov '07

Hello, the #-links to the references at the bottom of System.Random work fine in http://www.haskell.org/ghc/docs/latest/html/libraries/random-1.0.0.0/System… but not in http://hackage.haskell.org/packages/archive/random/1.0.0.0/doc/html/System-… Besides, I doubt that the links like System.Random#globalrng are intended to be rendered as such but rather as the title of the destination The global random number generator or something. Regards, apfelmus

2 1

Control.Category in base
by Bertram Felgenhauer 18 Nov '07

18 Nov '07

Hi, I played with ghc head today. I saw that its base library contains Control.Category, and Control.Arrow uses that. (I also saw the discussion about it on this mailing list. There weren't any serious objections; the discussion was far from focused though [*], and I found that the patch was applied rather abruptly. [1]) Anyway, here's what I found trying to compile HXT: 1) Control.Arrow doesn't export (>>>) and (<<<) anymore. 2) All user defined instances of Control.Arrow.Arrow break. The first one is easily fixed in the base library. The second one is more annoying. The required changes to HXT aren't that big - my patch inserts 30 lines and deletes 10 - but it'll be harder to make it compatible between several ghc versions. So all in all I'm rather unhappy that this patch went in, because it breaks existing code and personally I see little gain from it. Personally I'd like to see that patch reverted. However I realize that my complaint comes rather late, so if we decide to keep the patch we have to fix the first issue above to minimize breakage of other packages. regards, Bertram [*] a lot of mails in the thread went off tangents, extending the proposal to refining the class hierarchy of arrows. For reference, the thread starts at http://www.haskell.org/pipermail/libraries/2007-October/008291.html [1] http://www.haskell.org/pipermail/libraries/2007-October/008496.html

2 2

META-PROPOSAL: Documentation should be required to say when exports were introduced
by Ian Lynagh 17 Nov '07

17 Nov '07

Hi all, This is trac #1903: http://hackage.haskell.org/trac/ghc/ticket/1903 One of the nice things about, for example, PHP is that if you look at the documentation for one of its functions, e.g. http://www.php.net/manual/en/function.file-get-contents.php it tells you that file_get_contents is available in PHP >= 4.3.0. I propose that all exports in Haskell libraries should be required to have such a thing in their haddock documentation. For the current code we could either give the current versions as the date of introduction, or do some digging and put precise data in. Initial deadline: 1 December 2007. Thanks Ian

4 6