Hi!
Thanks to all who responded! I got a lot of information to read and think about.
For now I decided to use stm-channelize as the simplest approach which
seem to be enough.
On Mon, Mar 5, 2012 at 9:50 PM, Alexander V Vershilov
alexander.vershi...@gmail.com wrote:
Hello.
I've also written
Hello.
I've also written simple chat server based on conduits and stm channels
https://github.com/qnikst/chat-server/blob/master/src/Main.hs
it has quite similar aproach and maybe this solution can be used together
to have better results.
--
Alexander Vershilov
Sat, Mar 03, 2012 at 02:05:17AM
On Fri, Mar 2, 2012 at 5:19 PM, Paul Graphov grap...@gmail.com wrote:
Hello Cafe!
I am trying to implement networked application in Haskell. It should
accept many
client connections and support bidirectional conversation, that is not
just loop with
Request - Response function but also
Hi,
On Sat, Mar 3, 2012 at 10:38 AM, Gregory Collins g...@gregorycollins.netwrote:
Hi,
The tutorial I gave for CUFP 2011 was a multi-user web chat program using
the Snap Framework. STM channels make this kind of problem super-easy to
deal with. Don't be afraid of forking lots of Haskell
On Sat, Mar 3, 2012 at 12:50 PM, Alp Mestanogullari alpmes...@gmail.comwrote:
That's exactly what I would have needed, several times in the past 2
years. I've been wondering about a good way to abstract this to have a
library where you'd just plug your business logic and thus not have to
care
Hello Cafe!
I am trying to implement networked application in Haskell. It should accept many
client connections and support bidirectional conversation, that is not
just loop with
Request - Response function but also sending notifications to clients etc.
NB: I came from C++ background and used to
Hello, Paul.
It seems you should not use 3 threads, but run in a data-driven behaviour with
one thread per client.
You can take a look at network-conduit [1] example, there is a very good aproach
to tcp-network application. There are some iteratee based examples but they are
not so extensible.
On Fri, Mar 2, 2012 at 3:04 PM, Alexander V Vershilov
alexander.vershi...@gmail.com wrote:
Hello, Paul.
It seems you should not use 3 threads, but run in a data-driven behaviour with
one thread per client.
I don't think this will work for Paul's situation. He needs to be
able to send
Fri, Mar 02, 2012 at 07:34:41PM -0500, Joey Adams wrote
On Fri, Mar 2, 2012 at 3:04 PM, Alexander V Vershilov
alexander.vershi...@gmail.com wrote:
Hello, Paul.
It seems you should not use 3 threads, but run in a data-driven behaviour
with
one thread per client.
I don't think this
On Fri, Mar 2, 2012 at 7:34 PM, Joey Adams joeyadams3.14...@gmail.com wrote:
I'll try to put together a simple chat server example, like the one I
wrote for stm-channelize.
Here it is:
https://github.com/joeyadams/haskell-chat-server-example
See, in particular, the serveLoop function.
Hello Haskellers,
Having been pretty much impressed by Don Stewart's Practical Haskell
(http://donsbot.wordpress.com/2010/08/17/practical-haskell/), I
started to write a Haskell script to run maven jobs (yes, I know...).
In the course of undertaking this fantastic endeavour, I started to
use the
On 14/09/10 07:45, Arnaud Bailly wrote:
What surprised me is that I would expect the behaviour of the two
functions to be different:
- in doRunMvnInIO, I would expect stdout's content to be printed
before stderr, ie. the 2 threads are ordered because I call takeMVar
in between calls to forkIO
Probably did not test enough. Sorry for the noise.
arnaud
On Tue, Sep 14, 2010 at 12:18 PM, Neil Brown nc...@kent.ac.uk wrote:
On 14/09/10 07:45, Arnaud Bailly wrote:
What surprised me is that I would expect the behaviour of the two
functions to be different:
- in doRunMvnInIO, I would
13 matches
Mail list logo
