- Haskell-Cafe - Haskell.org

Ranges over Rational.
by André Scholz 14 Feb '12

14 Feb '12

Hello, i stumbled upon the specification of the Enum instances of Floats, Doubles and Rationals. I understand the idea behind this specification for floating point numbers. But why was it also used for Rational? As Rationals are exact, it would make sense to use the same definition of ranges as used for Integers. The specification seems to nullify the difference between Rational and floating point types in this respect. I would consider this a, well, a mistake in the specification. Kind regards, André Scholz

1 0

How to increase performance using concurrency for sequential producer-consumer problem
by John Lato 14 Feb '12

14 Feb '12

I would use bounded STM channels (from the stm-chans package) for communication; this would keep the producer from getting too far ahead of the converters. You'd need to tag items as they're produced (an Integer should be fine) also, and keep track of the tags. A TVar should suffice for that. The basic outline is that the producer writes to a channel. Each converter thread reads from that channel, and when it's finished, checks the output index TVar. If the converter's item index is equal to the current output index,the converter puts its value into an output channel and increments the output index. A final consumer reads from the output channel and processes each item in turn. Or instead of a bounded input channel, the producer could write to a TMVar. Which is better probably depends on the details of your production pattern. You certainly could use something like iteratee-stm or the conduits variant, but they wouldn't directly help with concurrency of converters, nor with synchronization. What they would give you is concurrency between the producer, converter, and consumer. Of course you could build your own converter step to work within that framework. John L. > Date: Mon, 13 Feb 2012 16:12:22 +0100 > From: Roel van Dijk <vandijk.roel(a)gmail.com> > Subject: [Haskell-cafe] How to increase performance using concurrency > for sequential producer-consumer problem > To: Haskell Caf? <haskell-cafe(a)haskell.org> > Message-ID: > <CABw4ky7Pu_RJSj5hQ_7GS_VTqv-dA4iYV0VhEY_J1YxxYBLyvg(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hello, > > I have a program which I believe can benefit from concurrency. But I > am wondering if the mechanisms I need already exist somewhere on > Hackage. > > Here is a sketch of my program, in literate Haskell: > >> module Problem where >> import Control.Monad ( forM_ ) > > The producer produces values. It blocks until there are now more > values to produce. Each value is given to a callback function. > >> type Producer a = (a -> IO ()) -> IO () > > The converter does some work with a value. This work is purely CPU and > it is the bottleneck of the program. The amount of work it has to do > is variable. > >> type Converter a b = a -> b > > The consumer does something with the value calculated by the > converter. It is very important that the consumer consumes the values > in the same order as they are produced. > >> type Consumer b = b -> IO () > > Dummy producer, converter and consumer: > >> producer :: Producer Int >> producer callback = forM_ [1..10] callback > >> converter :: Converter Int Int >> converter = (*10) > >> consumer :: Consumer Int >> consumer = print > > A simple driver. Does not exploit concurrency. > >> simpleDriver :: Producer a -> Converter a b -> Consumer b -> IO () >> simpleDriver producer converter consumer = producer (consumer . converter) > >> current_situation :: IO () >> current_situation = simpleDriver producer converter consumer > > Ideally I would like a driver that spawns a worker thread for each > core in my system. But the trick is in ensuring that the consumer is > offered results in the same order as they are generated by the > producer. > > I can envision that some kind of storage is necessary to keep track of > results which can not yet be offered to the consumer because it is > still waiting for an earlier result. > > Is there any package on Haskell that can help me with this problem? Or > do I have to implement it using lower level concurrency primitives? > > Regards, > Roel > >

1 0

Some reflections on Haskell
by Kevin Jardine 14 Feb '12

14 Feb '12

https://plus.google.com/u/0/111705054912446689620/posts/DPdA2rUSQ6c Comments are welcome! Kevin

1 0

How to increase performance using concurrency for sequential producer-consumer problem
by Roel van Dijk 14 Feb '12

14 Feb '12

Hello, I have a program which I believe can benefit from concurrency. But I am wondering if the mechanisms I need already exist somewhere on Hackage. Here is a sketch of my program, in literate Haskell: > module Problem where > import Control.Monad ( forM_ ) The producer produces values. It blocks until there are now more values to produce. Each value is given to a callback function. > type Producer a = (a -> IO ()) -> IO () The converter does some work with a value. This work is purely CPU and it is the bottleneck of the program. The amount of work it has to do is variable. > type Converter a b = a -> b The consumer does something with the value calculated by the converter. It is very important that the consumer consumes the values in the same order as they are produced. > type Consumer b = b -> IO () Dummy producer, converter and consumer: > producer :: Producer Int > producer callback = forM_ [1..10] callback > converter :: Converter Int Int > converter = (*10) > consumer :: Consumer Int > consumer = print A simple driver. Does not exploit concurrency. > simpleDriver :: Producer a -> Converter a b -> Consumer b -> IO () > simpleDriver producer converter consumer = producer (consumer . converter) > current_situation :: IO () > current_situation = simpleDriver producer converter consumer Ideally I would like a driver that spawns a worker thread for each core in my system. But the trick is in ensuring that the consumer is offered results in the same order as they are generated by the producer. I can envision that some kind of storage is necessary to keep track of results which can not yet be offered to the consumer because it is still waiting for an earlier result. Is there any package on Haskell that can help me with this problem? Or do I have to implement it using lower level concurrency primitives? Regards, Roel

3 2

Poll: Have you heard of or used GHC External Core?
by James Fisher 13 Feb '12

13 Feb '12

Hi all: I'm conducting a poll on Haskellers.com to assess the community importance of GHC External Core. Here's the link: http://www.haskellers.com/poll/7 Thanks, James Fisher

3 5

xattr takeover
by Deian Stefan 13 Feb '12

13 Feb '12

Hello, I've been trying to get in touch with the maintainer (CC'd) about the xattr package for about a month. There are quite a few memory leaks (among other issues) for which I have a patch (see [1]). I would like to push the new version to Hackage, but the etiquette for taking over a package is unclear. Any suggestions? Thanks, Deian [1] https://github.com/deian/libattr-hs

2 1

Usefulness of abstracting data storage, WAS: A universal data store interface
by Tom Murphy 13 Feb '12

13 Feb '12

Mailing list thread split! The GSoC seems like it should have its own list thread, so I'm moving this other discussion: On 2/13/12, Paul R <paul.r.ml(a)gmail.com> wrote: >> The most proeminent example is probably PostgreSQL, which is an >> incredibly strong product with high SQL power. But as soon as you access >> it through the ActiveRecord or Persistent API, it gets turned into >> a very limited store, with the SQL power of SQLITE or MongoDB. > > Tom> "Limited" /= "Worst", though [0]. > > Tom> The popularity of SQLite and "NoSQL" prove that sometimes a limited > Tom> feature set is worth the gains in abstraction. > > Tom> Definitely not for every project, of course. > > I don't dismiss MongoDB nor SQLite, they are great. But you probably > don't want to limit MongoDB to a SQL features set, and you don't want to > limit SQLite to a "NoSQL" interface, and you don't want to limit > PostgreSQL to a SQLite features set ... > > As you said, each of these stores has strenghs for particular needs and > weaknesses for others. Pick the one that best suits your project, and > use its full power, raw :) I agree about strengths and weaknesses of different data stores. However for my uses, I prefer Haskell Functors to any particular data store. The tool that helps me stay within Haskell the most is the one which I'll choose. Tom

1 0

Happstack-state in non-happstack production apps
by Tom Murphy 13 Feb '12

13 Feb '12

Hi, Is it common to use happstack-state without happstack for real-world code (web or otherwise)? Thanks, amindfv / Tom

3 4

Cannot understand liftM2
by Nicola Paolucci 13 Feb '12

13 Feb '12

Hi All, I'm loving learning Haskell quite a bit. It is stretching my brain but in a delightfull way. I've googled, I've hoogled but I haven't found a clear explanation for what exactly liftM2 does in the context below. Using the cool lambdabot "pointless" utility I found out that: > \x -> snd(x) - fst(x) is the same as: > liftM2 (-) snd fst I like the elegance of this but I cannot reconcile it with its type. I can't understand it. I check the signature of liftM2 and I get: Prelude> :t liftM2 Prelude> liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r Can someone help me understand what's happening here ? What does a Monad have to do with a simple subtraction ? What is actually the "m" of my example ? I am sure if I get this I'll be another step closer to illumination ... Thanks, Nick

15 18

ANNOUNCE: Registration open for DHD >>= UHac, April 20 - 22, Utrecht
by Sean Leather 13 Feb '12

13 Feb '12

We are happy to open registration to all. If you're interested in checking out some neat talks or hacking on cool Haskell projects, reserve your spot today! http://www.haskell.org/haskellwiki/DHD_UHac We are still looking for speakers for the Dutch HUG Day. Please consider sharing your latest new project or toy. It doesn't have to be research. It doesn't even have to be done. Just email Sean Leather (leather(a)cs.uu.nl) with your idea, and we'll talk about it. Also, the wiki has been updated with a lot more information since that last announcement. We'll continue to add more. Let us know if you have any questions. >>= >> >> >> >> >> >> >>= >>= >>= >>= DHD >>= UHac >>= >>= >>= >>= April 20 - 22 >>= >>= >>= >>= Utrecht >>= >>= >>= >>= >> >> >> >> >> >> >>= Sean Leather and Jurriën Stutterheim Organizers

1 0