Felipe Almeida Lessa wrote:
> What about inverting which thread gets to do what?
>
> _ <- resourceForkIO $ sourceHandle hsock $$ sinkHandle stdout
> sourceHandle stdin $$ sinkHandle hsock
> release releaseSock
Thats an interesting idea. Unfortunately this doesn't work correctly
in that if
On Wed, Jan 11, 2012 at 10:28 PM, Erik de Castro Lopo
wrote:
>
> Thanks for the input Felipe.
>
> Felipe Almeida Lessa wrote:
>
>> On line 29, instead of
>>
>> liftIO $ do
>> mapM_ ...
>> runResourceT $ do
>
> Well that was because that whole block needs to run in IO.
My point is that t
A new solution that drops two 'runResourceT' calls:
telnet :: String -> Int -> IO ()
telnet host port = runResourceT $ do
(releaseSock, hsock) <- with (connectTo host $ PortNumber $ fromIntegral
port) hClose
liftIO $ mapM_ (\h -> hSetBuffering h LineBuffering) [ stdin, stdout, hsock
]
Thanks for the input Felipe.
Felipe Almeida Lessa wrote:
> On line 29, instead of
>
> liftIO $ do
> mapM_ ...
> runResourceT $ do
Well that was because that whole block needs to run in IO.
> Regarding threads, you should use resourceForkIO [1] which has a quite
> nicer interface.
I
On line 29, instead of
liftIO $ do
mapM_ ...
runResourceT $ do
...
...
why not
liftIO $ mapM_ ...
...
...
?
Regarding threads, you should use resourceForkIO [1] which has a quite
nicer interface. So you telnet would end like:
telnet :: String -> Int -> IO ()
telnet h
Hi all,
I've written a simple telnet client using Michael Snoyman's Conduit
library and was looking for comments as to whether I'm doing it
right. In particular, is my usage of a ResourceT to track a thread
a good idea, necessary or waste of time.
The code is here:
https://gist.github.com/15