Re: [Haskell-cafe] Happstack-state in non-happstack production apps

2012-02-11 Thread dag.odenh...@gmail.com
On 10 February 2012 23:09, Antoine Latter aslat...@gmail.com wrote:
 On Fri, Feb 10, 2012 at 3:56 PM, Tom Murphy amin...@gmail.com 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


Re: [Haskell-cafe] some question about conduit usage

2012-02-11 Thread Michael Snoyman
On Fri, Feb 10, 2012 at 4:26 PM, Alexander V Vershilov
alexander.vershi...@gmail.com 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


[Haskell-cafe] question regarding Data.Array.Accelerate

2012-02-11 Thread Philipp
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


[Haskell-cafe] Calling OpenGL functions from multiple threads

2012-02-11 Thread Clark Gaebel
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


Re: [Haskell-cafe] Some thoughts on Type-Directed Name Resolution

2012-02-11 Thread wren ng thornton

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


Re: [Haskell-cafe] ANN: stm-conduit-0.2.1

2012-02-11 Thread wren ng thornton

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


[Haskell-cafe] Any advices on optimizing an array processing in a pitch tuner

2012-02-11 Thread Dmitry Vyal

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] Calling OpenGL functions from multiple threads

2012-02-11 Thread Thomas Davie
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