Hello,
Sorry for the delay but I made a patch and sent a pull request:
https://github.com/haskell/network/pull/18
After consideration, I realized that Johan's opinion is better.
Please read the comment of this request above.
When the next network package will be released, this problem
I've released a new version of network, 2.3.0.6, that contains the fix.
On Wed, Sep 28, 2011 at 1:34 AM, Kazu Yamamoto k...@iij.ad.jp wrote:
Hello,
Sorry for the delay but I made a patch and sent a pull request:
https://github.com/haskell/network/pull/18
After consideration, I
Hi Michael,
Kazu recently fixed this (in the stable branch on GitHub) in
Network.listenOn but perhaps the more basic Network.Socket.listen should
also be changed. Lets discuss what's the right thing to do in this thread.
On Wed, Sep 21, 2011 at 1:38 PM, Michael Snoyman mich...@snoyman.comwrote:
Hello,
My fix intended that Haskell code behaves the same in various
environments. That is, one socket catches both IPv4 and IPv6. And the
fix works even in both IPv4-only env and IPv6-only env.
Johan's observation is correct. Network.listenOn is alreay fixed but
Network.Socket.listen, which
Hi,
On Wed, Sep 21, 2011 at 7:38 PM, Kazu Yamamoto k...@iij.ad.jp wrote:
Johan's observation is correct. Network.listenOn is alreay fixed but
Network.Socket.listen, which Warp relies on, is not fixed yet. I will
try to fix it. When the next version of the network library will be
released,
Hi,
We should consider how we fix this. Right now N.S.listen just wraps the
underlying system call. Is that the right place to set socket options? Perhaps
we should set them when creating the socket instead?
Yes, of course.
If I remember correctly, this option works only between socket() and
