March 2009 - Libraries

Re: Cabal install error msg
by Duncan Coutts 17 Mar '09

17 Mar '09

On Tue, 2009-03-17 at 15:30 +1030, Mark Spezzano wrote: > Hi all, > I’m trying to do an install of OpenGL on Windows using Cabal > I type > >cabal.exe configure OpenGL > And get > sh: runProcess: does not exist (No such file or directory) > What’s the cause? The OpenGL package uses a ./configure script which needs sh.exe and various other programs. Cabal is trying to run sh.exe but it cannot find it. To build the OpenGL package on Windows you need to build it from within an MSYS shell (which provides sh.exe and the other required tools). There's also a ticket for the bad error message: #403 Bad error message when running ./configure fails to find sh http://hackage.haskell.org/trac/hackage/ticket/403 It should be very easy to improve the error message. Patches welcome. Duncan

1 0

Cabal install error msg
by Mark Spezzano 17 Mar '09

17 Mar '09

Hi all, I’m trying to do an install of OpenGL on Windows using Cabal I type >cabal.exe configure OpenGL And get sh: runProcess: does not exist (No such file or directory) What’s the cause? Cheers, Mark Spezzano No virus found in this outgoing message. Checked by AVG. Version: 7.5.557 / Virus Database: 270.11.15/2004 - Release Date: 16/03/2009 7:04 AM

1 0

Ticket #3058: Add 'hex' to the pretty package (and other thoughts)
by Thomas DuBuisson 14 Mar '09

14 Mar '09

All, http://hackage.haskell.org/trac/ghc/ticket/3058 Attached is a patch for Text.PrettyPrint.HughesPJ that adds a 'hex' function to print hexidecimal numbers. The only point that I exepect to be contended is it varies slightly from the surrounding functions in that it allows one to control the number of characters printed: > hex 5 31 0001f > hex 2 8 08 > hex 3 7495 d47 While we can argue about the consistancy issues, I almost always want to control the number of digits when dealing with hex. Hence I feel this is a reasonable special case. Secondary Issues: 1) Is there a repo for pretty? I didn't see one on code.haskell.org 2) If I submit a ticket+patch to move Text.PrettyPrint.HughesPJClass (from prettyclass, Augustsson) into Text.PrettyPrint (of the 'pretty' package) would anyone object? It feels mis-placed / I feel things need consolidated. Thomas

3 9

extensible-exceptions configuration failure, ghc 6.8.1, cabal 1.2.2.0
by Anton Tayanovskyy 14 Mar '09

14 Mar '09

Hi, extensible-exceptions-0.1.1.0 # runghc Setup.hs configure Setup.hs: extensible-exceptions.cabal:21: Parse of field 'extensions' failed: It builds fine after upgrading cabal to 1.6; probably the correct dependency on cabal version is somewhere in between 1.2 and 1.6 Thanks, --A

1 0

UArray for newtypes (LogFloat)
by Felipe Lessa 09 Mar '09

09 Mar '09

Hello, So, I would like to make an UArray of LogFloat. They are a newtype of Double, but the type system can't see trough newtypes. So I wonder if it is acceptable to exploit the fact that the internal representation of newtypes don't change to use some safe unsafeCoerces and create an instance of IArray for UArray of LogFloat. I've looked at the core of the code below and it seems sane, and -Wall only warn about the orphan instance, so I would also like to ask to include this instance in logfloat package itself (I've sent a copy of this message to LogFloat's maintainer). {-# LANGUAGE MultiParamTypeClasses #-} import Data.Array.Base import Data.Array.Unboxed (UArray) import Data.Number.LogFloat import Unsafe.Coerce -- For testing below import Data.Array.Unboxed as U import Test.QuickCheck {-# INLINE from #-} from :: UArray a LogFloat -> UArray a Double from = unsafeCoerce {-# INLINE to #-} to :: UArray a Double -> UArray a LogFloat to = unsafeCoerce {-# INLINE func #-} func :: (LogFloat -> a -> LogFloat) -> (Double -> a -> Double) func = unsafeCoerce instance IArray UArray LogFloat where {-# INLINE bounds #-} bounds = bounds . from {-# INLINE numElements #-} numElements = numElements . from {-# INLINE unsafeArray #-} unsafeArray lu = to . unsafeArray lu . unsafeCoerce {-# INLINE unsafeAt #-} unsafeAt = unsafeCoerce . unsafeAt . from {-# INLINE unsafeReplace #-} unsafeReplace arr = to . unsafeReplace (from arr) . unsafeCoerce {-# INLINE unsafeAccum #-} unsafeAccum f arr = to . unsafeAccum (func f) (from arr) {-# INLINE unsafeAccumArray #-} unsafeAccumArray f initialValue lu = to . unsafeAccumArray (func f) (unsafeCoerce initialValue) lu test1 :: [Double] -> Bool test1 elms' = elms == U.elems arr where arr :: UArray Int LogFloat arr = U.listArray (1, length elms) elms elms = map (logFloat . abs) elms' test2 :: [Double] -> Bool test2 elms' = product elms == arr U.! 1 where arr :: UArray Int LogFloat arr = U.accumArray (*) 1 (1, 1) [(1,x) | x <- elms] elms = map (logFloat . abs) elms' main :: IO () main = quickCheck test1 >> quickCheck test2 -- Felipe.

