[GHC] #12851: Regression: GHC doesn't show filepaths by default anymore
#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: regression | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sorry for chiming in so late, I didn't notice #12807 and I didn't build GHC HEAD for several days, otherwise I would have cried out loud sooner. I'm deliberately declaring this a regression since I consider this a bad default. And not for the mere fact that change is bad ;-) Don't get me wrong, I can see usefulness in the `-fno-show-source-paths` feature (although I consider it inconsistent, see below), but it's a bad default because in my workflows I rely on seeing the source-path ''by default'', and I see no way to restore this as the default behaviour of GHC short of patching GHC. {{{ [1 of 1] Compiling Control.Concurrent.STMSupply (.hs -> .o) }}} First of all, if we drop filepaths, then please drop them completely, either I need more information about which `.hs` file was used as source, or I don't need it at all, so this ` (.hs -> .o)` suffix is just noise to me; not the least because the `-> .o` part carries almost no information for me. If the premise of `-fno-show-source-paths` is that we know how we called GHC and thereby know what is being compiled, showing `(.hs -> .o)` is pointless. Morever, `-f(no-)show-source-paths` is a lie/misnomer, as it doesn't only control the *source* path display, but *also* the *output* path display! Also, when invoking GHC, and pass it multiple include folders, sometimes GHC picks up the wrong module (or rather one I didn't intend), having it print the source file path by default has been a big timesaver to me, detecting when I was barking up the wrong source-file while figuring out why stuff didn't work. Finally, this also breaks my shell-based workflow because I'm used to copy'n'paste filepaths from GHC's output, especially for longer source- paths where tab-completing my way to the source path is too tedious. This is just the first impression I got while being exposed to this UI change today, there may be other regressions I'd notice when having to use this for longer. So, in summary I propose to - Make `-fshow-source-paths` the default again - drop the `(.hs->.o)` suffix in `-fno-show-show-source-paths` - consider a better name; actually, I can see cases where you want to omit only the output-path display (since it's imho often less interesting to know the output files names; even though sometimes you may want to know it since it can be affected in a non-obvious way by output-dir flags), e.g. maybe - Have `-f(no-)show-source-paths` control the source-path display - Have `-f(no-)show-output-paths` control the output-path display - As a compromise, consider `-fshow-source-paths -fno-show-output- paths` becoming the new default. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12851 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): I agree that this change throws away useful information while keeping in not so useful one. I would do it simpler though: If verbose, show information as it used to be show, with full paths. If not verbose, show just module name. Note that haskell-mode filters out everything after module name and this is expected behavior by newbees or when smaller projects are compiled. For more complicated projects hvr and other can increase verbosity level. I would also postulate to *not* add new flag with such low marginal utility and just use the existing verbosity level for this purpose. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12851#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Author of the aformentioned patch here. Sorry for the lack of advertising of this change. 1. I didn't want the patch to be too radical, that is why I left the extensions "(.hs -> .o)": the paths could be inferred from the module name (at least in simple cases) but the extensions may not (.lhs for instance). I kept the previous object path display: "nothing"/"interpreted" when the target is HscNothing/HscInterpreted. Nevertheless I agree that we could totally avoid it. It is already what haskell-mode is doing (thanks @gracjan for the comment on Phab:D2679#79222). So this doesn't seem to be controversial and I will make a patch for this. 2. Do we need a new flag? Initially SPJ asked for one in #12807 to restore the old behaviour and it avoids enabling a too verbose mode. Also we would like verbosity levels to be aliases for sets of verbosity flags (see #12822). 3. Flag name: there has been a little bikeshedding about the flag name already (see Phab:D2679#77954). Initially I chose "-fshow-module-paths" but @nomeata thought "-fshow-source-paths" would be better and I don't have a strong opinion on it. I agree that having two flags (for source/object paths) would be more correct. 4. Hiding the object path by default: it doesn't seem controversial. Let's do that. 5. Hiding the the source path by default: I think we should as it is more newcomer friendly and in most cases I think we don't care about it (but I agree that it depends on your workflow). haskell-mode already hides it. Maybe we should have a poll on haskell-cafe or something. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12851#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Why I don't have a terribly strong opinion here one way or another, here are my thoughts, * I agree that, to a GHC developer, hiding paths by default is on the whole a small inconvenience. There is a certain convenience to pulling paths out of `ghc --make`. * I also agree that these paths are just noise to most users * However, I suspect that relatively few users are actually exposed to this noise at this point. Afterall, most users are using `stack` or `cabal-install` and both of those now hide GHC's output by default. * Even if the user uses a build tool which shows GHC's output (as `cabal- install` currently does with `-j1`), there's no reason why the tool couldn't pass `fno-show-source-paths` to GHC by default. * I really don't think the benefit-per-character-of-discussion ratio of this issue is high enough to warrant too many cycles -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12851#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:2 hsyl20]: Why exactly is this considered "more newcomer friendly" if the source-path is shown by default when directly interacting with `ghc`'s CLI? Moreover, why should we optimise `ghc` for beginners (which are beginners for a relatively short time) to the detriment of the much larger group of experienced users? Isn't it better to maximise overall benefit (c.f. [Utilitarianism](https://en.wikipedia.org/wiki/Utilitarianism)). I also don't understand how `haskell-mode` hiding the paths by default provides any justification for GHC doing the same. `haskell- mode`/`cabal`/`stack` are IDEs/frontends around GHC, and are free to control the verbosity of GHC (and they all have configuration files which can be used to change the default verbosity). But this besides the point here, as this is about `ghc`'s default UI and there's no equivalent mechanism for `ghc` (there is for `ghci` to some degree via `~/.ghci` btw) to restore the default I consider best for my workflow. In any case, I'm feeling very strong about this, and you'll have to convince me before I can accept this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12851#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
I really don't think the benefit-per-character-of-discussion ratio of
#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): this issue is high enough to warrant too many cycles I take a little offense with this statement as there were many cycles burt by haskell-mode logic tryng to filter out ghc noise, filtering too much or too little and requiring update with each new ghc version, new cabal, new stack and nix updates. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12851#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): And since we are discussion this part of GHC output, can we get a flag to disable all of progress wholesale? I have a project with 250 modules, ghci's :reload produces a couple of screenfuls of useless information. Note that errors/warnings have their location attributed anyway, which is good. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12851#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): You can already use `-v0`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12851#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2728 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => Phab:D2728 Comment: @bgamari: I use stack and it still shows GHC's output. @hvr: I think it is more newcomer friendly because I think it is noise for them. But it is also noise for me even if I am not a beginner. As in the end I can't speak for newcomers, I will be fine with any -fno-show- whatever-paths flag. Proposed patch: Phab:D2728 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12851#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2728 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari):
I take a little offense with this statement as there were many cycles burt by haskell-mode logic tryng to filter out ghc noise, filtering too much or too little and requiring update with each new ghc version, new cabal, new stack and nix updates.
Oh dear, I really didn't intend for this to be an insult to those who care about this issue. My apologies! I do understand that beginners may be overwhelmed by the volume of output that GHC can produce, I can easily believe that filtering out this noise is a non-trivial exercise, and I'm very happy that people are interested in improving the situation. What I had meant to say is that I don't really have a strong opinion in either direction; there are good arguments to be made for both defaults and there is no solution which will please all parties equally. If people want flags to disable various bits of output and they can be provided easily then let's add the flags. Sorry again for the rather careless remark and thanks for your efforts, gracjan. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12851#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12851: Regression: GHC doesn't show filepaths by default anymore
-------------------------------------+-------------------------------------
Reporter: hvr | Owner:
Type: bug | Status: patch
Priority: low | Milestone: 8.2.1
Component: Compiler | Version: 8.1
Resolution: | Keywords: regression
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): Phab:D2728
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by gracjan):
Well, my skin is thick enough for internet discussions.
I'd rather note as fact that cycles are burnt by this in multiple places
like emacs/vim/atom/vscode and hie/ghc-mod/intero, those could be burnt in
one place.
Second I think this is a very important issue to talk about and I see
pretty big benefit-per-char-of-discussion. Note that there were compilers
that boasting by readability of their output (clang), quickly followed by
their direct competition (gcc) and now high level of attention to compiler
output is an industry standard (see Elm or Rust). I'd like to thank hsyl20
for actually doing something about usability of compiler output.
Third, I think ghc is just breaking expectations here. Just try to load
Ruby, Python or C with the following code and see how much you expect:
{{{
require A
require B
require C
}}}
{{{
from A import *
from B import *
from C import *
}}}
{{{
#include
I'd rather note as fact that cycles are burnt by this in multiple places
#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2728 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): like emacs/vim/atom/vscode and hie/ghc-mod/intero, those could be burnt in one place. This is a fair point.
Third, I think ghc is just breaking expectations here. Just try to load Ruby, Python or C with the following code and see how much you expect:
...
I'm not entirely sure this is an apples-to-apples comparison though. Python and Ruby are both interpreted languages with no real compile-/run- time phase distinction and certainly no "batch" compilation. In the case of C++ you rarely invoke the compiler itself; instead you typically invoke it via some build system, most of which do provide per- module feedback on progress. The same holds for most Scala and Java build systems, as far as I know. Of course, none of this is to say we shouldn't reconsider our output. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12851#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#12851: Regression: GHC doesn't show filepaths by default anymore
-------------------------------------+-------------------------------------
Reporter: hvr | Owner:
Type: bug | Status: patch
Priority: low | Milestone: 8.2.1
Component: Compiler | Version: 8.1
Resolution: | Keywords: regression
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): Phab:D2728
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by Ben Gamari
#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: regression Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2728 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: I believe the above should resolve this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12851#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC