[ghc-steering-committee] Proposal #612: Change semantics of -fhpc to not accumulate data over multiple runs, rec: accept

[Arnaud Spiwack]

The proposed change seems sensible. At least the argument is convincing. I
don't use hpc myself, so I don't have an actual design opinion besides
that. So I vote (weakly) for the proposed new default.

Is a deprecation period necessary? Or even useful (how do we signal the
upcoming change in default, and how do we expect people would act on it)?

On Thu, 25 Jan 2024 at 07:06, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Dear Committee members,
>
> In Proposal #612 <https://github.com/ghc-proposals/ghc-proposals/pull/612>,
> David Binder suggests changing the semantics from `-fhpc` to auto-ingest
> existing .tix files for accumulation, towards _not_ auto-ingesting them
> and instead overwriting
> the .tix file with the coverage of the latest run.
>
> I agree with his assessment that the current behaviour easily leads to
> unexpected surprises. He suggests adding a flag --read-tix-file= to control
> this behaviour and defaulting that to _no_, with a grace and
> deprecation period prior informing the user that the currently accumulating
> feature will change in a future GHC release.
>
> Adding the flag to control this behaviour is fairly uncontroversial I
> hope, however I'd like you to. Weight in on the default. Should we change
> the default behaviour, or only add the flag?
>
> I'd recommend changing the default to --read-tix-file=no after a
> deprecation period.
>
> Best,
>  Moritz
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20240125/e030723f/attachment-0001.html>