Opened 4 years ago

Last modified 4 years ago

#11069 new bug

:cd in GHCi unloads modules

Reported by: mgsloan Owned by:
Priority: low Milestone:
Component: GHCi Version: 7.10.2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Other Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

If I run stack ghci in the stack repo, and then use :cd, I get the following:

Warning: changing directory causes all loaded modules to be unloaded, because the search path has changed.

And, indeed, all modules are unloaded. What's particularly strange about this is that in my case all of the paths provided on the commandline are absolute. Here's the output of ":show paths":

current working directory:

/home/mgsloan/fpco/stack

module import search paths:

/home/mgsloan/fpco/stack/src

/home/mgsloan/fpco/stack/.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/autogen

/home/mgsloan/fpco/stack/.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build

/home/mgsloan/fpco/stack/src/main

How about removing any dependency in GHC on the current working directory, and instead store it when the session is initialized?

This is also necessary if we want to support per-package working directories, details here.

Change History (3)

comment:1 Changed 4 years ago by thomie

How about removing any dependency in GHC on the current working directory, and instead store it when the session is initialized?

Go ahead. GHCi is just as unmaintained as hpc, so it's all yours to fix.

comment:2 in reply to:  1 Changed 4 years ago by goldfire

Replying to thomie:

How about removing any dependency in GHC on the current working directory, and instead store it when the session is initialized?

Go ahead. GHCi is just as unmaintained as hpc, so it's all yours to fix.

Whoa. I don't think of GHCi as unmaintained. The debugger in GHCi is regrettably unmaintained. But the rest of it gets active work, no?

And I don't agree with the proposed change. I may be an exception to the normal Haskell workflow, but I do most of my work in GHCi without reference to a cabalized package. (Usually, I'm just testing different constructs, not building a project intended for release.) I use :cd and expect it to change my working directory used for finding modules. If I understand correctly, the proposed change would eliminate this workflow. (I do find it annoying that all my modules get unloaded when I move directories, as that's not always my intent.)

So I think a bit of a larger discussion is in order before making this breaking change.

comment:3 Changed 4 years ago by mgsloan

My understanding is that it's unloading the objects because relative paths are being used within GHC. This issue seems relevant, but Simon's commit message "we should virtualise the CWD inside the GHC API, not in the client" suggests to me that we'd prefer that GHC not care about CWD.

To me, the ideal resolution is to use absolute paths within GHC, but perhaps this is a tall order. For example, :load would convert relative paths to absolute. Then, modules don't need to be unloaded for :cd to work.

An alternative solution for my particular case would be to have :cd not unload the modules if all of the search paths are absolute. This is the case when ghci is run by stack ghci, and probably when it's run by cabal repl as well.

Note: See TracTickets for help on using tickets.