- Haskell-Cafe - Haskell.org

warp and http-conduit on concurrent threads on windows
by Lars Kuhtz 28 Mar '13

28 Mar '13

Hi, I'd like to know what is wrong with the following program on windows8 (GHC 7.4.2, 32bit): {-# LANGUAGE OverloadedStrings #-} {-# LANGUAGE ScopedTypeVariables #-} module Main where import Control.Concurrent.Async import qualified Control.Exception as E import Network.HTTP.Conduit import Network.HTTP.Types import Network.Wai import Network.Wai.Handler.Warp query port = E.catch (simpleHttp ("http://haskell.org:" ++ show port) >>= print . take 10 . show) (\(e :: HttpException) -> print $ "caught: " ++ show e) listen = run 8080 $ \_ -> return $ responseLBS ok200 [] "abc" main = do withAsync (query 12345) $ \a -> do withAsync listen $ \b -> do wait a wait b I compile the program with "ghc --make -threaded Main.hs" and run it as "./Main +RTS -N". On POSIX systems this works as expected. Even if the failing "query" runs in a forever loop the "listen" thread responds promptly to requests. On windows the "listen" thread seems blocked by the failing "query" thread. Sometimes the query returns (relatively) prompt. But sometimes (about a third of all runs) it takes very long (about 20 sec). Also, sometimes it returns with "Connection timed out (WSAETIMEDOUT)", sometimes with "getAddrInfo: does not exist (error 11003)", and sometimes just with "FailedConnectionException". The fact that the "listen" thread is blocked seems to contradict the following quote form the documentation of Control.Concurrent: -- Quote from Control.Concurrent -- Using forkOS instead of forkIO makes no difference at all to the scheduling behaviour of the Haskell runtime system. It is a common misconception that you need to use forkOS instead of forkIO to avoid blocking all the Haskell threads when making a foreign call; this isn't the case. To allow foreign calls to be made without blocking all the Haskell threads (with GHC), it is only necessary to use the -threaded option when linking your program, and to make sure the foreign import is not marked unsafe. -- End Quote -- By the way: using withAsyncBound instead of withAsync seems to improve (but not completely solve) the issue. Thanks, Lars

2 2

nice pattern from simple converging series
by Christopher Howard 28 Mar '13

28 Mar '13

I made a nice little pattern from just a few lines of Haskell (mostly code comments) using gloss. It is very kindergarten in terms of mathematical art, but the idea was to illustrate that in a pretty short amount of time, and a small amount code, you could easily translate simple math concepts into geometry on your screen. http://frigidcode.com/code/haskell-series-circles/ -- frigidcode.com

1 0

Parallel Data.Vector.generate?
by Myles C. Maxfield 28 Mar '13

28 Mar '13

Hello all. I'm using the Data.Vector.generate function with a complicated creation function to create a long vector. Is it possible to parallelize the creation of each element? Alternatively, if there was something like parMap for vectors, I suppose I could pass id to Data.Vector.generate and use parMap. Does something like this exist? Thanks, Myles C. Maxfield

2 2

duplicate type signatures
by Heinrich Hördegen 28 Mar '13

28 Mar '13

Dear all, why is this allowed (GHCi, version 7.4.1): main :: IO () main = do let a, a :: Int a = 5 print a but this not: main :: IO () main = do let a :: Int a :: Int a = 5 print a Is there a deeper sens or is it just a little bit inconsistent? Heinrich

2 1

Re: [Haskell-cafe] [extension]syntactic sugar for maps
by Eli Frey 28 Mar '13

28 Mar '13

> Sorry, I forgot to explain (probably because I'm too used to it). I am referring to a syntax for easy creation of maps. Something equivalent to lists: > > to build a list: [ 1, 2, 3] > to build a map; { 1, "one", 2, "two", 3, "three"} > > Without it I am always forced to use fromList. This looks like something to use records for, or in any case something where association list performance is not an issue. If you just want to store some configuration-like structure and pass it around, a record is great for this. You might find where in other languages you would simply leave a key "null", in Haskell you can just fill it with a Nothing. Maps (hash or binary-tree) really pay off when they are filled dynamically with massive numbers of associations. I find when I am ending up in this scenario, I am generating my map programatically, not writing it as a literal. Sometimes people even write maps simply as functions and not even as a data-structure. > myMap char = case char of > 'a' -> 1 > 'b' -> 2 > 'c' -> 3 Perhaps you could describe a situation you are in where you are wanting this, and we could see if there is something you can do already that is satisfying and solves your problem. On Wed, Mar 27, 2013 at 12:59 PM, Eli Frey <eli.lee.frey(a)gmail.com> wrote: > > http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists comes to mind. > > This assumes you can turn ANY list into a thing. Maps only make sense to > be constructed from association list. If I've got a [Char], how do I make > a map form it? > > > On Wed, Mar 27, 2013 at 12:56 PM, Nicolas Trangez <nicolas(a)incubaid.com>wrote: > >> On Wed, 2013-03-27 at 21:30 +0200, Răzvan Rotaru wrote: >> > I am terribly missing some syntactic sugar for maps (associative data >> > structures) in Haskell. I find myself using them more than any other >> > data >> > structure, and I think there is no big deal in adding some sugar for >> > this >> > to the language. I could not find out whether such an extension is >> > beeing >> > discussed. If not, I would like to propose and extension. Any help and >> > suggestions are very welcome here. Thanks. >> >> http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists comes to mind. >> >> Nicolas >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe(a)haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> > >

2 1

[extension]syntactic sugar for maps
by Răzvan Rotaru 27 Mar '13

27 Mar '13

Hi, I am terribly missing some syntactic sugar for maps (associative data structures) in Haskell. I find myself using them more than any other data structure, and I think there is no big deal in adding some sugar for this to the language. I could not find out whether such an extension is beeing discussed. If not, I would like to propose and extension. Any help and suggestions are very welcome here. Thanks. Also related to the topic: 1/ Is there a list of proposals for extensions to Haskell that has currently been accepted in the new standard? I have not found one on Haskell' ( http://hackage.haskell.org/trac/haskell-prime/query?status=new&status=assig…) but it looks outdated. No mentions to the new standard! 2/ I have seen somewhere a statement that a new language standard will be published yearly. Didn't happen until now. Is there even a new standard on the way? Cheers, Răzvan

4 4

Re: [Haskell-cafe] Pattern matching with singletons
by Richard Eisenberg 27 Mar '13

27 Mar '13

Hello Paul, > ----- Forwarded message from Paul Brauner <polux2001(a)gmail.com> ----- <snip> > - is a ~ ('CC ('Left 'CA)) a consequence of the definitions of SCC, > SLeft, ... (in which case GHC could infer it but for some reason can't) > - or are these pattern + definitions not sufficient to prove that a > ~ ('CC ('Left 'CA)) no matter what? The first one. GHC can deduce that (a ~ ('CC ('Left b))), for some fresh variable (b :: TA), but it can't yet take the next step and decide that, because TA has only one constructor, b must in fact be 'CA. In type-theory lingo, this deduction is called eta-expansion. There have been on-and-off debates about how best to add this sort of eta-expansion into GHC, but all seem to agree that it's not totally straightforward. For example, see GHC bug #7259. There's a non-negligible chance I will be taking a closer look into this at some point, but not for a few months, so don't hold your breath. I'm not aware of anyone else currently focusing on this problem either, I'm afraid. I'm glad you're finding use in the singletons package! Let me know if I can be of further help. Richard

2 1

my take at knucleotide
by Branimir Maksimovic 27 Mar '13

27 Mar '13

Hi, I have tried to implement knucleotide benchmark program this time:http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=knuc… Implementation is shorter (uses hashtable from hashtables package),but two time slower then current Haskell entry ( which is too low levelfor my taste :)).What is interesting is that if I try to place Int64 as a key tohash table, performance is even slower.Strange that dropping and taking from bytestring would befaster than packing string in 64 bit int and directly indexing. If someone can see something that can bring performance on parwith current haskell entry , I would post it , otherwise no point,except that program is shorter and not low level. {-# Language BangPatterns #-}---- The Computer Language Benchmarks Game-- http://benchmarksgame.alioth.debian.org/---- Contributed by Branimir Maksimovic--import Data.Charimport Data.Listimport Data.IORefimport qualified Data.HashTable.IO as Himport qualified Data.ByteString.Char8 as Simport Control.Concurrentimport Text.Printf main = do s <- S.getContents let content = (S.map toUpper . S.concat . tail . dropWhile (\l->not $ S.isPrefixOf (S.pack ">THREE") l) . S.lines) s mapM_ (execute content) actions data Actions = I Int | S Stringactions = [I 1,I 2, S "GGT",S "GGTA",S "GGTATT",S "GGTATTTTAATT",S "GGTATTTTAATTTATAGT"]execute content (I i) = writeFrequencies content iexecute content (S s) = writeCount content s writeFrequencies input size = do ht <- tcalculate input size lst <- H.foldM (\lst (k,v)->do v' <- readIORef v return $ insertBy (\(_,x) (_,y)->y `compare` x) (k,v') lst) [] ht let sum = fromIntegral ((S.length input) + 1 - size) mapM_ (\(k,v)-> do printf "%s %.3f\n" (S.unpack k) ((100 * (fromIntegral v)/sum)::Double)) lst putChar '\n' writeCount input string = do let size = length string ht <- tcalculate input size res <- H.lookup ht (S.pack string) case res of Nothing -> putStrLn $ string ++ " not found..." Just v -> do r <- readIORef v printf "%d\t%s\n" r (string::String) tcalculate input size = do let l = [0..7] actions = map (\i -> (calculate input i size (length l))) l vars <- mapM (\action -> do var <- newEmptyMVar forkIO $ do answer <- action putMVar var answer return var) actions result <- newTable results <- mapM takeMVar vars mapM_ (\ht -> H.foldM (\lst (k,v) -> do res <- H.lookup lst k case res of Nothing -> do r1 <- readIORef v r2 <- newIORef r1 H.insert lst k r2 Just v1 -> do r1 <- readIORef v1 r2 <- readIORef v writeIORef v1 (r1+r2) return lst) result ht) results return result calculate input beg size incr = do ht <- newTable let calculate' :: S.ByteString -> Int -> IO HashTable calculate' str i | i >= ((S.length input)+1 - size) = return ht | otherwise = do res <- H.lookup ht k case res of Nothing -> do !r <- newIORef 1 H.insert ht k r Just v -> do !r <- readIORef v writeIORef v (r+1) calculate' (S.drop incr str) (i+incr) where k = S.take size str calculate' (S.drop beg input) beg type HashTable = H.BasicHashTable S.ByteString (IORef Int) newTable :: IO HashTablenewTable = H.new

2 4

Word8 literals in ByteString haddock?
by Niklas Hambüchen 27 Mar '13

27 Mar '13

Hey, according to http://hackage.haskell.org/packages/archive/bytestring/0.10.2.0/doc/html/Da… I can write: split '\n' "a\nb\nd\ne" Can I really do that? I don't know of a way to make a '\n' literal be a Word8, so maybe these Haddocks are wrong? I guess they would apply for Data.ByteString.Char8, but this is Data.ByteString. Or is there a way? Niklas

2 1

Future of MonadCatchIO
by Arie Peterson 26 Mar '13

26 Mar '13

Hi all, The function 'block' and 'unblock' (from Control.Exception) have been deprecated for some time, and are apparantly now being removed (in favour of 'mask'). Generalisations of these functions are (part of) the interface of MonadCatchIO-transformers (the 'MonadCatchIO' class has methods 'block' and 'unblock'). So, the interface would have to change to keep up with base. I'm inclined to deprecate MonadCatchIO-transformers itself, in favour of monad-control. I suspect that most clients do not use 'block' or 'unblock' directly, but use only derived functions, like 'bracket'. (I have partly confirmed this, by inspecting some reverse dependencies on hackage.) This allow an easy transition to monad-control: in many cases, only imports will need to be changed. In the minority of cases where 'block' and 'unblock' are used and/or instances of MonadCatchIO are defined, code will need to be updated. There is a difference in functionality between MonadCatchIO and monad-control. In the former, 'bracket' will not perform the final action if the main action is an ErrorT that throws an error (in contrast with exceptions in the underlying IO monad). In monad-control, 'bracket' will perform the final action in this case. (See this discussion for background: <http://www.haskell.org/pipermail/haskell-cafe/2010-October/084890.html>.) Probably, in most use cases the behaviour of monad-control is preferred. This seems to be the case also for snap, which uses MonadCatchIO-transformers, but defines its own variant of 'bracket' to get the right behaviour. Would anyone have a problem with a deprecation of MonadCatchIO-transformers, and a failure to update it to work with a base without 'block' and 'unblock'? Regards, Arie

5 7