February 2012 - Haskell-Cafe

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

Stable pointers: use of cast to/from Ptr
by Yves Parès 13 Feb '12

13 Feb '12

Hello, According to the documentation ( http://hackage.haskell.org/packages/archive/base/4.5.0.0/doc/html/Foreign-S…) StablePtrs aims at being opaque on C-side. But they provide functions to be casted to/from regular *void**'s. Does that mean if for instance you have a StablePtr CInt you can cast it to Ptr () and alter it on C-side? void alter(void* data) { int* x = (int*)data; *x = 42; } -------------------------------------------------- -- using 'unsafe' doesn't change anything. foreign import ccall safe "alter" alter :: Ptr () -> IO () main = do sptr <- newStablePtr (0 :: CInt) deRefStablePtr sptr >>= print alter (castStablePtrToPtr sptr) -- SEGFAULTS! deRefStablePtr sptr >>= print freeStablePtr sptr But I tried it, and it doesn't work: I got a segfault when 'alter' is called. Is it normal? Does this mean I can only use my pointer as opaque? (Which I know to be working, as I already got a C function call back into Haskell and pass it the StablePtr via a 'foreign export') But in that case, what is the use of castStablePtrToPtr/castPtrToStablePtr, as you can already pass StablePtrs to and from C code? Thanks!

5 9

hmatrix under ghci on x86_64
by Tom Doris 13 Feb '12

13 Feb '12

I'm using ghci + hmatrix and a few other packages as a Haskell based replacement for Matlab, everything works well so far in terms of available functionality. However, I have encountered an issue when running in ghci on x86_64 systems - calls into functions that in turn call gsl functions will result in a bus error, e.g: Prelude> :m +Numeric.Container Prelude Numeric.Container> randomVector 10 Gaussian 10 fromList Bus error (core dumped) I attached gdb and found the bus error was happening in gsl_rng_alloc() but some investigation indicate that the problem is probably due to this bug in ghci: http://hackage.haskell.org/trac/ghc/ticket/2912 which has been marked as a duplicate of http://hackage.haskell.org/trac/ghc/ticket/781 and a recent update to 781 indicates that it won't be addressed until at least v 7.6.1 (781 also references http://hackage.haskell.org/trac/ghc/ticket/3658 and it seems that this is a pretty large piece of work - moving to fully dynamically linked ghci which has been around for a while and pushed back a few times). Does anyone know of a workaround that would allow ghci to use wrapped gsl functionality on x86_64 systems in the meantime? Most linux boxes used by quants are x86_64 now, so this issue will impact many people who would like to use Haskell instead of Matlab. Thanks

1 0