Conflicting exports for ‘&’ during installation

[dmitriz]

Trying to install with cabal leads to some conflicting exports breaking the installation:

cabal v2-build    
Build profile: -w ghc-8.0.1 -O1
In order, the following will be built (use -v for more details):
 - ptghci-0.1.0.0 (lib) (first run)
 - ptghci-0.1.0.0 (exe:ptghci) (first run)
Preprocessing library for ptghci-0.1.0.0..
Building library for ptghci-0.1.0.0..
[ 7 of 19] Compiling Language.Haskell.PtGhci.Prelude ( src/Language/Haskell/PtGhci/Prelude.hs, /Users/dmitrizaitsev/Repos/ptghci/dist-newstyle/build/x86_64-osx/ghc-8.0.1/ptghci-0.1.0.0/build/Language/Haskell/PtGhci/Prelude.o )

src/Language/Haskell/PtGhci/Prelude.hs:4:5: error:
    Conflicting exports for ‘&’:
       ‘module MicroLens’ exports ‘MicroLens.&’
         imported from ‘Lens.Micro’ at src/Language/Haskell/PtGhci/Prelude.hs:12:1-30
         (and originally defined in ‘Data.Function’)
       ‘module P’ exports ‘P.&’
         imported qualified from ‘Protolude’ at src/Language/Haskell/PtGhci/Prelude.hs:13:1-31
cabal: Failed to build ptghci-0.1.0.0 (which is required by exe:ptghci from
ptghci-0.1.0.0).

[dmitriz]

Changing to import Lens.Micro as MicroLens hiding ((&)) in src/Language/Haskell/PtGhci/Prelude.hs seems to fix that error but there is now this new one:

➜  ptghci git:(cabal) ✗ cabal v2-build
Build profile: -w ghc-8.0.1 -O1
In order, the following will be built (use -v for more details):
 - ptghci-0.1.0.0 (lib) (first run)
 - ptghci-0.1.0.0 (exe:ptghci) (first run)
Preprocessing library for ptghci-0.1.0.0..
Building library for ptghci-0.1.0.0..
[ 7 of 19] Compiling Language.Haskell.PtGhci.Prelude ( src/Language/Haskell/PtGhci/Prelude.hs, /Users/dmitrizaitsev/Repos/ptghci/dist-newstyle/build/x86_64-osx/ghc-8.0.1/ptghci-0.1.0.0/build/Language/Haskell/PtGhci/Prelude.o )
[ 8 of 19] Compiling Language.Haskell.PtGhci.Exception ( src/Language/Haskell/PtGhci/Exception.hs, /Users/dmitrizaitsev/Repos/ptghci/dist-newstyle/build/x86_64-osx/ghc-8.0.1/ptghci-0.1.0.0/build/Language/Haskell/PtGhci/Exception.o ) [Language.Haskell.PtGhci.Prelude changed]
[ 9 of 19] Compiling Language.Haskell.PtGhci.PtgRequest ( src/Language/Haskell/PtGhci/PtgRequest.hs, /Users/dmitrizaitsev/Repos/ptghci/dist-newstyle/build/x86_64-osx/ghc-8.0.1/ptghci-0.1.0.0/build/Language/Haskell/PtGhci/PtgRequest.o ) [Language.Haskell.PtGhci.Prelude changed]
[10 of 19] Compiling Language.Haskell.PtGhci.Config ( src/Language/Haskell/PtGhci/Config.hs, /Users/dmitrizaitsev/Repos/ptghci/dist-newstyle/build/x86_64-osx/ghc-8.0.1/ptghci-0.1.0.0/build/Language/Haskell/PtGhci/Config.o ) [Language.Haskell.PtGhci.Exception changed]
[11 of 19] Compiling Language.Haskell.PtGhci.Env ( src/Language/Haskell/PtGhci/Env.hs, /Users/dmitrizaitsev/Repos/ptghci/dist-newstyle/build/x86_64-osx/ghc-8.0.1/ptghci-0.1.0.0/build/Language/Haskell/PtGhci/Env.o ) [Language.Haskell.PtGhci.Exception changed]
[12 of 19] Compiling Language.Haskell.PtGhci.WebBrowser ( src/Language/Haskell/PtGhci/WebBrowser.hs, /Users/dmitrizaitsev/Repos/ptghci/dist-newstyle/build/x86_64-osx/ghc-8.0.1/ptghci-0.1.0.0/build/Language/Haskell/PtGhci/WebBrowser.o )
[13 of 19] Compiling Language.Haskell.PtGhci.Log ( src/Language/Haskell/PtGhci/Log.hs, /Users/dmitrizaitsev/Repos/ptghci/dist-newstyle/build/x86_64-osx/ghc-8.0.1/ptghci-0.1.0.0/build/Language/Haskell/PtGhci/Log.o )

src/Language/Haskell/PtGhci/Log.hs:16:28: error:
    • Variable not in scope: hPutStrLn :: Handle -> Text -> IO a0
    • Perhaps you meant ‘putStrLn’ (imported from Language.Haskell.PtGhci.Prelude)
      Perhaps you want to add ‘hPutStrLn’ to the import list
      in the import of ‘System.IO’
      (src/Language/Haskell/PtGhci/Log.hs:6:1-25).

src/Language/Haskell/PtGhci/Log.hs:33:35: error:
    Variable not in scope: displayException :: e -> String
cabal: Failed to build ptghci-0.1.0.0 (which is required by exe:ptghci from
ptghci-0.1.0.0).

[dmitriz]

Going further and changing to import System.IO (hFlush, hPutStrLn) in src/Language/Haskell/PtGhci/Log.hs I am now getting next error:

➜  ptghci git:(cabal) ✗ cabal v2-build
Build profile: -w ghc-8.0.1 -O1
In order, the following will be built (use -v for more details):
 - ptghci-0.1.0.0 (lib) (first run)
 - ptghci-0.1.0.0 (exe:ptghci) (first run)
Preprocessing library for ptghci-0.1.0.0..
Building library for ptghci-0.1.0.0..
[15 of 19] Compiling Language.Haskell.PtGhci.Log ( src/Language/Haskell/PtGhci/Log.hs, /Users/dmitrizaitsev/Repos/ptghci/dist-newstyle/build/x86_64-osx/ghc-8.0.1/ptghci-0.1.0.0/build/Language/Haskell/PtGhci/Log.o )

src/Language/Haskell/PtGhci/Log.hs:16:40: error:
    • Couldn't match type ‘Text’ with ‘[Char]’
      Expected type: String
        Actual type: Text
    • In the second argument of ‘hPutStrLn’, namely ‘t’
      In the first argument of ‘(>>)’, namely ‘hPutStrLn h t’
      In the expression: hPutStrLn h t >> hFlush h

src/Language/Haskell/PtGhci/Log.hs:33:35: error:
    Variable not in scope: displayException :: e -> String
cabal: Failed to build ptghci-0.1.0.0 (which is required by exe:ptghci from
ptghci-0.1.0.0).

[RichardWarfield]

I wasn't able to reproduce this building with Cabal (I can build the repository with cabal v2-build), but this may have something to do with the GHC version -- I haven't tested on anything before 8.4.

The error about hPutStrLn is weird -- that import should come from Protolude via the PtGhci prelude. Could you try importing from Protolude `from Protolude import (hPutStrLn) or, if that doesn't work, import Data.Text.IO and see if that works?

[dmitriz]

I have since been given the advice to use stack instead and after some searching and battling managed to install it. However, I can only run ptghci from my local fork directory. Running from any other directory immediately begins downloading ghc-8.2.2 (almost 200MB) that I cannot stop other than killing the term window :(

When it works, there seem to be some weir errors:

λ [1]: fmap (+2) [1]                                                                                                           
Out [1]: 

<interactive>:82:1: error:
    • Ambiguous type variable ‘f0’ arising from a use of ‘print’
      prevents the constraint ‘(Show (f0 Integer))’ from being solved.
      Probable fix: use a type annotation to specify what ‘f0’ should be.
      These potential instances exist:
        instance Show a => Show (ZipList a)
          -- Defined in ‘Control.Applicative’
        instance Show a => Show (Complex a) -- Defined in ‘Data.Complex’
        instance (Show a, Show b) => Show (Either a b)
          -- Defined in ‘Data.Either’
        ...plus 50 others
        ...plus 48 instances involving out-of-scope types
        (use -fprint-potential-instances to see them all)
    • In a stmt of an interactive GHCi command: print it

[RichardWarfield]

That error has to do with the fact that the OverloadedLists extension is on in the ptghci app. It's not directly related to ptghci.

Stack is very gluttonous with disk space, but in return it provides a lot of benefits around repeatable builds. If you can, I'd suggest sticking with the install instructions in the Readme, which should give you an install based on GHC 8.6.4.

On Sun, Aug 18, 2019 at 9:52 PM Dmitri Zaitsev notifications@github.com wrote:

I have since been given the advice to use stack instead and after some searching and battling managed to install it. However, I can only run ptghci from my local fork directory. Running from any other directory immediately begins downloading ghc-8.2.2 (almost 200MB) that I cannot stop other than killing the term window :(

When it works, there seem to be some weir errors:

λ [1]: fmap (+2) [1] Out [1]:

:82:1: error: • Ambiguous type variable ‘f0’ arising from a use of ‘print’ prevents the constraint ‘(Show (f0 Integer))’ from being solved. Probable fix: use a type annotation to specify what ‘f0’ should be. These potential instances exist: instance Show a => Show (ZipList a) -- Defined in ‘Control.Applicative’ instance Show a => Show (Complex a) -- Defined in ‘Data.Complex’ instance (Show a, Show b) => Show (Either a b) -- Defined in ‘Data.Either’ ...plus 50 others ...plus 48 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In a stmt of an interactive GHCi command: print it — You are receiving this because you commented. Reply to this email directly, view it on GitHub , or mute the thread .

[dmitriz]

That error has to do with the fact that the OverloadedLists extension is on in the ptghci app. It's not directly related to ptghci.

Would you explain how to achieve the standard functionality? If that the kind of error message I am getting, I'd much prefer the standard setting :)

Stack is very gluttonous with disk space, but in return it provides a lot of benefits around repeatable builds. If you can, I'd suggest sticking with the install instructions in the Readme, which should give you an install based on GHC 8.6.4.

I have essentially followed it, apart from using the more recent 8.6.5 I have. But right now it tries to download 8.2.2 and then stalls in the middle, it just doesn't feel right, especially since it actually works from the repo directory. There might be some local settings doing that, is there there any way to make it work globally?

[RichardWarfield]

The way ptghci works is that it starts up ghci as a remote process, using the ghciCommand command line in your configuration file. If no configuration file is found, then ghciCommand defaults to stack ghci if the stack binary is on your $PATH, otherwise just ghci.

If you have stack installed and run ptghci in the ptghci project repository directory, then it will use the settings of the ptghci stack.yaml and package.yaml file, including OverloadedLists. This isn't really about ptghci; you would get the same behavior with plain old stack ghci. That said, you can turn off an extension just as you would in plain GHCi: unset -XOverloadedLists.

If stack is trying to download GHC 8.2.2 when you run ptghci in a different directory, my guess is that you are running in a directory without a stack.yaml file and stack is for some reason picking an old resolver using GHC 8.2.2. Try creating a new stack project (stack new <projname>) and running from there. Alternatively, you could create a configuration file and set the ghciCommand to plain old ghci if you just want to run vanilla ghci.

[dmitriz]

If no configuration file is found, then ghciCommand defaults to stack ghci if the stack binary is on your $PATH, otherwise just ghci.

It was indeed using stack ghci and that was the root of my problems, as it was silently downloading the old version without telling me any reasons why nor explaining how I could change that option. I had to look for help on the IRC, where it took several turns before they told me to look into .stack/global-project/stack.yaml that I would have not guessed myself. I was instead puzzled by why the .stack/stack.yaml was ignored. The naming "global-project", among other 10 directories (whose names give me no clue about their roles) is really confusing.

But all this pain could have been saved if running stack ghci would simply inform me which config it is using. I can't understand why it isn't, and in my opinion, either it should, or else it should not be used/recommended by packages.

I can see that this is indeed explained in your readme, but unfortunately every time I open it, it starts running Chrome Helper process taking 100% of my CPU that makes my computer unresponsive so I have to kill the process and then the whole page is gone. And when I open it in Firefox, my fans start working wildly.

But then the whole problem wouldn't exist, had it simply defaulted directly to ghci instead I presume.