- Haskell-Cafe - Haskell.org

[ANNOUNCE] HaTeX 3.2
by Daniel Díaz Casanueva 20 Feb '12

20 Feb '12

Hello, A new version (3.2) of HaTeX has been released today to Hackage: http://hackage.haskell.org/package/HaTeX-3.2 HaTeX is the LaTeX language syntax implementation done in Haskell. Key changes in this version are: + LaTeX parser implemented (so new dependency on parsec). + Greek alphabet added to AMSMath module. + New LaTeX package implemented: graphicx. + Function 'documentclass' changed. Further information on this release: http://deltadiaz.blogspot.com/2012/02/hatex-chapter-32.html Library homepage: http://dhelta.net/hprojects/HaTeX Thanks for reading, Daniel Díaz.

1 0

Nico de Bruijn dies at 93
by S D Swierstra 20 Feb '12

20 Feb '12

2 1

Re: [Haskell-cafe] Data.Array.Accelerate initialization timings
by Paul Sujkov 20 Feb '12

20 Feb '12

Yep. It doesn't help: generateArray1 n = Acc.use $ Acc.fromList (Acc.Z Acc.:. n*n*n) [0..n*n*n] still takes the same amount of time. I guess something's wrong elsewhere. On 20 February 2012 16:06, Alex Gremm <algremm(a)googlemail.com> wrote: > Hi Paul, > > even though I just started reading about Accelerate, it seems to me that > you didn't use the "use" method which according to [1] initiates > asynchronous data transfer from host to GPU. > > > Cheers, > Alex > > [1]: http://www.cse.unsw.edu.au/%7Echak/papers/acc-cuda.pdf > On 20/02/12 14:46, Paul Sujkov wrote: > > Hi everyone, > > > > since accelerate mail list seems to be defunct, I'm trying to ask > > specific questions here. The problem is: array initialization in > > Data.Array.Accelerate takes a 10x amount of time in contrast to both > > Data.Array and bare C++ CUDA array initialization. This can be due to > > Data.Array.Accelerate having two backends (however, it's own tests show > > that my nVidia card is CUDA-capable), but I'm not aware of how can I > > profile GPU to check whether it is used or not. Anyway, here's code: > > > > http://hpaste.org/64036 > > > > both generateArray (DIM3) and generateArray1 (DIM1) take the same amount > > of time to initialize array. I'd say the problem is in GPU memory > > copying time, but here's bare C++ code: > > > > http://hpaste.org/64037 > > > > which does exactly the same, but 10 times faster. I'm wandering what am > > I doing wrong and how to check if I really am. Thanks in advance if > > anyone can point me on my mistakes! > > > > -- > > Regards, Paul Sujkov > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Regards, Paul Sujkov

1 0

Re: [Haskell-cafe] Data.Array.Accelerate initialization timings
by Paul Sujkov 20 Feb '12

20 Feb '12

Hi Alex, I've seen that method, but I don't see how can I use it for initialization purposes. It creates Acc (Array e i) from Array e i, but what should I do while I don't have Array yet? And when Array is already initialized, 'use' will transfer it to GPU memory which will add some extra timings, but won't optimize what I have at the moment. However, I'll try to use it somehow. Maybe I misunderstand the mechanics. Thanks a lot! On 20 February 2012 16:06, Alex Gremm <algremm(a)googlemail.com> wrote: > Hi Paul, > > even though I just started reading about Accelerate, it seems to me that > you didn't use the "use" method which according to [1] initiates > asynchronous data transfer from host to GPU. > > > Cheers, > Alex > > [1]: http://www.cse.unsw.edu.au/%7Echak/papers/acc-cuda.pdf > On 20/02/12 14:46, Paul Sujkov wrote: > > Hi everyone, > > > > since accelerate mail list seems to be defunct, I'm trying to ask > > specific questions here. The problem is: array initialization in > > Data.Array.Accelerate takes a 10x amount of time in contrast to both > > Data.Array and bare C++ CUDA array initialization. This can be due to > > Data.Array.Accelerate having two backends (however, it's own tests show > > that my nVidia card is CUDA-capable), but I'm not aware of how can I > > profile GPU to check whether it is used or not. Anyway, here's code: > > > > http://hpaste.org/64036 > > > > both generateArray (DIM3) and generateArray1 (DIM1) take the same amount > > of time to initialize array. I'd say the problem is in GPU memory > > copying time, but here's bare C++ code: > > > > http://hpaste.org/64037 > > > > which does exactly the same, but 10 times faster. I'm wandering what am > > I doing wrong and how to check if I really am. Thanks in advance if > > anyone can point me on my mistakes! > > > > -- > > Regards, Paul Sujkov > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe(a)haskell.org > > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Regards, Paul Sujkov

1 0

Data.Array.Accelerate initialization timings
by Paul Sujkov 20 Feb '12

20 Feb '12

Hi everyone, since accelerate mail list seems to be defunct, I'm trying to ask specific questions here. The problem is: array initialization in Data.Array.Accelerate takes a 10x amount of time in contrast to both Data.Array and bare C++ CUDA array initialization. This can be due to Data.Array.Accelerate having two backends (however, it's own tests show that my nVidia card is CUDA-capable), but I'm not aware of how can I profile GPU to check whether it is used or not. Anyway, here's code: http://hpaste.org/64036 both generateArray (DIM3) and generateArray1 (DIM1) take the same amount of time to initialize array. I'd say the problem is in GPU memory copying time, but here's bare C++ code: http://hpaste.org/64037 which does exactly the same, but 10 times faster. I'm wandering what am I doing wrong and how to check if I really am. Thanks in advance if anyone can point me on my mistakes! -- Regards, Paul Sujkov

1 0

11th GhentFPG meeting: Tuesday 20th of March at 19:30h. Location and program TBA shortly.
by Jeroen Janssen 20 Feb '12

20 Feb '12

(apologies if you receive multiple postings) Dear all, The date has been decided and the 11th GhentFPG meeting will take place on Tuesday, the 20th of March at 19:30h. Note that due to organizational issues, we will be moving to a different location (still in Ghent though!). The program and exact location will be communicated shortly. We have two talks lined up and thus have room for one extra lightning talk, so if you have something to talk about do not hesitate to contact one of the organizers! Kind Regards, The GhentFPG organizing committee.

1 0

Disabling warning over ranges of source lines
by Thomas DuBuisson 20 Feb '12

20 Feb '12

Using GHC, is there any way to disable warnings (entirely or selectively) during a section of source code? I ask because of some Template Haskell that periodically generates unused code and I'd rather not see the warnings or rework the macros (beyond emitting some sort of "disable" and "re-enable" pragma which probably isn't in the AST now that I think about it). Cheers, Thomas

2 1

Test suite sections of cabal
by Kazu Yamamoto 20 Feb '12

20 Feb '12

Hello, I recently started using test suite sections of cabal but it soon appeared very inconvenient to me. 1) test data files If I want to include test data files into package, I have to enumerate all test files since the usage of '*' is restricted. I just want to specify the top directory of test data files. Why does this restriction exist? 2) build-dependency I need to repeat all build-dependency of a library section to a test suite section. Specifying the library itself to build-dependency of a test suite section does not work. This violates the DRY philosophy. Any ideas to avoid this? Thanks. --Kazu

2 4

Failing to find a function
by Jon Fairbairn 19 Feb '12

19 Feb '12

This is probably a failure of my search fu or some other mental lacuna, but is there already a definition of this function somewhere: \a b -> runKleisli $ (Kleisli a) <+> Kleisli b ? Hoogling for its type MonadPlus m => (a -> m b) -> (a -> m b) -> a -> m b doesn’t net me anything useful. -- Jón Fairbairn Jon.Fairbairn(a)cl.cam.ac.uk

3 3

Re: [Haskell-cafe] "Best" FRP package for newbie
by Adam Duracz 19 Feb '12

19 Feb '12

Hi Arnaud, While not necessarily in line with the state of the art of FRP libraries, I can warmly recommend going through the parts of Paul Hudak's "Haskell School Of Expression" that cover the Functional Animation Library ("FAL", basically a light version of Fran). The book introduces FRP concepts gently and FAL is really nice to work with, at least when it comes to the type of code that is discussed in that book. Good luck! //Adam On Feb 17, 2012, at 12:00 , haskell-cafe-request(a)haskell.org wrote: > Hello, > I am interested in exploring more in depth FRP. I had a look at the wiki > page and started to explore "reactive" which looked promising at first > glance and backed by quite a few articles and tutorials, but 1) it did not > install properly on my haskell platform and 2) from the mailing-list > archives it seems to have died a couple of years ago. > > So my question is : What package would you recommend me to get my hands > dirty with FRP? I am mostly interested in things related to music and > network programming, if that matters. > > Thanks in advance for your help, > > Arnaud

3 2