- Haskell-Cafe - Haskell.org

Joels Time Leak
by Adrian Hey 03 Jan '06

03 Jan '06

Hello, I haven't followed everything that's happened on the Binary IO thread, but has anybody else actually tried Joels code? .. http://wagerlabs.com/timeleak.tgz I can reproduce the problem (ghc/Linux), but can't explain it. It seems very strange that friggin about with an otherwise irrelevant (AFAICT) MVar fixes the problem. Regards -- Adrian Hey

6 9

Re: Joels Time Leak
by Chris Kuklewicz 03 Jan '06

03 Jan '06

Thanks for the answer, but I should I written a longer comment. I have added such a longer comment below: Simon Marlow wrote: > Chris Kuklewicz wrote: > >> Another comment: between 1000's of threads and writing a custom >> continuation based scheduler, what about using a thread pool? Does >> anyone have a library with a "fork-IO-Pool" command? > > > You don't need a thread pool, because threads are so cheap. Thread > pools are just a workaround for lack of lightweight concurrency. > > Cheers, > Simon > Since the round-robin scheduler has (0.02 * N) seconds of delay for N therads, then one could trade off latency between time spent waiting for the thread pool to start a job and time spend running the job and getting interrupted. In the limit of 1 worker thread, all the latency is waiting to get run, and there are no interruptions, so the time taken *while running* is very short. With 10 threads, there can be a delay to start, and each interruption adds 0.2 seconds to the job's run time once it has started. For a server, the client requests queue up and wait for room in the thread pool, and the pool is kept small enough that the round-robin-schedular-delay keeps requests from timing out while being serviced. Otherwise 1000 client requests would cause 20 seconds of reschedule penalty for all threads and they could all timeout. With a thread pool, one can drop threads that have been waiting for too long instead of running them, so those threads will timeout. But the pool keeps servicing at least some of the client requests on time. All hypothetical to me, of course. -- Chris

1 0

Haskell vs. Erlang: Logging to one thread from thousands /Answer/
by Joel Reymont 03 Jan '06

03 Jan '06

I asked the Erlang guys why I can log to a single process in Erlang without any problems. The scheduler could well be round-robin but since the message queue is hard-wired to each Erlang process they found an elegant way out. -- There is a small fix in the scheduler for the standard producer/consumer problem: A process that sends to a receiver having a large receive queue gets punished with a large reduction (number of function calls) count for the send operation, and will therefore get smaller scheduling slots. -- Thanks, Joel -- http://wagerlabs.com/

1 0

Help with "shootout"
by Chris Kuklewicz 03 Jan '06

03 Jan '06

Hello all, I decided to put together an entry for one of the shooutout categories: http://haskell.org/hawiki/ChameneosEntry It involves 4 threads. There is no current Haskell entry. Anyone have comments? Alterations? I can't have created the best code yet. I don't have the compilers for the other entries, so I can't compare speed on my powerbook (which is the wrong kind of CPU anyway -- they test on an AMD system). -- Chris

5 10

RE: [Haskell-cafe] ST monad
by Ralf Lammel 03 Jan '06

03 Jan '06

... for the same reason as this one doesn't get through: import Control.Monad.ST import Data.Array.ST main = print $ runST $ do return () ... but this one does: import Control.Monad.ST import Data.Array.ST main = print $ runST ( do return ()) it's all about rank-2 types; see SPJ's et al. paper on type inference for these types. However, I guess that the jury is still out, say this specific rank-2 behavior may be revised (and I also hope so). HTH Ralf > -----Original Message----- > From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe- > bounces(a)haskell.org] On Behalf Of Bulat Ziganshin > Sent: Tuesday, January 03, 2006 2:28 AM > To: haskell-cafe(a)haskell.org > Subject: [Haskell-cafe] ST monad > > Hello > > the following code can't go through typechecking. can anyone help me > to fix it or, better, let me know what i need to read to fix it myself? :) > > import Control.Monad.ST > import Data.Array.ST > main = print $ runST $ > do arr <- newArray (1,10) 127 > a <- readArray arr 1 > writeArray arr 1 216 > b <- readArray arr 1 > return (a,b) > > > PS: error message is > > b.hs:4:15: > Inferred type is less polymorphic than expected > Quantified type variable `s' escapes > Expected type: ST s a -> b > Inferred type: (forall s1. ST s1 a) -> a > In the first argument of `($)', namely `runST' > In the second argument of `($)', namely > `runST > $ (do > arr <- newArray (1, 10) 127 > a <- readArray arr 1 > writeArray arr 1 216 > b <- readArray arr 1 > return (a, b))' > > > > -- > Best regards, > Bulat mailto:bulatz@HotPOP.com > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

