Re: Patch to enable GHC runtime system with thr_debug_p options...
Dear Michał, Am Sonntag, den 02.12.2012, 22:44 +0100 schrieb "Michał J. Gajda":
On 12/02/2012 09:20 PM, Joachim Breitner wrote:
I noticed that Ubuntu, as well as Debian and original packages come without some variants of threaded debugging binaries. A recent change added of printing a stack trace with -xc option requires using both -ticky and profiling compile options, which in turn forces program to be compiled in a -debug RTS way. Since stack trace looks like indispensable debugging tool, and convenient parallelization is strength of Haskell, I wonder is there any remaining reason to leave beginners with a cryptic error message when they try to debug a parallel or threaded application, and want to take advantage of stack trace?
The resulting ghc-prof package would be increased by less than 1%.
Here is a patch for Ubuntu/Debian GHC 7.4.2 package, as well as upstream
--- ghc-7.4.2-orig/mk/config.mk.in 2012-06-06 19:10:25.000000000 +0200 +++ ghc-7.4.2/mk/config.mk.in 2012-12-01 00:22:29.055003842 +0100 @@ -256,7 +256,7 @@ # l : event logging # thr_l : threaded and event logging # -GhcRTSWays=l +GhcRTSWays=l thr_debug_p thr_debug # Usually want the debug version ifeq "$(BootingFromHc)" "NO" I notice that your patch modifies the defaults of GHC as shipped by upstream, and I wonder if there is a reason why these ways are not enabled by default. Dear GHC HQ: Would you advice against or for providing a RTS in the thr_debug_p and thr_debug ways in the Debian package? Thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
On 03/12/12 20:11, Joachim Breitner wrote:
Dear Michał,
Am Sonntag, den 02.12.2012, 22:44 +0100 schrieb "Michał J. Gajda":
On 12/02/2012 09:20 PM, Joachim Breitner wrote:
I noticed that Ubuntu, as well as Debian and original packages come without some variants of threaded debugging binaries. A recent change added of printing a stack trace with -xc option requires using both -ticky and profiling compile options, which in turn forces program to be compiled in a -debug RTS way. Since stack trace looks like indispensable debugging tool, and convenient parallelization is strength of Haskell, I wonder is there any remaining reason to leave beginners with a cryptic error message when they try to debug a parallel or threaded application, and want to take advantage of stack trace?
The resulting ghc-prof package would be increased by less than 1%.
Here is a patch for Ubuntu/Debian GHC 7.4.2 package, as well as upstream
--- ghc-7.4.2-orig/mk/config.mk.in 2012-06-06 19:10:25.000000000 +0200 +++ ghc-7.4.2/mk/config.mk.in 2012-12-01 00:22:29.055003842 +0100 @@ -256,7 +256,7 @@ # l : event logging # thr_l : threaded and event logging # -GhcRTSWays=l +GhcRTSWays=l thr_debug_p thr_debug
# Usually want the debug version ifeq "$(BootingFromHc)" "NO"
I notice that your patch modifies the defaults of GHC as shipped by upstream, and I wonder if there is a reason why these ways are not enabled by default.
Dear GHC HQ: Would you advice against or for providing a RTS in the thr_debug_p and thr_debug ways in the Debian package?
thr_debug is already enabled by default. thr_debug_p is not currently enabled, but only because we very rarely need it, so there wouldn't be any problem with enabling it by default. Cheers, Simon
On Mon, Dec 03, 2012 at 09:11:07PM +0100, Joachim Breitner wrote:
Dear GHC HQ: Would you advice against or for providing a RTS in the thr_debug_p and thr_debug ways in the Debian package?
The main reasons not to add RTS ways are that they take time to build, and use disk space once built. For a distribution, it probably makes sense to build all of them (even if some are put in a separate ghc-rts-extra-ways package) as the compile-time is shared amongst many users, and it is harder for the user to build extra ways. It's also true that non-default ways are less-well-tested, but that doesn't necessarily mean they are buggier. And building them certainly shouldn't cause any bugs when not using those extra ways. Thanks Ian
participants (3)
-
Ian Lynagh -
Joachim Breitner -
Simon Marlow