nofib oldest GHC to support?

Simon Marlow marlowsd at gmail.com
Thu Oct 4 07:35:54 UTC 2018


Typically I never remove any support for older compilers in nofib and the
nofib-analyze tool, I just add support for new things. I realise we don't
continuously test any of those old versions and thus they can bitrot, but
in my experience so far it doesn't happen very often, and it's sometimes
really useful to be able to use older versions.

Why did it break with 7.10.3? Can that be fixed?

I guess we could remove the Gofer support though :)

In the list of regrexes you pointed to, don't you just need to add one more
to support the new format? It would be nice if those regexes had comments
to explain which version they were added for, I guess we could start doing
that from now on.

Cheers
Simon


On Mon, 1 Oct 2018 at 09:05, Ömer Sinan Ağacan <omeragacan at gmail.com> wrote:

> We currently claim to support GOFER and GHC 4.02! Surely we can drop some
> of
> those support.
>
> I just tried booting nofib with GHC 7.10.3 and it failed. We don't even
> support
> 7.10.3, but we still have code to support ... 4.02!
>
> The desire to cleanup is not because removing code is fun, it's because it
> makes it easier to maintain. Currently I need to parse another variant of
> `+RTS
> -t` output, and I have to deal with this mess for it:
>
>
> https://github.com/ghc/nofib/blob/a80baacfc29cc2e7ed50e94f3cd2648d11b1d7d5/nofib-analyse/Slurp.hs#L153-L207
>
> (note that all of these need to be updated to add one more field)
>
> If we decide on what versions to support we could remove most of those (I
> doubt
> `+RTS -t` output changes too much, so maybe we can even remove all but
> one).
>
> There are also other code with CPP macros for GOFER etc.
>
> I suggest supporting HEAD + 3 major releases. In this plan currently we
> should
> be able to run nofib with GHC HEAD, 8.6, 8.4, and 8.2. Then setting up a
> CI to
> test nofib with these configurations should be trivial (except for GHC HEAD
> maybe, I don't know if we're publishing GHC HEAD bindists for CI servers to
> use).
>
> Ömer
> Joachim Breitner <mail at joachim-breitner.de>, 1 Eki 2018 Pzt, 03:33
> tarihinde şunu yazdı:
> >
> > Hi,
> >
> > there is no policy that I am aware of, but being able to run nofib on
> > old (or even ancient) versions of GHC is likely to make someone happy
> > in the future, so I’d say that the (valid!) desire to cleanup is not a
> > good reason to drop support – only if it would require unreasonable
> > efforts should we drop old versions there.
> >
> > Cheers,
> > Joachim
> >
> > Am Sonntag, den 30.09.2018, 14:18 +0300 schrieb Ömer Sinan Ağacan:
> > > Do we have a policy on the oldest GHC to support in nofib? I'm
> currently doing
> > > some hacking on nofib to parse some new info printed by a modified
> GHC, and I
> > > think we can do a lot of cleaning (at the very least remove some
> regexes and
> > > parsers) if we decide on which GHCs to support.
> > >
> > > I checked the README and RunningNoFib wiki page but couldn't see
> anything
> > > relevant.
> > >
> > > Thanks
> > >
> > > Ömer
> > > _______________________________________________
> > > ghc-devs mailing list
> > > ghc-devs at haskell.org
> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> > --
> > Joachim Breitner
> >   mail at joachim-breitner.de
> >   http://www.joachim-breitner.de/
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181004/3a0ef2ee/attachment.html>


More information about the ghc-devs mailing list