June 2008 - Haskell-Cafe

Ubuntu and ghc
by Galchin, Vasili 05 Jun '08

05 Jun '08

Hello, https://bugs.launchpad.net/ubuntu/+source/gtk2hs/+bug/229489 .... this is almost identical to my problem. I am just trying to help others on this list who are using Ubuntu Linux to avoid my predicament! Kind regards, Vasili

11 27

re: very hard to build darcs with win32 ghc-6.8.2!
by Tim Newsham 05 Jun '08

05 Jun '08

Here's the wrapup, thanks to those who replied: - the haskell zlib package on hackage no longer requires that zlib (the C library) be prebuilt. It includes sources itself and builds and installs them using Cabal. - the haskell zlib package is not used by darcs. It links against libz.a directly. You do need to have libz.a somehow to build darcs. - the darcs link error with "SleepEx" is caused because it uses "foreign import ccall" when it should use "foreign import stdcall". Fixing the decl in src/win32/System/Posix.hs to stdcall fixes this issue. I still think its odd that ghc's "gcc" is not very useable outside of Cabal, but in this case it has no bearing on the zlib package. If you choose to build "libz.a" (the C library) from sources using this gcc it will be hard, but you could also get it from an external source (such as the prebuilt libcurl library package). Tim Newsham http://www.thenewsh.com/~newsham/

1 0

Laziness leaks
by Ronald Guida 05 Jun '08

05 Jun '08

I was looking at the real time queues in [1] and I wanted to see what would happen if I tried to write one in Haskell. The easy part was translating the real time queue from [1], p43 into Haskell. The hard part is testing to see if the rotations really happen what they should. Basically, I decided to use Debug.Trace.trace to see when rotations were actually occurring. I pushed the numbers 1 to 10 into the queue, and then I popped the queue ten times. What I found is that none of the rotations would actually take place until the first time I actually tried to /display the value/ of a popped element. What I realized is that my test driver is lazy. I figured out that I could put a bunch of 'seq' functions in the test driver to get the rotations to happen. My demonstration code is in: http://hpaste.org/8080 This leads to two questions: 1. If I find a laziness leak, is 'seq' the appropriate way to plug it? 2. Is there any way to systematically search for or detect laziness leaks?

12 17

GHCi gives type signature that won't compile.
by A A 05 Jun '08

05 Jun '08

Hi All I can successfully compile the following code using ghci import Data.Array.IArray makeArray (lower, upper) f = listArray (lower, upper) [(f i) | i <- [lower..upper] tridiagonal_solve (a, b, c, d, (lower, upper)) = x where gen_array f = (makeArray (lower, upper) f) x = gen_array x_f where x_f i | i == upper = (d_dash ! upper) | otherwise = (d_dash ! i) - (c_dash ! i) * (x ! (i + 1)) d_dash = gen_array d_dash_f where d_dash_f i | i == lower = (d ! lower) / (b ! lower) | otherwise = ((d ! i) - (d_dash ! (i - 1)) * (a ! i)) / ((b ! i) - (c_dash ! (i - 1)) * (a ! i)) c_dash = gen_array c_dash_f where c_dash_f i | i == lower = (c ! lower) / (b ! lower) | otherwise = (c ! i) / ((b ! i) - (c_dash ! (i - 1)) * (a ! i)) I then attempted to write a type signature for tridiagonal_solve. I didn't succeed at this however, all of my type signatures gave compile errors when attempting to load them in ghci. I asked in the #haskell channel, and they suggested that I try the type signature from ghci :type function. So I removed any type signatures, and reloaded the file in ghci, and typed ":type tridiagonal_solve" which produced the following output: tridiagonal_solve :: (IArray a3 e, IArray a6 e, IArray a7 e, Fractional e, Ix a, Num a, IArray a4 e, IArray a2 e, IArray a5 e, IArray a1 e, Enum a) => (a4 a e, a2 a e, a1 a e, a5 a e, (a, a)) -> a7 a e I then attempted to paste this into my code, the resulting code looking like this: import Data.Array.IArray makeArray (lower, upper) f = listArray (lower, upper) [(f i) | i <- [lower..upper]] tridiagonal_solve :: (IArray a3 e, IArray a6 e, IArray a7 e, Fractional e, Ix a, Num a, IArray a4 e, IArray a2 e, IArray a5 e, IArray a1 e, Enum a) => (a4 a e, a2 a e, a1 a e, a5 a e, (a, a)) -> a7 a e tridiagonal_solve (a, b, c, d, (lower, upper)) = x where gen_array f = (makeArray (lower, upper) f) x = gen_array x_f where x_f i | i == upper = (d_dash ! upper) | otherwise = (d_dash ! i) - (c_dash ! i) * (x ! (i + 1)) d_dash = gen_array d_dash_f where d_dash_f i | i == lower = (d ! lower) / (b ! lower) | otherwise = ((d ! i) - (d_dash ! (i - 1)) * (a ! i)) / ((b ! i) - (c_dash ! (i - 1)) * (a ! i)) c_dash = gen_array c_dash_f where c_dash_f i | i == lower = (c ! lower) / (b ! lower) | otherwise = (c ! i) / ((b ! i) - (c_dash ! (i - 1)) * (a ! i)) When I attempt to load this into ghci, I recieve the following error: [1 of 1] Compiling Main ( main.lhs, interpreted ) main.lhs:29:11: Could not deduce (IArray a1 e) from the context (IArray a3 e, IArray a6 e, IArray a7 e, Fractional e, Ix a2, Num a2, IArray a4 e, IArray a21 e, IArray a5 e, IArray a11 e, Enum a2) arising from a use of `gen_array' at main.lhs:29:11-28 Possible fix: add (IArray a1 e) to the context of the type signature for `tridiagonal_solve' In the expression: gen_array d_dash_f In the definition of `d_dash': d_dash = gen_array d_dash_f where d_dash_f i | i == lower = (d ! lower) / (b ! lower) | otherwise = ((d ! i) - (d_dash ! (i - 1)) * (a ! i)) / ((b ! i) - (c_dash ! (i - 1)) * (a ! i)) In the definition of `tridiagonal_solve': tridiagonal_solve (a, b, c, d, (lower, upper)) = x where gen_array f = (makeArray (lower, upper) f) x = gen_array x_f where x_f i | i == upper = (d_dash ! upper) | otherwise = (d_dash ! i) - (c_dash ! i) * (x ! (i + 1)) d_dash = gen_array d_dash_f where d_dash_f i | i == lower = (d ! lower) / (b ! lower) | otherwise = ((d ! i) - (d_dash ! (i - 1)) * (a ! i)) / ((b ! i) - (c_dash ! (i - 1)) * (a ! i)) c_dash = gen_array c_dash_f where c_dash_f i | i == lower = (c ! lower) / (b ! lower) | otherwise = (c ! i) / ((b ! i) - (c_dash ! (i - 1)) * (a ! i)) main.lhs:35:11: Could not deduce (IArray a e) from the context (IArray a3 e, IArray a6 e, IArray a7 e, Fractional e, Ix a2, Num a2, IArray a4 e, IArray a21 e, IArray a5 e, IArray a11 e, Enum a2) arising from a use of `gen_array' at main.lhs:35:11-28 Possible fix: add (IArray a e) to the context of the type signature for `tridiagonal_solve' In the expression: gen_array c_dash_f In the definition of `c_dash': c_dash = gen_array c_dash_f where c_dash_f i | i == lower = (c ! lower) / (b ! lower) | otherwise = (c ! i) / ((b ! i) - (c_dash ! (i - 1)) * (a ! i)) In the definition of `tridiagonal_solve': tridiagonal_solve (a, b, c, d, (lower, upper)) = x where gen_array f = (makeArray (lower, upper) f) x = gen_array x_f where x_f i | i == upper = (d_dash ! upper) | otherwise = (d_dash ! i) - (c_dash ! i) * (x ! (i + 1)) d_dash = gen_array d_dash_f where d_dash_f i | i == lower = (d ! lower) / (b ! lower) | otherwise = ((d ! i) - (d_dash ! (i - 1)) * (a ! i)) / ((b ! i) - (c_dash ! (i - 1)) * (a ! i)) c_dash = gen_array c_dash_f where c_dash_f i | i == lower = (c ! lower) / (b ! lower) | otherwise = (c ! i) / ((b ! i) - (c_dash ! (i - 1)) * (a ! i)) My question is, what should the type signature for tridiagonal_solve actually be? I would like one that doesn't limit the generality of tridiagonal_solve because I would like to pass different array types in the one function invocation, as long as they have the same index and element types. I'm happy if other functions need type signatures as well. I'm using ghc 6.8.2 on windows, though I get a similar issue with ghc 6.4.1. Thanks. Clinton

3 2

example of FFI FunPtr
by Galchin, Vasili 05 Jun '08

05 Jun '08

Hello, I want to model a Haskell function that is a callback from C. I have only found one example in the unix package's Semaphore.hsc, which apparently is not used. I want to be able to marshall a Haskell function that is a first class citizen residing in a Haskell data type and pass to a C function via FFI. Are there examples of this? Thanks, Vasili

2 2

HDBC-odbc 1.1.4.4 fixes Windows linking problems
by John Goerzen 05 Jun '08

05 Jun '08

Hi, HDBC-odbc version 1.1.4.4 has been uploaded to Hackage. It fixes the problems some here have encountered regarding ODBC crashes or other similar odd behavior on Windows. Thanks to Andrew Appleyard for tracking down the problem and sending me a patch. The detailed explanation, if you're interested, is a ccall vs. stdcall issue in FFI. Details here: http://git.complete.org/hdbc-odbc?a=commit;h=cca312d9891d227094494dcee518f4… People that are not using HDBC-odbc on Windows will not find any difference or other changes in this version. -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715

3 5

library for drawing charts
by Peter Gammie 05 Jun '08

05 Jun '08

Hello, Has anyone got some code for drawing charts? I don't mean graphs of functions, ala http://dockerz.net/twd/HaskellCharts and I don't mean calls to the Google Charts API ala http://community.livejournal.com/evan_tech/241080.html I would like something that can generate PNGs in memory, i.e. not directly to a file. This is close to what I have in mind: http://www.fred.net/brv/chart/ I'd like 2D pie charts, bar charts and something like a google-o-meter. Any pointers? cheers peter

4 5

Re: Having trouble with parallel Haskell
by Donnie Jones 04 Jun '08

04 Jun '08

Hello Bryan, 2008/6/4 Bryan O'Sullivan <bos(a)serpentine.com>: > I intended to write a half chapter or so about parallel programming in > Haskell for the book I'm working on, but I've been coming to the > conclusion that the time is not yet ripe for this. I hope it will be > helpful if I share my experiences here. > > Specifically, I was planning to write about parallel programming in pure > code: use of "par" and programming with strategies. > > The most substantial problem is that the threaded RTS in GHC 6.8.2 is > very crashy in the face of "par": about 90% of my runs fail with a > segfault or an assertion failure. Simon Marlow mentioned that this bug > is fixed, but I've been unsuccessful in building a GHC 6.8.3 release > candidate snapshot so far, so I can't verify this. > > When a run does go through, I have found it surprisingly difficult to > actually get both cores of a dual-core system to show activity. As > there are no tools I can use to see what is happening, I am stumped. It > is of course quite likely that I am doing something wrong that results > in unexpected dependencies, but I cannot find a means to gaining insight > into the problem. Although my Google Summer of Code project was not selected, I decided to go ahead and work on the Parallel Profiling Tools for GHC this Summer, with the help of Simon Marlow of course, for my Master's thesis. The work is nowhere near complete, as I just began working on it a couple of weeks ago. I was able to run the ParSort.hs program in your original post with my modified version of GHC HEAD that now supports parallel profiling. Hopefully, by the end of the Summer, Haskell's support for parallel profiling will be vastly improved. This is the example test I performed: ghc -parprof -threaded -o ParSort --make ParSort.hs time ./ParSort 1000000 +RTS -pN -N6 -RTS We have 1000000 elements to sort. Sorted all 1000000 elements. 28.04362s elapsed. real 0m36.060s user 0m44.107s sys 0m0.708s I have attached an Postscript file containing a graph that visualizes the parallel profiling data from the above test. A lot of work still needs to be done, but I just wanted to let you know that improvements are expected soon. Btw, ParSort.hs was taking advantage of both cores on my machine. Thank you. __ Donnie Jones

1 0

very hard to build darcs with win32 ghc-6.8.2!
by Tim Newsham 04 Jun '08

04 Jun '08

I built darcs for win32 recently and it was much more difficult than it should be. Probably most of the blame goes to ghc-6.8.2 binary release for win32. Half of the effort is getting the zlib prereq working. Previously to build zlib for win32 ghc I did the following: http://www.haskell.org/pipermail/haskell-cafe/2007-March/023059.html However, now, the gcc binary for ghc-6.8.2 does not work as well as I would like which requires a bit more effort: - It did not automatically add mingw headers during compilation, and to fix this I had to force some extra flags. I built a shell script "xcc": #!/bin/sh GHC=/ghc/ghc-6.8.2 PATH=/c$GHC/gcc-lib:$PATH export PATH /c$GHC/gcc -I $GHC/include -I $GHC/include/mingw \ -I $GHC/gcc-lib/include -L $GHC/gcc-lib "$@" - During linking it did not find crt2.o and adding it to PATH and -L did not help, so I just copied wholesale all of /c/ghc/ghc-6.8.2/gcc-lib into my zlib source directory. - At this point I was able to build with: CC=./xcc ./configure --prefix=/c/ghc/ghc-6.8.2 \ --libdir=/c/ghc/ghc-6.8.2 make make install Why is the gcc in ghc's directory so non-functional? Ok, so with zlib (the C library) installed, the zlib haskell package installs properly. Dependency resolved. Next, to build darcs I had to configure it without libcurl support (or alternately spend time chasing down that dep, pass for now). Using cygwin I ran "./configure" which falsely uses the cygwin gcc for configuration checks, but since gcc is never used directly during the compilation process, that doesn't matter that much. I could have tried the "xcc" trick here again, but didn't bother. I ran into two problems during the build: - -Werror is specified in the GNUMakefile and there are many warnings. I just removed -Werror for now. - During linking it was not able to resolve "SleepEx" from src/win32/System/Posix.hs. I could not figure out what is going on here. I tried adding "-lkernel32" and "-L /ghc/ghc-6.8.2/gcc-lib -Lkernel32" to the Makefile and it still did not work even though /ghc/ghc-6.8.2/gcc-lib/libkernel32.a has SleepEx@8 defined(!) Finally I bit the bullet and hacked around this by noticing that mingw headers have _sleep() defined. I replaced the code in Posix.hs with: foreign import ccall "_sleep" c_sleep :: CULong -> IO () sleep :: Integer -> IO CInt sleep n = c_sleep (fromIntegral n) >> return (toEnum $ fromIntegral n) At this point darcs builds and the binary seems to work (so far). I don't know the implication of my sleep hack (which doesn't return the actual time slept). Here's a small test program which uses FFI to SleepEx which I was not able to get working with win32 ghc-6.8.2. ------ {-# OPTIONS -fglasgow-exts -fffi #-} module Main where import Foreign.C.Types foreign import ccall "SleepEx" c_SleepEx :: CUInt -> CInt -> IO CInt main = do putStrLn "start" n <- c_SleepEx (2*1000) 1 print n ------- So, what is going on with ghc-6.8.2? Why is the gcc so hard to use now? Why can't I get FFI working with standard win32 functions? Why aren't there prebuilt win32 darcs binaries anymore? Tim Newsham http://www.thenewsh.com/~newsham/

3 2

[ANN] hs-pgms 0.1 -- Programmer's Minesweeper in Haskell
by Bertram Felgenhauer 04 Jun '08

04 Jun '08

Hi, I've just uploaded hs-pgms to hackage. It is a Haskell implementation of Programmer's Minesweeper [1], which allows programmers to implement minesweeper strategies and run them. (Note: ghc >= 6.8 is required.) hs-pgms uses MonadPrompt to achieve a clean separation between strategies, game logic, and presentation. There are two frontends, one command line frontend which is mainly useful for collecting statistics, and a GUI frontend, using gtk2hs, for watching the strategies in action. There's a git repo, see http://repo.or.cz/w/hs-pgms.git . enjoy, Bertram [1] http://www.ccs.neu.edu/home/ramsdell/pgms/index.html

1 0