- Haskell-Cafe - Haskell.org

Reducing # of context switches
by Joel Reymont 17 Nov '05

17 Nov '05

Folks, The latest GHC docs mention that the -C option takes a seconds value whereas prior docs mention microseconds. Which is it? Also, do I pass +RTS -Cxxx or is it just -C? Thanks, Joel -- http://wagerlabs.com/

1 0

IO exception not being caught
by Joel Reymont 17 Nov '05

17 Nov '05

Folks, I have a problem catching my IO exception with the code below. The intent is to catch either the IO exception from connectTo (connection refused, etc.) or the timeout. type EngineState = ErrorT String (StateT World IO) fromIOError err = ioeGetErrorString err liftIOTrap :: IO a -> EngineState a liftIOTrap io = do mx <- liftIO (do x <- io return (return x) `catchError` (\e -> return (throwError (fromIOError e)))) mx timeout secs fun = do resultVar <- newEmptyMVar threadId <- forkIO $ do result <- fun putMVar resultVar result forkIO $ do threadDelay (secs * 1000000) throwError $ userError "Timeout" maybeResult <- takeMVar resultVar killThread threadId return maybeResult connect_ :: HostName -> Int -> IO Handle connect_ h p = connectTo h $ PortNumber $ fromIntegral p connect :: HostName -> Int -> EngineState () connect host port = do w <- get let secs = timeout_seconds w h <- liftIOTrap $ timeout secs $ connect_ host port trace $ "Connection established, h: " ++ show h ... Thanks, Joel -- http://wagerlabs.com/

2 3

Spurious program crashes
by Joel Reymont 17 Nov '05

17 Nov '05

I'm getting crashes like this and I cannot figure out what the problem is. I'm launching a bunch of threads that connect to a server via TCP and exchange packets. I am running operations like connect and receive in a timeout function that launches two threads and uses an MVar to figure out who's done first. The timeout function then kills the two threads. Any ideas what could be causing this? I feel like a Haskell guinea pig these days :-). My Cabal build options look like this ghc-options: -fglasgow-exts -Wall -O -debug And the stack trace: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x3139322e 0x0027c174 in s8j1_info () (gdb) where #0 0x0027c174 in s8j1_info () #1 0x0021c9f4 in StgRunIsImplementedInAssembler () at StgCRun.c:576 #2 0x0021cdc4 in schedule (mainThread=0x1100360, initialCapability=0x308548) at Schedule.c:932 #3 0x0021dd6c in waitThread_ (m=0x1100360, initialCapability=0x0) at Schedule.c:2156 #4 0x0021dc50 in scheduleWaitThread (tso=0x13c0000, ret=0x0, initialCapability=0x0) at Schedule.c:2050 #5 0x00219548 in rts_evalLazyIO (p=0x29b47c, ret=0x0) at RtsAPI.c:459 #6 0x001e4768 in main (argc=2262116, argv=0x308548) at Main.c:104 Thanks, Joel -- http://wagerlabs.com/

2 3

RE: [Haskell-cafe] Re: [Haskell] Making Haskell more open
by Simon Marlow 17 Nov '05

17 Nov '05

On 14 November 2005 08:32, Gour wrote: > Nobody said that DocBook does not work fine. However let me quote > SPJ's message: > > <quote> > However, I still wonder if there are things we could do that would > make > it easier for people to contribute. Here are two concrete > suggestions: ^^^^^^^ > - Make it possible for people to add comments, explanations, or > questions to > * The GHC user manual [currently generated using DocBook] > * The Haskell 98 Report > The idea would be that anyone could help improve these documents, > ^^^^^^^^^^^^^^^^^^^ > and that, at least in the case of the GHC user manual, we could > use the comments to help clarify the text. > </quote> > > So, the whole discussion, at least from my side, was to offer > suggestions to make it easier for more people to contribute to the > whole haskell community. With regard to the GHC user manual, I don't think the implication above was that we should change the markup technology (at least, I agree with Sven that DocBook XML is on the whole a reasonable solution). The idea was to make it easy for Joe Programmer to add his comments to the manual, whether by a wiki link or some other clever user-editable content mechanism. In a separate stage the comments could be incorporated into the manual proper by the developers, or just left in place for the edification of other users. Cheers, Simon

1 0

RE: [Haskell-cafe] waitForProcess: sytem call interrupted
by Simon Marlow 17 Nov '05

17 Nov '05

On 16 November 2005 11:26, Joel Reymont wrote: > I think runhaskell reports that when the program has crashed > violently with a segmentation violation. It does, and that's a bug. I fixed it last week. Cheers, Simon > > On Nov 16, 2005, at 1:54 AM, Donald Bruce Stewart wrote: > >> I've been getting this in lambdabot with waitForProcess since 6.4.1 >> (I think). Seems harmless though (I think). Try catching the >> exception. >> >> Control.Exception.catch (waitForProcess pid) >> (\_ -> return ExitSuccess) -- so just >> fake success

1 0

RE: [Haskell-cafe] GHC ignores RTS options
by Simon Marlow 16 Nov '05

16 Nov '05

On 16 November 2005 13:24, Tomasz Zielonka wrote: > On Wed, Nov 16, 2005 at 01:09:07PM -0000, Simon Marlow wrote: >>> BTW - it would be nice if it was easier to override the default RTS >>> options when compiling the program. Perhaps a nice task for a newbie >>> GHC developer? >> >> Already possible, see: >> >> http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control. >> html#rts-hooks > > I was aware of this, and I should write about it. > >> Admittedly it's a bit more fiddly than a command-line flag to GHC, >> though. > > And because of this I wrote that it would be nice if it was easier :-) Sorry, I misread the message. > I've bitten several times by the default values of RTS options, > especially the stack size limit (-K). But it was always easier to > set GHCRTS or use +RTS -RTS, so I never used the rts-hooks. > > Do you think I could do this? I am not sure how difficult it would be. Sure, it shouldn't be too hard. You need to generate a .c file containing the ghc_rts_opts setting, and then compile & link it into the final binary. It's just a matter of plumbing the various bits together in GHC's front end. (it might be nicer to generate Cmm and then push this through the back end, to avoid the dependence on the C compiler, though). Cheers, Simon

1 0

RE: [Haskell-cafe] Re: Bring down the house (was Re: GHC cannot compilemy code)
by Simon Peyton-Jones 16 Nov '05

16 Nov '05

I've fixed the HEAD so that it behaves decently on this now. Thanks for reporting it. It's in the test suite! S | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Joel | Reymont | Sent: 09 November 2005 19:27 | To: Haskell Cafe | Subject: [Haskell-cafe] Re: Bring down the house (was Re: GHC cannot compilemy code) | | Shae (#haskell) figured out that this is called for and that GHC has | trouble deriving for large tuples. I have no idea what type of a | performance hit this is gonna be but I hope it's resolved at compile- | time and there's no impact afterwards. | | type TableInfo = TableInfo1 :*: TableInfo2 | | type TableInfo1 = | AvgPot :*: | NumPlayers :*: | Waiting :*: | PlayersFlop :*: | TableName :*: | TableID :*: | GameType :*: | InfoMaxPlayers :*: | RealMoneyTable :*: | LowBet :*: | HighBet :*: | HNil | | type TableInfo2 = | MinStartMoney :*: | MaxStartMoney :*: | GamesPerHour :*: | TourType :*: | TourID :*: | BetType :*: | CantReturnLess :*: | AffiliateID :*: | NIsResurrecting :*: | MinutesForTimeout :*: | SeatsToResurrect :*: | LangID :*: | HNil | | Thanks, Joel | | -- | http://wagerlabs.com/ | | | | | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

RE: [Haskell-cafe] GHC ignores RTS options
by Simon Marlow 16 Nov '05

16 Nov '05

On 16 November 2005 08:12, Tomasz Zielonka wrote: > On Wed, Nov 16, 2005 at 08:53:18AM +0100, Dusan Kolar wrote: >> I wonder whether anybody could advise me how to pass >> correctly RTS options to ghc? I've tried > > You have to pass these options to the program, not > to GHC. > > BTW - it would be nice if it was easier to override the default RTS > options when compiling the program. Perhaps a nice task for a newbie > GHC developer? Already possible, see: http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control. html#rts-hooks Admittedly it's a bit more fiddly than a command-line flag to GHC, though. Cheers, Simon

2 1

Re: [Haskell-cafe] waitForProcess: sytem call interrupted
by Joel Reymont 16 Nov '05

16 Nov '05

I think runhaskell reports that when the program has crashed violently with a segmentation violation. On Nov 16, 2005, at 1:54 AM, Donald Bruce Stewart wrote: > I've been getting this in lambdabot with waitForProcess since 6.4.1 (I > think). Seems harmless though (I think). Try catching the exception. > > Control.Exception.catch (waitForProcess pid) > (\_ -> return ExitSuccess) -- so just > fake success -- http://wagerlabs.com/

1 0

Re: [Haskell-cafe] waitForProcess: sytem call interrupted
by Joel Reymont 16 Nov '05

16 Nov '05

The thing is that I'm launching threads, not processes. The message is printed by runhaskell now that I think about it. On Nov 16, 2005, at 1:54 AM, Donald Bruce Stewart wrote: > I've been getting this in lambdabot with waitForProcess since 6.4.1 (I > think). Seems harmless though (I think). Try catching the exception. > > Control.Exception.catch (waitForProcess pid) > (\_ -> return ExitSuccess) -- so just > fake success -- http://wagerlabs.com/

1 0