March 2003 - Glasgow-haskell-users

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

RE: Network/Notwork?
by Simon Marlow 17 Mar '03

17 Mar '03

> - in Network.Socket: SocketOptions may include Linger, but > setSocketOptions uses packSocketOptions, which doesn't know > about Linger? That looks like a bug, thanks. > And shouldn't Linger be on by default for the > high-level Network lib? It looks that way to me, but perhaps a Network Guru could comment? > - 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? Cheers, Simon

1 0

RE: Hugs extension in GHC ?
by Simon Marlow 17 Mar '03

17 Mar '03

> Is there a way to express the following Hugs (Gofer) Haskell > extension in GHC? > > From the Hugs User's Manual, "Section 7.3.5 Restricted type synonyms" GHC doesn't support restricted type synonyms, sorry. Cheers, Simon

1 0

Network/Notwork?
by Claus Reinke 16 Mar '03

16 Mar '03

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… 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

1 1

Hugs extension in GHC ?
by Ed Komp 16 Mar '03

16 Mar '03

Is there a way to express the following Hugs (Gofer) Haskell extension in GHC? >From the Hugs User's Manual, "Section 7.3.5 Restricted type synonyms" >> Hugs supports the use of restricted type synonyms, first introduced >> in Gofer, and similar to the mechanisms for defining abstract >> datatypes that were provided in several earlier languages. The purpose >> of a restricted type synonym is to restrict the expansion of a type >> synonym to a particular set of functions. Outside of the selected >> group of functions, the synonym constructor behaves like a standard >> datatype. More precisely, a restricted type synonym definition is a >> top level declaration of the form: >> > type T a1 ... am = rhs in f1, ..., fn >> where T is a new type constructor name and rhs is a type expression >> typically involving some of the (distinct) type variables a1, ..., >> am. The major difference with a normal type synonym definition is that >> the expansion of the type synonym can only be used within the binding >> group of one of the functions f1, ..., fn (all of which must be >> defined by top-level definitions in the module containing the >> restricted type synonym definition). In the definition of any other >> value, T is treated as if it had been introduced by a definition of >> the form: >> > data T a1 ... am = ... For my intended application, this last line, the type synonym is treated as if it had been introduced with "data" is of key importance. Here are some code snippets, taken from the paper "Using catamorphisms, subtypes and monad transformers for writing modular functional interpretors" by Luc Duponcheel (Nov. 1995) further explain what I to express: >> data Sum x y = L x | R y >> >> type E x = Sum (E1 x) (E2 x) in fmapE, phiE >> >> fmapE :: (x -> y) -> (E x -> E y) >> fmapE g = (L . fmap1 g) <+> (R . fmap2 g) >> >> phiE :: E Int -> Int >> phiE = phi1 <+> phi2 >> >> data Rec1 f = In (f (Rec1 f)) >> >> type Expr = Rec1 E >> >> instance Functor E where >> fmap = fmapE Trying to compile this with GHC (after removing the "in fmapE, phiE"), generates the (expected) error: >> Type synonym `E' should have 1 argument, but has been given 0 >> In the type: Rec1 E >> While checking the RHS of a type synonym declaration `Expr' for the line: type Expr = Rec1 E and, if I replace that line with: type Expr x = Rec1 E x I get the following error message: >> Couldn't match `*' against `k -> k1' >> Expected kind: * >> Inferred kind: k -> k1 >> When checking kinds in `Rec1 E x' >> In the type synonym declaration for `Expr' and, more problems are anticipated for: >> instance Functor E where >> fmap = fmapE Thanks in advance for all help, Ed Komp komp(a)ittc.ku.edu

1 0

RE: Effect of large binaries on garbage collection
by Simon Peyton-Jones 15 Mar '03

15 Mar '03

| In the current CVS GHC, undoubtedly the right thing to use is | Foreign.mallocForeignPtr. Internally these are implemented as | MutableByteArray#, so you get fast allocation and GC, but from the | programmer's point of view it's a normal ForeignPtr. I wonder how it is for a random FFI user to discover this. Does some advice belong in the FFI spec, or in GHC's FFI chapter? Simon

3 2