[commit: ghc] master: Bump haddock.base max_bytes_used (8df7fea)

Joachim Breitner mail at joachim-breitner.de
Mon Aug 4 12:13:48 UTC 2014


Am Montag, den 04.08.2014, 13:08 +0200 schrieb Joachim Breitner:
> Am Montag, den 04.08.2014, 12:02 +0100 schrieb Edward Z.Yang:
> > Yes, on my box, this test is now failing (because the stat is too good):
> > 
> >     Expected    haddock.base(normal) max_bytes_used: 127954488 +/-10%
> >     Lower bound haddock.base(normal) max_bytes_used: 115159039 
> >     Upper bound haddock.base(normal) max_bytes_used: 140749937 
> >     Actual      haddock.base(normal) max_bytes_used: 113167424 
> >     Deviation   haddock.base(normal) max_bytes_used:     -11.6 %
> ugh.
> What are your compilation settings? Plain "validate"?
> Looks like the ghcspeed instance settings still don’t quite match what
> validate does...
> But I don’t see anything in 
>         mk/validate-settings.mk
> which would yield different results than
>         echo 'GhcLibHcOpts += -O -dcore-lint'  >> mk/build.mk
>         echo 'GhcStage2HcOpts += -O -dcore-lint'  >> mk/build.mk
> I’m starting a plain validate run on that machine, to see if it is
> compilation settings or some other variable.

validate goes through without a problem. So it seems to be dependent on
other things.

Are these very flaky measures (max_bytes_used) at all useful? So far, I
have only seen friction due to them, and any real problem would likely
be caught by either bytes_allocated or nofib measurements (I hope).
Maybe we should simply remove them from the test suite, and stop


Joachim “nomeata” Breitner
  mail at joachim-breitner.dehttp://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140804/9d879b13/attachment.sig>

More information about the ghc-devs mailing list