bug during documentation generation?
Shouldn't the attached patch be applied to the file package.mk in the GHC 6.2 build system? Explanation: I think that for the generation of the documentation the new ghc should be used, not the old one. I got the following error while compiling GHC 6.2 with OpenGL support, using the binary distribution of 6.2 for Linux, which seems to not support OpenGL. ==fptools== make html - --no-print-directory -r; in /var/tmp/portage/ghc-6.2/work/ghc-6.2/libraries/GLUT /opt/ghc/bin/ghc -H16m -O -Wall -fffi -Iinclude '-#include HsGLUT.h' -cpp -DCA LLCONV=ccall -package-name GLUT -O -Rghc-timing -package base -package OpenGL -split-objs-D__HADDOCK__ -E -cpp Graphics/UI/GLUT.hs -o Graphics/UI/GLUT.hs. tmp sed -e 's/^#.*//' Graphics/UI/GLUT.hs.tmp Graphics/UI/GLUT.raw-hs ghc-6.2: unknown package name: OpenGL ghc: 2877832 bytes, 2 GCs, 51232/51232 avg/max bytes residency (1 samples), 5M in use, 0.00 INIT (0.00 elapsed), 0.00 MUT (0.02 elapsed), 0.01 GC (0.01 elapse d) :ghc make[2]: *** [Graphics/UI/GLUT.raw-hs] Error 1 make[1]: *** [html] Error 1 make: *** [html] Error 1 Best, Andres diff -Naur ghc-6.2.orig/mk/package.mk ghc-6.2/mk/package.mk --- ghc-6.2.orig/mk/package.mk 2003-12-17 16:26:11.0 +0100 +++ ghc-6.2/mk/package.mk 2003-12-17 16:27:21.0 +0100 @@ -237,10 +237,10 @@ CLEAN_FILES += $(PACKAGE).haddock %.raw-hs : %.lhs - $(GHC) $(HC_OPTS) -D__HADDOCK__ -E -cpp $ -o $.tmp sed -e 's/^#.*//' $.tmp $@ + $(HC) $(HC_OPTS) -D__HADDOCK__ -E -cpp $ -o $.tmp sed -e 's/^#.*//' $.tmp $@ %.raw-hs : %.hs - $(GHC) $(HC_OPTS) -D__HADDOCK__ -E -cpp $ -o $.tmp sed -e 's/^#.*//' $.tmp $@ + $(HC) $(HC_OPTS) -D__HADDOCK__ -E -cpp $ -o $.tmp sed -e 's/^#.*//' $.tmp $@ install-docs :: $(HTML_DOC) @$(INSTALL_DIR) $(datadir)/html/libraries/$(PACKAGE) ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
hGetBuf (or something related) broken for 6.2 with sockets
I have just installed ghc6.2 on Linux. (I had to compile it from source because the binaries insist on a glibc version we don't have.) The attached module contains two functions (serverMain) and (clientMain). clientMain opens a connection (to localhost) and sends some data along it, then executes hFlush. serverMain receives this data. They should display identical data. This should be run by (1) compiling the code using ghc Server.hs -c (2) starting up ghci in this directory, twice, in separate terminal windows. (3) in both ghci's doing :module Server (4) in one ghci doing serverMain (5) in the other ghci doing clientMain What happens is (a) the serverMain ghci displays Iterating several times. This is because hGetBuf appears to be terminating prematurely when there is still data to come on the socket. This is a pain (especially as I took several hours finding this was why my program didn't work), but at least it can be worked around, and the code in the module does this. (b) The server module only gets part of the data. In fact for me it comes to a stop with [239][240][241][242][243Iterating despite there being more data to come. (And despite the fact that the client has done hFlush). I don't know any way of working around (b), so I suspect that means ghc6.2 is unusable for us. What a pity no development snapshot was made for 6.2 shortly before its release, as it might have been possible for me to discover this bug in time for it to be fixed in 6.2.(I did try to test the 6.3 development snapshot but was grounded by the instances bug I've reported elsewhere.) module Server where import Char import IO import Random import Monad import Network import GHC.IO(hPutBuf,hGetBuf) import Foreign.C.Types import Foreign.ForeignPtr import Foreign.Marshal.Array import Foreign.Marshal.Alloc import Foreign.Ptr maxLen = (2000 :: Int) port = PortNumber 11394 host = localhost writeInt :: Handle - Int - IO () writeInt handle i = hPutStrLn handle (show i) readInt :: Handle - IO Int readInt handle = do l - hGetLine handle return (read l) runClient :: Ptr CChar - Handle - IO () runClient ptr handle = do mapM_ (\ _ - writeOut ptr maxLen handle mapM_ (\ toWrite - writeOut ptr toWrite handle ) [1..255] ) [1..4] hFlush handle writeOut :: Ptr CChar - Int - Handle - IO () writeOut ptr toWrite handle = do putStr ([++show toWrite) hFlush stdout writeInt handle toWrite hPutBuf handle ptr toWrite putStr (]) hFlush stdout getChars :: Handle - Ptr CChar - Int - IO () getChars handle ptr 0 = return () getChars handle ptr toRead = do read - hGetBuf handle ptr toRead if (read == 0) then error (Unexpected EOF) else return () if read toRead then putStrLn Iterating hFlush stdout getChars handle (plusPtr ptr read) (toRead - read) else return () readIn :: Ptr CChar - Handle - IO () readIn ptr handle = do toRead - readInt handle putStr ([++show toRead) hFlush stdout getChars handle ptr toRead putStr ] hFlush stdout runServer :: Ptr CChar - Handle - IO () runServer ptr handle = do readIn ptr handle runServer ptr handle clientMain = do ptr - mallocBytes maxLen handle - connectTo host port runClient ptr handle serverMain = do ptr - mallocBytes maxLen socket - listenOn port (handle,hostName,_) - accept socket runServer ptr handle ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: hGetBuf (or something related) broken for 6.2 with sockets
On Thu, Dec 18, 2003 at 07:44:58PM +0100, George Russell wrote: (b) The server module only gets part of the data. In fact for me it comes to a stop with [239][240][241][242][243Iterating despite there being more data to come. (And despite the fact that the client has done hFlush). I don't know any way of working around (b), so I suspect that means ghc6.2 is unusable for us. What a pity no development snapshot was made for 6.2 shortly before its release, as it might have been possible for me to discover this bug in time for it to be fixed in 6.2.(I did try to test the 6.3 development snapshot but was grounded by the instances bug I've reported elsewhere.) It seems to work when I change hGetBuf to hGetBufNonBlocking. The name is a bit misleading - the action _does_ wait for some data, but it doesn't wait for all requested bytes. Best regards, Tom -- .signature: Too many levels of symbolic links ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug during documentation generation?
Andres Loeh wrote: Shouldn't the attached patch be applied to the file package.mk in the GHC 6.2 build system? [...] Thank for the patch, I've just applied it to the CVS version. I thought I fixed this some time ago, but OTOH I have been building my GHC including the OpenGL package for ages now... :-) Cheers, S. ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