3 2

ANN: Future 1.1.0 concurrency library
by ChrisK 09 Mar '09

09 Mar '09

Hello, As a side effect of the discussion of the new C++ future/promise features at http://lambda-the-ultimate.org/node/3221 I have implemented a Haskell package called "future" at http://hackage.haskell.org/cgi-bin/hackage-scripts/package/future This ought to do what C++ standard futures/promises do, plus a bit more. The main operation is > forkPromise :: IO a -> IO (Promise a) This sets the "IO a" operation running in a fresh thread. The eventual result can be accessed in many ways (non-blocking, blocking, blocking with timeout). > let one :: Int; one = 1 > p <- forkPromise (return (one+one)) > x <- get > y <- wait x is an Int with value 2. y is an (Either SomeException Int) with value (Right 2). The useful thing about futures, as opposed to various IVar packages, is handling the case where the forked operation ends with an exception. The exception becomes the return value of the promise. The "get" operation rethrows it, the "wait" operation returns it as (Left ...). There is also an "abort" command to kill a promise. The dead promise may then have an exceptions as its value. The "plus a bit more" than C++ is the nonblocking "addTodo" feature. This takes a continuation function from the "Either SomeException a" to an IO operation. These continuation functions get queued and they are run immediately after the the forked operation completes. Once completed any new "addTodo" continuations run immediately. These continuations allow you to race a list of action and take the first one done, or to collect the answers as they complete into a Chan. Both of those options are demonstrated in Future.hs as racePromises and forkPromises. It should be safe to use "unsafePerformIO . get" or "unsafePeformIO . wait" to get lazy access to the result, which is itself immutable once set. Cheers, Chris

2 1

Re: UArray for newtypes (LogFloat)
by Felipe Lessa 07 Mar '09

07 Mar '09

On Sat, Mar 7, 2009 at 9:10 PM, wren ng thornton <wren(a)freegeek.org> wrote: > You can replace many of the coercions by using logToLogFloat and > logFromLogFloat. Those give an isomorphism without doing log/exp, which is > specialized for Double to be id (except logToLogFloat also checks isNaN). I used unsafeCoerce for saving the check cost as we know it is valid. > Though, as a general matter it seems that adding "deriving (IArray UArray)" > to the newtype declaration is sufficient. Doesn't even require > GeneralizedNewtypeDeriving. I'll push out a new release soon. Whoa, that's great news for me, didn't know it was possible. And thanks for acting so promptly. :) -- Felipe.

1 0

Re: [Haskell] string type class
by Brandon S. Allbery KF8NH 06 Mar '09

06 Mar '09

On 2009 Mar 6, at 11:13, Wolfgang Jeltsch wrote: > Am Freitag, 6. März 2009 13:33 schrieb Matthew Pocock: >> It seems every time I look at hackage there is yet another stringy >> datatype. For lots of apps, the particular stringy datatype you use >> matters >> for performance but not algorithmic reasons. Perhaps this is a good >> time >> for someone to propose a stringy class? > > There is already the class IsString which was introduced for > overloaded string > literals. > > However, the name is terrible. No other Haskell class I know of has > an “Is” at > its beginning. Classes don’t name properties (IsNum, IsMonoid, Has…). But their proper names were available. "String" is already taken for a concrete type, which complicates things; "IsString" was the simplest answer (and possibly avoided bikeshedding by being the answer nobody liked :) > Maybe you can also try to convince the masters of the IsString class > to change > the class name. My previous attempts through mailing list e-mails > seemed to > have no effect. :-( I think the problem here is you need to get buy-in from everyone involved, which includes libraries@ (String), ghc (IsString is recognized in order to enable string overloading), ByteString, and potentially anyone who uses any of the above. That said, if you want to officially propose it you need to read up on how to properly propose such changes to libraries(a)haskell.org. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery(a)kf8nh.com system administrator [openafs,heimdal,too many hats] allbery(a)ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

1 0

containers: to be or not to be (strict, in this case)?
by Claus Reinke 05 Mar '09

05 Mar '09

[addressing libraries@ as the maintainer of containers] summary: could we please have equal support for all container operations, parameterised by element strictness? We are now starting to see issues with container strictness almost as often as we used to see the foldl/foldl' issue (the most recent example on cafe even used foldl' to accumulate an IntMap, unfortunately running into the non-strict nature of unionWith). As with foldl' itself, this is only partially a learning from experience issue: foldl' wasn't always available, and containers is rather inconsistent about supporting (element-)strict operations (Data.Map offers insertWith', Data.IntMap doesn't, neither offers strict unionWith; Data.Set is completely ambivalent about element strictness, depending on whether or not comparison is used). For the case of Maps, a partial workaround is known, namely to tie the availability of keys to evaluation of values. But this only works if key and value are supplied from the outside - which is not the case for the *With* family of functions (the supplied operation is applied to the old value, from within the Map, and the new value, from outside - there is no leverage to apply strictness), nor for map. Another workaround is to define your own strict insertWith', then to avoid the non-strict parts of the API: insertWith' op (k,v) m = maybe (IM.insert k v m) (\old->((IM.insert k) $! (v `op` old)) m) (IM.lookup k m) Apart from costing an extra lookup, that cannot be the intended way to use the API. If possible, I'd like to see both element-strict and element-non-strict containers supported, with otherwise the same APIs, and without a separate strict-containers package. The obvious disadvantage of code duplication (Data.Map has two definitions of insertWith) could perhaps be avoided, by parameterising the code over element strictness, as demonstrated here for Data.IntMap.insertWith: insertWithKey :: (Key -> a -> a -> a) -> Key -> a -> IntMap a -> IntMap a insertWithKey = insertWithKeyS ($) insertWithKey' :: (Key -> a -> a -> a) -> Key -> a -> IntMap a -> IntMap a insertWithKey' = insertWithKeyS ($!) type Strictness c a = (a -> c a) -> (a -> c a) -- constructor transformers insertWithKeyS :: Strictness IntMap a -> (Key -> a -> a -> a) -> Key -> a -> IntMap a -> IntMap a insertWithKeyS ($) f k x t = case t of Bin p m l r | nomatch k p m -> join k (Tip k $ x) p t | zero k m -> Bin p m (insertWithKeyS ($) f k x l) r | otherwise -> Bin p m l (insertWithKeyS ($) f k x r) Tip ky y | k==ky -> Tip k $ (f k x y) | otherwise -> join k (Tip k $ x) ky t Nil -> Tip k $ x The idea being to abstract over every application of the container constructors to the element type, then to supply either strict or non-strict application. Ultimately, one might prefer a type-constructor-based abstraction instead, to gain additional performance, but this should be at least as good as the current situation (perhaps with an INLINE on the parameterised versions), without the duplication. Btw, this variant is slightly stricter than Data.Map.insertWith', applying the strictness not only to the function passed in, but to all IntMap construction from the element type (seemed more consistent that way..). Claus

4 4

memory issues with cabal
by Paul Brown 04 Mar '09

04 Mar '09

Hi, All -- I'm having some issues getting cabal-install to upgrade itself to the current version (Cabal 1.6.0.2, cabal-install 0.6.2): > $ cabal install Cabal cabal-install > Resolving dependencies... > cabal: memory allocation failed (requested 2097152 bytes) I've tried various combinations of ghc options and RTS options passed in without success. The machine has plenty of horsepower for the task (8 cores, 20GB of RAM; Mac OS X 10.5.6, ghc 6.10.0) if I could convince cabal to use it... Any magic flags or tricks for this one? Thanks in advance. Paul Brown prb(a)mult.ifario.us http://mult.ifario.us http://www.linkedin.com/in/paulrbrown

2 2