[Haskell-cafe] question in install gtk2hs's webkit hackage

[Canhua]

hi, I am cabal-installing webkit hackage on windows, and get a error:
 pkg-config pckage webkit-1.0 version > 1.1.15 is required but could
be not found

What should I next? install webkit? How to? I find there is a
webkitgtk+ project.
Which one should I install.

I have try to install both of them follow their docs, and failed. I
just have no experience
in build software on windows.

Thanks.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Finally, a pure iteratee library that deals with errors

[Daniel Waterworth]

Hi all,

There's seems to be a growing trend amongst the Haskell community for
writing replacements of enumerator. It's shortcomings are well
documented, but the solution is, IMO, undecided. This is my attempt:

https://gist.github.com/1915841

I have largely copied pipes' concept. The major difference is that
pipes are now able to push, pull, complete or throw an error. Errors
are propagated up and down a pipeline, triggering all of the error
handlers. The library is in a fairly unrefined state, but the core
functionality is there.

I look forward to your feedback,

Daniel

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Finally, a pure iteratee library that deals with errors

[Paul R]

Nice, thank you. I was wondering recently what was the current state of
Gabriel's pipes and Paolo's guarded variant. IIRC, they were working on
a converging branch with good support at resources early termination.

On Sun, 26 Feb 2012 10:50:22 +, Daniel Waterworth  
said:

Daniel> Hi all,
Daniel> There's seems to be a growing trend amongst the Haskell community for
Daniel> writing replacements of enumerator. It's shortcomings are well
Daniel> documented, but the solution is, IMO, undecided. This is my attempt:

Daniel> https://gist.github.com/1915841

Daniel> I have largely copied pipes' concept. The major difference is that
Daniel> pipes are now able to push, pull, complete or throw an error. Errors
Daniel> are propagated up and down a pipeline, triggering all of the error
Daniel> handlers. The library is in a fairly unrefined state, but the core
Daniel> functionality is there.

Daniel> I look forward to your feedback,

Daniel> Daniel

-- 
  Paul

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Finally, a pure iteratee library that deals with errors

[Ozgur Akgun]

I didn't really look into (enumerators/iteratees/conduits/etc)-land closely
enough, but I can say one thing. The code you link to is very easy to
understand and see what is going on. This must be a good thing.

On 26 February 2012 10:50, Daniel Waterworth wrote:

> There's seems to be a growing trend amongst the Haskell community for
> writing replacements of enumerator. It's shortcomings are well
> documented,
>

Where can I find a compilation of their shortcomings?

Best,
Ozgur
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] FFI: Overhead of foreign unsafe imports

[Yves Parès]

Hello,
When I was using C code from Python, the overhead put on calling C code by
Python was significant.
To simplify, say I have on C-side two procedures f and g, I do all the
stuff to call them in a row from Python, well I'm better off factorizing:
adding on C side a wrapper h procedure that calls them both, and then call
h from Python, because then I will have half as much overhead:

Instead of SwitchToC -> call f -> SwitchToPython -> SwitchToC -> call g ->
SwitchToPython,
the factorization leads to SwitchToC -> call f -> call g -> SwitchToPython,
which gives the same result yet is different performance-wise because each
switching has a cost.

This is painful, because if another time I have to call f and j (another
function), then I have to make another wrapper.

In Haskell world, now, given that my functions f and g would have been
imported using *unsafe*:

foreign import unsafe "f" f :: Thing -> Foo -> IO ()
foreign import unsafe "g" g :: Stuff -> Bar -> IO ()
foreign import unsafe "h" h :: Thing -> Foo -> Stuff -> Bar -> IO ()

Are
doStuff = f x y >> g z w
and
doStuff = h x y z w
equivalent, or is there an overhead (e.g. due to IO monad, or due to the
way the FFI does the calls) when compiled (if need be with optimizations)
with GHC?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Streaming to JuicyPixels

[Vincent Berthoux]

Hi,

   I didn't thought it would be a full rewrite, when I finish Jpeg writing
functionality, I will look at it in depth, which will not be immediately.
Feel free to use any code snippet from JuicyPixels if it help your for your
own library.

   Regards

Vincent Berthoux

Le 24 février 2012 06:42, Myles C. Maxfield  a
écrit :

So I started working on moving JuicyPixels to a streaming interface, and
> have some observations. This is going to be a pretty major change, touching
> pretty much every function, and the end result will end up looking very
> close to the code that I have already written. I'm not nearly as close to
> the code as the author is, and I've already made some mistakes due to not
> understanding how the original code is structured and layed out.
>
> Because this is essentially turning out to be a rewrite, I think it makes
> more sense for me to just work on my own library, and release it as a
> streaming alternative to JuicyPixels. How do you feel about this, Vincent?
>
> Thanks,
> Myles
>
> On Wed, Feb 22, 2012 at 12:30 PM, Vincent Berthoux <
> vincent.berth...@gmail.com> wrote:
>
>> Hi,
>>   Please go ahead, and github is the perfect medium for code sharing :)
>>
>>   Regards
>>
>>Vincent Berthoux
>>
>> Le 22 février 2012 20:20, Myles C. Maxfield  a
>> écrit :
>>
>> Let's put aside the issue of getting access to the pixels before the
>>> stream is complete.
>>>
>>> How would you feel if I implemented use of the STT monad transformer on
>>> top of Get in JuicyPixels, in order to get rid of the (remaining >>
>>> getBytes) call, and then expose the underlying Get interface to callers?
>>> This would allow use for streaming.
>>>
>>> Is this something that you feel that I should pursue? I can send you a
>>> GitHub Pull Request when I'm done.
>>>
>>> Thanks,
>>> Myles
>>>
>>> On Wed, Feb 22, 2012 at 5:01 AM, Vincent Berthoux <
>>> vincent.berth...@gmail.com> wrote:
>>>
 Hi,

   I can understand your performance problems, I bumped into them before
 the first release of Juicy Pixels and took a long time to get 'correct'
 performance out of the box, and the IDCT is not the only 'hot point', I got
 problems with intermediate data structure as well. Any list has proven a
 bit problematic performance wise, so I rewrote some things which would have
 been easily implemented with forM_ or mapM_ with manual recursion.

 I didn't knew STT existed, so it open a new area of reflection for the
 streaming Jpeg decoder, instead of using the (remaining >> getBytes) combo,
 staying in the Get monad might help. The reason to expose the ST monad is
 that I use it internally to mutate the final image directly, and I'd prefer
 to avoid freezing/unfreezing the underlying array. So in order to give
 access to the intermediate representation, a type could be (STT s (StateT
 JpegDecodingState Get) (MutableImage s PixelYCbCr8)) (the Jpeg decoder only
 produce (Image PixelYCbCr8 internally)). This should allow a freeze then a
 color conversion.

   As it would induce performance loss, this version should exist
 alongside current implementation. This is not trivial, but it's far from
 impossible. For the IDCT implementation, I don't think a package make much
 sense, if you want to use it, just grab it and customize the interface to
 your needs :).

   Regards

  Vincent Berthoux

 Le 21 février 2012 06:16, Myles C. Maxfield a 
 écrit :

 Hello, and thanks for the quick reply.
