Visitar URL original
Expose `--no-automatic-time-samples` in `GHC.RTS.Flags` API · Issue #243 · haskell/core-libraries-committee · GitHub
Skip to content

Expose --no-automatic-time-samples in GHC.RTS.Flags API #243

Closed

Description

@mpickering

GHC MR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11916

In GHC MR !11424 a new RTS flag was added --no-automatic-time-samples.

Therefore we should also modify GHC.RTS.Flags in the same manner so that users can query whether this option is set from their programs, and keep GHC.RTS.Flags up to date with the implemented RTS flags.

Activity

  1. mpickering commented on Jan 30, 2024

    @mpickering
    Author

    Is there anything which can be done to move this issue forwards? It seems that we should keep GHC.RTS.Flags up to date with the flags implemented by the RTS.

  2. Bodigrim commented on Feb 1, 2024

    @Bodigrim
    Contributor

    Technically adding a record field is a breaking change, but given how obscure GHC.RTS.Flags is...

    ProfFlags are used only in handful of places throughout entire Hackage: https://hackage-search.serokell.io/?q=%5CbProfFlags. None of them will be broken by the change.

    Thus I'm content to vote in favor. Dear CLC members, any more opinions before we vote?

  3. tomjaguarpaw commented on Feb 1, 2024

    @tomjaguarpaw
    Member

    It seems fine to me. If GHC's interface changes then we need to make the corresponding change to anything that represents its interface. Ultimately though, given that this is a GHC-only concern, I'd love to see this functionality migrated into a package under the sole purview of GHC HQ.

  4. Bodigrim commented on Feb 11, 2024

    @Bodigrim
    Contributor

    Dear CLC members, let's vote on the proposal to extend GHC.RTS.Flags to reflect faithfully RTS flags, including recently added one --no-automatic-time-samples. The MR is available at https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11916 and boils down to extending data ProfFlags with startTimeProfileAtStartup :: Bool.

    @tomjaguarpaw @mixphix @hasufell @velveteer @angerman @parsonsmatt


    +1 from me.

  5. tomjaguarpaw commented on Feb 11, 2024

    @tomjaguarpaw
    Member

    +1


    I risk sounding monotonous and saying things redundantly, but I'll reiterate anyway that these kinds of GHC configuration types should be in a GHC-internal module in the future.

    EDIT: Actually I shouldn't say "internal". It's up to GHC HQ whether they expose these from a package that they intend to keep stable (I encourage them to do so), it just shouldn't be base, because they are deeply linked to GHC implementation details.

  6. velveteer commented on Feb 11, 2024

    @velveteer
    Contributor

    +1

  7. parsonsmatt commented on Feb 11, 2024

    @parsonsmatt

    +1

  8. angerman commented on Feb 12, 2024

    @angerman

    +1

  9. mpickering commented on Feb 12, 2024

    @mpickering
    Author

    @tomjaguarpaw I think we are in agreement there, and if you or another CLC member would like to open a proposal to move GHC.RTS.Flags out of base then I think GHC developers would support that.

  10. Bodigrim commented on Feb 12, 2024

    @Bodigrim
    Contributor

    Thanks all, that's enough votes to approve.

  11. added
    approvedApproved by CLC vote
    and removed on Feb 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    approvedApproved by CLC votebase-4.20Implemented in base-4.20 (GHC 9.10)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions