- Glasgow-haskell-users

Exception handler missimg in GHC.Handle.hs
by MR K P SCHUPKE 11 Apr '03

11 Apr '03

If someone has aknowledged this problem, please reply, I'm getting the feeling nobody want's to do anything about it... Brief description: if the remote side of a socket closes the connection, any write will cause a sigPIPE signal, if a signal handler ignoring the signal is in place this results in an IO exception in the write call (or flush). At this point the local end of the socket still exists and needs to be closed by a call to c_close, howerver, hClose and the finalizer both try to flush the write side causeing a second exception, resulting in the handle never getting closed, and leaking... Here is a potential solution: (maybe better to use catchJust ioErrors) handleFinalizer :: MVar Handle__ -> IO () handleFinalizer m = do h_ <- takeMVar m catch (flushWriteBufferOnly h_) (\e -> return()) -- catch exception if remote side closed let fd = fromIntegral (haFD h_) unlockFile fd when (fd /= -1) #ifdef mingw32_TARGET_OS (closeFd (haIsStream h_) fd >> return ()) #else (c_close fd >> return ()) #endif return () Regards, Keean Schupke.

1 0

RE: Text.Regex bug in ghc 5.04.2
by Simon Marlow 11 Apr '03

11 Apr '03

> After importing Text.Regex and Data.Maybe, here's some output > from ghci: > > *ProtoRegexp> fromJust $ matchRegex (mkRegex "foo") "barfoobaz" > [] > *ProtoRegexp> fromJust $ matchRegexAll (mkRegex "foo") "barfoobaz" > ("ba","foo","baz",[]) > > I'm relatively sure those are both wrong. I think the first should be > "foo" > and the second should be > ("bar","foo","baz",[]) > > I haven't yet tried Text.Regex.Posix to see if the problem is > just the wrapper. The first example is correct (it returns the parenthesised sub-expressions in the match). The second is indeed incorrect, there's an off-by-one in calculating the first component of the tuple, which I've now fixed. Thanks for the report. Cheers, Simon

1 0

What have you got planned for sunday?.. 5150rvve9-289zyBc9061-20
by Jenna Solly 10 Apr '03

10 Apr '03

1 0

Text.Regex bug in ghc 5.04.2
by Shae Matijs Erisson 09 Apr '03

09 Apr '03

After importing Text.Regex and Data.Maybe, here's some output from ghci: *ProtoRegexp> fromJust $ matchRegex (mkRegex "foo") "barfoobaz" [] *ProtoRegexp> fromJust $ matchRegexAll (mkRegex "foo") "barfoobaz" ("ba","foo","baz",[]) I'm relatively sure those are both wrong. I think the first should be "foo" and the second should be ("bar","foo","baz",[]) I haven't yet tried Text.Regex.Posix to see if the problem is just the wrapper. -- Shae Matijs Erisson - 2 days older than RFC0226 #haskell on irc.freenode.net - We Put the Funk in Funktion 10 PRINT "HELLO" 20 GOTO 10 ; putStr $ fix ("HELLO\n"++)

1 0

bug in Handle.hs!!!
by Keean Schupke 09 Apr '03

09 Apr '03

seeing as nobody replied to this i'll send it again ... I think its important these problems get fixed! Here are the symptoms, each connection to a server sparks a thread. The thread does the processing, which may be interrupted by an asynchnonous exception (sigPIPE) at any point. Sometimes partially closed sockets are left open, even though the sparked thread has a finally clause closeing the handle for the socket. This seems to happen because a write to a socket that has been closed at the write end causes sigPIPE. If this signal is ignored an asynchronous exception is delivered to the thread, which causes a thread level exception handler to try and close the socket. The problem seems to be the finalizer itself tries to flush the write side, which results in an uncought exception meaning c_close is never called, hence the hanging socket. Here is a possible fix: handleFinalizer :: MVar Handle__ -> IO () handleFinalizer m = do h_ <- takeMVar m catch (flushWriteBufferOnly h_) (\e -> return()) -- catch exception if remote side closed let fd = fromIntegral (haFD h_) unlockFile fd when (fd /= -1) #ifdef mingw32_TARGET_OS (closeFd (haIsStream h_) fd >> return ()) #else (c_close fd >> return ()) #endif return () I think hClose should be modified also, does this sound reasonable? Regards, Keean Schupke

1 0

RE: Type Inference Infelicity
by Simon Peyton-Jones 08 Apr '03

08 Apr '03

Interesting example, right on the borderline. I've jiggled the type inference for applications a bit so that it works (HEAD only of course). Thanks for the test case. Simon | -----Original Message----- | From: Ashley Yakeley [mailto:ashley@semantic.org] | Sent: 19 March 2003 09:43 | To: glasgow-haskell-users(a)haskell.org | | 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 | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

RE: ghc puzzling behaviour
by Simon Peyton-Jones 08 Apr '03

08 Apr '03

Thank you. A palpable bug. Fixed. Simon | -----Original Message----- | From: glasgow-haskell-users-admin(a)haskell.org [mailto:glasgow-haskell-users- | admin(a)haskell.org] On Behalf Of Ketil Z. Malde | Sent: 07 April 2003 13:33 | To: glasgow-haskell-users(a)haskell.org | | | Hi, | | When compiling with -funbox-strict-fields, the supplied code doesn't | seem to compile, requiring 'Ord Foo' to derive 'Ord Zot', even if 'Ord | Bar' is explicitly declared. Without the flag, it works as expected. | | Is this intentional? I'll get by by dropping -funbox, or explicitly | declaring the instance, so it's no big deal -- just slightly | surprising. | | --T1.hs-- | | > module T1 where | > | > data Foo = Foo Int String | > data Bar = Bar Int Foo | > | > instance Ord Bar where | > compare (Bar i _) (Bar j _) = compare i j | > | > instance Eq Bar where | > (Bar i _) == (Bar j _) = i == j | | --T2.hs-- | | > module Main where | > | > import T1 | > | > data Zot = Zot !Bar !String deriving (Ord,Eq) | > | > main = putStrLn "Success" | | -kzm | -- | If I haven't seen further, it is by standing in the footprints of giants | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

ghc puzzling behaviour
by ketil＠ii.uib.no 07 Apr '03

07 Apr '03

Hi, When compiling with -funbox-strict-fields, the supplied code doesn't seem to compile, requiring 'Ord Foo' to derive 'Ord Zot', even if 'Ord Bar' is explicitly declared. Without the flag, it works as expected. Is this intentional? I'll get by by dropping -funbox, or explicitly declaring the instance, so it's no big deal -- just slightly surprising. --T1.hs-- > module T1 where > > data Foo = Foo Int String > data Bar = Bar Int Foo > > instance Ord Bar where > compare (Bar i _) (Bar j _) = compare i j > > instance Eq Bar where > (Bar i _) == (Bar j _) = i == j --T2.hs-- > module Main where > > import T1 > > data Zot = Zot !Bar !String deriving (Ord,Eq) > > main = putStrLn "Success" -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

deprecated non-standard syntax
by Andre W B Furtado 06 Apr '03

06 Apr '03

The following line: foreign import shutdownHaskellAndExit :: Int -> IO () causes a compiler warning: foreign declaration uses deprecated non-standard syntax Which is the correct way to use a foreign declaration? Thanks, -- Andre

4 4

Waiting to hear from you.
by Dr.Williams Okun. 06 Apr '03

06 Apr '03

Dear Sir, REQUEST ASSISTANCE/PARTNERSHIP . I am a member of a contract award and review committee .A contract already executed by a foreign firm in Africa in 1999 was over invoiced by us to the tune of $8,600,000.00 (Eight million six hundred thousand United states dollars). In the light of the above, I ask for your assistance in the transfer of this excess floating fund in a suspence account into a foreign account you may wish to provide, for it was a category "A" contract, (strictly reserved for foreign contractors) this informed my request, and also that I am forbidden by my government to run any foreign account. After the sucessful transfer, 20% of the total sum will go to you for your assistance. 5% of the total sum will be set aside to compensate for any incidental expenses incured by both parties. More details will be given in the course of correspondence. Your confidentiality is highly required since I am still in active service . Thank you for your anticipated co-operation. Regards, Dr.Williams Okun. TELEPHONE:234-1-776-3350. FAX:234-1-759-7912. You can contact me on my home email on. drokunwill(a)hknetmail.com

1 0