>
> You're right that using (remaining >> getBytes) won't work for
> streaming, as it would pull the rest of the stream into a buffer, thereby
> delaying further processing until the image is completely downloaded. :-(
>
> I'm a little unclear about what you mean about the use of the ST
> monad. There is an 
> STT
>  monad
> transformer, so you could wrap that around Get. Is that what you're
> referring to?
>
> As an aside: I didn't realize that JuicyPixels existed, so I wrote a
> JPEG decoder specifically designed for streaming - it doesn't request a
> byte of input unless it has to, uses a StateT (wrapped around Attoparsec)
> to keep track of which bit in the current byte is "next", and does the
> Huffman decoding in-line. However, I didn't use ST for the IDCT, so my own
> decoder has serious performance problems. This prompted me to start
> searching around for a solution, and I came across JuicyPixels, which
> already exists and is much faster than my own implementation. I'm hoping 
> to
> get rid of my own decoder and just use JuicyPixels. If you're curious, my
> own code is here: https://github.com/litherum/jpeg.
>
> Is it reasonable to extend JuicyPixels to fit my use case? It sounds
> like JuicyPixels

Re: [Haskell-cafe] FFI: Overhead of foreign unsafe imports

[Jason Dagit]

On Sun, Feb 26, 2012 at 10:36 AM, Yves Parès  wrote:
> Hello,
> When I was using C code from Python, the overhead put on calling C code by
> Python was significant.
> To simplify, say I have on C-side two procedures f and g, I do all the stuff
> to call them in a row from Python, well I'm better off factorizing: adding
> on C side a wrapper h procedure that calls them both, and then call h from
> Python, because then I will have half as much overhead:
>
> Instead of SwitchToC -> call f -> SwitchToPython -> SwitchToC -> call g ->
> SwitchToPython,
> the factorization leads to SwitchToC -> call f -> call g -> SwitchToPython,
> which gives the same result yet is different performance-wise because each
> switching has a cost.
>
> This is painful, because if another time I have to call f and j (another
> function), then I have to make another wrapper.
>
> In Haskell world, now, given that my functions f and g would have been
> imported using unsafe:
>
> foreign import unsafe "f" f :: Thing -> Foo -> IO ()
> foreign import unsafe "g" g :: Stuff -> Bar -> IO ()
> foreign import unsafe "h" h :: Thing -> Foo -> Stuff -> Bar -> IO ()
>
> Are
> doStuff = f x y >> g z w
> and
> doStuff = h x y z w
> equivalent, or is there an overhead (e.g. due to IO monad, or due to the way
> the FFI does the calls) when compiled (if need be with optimizations) with
> GHC?

I would expect the second doStuff to be more efficient, but you
shouldn't care what I expect! To check what is going on you can use a
tool like ghc-core (available on hackage) to see what code GHC is
generating. To see the difference in performance you can use a micro
benchmark tool like criterion (also on hackage) to quantify
performance differences.

Once you have a conclusion based on some good evidence, please report
back here :)

I hope that helps,
Jason

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] FFI: Overhead of foreign unsafe imports

[Sanket Agrawal]

On Sun, Feb 26, 2012 at 1:36 PM, Yves Parès  wrote:

> Hello,
> When I was using C code from Python, the overhead put on calling C code by
> Python was significant.
> To simplify, say I have on C-side two procedures f and g, I do all the
> stuff to call them in a row from Python, well I'm better off factorizing:
> adding on C side a wrapper h procedure that calls them both, and then call
> h from Python, because then I will have half as much overhead:
>
> Instead of SwitchToC -> call f -> SwitchToPython -> SwitchToC -> call g ->
> SwitchToPython,
> the factorization leads to SwitchToC -> call f -> call g -> SwitchToPython,
> which gives the same result yet is different performance-wise because each
> switching has a cost.
>
> This is painful, because if another time I have to call f and j (another
> function), then I have to make another wrapper.
>
> In Haskell world, now, given that my functions f and g would have been
> imported using *unsafe*:
>
> foreign import unsafe "f" f :: Thing -> Foo -> IO ()
> foreign import unsafe "g" g :: Stuff -> Bar -> IO ()
> foreign import unsafe "h" h :: Thing -> Foo -> Stuff -> Bar -> IO ()
>
> Are
> doStuff = f x y >> g z w
> and
> doStuff = h x y z w
> equivalent, or is there an overhead (e.g. due to IO monad, or due to the
> way the FFI does the calls) when compiled (if need be with optimizations)
> with GHC?
>

Each unsafe call to FFI should be pretty fast - I have measured it to be
about 15ns on my computer (~30-50 clock cycles). Assuming C implementation
of (f;g) and h take about the same time in C, first version of doStuff
would likely be a bit slower than second version because of one additional
FFI call - I would expect it to take ~15ns more on my computer. From what I
have seen in my code, GHC optimizes away IO monad when compiled with -O2
flag. So, impact of IO monad on performance should usually be
negligible/close to zero.

Keep in mind that unsafe call to FFI will block the OS capability used up
for that FFI thread until that FFI call returns (more here:
http://blog.melding-monads.com/category/haskell/). So, if it takes long
time to execute, you might want to use the safe version instead. I have
seen safe version take about ~150ns in my tests.

Like Jason said, you could create a micro-benchmark to see the difference.
For example, like below:

Haskell code:

import Control.Monad (forM_)import Foreign.C.Types (CInt)import
Data.Time.Clock (diffUTCTime, getCurrentTime)import Foreign.C

foreign import ccall safe "print"
  printsafe :: CInt -> IO ()foreign import ccall unsafe "print"
  printunsafe :: CInt -> IO ()

main = do
  let  l = 5
  a <- getCurrentTime
  forM_ [1..l] $ \x -> printsafe x
  b <- getCurrentTime
  forM_ [1..l] $ \x -> printunsafe x
  c <- getCurrentTime

  print $ "safe call average overhead " ++ show ((diffUTCTime b
a)/fromIntegral l)
  print $ "unsafe call average overhead " ++ show ((diffUTCTime c
b)/fromIntegral l)

C code:
#include 
void print(int x){
  return;}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANN: shelltestrunner-1.2

[Simon Michael]

I'm pleased to announce the release of shelltestrunner 1.2. Also, in
case you missed it
there's a survey where you can help steer the project (below).

shelltestrunner tests command-line programs (or arbitrary shell
commands.)
It reads simple declarative tests specifying a command, some input, and
the expected output, and can run them run in parallel, selectively, with
a
timeout, in color, and/or with differences highlighted. shelltestrunner
has been tested on gnu/linux, mac and windows; projects using it include
hledger, berp, cblrepo and eddie. shelltestrunner is free software
released under GPLv3+.

New in 1.2:

  * support latest cmdargs, test-framework, and GHC 7.4.

  * more readable non-quoted failure output by default; for quoted
  output, use `-p/--precise`

  * the `--all`, `--diff` and `--precise` options now interact well

Install: $ cabal install shelltestrunner

Home: http://joyful.com/shelltestrunner

User survey:
https://docs.google.com/spreadsheet/viewform?formkey=dGpZSzdhWHlCUkJpR2hjX1MwMWFoUEE6MA#gid=3


One confession: I've shipped with failing unicode tests on GHC 7.4 as I
can't see unicode on this terminal - patch welcome!

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Using multiplate to get free variables from a syntax tree

[Sjoerd Visscher]

Here's the same code but with a variation on Multiplate that doesn't use 
records, but a GADT:
https://gist.github.com/1919528

It is easier on the eyes I think, but probably not any easier to decipher. But 
hey, this is generic programming for mutually recursive datatypes, that's a 
complicated subject! (Have you tried multirec?)

Sjoerd

On Feb 26, 2012, at 12:21 AM, Thomas Schilling wrote:

> No that's correct.  I have to say the multiplate code is incredibly
> hard to decipher.
> 
> On 25 February 2012 19:47, Sjoerd Visscher  wrote:
>> I don't understand what you mean.
>> 
> ($[]) . foldFor expr freeVariablesPlate $ Add (Let ("x" := Con 1) (Add 
> (EVar "x") (EVar "y"))) (EVar "x")
>> (["y","x"],[])
>> 
>> I.e. free variables y and x, no bound variables. Is that not correct?
>> 
>> Sjoerd
>> 
>> On Feb 25, 2012, at 7:15 PM, Thomas Schilling wrote:
>> 
>>> That will give you the wrong answer for an expression like:
>>> 
>>>  (let x = 1 in x + y) + x
>>> 
>>> Unless you do a renaming pass first, you will end up both with a bound
>>> "x" and a free "x".
>>> 
>>> On 25 February 2012 16:29, Sjoerd Visscher  wrote:
 
 On Feb 24, 2012, at 10:09 PM, Stephen Tetley wrote:
 
> I'm not familiar with Multiplate either, but presumably you can
> descend into the decl - collect the bound vars, then descend into the
> body expr.
 
> Naturally you would need a monadic traversal
> rather than an applicative one...
 
 
 It turns out the traversal is still applicative. What we want to collect 
 are the free and the declared variables, given the bound variables. ('Let' 
 will turn the declared variables into bound variables.) So the type is 
 [Var] -> ([Var], [Var]). Note that this is a Monoid, thanks to the 
 instances for ((->) r), (,) and []. So we can use the code from 
 preorderFold, but add an exception for the 'Let' case.
 
 freeVariablesPlate :: Plate (Constant ([Var] -> ([Var], [Var])))
 freeVariablesPlate = handleLet (varPlate `appendPlate` multiplate 
 freeVariablesPlate)
  where
varPlate = Plate {
  expr = \x -> Constant $ \bounded -> ([ v | EVar v <- [x], v `notElem` 
 bounded], []),
  decl = \x -> Constant $ const ([], [ v | v := _ <- [x]])
}
handleLet plate = plate { expr = exprLet }
  where
exprLet (Let d e) = Constant $ \bounded ->
  let
(freeD, declD) = foldFor decl plate d bounded
(freeE, _) = foldFor expr plate e (declD ++ bounded)
  in
(freeD ++ freeE, [])
exprLet x = expr plate x
 
 freeVars :: Expr -> [Var]
 freeVars = fst . ($ []) . foldFor expr freeVariablesPlate
 
>>> freeVars $ Let ("x" := Con 42) (Add (EVar "x") (EVar "y"))
 ["y"]
 
 --
 Sjoerd Visscher
 https://github.com/sjoerdvisscher/blog
 
 
 
 
 
 ___
 Haskell-Cafe mailing list
 Haskell-Cafe@haskell.org
 http://www.haskell.org/mailman/listinfo/haskell-cafe
>>> 
>>> 
>>> 
>>> --
>>> Push the envelope. Watch it bend.
>>> 
>> 
>> --
>> Sjoerd Visscher
>> https://github.com/sjoerdvisscher/blog
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
> 
> 
> 
> -- 
> Push the envelope. Watch it bend.
> 

--
Sjoerd Visscher
https://github.com/sjoerdvisscher/blog






___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Using multiplate to get free variables from a syntax tree

[Matt Brown]

Thanks everyone! This has been interesting and helpful.  I for one had
not seen multirec, but will check it out.  Is the implication that
multirec is more or less complicated than multiplate?

Cheers,
-matt

On Sun, Feb 26, 2012 at 3:28 PM, Sjoerd Visscher  wrote:
> Here's the same code but with a variation on Multiplate that doesn't use 
> records, but a GADT:
> https://gist.github.com/1919528
>
> It is easier on the eyes I think, but probably not any easier to decipher. 
> But hey, this is generic programming for mutually recursive datatypes, that's 
> a complicated subject! (Have you tried multirec?)
>
> Sjoerd
>
> On Feb 26, 2012, at 12:21 AM, Thomas Schilling wrote:
>
>> No that's correct.  I have to say the multiplate code is incredibly
>> hard to decipher.
>>
>> On 25 February 2012 19:47, Sjoerd Visscher  wrote:
>>> I don't understand what you mean.
>>>
>> ($[]) . foldFor expr freeVariablesPlate $ Add (Let ("x" := Con 1) (Add 
>> (EVar "x") (EVar "y"))) (EVar "x")
>>> (["y","x"],[])
>>>
>>> I.e. free variables y and x, no bound variables. Is that not correct?
>>>
>>> Sjoerd
>>>
>>> On Feb 25, 2012, at 7:15 PM, Thomas Schilling wrote:
>>>
 That will give you the wrong answer for an expression like:

  (let x = 1 in x + y) + x

 Unless you do a renaming pass first, you will end up both with a bound
 "x" and a free "x".

 On 25 February 2012 16:29, Sjoerd Visscher  wrote:
>
> On Feb 24, 2012, at 10:09 PM, Stephen Tetley wrote:
>
>> I'm not familiar with Multiplate either, but presumably you can
>> descend into the decl - collect the bound vars, then descend into the
>> body expr.
>
>> Naturally you would need a monadic traversal
>> rather than an applicative one...
>
>
> It turns out the traversal is still applicative. What we want to collect 
> are the free and the declared variables, given the bound variables. 
> ('Let' will turn the declared variables into bound variables.) So the 
> type is [Var] -> ([Var], [Var]). Note that this is a Monoid, thanks to 
> the instances for ((->) r), (,) and []. So we can use the code from 
> preorderFold, but add an exception for the 'Let' case.
>
> freeVariablesPlate :: Plate (Constant ([Var] -> ([Var], [Var])))
> freeVariablesPlate = handleLet (varPlate `appendPlate` multiplate 
> freeVariablesPlate)
>  where
>    varPlate = Plate {
>      expr = \x -> Constant $ \bounded -> ([ v | EVar v <- [x], v 
> `notElem` bounded], []),
>      decl = \x -> Constant $ const ([], [ v | v := _ <- [x]])
>    }
>    handleLet plate = plate { expr = exprLet }
>      where
>        exprLet (Let d e) = Constant $ \bounded ->
>          let
>            (freeD, declD) = foldFor decl plate d bounded
>            (freeE, _)     = foldFor expr plate e (declD ++ bounded)
>          in
>            (freeD ++ freeE, [])
>        exprLet x = expr plate x
>
> freeVars :: Expr -> [Var]
> freeVars = fst . ($ []) . foldFor expr freeVariablesPlate
>
 freeVars $ Let ("x" := Con 42) (Add (EVar "x") (EVar "y"))
> ["y"]
>
> --
> Sjoerd Visscher
> https://github.com/sjoerdvisscher/blog
>
>
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



 --
 Push the envelope. Watch it bend.

>>>
>>> --
>>> Sjoerd Visscher
>>> https://github.com/sjoerdvisscher/blog
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe@haskell.org
>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>>
>> --
>> Push the envelope. Watch it bend.
>>
>
> --
> Sjoerd Visscher
> https://github.com/sjoerdvisscher/blog
>
>
>
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ghc-mod: Expanding Template Haskell

[山本和彦]

Hello,

I have released ghc-mod v1.10.10. With this version, you can
expnad Template Haskell by using C-cC-e on Emacs.

http://mew.org/~kazu/proj/ghc-mod/en/

Enjoy!

--Kazu

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Reminder Haskell Munich

[Heinrich Hördegen]

 Dear all,

Munich's Haskellers will meet tomorrow, 28. Feb 2012, at 19h30 at Cafe Puck:


http://www.haskell-munich.de/dates


See you,
Heinrich

--
--

hoerde...@funktional.info
www.funktional.info

--


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Job Opportunity: Data Scientist at madvertise Mobile Advertising, Berlin

[Adam Drake]

Hello Haskell-Cafe,

We are a start-up company (currently approximately 70 people) and are
looking to grow our research and technology group by hiring a new Data
Scientist.  This person should have a strong quantitative background
and Haskell experience is a plus.  Bonus points if you have experience
building sizable tool chains and applications or your Haskell
experience has involved analysis and machine learning techniques on
large data sets.  For more information, please visit the job listing
on our website.

http://madvertise.com/en/2012/02/14/data-scientist-fm/

If you have any questions, feel free to contact me directly.  You can
also email questions to Julian Fichter in HR: julian [dot] fichter
(at) madvertise (dot) com.

-- 
Best Regards,
Adam Drake

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe