Some warnings are irrelevant in ghci, as an example:

-O conflicts with --interactive; -O ignored.

Produced by adding to the top of a file:

{-# OPTIONS_GHC -O2 #-}

I have a test suite which I can run inside of cabal repl test, with a simple main call.

Is there an existing way to make the test suite run every time I write a file?

Due to some circumstance, my project doesn't reload properly with :reload. I need to write :load app/Main.hs for it to work properly. It would be nice if we could provide a custom reload command.

There are certain classes of errors where the error points immediately to the solution. Certain language extensions are easy to turn on and obvious when required, and for certain functions you know where they live and could add an import. I'm particularly interested in cases where currently I have to go to the top of the file, as that's annoying and breaks my flow, and is usually just boilerplate. (It goes without saying, this would have to be opt-in.) Some examples of errors we could catch:

Illegal `..' in record pattern
Use -XRecordWildCards to permit this

Or:

Not in scope: `when'

Or:

The import of `Data.List' is redundant
  except perhaps to import instances from `Data.List'
To import instances alone, use: import Data.List()

Loading ghci foo.hs...

Should add a space before the ... - more consistent with what ghci does, and if you do -i.. it doesn't look crazy.

When I use ghcid I often want to know if my cabal file's executable entries will compile in addition to knowing whether library modules do. Right now, since ghcid doesn't check those, I run cabal install or similar after ghcid ceases to report errors in order to check my entire package. Would it be possible to make ghcid check my programs as well? (Without running them, of course.)

Given:

module A where
import Data.List
import B
a = b

module B where
import Data.Maybe
b = 1

Running with warnings, if you save A.hs or B.hs then the order of warnings switches. Should I warn based on module load list order?

On Unix at least it should be possible to find out the height of the terminal window ghcid is running in automatically by using some terminal capabilities library.

Appveyor currently fails using GHC 7.10.3 on Windows with the error:

  Exception: waitForProcess: invalid argument (Bad file descriptor)

I worked around that with 2136e32, but it would be good to get to the source.

I think because this error message isn't associated with a place, so is parsed incorrectly.

Loading Shake with ghci -fno-code is a big win - I load in 3.61s instead of 5.55s, and working set memory is 130Mb instead of 200Mb. The downside is that you can't actually execute code. In general most .ghci files won't execute code, but they potentially can. The test command if present will almost certainly execute code. Therefore I suggest we:

• Add -fno-code by default, unless:
  • Either: The user passes --code or some similar flag.
  • Or: the user passes a --test expression.

Compare:

src\Idea.hs:8:1: Warning:
    The import of `Control.Arrow' is redundant

And:

src\Idea.hs:8:8:
    Could not find module `Control.ArrowX'
    Perhaps you meant Control.Arrow (from base-4.8.1.0)
    Use -v to see a list of the files searched for.

Would be nice if the second said Error explicitly, as suggested in #59 by @rvion.

If I never get the prompt I was hoping for then give a nice error message, don't just fail.

suppose i change my cabal file (or similarly when my package.yaml changes, which will generate a new cabal file when stack runs); can ghcid rerun then? would this be a bad idea for any reason?

ghcid exited unexpectedly:

 ghcid: somefile.hs: getFileStatus: does not exist (No such file or directory)

Happened twice but I am not able to reproduce it (both times editing the file with Vim).

Putting the file name in bold would make it easier to pick out the key bits. Perhaps the warnings/errors in different colors too. Using the ansi-terminal package here probably makes sense.

It would seem that ghcid is truncating error messages to 3 (?) lines. That's somewhat counter to what I was used to. I can imagine why you did it (sometimes you want to see all the errors, not just the first one) but I find myself having to ^C, run stack build manually to see the full error, then back to ghcid.

Am I missing something?

AfC

minor help text improvement suggestion:

current:

     --reload=FILE      Reload if any of these files change (defaults to
                        none)
     --restart=FILE     Restart the command if any of these files change
                        (defaults to .ghci or .cabal)

suggestion:

• replace FILE by PATH
• replace (defaults to .ghci or .cabal) by (defaults to .ghci and .cabal)
• replace any of these files (that let one think that we can pass several files space separated using shell expansion) by something like given file or folder files or { given file | files in given folder } (no strong opinion on specific wording, but current one seems to imply I can pass --reload="foo foro/bar baz" which doesn't work

     --reload=PATH      Reload when { given file | files in given folder } change (defaults to
                        none)
     --restart=PATH     Restart the command when given file or folder files change
                        (defaults to .ghci and .cabal)

Start a project, load some files, delete one. Watch the system continually reload. A special case of #1.

Equivalent to watching every file in that directory

I would like an optional flag like --output-file somefile which would be written each time ghcid recompiles the program and would have the same information as the one displayed by ghcid. That way I could watch that file and invoke other utilities on successful compilation.

See https://www.reddit.com/r/haskell/comments/3bqy5h/survey_which_haskell_development_tools_are_you/csqxz2s for the full details. They have a .ghci with:

:set -fbreak-on-exception
:set -fbreak-on-error

Ghcid raises an error to flush its buffers. It should turn off those flags.

@ndmitchell I have a problem with ghcid 0.6.1

*It is currently impossible to start ghcid so it reloads my code when some .hs file change in my multi-package project

I use stack, I have a set of ~10 packages within one same folder.
All of them have a src folder containing module tree (Foo.hs, Foo/Bar.hs, etc.)
I have one empty package at the top level importing all other packages to simplify compatibility with cabal specific stuff (like haskell-ide-atom).

• default doesn't work

  ghcid --> never reload when any file changes

  (this is probably a bug 🐛 related to this message printed in ghci: )

  * * * * * * * *
  The main module to load is ambiguous. Candidates are:
  1. Package `app' component exe:app-example with main-is file: /Users/rvion/dev/cogito/app/Main.hs
  2. Package `pghs' component exe:pg2hs with main-is file: /Users/rvion/dev/cogito/pghs/Main.hs
  You can specify which one to pick by:
   * Specifying targets to stack ghci e.g. stack ghci app:exe:app-example
  Specify main module to use (press enter to load none): Not loading any main modules, as no valid     module selected
   * Specifying what the main is e.g. stack ghci --main-is app:exe:app-example
  
   * Choosing from the candidate above [1..2]
  * * * * * * * *
  

• command to load top level package doesn't work because it doesn't watch local deps change

  `ghcid -c "stack ghci toplevelpackage"

• one reload param with list of file doesn't watch

  ghcid --test="testFunction" --reload="**/*.hs" -> loop weirdly because of "*/.hs"

• one --reload per folder doesn't work because no recursivity

  ghcid --reload pkg1 --reload pkg2 --> never reload when pkg1/src/*/.hs change because only watch for pkg1/* (direct folder, no recursive)

So far: the only 2 solutions I thought about were

1. make a giant cmd like

   ghcid ... \
      --reload pkg1/src/ \
      --reload pkg1/src/Foo \
      --reload pkg1/src/Foo/Bar \
   
      --reload pkg2/src/ \
     -- ...

   possible partial workaround:

   ghcid  $(ls **/*.hs | while read -r line; do dirname "$line"; done | uniq | sed 's/^/--reload=/' | tr '\n' ' ' | sed 's/ $//g')

2. start one ghcid cmd per package

I went with (1) but then I found a bug 🐛 in ghcid:

ghcid --reload=pkg1/src/

doens't reload anything unless I'm specifying a target.
since I have several executables, not specifying a target shows

* * * * * * * *
The main module to load is ambiguous. Candidates are:
1. Package `app' component exe:app-example with main-is file: /Users/rvion/dev/cogito/app/Main.hs
2. Package `pghs' component exe:pg2hs with main-is file: /Users/rvion/dev/cogito/pghs/Main.hs
You can specify which one to pick by:
 * Specifying targets to stack ghci e.g. stack ghci app:exe:app-example
Specify main module to use (press enter to load none): Not loading any main modules, as no valid module selected
 * Specifying what the main is e.g. stack ghci --main-is app:exe:app-example

 * Choosing from the candidate above [1..2]
* * * * * * * *

and then no reload occurs at all

so I did

ghcid -c "stack ghci toplevelpackage" --reload=pkg1/src/ --reload=pkg1/src/Foo --reload=...

but arg again: ghci don't reload files in pkg1 since I specified toplevelpackage. so toplevelpackage reload when I change pkg1, but it doesn't pick changes in pkg1

Otherwise, great project ! Thanks

I'm in a hurry, so I'm afraid this won't have much detail.
When either using -XNoImplicitPrelude or import Prelude (a, few, functions), ghcid gets stuck.

@fegu suggests that instead of All good the tool should say something like:

All good
   Press R to reload
   Press P to pause
   Press B to build
   Press H to HLint

I am particularly keen on the R option, which would kill ghci and restart from scratch, as it provides some workaround for #7, especially if you are using cabal repl and change the .cabal file. The P option would also be useful when I'm on a train, at the moment ghcid sucks my battery flat in about the duration of my train ride, sometimes slightly sooner.

On iterm2/3 (osx)

• one can Cmd+click on filepaths to open the file in any editor at the right line/column. Sublime and atom even find the best window to reuse to open the file (the window where the project containing the file is open by default)

• one can configure specific triggers:

to color the text for instance:

While editing a file with Vim, ghcid -v reports:

%WAITING: GHCidTest.hs

Reloading...
  GHCidTest.hs
%GHCINP: :reload
%GHCERR: 
%GHCERR: <no location info>: can't find file: GHCidTest.hs
%GHCOUT: #~GHCID-START~##~GHCID-START~#Failed, modules loaded: none.
%GHCOUT: #~GHCID-START~##~GHCID-FINISH~#
%GHCERR: *** Exception: #~GHCID-FINISH~#
%GHCINP: :show modules
%GHCOUT: #~GHCID-START~##~GHCID-START~##~GHCID-START~##~GHCID-FINISH~#
%GHCERR: *** Exception: #~GHCID-FINISH~#
%ACTIVE: []
%LOAD: []

All good

%WAITING: 

It only happens with Vim, not with other editors, and only after a few edits have been made (and for which ghcid did report errors and warnings correctly). I'm not sure it's a ghcid bug, it might be something specific to my system.

See also #21.

I'm using version 0.3.2 and the command ghcid --command='ghci GHCidTest.hs' on Ubuntu Linux.

It would make the window smaller and less intrusive.

Unfortunately our work to reduce wakeups in #27 doesn't work when the editor is vi[m]. ghcid errors out with:

src/MostExcellentProgram.hs: Can't find file

the moment the source file in question is updated. Bummer.

When saving, some editors — like vi — write out a new file, then delete the original one and atomically move the replacement to the original's name (this avoids an interrupted write from leaving a corrupt half empty file).

The particular set of inotify(7) flags I used in my original branch at #27 were specifically chosen to accommodate this case ("deleted", "closed write" in addition to "modified").

Since you've adopted fsnotify, we'll need to work out what the equivalent trick will be with that wrapper. At present ghcid is unusable, unfortunately.

AfC

Sometimes the lines exceed the length of the console, then the useful messages are pushed off the screen after a wrap. We should either truncate long lines, or account for their size properly.

If I start ghcid without arguments it scrolls to just below the line src/Handlers.hs:19:52: (or the line an error is found at). So I can see the warning but not the line info which makes the default pretty useless. If I specify the height manually it works just fine.

The test suite should cover more cases, and be run on each commit via Travis.

stack unfortunately (or fortunately) is yet another tool projects can be built with. I believe it deprecates cabal sandboxes and cabal install entirely. A stack-based project can jump into a ghci session with stack ghci.

Using 6.0.1. I have a stack project with extra projects linked to it through the packages flag in stack.yaml. I run the repl with stack repl my-main-project so I've provided that in the --command flag.

The problem is I don't see any errors. I see All good (10 modules) and when I introduce an error I see All good (9 modules) without any messages.

powertop(8) on Linux reports the most expensive process in terms of processor wakups is ghcid.

     Usage     Events/s     Category       Description
  4.5 ms/s     108.8        Process        ghcid --command=cabal exec ghci tests/Experiment.hs

this represents about a quarter of the user-space power draw on this machine when on battery!

Originally I thought you were using inotify(7) so assumed that it wouldn't be doing any wakeups at all. When I saw it sucking down power like this, I had a look and just realized you're not using hnotify. Oh.

Is that deliberate? Assuming not, would you countenance a dependency on fsnotify (which purports to be a cross-platform wrapper around the different filesystem notification mechanisms)?

AfC

i'm not entirely sure if this is the job of ghcid, but i'm using the NoImplicitPrelude extension, and thus my ghcid command starts off like ...:

ghcid --command="stack ghci --ghci-options -XNoImplicitPrelude ...

it'll get more crazy as i care about more extensions. but shouldn't we just be able to load with the extensions that are found in the cabal file? am i missing some reason that this isn't a good idea?

when ghc(i) outputs an error message

src/Matchbox/Automaton/Plain.hs:180:27: error:
    • Variable not in scope:
        domainL
          :: R.Rel p q (Path q1)
             -> t0 containers-0.5.7.1:Data.IntSet.Base.Key

then ghcid does not show the name:

src/Matchbox/Automaton/Plain.hs:180:27: error:
    • Variable not in scope:
src/Matchbox/Relation.hs:103:1: warning:

I guess this is because of the extra line break, because it works if the error message is like this

src/Matchbox/Automaton/Plain.hs:49:31: error:
    • Variable not in scope: auto :: Aut Q c0 (Path Q)

then ghcid handles this fine.

I think haskell-mod has the same problem. The extra line break could be flagged as a bug (misfeature) in ghc?

I have the following lines in my ~/.ghci:

:set -package pretty-show
:set -package hscolour

With those two lines present, when I :reload in ghci no message is printed, and ghcid then bails out because it can't detect any reloaded files.

Is this perhaps a problem that needs to reported upstream to GHC?

When I delete the file being monitored, or if it didn't exist to begin with, ghcid always reports "All good". This is confusing, because it hides the fact something is probably wrong.

I'm using version 0.3.2 and the command ghcid --command='ghci GHCidTest.hs' on Ubuntu Linux.

Prelude.hs

module Prelude where

A.hs

module A where

Situation 1 Structure:

./Prelude.hs
./A.hs
./.ghci

where ./.ghci is

:load A

Situation 2 Structure:

src/Prelude.hs
src/A.hs
./.ghci

where ./.ghci is

:set -isrc
:load A

Running ghcid in situation 1 gives: ghcid.exe: UnexpectedExit "ghci" ""

Running ghcid in situation 2 gets stuck in Loading... forever

When loading from a .ghci file, if the .ghci file changes, the GHCi session should exit and be restarted.

Could have Red for failure, Green for success, Yellow for warnings.

When reloading it displays Reloading.... The initial load should get a similar Loading....

Following #42, now that I show the full output, the import warnings are excessive and unhelpful:

src\General\BigString.hs:6:1: Warning:
    The import of `Data.Time.Clock' is redundant
      except perhaps to import instances from `Data.Time.Clock'
    To import instances alone, use: import Data.Time.Clock()

The last two lines are very low information density. I should special case them and remove them.

ghcid -V prints

Auto :reload'ing GHCi daemon

This is with ghcid 0.2 installed in a cabal sandbox.

Seems to have started around the time I switched to the filesystem watcher. Not sure what's going on. Not all the time, but it certainly fails some of the time.

Running ghcid -v in a project with an (artificial) compile error produces:

%GHCINP: 
%GHCERR: Warning: The package list for the local repo
%GHCERR: '/Users/sk/projects/samplecount/shake-language-c/.cabal-sandbox/packages' is
%GHCERR: missing. The repo is invalid.
%GHCOUT: Preprocessing library shake-language-c-0.6.0...
%GHCOUT: [16 of 19] Compiling Development.Shake.Language.C.Rules ( Development/Shake/Language/C/Rules.hs, dist/build/Development/Shake/Language/C/Rules.o )
%GHCERR: 
%GHCERR: Development/Shake/Language/C/Rules.hs:91:15:
%GHCERR:     Not in scope: ‘ToolCain.defaultBuildFlags’
%GHCERR:     Perhaps you meant ‘ToolChain.defaultBuildFlags’ (imported from Development.Shake.Language.C.ToolChain)
ghcid: UnexpectedExit "cabal repl" ""

This is with ghcid 0.2 installed in a cabal sandbox.

I'm thinking which directory you are in, whether it is errors, warnings, passing etc.

It just took me the better part of an hour to remember how to use this. I tried

$ ghcid
$ cabal exec ghcid
$ ghcid tests/Experiment.hs

and many variations. You get the idea, I'm sure. What worked in the end was this:

$ ghcid --command="cabal exec ghci tests/Experiment.hs"

which, I think you'd agree, is a mouthful.

It would be nice if

a) ghcid was cabal sandbox aware, automatically using cabal exec to get into ghci [I gather it's a no-op in the absence of a sandbox, so perhaps that's viable as a default]

b) ghcid took an argument to be interpreted as a filename [or cabal repl target?] to be what is :loaded.

Am I totally missing the plot here? I know you can have a .ghci file with commands in it, but that doesn't seem to be so great when you're quickly trying to build and test lots of different snippet test prorams.

AfC

ghcid is the quickest way for me to test my code, faster than cabal test and stack test. I'd like to use ghcid in a pre-commit hook but ghcid doesn't support a oneshot mode as far as I understand it.

Simply using echo test | cabal repl doesn't work for me because cabal repl's return codes aren't meaningful.