Proposal #612: Change semantics of -fhpc to not accumulate data over multiple runs, rec: accept
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
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@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@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.
Here's my rationale for a deprecation period. Someone who uses hpc, might rely on the accumulating behaviour. They need a way to be informed about the upcoming change, otherwise they won't know that they need to pass a new flag going forward (and they can even start doing that at that point to be defensive). I also hope the deprecation note would show up in automated tooling, which can then be proactively adjusted. To me the compiler is _the_ interface to the end user. Chances that someone reads the proposals, GHC changelog are very low. Chances someone reads the user guide in detail for each GHC release are low as well, only after the fact, if someone broke will someone start trying to figure out why something broke. At that point, I think we've lost. They are frustrated already that something they knew worked just broke. So to me the deprecation note is basically the signage towards the end user that uses hpc, that they will need to adjust their ghc invocation if they rely on the current behaviour, and also a courtesy heads up that the behaviour they might rely on changes, _and_ how to adjust and get their old behaviour (they may need/rely on) back. To address your two points in detail: > 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)? - As the flag currently does not exist, call GHC with hpc without the new flag will issue a warning. (e.g. current users will be informed). - The warning message will let the user know what to pass to ghc to retain the old (current) behaviour, or opt in to the new (future current) behaviour, depending on their needs. If we did neither, the user would at some point just notice an existing workflow magically stopped or in this case even worse, the silent aggregation of .tix data would stop, and they might _assume_ the data was the aggregate but it wasn't. A silent change in default behaviour would be rather painful to notice, debug, and rectify for users. At least that's my expectation. (And I know I personally would be furious if a compiler pulled that on me). Best, Moritz On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote: > 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@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@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. >
This is an area in which I'm uneducated. I'll abstain, unless we feel like there is enough contention here that it's worth time educating myself. Thanks for driving this forward, Moritz. Richard On Thu, Jan 25, 2024 at 5:50 AM Moritz Angermann <moritz.angermann@gmail.com> wrote: > Here's my rationale for a deprecation period. > > Someone who uses hpc, might rely on the accumulating behaviour. They need > a way to be informed about the upcoming change, otherwise they won't know > that they need to pass a new flag going forward (and they can > even start doing that at that point to be defensive). I also hope the > deprecation note would show up in automated tooling, which can then be > proactively adjusted. > > To me the compiler is _the_ interface to the end user. Chances that > someone reads the proposals, GHC changelog are very low. Chances someone > reads the user guide in detail for each GHC release are low as well, > only after the fact, if someone broke will someone start trying to figure > out why something broke. At that point, I think we've lost. They are > frustrated already that something they knew worked just broke. > > So to me the deprecation note is basically the signage towards the end > user that uses hpc, that they will need to adjust their ghc invocation if > they rely on the current behaviour, and also a courtesy heads up that the > behaviour > they might rely on changes, _and_ how to adjust and get their old > behaviour (they may need/rely on) back. > > To address your two points in detail: > > 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)? > - As the flag currently does not exist, call GHC with hpc without the new > flag will issue a warning. (e.g. current users will be informed). > - The warning message will let the user know what to pass to ghc to retain > the old (current) behaviour, or opt in to the new (future current) > behaviour, depending on their needs. > > If we did neither, the user would at some point just notice an existing > workflow magically stopped or in this case even worse, the silent > aggregation of .tix data would stop, and they > might _assume_ the data was the aggregate but it wasn't. A silent change > in default behaviour would be rather painful to notice, debug, and rectify > for users. At least that's my expectation. > (And I know I personally would be furious if a compiler pulled that on me). > > Best, > Moritz > > On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack <arnaud.spiwack@tweag.io> > wrote: > >> 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@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@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. >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >
On Thu, 25 Jan 2024 at 11:49, Moritz Angermann <moritz.angermann@gmail.com> wrote: > To address your two points in detail: > > 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)? > - As the flag currently does not exist, call GHC with hpc without the new > flag will issue a warning. (e.g. current users will be informed). > - The warning message will let the user know what to pass to ghc to retain > the old (current) behaviour, or opt in to the new (future current) > behaviour, depending on their needs. > > If we did neither, the user would at some point just notice an existing > workflow magically stopped or in this case even worse, the silent > aggregation of .tix data would stop, and they > might _assume_ the data was the aggregate but it wasn't. A silent change > in default behaviour would be rather painful to notice, debug, and rectify > for users. At least that's my expectation. > (And I know I personally would be furious if a compiler pulled that on me). > My guess as to what will happen: people run hpc in CI, at a place where the warning isn't an error, the warning won't be seen, and the breakage will happen all the same. Just a few versions later. To be clear, I don't really care either way. But I'm suspicious of creating extra work for maintainers if we don't believe it's going to actually be useful. There's not enough maintainer time as it is. So I guess my real question is: why do you think my scenario above is incorrect?
Moritz - I agree with everything you say about how users will typically experience the change, but I don't think a deprecation warning resolves the concern. As you say, people might be using HPC via automated tooling and will likely not even see the warning, and even if they do see it will likely ignore it (I don't know about you, but I don't usually want to be distracted by some different yak that needs shaving while I'm coding). IMO we either have to break it completely - i.e. make the existing usage just fail, after a warning cycle - or don't change it at all. We can't silently change the behaviour even with a deprecation cycle. Cheers Simon On Thu, 25 Jan 2024 at 10:49, Moritz Angermann <moritz.angermann@gmail.com> wrote: > Here's my rationale for a deprecation period. > > Someone who uses hpc, might rely on the accumulating behaviour. They need > a way to be informed about the upcoming change, otherwise they won't know > that they need to pass a new flag going forward (and they can > even start doing that at that point to be defensive). I also hope the > deprecation note would show up in automated tooling, which can then be > proactively adjusted. > > To me the compiler is _the_ interface to the end user. Chances that > someone reads the proposals, GHC changelog are very low. Chances someone > reads the user guide in detail for each GHC release are low as well, > only after the fact, if someone broke will someone start trying to figure > out why something broke. At that point, I think we've lost. They are > frustrated already that something they knew worked just broke. > > So to me the deprecation note is basically the signage towards the end > user that uses hpc, that they will need to adjust their ghc invocation if > they rely on the current behaviour, and also a courtesy heads up that the > behaviour > they might rely on changes, _and_ how to adjust and get their old > behaviour (they may need/rely on) back. > > To address your two points in detail: > > 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)? > - As the flag currently does not exist, call GHC with hpc without the new > flag will issue a warning. (e.g. current users will be informed). > - The warning message will let the user know what to pass to ghc to retain > the old (current) behaviour, or opt in to the new (future current) > behaviour, depending on their needs. > > If we did neither, the user would at some point just notice an existing > workflow magically stopped or in this case even worse, the silent > aggregation of .tix data would stop, and they > might _assume_ the data was the aggregate but it wasn't. A silent change > in default behaviour would be rather painful to notice, debug, and rectify > for users. At least that's my expectation. > (And I know I personally would be furious if a compiler pulled that on me). > > Best, > Moritz > > On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack <arnaud.spiwack@tweag.io> > wrote: > >> 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@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@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. >> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >
If we want to "break it completely", we could introduce a third option --read-tix-file=error which will throw an error if an existing .tix file is present (much as will currently happen sometimes if a stale .tix file is there, but with a better error message). The deprecation process could then start by introducing a warning if --read-tix-file is not specified (while --read-tix-file=yes remains the default), then make --read-tix-file=error the default for a release or two, before finally adopting --read-tix-file=no as the default we actually want. Is all this worth it? I'm not sure. It seems quite a lot of bureaucracy and extra work for David and the rest of the GHC team. At some point, perhaps we should expect users to read the release notes if they are upgrading the compiler and experiencing changes? Cheers, Adam On 26/01/2024 16:46, Simon Marlow wrote:
Moritz - I agree with everything you say about how users will typically experience the change, but I don't think a deprecation warning resolves the concern. As you say, people might be using HPC via automated tooling and will likely not even see the warning, and even if they do see it will likely ignore it (I don't know about you, but I don't usually want to be distracted by some different yak that needs shaving while I'm coding).
IMO we either have to break it completely - i.e. make the existing usage just fail, after a warning cycle - or don't change it at all. We can't silently change the behaviour even with a deprecation cycle.
Cheers Simon
On Thu, 25 Jan 2024 at 10:49, Moritz Angermann <moritz.angermann@gmail.com <mailto:moritz.angermann@gmail.com>> wrote:
Here's my rationale for a deprecation period.
Someone who uses hpc, might rely on the accumulating behaviour. They need a way to be informed about the upcoming change, otherwise they won't know that they need to pass a new flag going forward (and they can even start doing that at that point to be defensive). I also hope the deprecation note would show up in automated tooling, which can then be proactively adjusted.
To me the compiler is _the_ interface to the end user. Chances that someone reads the proposals, GHC changelog are very low. Chances someone reads the user guide in detail for each GHC release are low as well, only after the fact, if someone broke will someone start trying to figure out why something broke. At that point, I think we've lost. They are frustrated already that something they knew worked just broke.
So to me the deprecation note is basically the signage towards the end user that uses hpc, that they will need to adjust their ghc invocation if they rely on the current behaviour, and also a courtesy heads up that the behaviour they might rely on changes, _and_ how to adjust and get their old behaviour (they may need/rely on) back.
To address your two points in detail: > 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)? - As the flag currently does not exist, call GHC with hpc without the new flag will issue a warning. (e.g. current users will be informed). - The warning message will let the user know what to pass to ghc to retain the old (current) behaviour, or opt in to the new (future current) behaviour, depending on their needs.
If we did neither, the user would at some point just notice an existing workflow magically stopped or in this case even worse, the silent aggregation of .tix data would stop, and they might _assume_ the data was the aggregate but it wasn't. A silent change in default behaviour would be rather painful to notice, debug, and rectify for users. At least that's my expectation. (And I know I personally would be furious if a compiler pulled that on me).
Best, Moritz
On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
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@gmail.com <mailto:moritz.angermann@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 _______________________________________________
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
The change itself makes sense to me, non-accumulating semantics seem like a much better default. I also think this is a case where users should be expected to read the Release Notes. Just highlight the change of default behavior at the top and move on. On Fri, Jan 26, 2024, at 15:22, Adam Gundry wrote:
If we want to "break it completely", we could introduce a third option --read-tix-file=error which will throw an error if an existing .tix file is present (much as will currently happen sometimes if a stale .tix file is there, but with a better error message).
The deprecation process could then start by introducing a warning if --read-tix-file is not specified (while --read-tix-file=yes remains the default), then make --read-tix-file=error the default for a release or two, before finally adopting --read-tix-file=no as the default we actually want.
Is all this worth it? I'm not sure. It seems quite a lot of bureaucracy and extra work for David and the rest of the GHC team. At some point, perhaps we should expect users to read the release notes if they are upgrading the compiler and experiencing changes?
Cheers,
Adam
On 26/01/2024 16:46, Simon Marlow wrote:
Moritz - I agree with everything you say about how users will typically experience the change, but I don't think a deprecation warning resolves the concern. As you say, people might be using HPC via automated tooling and will likely not even see the warning, and even if they do see it will likely ignore it (I don't know about you, but I don't usually want to be distracted by some different yak that needs shaving while I'm coding).
IMO we either have to break it completely - i.e. make the existing usage just fail, after a warning cycle - or don't change it at all. We can't silently change the behaviour even with a deprecation cycle.
Cheers Simon
On Thu, 25 Jan 2024 at 10:49, Moritz Angermann <moritz.angermann@gmail.com <mailto:moritz.angermann@gmail.com>> wrote:
Here's my rationale for a deprecation period.
Someone who uses hpc, might rely on the accumulating behaviour. They need a way to be informed about the upcoming change, otherwise they won't know that they need to pass a new flag going forward (and they can even start doing that at that point to be defensive). I also hope the deprecation note would show up in automated tooling, which can then be proactively adjusted.
To me the compiler is _the_ interface to the end user. Chances that someone reads the proposals, GHC changelog are very low. Chances someone reads the user guide in detail for each GHC release are low as well, only after the fact, if someone broke will someone start trying to figure out why something broke. At that point, I think we've lost. They are frustrated already that something they knew worked just broke.
So to me the deprecation note is basically the signage towards the end user that uses hpc, that they will need to adjust their ghc invocation if they rely on the current behaviour, and also a courtesy heads up that the behaviour they might rely on changes, _and_ how to adjust and get their old behaviour (they may need/rely on) back.
To address your two points in detail: > 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)? - As the flag currently does not exist, call GHC with hpc without the new flag will issue a warning. (e.g. current users will be informed). - The warning message will let the user know what to pass to ghc to retain the old (current) behaviour, or opt in to the new (future current) behaviour, depending on their needs.
If we did neither, the user would at some point just notice an existing workflow magically stopped or in this case even worse, the silent aggregation of .tix data would stop, and they might _assume_ the data was the aggregate but it wasn't. A silent change in default behaviour would be rather painful to notice, debug, and rectify for users. At least that's my expectation. (And I know I personally would be furious if a compiler pulled that on me).
Best, Moritz
On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote:
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@gmail.com <mailto:moritz.angermann@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 _______________________________________________
-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/
Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Simon, I see where you are coming from. So let me try to outline how I usually handle this: this silent change (even with deprecation) likely alters one of the build products, and hopefully(!) someone will get suspicious (because the build products are used (otherwise why bother building them in the first place). Thus someone flags that something with hpc is off. At which point I'd go and manually investigate what is going on, at _that_ point, I will see this, either because I'm reading the logs, or because the compiler reports it to me while manually running it. 1. I upgrade the compiler. 2. I observe a change. 3. I try to figure out where the change comes from. If in (3) or maybe (2), I am told pretty directly what the change is, it's much easier for me to adjust. Even better if the change message includes instructions on how to adjust. Even better if someone else can observe the change, _and_ know as well as having been given actionable advice on how to proceed. If I can cut myself out of the whole "Something broke, I looked at it, but can't figure out what's going on, and got way too much on my hands, please someone else dig into it" situation, it's a win. Not only for the person experiencing the change (they don't feel helpless, nor do they need to ask for assistance), but also for the people supporting these kinds of issues as they don't come up in the first place. The difference is between it taking 10min to figure, and providing the agency to understand and solve it alone, or needing to reach for support it taking 60+min to figure out and correct, because one has to dig into all the changes and details. Maybe LLM will cut this a bit because one could ask "I'm seeing some strange behaviour regarding -fhpc, please provide a summary of the relevant changes between X and Y". I like SPJ's suggestion in this thread quite a bit and will ask the Author about their opinion. In general we seem to be in agreement around the current default not being ideal, and somewhat hung on the deprecation notice part. With an eye on our stability goals, I'd like to see us try light deprecation warnings. I see that Adams' solution is much more thorough, I also agree that it's a lot more involved. If anyone has qualms around accepting this with a light deprecation notice, please speak up, otherwise I'll mark this proposal as accepted, and merge it in a few days after David responded. Cheers, Moritz On Sat, 27 Jan 2024 at 00:46, Simon Marlow <marlowsd@gmail.com> wrote: > Moritz - I agree with everything you say about how users will typically > experience the change, but I don't think a deprecation warning resolves the > concern. As you say, people might be using HPC via automated tooling and > will likely not even see the warning, and even if they do see it will > likely ignore it (I don't know about you, but I don't usually want to be > distracted by some different yak that needs shaving while I'm coding). > > IMO we either have to break it completely - i.e. make the existing usage > just fail, after a warning cycle - or don't change it at all. We can't > silently change the behaviour even with a deprecation cycle. > > Cheers > Simon > > On Thu, 25 Jan 2024 at 10:49, Moritz Angermann <moritz.angermann@gmail.com> > wrote: > >> Here's my rationale for a deprecation period. >> >> Someone who uses hpc, might rely on the accumulating behaviour. They >> need a way to be informed about the upcoming change, otherwise they won't >> know that they need to pass a new flag going forward (and they can >> even start doing that at that point to be defensive). I also hope the >> deprecation note would show up in automated tooling, which can then be >> proactively adjusted. >> >> To me the compiler is _the_ interface to the end user. Chances that >> someone reads the proposals, GHC changelog are very low. Chances someone >> reads the user guide in detail for each GHC release are low as well, >> only after the fact, if someone broke will someone start trying to figure >> out why something broke. At that point, I think we've lost. They are >> frustrated already that something they knew worked just broke. >> >> So to me the deprecation note is basically the signage towards the end >> user that uses hpc, that they will need to adjust their ghc invocation if >> they rely on the current behaviour, and also a courtesy heads up that the >> behaviour >> they might rely on changes, _and_ how to adjust and get their old >> behaviour (they may need/rely on) back. >> >> To address your two points in detail: >> > 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)? >> - As the flag currently does not exist, call GHC with hpc without the new >> flag will issue a warning. (e.g. current users will be informed). >> - The warning message will let the user know what to pass to ghc to >> retain the old (current) behaviour, or opt in to the new (future current) >> behaviour, depending on their needs. >> >> If we did neither, the user would at some point just notice an existing >> workflow magically stopped or in this case even worse, the silent >> aggregation of .tix data would stop, and they >> might _assume_ the data was the aggregate but it wasn't. A silent change >> in default behaviour would be rather painful to notice, debug, and rectify >> for users. At least that's my expectation. >> (And I know I personally would be furious if a compiler pulled that on >> me). >> >> Best, >> Moritz >> >> On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack <arnaud.spiwack@tweag.io> >> wrote: >> >>> 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@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@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. >>> >> _______________________________________________ >> ghc-steering-committee mailing list >> ghc-steering-committee@haskell.org >> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >> >
I am fine with a light depracation notice : +1 from me. > On 23 Feb 2024, at 00:41, Moritz Angermann <moritz.angermann@gmail.com> wrote: > > Simon, > > I see where you are coming from. So let me try to outline how I usually handle this: this silent change (even with deprecation) likely alters one > of the build products, and hopefully(!) someone will get suspicious (because the build products are used (otherwise why bother building them > in the first place). Thus someone flags that something with hpc is off. At which point I'd go and manually investigate what is going on, at _that_ > point, I will see this, either because I'm reading the logs, or because the compiler reports it to me while manually running it. > > 1. I upgrade the compiler. > 2. I observe a change. > 3. I try to figure out where the change comes from. > > If in (3) or maybe (2), I am told pretty directly what the change is, it's much easier for me to adjust. Even better if the change message includes > instructions on how to adjust. Even better if someone else can observe the change, _and_ know as well as having been given actionable advice > on how to proceed. If I can cut myself out of the whole "Something broke, I looked at it, but can't figure out what's going on, and got way too much > on my hands, please someone else dig into it" situation, it's a win. Not only for the person experiencing the change (they don't feel helpless, nor do they > need to ask for assistance), but also for the people supporting these kinds of issues as they don't come up in the first place. > > The difference is between it taking 10min to figure, and providing the agency to understand and solve it alone, or needing to reach for support it > taking 60+min to figure out and correct, because one has to dig into all the changes and details. Maybe LLM will cut this a bit because one could > ask "I'm seeing some strange behaviour regarding -fhpc, please provide a summary of the relevant changes between X and Y". > > I like SPJ's suggestion in this thread quite a bit and will ask the Author about their opinion. > > In general we seem to be in agreement around the current default not being ideal, and somewhat hung on the deprecation notice part. With an > eye on our stability goals, I'd like to see us try light deprecation warnings. I see that Adams' solution is much more thorough, I also agree that it's > a lot more involved. > > If anyone has qualms around accepting this with a light deprecation notice, please speak up, otherwise I'll mark this proposal as accepted, and > merge it in a few days after David responded. > > Cheers, > Moritz > > On Sat, 27 Jan 2024 at 00:46, Simon Marlow <marlowsd@gmail.com <mailto:marlowsd@gmail.com>> wrote: >> Moritz - I agree with everything you say about how users will typically experience the change, but I don't think a deprecation warning resolves the concern. As you say, people might be using HPC via automated tooling and will likely not even see the warning, and even if they do see it will likely ignore it (I don't know about you, but I don't usually want to be distracted by some different yak that needs shaving while I'm coding). >> >> IMO we either have to break it completely - i.e. make the existing usage just fail, after a warning cycle - or don't change it at all. We can't silently change the behaviour even with a deprecation cycle. >> >> Cheers >> Simon >> >> On Thu, 25 Jan 2024 at 10:49, Moritz Angermann <moritz.angermann@gmail.com <mailto:moritz.angermann@gmail.com>> wrote: >>> Here's my rationale for a deprecation period. >>> >>> Someone who uses hpc, might rely on the accumulating behaviour. They need a way to be informed about the upcoming change, otherwise they won't know that they need to pass a new flag going forward (and they can >>> even start doing that at that point to be defensive). I also hope the deprecation note would show up in automated tooling, which can then be proactively adjusted. >>> >>> To me the compiler is _the_ interface to the end user. Chances that someone reads the proposals, GHC changelog are very low. Chances someone reads the user guide in detail for each GHC release are low as well, >>> only after the fact, if someone broke will someone start trying to figure out why something broke. At that point, I think we've lost. They are frustrated already that something they knew worked just broke. >>> >>> So to me the deprecation note is basically the signage towards the end user that uses hpc, that they will need to adjust their ghc invocation if they rely on the current behaviour, and also a courtesy heads up that the behaviour >>> they might rely on changes, _and_ how to adjust and get their old behaviour (they may need/rely on) back. >>> >>> To address your two points in detail: >>> > 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)? >>> - As the flag currently does not exist, call GHC with hpc without the new flag will issue a warning. (e.g. current users will be informed). >>> - The warning message will let the user know what to pass to ghc to retain the old (current) behaviour, or opt in to the new (future current) behaviour, depending on their needs. >>> >>> If we did neither, the user would at some point just notice an existing workflow magically stopped or in this case even worse, the silent aggregation of .tix data would stop, and they >>> might _assume_ the data was the aggregate but it wasn't. A silent change in default behaviour would be rather painful to notice, debug, and rectify for users. At least that's my expectation. >>> (And I know I personally would be furious if a compiler pulled that on me). >>> >>> Best, >>> Moritz >>> >>> On Thu, 25 Jan 2024 at 18:35, Arnaud Spiwack <arnaud.spiwack@tweag.io <mailto:arnaud.spiwack@tweag.io>> wrote: >>>> 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@gmail.com <mailto:moritz.angermann@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@haskell.org <mailto:ghc-steering-committee@haskell.org> >>>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>>> >>>> >>>> -- >>>> Arnaud Spiwack >>>> Director, Research at https://moduscreate.com <https://moduscreate.com/> and https://tweag.io <https://tweag.io/>. >>> _______________________________________________ >>> ghc-steering-committee mailing list >>> ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
The change itself makes sense to me, non-accumulating semantics seem like a much better default. I strongly agree with this. The current behaviour seems deeply strange, and the proposer offers evidence that it messes up users. As to deprecation, how about this: - In the first release, GHC continues with the current behaviour, but *if* it finds an old file (of any kind, even in the wrong format) it emits a warning (before attempting to read it) saying *I am reading in the existing tix file, and will add hpc info from this run to the existing data in that file. GHC 9.12 will cease looking for an existing tix file. If you positively want to add hpc info to the current tix file, use `-fread-tix-file`* - In the next release, it stops reading the file That is not onerous to implement, but it gives due warning. Moreover, you can respond right away by saying `-fno-read-tix-file` or `-fread-tix-file` to avoid the warning. Simon says I don't think a deprecation warning resolves the concern
That's true of all deprecation warnings -- there will always be users who ignore them. But we have done our duty by, well, warning them. Simon On Thu, 25 Jan 2024 at 06:06, Moritz Angermann <moritz.angermann@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
For the record, I'm fine either way. On Mon, 29 Jan 2024 at 10:35, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:
The change itself makes sense to me, non-accumulating semantics seem like a much better default.
I strongly agree with this. The current behaviour seems deeply strange, and the proposer offers evidence that it messes up users.
As to deprecation, how about this:
- In the first release, GHC continues with the current behaviour, but *if* it finds an old file (of any kind, even in the wrong format) it emits a warning (before attempting to read it) saying
*I am reading in the existing tix file, and will add hpc info from this run to the existing data in that file. GHC 9.12 will cease looking for an existing tix file. If you positively want to add hpc info to the current tix file, use `-fread-tix-file`*
- In the next release, it stops reading the file
That is not onerous to implement, but it gives due warning. Moreover, you can respond right away by saying `-fno-read-tix-file` or `-fread-tix-file` to avoid the warning.
Simon says
I don't think a deprecation warning resolves the concern
That's true of all deprecation warnings -- there will always be users who ignore them. But we have done our duty by, well, warning them.
Simon
On Thu, 25 Jan 2024 at 06:06, Moritz Angermann <moritz.angermann@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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.
participants (8)
-
Adam Gundry -
Arnaud Spiwack -
Chris Dornan -
Eric Seidel -
Moritz Angermann -
Richard Eisenberg -
Simon Marlow -
Simon Peyton Jones