New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

'stack ghci' doesn't notice that a module got deleted #1180

Closed
borsboom opened this Issue Oct 17, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@borsboom
Contributor

borsboom commented Oct 17, 2015

If you remove a module and then run stack ghci before stack build, it fails with a Could not find module error.

Hypothesis:

The build doesn't run before stack ghci reads the modules, so it doesn't get a chance to re-write the .dump-hi files with the updated information (that the module does not exist), so stack ghci is still reading the out-of-date information.

Notes from @chrisdone:

as a heads up the stack ghci code uses the build info, but runs the equiv. of stack build —only-dependencies to ensure that dependencies are available
at a guess, it seems that the build cache doesn’t get invalidated by simply reading it in the manner that stack ghci does, but i didn’t get niklas to test with stack build to see if running that would trigger a cache invalidation
the building with —only-dependencies was enabled to avoid ghci not being able to start when there’s a build error. i don’t like that fix, i’d prefer if the build just ran and if it fails then it should catch the exception and print the compile error but still launch ghci anyway in an optimistic way (edited)

It's likely that fixing #1065 will also fix this, but tracking separately since the symptoms are different.

(PAT-125)

@borsboom borsboom added the type: bug label Oct 17, 2015

@borsboom borsboom self-assigned this Oct 17, 2015

@borsboom borsboom added this to the P1: Must milestone Oct 17, 2015

@borsboom borsboom changed the title from stack doesn't notice that a module got deleted to 'stack ghci' doesn't notice that a module got deleted Oct 17, 2015

borsboom added a commit that referenced this issue Oct 25, 2015

'stack ghci': build project before launching GHCi (closes #1065, fixes
…#1180)

Optimistically, launch GHCi anyway even if the build fails.

borsboom added a commit that referenced this issue Oct 29, 2015

'stack ghci': build project before launching GHCi (closes #1065, fixes
…#1180)

Optimistically, launch GHCi anyway even if the build fails.

borsboom added a commit that referenced this issue Oct 31, 2015

'stack ghci': build project before launching GHCi (closes #1065, fixes
…#1180)

Optimistically, launch GHCi anyway even if the build fails.
@chreekat

This comment has been minimized.

Contributor

chreekat commented Oct 31, 2015

In general stack ghci doesn't seem to like it when modules come and go. I often get "panic: the "impossible" happened!" when stack ghci is running and I try adding or deleting modules.

Maybe that's to be expected (? I don't know how stack ghci interacts with cabal really) but it's still annoying.

@borsboom borsboom removed the in progress label Oct 31, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Oct 31, 2015

@chreekat is that Stack-specific? As I understand it (but I'm not much of a GHCi user), once you're actually in the GHCi interpreter, Stack has fully passed control to it and is no longer involved at all.

This particular issue was about the list of modules that was passed to GHCi on startup, and should now be fixed on master.

@chreekat

This comment has been minimized.

Contributor

chreekat commented Oct 31, 2015

@borsboom probably not stack-specific, in fact. :)

mgsloan added a commit that referenced this issue Jul 7, 2018

'stack ghci' now asks which main module to load before building
Before this change, 'stack ghci' would ask the user a question after doing a
build which may take a long time. The reason it was this way is that the
question required resolution of package files, and package file resolution
needed to come after the build due to #1180.

The solution here is to resolve the package files twice - once before the build
- and once after. This isn't the most efficient solution possible, but it is a
much better user experience to ask the main target question before building
rather than after.

mgsloan added a commit that referenced this issue Jul 7, 2018

'stack ghci' now asks which main module to load before building
Before this change, 'stack ghci' would ask the user a question after doing a
build which may take a long time. The reason it was this way is that the
question required resolution of package files, and package file resolution
needed to come after the build due to #1180.

The solution here is to resolve the package files twice - once before the build
- and once after. This isn't the most efficient solution possible, but it is a
much better user experience to ask the main target question before building
rather than after.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment