Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,867
    • Issues 4,867
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 457
    • Merge requests 457
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #2946
Closed
Open
Created Jan 13, 2009 by phercek@trac-phercek

tracing should be controled by a global flag

Instead of ":trace" and ":trace <expr>" command there should be one command ":set trace on/off" and a new command ":debug <expr>".

":set trace" would control a global flag indicating whether tracing should be active or not. If tracing is active then:[[BR]]

  • ":continue" would behave like current ":trace",[[BR]]
  • forcing a value using ":force <expr>" woudl work like current ":trace <expr>" but ignoring breakpoitns,[[BR]]
  • ":debug <expr>" would work like current ":trace <expr>",[[BR]]
  • and ":main ..." would start Main.main with tracing on from the very beginning.[[BR]]

If tracing is not active then ":continue", ":force", ":main" would behave like they do now and ":debug <expr>" would be the same as current "<expr>".

Reasoning:

I believe people use tracing to get access to variables which are not free in the selected scope but which contributed to values in the selected scope. So if they want variable availability they want tracing on all the time if they care about speed they want tracing off all the time. With this change request accepted they do not need to remember which command to use to continue or to print a forced value. When an <expr> is an argument to a ghci command and tracing is on then trace hisotry is extended, if tracing is off then trace history is not extended, if <expr> is typed on the ghci command line directly then tracing is never extended.

This change is not that important for manual ussage but it helps to simplify custom defined ghci comamnds/scripts (which e.g. will not need to take care whether to use ":continue" or ":trace" based on a global flag). This would also allow to start tracing from the very beggining of ":main" instead of setting a break at Main.main with a script set to ":trace" and then running ":main ...".

Related discussion is here: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-January/016436.html

I do not know about other usage patterns for which the current state of tracing UI is better. If you do know then vote against this.

Trac metadata
Trac field Value
Version 6.10.1
Type FeatureRequest
TypeOfFailure OtherFailure
Priority normal
Resolution Unresolved
Component GHCi
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture
Edited Mar 09, 2019 by phercek
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking