Is it possible to configure stack ghci similar to the way ghci is configured via the ~/.ghci file?
Currently stack ghci does not pick up the settings in the ~/.ghci file.
I'm looking into setting the prompt to be a lambda instead of the loaded modules:
:set prompt "\ESC[33m\STXλ> \ESC[m\STX"
Update
[neo#nixos:~/HaskellLearning/IdeTest]$ stack ghci The following GHC
options are incompatible with GHCi and have not been passed to it:
-threaded Configuring GHCi with the following packages: IdeTest Using main module: 1. Package `IdeTest' component exe:IdeTest-exe with
main-is file: /home/neo/HaskellLearning/IdeTest/app/Main.hs GHCi,
version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi
configuration from /home/neo/HaskellLearning/IdeTest/.ghci Loaded GHCi
configuration from /home/neo/.ghci [1 of 9] Compiling Ch13
( /home/neo/HaskellLearning/IdeTest/src/Ch13.hs, interpreted ) [2 of
9] Compiling Ch15 (
/home/neo/HaskellLearning/IdeTest/src/Ch15.hs, interpreted ) [3 of 9]
Compiling Ch17 (
/home/neo/HaskellLearning/IdeTest/src/Ch17.hs, interpreted ) ... Ok, 9
modules loaded. Loaded GHCi configuration from
/run/user/1000/ghci31082/ghci-script
*Main Ch13 Ch15 Ch17 Functor HelloError Lib Phone SemigroupAndMonoid>
None of the other 2 configurations mentioned does anything regarding changing the prompt.
Try to put your config under:
~/.ghc/ghci.conf
Works for me on Ubuntu 16.04.
Related
I'm using stack ghci to start my REPL, based on the answer I got for my question on how to import a module installed with stack. This works fine, but I get initially a warning message Note: No local targets specified, so a plain ghci will be started with no package hiding or package options., followed by a bunch of suggestions about package hiding and options. My guess is that this is because I have not used stack init to setup a project, since I am still in the "playing around and learning" state and don't want a project yet. I have not found an explanation about the meaning of 'no local targets', but the effect to start a plain ghci is exactly what I want at that point. Is there a way to suppress this message? I looked at stack --help, but could not find something suitable.
As the Note (not warning) suggests, a plain ghci is started, which is rather uncommon situation when working with stack.
~$ stack ghci
Note: No local targets specified, so a plain ghci will be started with no package hiding or package options.
You are using snapshot: lts-14.12
If you want to use package hiding and options, then you can try one of the following:
* If you want to start a different project configuration than /home/username/.stack/global-project/stack.yaml, then you can use stack init to create a new stack.yaml for the packages in the
current directory.
* If you want to use the project configuration at /home/username/.stack/global-project/stack.yaml, then you can add to its 'packages' field.
Configuring GHCi with the following packages:
GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /tmp/haskell-stack-ghci/2a3bbd58/ghci-script
Prelude>
This means though that all you need to do to get the same behavior without the Note is just start ghci manually in the context of global stack environment:
~$ stack exec -- ghci
GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help
Prelude>
In case that you want to make sure some package is installed for "playing around and learning" in the ghci session you can supply them as --package arguments
~$ stack exec --package massiv -- ghci
atomic-primops> using precompiled package
cabal-doctest > using precompiled package
scheduler > using precompiled package
massiv > using precompiled package
Completed 4 action(s).
GHCi, version 8.6.5: http://www.haskell.org/ghc/ :? for help
Prelude> import Data.Massiv.Array
Prelude Data.Massiv.Array>
stack exec --ghci as in lehins's answer did not work for me, but stack exec ghci did.
I'm looking at the following module: https://hackage.haskell.org/package/boxes-0.1.4/docs/src/Text-PrettyPrint-Boxes.html
Which has contents of:
module Text.PrettyPrint.Boxes
( -- * Constructing boxes
#ifdef TESTING
Box(Box, content)
#else
Box
#endif
How can I enable / define the TESTING value - for development purposes? Ideally I'd like to have this built / enabled within a GHCi session.
I have to correct myself - the comment I gave is totally and utterly wrong.
> git clone git://github.com/treeowl/boxes.git
> cd boxes
> stack init
> stack ghci --ghc-options=-DTESTING
split-0.2.3.2: using precompiled package
boxes-0.1.4: configure (lib)
Configuring boxes-0.1.4...
boxes-0.1.4: initial-build-steps (lib)
Completed 2 action(s).
Configuring GHCi with the following packages: boxes
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from ...
[1 of 1] Compiling Text.PrettyPrint.Boxes ( .../boxes/Text/PrettyPrint/Boxes.hs, interpreted )
Ok, modules loaded: Text.PrettyPrint.Boxes.
Loaded GHCi configuration from /tmp/ghci28386/ghci-script
*Text.PrettyPrint.Boxes Text.PrettyPrint.Boxes> :t content
content :: Box -> Content
just works fine.
I created a new project and, as you can see, it even downloaded a brand new build plan for lts-7.4, which as you can see uses ghc-8.0.1.
But when running stack ghci, it built the project with GHC 7.10, and dropped me in a 7.10 ghci shell.
dario#curie /tmp> stack new foo
Downloading template "new-template" to create project "foo" in foo/ ...
Looking for .cabal or package.yaml files to use to init the project.
Using cabal packages:
- foo/foo.cabal
Selecting the best among 9 snapshots...
Downloaded lts-7.4 build plan.
* Matches lts-7.4
Selected resolver: lts-7.4
Initialising configuration using resolver: lts-7.4
Total number of user packages considered: 1
Writing configuration to file: foo/stack.yaml
All done.
dario#curie /tmp> cd foo
dario#curie /t/foo> stack ghci
foo-0.1.0.0: configure
Configuring foo-0.1.0.0...
foo-0.1.0.0: build
Preprocessing library foo-0.1.0.0...
[1 of 1] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/Lib.o )
In-place registering foo-0.1.0.0...
Preprocessing executable 'foo-exe' for foo-0.1.0.0...
[1 of 1] Compiling Main ( app/Main.hs, .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/foo-exe/foo-exe-tmp/Main.o )
Linking .stack-work/dist/x86_64-linux/Cabal-1.22.5.0/build/foo-exe/foo-exe ...
foo-0.1.0.0: copy/register
Installing library in
/tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/lib/x86_64-linux-ghc-7.10.3/foo-0.1.0.0-6bylsnNRJPuHxByS3dKqs5
Installing executable(s) in
/tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/bin
Registering foo-0.1.0.0...
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Using main module: 1. Package `foo' component exe:foo-exe with main-is file: /tmp/foo/app/Main.hs
Configuring GHCi with the following packages: foo
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Lib ( /tmp/foo/src/Lib.hs, interpreted )
Ok, modules loaded: Lib.
[2 of 2] Compiling Main ( /tmp/foo/app/Main.hs, interpreted )
Ok, modules loaded: Lib, Main.
>
I always relied on the assumption that for every stackage snapshot, stack would use only one version of GHC, am I wrong?
I don't have system-ghc: true in my config, and the faq doesn't mention many other alternatives
This is the output of stack path:
dario#curie /t/foo> stack path
stack-root: /home/dario/.stack
project-root: /tmp/foo
config-location: /tmp/foo/stack.yaml
bin-path: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/bin:/home/dario/.stack/programs/x86_64-linux/ghc-8.0.1/bin:/home/dario/Applications/bin:/home/dario/.rbenv/shims:/home/dario/.cabal/bin:/home/dario/.nix-profile/bin:/home/dario/.nix-profile/sbin:/home/dario/.sdkman/candidates/grails/current/bi n:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/lib/jvm/java-8-oracle/bin:/usr/lib/jvm/java-8-oracle/db/bin:/usr/lib/jvm/java-8-oracle/jre/bin:/home/dario/.local/bin:/home/dario/.nix-profile/bin
programs: /home/dario/.stack/programs/x86_64-linux
compiler-exe: /usr/bin/ghc
compiler-bin: /usr/bin
local-bin: /home/dario/.local/bin
extra-include-dirs:
extra-library-dirs:
snapshot-pkg-db: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/pkgdb
local-pkg-db: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/pkgdb
global-pkg-db: /var/lib/ghc/package.conf.d
ghc-package-path: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/pkgdb:/home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/pkgdb:/var/lib/ghc/package.conf.d
snapshot-install-root: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3
local-install-root: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3
snapshot-doc-root: /home/dario/.stack/snapshots/x86_64-linux/lts-7.4/7.10.3/doc
local-doc-root: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/doc
dist-dir: .stack-work/dist/x86_64-linux/Cabal-1.22.5.0
local-hpc-root: /tmp/foo/.stack-work/install/x86_64-linux/lts-7.4/7.10.3/hpc
local-bin-path: /home/dario/.local/bin
ghc-paths: /home/dario/.stack/programs/x86_64-linux
dario#curie /t/foo> echo $PATH
/home/dario/Applications/bin /home/dario/.rbenv/shims /home/dario/.cabal/bin /home/dario/.nix-profile/bin /home/dario/.nix-profile/sbin /home/dario/.sdkman/candidates/grails/current/bin /usr/local/sbin /usr/local/bin /usr/sbin /usr/bin /sbin /bin /usr/games /usr/local/games /snap/bin /usr/lib/jvm/java-8-oracle/bin /usr/lib/jvm/java-8-oracle/db/bin /usr/lib/jvm/java-8-oracle/jre/bin /home/dario/.local/bin /home/dario/.nix-profile/bin
I rely on the lts determining the version of ghc in use also for CI, so it's a bit worrying if my assumption doesn't hold (anymore?)
(I'm running stack Version 1.2.0 x86_64 hpack-0.14.0)
This is the output of stack setup
dario#curie /t/foo> stack setup
stack will use a sandboxed GHC it installed
For more information on paths, see 'stack path' and 'stack exec env'
To use this GHC and packages outside of a project, consider using:
stack ghc, stack ghci, stack runghc, or stack exec
I realized that this was due to the faulty way in which I "worked around" this issue:
https://github.com/commercialhaskell/stack/issues/2712
I might open it as another bug report, but it's definitely less important/interesting than fixing #2712
Is there a way to load a package(s) using Stack in GHCI and play around with it ?
So, that when the ghci is loaded, we can import the modules and see it's type signature, etc.
For the packages present in Stackage,
$ stack ghci --package unix-time
And this will give you a repl with the package unix-time loaded in it:
Run from outside a project, using implicit global project config
Using resolver: lts-6.14 from implicit global project's config file: /home/sibi/.stack/global-project/stack.yaml
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
λ> import Data.UnixTime
λ> :t getUnixTime
getUnixTime :: IO UnixTime
For multiple packages:
$ stack ghci --package unix-time --package download
Run from outside a project, using implicit global project config
Using resolver: lts-6.14 from implicit global project's config file: /home/sibi/.stack/global-project/stack.yaml
tagsoup-0.13.10: using precompiled package
xml-1.3.14: using precompiled package
time-locale-compat-0.1.1.3: using precompiled package
feed-0.3.11.1: download
feed-0.3.11.1: configure
feed-0.3.11.1: build
feed-0.3.11.1: copy/register
download-0.3.2.4: download
download-0.3.2.4: configure
download-0.3.2.4: build
download-0.3.2.4: copy/register
Completed 5 action(s).
Configuring GHCi with the following packages:
GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help
Ok, modules loaded: none.
λ> import Network.Download
λ>
I am getting a GHCI segfault when trying to create a database connection in GHCI with postgresql-simple.
I am using GHC 8.0.1, OSX 10.11.16. I do not have a system GHC, only the one installed by stack.
If I do the following in my project, it segfaults:
$ stack ghci
Loaded GHCi configuration from /private/var/folders/wb/vvtxjd7n2qz02f571yjyr9j40000gs/T/ghci62972/ghci-script
gchi> :set -XOverloadedStrings
gchi> import Database.PostgreSQL.Simple
gchi> let connstr = "host=localhost port=5432 user=myusername password=mypass dbname=local"
gchi> conn <- connectPostgreSQL connstr
zsh: segmentation fault stack ghci
I thought it might be worth looking at that file it mentions, so here are the contents:
> cat /private/var/folders/wb/vvtxjd7n2qz02f571yjyr9j40000gs/T/ghci62972/ghci-script
:load "/Users/erewok/projects/haskell/simpleservantblog/app/Main.hs" "Api" "Api.Post" "Api.User" "Config" "Html.Home" "Models.Author" "Models.Post"
:module + Api Api.Post Api.User Config Html.Home Models.Author Models.Post
It's a list of all the modules loaded from the project (which compiles and runs fine).
Here's the complete output of everything from starting ghci up to the seg fault:
$ stack ghci
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Using main module: 1. Package `simpleservantblog' component exe:simpleservantblog-exe with main-is file: /Users/erewok/projects/haskell/simpleservantblog/app/Main.hs
Configuring GHCi with the following packages: simpleservantblog
GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /Users/erewok/.ghci
[1 of 8] Compiling Models.Author ( /Users/erewok/projects/haskell/simpleservantblog/src/Models/Author.hs, interpreted )
[2 of 8] Compiling Models.Post ( /Users/erewok/projects/haskell/simpleservantblog/src/Models/Post.hs, interpreted )
[3 of 8] Compiling Html.Home ( /Users/erewok/projects/haskell/simpleservantblog/src/Html/Home.hs, interpreted )
[4 of 8] Compiling Api.User ( /Users/erewok/projects/haskell/simpleservantblog/src/Api/User.hs, interpreted )
[5 of 8] Compiling Api.Post ( /Users/erewok/projects/haskell/simpleservantblog/src/Api/Post.hs, interpreted )
[6 of 8] Compiling Config ( /Users/erewok/projects/haskell/simpleservantblog/src/Config.hs, interpreted )
[7 of 8] Compiling Api ( /Users/erewok/projects/haskell/simpleservantblog/src/Api.hs, interpreted )
[8 of 8] Compiling Main ( /Users/erewok/projects/haskell/simpleservantblog/app/Main.hs, interpreted )
Ok, modules loaded: Api, Config, Api.Post, Api.User, Html.Home, Models.Post, Models.Author, Main.
Loaded GHCi configuration from /private/var/folders/wb/vvtxjd7n2qz02f571yjyr9j40000gs/T/ghci64266/ghci-script
gchi> :set -XOverloadedStrings
gchi> import Database.PostgreSQL.Simple
gchi> let connstr = "host=localhost port=5432 user=myusername password=mypass dbname=local"
gchi> conn <- connectPostgreSQL connstr
zsh: segmentation fault stack ghci
More Information
Postgresql Version: 9.5, installed using the EnterpriseDB installer
The request to post my stack.yaml (which is below) reminded me of an issue I had when trying to install postgresql-libpq. This is probably related.
Stack.yaml
# This file was automatically generated by stack init
# For more information, see: http://docs.haskellstack.org/en/stable/yaml_configuration/
# Specifies the GHC version and set of packages available (e.g., lts-3.5, nightly-2015-09-21, ghc-7.10.2)
resolver: nightly-2016-08-25
# Local packages, usually specified by relative directory name
packages:
- '.'
- location:
git: https://www.github.com/mattjbray/elm-export
commit: 8868c1f09597f44c2e18e014cd9fbcf8320c3fea
extra-dep: True
- location:
git: https://www.github.com/mattjbray/servant-elm
commit: e13c8def8127ea339e9801d804638854947193e8
extra-dep: True
# Packages to be pulled from upstream that are not in the resolver (e.g., acme-missiles-0.3)
extra-deps:
- wai-make-assets-0.1.1
# Override default flag values for local packages and extra-deps
flags: {}
# Extra package databases containing global packages
extra-package-dbs: []
# Control whether we use the GHC we find on the path
# system-ghc: true
# Extra directories used by stack for building
# extra-include-dirs: [/path/to/dir]
extra-lib-dirs: [/usr/local/opt/libiconv/lib, /usr/local/lib, /usr/lib]
Also segfaults on GHC 7.10.3 with resolver lts-6.17
gchi> conn <- connectPostgreSQL connstr
zsh: segmentation fault stack ghci --resolver lts-6.17
An Idea I had
I think the version of postgresql-libpq I am using was built with libiconv.2.dylib compiled for Postgresql 9.4, but the database I am trying to connect to is actually Postgresql 9.5. This may be the reason for my issue.
A Thing I Did Inspired By that Idea
Here are some steps I took to try to debug further and/or fix this. I first linked the Postgresql 9.5 *dylib files into my /usr/local/lib directory in order to replace the old ones linked against the Postgresql 9.4 version.
$ cd /usr/local/lib
$ sudo ln -s -f /Library/PostgreSQL/9.5/lib/*dylib .
After that, I tried to force stack to rebuild postgresql-libpq and postgresql-simple in this way:
$ stack exec -- ghc-pkg unregister --force postgresql-simple
$ stack exec -- ghc-pkg unregister --force postgresql-libpq
$ rm -rf ~/.stack/precompiled/x86_64-osx/ghc-8.0.1/1.24.0.0/postgresql-libpq-0.9.1.1/
$ rm -rf ~/.stack/precompiled/x86_64-osx/ghc-8.0.1/1.24.0.0/postgresql-simple-0.5.2.*
$ stack build
At which point, it promised me it would build and configure the removed packages. Still segfaulted when I ran the above, however.
While attempting to generate a stack trace for my issue, I discovered that I can start ghci in the following way:
$ stack ghci --ghci-options -fexternal-interpreter
And then, for whatever, reason, the segfault does not appear and everything works as expected. I have no idea if anyone else will find this useful.
The thing that seemed weird to me was that I didn't have an issue when the code was compiled and run. I only had an issue in GHCI.
Anyway, until I find out more or someone has a better suggestion, I'll go with this so I can continue testing what I want in the REPL.