ST monad
by oleg＠pobox.com 03 Jan '06

03 Jan '06

Bulat Ziganshin wrote: the following code can't go through typechecking > import Control.Monad.ST > import Data.Array.ST > main = print $ runST $ > do arr <- newArray (1,10) 127 > a <- readArray arr 1 > writeArray arr 1 216 > b <- readArray arr 1 > return (a,b) Indeed. The short answer: use runST (long expression) rather than runST $ long expression when it comes to higher-ranked functions such as runST. A longer answer: http://www.haskell.org/pipermail/haskell-cafe/2004-December/008062.html > let me know what i need to read to fix it myself MLF (see Daan Leijen, A. Loeh, `Qualified types for MLF', ICFP05)

1 0

ST monad
by Bulat Ziganshin 03 Jan '06

03 Jan '06

Hello the following code can't go through typechecking. can anyone help me to fix it or, better, let me know what i need to read to fix it myself? :) import Control.Monad.ST import Data.Array.ST main = print $ runST $ do arr <- newArray (1,10) 127 a <- readArray arr 1 writeArray arr 1 216 b <- readArray arr 1 return (a,b) PS: error message is b.hs:4:15: Inferred type is less polymorphic than expected Quantified type variable `s' escapes Expected type: ST s a -> b Inferred type: (forall s1. ST s1 a) -> a In the first argument of `($)', namely `runST' In the second argument of `($)', namely `runST $ (do arr <- newArray (1, 10) 127 a <- readArray arr 1 writeArray arr 1 216 b <- readArray arr 1 return (a, b))' -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

Catching string from error function with GHC Control.Exception
by Andrew Savige 03 Jan '06

03 Jan '06

I am a Haskell beginner, using GHC 6.4.1. Suppose I have a function, tt, say, which may call error. For the purposes of testing tt, I'd like to be able to catch the error string and assert that it matches the expected error string. Is HUnit or QuickCheck (or either) the appropriate tool for this sort of testing? I managed to get it working with HUnit, but it's horribly kludgy mainly because I'm yet to grok monads. The little test program below demonstrates my question outside of HUnit: import Control.Exception tt :: String -> Int tt s = error ("hi error '" ++ s ++ "'") -- tt s = read s ttWrap :: String -> IO String ttWrap x = do let r = tt x -- comment out next line, error string not caught putStr (show r) return (show r) ttWrap2 :: IO String ttWrap2 = do res <- tryJust errorCalls (ttWrap "123") case res of Right r -> return (show r) Left r -> return r main = do x <- ttWrap2 putStrLn ("caught:" ++ x) y <- ttWrap2 putStrLn ("caught:" ++ y) When you run the above test program, it does indeed catch the error string thrown by the tt function (and prints it out in main). However, if you comment out the putStr line as shown in the comment above, it no longer catches the error string, but dies instead. Why? I'm sure there is a cleaner way to achieve what I'm trying to do and I'd appreciate advice on the best way to do this. Thanks, /-\ Send instant messages to your online friends http://au.messenger.yahoo.com

3 2

Re: Haskell Speed
by Brent Fulgham 02 Jan '06

02 Jan '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I recently stumbled across this thread, related to the Shootout > (which I run) and wanted to add a few comments. > > First, I agree that I am a Haskell novice; however, I rely on > people like yourselves to show me where I am doing things wrong. > If our solutions are horribly inefficient, please tell us what we > can do to resolve the problem. But note that in some cases, we are > purposely being inefficient so that we can measure the cost of > certain basic operations. > > Doug Bagely started the Shootout as a comparison of scripting > languages. After I revived it, I started focussing more on > functional and logic languages, since I was curious how these > languages would fare in comparison with the more typically-used > languages like C/C++. Consequently, many of the tests show this > heritage and are highly imperative. We have been working to relax > some of these rules, and have added many new tests that try to be > more amenable to comparison of lazy and 'strict' languages. > > In our defense I would like to plead that it is not easy to devise > short problems (e.g., that can be expressed in a page or so of code > - -- we try to limit it to 100 lines of C++ code as a rough > benchmark), and that also take enough run time for a meaningful > measurement. So, many of the tests initially suffered from foolish > looping and repetition as a means of extending the run times > sufficiently to allow measurement. We have been changing tests so > that fewer of them rely on these kinds of activities to generate > results. We are always interested in new ideas, and would consider > any benchmark ideas you have. > > Finally, I don't agree at all that Haskell's scores show poorly. > The GHC compiler is one of the better performers, and regularly > trounces other languages when we let it do its job. For example, > we had to jump through many hoops to convince the compiler to > actually invoke all the loops required to do the "same way" tests > on methodcall and similar benchmarks, because the compiler was so > sharp at identifying wasted effort and optimizing it away. Perhaps > we don't say this strongly enough on the site, but I was truly > impressed at its ability to toss aside wasted calculations and > focus on the core problem. I'll admit it was frustrating because > we wanted to see how long it would take for Haskell to make N > recursive calls, or what have you, but the fact that the compiler > saw that there was no need to do the recursion to get the result is > quite amazing! I'm sure this would be extremely useful when > compiling real-world programs. > > There have been many cases where the "obvious" solution in Haskell > is a great performer, but we discover that it's so fast because it > has tossed aside wasted cycles and just done the work necessary to > arrive at a solution. It's unfortunate, since we then have to > dirty the program with wasted steps to force it to exercise the > tasks required. But in a "real world" test I think Haskell would > show quite well. > > As we evolve into the newer tests, I think you will see Haskell > make a better showing. Simon Marlow (and others) have been a huge > help in optimizing the existing tests in a "fair" fashion, and as > we provide more "same thing" type tests, I think Haskell will pull > further ahead. > > Thanks, > > - -Brent > > P.S. I must say that I find Haskell to be the most esthetically > pleasing language -- it's quite beautiful when printed! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (Darwin) iD8DBQFDuWIlzGDdrzfvUpURAnJuAJ90G9ltXH5m+jsz6D0QoucoY6anNACfcfkQ Mg2K0NO0kbBYLy4ZX7LCoeM= =uGnw -----END PGP SIGNATURE-----

1 0

Typechecking Help
by Dominic Steinitz 02 Jan '06

02 Jan '06

I have a function which, without a type annotation, types as: *Codec.ASN1.BER> :t choiceAux choiceAux :: forall (m :: * -> *) e e1. (MonadState [Maybe Encoding] m, MonadState [Maybe Encoding] (StateT [Maybe Encoding] m), MonadError e (StateT [Maybe Encoding] m), MonadError e1 m) => (TagPlicity, NamedType) -> Encoding -> m Defaulted But if I try to give it a type annotation of choiceAux :: (MonadState [Maybe Encoding] m, MonadState [Maybe Encoding] (StateT [Maybe Encoding] m), MonadError e (StateT [Maybe Encoding] m), MonadError e1 m) => (TagPlicity, NamedType) -> Encoding -> m Defaulted I get Codec/ASN1/BER.hs:66:0: Quantified type variable `e1' is unified with another quantified type variable e When trying to generalise the type inferred for `choiceAux' Signature type: forall (m :: * -> *) e e1. (MonadState [Maybe Encoding] m, MonadState [Maybe Encoding] (StateT [Maybe Encoding] m), MonadError e (StateT [Maybe Encoding] m), MonadError e1 m) => (TagPlicity, NamedType) -> Encoding -> m Defaulted Type to generalise: (TagPlicity, NamedType) -> Encoding -> m Defaulted In the type signature for `choiceAux' When generalising the type(s) for tc, choiceAux, k Changing e1 to e makes it typecheck. 1. Can anyone explain why the typechecker rejects the type it had inferred for itself? 2. I thought StateT guaranteed that the lifted monad was a state monad so why is the typechecker adding MonadState ... (StateT ... ) to the list of constraints? Ditto for MonadError ... (StateT ... )? Thanks, Dominic. PS What I thought I was going to get was choiceAux :: forall (m :: * -> *) e. (MonadError e m, MonadState [Maybe Encoding] m) => (TagPlicity, NamedType) -> Encoding -> m Defaulted and this is what I have now specified.

3 4