Re: [Haskell-cafe] Calling OpenGL functions from multiple threads
Just for reference – glX functions are not OpenGL functions at all, they're also not extensions to OpenGL, so I'd be very surprised if they could be got at from the Haskell GL bindings. glX is instead a library for creating OpenGL contexts (and working with them) for X11. As the Haskell bindings for OpenGL are for OpenGL, not X windows, they don't support this call. Though another package (not sure which, because it doesn't apply on my platform) may well include it. Bob if (*ra4 != 0xffc78948) { return false; } On 12 Feb 2012, at 03:03, Clark Gaebel wrote: > 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 > ___ > 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] Any advices on optimizing an array processing in a pitch tuner
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: stm-conduit-0.2.1
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 :) -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution
On 2/8/12 10:10 PM, Anthony Clayden wrote: 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). Even better, use the section symbol for getting and setting the various sections/fields of a record! ;) -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Calling OpenGL functions from multiple threads
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 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] question regarding Data.Array.Accelerate
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-Accelerate-tp5476144p5476144.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] some question about conduit usage
On Fri, Feb 10, 2012 at 4:26 PM, Alexander V Vershilov wrote: > 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] We have a `sequenceSink` function that takes a `Sink` and turns it into a `Conduit` by running it repeatedly. It looks to me like the best approach would be to have an equivalent `sequenceSource`, something like: sequenceSource :: (a -> Source m b) -> Conduit a m b I can help out with implementation. > 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 This is purposely not allowed currently, for various low-level reasons. I can get into details if anyone's curious, but don't have time at the moment. > 3). split stream to send it to different Sinks, e.g. >> sendToAll test3 [sink1,sink2,sink3] It's mostly straight-forward to implement, but there are some questions. In particular: what do you do if sink1 terminates earlier than sink2? Do you call sinkClose on sink2, or continue pulling data until all of the sinks close? Also, I think it could be a Sink, e.g.: sendToAll :: [Sink a m b] -> Sink a m [b] > 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'm not sure what you're looking for here. You want to control the behavior of src from snk? If you just want to modify the handle from snk, you could pass the handle to snk directly. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Happstack-state in non-happstack production apps
On 10 February 2012 23:09, Antoine Latter wrote: > On Fri, Feb 10, 2012 at 3:56 PM, Tom Murphy wrote: >> Hi, >> Is it common to use happstack-state without happstack for >> real-world code (web or otherwise)? >> > > The package 'acid-state' is considered the successor to > happstack-state, and it doesn't include 'happstack' in it's name to > advertise that it is quite usable outside of happstack. > > I don't have a list of who does, though. > > http://hackage.haskell.org/package/acid-state > > Antoine There's even a snaplet for acid-state: http://hackage.haskell.org/package/snaplet-acid-state ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe