nofib oldest GHC to support?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

nofib oldest GHC to support?

Ö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
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: nofib oldest GHC to support?

Joachim Breitner-2
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
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
--
Joachim Breitner
  [hidden email]
  http://www.joachim-breitner.de/


_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: nofib oldest GHC to support?

Ömer Sinan Ağacan
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 <[hidden email]>, 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> --
> Joachim Breitner
>   [hidden email]
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Reply | Threaded
Open this post in threaded view
|

Re: nofib oldest GHC to support?

Simon Marlow-7
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 <[hidden email]> 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 <[hidden email]>, 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
> > [hidden email]
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> --
> Joachim Breitner
>   [hidden email]
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> ghc-devs mailing list
> [hidden email]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
ghc-devs mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs