February 2012 - Haskell-Cafe

[ANNOUNCE] fb package, bindings to Facebook's API
by Felipe Almeida Lessa 13 Feb '12

13 Feb '12

Hello, everyone! I'm pleased to finally announce the fb package, a Haskell-only package that provides bindings to Facebook's API. This package is sponsored by my employer, which will soon enough be able to become the copyright holder of all of our open source contributions. http://hackage.haskell.org/package/fb It's by no means complete, but we thrive to be as correct as possible and to turn API errors into type errors caught at compile time. Right now the current version is fb 0.7.2. While this is the first announcement, this package is already being actively used by Facebook authentication code on Yesod (yesod-auth-fb package) and internally at my day job's projects. Hope you find it useful! =) Cheers, -- Felipe.

1 0

Re: [Haskell-cafe] ANN: stm-conduit-0.2.1
by John Lato 13 Feb '12

13 Feb '12

> Message: 6 > Date: Sun, 12 Feb 2012 01:47:40 -0500 > From: wren ng thornton <wren(a)freegeek.org> > Subject: Re: [Haskell-cafe] ANN: stm-conduit-0.2.1 > To: Haskell Cafe <haskell-cafe(a)haskell.org> > Message-ID: <4F37608C.3090808(a)freegeek.org> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/9/12 2:29 PM, Felipe Almeida Lessa wrote: >> Your package uses TMChans which AFAIK are unbounded. That means that >> if the writer is faster than the reader, then everything will be kept >> into memory. This means that using TMChans you may no longer say that >> your program uses a constant amount of memory. Actually, you lose a >> lot of your space reasoning since, being concurrent processes, you >> can't guarantee almost anything wrt. progress of the reader. > > Of course, you're free to use TBMChans instead, which are bounded :) This is what I did in iteratee-stm. The stm-chans package is very nice. (and the results with iteratee-stm were very good as well) John L.

1 0

A universal data store interface
by Sergiu Ivanov 13 Feb '12

13 Feb '12

Hello, I am interested in applying for GSoC-2012 with the Haskell community. (I think I've told that to quite a number of people already, sorry for the duplicate.) I'm currently digging my way towards http://hackage.haskell.org/trac/ghc/ticket/4213 . However, instead of focusing on a single project right now, I'd like to diversify a bit and consider at least one more project. I've come over this: http://hackage.haskell.org/trac/summer-of-code/ticket/1605 . It looks quite interesting and also promising in the sense that it is going to be useful to many people. However, this page http://hackage.haskell.org/trac/summer-of-code/report/1 states the priority is undefined for this project, which makes me wonder whether the Haskell community would be interested in having a GSoC student work on the task. If the community is interested in having a student assigned to this task, I'd be glad to submit proposal for this project as well. Sergiu

1 0

ghc-mod v1.10.3
by Kazu Yamamoto 13 Feb '12

13 Feb '12

Hello, I have just released ghc-mod v1.10.3. C-cC-t of this version was powered by Hideyuki Tanaka. The old implementation just show the type of the current expression on Emacs. Howver, the new implementation first show the type of the current expression and the expression is highlighted. If you type C-cC-t again, the region is enlarged to its upper expression, and its type is displayed. # I don't know well but this is called "annot" in the OCaml community Enjoy! --Kazu

1 0

ANN: stm-conduit-0.2.1
by Clark Gaebel 12 Feb '12

12 Feb '12

Hi all, I've just released stm-conduit [1] on Hackage. This package introduces conduits to the wonderful world of concurrency. My package solves the common problem of constant bottleneck switching loaders have. This is when, for example, we stream XML from the disk and then parse the XML in one conduit pipeline. While it streams a file from the disk, the process is clearly IO bound, and while it parses the XML, the process is CPU bound. By putting each task on its own thread, the disk IO doesn't need to wait for the CPU to parse a document before loading the next file. By using stm-based conduits, we have full resource utilization. The way it does this is by creating a source and sink for TChans, letting us stream data between conduits and channels. There are more examples in the docs. Check it out! Regards, - clark [1] http://hackage.haskell.org/package/stm-conduit

4 6

question regarding Data.Array.Accelerate
by Philipp 12 Feb '12

12 Feb '12

Hi, I have read the papers about the accelerate package that provides a high-level interface to nvidia's cuda library and am very intrigued. However, I have some start-up problems. Is this the right place for such questions? In particular, I'm having trouble with lifting and unlifting. From what I understood, I should be able to use unlift to get an Int from an Exp (Plain Int), but when I try, for example, (unlift . lift) (1::Int) :: Int ghci complains with "No instance for (Unlift Int)". I have the latest versions of accelerate (accelerate-0.9.0.1) and ghc (version 7.4.1). I think I'm missing something obvious, so if any of you could point it out to me I would be glad. Thanks, Philipp -- View this message in context: http://haskell.1045720.n5.nabble.com/question-regarding-Data-Array-Accelera… Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.

1 1

Calling OpenGL functions from multiple threads
by Clark Gaebel 12 Feb '12

12 Feb '12

Do the OpenGL bindings on Hackage expose anything like glXMakeCurrent [1]? I need to use OpenGL functions from multiple threads (note: not at once, I protect it with an MVar), but that's forbidden in extension-less OpenGL. Thanks, - clark [1] http://www.talisman.org/opengl-1.1/Reference/glXMakeCurrent.html

2 1

Any advices on optimizing an array processing in a pitch tuner
by Dmitry Vyal 12 Feb '12

12 Feb '12

Hello Haskellers, Recently I've revived my old toy project. It's a sound spectrum analyzer with Gtk2hs interface. I decided to rewrite it into a pitch tuner. Basically I'm done, but I've ran into performance difficulties while trying to rise a resolution in a frequency space. The original code used Storable arrays to get data out of fftw, for some processing I convert it to lists, which obviously hinders performance. I've heard there are some modern efficient array processing libraries available. So I hope I can avoid writing all those low-level for loops. Any hints on how to optimize and prettify the code are welcome. Repository is located at https://github.com/akamaus/HTuner Best regards, Dmitry

1 0

Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
by Anthony Clayden 12 Feb '12

12 Feb '12

> > I chose the most available non-ASCII character I could > find. Set the criterion to be "present in most ISO 8-bit > character sets" and there are really only two candidates, > section sign and degrees sign. ... > Brilliant! We'll use degrees sign for function composition (so that it follows the convention in everything except a handful of obscure programming languages). That frees up dot for record.field. And still we can scratch our heads for something to do with section sign. SS as in set? Some smoother syntax for swifter, saner, salubrious setting. Super! AntC

2 1

some question about conduit usage
by Alexander V Vershilov 11 Feb '12

11 Feb '12

Hello, cafe! I have somq questions about proper conduit usage in some usecases, I can't find a good way to solve this problems 1). adding additional source to conduit processing [1] Sometimes I want to run a Source and send use it to produce output e.g. have something like: > runSource :: ResourceT m => a -> Source m b > runSource = undefined > > test1 :: ResourceT m => Conduit a m b > test1 = Conduit push close > where > push = runSource > close = undefined > -- In my first problem I've got > -- push i = case i of Left _ -> oneValue ; Right -> runSource > -- but it can be solved with oneValue = sourceList [oneValue] 2). pushing data back [1] e.g. I have > test2 :: ResourceT Conduit ByteString m b > test2 = Conduit push close > where > conduit i = let (item,lft) = parse i > in -- I want to send lft back to test2 and > -- process item > -- in the other case I want to be able to send data back to > -- previous or arbitrary level, e.g. > test1 $= test2 $= test3 > ^--------| (<<<=) lft 3). split stream to send it to different Sinks, e.g. > sendToAll test3 [sink1,sink2,sink3] 4). send additional data from the other place, e.g. > src $= handle $$ snk > -- state -^ > -- I want to send message into handle to change it's state > -- It can be done with stm-conduit and Either (Left for commands > -- and Right for data), but it seems its overkill I will be apprecated, if smb has any idea how to implement it correnly, or why I shouldn't implement it at all. [1] http://stackoverflow.com/questions/9226780/how-to-add-a-new-source-inside-a… -- Regards, Alexander V Vershilov

2 1