- Haskell-Cafe - Haskell.org

Re: [Haskell-cafe] Re: Go Haskell! -> array libraries
by Andrew Coppin 30 Nov '08

30 Nov '08

Henning Thielemann wrote: > I suspect that this particular function is less useful than you think. > It safes one allocation and might be faster since it uses less cache, > but on the other hand, it cannot be fused. If the array is "seriously large", you don't want to have five or six versions of it sitting in memory until the GC comes along to remove it. (OTOH, presumably an unboxed array can be allocated or freed quite quickly...) At a minimum, you've going to end up with two copies in memory - the existing one, and the one being built. > I think in-place array > updates are only sensible for writing array elements in really random > order. As long as you can formulate your algorithm the way "read from > random indices, but write a complete array from left to right", there is > almost no need for mutable arrays. > Does quick-sort fit that pattern? (I'm guessing yes, since all you need to do is filtering and merging...) Yeah, generally you only need arrays if you really want random access. Except in Haskell, where an array also happens to be the only way of storing large numbers of values unboxed. So sometimes you'll use an array because you want to save space. (E.g., parsing text is usually a sequential process with no random access, but you probably want to use ByteString all the same!) I sometimes also use unboxed arrays for the increase in strictness. I guess the thing to do would be to measure the difference...

5 5

"Could not find module ... which is hidden" problem
by Belka 30 Nov '08

30 Nov '08

Hello! ----------------------------START---------------------------------- $ sudo runghc Setup configure --user Configuring HCL-1.2... $ sudo runghc Setup build Preprocessing library HCL-1.2... Preprocessing executables for HCL-1.2... Building HCL-1.2... HCL.hs:302:7: Could not find module `System.Random': it is a member of package random-1.0.0.1, which is hidden $ sudo ghc-pkg expose random Saving old package config file... done. Writing new package config file... done. $ sudo runghc Setup configure --user Configuring HCL-1.2... $ sudo runghc Setup build Preprocessing library HCL-1.2... Preprocessing executables for HCL-1.2... Building HCL-1.2... HCL.hs:302:7: Could not find module `System.Random': it is a member of package random-1.0.0.1, which is hidden ---------------------THE-END---------------------------------------- Perhaps, i'm 1000th, who asks how to solve this. Sorry that didn't search better, but it's really tiring for a newby. :-( [ http://www.haskell.org/haskellwiki/Upgrading_packages/Updating_to_GHC_6.8 Here ] found something, which maybe called "a gentle explaination" of what's going on. I have ghc ver: 6.8.2, base ver: 3.0.1.0. So there are 2 questions of mine: (1) Is there any centralized and well organized Haskell Knowledge Base, where it would be much easier to find solutions for "popular" problems? Anybody, please, your recommendations. (2) As for the topic: the only option for me would be obtaining older GHC (base?) - is that correct? So that require me reinstalling every Haskell package I have installed so far? Thanks in advance. -- View this message in context: http://www.nabble.com/%22Could-not-find-module-...-which-is-hidden%22-probl… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

3 3

Data parallelism doesn't seem to work on windows...
by Sebastian Sylvan 30 Nov '08

30 Nov '08

Hi,I can't seem to get DPH to work on 6.10.1 on Vista-64. I run the executables with +RTS -N2, and to verify that I'm doing it correctly I checked with a simple benchmark using forkIO and that does indeed use both my cores: -- compiler command line: ghc --make -O2 -threaded parr.hs -- execution command line: parr.exe +RTS -N2 main = do forkIO $ print [ True | n <- [ 1000 .. 3000], fac n == 0 ] forkIO $ print [ True | n <- [ 1000 .. 3000], fac n == 0 ] getLine return () This, on the other hand does not use more than one core: -- compiler command line (from shootout code): ghc --make -fcpr-off -threaded -fdph-par -package dph-base -Odph -XPArr parr2.hs -- execution as before main = print $ [: True | n <- [: 1000 .. 5000 :], fac n == 0 :] That's 4000 items of work there, so surely it should kick off plenty of sparks to overcome the "sparks bug"? -- Sebastian Sylvan +44(0)7857-300802 UIN: 44640862

2 1

Control.Exception Funny
by Dominic Steinitz 29 Nov '08

29 Nov '08

I'm probably doing something wrong but this example doesn't compile for me under ghc 6.10.1 (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exceptio…) > catch (openFile f ReadMode) > (\e -> hPutStr stderr ("Couldn't open "++f++": " ++ show e)) > Run.hs:77:24: > Couldn't match expected type `Handle' against inferred type `()' > Expected type: IO Handle > Inferred type: IO () > In the expression: > hPutStr stderr ("Couldn't open " ++ d ++ ": " ++ show e) > In the second argument of `CE.catch', namely > `(\ e -> hPutStr stderr ("Couldn't open " ++ d ++ ": " ++ show e))' Fair enough because openFile returns a Handle and hPutStr returns () so they don't match as the compiler says. > CE.catch :: (CE.Exception e) => IO a -> (e -> IO a) -> IO a So if I fix the example thus: > foo d = CE.catch (openFile d ReadMode >> return ()) > (\e -> hPutStr stderr ("Couldn't open "++ d ++": " ++ show e)) I get > Run.hs:70:8: > Ambiguous type variable `e' in the constraint: > `CE.Exception e' > arising from a use of `CE.catch' at Run.hs:(70,8)-(71,78) > Probable fix: add a type signature that fixes these type variable(s) Now I think I never used to get this under 6.8.2 but I don't easily have a 6.8.2 to try it out on. Doing what the compiler suggests doesn't work for obvious reasons: > foo :: CE.Exception e => FilePath -> IO () > foo d = CE.catch (openFile d ReadMode >> return ()) > (\e -> hPutStr stderr ("Couldn't open "++ d ++": " ++ show e)) > Run.hs:69:0: > Ambiguous constraint `CE.Exception e' > At least one of the forall'd type variables mentioned by the constraint > must be reachable from the type after the '=>' > In the type signature for `foo': > foo :: (CE.Exception e) => FilePath -> IO () There seems to be a ticket for it (http://hackage.haskell.org/trac/ghc/ticket/2819) but this doesn't give a suggested example that compiles. Dominic.

2 2

Re: Go Haskell! -> array libraries
by John Lato 29 Nov '08

29 Nov '08

> From: Andrew Coppin <andrewcoppin(a)btinternet.com> > >>> My view would be to let the free market of developers decide what is >>> best. No bottlenecks -- there's too many Haskell libraries already (~1000 now). >>> >>> And this approach has yielded more code than ever before, more libraries >>> than ever before, and library authors are competing. >>> >>> So let the market decide. We're a bazaar, not a cathedral. >>> > > I find this kind of attitude disturbing. > > Are you seriously asserting that it's "bad" for people to stop and think > about their designs before building? That it's "bad" for people to get > together and coordinate their efforts? Would you really prefer each and > every developer to reinvent the wheel until we have 50,000 equivilent > but slightly different wheel implementations? Certainly you seem > obsessed with the notion that "more packages on Hackage == better". Well > in my book, quantity /= quality. (The latter being vastly more important > than the former - while admittedly far harder to measure objectively.) I > would far prefer to see one well-written library that solves the problem > properly than see 25 incompatible libraries that all solve small > fragments of the problem poorly. In the latter case, there will be no > "competition" between libraries; everybody will just give up and not use > *any* of them. You _can_ have too much choice! > > I really hope I'm not the only person here who sees it this way... > I would love to see a perfect, unified array library in Haskell. I think everyone would. However, the problem Don, Roman, and others have raised is that there is no single consensus on what that library would look like, or how it would be implemented. It might be impossible for one library to fill the entire design space. Don's point is that, since this isn't yet a solved problem, having multiple implementations available to see what works well (and what doesn't) is a necessary step in finding a solution. I also think this is a exactly why Hackage needs a way to indicate that packages are deprecated/superceded by other packages. There was some talk about this recently, and IIRC even a submitted patch. I hope that gets adopted soon. John

3 2

GHC 6.10.1 multi-threaded broken?
by Jeroen Baekelandt 29 Nov '08

29 Nov '08

Hi, Since I upgraded from ghc 6.8.3 to 6.10.1, I noticed that my programs do not run multi-threaded anymore. I tried simplifying my code, till I just took one of the par/pseq demo's to verify if it wasn't my fault. When I compile this code on 6.8.3 (both ubuntu and OS X), top shows something like 180% CPU usage and the elapsed time is almost halved. When compiled with 6.10.1, top shows max 100% and no speedup is noticable at all. Sample run: $ ghc --make -threaded paralleltest $ time ./paralleltest +RTS -N1 -RTS 119201850 real 0m26.024s user 0m25.494s sys 0m0.220s $ time ./paralleltest +RTS -N2 -RTS 119201850 real 0m25.770s user 0m25.539s sys 0m0.167s I have the same on OS X and Ubuntu. I even compiled the Ubuntu ghc from source myself and verified that GMP was used. Any ideas? Thanks, Jeroen Here's the code: module Main where import Control.Parallel fib :: Int -> Int fib 0 = 0 fib 1 = 1 fib n = fib (n - 1) + fib (n - 2) mkList :: Int-> [Int] mkList n = [1..n-1] relprime :: Int -> Int -> Bool relprime x y = gcd x y == 1 euler :: Int -> Int euler n = length (filter (relprime n) (mkList n)) sumEuler :: Int -> Int sumEuler = sum . (map euler) . mkList parSumFibEuler :: Int -> Int -> Int parSumFibEuler a b = f `par` (e `pseq` (e + f)) where f = fib a e = sumEuler b main = do print $ parSumFibEuler 40 7450

2 1

Extensible Exceptions
by David F. Place 29 Nov '08

29 Nov '08

Hi, All. I am trying to understand the new exceptions package in base-4 Control.Exceptions. The documentation for catchJust is the same as in Control.OldException including this example: result <- catchJust errorCalls thing_to_try handler Control.OldException provides the predicate errorCalls, but the new one does not. I don't see how to write it. Thanks for reading. Cheers, David

6 11

Using Parsec with other monads
by Roly Perera 28 Nov '08

28 Nov '08

Hi, I've spent some time writing a parser using the Parsec library and was looking forward to being able to plug in some side-behaviour once I'd got the parser working. Now it seems I can't actually do that in a nice way because Parsec appears to be "fixed" to a simple State monad. I found this mentioned in the Cafe archives, but not much discussion. Is there a reason Parsec wasn't implemented using the monad transformer approach? Are there any plans to open it up? It's a nice powerful library and a natural thing to want to do for example would be to plug in something like a Reader to track a variable context. I guess one could abuse the State monad to achieve the goal but that feels like the wrong tool for the job. Any insights appreciated. thanks, Roly

3 2

definitive list of editline bindings anywhere?
by Paul Brown 28 Nov '08

28 Nov '08

All -- Anyone have a definitive list of editline keybindings available? I find myself missing some of the capabilities of readline, and there doesn't seem to be documentation. -- Paul

2 1

Question about fastcgi
by Mauricio 28 Nov '08

28 Nov '08

Hi, I'm learnng to use fastcgi and, reading the examples, I see the main "loop" is like this: main = runFastCGI my_work However, isn't a fastcgi program supposed to choose a port where to listen to calls? For instance, in this C example: xzdev.com/nginx_fastcgi.html doesn't the line listen_socket = FCGX_OpenSocket(":8002", 2000); says it's listening to port 8002? I read the code for fastcgi, from hackage, and I can't find anything related to ports like, for instance, a default port. Am I understanding something the wrong way? Thanks, Maurício

3 4