#12851 closed bug (fixed)

Regression: GHC doesn't show filepaths by default anymore

Reported by: hvr Owned by:
Priority: low Milestone: 8.2.1
Component: Compiler Version: 8.1
Keywords: regression Cc:
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:

Description

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.

Change History (13)

comment:1 Changed 12 months ago 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 a new flag with such low marginal utility and just use the existing verbosity level for this purpose.

Last edited 12 months ago by gracjan (previous) (diff)

comment:2 Changed 12 months ago 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.

  1. 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).
  1. 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.
  1. Hiding the object path by default: it doesn't seem controversial. Let's do that.
  1. 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.

comment:3 Changed 12 months ago 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

comment:4 in reply to:  2 Changed 12 months ago by hvr

Replying to hsyl20:

Why exactly is this considered "more newcomer friendly" if the source-file path is hidden 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).

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 why I should suffer this regression before I can accept this.

Last edited 12 months ago by hvr (previous) (diff)

comment:5 Changed 12 months ago by gracjan

I really don't think the benefit-per-character-of-discussion ratio of 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.

comment:6 Changed 12 months ago 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.

comment:7 Changed 12 months ago by mpickering

You can already use -v0.

comment:8 Changed 12 months ago by hsyl20

Differential Rev(s): Phab:D2728
Status: newpatch

@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

comment:9 Changed 12 months ago 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.

comment:10 Changed 12 months ago 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 <a.h>
#include <b.h>
#include <c.h>

There will be no output from these, unless you request extra verbosity to trace this functionality. GHC is an outlier.

comment:11 Changed 12 months ago by bgamari

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.

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.

comment:12 Changed 12 months ago by Ben Gamari <ben@…>

In 3ec85630/ghc:

Replace -fshow-source-paths with -fhide-source-paths

This patch reverts the change introduced with
587dcccfdfa7a319e27300a4f3885071060b1f8e and restores the previous
default output of GHC (i.e., show source path and object path for each
compiled module).

The -fhide-source-paths flag can be used to hide these paths and reduce
the line
noise.

Reviewers: gracjan, nomeata, austin, bgamari, simonmar, hvr

Reviewed By: hvr

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D2728

GHC Trac Issues: #12851

comment:13 Changed 12 months ago by bgamari

Resolution: fixed
Status: patchclosed

I believe the above should resolve this.

Note: See TracTickets for help on using tickets.