Hmm, I just read jou dont want to change ever instance... In which case use the definition of hGetChar you just wrote, and change the import line to: import IO hiding (hGetChar) and it will use the local definition with no conflicts... Regards, Keean Schupke. Keean Schupke wrote:
You could try using lazy reading instead. Someting Like:
module Main(main) where
import IO import Network
main = do socket <- listenOn (PortNumber 15151) (handle,hostName,_) <- accept socket hSetBuffering handle (BlockBuffering (Just 4096)) putStr ("Accepted: "++hostName++"\n") (c:_) <- hGetContents handle putStrLn (show c)
Regards, Keean Schupke
George Russell wrote:
Simon Marlow wrote (snipped)
Hmm. I rather think that hGetChar should always return a character immediately if there is one available, regardless of the buffering mode. Looking at the source, it appears that hGetLine behaves like this, as does lazy reading with hGetContents. I can't see any reason for waiting for the buffer to be completely full before returning anything.
If you have a source tree handy, try the enclosed patch. If not, make a copy of hGetChar from the sources in libraries/base/GHC/IO.hs, apply the patch, and compile it separately (you'll need to import GHC.Handle explicitly, amongst other things).
OK, applying the patch and dropping the patched hGetChar in (as per the attached file) seems to fix the problem. Is there any way of getting the same effect without setting NoBuffering/waiting for the next ghc release/changing every call by client and server to hGetChar in the program? If not I think I'll keep NoBuffering and wait for the next ghc release ..
Thanks,
George
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users