Make default output less verbose (source/object paths)
ClosedPublic

Authored by hsyl20 on Nov 4 2016, 4:32 PM.

Diff Detail

Repository
rGHC Glasgow Haskell Compiler
Branch
ghc-less-verbose
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 11759
Build 14853: [GHC] Linux/amd64: Patch building
Build 14852: arc lint + arc unit
hsyl20 updated this revision to Diff 9300.Nov 4 2016, 4:32 PM
hsyl20 retitled this revision from to Make default output less verbose (source/object paths).
hsyl20 updated this object.
hsyl20 edited the test plan for this revision. (Show Details)
hsyl20 updated the Trac tickets for this revision.
hsyl20 updated this revision to Diff 9302.Nov 4 2016, 7:46 PM
hsyl20 edited edge metadata.
  • Add -fshow-module-paths flag
hsyl20 updated this revision to Diff 9303.Nov 4 2016, 8:59 PM
hsyl20 edited edge metadata.
  • Try to fix T12567a manually (doesn't support "accept")
nomeata added a subscriber: nomeata.Nov 5 2016, 9:23 AM
nomeata added inline comments.
compiler/main/DynFlags.hs
394

Maybe ShowFilePaths? Modules themselves do not really have a path.

mpickering requested changes to this revision.Nov 5 2016, 5:20 PM
mpickering added a reviewer: mpickering.
mpickering added a subscriber: mpickering.

One of the tests is still failing. Please could you look?

This revision now requires changes to proceed.Nov 5 2016, 5:20 PM
simonmar edited edge metadata.Nov 7 2016, 2:43 AM

No objection to this change, but just a related comment: in general, it would be great if everywhere we test verbosity there was an associated flag, and each verbosity level were equivalent to a collection of flags, just like -O.

hsyl20 updated this revision to Diff 9331.Nov 7 2016, 1:46 PM
hsyl20 edited edge metadata.
  • Fix T12567a
hsyl20 added a comment.Nov 7 2016, 2:03 PM

@mpickering: The failing test should be fixed now.

@nomeata: I first named the flag -fshow-file-paths but I thought it was too general (could be package files, config files, library files, etc.). Modules don't really have paths but the latter are shown when modules are compiled (and from the showModMsg function) so it was the most descriptive name I came up with. Maybe we should have both -fshow-source-paths and -fshow-object-paths.

@simonmar: do you think it is worth creating a specific ticket for this (as a newcomer task maybe)?

I like -fshow-source-paths. The slight imprecision that it also affects object files when printed next to source file names is fine with me.

do you think it is worth creating a specific ticket for this (as a newcomer task maybe)?

Yes. And maybe all the verbosity flags should begin with -v, e.g. -vshow-file-paths?

bgamari edited edge metadata.Nov 8 2016, 9:28 AM
do you think it is worth creating a specific ticket for this (as a newcomer task maybe)?

Yes. And maybe all the verbosity flags should begin with -v, e.g. -vshow-file-paths?

Indeed, There isn't a lot of precedent that I can think of in compilers using -v this way, but it feels more reasonable than overloading -f for this.

hsyl20 updated this revision to Diff 9345.Nov 9 2016, 6:34 AM
hsyl20 edited edge metadata.
  • Change flag name to -fshow-source-paths
bgamari accepted this revision.Nov 10 2016, 2:19 PM
bgamari edited edge metadata.

This looks reasonable to me. I don't want to bike-shed about the flag name for eternity. Anyone else have any final requests?

I have added a ticket so that we don't forget to homogenize verbosity flags: Trac #12822

This revision was automatically updated to reflect the committed changes.

Hmm, sorry for jumping in the middle of discussion at this last moment. I just wanted to tell you than in haskell-mode in Emacs we filter out everything after module name, so it looks like this:

[1 of 3] Compiling SH_Overlap4_B
[2 of 3] Compiling SH_Overlap4_A
[3 of 3] Compiling SH_Overlap4

Now, for debugging purposes I sometimes needed the path information. It was useful for a multiplatform setup where I had two T modules, one in posix/T.hs and other in windows/T.hs. Path information was useful to check if correct module was loaded this time.

After you remove the path what is left is just three cases:

[1 of 3] Compiling A               (.hs -> nothing)
[2 of 3] Compiling B               (.hs -> .o)
[3 of 3] Compiling C[sig]          (.hsig -> nothing)

Note that 1. and 2. informs if module is compiled or interpreted (I guess, I'm not sure). Case 3. is redundant because it says sig two times.

To sum it up:

  • path info is useful in cases where configuration uses directories for functionality switching
  • interpreted vs compiled is arguably not that useful, I have never needed this info
  • there are tools already to filter out this whole information

I'd like to propose to have the functionality work as follows:

In non-verbose mode:

[1 of 3] Compiling SH_Overlap4_B

In verbose mode:

[1 of 3] Compiling SH_Overlap4_B  ( windows/SH_Overlap4_B.hs, dist/build/output/SH_Overlap4_B.o )

You may also consider not adding a flag with such marginal utility and just use current verbosity setting.

Just .02$ about how this works in haskell-mode.

interpreted vs compiled is arguably not that useful, I have never needed this info

Just as another data point, I find that info *very* useful :)

What do you use this information for? How do you use it?

interpreted vs compiled is arguably not that useful, I have never needed this info

Just as another data point, I find that info *very* useful :)

Me too, although mostly when working with ghc-vis which works better with compiled code.

To tell whether GHCi is picking up .o files for a module, or falling back to interpreting. Particularly if you're using :set -fobject-code, or if you've compiled the project in the past and you want to know whether GHCi is using the compiled artifacts.