Re: ANNOUNCE: GHC vesrion 5.04.3 released
I notice the release notes say a few architectures should be possible to port to, in particular AIX/POWER. How possible is that, exactly? Has anybody done it with any success? Alternatively, is there any alternative Haskell compiler (I guess that would be NHC?) that works for this architecture? And does GHC or anybody else support 64bit address spaces? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
fix missing from 5.04.3 ???
Previous 5.04 releases had an exception handler missing from connectTo that results in a socket leaking if socketToHandle fails for some reason (I cant remember the exact circumstances at the moment, but it causes a server to die - I think the leak is caused when the client closes the connection during the handshake - ie somebody presses stop on a web browser because of a slow connection after the handshake has just started) - I suggested a fix along the lines of: connectTo hostname (Service serv) = do proto - getProtocolNumber tcp port - getServicePortNumber serv he - getHostByName hostname sock - socket AF_INET Stream proto (do connect sock (SockAddrInet port (hostAddress he)) socketToHandle sock ReadWriteMode) `Control.Exception.catch` (\e - do sClose sock; throw e) This seems to be missing from 5.04.3 - this fix is important for reliability in a production server, what happened - does this cause problems in other places? Regards, Keean Schupke. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ANNOUNCE: GHC vesrion 5.04.3 released
I notice the release notes say a few architectures should be possible to port to, in particular AIX/POWER. How possible is that, exactly? Has anybody done it with any success? Alternatively, is there any alternative Haskell compiler (I guess that would be NHC?) that works for this architecture? And does GHC or anybody else support 64bit address spaces? GHC worked on Alpha recently (5.02.x), so our 64 bit support should be up to scratch. Check the porting section of the GHC building guide for information on porting: the bottom line is that there are various levels of porting, from a basic unregisterised port up to a full port with GHCi and a native code generator. http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.htm l Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: ANNOUNCE: GHC vesrion 5.04.3 released
[EMAIL PROTECTED] (Ketil Z. Malde) writes: I notice the release notes say a few architectures should be possible to port to, in particular AIX/POWER. How possible is that, exactly? Has anybody done it with any success? Alternatively, is there any alternative Haskell compiler (I guess that would be NHC?) that works for this architecture? We fixed some small configuration issues with building nhc98 on a POWER3/AIX machine in Feb 2001. I have no reason to think that anything has broken since then. The Power architecture is somewhat similar to the PowerPC architecture as used on the Mac, for which GHC does have support. And does GHC or anybody else support 64bit address spaces? nhc98 definitely does not, and it would be a significant amount of work to make it possible. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Stricness of floor etc
Hi all, Looking at ghc --show-iface .../ghc/lib/ghc-5.05/imports/base/GHC/Float.hi I see floor1 :: forall b. (GHC.Real.Integral b) = Double - b __S L properFraction2 :: forall b. (GHC.Real.Integral b) = Double - (b, Double) __S L decodeFloat2 :: Double __S U(L)m My understanding of this is that floor and properFraction of Doubles have a lazy argument while decodeFloat has a strict constructor of lazy values. It's not clear to me why the U(L) strictness isn't inherited by properFraction and then float, nor do I understand why decodeFloat is not strict in its argument when it seems to be working exclusively with unboxed values. Unfortunately decodeDouble# in PrimopWrappers.hi doesn't seem to have a strictness description so I can't see what's going on there. So I guess what I'm asking is are these strictnesses the best that can be inferred or could GHC do better? Of course a strict floor (Double to Int and Integer) is what I'm really hoping for (without having to specify it explicitly with $! in my code). Incidentally, what are 'm's in the strictness descriptions? Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
HTk for ghc5.04.3
I have created binary bundles for HTk, our Haskell interface to Tcl/Tk, for ghc5.04.3 on Linux/x86 and Windows, and put them on the download page: http://www.informatik.uni-bremen.de/htk/download/INSTALL.BINARY.html I will add FreeBSD and Solaris bundles when I can get hold of ghc5.04.3 on those platforms. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Network/Notwork?
Happy with my Winsock work-arounds for my small client-/server-test, I decided to try integrating the Network use into my target project, and got nothing but trouble. Again, things that work happily under Unix simply fail under windows. My best guess at the moment is that the socketToHandle conversion used within accept and connectTo simply doesn't work as advertised, under windows (at least, handle-based operations such as hGetLine or hClose on the handles returned by accept/connectTo results in errors, whereas avoiding the socketToHandle conversion and using Network.Socket.send and Network.Socket.recv yields some improvements..). A little more digging in mail-archives brings up the following rather discouraging thread/message: Socket library ghc 5.02.1 http://www.haskell.org/pipermail/glasgow-haskell-users/2001-November/002673.html in which Sigbjorn summarizes: FYI, in case you're planning on doing socket programming with GHC-5.02 on a Win32 platform, stay away from using the higher-level Socket module, since its IO.Handle based view of sockets is just broken. Stick with the lower-level SocketPrim interface instead. Is it just me doing something stupid, or is this problem still pertinent, for the higher-level Network module in GHC-5.04? If the latter, could this please be flagged in the GHC documentation, so that people don't have to rediscover the problem by painful debugging? (if the former, any suggestions on what I should try instead?) Is anyone else here using GHC's Network module under Windows? Claus FPI: foreign problem interface ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
