Nabble - Haskell - Libraries

[network] `setSocketOption' fails with `Linger' option

2009-11-30T06:49:13Z

See http://is.gd/57Ptu (Network.Socket.setSocketOption).

`setSocketOption' uses FFI binding to setsockopt(2), named
`c_setsockopt'.

> foreign import CALLCONV unsafe "setsockopt"
> c_setsockopt :: CInt -> CInt -> CInt -> Ptr CInt -> CInt -> IO CInt

The binding treats OPTVAL (4th argument) as a pointer to `int'. This
is mostly fine but not when `SO_LINGER' option is being set. In the
latter case OPTVAL must be a pointer to `struct linger'. [1]

[1] http://www.gnu.org/s/libc/manual/html_node/Socket_002dLevel-Options.html

Haskell programs trying to set SO_LINGER socket option will
successfully compile but fail in runtime.

$ runhaskell socket-linger.hs || echo X
$ runhaskell -DLINGER socket-linger.hs || echo X
socket-linger.hs: setSocketOption: invalid argument (Invalid argument)
X

$ gcc -g -Wall -W -o /tmp/1 socket-linger.c && /tmp/1 || echo X
$ gcc -g -DLINGER_AS_INT -Wall -W -o /tmp/1 socket-linger.c &&
/tmp/1 || echo X
setsockopt: Invalid argument
X

(See attached files `socket-linger.c', `socket-linger.hs'.)

The necessity of `SO_LINGER' option is controversial (see [2]).
I think it is better to comment the `Linger' constructor out of
Network/Socket.hsc.

[2] http://www.developerweb.net/forum/archive/index.php/t-2982.html

Cheers.

--
vvv

[socket-linger.hs]

{-# LANGUAGE CPP #-} module Main where import Network.Socket main = do (ap:_) <- getAddrInfo (Just hints) (Just "slashdot.org") (Just "80") h <- socket AF_INET Stream tcp #ifdef LINGER setSocketOption h Linger 5 -- ==> Exception: setSocketOption: invalid argument (Invalid argument) #endif connect h (addrAddress ap) sClose h where tcp = 6 -- awk '($1 == "tcp") {print $2}' /etc/protocols hints = defaultHints { addrFamily = AF_INET , addrSocketType = Stream , addrProtocol = tcp }

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

socket-linger.c (1K) Download Attachment

Re: Guarantees regarding finalizers

2009-11-30T06:45:48Z

On 26/11/2009 12:41, Mietek Bąk wrote:

> I'm writing a binding to a C library, which requires an explicit
> cleanup call before program termination. While looking for a way to
> automatize this, I noticed a discrepancy in the standard library
> documentation.
>
> The Foreign.Concurrent documentation states:
> "The only guarantee is that the finalizer runs before the program terminates."
> (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-Concurrent.html)
>
> On the other hand, the Foreign.ForeignPtr documentation states:
> "Indeed, there is no guarantee that the finalizer is executed at all;
> a program may exit with finalizers outstanding."
> (http://www.haskell.org/ghc/docs/latest/html/libraries/base/Foreign-ForeignPtr.html)
>
> Note that Foreign.Concurrent.newForeignPtr is implemented in GHC as
> GHC.ForeignPtr.newConcForeignPtr. The newConcForeignPtr comments also
> state:
> "There is no guarantee of promptness, and in fact there is no
> guarantee that the finalizer will eventually run at all."
> (http://www.haskell.org/ghc/docs/latest/html/libraries/base/src/GHC-ForeignPtr.html)
>
> As much as I would like the Foreign.Concurrent guarantee to be true,
> this seems to me like a documentation bug.

The docs are rather backward. Foreign.ForeignPtr finalizers are
guaranteed to run, Foreign.Concurrent finalizers are not. I'll fix the
docs, thanks for the report.

Cheers,
Simon
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[network] new tickets submission unavailable

2009-11-30T05:40:24Z

> Example in the haddock documentation for `getAddrInfo' function is
> rendered incorrectly

And what's the purpose of issue tracking system, which even _registered_
user cannot create a ticket for?

http://trac.haskell.org/network/wiki

"What the bug?"

--
vvv
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

[network] getAddrInfo: invalid haddock (+ patch)

2009-11-30T05:32:56Z

Example in the haddock documentation for `getAddrInfo' function is
rendered incorrectly:

http://is.gd/57LgX

-----BEGIN PATCH-----
--- Network/Socket.hsc.orig 2009-11-30 15:08:57.869477201 +0200
+++ Network/Socket.hsc 2009-11-30 15:08:28.328452505 +0200
@@ -1972,9 +1972,10 @@
-- to make partial application easier.
--
-- Example:
+--
-- @
-- let hints = defaultHints { addrFlags = [AI_ADDRCONFIG, AI_CANONNAME] }
--- addrs <- getAddrInfo (Just hints) (Just "www.haskell.org") (Just "http")
+-- addrs <- getAddrInfo (Just hints) (Just \"www.haskell.org\")
(Just \"http\")
-- let addr = head addrs
-- sock <- socket (addrFamily addr) (addrSocketType addr) (addrProtocol addr)
-- connect sock (addrAddress addr)
-----END PATCH-----

--
vvv

[getAddrInfo-haddock.patch]

--- Network/Socket.hsc.orig 2009-11-30 15:08:57.869477201 +0200 +++ Network/Socket.hsc 2009-11-30 15:08:28.328452505 +0200 @@ -1972,9 +1972,10 @@ -- to make partial application easier. -- -- Example: +-- -- @ -- let hints = defaultHints { addrFlags = [AI_ADDRCONFIG, AI_CANONNAME] } --- addrs <- getAddrInfo (Just hints) (Just "www.haskell.org") (Just "http") +-- addrs <- getAddrInfo (Just hints) (Just \"www.haskell.org\") (Just \"http\") -- let addr = head addrs -- sock <- socket (addrFamily addr) (addrSocketType addr) (addrProtocol addr) -- connect sock (addrAddress addr)

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

RE: GHC 6.12 + zlib + Mac OS 10.6

2009-11-30T04:22:08Z

On Mon, 2009-11-30 at 12:20 +0000, Simon Peyton-Jones wrote:
> | For ghc-6.12, we should just fix ticket #3681.
>
> OK, good. But who is "we"?

I think the short-term fix is just to change the hsc2hs wrapper script.
So that'd be Ian.

Longer term we might want to do it differently to allow a single hsc2hs
instance to be used to target either 32 or 64bit ABIs on the same
platform.

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

RE: GHC 6.12 + zlib + Mac OS 10.6

2009-11-30T04:20:24Z

| For ghc-6.12, we should just fix ticket #3681.

OK, good. But who is "we"?

Simon

| -----Original Message-----
| From: libraries-bounces@... [mailto:libraries-bounces@...] On Behalf
| Of Duncan Coutts
| Sent: 30 November 2009 10:41
| To: Simon Peyton-Jones
| Cc: glasgow-haskell-users@...; Haskell Libraries
| Subject: RE: GHC 6.12 + zlib + Mac OS 10.6
|
| On Mon, 2009-11-30 at 08:44 +0000, Simon Peyton-Jones wrote:
| > Should this go in a FAQ? For GHC? Or for a particular architecture?
|
| For ghc-6.10, yes. It'd should be a section "GHC on OSX 10.6 (Snow
| Leopard)" and should describe the changes required to the shell script
| wrappers of ghc and hsc2hs. It should also note that none of this is
| necessary for ghc-6.12+.
|
| For ghc-6.12, we should just fix ticket #3681.
|
| http://hackage.haskell.org/trac/ghc/ticket/3681
|
|
| Duncan
|
| _______________________________________________
| Libraries mailing list
| Libraries@...
| http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-30T03:59:57Z

On Sun, Nov 29, 2009 at 11:37:45AM -0800, Alexander Dunlap wrote:
> What is the plan for letting the two co-exist? Is everyone going to
> have to write instances that work with both monads-{tf,fd} and then
> export duplicate functions that have monad classes in their
> signatures?

Most clients just use the transformers to make composite monads, and
the classes to get the operations. They can just pick one or the
other for their private use.

People defining and exporting their own monads will probably want to
make them instances of both versions of the classes.

If a package's interface uses the transformers (or the Haskell 98 classes
MonadTrans and MonadIO), it will work with both monads packages.

That leaves the packages that have FD or TF classes in their interfaces.
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-30T03:28:17Z

On Sun, Nov 29, 2009 at 07:48:56PM +0000, Duncan Coutts wrote:
> I'm not really saying whether it should be the tf or fd version.
> I've not been taking part in that discussion.

You haven't missed anything. I think we're a long way off being ready to
make a final choice between FDs and TFs. For one thing neither of them
is standard, and both monads-* packages also require other non-standard
extensions.

But we are at the point where we can decide to make FDs optional, though
that hasn't been decided yet either.

That's not to say that the HP shouldn't present a pre-packaged choice
(probably FDs for some time), just that it shouldn't get in the way of
alternatives.
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

RE: GHC 6.12 + zlib + Mac OS 10.6

2009-11-30T02:41:24Z

On Mon, 2009-11-30 at 08:44 +0000, Simon Peyton-Jones wrote:
> Should this go in a FAQ? For GHC? Or for a particular architecture?

For ghc-6.10, yes. It'd should be a section "GHC on OSX 10.6 (Snow
Leopard)" and should describe the changes required to the shell script
wrappers of ghc and hsc2hs. It should also note that none of this is
necessary for ghc-6.12+.

For ghc-6.12, we should just fix ticket #3681.

http://hackage.haskell.org/trac/ghc/ticket/3681

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: GHC 6.12 + zlib + Mac OS 10.6

2009-11-30T02:38:29Z

I think this is a problem for architectures in which can only build
32-bit binaries.

On such architectures, hsc2hs should ensure to work for 32-bit
binaries as possible. So I think hsc2hs wrapper should be fixed to
give the flags if gcc is used.

--nwn

On Mon, Nov 30, 2009 at 5:44 PM, Simon Peyton-Jones
<simonpj@...> wrote:

> Should this go in a FAQ? For GHC? Or for a particular architecture?
>
> Simon
>
> | -----Original Message-----
> | From: glasgow-haskell-users-bounces@... [mailto:glasgow-haskell-users-
> | bounces@...] On Behalf Of Antoine Latter
> | Sent: 28 November 2009 23:01
> | To: Yusaku Hashimoto
> | Cc: glasgow-haskell-users@...; Haskell Libraries
> | Subject: Re: GHC 6.12 + zlib + Mac OS 10.6
> |
> | On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto <nonowarn@...> wrote:
> | > I think you installed zlib without proper flags to link with 32-bit
> | > libraries. configuring with ./Setup configure
> | > --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks.
> | >
> | > See also http://hackage.haskell.org/trac/ghc/ticket/3681.
> | >
> | > HTH
> | > -~nwn
> |
> | The following worked like a charm:
> |
> | cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32'
> |
> | Thanks for the tip.
> |
> | Antoine
> | _______________________________________________
> | Glasgow-haskell-users mailing list
> | Glasgow-haskell-users@...
> | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-30T02:37:48Z

On Mon, Nov 30, 2009 at 3:03 AM, wren ng thornton <wren@...> wrote:

Edward Kmett wrote:

As a straw man proposal to get things started:

transformers:
Control.Monad.Foo.Transformer - for the actual data type for FooT

Feel free to amend that to keep the monad transformers where they are under Control.Monad.Trans.Foo - I hadn't checked before writing that out and have no real reason to move them.

-Edward Kmett

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-30T02:35:25Z

It's consistent and avoids name-clashery, which is nice. But I thought transformers had everything in one file? Maybe I'm thinking of a different monad transformer library...

I believe you are thinking of monadLib.

-Edward Kmett

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

RE: GHC 6.12 + zlib + Mac OS 10.6

2009-11-30T00:44:34Z

Should this go in a FAQ? For GHC? Or for a particular architecture?

Simon

| -----Original Message-----
| From: glasgow-haskell-users-bounces@... [mailto:glasgow-haskell-users-
| bounces@...] On Behalf Of Antoine Latter
| Sent: 28 November 2009 23:01
| To: Yusaku Hashimoto
| Cc: glasgow-haskell-users@...; Haskell Libraries
| Subject: Re: GHC 6.12 + zlib + Mac OS 10.6
|
| On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto <nonowarn@...> wrote:
| > I think you installed zlib without proper flags to link with 32-bit
| > libraries. configuring with ./Setup configure
| > --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks.
| >
| > See also http://hackage.haskell.org/trac/ghc/ticket/3681.
| >
| > HTH
| > -~nwn
|
| The following worked like a charm:
|
| cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32'
|
| Thanks for the tip.
|
| Antoine
| _______________________________________________
| Glasgow-haskell-users mailing list
| Glasgow-haskell-users@...
| http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-30T00:03:08Z

Edward Kmett wrote:

> As a straw man proposal to get things started:
>
> transformers:
> Control.Monad.Foo.Transformer - for the actual data type for FooT
>
> mtl 2:
> Control.Monad.Foo.Class - exports just the fundep-based typeclass and no
> instances, like now.
> Control.Monad.Foo - exports the instances for the fundep based version and
> re-exports the Transformer and Class module contents.
>
> mtl-tf:
> Control.Monad.Foo.Family.Class - exports just the type-family based
> typeclass
> Control.Monad.Foo.Family - exports the instances of the typefamily base
> version and re-exports the Transformer and Family.Class modules
>
> This will safely let most libraries just use a constraint on mtl >= 1.2 &&
> <= 2.1 in which case their code works across both versions, and if someone
> wants to use mtl-tf for clarity in their code, it will introduce no
> complications regardless of what libraries they import as long as those
> libraries can support both versions.

It's consistent and avoids name-clashery, which is nice. But I thought
transformers had everything in one file? Maybe I'm thinking of a
different monad transformer library...

I think keeping fundeps as the default is probably best. It maintains
instance definitions in old code across the version boundary, and it
also maintains support with Hugs for folks who care about that.

If, in the future, the community decides that fundeps are bad and TFs
are good then we can make that switch in mtl-3. Even though a lot of
folks are leaning that way now, I don't think there's a clear consensus
yet to deprecate fundeps. Conflating the fundep-vs-TF debate in with the
mtl-vs-transformers debate is just going to drag things out longer IMO.

--
Live well,
~wren
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: GHC 6.12 + zlib + Mac OS 10.6

2009-11-29T23:25:55Z

This was reproduced on rc2, too. I installed ghc-6.12 rc2 by the installer.

As the ticket I mentioned[1] says, The problem is the flags to build
32-bit binaries is not passed to the hsc2hs executable when the hsc2hs
wrapper get any --cc parameter. Cabal passes --cc parameter to the
wrapper to tell where gcc is. So when building a package with Cabal,
hsc2hs goes wrong.

[1]: http://hackage.haskell.org/trac/ghc/ticket/3681

--nwn

On Mon, Nov 30, 2009 at 1:49 PM, Antoine Latter <aslatter@...> wrote:

> On Sun, Nov 29, 2009 at 9:08 PM, Manuel M T Chakravarty
> <chak@...> wrote:
>>
>> Which version of 6.12 are you running? These options or manually patching the hsc2hs wrapper should not be necessary with 6.12 anymore. (They are only a temporary workaround to use the old 6.10 release on Snow Leopard.)
>>
>> Manuel
>
> I built it within the past few days, I'm not sure why the version
> number says 1120.
>
> $ ghc --version
> The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091120
>
> Installed from darcs via "configre --prefix=${HOME}/usr && make &&
> make install" and such.
>
> Could an unpatched hsc2hs wrapper have been left around by my old GHC
> 6.10 installation?
>
> Antoine
>

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: GHC 6.12 + zlib + Mac OS 10.6

2009-11-29T20:49:17Z

On Sun, Nov 29, 2009 at 9:08 PM, Manuel M T Chakravarty
<chak@...> wrote:
>
> Which version of 6.12 are you running? These options or manually patching the hsc2hs wrapper should not be necessary with 6.12 anymore. (They are only a temporary workaround to use the old 6.10 release on Snow Leopard.)
>
> Manuel

I built it within the past few days, I'm not sure why the version
number says 1120.

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.0.20091120

Installed from darcs via "configre --prefix=${HOME}/usr && make &&
make install" and such.

Could an unpatched hsc2hs wrapper have been left around by my old GHC
6.10 installation?

Antoine
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: GHC 6.12 + zlib + Mac OS 10.6

2009-11-29T19:08:42Z

Antoine Latter:

> On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto <nonowarn@...> wrote:
>> I think you installed zlib without proper flags to link with 32-bit
>> libraries. configuring with ./Setup configure
>> --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks.
>>
>> See also http://hackage.haskell.org/trac/ghc/ticket/3681.
>>
>> HTH
>> -~nwn
>
> The following worked like a charm:
>
> cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32'

Which version of 6.12 are you running? These options or manually patching the hsc2hs wrapper should not be necessary with 6.12 anymore. (They are only a temporary workaround to use the old 6.10 release on Snow Leopard.)

Manuel_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-29T16:29:47Z

Overall, it sounds good. I would suggest that perhaps maintaining the fundep version as the default exported by mtl-2 might be nicer for backwards and simplicity reasons.

A lot of code could quite reasonably work with an mtl constraint that spans both versions if mtl-2 was the fundep version as long as it doesn't provide instances for the base monads, otherwise the dependency section of their cabal file would get complicated, having to switch packages at the 2.0 mark.

That way existing code would continue to work across the version bump if it didn't care about the type synonym issue for State, Reader, etc.

The question then becomes how to shuffle things around namespace wise?

As a straw man proposal to get things started:

transformers:

Control.Monad.Foo.Transformer - for the actual data type for FooT

mtl 2:

Control.Monad.Foo.Class - exports just the fundep-based typeclass and no instances, like now.

Control.Monad.Foo - exports the instances for the fundep based version and re-exports the Transformer and Class module contents.

Then the type-family package can provide:

mtl-tf:

Control.Monad.Foo.Family.Class - exports just the type-family based typeclass

Control.Monad.Foo.Family - exports the instances of the typefamily base version and re-exports the Transformer and Family.Class modules

This will safely let most libraries just use a constraint on mtl >= 1.2 && <= 2.1 in which case their code works across both versions, and if someone wants to use mtl-tf for clarity in their code, it will introduce no complications regardless of what libraries they import as long as those libraries can support both versions.

The final issue is whether or not it is a good idea to eliminate the simpler non-transformer versions of the monads.

Without them, libraries that provide instances for the various monads cannot provide instances for State and StateT in a way that lets them work compatibly with both versions.

So, an issue that I would like to talk about separately is if we _should_ be dropping the basic State, Reader, Writer, etc. constructors. They have definite pedagogical value, and have easier to understand behavior for introductory purposes. If we kept those then ALL code that worked with mtl 1.2 would be compatible with mtl 2, which strikes me as a desirable property. This has the benefit that it is easier to write libraries that export instances. I think we would be remiss in not at least considering the issue. On the other hand, I don't know how many libraries provide instances for the monads in the MTL. I have a few in my monoids library, but I'd be willing to go either way.

-Edward Kmett

On Sun, Nov 29, 2009 at 2:48 PM, Duncan Coutts <duncan.coutts@...> wrote:

On Sun, 2009-11-29 at 21:08 +0200, Michael Snoyman wrote:

>> Ok, how about this:
>>
>> transformers H98 bits, registered hidden by default
>> mtl 2 re-exports transformers, adds type function stuff
>> mtl-fd alternative that uses FDs, hidden by default
>>

> Are you saying that mtl-2 would be the equivalent of transformers +
> monads-tf? That might not be a good call; monads-fd is probably more
> popular than monads-tf.

Yes mtl-2 would be transformers + monads-${the-right-one}

Though more precisely, it'd re-export transformers and contain
monads-${the-right-one}.

I'm not really saying whether it should be the tf or fd version. I've
not been taking part in that discussion.

But other people have been discussing it and whichever one it is that
they agree is the right default, that one should be labelled as mtl
version 2.

Also, I should say that it would be wrong to push the choice of FDs/TFs
onto everyone. We should just pick one. Some people know the difference
and can select an alternative. Everyone else just wants to use the same
one as everyone else is using.

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: #562: cabal-install update fails going through a HTTP proxy

2009-11-29T13:30:14Z

Sigbjorn Finne <sigbjorn.finne@...> wrote:
>
> Despite repeated attempts from this end, I am unable to reproduce
> this via local proxies.
>
> Hence chasing down whatever problem is biting you (and others) is
> tricky without a repro case.

I'll try this change tomorrow:

-----BEGIN DIFF-----
diff --git a/Network/TCP.hs b/Network/TCP.hs
index 7d3dbe7..04b8e2a 100644
--- a/Network/TCP.hs
+++ b/Network/TCP.hs
@@ -34,7 +34,7 @@ module Network.TCP

import Network.BSD (getHostByName, hostAddresses)
import Network.Socket
- ( Socket, SockAddr(SockAddrInet), SocketOption(KeepAlive)
+ ( Socket, SockAddr(SockAddrInet), SocketOption(KeepAlive, Linger)
, SocketType(Stream), inet_addr, connect
, shutdown, ShutdownCmd(..)
, sClose, setSocketOption, getPeerName
@@ -189,6 +189,7 @@ openTCPConnection_ :: BufferType ty => String ->
Int -> Bool -
openTCPConnection_ uri port stashInput = do
s <- socket AF_INET Stream 6
setSocketOption s KeepAlive 1
+ setSocketOption s Linger 5
hostA <- getHostAddr uri
let a = SockAddrInet (toEnum port) hostA
catchIO (connect s a) (\e -> sClose s >> ioError e)
-----END DIFF-----

| If there is still data waiting to be transmitted over the
| connection, normally `close' tries to complete this transmission.
| You can control this behavior using the `SO_LINGER' socket option to
| specify a timeout period; see *note _Socket Options_.
[http://www.gnu.org/s/libc/manual/html_node/Closing-a-Socket.html]

--
vvv
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-29T11:48:56Z

On Sun, 2009-11-29 at 21:08 +0200, Michael Snoyman wrote:

>> Ok, how about this:
>>
>> transformers H98 bits, registered hidden by default
>> mtl 2 re-exports transformers, adds type function stuff
>> mtl-fd alternative that uses FDs, hidden by default
>>

> Are you saying that mtl-2 would be the equivalent of transformers +
> monads-tf? That might not be a good call; monads-fd is probably more
> popular than monads-tf.

Yes mtl-2 would be transformers + monads-${the-right-one}

Though more precisely, it'd re-export transformers and contain
monads-${the-right-one}.

I'm not really saying whether it should be the tf or fd version. I've
not been taking part in that discussion.

But other people have been discussing it and whichever one it is that
they agree is the right default, that one should be labelled as mtl
version 2.

Also, I should say that it would be wrong to push the choice of FDs/TFs
onto everyone. We should just pick one. Some people know the difference
and can select an alternative. Everyone else just wants to use the same
one as everyone else is using.

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-29T11:40:10Z

On Sun, Nov 29, 2009 at 9:37 PM, Alexander Dunlap <alexander.dunlap@...> wrote:

On Sun, Nov 29, 2009 at 11:08 AM, Michael Snoyman <michael@...> wrote:
>
>
> On Sun, Nov 29, 2009 at 9:02 PM, Duncan Coutts
> <duncan.coutts@...> wrote:
>>
>> On Sun, 2009-11-29 at 13:35 +0000, Ross Paterson wrote:
>> > On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote:
>> > > On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote:
>> > > > On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote:
>> > > > > Could someone remind me why it's better for use to ask everyone to
>> > > > > switch to monads-fd / transformers rather than to mtl-2? Does that
>> > > > > make
>> > > > > the transition easier?
>> > > >
>> > > > The problem is that transformers and mtl use the same module names,
>> > > > such as Control.Monad.Identity. Unless one of these packages is
>> > > > hidden,
>> > > > people using ghci or ghc --make will have problems.
>> > >
>> > > Right, so having transformers + mtl is bad, but why do we want to end
>> > > up
>> > > with a situation where we have both? If you've all agreed what should
>> > > go
>> > > into the new monad package, can't we call that mtl-2 ? Why would we
>> > > want
>> > > to define things in one package and re-export them in another?
>> >
>> > Because there is not one new monad package, but two. The idea is to
>> > split the mtl package to decouple monad transformers from functional
>> > dependencies. The transformers part can then be used in Haskell 98
>> > code,
>> > or with type classes using type functions. Exposed modules from mtl are
>> > split between the resulting two packages, so neither is a replacement
>> > for
>> > mtl-1. As I said above, having both would be a transitional
>> > arrangement,
>> > on the way to replacing mtl with the two packages split from it. mtl-2
>> > is an attempt to smooth that transition, but it would eventually go
>> > away.
>>
>> Ok, how about this:
>>
>> transformers H98 bits, registered hidden by default
>> mtl 2 re-exports transformers, adds type function stuff
>> mtl-fd alternative that uses FDs, hidden by default
>>
>> I'm not sure what you agreed, if you chose the FD one as default then
>> use mtl-tf as the alternative. Whichever you have chosen as the
>> recommended stuff should be called mtl 2, because that is the easiest to
>> explain to everyone.
>>
>> So all the packages now using mtl-1, move up to mtl 2. Then for packages
>> that only want transformers, they depend on transformers. Similarly for
>> the mtl-fd alternative (and whether that re-exports transformers or
>> whether such packages should depend on transformers + mtl-fd is up to
>> you).
>>
>> Users of ghci / ghc --make will end up using mtl 2 by default and there
>> will be no module name clashes because transformers and mtl-fd will by
>> hidden by default (Cabal-1.6+ can do that). The hiding does not affect
>> cabal packages of course.
>>
>> Duncan
>>
> Are you saying that mtl-2 would be the equivalent of transformers +
> monads-tf? That might not be a good call; monads-fd is probably more popular
> than monads-tf.
>
> Michael
>

What is the plan for letting the two co-exist? Is everyone going to
have to write instances that work with both monads-{tf,fd} and then
export duplicate functions that have monad classes in their
signatures? It seems like if we can't have a nice way to use both, we
ought to just pick one and deprecate the other.

Alex

Sounds reasonable to me. Shall we take a vote on which one it'll be? If FunDeps is really being deprecated, it would appear that tf is the way forward...

Michael

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-29T11:37:45Z

On Sun, Nov 29, 2009 at 11:08 AM, Michael Snoyman <michael@...> wrote:

>
>
> On Sun, Nov 29, 2009 at 9:02 PM, Duncan Coutts
> <duncan.coutts@...> wrote:
>>
>> On Sun, 2009-11-29 at 13:35 +0000, Ross Paterson wrote:
>> > On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote:
>> > > On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote:
>> > > > On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote:
>> > > > > Could someone remind me why it's better for use to ask everyone to
>> > > > > switch to monads-fd / transformers rather than to mtl-2? Does that
>> > > > > make
>> > > > > the transition easier?
>> > > >
>> > > > The problem is that transformers and mtl use the same module names,
>> > > > such as Control.Monad.Identity. Unless one of these packages is
>> > > > hidden,
>> > > > people using ghci or ghc --make will have problems.
>> > >
>> > > Right, so having transformers + mtl is bad, but why do we want to end
>> > > up
>> > > with a situation where we have both? If you've all agreed what should
>> > > go
>> > > into the new monad package, can't we call that mtl-2 ? Why would we
>> > > want
>> > > to define things in one package and re-export them in another?
>> >
>> > Because there is not one new monad package, but two. The idea is to
>> > split the mtl package to decouple monad transformers from functional
>> > dependencies. The transformers part can then be used in Haskell 98
>> > code,
>> > or with type classes using type functions. Exposed modules from mtl are
>> > split between the resulting two packages, so neither is a replacement
>> > for
>> > mtl-1. As I said above, having both would be a transitional
>> > arrangement,
>> > on the way to replacing mtl with the two packages split from it. mtl-2
>> > is an attempt to smooth that transition, but it would eventually go
>> > away.
>>
>> Ok, how about this:
>>
>> transformers H98 bits, registered hidden by default
>> mtl 2 re-exports transformers, adds type function stuff
>> mtl-fd alternative that uses FDs, hidden by default
>>
>> I'm not sure what you agreed, if you chose the FD one as default then
>> use mtl-tf as the alternative. Whichever you have chosen as the
>> recommended stuff should be called mtl 2, because that is the easiest to
>> explain to everyone.
>>
>> So all the packages now using mtl-1, move up to mtl 2. Then for packages
>> that only want transformers, they depend on transformers. Similarly for
>> the mtl-fd alternative (and whether that re-exports transformers or
>> whether such packages should depend on transformers + mtl-fd is up to
>> you).
>>
>> Users of ghci / ghc --make will end up using mtl 2 by default and there
>> will be no module name clashes because transformers and mtl-fd will by
>> hidden by default (Cabal-1.6+ can do that). The hiding does not affect
>> cabal packages of course.
>>
>> Duncan
>>
> Are you saying that mtl-2 would be the equivalent of transformers +
> monads-tf? That might not be a good call; monads-fd is probably more popular
> than monads-tf.
>
> Michael
>

What is the plan for letting the two co-exist? Is everyone going to
have to write instances that work with both monads-{tf,fd} and then
export duplicate functions that have monad classes in their
signatures? It seems like if we can't have a nice way to use both, we
ought to just pick one and deprecate the other.

Alex
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-29T11:08:26Z

On Sun, Nov 29, 2009 at 9:02 PM, Duncan Coutts <duncan.coutts@...> wrote:

On Sun, 2009-11-29 at 13:35 +0000, Ross Paterson wrote:
> On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote:
> > On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote:
> > > On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote:
> > > > Could someone remind me why it's better for use to ask everyone to
> > > > switch to monads-fd / transformers rather than to mtl-2? Does that make
> > > > the transition easier?
> > >
> > > The problem is that transformers and mtl use the same module names,
> > > such as Control.Monad.Identity. Unless one of these packages is hidden,
> > > people using ghci or ghc --make will have problems.
> >
> > Right, so having transformers + mtl is bad, but why do we want to end up
> > with a situation where we have both? If you've all agreed what should go
> > into the new monad package, can't we call that mtl-2 ? Why would we want
> > to define things in one package and re-export them in another?
>
> Because there is not one new monad package, but two. The idea is to
> split the mtl package to decouple monad transformers from functional
> dependencies. The transformers part can then be used in Haskell 98 code,
> or with type classes using type functions. Exposed modules from mtl are
> split between the resulting two packages, so neither is a replacement for
> mtl-1. As I said above, having both would be a transitional arrangement,
> on the way to replacing mtl with the two packages split from it. mtl-2
> is an attempt to smooth that transition, but it would eventually go away.

Ok, how about this:

transformers H98 bits, registered hidden by default
mtl 2 re-exports transformers, adds type function stuff
mtl-fd alternative that uses FDs, hidden by default

I'm not sure what you agreed, if you chose the FD one as default then
use mtl-tf as the alternative. Whichever you have chosen as the
recommended stuff should be called mtl 2, because that is the easiest to
explain to everyone.

So all the packages now using mtl-1, move up to mtl 2. Then for packages
that only want transformers, they depend on transformers. Similarly for
the mtl-fd alternative (and whether that re-exports transformers or
whether such packages should depend on transformers + mtl-fd is up to
you).

Users of ghci / ghc --make will end up using mtl 2 by default and there
will be no module name clashes because transformers and mtl-fd will by
hidden by default (Cabal-1.6+ can do that). The hiding does not affect
cabal packages of course.

Duncan

Are you saying that mtl-2 would be the equivalent of transformers + monads-tf? That might not be a good call; monads-fd is probably more popular than monads-tf.

Michael

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-29T11:02:22Z

On Sun, 2009-11-29 at 13:35 +0000, Ross Paterson wrote:

> On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote:
> > On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote:
> > > On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote:
> > > > Could someone remind me why it's better for use to ask everyone to
> > > > switch to monads-fd / transformers rather than to mtl-2? Does that make
> > > > the transition easier?
> > >
> > > The problem is that transformers and mtl use the same module names,
> > > such as Control.Monad.Identity. Unless one of these packages is hidden,
> > > people using ghci or ghc --make will have problems.
> >
> > Right, so having transformers + mtl is bad, but why do we want to end up
> > with a situation where we have both? If you've all agreed what should go
> > into the new monad package, can't we call that mtl-2 ? Why would we want
> > to define things in one package and re-export them in another?
>
> Because there is not one new monad package, but two. The idea is to
> split the mtl package to decouple monad transformers from functional
> dependencies. The transformers part can then be used in Haskell 98 code,
> or with type classes using type functions. Exposed modules from mtl are
> split between the resulting two packages, so neither is a replacement for
> mtl-1. As I said above, having both would be a transitional arrangement,
> on the way to replacing mtl with the two packages split from it. mtl-2
> is an attempt to smooth that transition, but it would eventually go away.

Ok, how about this:

transformers H98 bits, registered hidden by default
mtl 2 re-exports transformers, adds type function stuff
mtl-fd alternative that uses FDs, hidden by default

I'm not sure what you agreed, if you chose the FD one as default then
use mtl-tf as the alternative. Whichever you have chosen as the
recommended stuff should be called mtl 2, because that is the easiest to
explain to everyone.

So all the packages now using mtl-1, move up to mtl 2. Then for packages
that only want transformers, they depend on transformers. Similarly for
the mtl-fd alternative (and whether that re-exports transformers or
whether such packages should depend on transformers + mtl-fd is up to
you).

Users of ghci / ghc --make will end up using mtl 2 by default and there
will be no module name clashes because transformers and mtl-fd will by
hidden by default (Cabal-1.6+ can do that). The hiding does not affect
cabal packages of course.

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-29T09:08:18Z

Duncan Coutts <duncan.coutts@...> writes:

> Right, so having transformers + mtl is bad, but why do we want to end
> up with a situation where we have both? If you've all agreed what
> should go into the new monad package, can't we call that mtl-2 ? Why
> would we want to define things in one package and re-export them in
> another?

+1.

G
--
Gregory Collins <greg@...>
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-29T05:35:30Z

On Sun, Nov 29, 2009 at 01:03:06PM +0000, Duncan Coutts wrote:

> On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote:
> > On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote:
> > > Could someone remind me why it's better for use to ask everyone to
> > > switch to monads-fd / transformers rather than to mtl-2? Does that make
> > > the transition easier?
> >
> > The problem is that transformers and mtl use the same module names,
> > such as Control.Monad.Identity. Unless one of these packages is hidden,
> > people using ghci or ghc --make will have problems.
>
> Right, so having transformers + mtl is bad, but why do we want to end up
> with a situation where we have both? If you've all agreed what should go
> into the new monad package, can't we call that mtl-2 ? Why would we want
> to define things in one package and re-export them in another?

Because there is not one new monad package, but two. The idea is to
split the mtl package to decouple monad transformers from functional
dependencies. The transformers part can then be used in Haskell 98 code,
or with type classes using type functions. Exposed modules from mtl are
split between the resulting two packages, so neither is a replacement for
mtl-1. As I said above, having both would be a transitional arrangement,
on the way to replacing mtl with the two packages split from it. mtl-2
is an attempt to smooth that transition, but it would eventually go away.
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-29T05:03:06Z

On Sat, 2009-11-28 at 16:56 +0000, Ross Paterson wrote:
> On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote:
> > Could someone remind me why it's better for use to ask everyone to
> > switch to monads-fd / transformers rather than to mtl-2? Does that make
> > the transition easier?
>
> The problem is that transformers and mtl use the same module names,
> such as Control.Monad.Identity. Unless one of these packages is hidden,
> people using ghci or ghc --make will have problems.

Right, so having transformers + mtl is bad, but why do we want to end up
with a situation where we have both? If you've all agreed what should go
into the new monad package, can't we call that mtl-2 ? Why would we want
to define things in one package and re-export them in another?

Duncan

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: GHC 6.12 + zlib + Mac OS 10.6

2009-11-28T17:27:05Z

I had wrote last mail without verifications, so ./Setup configure
--hsc2hs-options='--cflag=-m32 --lflag=-m32' is correct.

But I'm glad to know you got working fine with zlib :)

~-nwn

On Sun, Nov 29, 2009 at 8:00 AM, Antoine Latter <aslatter@...> wrote:

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: GHC 6.12 + zlib + Mac OS 10.6

2009-11-28T15:30:04Z

Antoine Latter <aslatter@...> writes:

You can also patch your hsc2hs wrapper to read:

...
exec /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.4/hsc2hs $tflag $HSC2HS_EXTRA --cflag="-m32" --lflag="-m32" ${1+"$@"} "$Iflag"

G
--
Gregory Collins <greg@...>
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: GHC 6.12 + zlib + Mac OS 10.6

2009-11-28T15:00:57Z

On Sat, Nov 28, 2009 at 3:54 PM, Yusaku Hashimoto <nonowarn@...> wrote:
> I think you installed zlib without proper flags to link with 32-bit
> libraries. configuring with ./Setup configure
> --with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks.
>
> See also http://hackage.haskell.org/trac/ghc/ticket/3681.
>
> HTH
> -~nwn

The following worked like a charm:

cabal install --hsc2hs-options='--cc-flag=-m32 --ld-flag=-m32'

Thanks for the tip.

Antoine
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: GHC 6.12 + zlib + Mac OS 10.6

2009-11-28T13:54:42Z

I think you installed zlib without proper flags to link with 32-bit
libraries. configuring with ./Setup configure
--with-hsc2hs='--cc-flag=-m32 --ld-flag=-m32' should do the tricks.

See also http://hackage.haskell.org/trac/ghc/ticket/3681.

HTH
-~nwn

On Sun, Nov 29, 2009 at 6:01 AM, Antoine Latter <aslatter@...> wrote:

> Hello folks,
>
> Everything has been going beautifully with the latest versions of GHC
> 6.12, except that anything involving zlib dies at run-time. In ghci:
>
>> :m Codec.Compression.Zlib
>> :m +Data.ByteString.Lazy.Char8
>> :s -XOverloadedStrings
>> compress "hello"
>
> *** Exception: user error (Codec.Compression.Zlib: incompatible zlib version)
>
> I'm running OS X 10.6 on a 64-bit machine.
>
> I've heard of folks running into this with GHC 6.10 on OS X 10.6, who
> got rid of it by removing mac-ports. I tried that and it didn't change
> anything. My mac-ports install should have all been universal binaries
> anyway.
>
> I imagine I'm somehow building against a 64-bit version of the zlib
> library, but I'm not sure at what step I'm supposed to do things
> different, or what precisely I'm supposed to do different.
>
> Thanks,
> Antoine
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users@...
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-28T13:17:06Z

On Sat, 28 Nov 2009, Thomas DuBuisson wrote:

> On Sat, Nov 28, 2009 at 8:56 AM, Ross Paterson <ross@...> wrote:
>>
>> The problem is that transformers and mtl use the same module names,
>> such as Control.Monad.Identity. Unless one of these packages is hidden,
>> people using ghci or ghc --make will have problems.
>
> I've happily used LANGUAGE PackageImports to handle transformer / mtl
> conflicts. I don't see why either one must change their module names
> and there are obvious disadvantages.

This PRAGMA is only available in GHC, is it?
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-28T13:14:51Z

On Sat, 28 Nov 2009, Thomas DuBuisson wrote:

> On Sat, Nov 28, 2009 at 8:56 AM, Ross Paterson <ross@...> wrote:
>> On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote:
>>> Could someone remind me why it's better for use to ask everyone to
>>> switch to monads-fd / transformers rather than to mtl-2? Does that make
>>> the transition easier?
>>
>> The problem is that transformers and mtl use the same module names,
>> such as Control.Monad.Identity. Unless one of these packages is hidden,
>> people using ghci or ghc --make will have problems.
>
> I've happily used LANGUAGE PackageImports to handle transformer / mtl
> conflicts. I don't see why either one must change their module names
> and there are obvious disadvantages.

Is there long-term value in having both packages, if mtl ends up as just
re-exporting pieces of transformers+monads-fd? I guess it reduces the
dependencies people have to declare, but that seems marginal to me.

Ganesh
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: MTL vs Transformers. Any status update?

2009-11-28T13:11:46Z

On Sat, Nov 28, 2009 at 8:56 AM, Ross Paterson <ross@...> wrote:
> On Sat, Nov 28, 2009 at 04:40:49PM +0000, Duncan Coutts wrote:
>> Could someone remind me why it's better for use to ask everyone to
>> switch to monads-fd / transformers rather than to mtl-2? Does that make
>> the transition easier?
>
> The problem is that transformers and mtl use the same module names,
> such as Control.Monad.Identity. Unless one of these packages is hidden,
> people using ghci or ghc --make will have problems.

I've happily used LANGUAGE PackageImports to handle transformer / mtl
conflicts. I don't see why either one must change their module names
and there are obvious disadvantages.

Thomas
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

GHC 6.12 + zlib + Mac OS 10.6

2009-11-28T13:01:26Z

Hello folks,

Everything has been going beautifully with the latest versions of GHC
6.12, except that anything involving zlib dies at run-time. In ghci:

> :m Codec.Compression.Zlib
> :m +Data.ByteString.Lazy.Char8
> :s -XOverloadedStrings
> compress "hello"

*** Exception: user error (Codec.Compression.Zlib: incompatible zlib version)

I'm running OS X 10.6 on a 64-bit machine.

I've heard of folks running into this with GHC 6.10 on OS X 10.6, who
got rid of it by removing mac-ports. I tried that and it didn't change
anything. My mac-ports install should have all been universal binaries
anyway.

I imagine I'm somehow building against a 64-bit version of the zlib
library, but I'm not sure at what step I'm supposed to do things
different, or what precisely I'm supposed to do different.

Thanks,
Antoine
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries