- Glasgow-haskell-users

Concurrncy is not working well in Windows
by Ahn Ki-yung 20 Mar '03

20 Mar '03

{- In FreeBSD ghc-5.04.2 the simple echo server below works fine. (except for broken pipe. Installing signal handler will do good.) It broadcasts "Welcome!" to all users repeatedly. But in Windows XP, cygwin, ghc-5.04.3. It gets blocked on the accept routine and wakes up for a moment when new connections are requested and then get blocked soon, only printing some lines. Inserting yield in the code didn't help either. Is runtime system of cygwin version something wrong or non-blocking IO bad ? It seems almost impossible to write servers in win32. The server just STOPs without reason ! -} import IO import Monad import Network import Control.Exception (finally) import Control.Concurrent acceptConns sock = do conn@(h,host,port) <- accept sock forkIO $ catch (talk conn `finally` hClose h) print acceptConns sock talk conn@(h,_,_) = hPutStrLn h "Welcome!" >> hFlush h >> talk conn main = withSocketsDo $ do sock <- listenOn $ PortNumber 9900 acceptConns sock

1 0

RE: fun with sockets (ghc-5.04.1)
by Simon Marlow 19 Mar '03

19 Mar '03

Peter, [...] > After processing a random number of connections, the server dies with > > Fail: invalid argument > Action: accept > Reason: Invalid argument [...] I don't know what's wrong, I'm afraid. Any chance you could supply us with a working example that demonstrates the bug? Cheers, Simon

2 1

RE: How do I profile Prelude functions?
by Simon Marlow 19 Mar '03

19 Mar '03

Alistair, > I can't find advice in the GHC manual on determining how much > time your > program spends in Prelude functions. I've discovered that I > can alias a > Prelude function e.g. > > > import Data.Set > > .... > > > myMkSet = mkSet > > ... which will give me a cost-centre for mkMySet. Isn't there > an easier way to do this? Sorry for the delay in answering your question. We should really turn on -auto-all when compiling the libraries for profiling, but we don't for several reasons: (a) it affects optimisations (b) it makes profiles harder to read (c) it makes the libraries a lot larger these are all things we should fix (well, at least (a) and (b)). For (b), we really need a better tool for viewing the profiles: I have a prototype for such a tool which uses Gtk+HS, which I'll try to incorporate at some point. You can of course compile up your own libraries with -auto-all turned on. Or alternatively, just use the workaround you discovered. Cheers, Simon

1 0

Type Inference Infelicity
by Ashley Yakeley 19 Mar '03

19 Mar '03

This should compile, shouldn't it? -- ghc -c -fglasgow-exts TestInfer.hs module TestInfer where { class C t a b | t a -> b; instance C Char a Bool; data P t a = forall b. (C t a b) => MkP b; data Q t = MkQ (forall a. P t a); f' :: Q Char; f' = MkQ (MkP True :: forall a. P Char a); f :: Q Char; f = MkQ (MkP True); } GHC 5.04.2 for MacOS X complains about f, but not about f': TestInfer.hs:15: Could not deduce (C t a Bool) from the context () Probable fix: Add (C t a Bool) to the When generalising the type of an expression Or add an instance declaration for (C t a Bool) arising from use of `MkP' at TestInfer.hs:15 In the first argument of `MkQ', namely `(MkP True)' In the definition of `f': MkQ (MkP True) -- Ashley Yakeley, Seattle WA

1 0

RE: trouble linking with -O and unboxed tuple
by Simon Marlow 19 Mar '03

19 Mar '03

> With ghc 5.04.2 I'm having some trouble linking (debian linux). > > Here's the error I get: > > /home/bjpop/woo/lib/buddha-0.5/libbuddha_p.a(Partial.o): > In function `s1jZ_fast1': > Partial.o(.text+0xa44): undefined reference to > `GHCziPrim_zdwZ2H_entry' Ok, could you help us out by doing the following: compile Partial.o, using exactly the same flags you were using to demonstrate the problem, but add -ddump-simpl -dppr-debug -ddump-stg and send us the output. Also the source for the module would help too. Cheers, Simon

1 0

Re: trouble linking with -O and unboxed tuple
by Bernard James POPE 19 Mar '03

19 Mar '03

> /home/bjpop/woo/lib/buddha-0.5/libbuddha_p.a(Partial.o): > In function `s1jZ_fast1': > Partial.o(.text+0xa44): undefined reference to `GHCziPrim_zdwZ2H_entry' > > 1) libbuddha_p.a is a library built from a number of modules. Each of these > modules is compiled with: > -O -cpp -prof -fglasgow-exts -package lang -package-name buddha > > 2) The problem occurs when I try to use an unboxed tuple in one of the > modules: > > newtype Comp a = C (CompState -> (# a, CompState #)) > > If I remove the unboxing, the linking problem disappears > > 3) removing the -prof flag doesn't seem to fix anything > > 4) compiling without -O fixes the problem And some more information about the problem: 5) If I compile everything with -auto-all then the linking problem disappears. 6) If I swtich back from an unboxed tuple to a normal tuple and only recompile the module that contains that type (not every module in the program). Then I get this message: Compiling ParseLib_Buddha ( ParseLib_Buddha.hs, ParseLib_Buddha.o ) ghc-5.04.2: panic! (the `impossible' happened, GHC version 5.04.2): Missing alternative GHCziPrim.Z2H{-84-} (DataziTuple.Z2T{-74-}, [result1{-r3Au-}, newState{-r3At-}], next{-r3Av-} result1{-r3Au-} newState{-r3At-}) 7) I only export the type Comp, not its constructor. There looks to be an interaction between profiling, optimisation and the unboxed tuple. The problem may very well be with me, but I'm not sure how to find out. You may wonder why I'm compiling things with -prof. This is for my declarative debugger (buddha). I'm abusing the -prof option to get the string names of constructors in the heap representation of values. I know it is a hack, but for the moment it works well enough. Cheers, Bernie. ----- End of forwarded message from Bernard James POPE -----

1 0

RE: Stricness of floor etc
by Simon Marlow 18 Mar '03

18 Mar '03

> 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? This floor is the dictionary selector, and for various (complicated looking) reasons it is lazy in its dictionary argument. It does some dictionary selections which might be shared, before returning a function. > 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). There are specialised versions of floor for Double -> Int and Double -> Integer. You *ought* to get good code out if you call floor at one of these types. If not, please send us the example. > Incidentally, what are 'm's in the strictness descriptions? It means the function returns a manifest constructor, which can be eliminated with CPR (constructed product result optimisation). Cheers, Simon

2 1

trouble linking with -O and unboxed tuple
by Bernard James POPE 18 Mar '03

18 Mar '03

Hi all, With ghc 5.04.2 I'm having some trouble linking (debian linux). Here's the error I get: /home/bjpop/woo/lib/buddha-0.5/libbuddha_p.a(Partial.o): In function `s1jZ_fast1': Partial.o(.text+0xa44): undefined reference to `GHCziPrim_zdwZ2H_entry' This is repeated about 4 times for different locations, but the same symbol. Unfortunately I can't repeat the problem in a small program. So instead, I'll point out the things I know, in case any of them help. 1) libbuddha_p.a is a library built from a number of modules. Each of these modules is compiled with: -O -cpp -prof -fglasgow-exts -package lang -package-name buddha 2) The problem occurs when I try to use an unboxed tuple in one of the modules: newtype Comp a = C (CompState -> (# a, CompState #)) If I remove the unboxing, the linking problem disappears 3) removing the -prof flag doesn't seem to fix anything 4) compiling without -O fixes the problem I'm sorry I can't be clearer than this. I'm hoping someone understands what that symbol means, which might help to understand the problem. My suspicion is that it is something to do with inter-module optimisations and the boxed tuple, but of course I'm only guessing. Cheers, Bernie.

1 0

Re: Network/Notwork?
by C.Reinke 18 Mar '03

18 Mar '03

> > - using hFlush does *not* seem to cure the problem?? > > That's worrying, and it perhaps indicates that there's another problem > somewhere. I just tried a small test and hFlush does appear to do the > right thing, so do you think you could boil down your example to > something small that demonstrates the problem? Does it happen only on > Windows, or Un*x too? Windows only, of course!-) On Solaris, I never even noticed there might be a problem (it seems to work even without acknowledgment or hFlush..). I append my current test MyNetwork module - server and client are the main functions of the respective apps, nothing else going on, so it's very small, but for modified copies of some of the Network code (for use on windows, you'll want to change to the other definition of whatsWrong and uncomment c_getLastError). On solaris (ghc version 5.04), this seems to work as shown. On win2k (ghc version 5.04), with error reporting on, I get: $ ./server.exe & [1] 1388 tcp: 6 $ ./client.exe huhuadsfas tcp: 6 CLIENT: huhuadsfas WSAGetLastError: 10054 Fail: failed Action: hGetLine Handle: {loc=<socket: 140>,type=duplex (read-write),binary=True,buffering=line} Reason: No error File: <socket: 140> [1]+ Exit 1 ./server.exe (on win98, not even the tcp number would be correct, hence the hardcoded 6). The 10054 error from the hGetLine is the "Connection reset by peer."-message I mentioned earlier. So it seems that on windows, when the client terminates, the connection goes down and the server fails when trying to get the message. Whereas on solaris, the message gets through anyway. Uncommenting the hFlush in the client makes no difference whatsoever. Uncomment the acknowledgement in client and server instead, and it works like a charm (although it does require an asymmetry between the two processes - I have to know which one lives longer..). Over to you, Claus ------------------------------------------ module MyNetwork where import System(system,getArgs) import IO(hPutStrLn ,hGetLine ,hClose ,hFlush ,hSetBuffering ,BufferMode(..) ,IOMode(..) ,Handle) import Control.Exception as Exception import Foreign import Foreign.C import Network hiding (listenOn,connectTo) import Network.BSD(getProtocolNumber,getHostByName,hostAddress) import Network.Socket(Family(..) ,SocketType(..) ,SockAddr(..) ,SocketOption(..) ,socket ,sClose ,setSocketOption ,bindSocket ,listen ,connect ,socketToHandle ,iNADDR_ANY ,maxListenQueue ) server :: IO () server = withSocketsDo $ do s <- listenOn $ PortNumber 9000 loop s where loop s = do l <- getInput s putStrLn $ "SERVER: "++l loop s getInput s = do (h,host,portnr) <- accept s hSetBuffering h LineBuffering l <- whatsWrong $ hGetLine h -- hPutStrLn h "<ack>" -- hClose h -- not a good idea? return l client :: IO () client = withSocketsDo $ do args <- getArgs h <- connectTo "localhost" $ PortNumber 9000 hSetBuffering h LineBuffering let l = unwords args putStrLn $ "CLIENT: "++l hPutStrLn h l -- hFlush h -- hGetLine h -- wait for acknowledgement return () {- only for winsock foreign import stdcall unsafe "WSAGetLastError" c_getLastError :: IO CInt -} {- -- does this exist? foreign import ccall unsafe "getWSErrorDescr" c_getWSError :: CInt -> IO (Ptr CChar) -} whatsWrong act = act {- whatsWrong act = Exception.catch act (\e-> do errCode <- c_getLastError -- perr <- c_getWSError errCode -- err <- peekCString perr putStrLn $ "WSAGetLastError: "++show errCode throw e) -} listenOn :: PortID -- ^ Port Identifier -> IO Socket -- ^ Connected Socket listenOn (PortNumber port) = do proto <- getProtocolNumber "tcp" putStrLn $ "tcp: "++show proto let proto = 6 -- bug in ghc's getProtocolNumber.. bracketOnError (whatsWrong (socket AF_INET Stream proto)) (sClose) (\sock -> do setSocketOption sock ReuseAddr 1 bindSocket sock (SockAddrInet port iNADDR_ANY) listen sock maxListenQueue return sock ) bracketOnError :: IO a -- ^ computation to run first (\"acquire resource\") -> (a -> IO b) -- ^ computation to run last (\"release resource\") -> (a -> IO c) -- ^ computation to run in-between -> IO c -- returns the value from the in-between computation bracketOnError before after thing = block (do a <- before r <- Exception.catch (unblock (thing a)) (\e -> do { after a; throw e }) return r ) connectTo :: HostName -- Hostname -> PortID -- Port Identifier -> IO Handle -- Connected Socket connectTo hostname (PortNumber port) = do proto <- getProtocolNumber "tcp" putStrLn $ "tcp: "++show proto let proto = 6 -- bug in ghc's getProtocolNumber.. bracketOnError (whatsWrong (socket AF_INET Stream proto)) (sClose) -- only done if there's an error (\sock -> do he <- getHostByName hostname connect sock (SockAddrInet port (hostAddress he)) socketToHandle sock ReadWriteMode )

3 2

More problems compiling GHC on Mac OS X
by Kirsten Chevalier 17 Mar '03

17 Mar '03

I'm getting the following error message trying to compile the latest version of GHC on Mac OS 10.2.1, using GHC 5.04.2 installed from binaries: ../../ghc/compiler/ghc-inplace -H16m -O -Iinclude -package-name unix -O -Rghc-timing -p\ ackage base -split-objs -c System/Sendfile.hs -o System/Sendfile.o -ohi System/Sendf\ ile.hi Sendfile.hsc:94: Couldn't match `IO ()' against `Fd -> Fd -> Int -> Int -> IO ()' Expected type: IO () Inferred type: Fd -> Fd -> Int -> Int -> IO () In a right-hand side of function `sendfile': squirt In the definition of `sendfile': sendfile inFd outFd startpos count = squirt make[2]: *** [System/Sendfile.o] Error 1 make[1]: *** [all] Error 1 make: *** [build] Error 1 -- Kirsten Chevalier * krc(a)uclink.berkeley.edu * Often in error, never in doubt

5 7