- Haskell-Cafe - Haskell.org

Maintainer of pngload listening?
by Daniel Trstenjak 30 Jun '12

30 Jun '12

Hi, Marko Lauronens email address from the package is invalid, so I'm trying to reach him this way. pngload doesn't compile with ghc >= 7.2 because of it's dependency to base and haskell98. Greetings, Daniel

3 3

Slowdown with GHC when using multiple CPUs
by David Powell 29 Jun '12

29 Jun '12

I recently ran into a problem writing a program that I hoped I could speed up by running over multiple CPUs. I want non-haskell users to be able to run the tool and take advantage of multiple CPUs. *But* there is a serious slowdown when the RTS is run with -N and some of the CPUs are already busy. This is already mentioned in the GHC docs, but the problem I experienced was more serious than I expected causing a slowdown of around 2x compared to running with a single CPU. I reproduced the problem with the following code from the haskell wiki: {-# LANGUAGE BangPatterns #-} import Data.Digest.Pure.MD5 import qualified Data.ByteString.Lazy as L import System.Environment import Control.Concurrent import Control.Monad (replicateM_) main = do files <- getArgs str <- newEmptyMVar mapM_ (forkIO . hashAndPrint str) files printNrResults (length files) str printNrResults i var = replicateM_ i (takeMVar var >>= putStrLn) hashAndPrint str f = do bs <- L.readFile f let !h = show $ md5 bs putMVar str (f ++ ": " ++ h) When run on 4 idle CPU cores, I get the following wall clock times: ./run +RTS -N1 : 20.4 sec ./run +RTS -N2 : 11.0 sec ./run +RTS -N4 : 6.7 sec When run on the same 4 core machine, but with 2 cores already busy: ./run +RTS -N1 : 23.5 sec ./run +RTS -N2 : 14.1 sec ./run +RTS -N4 : 57.8 sec <---- Blowout... This is quite a problem in practice when running on a shared server. Is there anything that can be done to address this? (I wrote up a few more details here: http://thunking.drp.id.au/2012/06/slowdown-with-ghc-when-using-multiple.html ) Thanks, -- David Powell

2 1

Help requested: naming things in conduit
by Michael Snoyman 29 Jun '12

29 Jun '12

Hi all, I'm just about ready to make the 0.5 release of conduit. And as usual, I'm running up against the hardest thing in programming: naming things. Here's the crux of the matter: in older versions of conduit, functions would have a type signature of Source, Sink, or Conduit. For example: sourceFile :: MonadResource m => FilePath -> Source m ByteString I think most people can guess at what this function does: it produces a stream of ByteStrings, which are read from the given file. Now the trick: Source (and Sink and Conduit) are all type synonyms wrapping around the same type, Pipe. Ideally, we'd like to be able to reuse functions like sourceFile in other contexts, such as producing a Conduit that calls sourceFile[1]. However, the type synonym Source over-specifies some of the type parameters to Pipe, and therefore `sourceFile` can't be used directly to create a Conduit[2]. To get around this whole problem, I've added a number of type synonyms with rank-2 types, that don't over-specify. You can see the type synonyms here[3], and more explanation of the problem here[4]. So my question is: can anyone come up with better names for these synonyms? Just to summarize here: * All of the generalized types start with a G, e.g., Source becomes GSource. * For Sinks and Conduits, if leftovers are generated, there's an L after the G (e.g., GLSink). * For Sinks and Conduits which consume all of their input and then return the upstream result, we tack on an Inf for Infinite (e.g., GInfConduit, GLInfSink). I think these names are relatively descriptive, and certain `GSink ByteString m Int` is easier to follow than `Pipe l ByteString o u m Int`, but I was wondering if anyone had some better recommendations. Michael [1] For example, maybe we want to produce `conduitFiles :: MonadResource m => Conduit FilePath m ByteString` [2] This problem exists to a smaller extent in conduit 0.4. This is the purpose of the sinkToPipe function. [3] https://github.com/snoyberg/conduit/blob/52d7bc0b551b877de92be4c87f933e3ffb… [4] https://github.com/snoyberg/conduit/blob/a853141d7b9eed047c7cc790979f73a346…

2 2

crash in hs_init_ghc
by A.M. 29 Jun '12

29 Jun '12

Hello, I am trying to load a Haskell module in a C program as a dynamically-loaded plugin via FFI. I am able to compile and link successfully, but I find the following crash. #0 0x00007f16147da9e7 in ?? () from /usr/lib/ghc/libHSrts_debug-ghc7.4.1.so #1 0x00007f16147e0970 in hs_init_ghc () from /usr/lib/ghc/libHSrts_debug-ghc7.4.1.so #2 0x00007f16147e0795 in hs_init () from /usr/lib/ghc/libHSrts_debug-ghc7.4.1.so #3 0x00007f1614a44ece in plhaskell_plmain (fcinfo=<optimized out>) at plhaskellc.c:26 #4 0x0000000000565e1a in ExecMakeFunctionResult () #5 0x00000000005682f2 in ExecProject () #6 0x000000000057849a in ExecResult () #7 0x0000000000561648 in ExecProcNode () #8 0x000000000055ea5a in standard_ExecutorRun () #9 0x0000000000628577 in PortalRunSelect () #10 0x0000000000629900 in PortalRun () #11 0x0000000000625bec in PostgresMain () #12 0x00000000005eb429 in ServerLoop () #13 0x00000000005ebd3c in PostmasterMain () #14 0x0000000000453d20 in main () In the trace above, one can see that I am linking against the debugging Haskell runtime. hs_init_ghc is called with dual NULL arguments. Is that cause for concern? I noticed that RtsStartup.c does some questionable stuff in a module context right away, such as calling "setlocale". Are there other things I need to watch out for? Do I need to build ghc from source in order to debug this further? Any advice would be appreciated. This is on Ubuntu 12.04. Cheers, M

1 0

Network.Curl curiosity
by Michael Orlitzky 29 Jun '12

29 Jun '12

I've been fighting with this silly bug: I have two functions using curl (Network.Curl) for logging in via POST and downloading pages via GET. They do the usual boring stuff; cookies go in a text file whose path is passed in to both functions. They work great individually. But, I'm calling them sequentially: cj <- make_cookie_jar li_result <- log_in cj username password html <- get_page (Just cj) my_article The symptom that I noticed was that the call to get_page wasn't using the cookies. I looked in the cookie file -- they're all there. And when I call get_page from ghci (with the same cookie file), it works. It turns out that between the calls to log_in and get_page, the cookie file is empty. The stupidest possible solution that works is, cj <- make_cookie_jar li_result <- log_in cj username password putStrLn "Waiting one second..." thread_sleep 1 html <- get_page (Just cj) my_article And this program is not at all time sensitive, so that actually works for me. But now I'm curious. Does anyone have an idea what sort of sorcery is going on? Here's the rest of log_in if it's useful. log_in :: FilePath -> String -> String -> IO Bool log_in cookie_jar username password = withCurlDo $ do -- Create a curl instance. curl <- initialize -- Perform the request, and get back a CurlResponse object. -- The cast is needed to specify how we would like our headers -- and body returned (Strings). resp <- do_curl_ curl login_url curl_opts :: IO CurlResponse -- Pull out the response code as a CurlCode. let code = respCurlCode resp case code of CurlOK -> return True error_code -> do hPutStrLn stderr ("HTTP Error: " ++ (show error_code)) -- If an error occurred, we want to dump as much information as -- possible. If this becomes a problem, we can use respGetInfo -- to query the response object for more information return False where post_submit :: String post_submit = submit_field ++ "=Log+In" post_username :: String post_username = username_field ++ "=" ++ username post_password :: String post_password = password_field ++ "=" ++ password post_data :: [String] post_data = [post_username, post_password, post_submit] post_opts :: [CurlOption] post_opts = [ CurlCookieSession True, CurlCookieJar cookie_jar, CurlPost True, CurlPostFields post_data ] curl_opts :: [CurlOption] curl_opts = default_curl_opts ++ post_opts default_curl_opts :: [CurlOption] default_curl_opts = [ -- The Global cache is not thread-friendly. CurlDNSUseGlobalCache False, -- And we don't want to use a DNS cache anyway. CurlDNSCacheTimeout 0, -- Follow redirects. CurlFollowLocation True, -- Give it a little time... CurlTimeout 45, -- For debugging. CurlVerbose True ]

1 0

Re: [Haskell-cafe] Martin Odersky on "What's wrong with Monads"
by Donn Cave 28 Jun '12

28 Jun '12

To be fair, while it's great that Functor et al. are available to help solve problems like that with a Tree data structure, in the present context it mostly shows that a trivial example was used to illustrate the problem. Unless I'm missing how this generic fold functionality solves the more general problem. Quoth Alberto G. Corona, > ... There is no such problem in imperative languages, which work > ever in an hardwired IO monad. Or to look at it from the other direction, the problem with Haskell is that it allows the programmer to write non-IO functions. To the extent that's a real problem, the solution would obviously be to exercise some restraint with the pure code and write more in the IO monad. If you will humor me, we understand that this code is equally satisfactory from a mathematical perspective and there's no crime in it. But does it help with the `flags problem?' Suppose that functions f and g both have IO types; f calls g, and g has optional behavior depending on some IO value computed previously, the flag. The way I understand it, I can accomplish this without passing the flag around: with an IORef. What's less clear to me is whether Haskell really supports the module level accessible IORef value I need. Also known as "top level mutable state." Is the NOINLINE pragma I've been using with GHC, really a sound and reliable practice that we're reasonably confident will be supported by other compilers? It feels to me like I'm pulling a weird trick, to do something that's trivial in other programming languages. Maybe that's part of the problem, that imperative programming receives something a little short of full support in Haskell, inasmuch as basic features like top level mutable state require relatively arcane incantations. Donn

1 0

ghc-7.4 on CentOS-5.8 ?
by Johannes Waldmann 28 Jun '12

28 Jun '12

Dear all, I need a recent ghc on a not-so-recent (?) CentOS. The ghc binary package (7.2 or 7.4) does not work because of a mismatch in the libc version. ghc-7.0 is working but when I use it to compile 7.4, it breaks with some linker error (relocation R_X86_64_PC32 ...) it also suggests "recompile with -fPIC" but I don't see how. (In this particular case, I absolutely cannot change/update the OS.) Thanks, J.W.

5 5

Fwd: Martin Odersky on "What's wrong with Monads"
by Strake 28 Jun '12

28 Jun '12

On 26/06/2012, Nathan Howell <nathan.d.howell(a)gmail.com> wrote: > On Tue, Jun 26, 2012 at 3:19 PM, Tillmann Rendel > <rendel(a)informatik.uni-marburg.de> wrote: >> All fine so far. Now, consider the following additional requirement: "If >> the >> command-line flag --multiply is set, the function amount computes the >> product instead of the sum." >> >> How would you implement this requirement in Haskell without changing the >> line "amount (Leaf x) = x"? > > One option is to encode the desired behavior at the type level. By > extended the data type slightly and adding a Functor instance, > selecting between a product and a sum can be done using their Monoid > newtypes: ... Better yet, use foldMap: > import Data.Monoid > import Data.Foldable > import System.Environment > data Tree a = Leaf a | Branch (Tree a) (Tree a) > instance Functor Tree where > f `fmap` Leaf x = Leaf (f x) > f `fmap` Branch x y = Branch (fmap f x) (fmap f y) > instance Foldable Tree where > foldMap f (Leaf x) = f x > foldMap f (Branch s t) = foldMap f s <> foldMap f t > main :: IO () > main = do > args <- getArgs > let val :: Tree Int > val = Branch (Leaf 8) (Leaf 18) > let getResult :: Tree Int -> Int > getResult = case args of > ["--multiply"] -> getProduct . foldMap Product > _ -> getSum . foldMap Sum > print . getResult $ val Yet better yet: > {-# LANGUAGE DeriveFunctor, DeriveFoldable #-} > import Data.Monoid; > import Data.Foldable; > import System.Environment > data Tree a = Leaf a | Branch (Tree a) (Tree a) > deriving (Functor, Foldable); > ... (^_^) -- Strake

1 0

Data.Bitmap, readBitmap exception
by Alexander Foremny 28 Jun '12

28 Jun '12

Hello, I am using bitmap-0.2 [1] to load a Bitmap file [2]. However, the following sample GHCi session fails for me. > Prelude Data.Bitmap Data.Bitmap.Pure.File> readBitmap "b.bmp" :: IO (Bitmap Word8) > *** Exception: Data/Bitmap/Internal.hs:(63,17)-(67,15): Non-exhaustive patterns in case I downloaded the sources of bitmap-0.2 from Hackage and modified the relevant function by appending the last line. > decodeCType :: CInt -> PixelComponentType > decodeCType k = case k of > 1 -> PctWord8 > 2 -> PctWord16 > 3 -> PctWord32 > 4 -> PctFloat > _ -> error $ "decodeCType: unexpected integer (" ++ show k ++ ")" With this modification the same GHCi session given above results in the following error. > Prelude Data.Bitmap Data.Bitmap.Pure.File> readBitmap "b.bmp" :: IO (Bitmap Word8) > *** Exception: decodeCType: unexpected integer (7077888) I don't have any idea where 7077888 comes from. Am I doing something wrong? Is my bitmap corrupted in some way? The number 7077888 has no apparent significance except that it is a perfect cube [3]. So I guess this is not a problem with endianness. In fact as far as I can tell `decodeCType` is only called on `(PixelComponent t => c_type t)` and `c_type t` only yields integer values in the (inclusive) range of 1 to 4. That is if I am not missing some orphaned instance. Could anyone please enlighten me what is happening and if I am doing something wrong? In case this is relevant: I am using bitmap-0.2 from Hackage with GHC 7.4.1 on a 3.2.20 kernel i686 architecture Linux. Regards, Alexander Foremny [1] http://hackage.haskell.org/package/bitmap [2] https://www.dropbox.com/s/pyutvni9vx6f6mo/b.bmp [3] http://www.wolframalpha.com/input/?i=7077888

3 4

Re: [Haskell-cafe] Martin Odersky on "What's wrong with Monads"
by Tillmann Rendel 28 Jun '12

28 Jun '12

Hi Rico, Rico Moorman wrote: >> data Tree = Leaf Integer | Branch (Tree Integer) (Tree Integer) >> >> amount:: Tree -> Integer >> amount (Leaf x) = x >> amount (Branch t1 t2) = amountt1 + amountt2 >> >> [...] additional requirement: "If the command-line flag --multiply is set, >> the function amount computes the product instead of the sum." >> >> How would you implement this requirement in Haskell without changing the >> line "amount (Leaf x) = x"? > The (for me at least) most obvious way to do this would be, to make the > operation to be applied to determine the amount (+ or *) an explicit > parameter in the function's definition. > > data Tree a = Leaf a > | Branch (Tree a) (Tree a) > amount :: (a -> a -> a) -> Tree a -> a > amount fun (Leaf x) = x > amount fun (Branch t1 t2) = amount fun t1 `fun` amount fun t2 I agree: This is the most obvious way, and also a very good way. I would probably do it like this. > Which drawbacks do you see besides increased verbosity? Well, you did change the equation "amount (Leaf x) = x" to "amount fun (Leaf x) = x". In a larger example, this means that you need to change many lines of many functions, just to get the the value of fun from the point where it is known to the point where you need it. > [...] I am wondering which ways of doing this in Haskell you mean. I thought of the following three options, but see also Nathan Howells email for another alternative (that is related to my option (1) below): (1) Implicit parameters: {-# LANGUAGE ImplicitParams #-} data Tree = Leaf Integer | Branch Tree Tree amount :: (?fun :: Integer -> Integer -> Integer) => Tree -> Integer amount (Leaf x) = x amount (Branch t1 t2) = ?fun (amount t1) (amount t2) (2) Lexical Scoping: data Tree = Leaf Integer | Branch Tree Tree amount :: (Integer -> Integer -> Integer) -> Tree -> Integer amount fun = amount where { amount (Leaf x) = x ; amount (Branch t1 t2) = fun (amount t1) (amount t2) } (3) UnsafePerformIO: import System.IO.Unsafe (unsafePerformIO) data Tree = Leaf Integer | Branch Tree Tree amount :: Tree -> Integer amount (Leaf x) = x amount (Branch t1 t2) = fun (amount t1) (amount t2) where fun = unsafePerformIO ... I'm not happy with any of these options. Personally, I would probably go ahead and transform the whole program just to get the value of fun to where it is needed. Nevertheless, having actually done this before, I understand why Martin Odersky doesn't like doing it :) Tillmann

4 3