<div dir="ltr"><div>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.</div><div><br></div><div>Why did it break with 7.10.3? Can that be fixed?<br></div><div><br></div><div>I guess we could remove the Gofer support though :)<br></div><div><br></div><div>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.<br></div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, 1 Oct 2018 at 09:05, Ömer Sinan Ağacan <<a href="mailto:omeragacan@gmail.com">omeragacan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We currently claim to support GOFER and GHC 4.02! Surely we can drop some of<br>
those support.<br>
<br>
I just tried booting nofib with GHC 7.10.3 and it failed. We don't even support<br>
7.10.3, but we still have code to support ... 4.02!<br>
<br>
The desire to cleanup is not because removing code is fun, it's because it<br>
makes it easier to maintain. Currently I need to parse another variant of `+RTS<br>
-t` output, and I have to deal with this mess for it:<br>
<br>
<a href="https://github.com/ghc/nofib/blob/a80baacfc29cc2e7ed50e94f3cd2648d11b1d7d5/nofib-analyse/Slurp.hs#L153-L207" rel="noreferrer" target="_blank">https://github.com/ghc/nofib/blob/a80baacfc29cc2e7ed50e94f3cd2648d11b1d7d5/nofib-analyse/Slurp.hs#L153-L207</a><br>
<br>
(note that all of these need to be updated to add one more field)<br>
<br>
If we decide on what versions to support we could remove most of those (I doubt<br>
`+RTS -t` output changes too much, so maybe we can even remove all but one).<br>
<br>
There are also other code with CPP macros for GOFER etc.<br>
<br>
I suggest supporting HEAD + 3 major releases. In this plan currently we should<br>
be able to run nofib with GHC HEAD, 8.6, 8.4, and 8.2. Then setting up a CI to<br>
test nofib with these configurations should be trivial (except for GHC HEAD<br>
maybe, I don't know if we're publishing GHC HEAD bindists for CI servers to<br>
use).<br>
<br>
Ömer<br>
Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>>, 1 Eki 2018 Pzt, 03:33<br>
tarihinde şunu yazdı:<br>
><br>
> Hi,<br>
><br>
> there is no policy that I am aware of, but being able to run nofib on<br>
> old (or even ancient) versions of GHC is likely to make someone happy<br>
> in the future, so I’d say that the (valid!) desire to cleanup is not a<br>
> good reason to drop support – only if it would require unreasonable<br>
> efforts should we drop old versions there.<br>
><br>
> Cheers,<br>
> Joachim<br>
><br>
> Am Sonntag, den 30.09.2018, 14:18 +0300 schrieb Ömer Sinan Ağacan:<br>
> > Do we have a policy on the oldest GHC to support in nofib? I'm currently doing<br>
> > some hacking on nofib to parse some new info printed by a modified GHC, and I<br>
> > think we can do a lot of cleaning (at the very least remove some regexes and<br>
> > parsers) if we decide on which GHCs to support.<br>
> ><br>
> > I checked the README and RunningNoFib wiki page but couldn't see anything<br>
> > relevant.<br>
> ><br>
> > Thanks<br>
> ><br>
> > Ömer<br>
> > _______________________________________________<br>
> > ghc-devs mailing list<br>
> > <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> > <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
> --<br>
> Joachim Breitner<br>
> <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
> <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
><br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>