[ ghc-Bugs-559987 ] accept does reverse DNS lookup
Bugs item #559987, was opened at 2002-05-24 07:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=559987group_id=8032 Category: hslibs/net Group: 5.02 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: accept does reverse DNS lookup Initial Comment: If accept gets a connection where the connecting machine cannot be found via a reverse DNS lookup, it throws an exception. I noticed this when I tried connecting to a server made with GHC from inside a network that has real IP numbers but no reverse DNS entries, and have had reports of the same problems from inside similar networks. If I disable the server's DNS lookups, connections fail from everywhere. This is the exception: exception during accept: does not exist Action: getHostByAddr Reason: no such host entry I'm fairly sure this isn't an OS quirk, since the machine I'm testing on runs lots of other services that don't have this problem, it seems to be a problem for GHC servers. As you can see from this snippet: aResult - try (accept s) case aResult of Right (h,_,port) - do pid - forkIO (do c1 - takeMVar cc if c1 == 0 then takeMVar l else return () putMVar cc (c1 + 1) handler state h c2 - takeMVar cc if c2 == 1 then putMVar l () else return () putMVar cc (c2-1)) return () Left e - do --DEBUG putStrLn (exception during accept: ++ show e) return () I never actually demand the connecting host name, so I would hope the lookup wouldn't happen I'm testing on a RH 7.1 x86, with the GHC 5.02. Sample code attached -- Comment By: Simon Marlow (simonmar) Date: 2002-05-28 10:07 Message: Logged In: YES user_id=48280 I think the solution to this problem is just to document the behaviour - Socket.accept does return a HostName, so it has to do a reverse lookup. There is a wider issue, namely whether the interface presented by Socket is really the Right Thing, but that debate should be had on the mailing list ([EMAIL PROTECTED]?). -- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 12:52 Message: Logged In: NO Thank you for the work-around, using SocketPrim and doing the socket - bind - accept at that level works fine. -- Comment By: Volker Stolz (volkersf) Date: 2002-05-26 07:02 Message: Logged In: YES user_id=126328 You can work around this by using SocketPrim.accept, take a look at Socket.lhs on how it is used there. Maybe the corresponding error should be caught inside Socket and the tuple be changed to 'Maybe HostEntry'? OTOH Socket (now Network) has always been rather high-level with funny things like 'recvFrom', so for practical purposes, you'd end up using SocketPrim anyway. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=559987group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-561809 ] Read for Arrays does not work
Bugs item #561809, was opened at 2002-05-28 22:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=561809group_id=8032 Category: hslibs/lang Group: 5.02 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Read for Arrays does not work Initial Comment: In hugs I can go: Array read (show (array (1,1) [(1,42)])) :: Array Int Int array (1,1) [(1,42)] whereas ghc gives me: Main read (show (array (1,1) [(1,42)])) :: Array Int Int interactive:1: No instance for (Read (Array Int Int)) arising from use of `read' at interactive:1 In an expression with a type signature: read (show (array (1, 1) [(1, 42)])) :: Array Int Int In the definition of `it': read (show (array (1, 1) [(1, 42)])) :: Array Int Int The Haskell Library Report 98 says Read should be defined for Array a b, with (Read a, Ix a, Read b) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=561809group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: trouble with Debian package ghc5
On 2002-05-28T14:50:22-0400, Norman Ramsey wrote: I _could_ make readline a hard dependency of ghc, but this is somehow not satisfactory. I'd rather like readline to be out-factored to its own package (I know, this would break other Haskell programs, but it's arguably easy-to-fix breakage...). Comments? For a newbie like me, it would be useful to have a `virtual' package ghc-util for `ghc programs that need util'. This could then require libreadline4-dev. The key is that something show up in dpkg --list ghc* Otherwise the need for libreadline4-dev is not obvious to the amateur. This dependency on libreadline4-dev seems to be a special case of a more general issue, namely how to handle packages in the GHC sense in the Debian packaging system. The way Perl module code is packaged for Debian seems to be quite sophisticated: Perl packages tend to correspond to individual Debian packages, so if a Perl program packaged for Debian uses a certain module, only that module (roughly speaking) needs to be installed, and will be automatically. Ideally, GHC packages would be handled in a similar way, but is it worth the trouble? - On one hand, since GHC does not yet support dynamic linking, programs compiled by GHC do not depend on Haskell modules or GHC packages. - On the other hand, there are relatively few GHC packages. (And Norman, welcome to Debian :) -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig You can't spell Chung-chieh without the Hun. msg04858/pgp0.pgp Description: PGP signature
Re: trouble with Debian package ghc5
This dependency on libreadline4-dev seems to be a special case of a more general issue, namely how to handle packages in the GHC sense in the Debian packaging system. The way Perl module code is packaged for Debian seems to be quite sophisticated: Perl packages tend to correspond to individual Debian packages, so if a Perl program packaged for Debian uses a certain module, only that module (roughly speaking) needs to be installed, and will be automatically. Ideally, GHC packages would be handled in a similar way, but is it worth the trouble? My personal inclination would be to do as Perl does: have many Debian packages with just one or two GHC packages each plus one or more dummy packages corresponding to top level directories in the hslibs tree. One potential problem with this is that GHC packages have unusually strong connections with each other. The problem is that GHC does a lot of cross-module inlining so if GHC package A imports GHC package B then the compiled form of A (i.e., the Debian package) will depend not on B but on the particular version of B that it was compiled against (and the version of GHC used to compile A and B). Changes to B which leave the API and semantics unchanged might still break A. One could get round this in the Debian package by requiring particular version numbers in the packages (it's more usual for a Debian package to depend on ranges of version numbers such as = 3.2.1) - at the cost of making the restrictions on source distributions a bit stronger then they have to be. Note that there's really no way to avoid this problem: tomorrow some Haskell hacker could come along with a cool Haskell library that they don't want to add to the hslibs collection but which they want to release as a Debian package. They'll be faced with exactly this problem. (This problem may already exist: are there separate packages for the BSD and GPL'd parts of the hslibs tree.) -- Alastair Reid[EMAIL PROTECTED]http://www.cs.utah.edu/~reid/ ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
