You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The issue is that code loaded into ghci is treated as if it comes from the main package. This can cause unexpected issues! For example, if stack ghci is used to run stack, it will invalidate the binary caches stored by the compiled version.
Another issue is that TypeHash is sensitive to changes in the TH API. For the original usecase, this was fine, but for the usecase in stack, this isn't so good. It means that stack built with ghc-7.8 will invalidate the caches stored by stack built with ghc-7.10. Rather inconvenient!
I have changes in progress addressing both of these, I'm mostly writing this to document the existence of the issue.
One nice side effect of this is that the store instances for TH AST types can get dropped from the package. They add quite a bit to the compile time.
The text was updated successfully, but these errors were encountered:
The issue is that code loaded into
ghci
is treated as if it comes from themain
package. This can cause unexpected issues! For example, ifstack ghci
is used to run stack, it will invalidate the binary caches stored by the compiled version.Another issue is that
TypeHash
is sensitive to changes in the TH API. For the original usecase, this was fine, but for the usecase instack
, this isn't so good. It means thatstack
built withghc-7.8
will invalidate the caches stored bystack
built withghc-7.10
. Rather inconvenient!I have changes in progress addressing both of these, I'm mostly writing this to document the existence of the issue.
One nice side effect of this is that the
store
instances for TH AST types can get dropped from the package. They add quite a bit to the compile time.The text was updated successfully, but these errors were encountered: