ghc-devs

Download

ghc-devs@haskell.org

December 2013

37 participants
42 discussions

Re: [commit: testsuite] master: Explain skipping compiler-perf tests when debugging is on (14958ae)
by Simon Marlow 02 Dec '13

02 Dec '13

Actually this isn't quite right. compiler_debugged() is true when GhcDebugged=YES in the build system, and GhcDebugged controls whether GHC is compiled with -debug or not. That is, compiler_debugged() tells us whether the compiler was compiled with -debug, not -DDEBUG. The -debug flag links in the debug RTS and doesn't change allocation or heap residency, whereas -DDEBUG enables assertions in the compiler and *does* change allocation and heap residency. It looks like we need another predicate to tell us whether GHC was compiled with -DDEBUG or not. Would you mind backing out these changes in the meantime? Cheers, Simon On 28/11/13 15:55, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/testsuite > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/14958ae02b99bafc06288493d186b9313… > >> --------------------------------------------------------------- > > commit 14958ae02b99bafc06288493d186b9313ee8c4b9 > Author: Joachim Breitner <mail(a)joachim-breitner.de> > Date: Thu Nov 28 15:56:16 2013 +0000 > > Explain skipping compiler-perf tests when debugging is on > > >> --------------------------------------------------------------- > > 14958ae02b99bafc06288493d186b9313ee8c4b9 > driver/testlib.py | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/driver/testlib.py b/driver/testlib.py > index bdb91b8..8c8c60d 100644 > --- a/driver/testlib.py > +++ b/driver/testlib.py > @@ -291,6 +291,8 @@ def _compiler_stats_num_field( name, opts, field, expecteds ): > if field in opts.compiler_stats_range_fields: > framework_fail(name, 'duplicate-numfield', 'Duplicate ' + field + ' num_field check') > > + # Compiler performance numbers change when debugging is on, making the results > + # useless and confusing. Therefore, skip if debugging is on. > if compiler_debugged(): > skip(name, opts) > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 3

Re: Getting Involved
by Jan Stolarek 02 Dec '13

02 Dec '13

Herbert, Austin, right, I didn't notice link to Newcomers is on the "Working on GHC" page. I rearranged it slightly by reversing first three steps. So link to Newcomers is now first on the list and I think it might stay that way. Link to "Working on GHC" is also in the second paragraph of the main wiki page, so I think we're good. As for the sidebar I'm using it on a regular basis although I feel some links could be removed: Documentation -> Repositories; Debugging; View Tickets -> By Milestone; By OS; By Architecture; But that's only my opinion - I'm CCing ghc-devs so others can chime in. If we could somehow track how often each link is used that could be a valuable information. Not sure if it can be done. Janek Dnia niedziela, 1 grudnia 2013, Herbert Valerio Riedel napisał: > On 2013-12-01 at 09:00:21 +0100, Jan Stolarek wrote: > >> perhaps a direct link in the sidebar or maybe even a link on the front > >> page in Developer Documentation section would be appropriate! > > > > I added link to Newcomers page at the main page of Commentary. > > btw, I'm confused a bit... there's already a rather obvious > > "Joining In"->"Working on GHC" link in the side-bar, which points to > > https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions > > which then points you to the steps that are expected from newcomers, > including the 'Newcomers' page as the 3rd step; once could maybe just > add more emphasis to the 3rd step so that it visually stands out better > (e.g. via [2] or [3]) > > I'm just worried that cluttering the side-bar[1] with a redundant link > may make it less useful. > > > Don't have the permissions to add it to the sidebar though. > > ...the reason is btw, that it's a hacked in HTML fragment that's part of > the custom Trac stylesheet mod for GHC; it can't be edited via the > web-UI. > > > > [1]: which, personally, I find kinda overloaded and redundant which > makes me wonder if it's really that useful in its current form; > > > [2]: https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes > > [3]: https://ghc.haskell.org/trac/ghc/wiki/WikiIcons

2 1