- Libraries - Haskell.org

Re: who develops and maintains the Unix package?
by Galchin Vasili 03 Dec '07

03 Dec '07

Hello, > > I am starting to get in the groove related to runhaskell -- > config/builds on top of cygwin (I haven't had time to carve up hard drive > and install Linux). > > In any case, I really want to get the Unix package to build on > cgywin (as advertised at > http://hackage.haskell.org/cgi-bin/hackage-scripts/package/unix-2.2.0.0) > When i do "runhaskell Setup.lhs configure" > things seem to go fine, .log fine is clean, and pertinent cygwin include > files like times.h are found, but when i do a "runhaskell Setup.lhs build" > then the include files that are allegedly found during the configure > "probe" cannot be found. ???? > > 1) During the "runhaskell Setup.lhs build" step, what human readable > file > is used and contains paths to the cygwin Posix include file > directories? 2) thatis foloowing is a better approach for me .. => > > 2) Somebody obviously put " (except under Cygwin)". Can you point at > who made this claim and why? > > > Kind regards, Vasya >

1 0

Bounded and floating types
by Conal Elliott 02 Dec '07

02 Dec '07

Currently Float & Double do not have standard Bounded instances. Is there any reason not to use the following? instance Bounded Float where { minBound = -1/0; maxBound = 1/0 } instance Bounded Double where { minBound = -1/0; maxBound = 1/0 } If I don't hear objections, I'll submit a ticket and re-send a proposal note. - Conal

2 1

Fwd: 2 GHCs => can't resolve Cabal dependencies
by Valery V. Vorotyntsev 30 Nov '07

30 Nov '07

---------- Forwarded message ---------- From: Valery V. Vorotyntsev <valery.vv(a)gmail.com> Date: Dec 1, 2007 12:40 AM Subject: 2 GHCs => can't resolve Cabal dependencies To: cvs-ghc(a)haskell.org Hi, I've installed GHC from darcs recently (following http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking instructions), and come into issue with Cabal dependencies: http://hpaste.org/4182 I suspect my GHC configuration to be broken. Could you please help me investigate the problem? Thanks. :) -- vvv

1 0

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 27 Nov '07

27 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 18 Nov '07

18 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