RE: [Haskell] GHC Error question
| What Claus says. What is the real type that ghc infers? It's this: forall a b . C a b = a - a | If it's really what it claims it to be, then this is definitely a bug. | And it might not be common to you, but I have several places in my | code base where I have to leave off type signatures, because the | inferred signature is not accepted. I'd love to see those examples. Can you extract them? You could add them to http://hackage.haskell.org/trac/ghc/ticket/1050 Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network.Socket endian problem?
On 12/13/06, Sigbjorn Finne [EMAIL PROTECTED] wrote: as you've time-consumingly discovered, Network.Socket.HostAddress is represented in network byte order (something that's not well documented, and a potential trap.) You may want to consider using Network.Socket.inet_addr as a constructor. Thanks to everyone for their help and suggestions. I agree, however, with Tomasz that the address should be in host byte order to the application. At the very least, the port value and the address should use the same byte ordering. For now, I'll use inet_addr as a constructor. Thanks again. -- Rich AIM : rnezzy ICQ : 174908475 ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network.Socket endian problem?
Tomasz Zielonka [EMAIL PROTECTED] writes: On Wed, Dec 13, 2006 at 03:54:59PM -0600, Mark Hills wrote: It does expect the address to be in network byte order instead of host byte order, which is usually done using htons and htonl. This seems to do what you want (running SUSE 10.1 on an Intel box): Who agrees with me that it would be nice if network libraries used host byte order in their interface? Or at least they could use an abstract data type, whose byte order would be unobservable. Why is this trapdoor present in the C library? -- Feri. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Network.Socket endian problem?
On Thu, Dec 14, 2006 at 05:22:43PM +0100, Ferenc Wagner wrote: Tomasz Zielonka [EMAIL PROTECTED] writes: On Wed, Dec 13, 2006 at 03:54:59PM -0600, Mark Hills wrote: It does expect the address to be in network byte order instead of host byte order, which is usually done using htons and htonl. This seems to do what you want (running SUSE 10.1 on an Intel box): Who agrees with me that it would be nice if network libraries used host byte order in their interface? Or at least they could use an abstract data type, whose byte order would be unobservable. Why is this trapdoor present in the C library? I don't know. Maybe for efficiency? Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
