Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Phil Ruffwind]

On Tue, Sep 13, 2016, at 16:24, Sven Panne wrote:
>
>* On Windows under  a MinGW bash you get a a warning for ghci:
> 
> $ stack --resolver=nightly-2016-07-01 exec ghci -- --version
> Run from outside a project, using implicit global project config
> WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells
> (cygwin-bash, in particular)
>  doesn't handle Ctrl-C well; use the 'ghcii.sh' shell
> wrapper instead
> The Glorious Glasgow Haskell Compilation System, version 8.0.1
> 
>  But using ghcii.sh through stack doesn't work:
> 
> $ stack --resolver=nightly-2016-07-01 exec ghcii.sh -- --version
> Run from outside a project, using implicit global project config
> 
> D:\Benutzer\Sven\AppData\Local\Programs\stack\x86_64-windows\ghc-8.0.1\bin\ghcii.sh:
> createProcess: invalid argument (Exec format error)

My guess is that `stack.exe` executes commands using the native Windows
`CreateProcess`, which has no concept of Bash-like shell scripts (since
they are a foreign thing introduced by MinGW).  Perhaps try something
like `stack exec sh ghcii.sh` instead?  (Or `stack exec -- sh -c
` if you want to be agnostic to whether `` is a true
executable or just a script.)
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Edward Z. Yang]

Excerpts from Harendra Kumar's message of 2016-09-15 13:02:50 +0530:
> While I agree that stack.yaml is a frozen config, we do not necessarily
> need a separate config file or a separate format for that. My main point
> was a that a new user will have to understand two more languages
> (YAML/cabal) in addition to Haskell. We can have the config spread in
> multiple files, but they should look like an extension of the same thing
> rather than disparate things.

For what it's worth, cabal.project files use the same parser/lexical
structure as Cabal files; the fields/stanzas are just different.  I'm
not familiar with the reasons why Stack decided to use YAML for their
configuration format.

> The stack snapshot config can be seen as a higher level concept of the
> pvp-bounds in the cabal file. While pvp-bounds specifies a whole range, the
> snapshot is a point in that space. It can also be seen as a more general
> version of the "tested-with" field in the cabal file. We can instead say -
> tested-with these snapshots (or set of versions). Instead of using
> stack-7.8.yaml, stack-8.0.yaml manually, the build tool itself can list
> which snapshot configs that are available and you can choose which one you
> want to build. The config could be tool agnostic.

Well, if the "snapshot" config is put in specific file, there's no
reason why Cabal couldn't be taught to also read configuration from that
file.  But if cabal-install wants it to be in "pkg description format"
and Stack wants it to be in YAML I'm not sure how you are going to get
the projects to agree on a shared format.  Snapshot config is put
in cabal.project.freeze, which has the virtue of having the *same*
format of cabal.project.

Edward
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Patrick Pelletier]

On 9/14/16 10:47 AM, David Feuer wrote:


While we're griping about stack: it seems to place compiler output 
from -ddump-... in mysterious places that are hard to find without 
Google, and (worse) it seems to do something with stack test output 
that even Google can't discover.




Also, compiler warnings get squirreled away in a file that I have to go 
hunting for.  It would be nice to have an option to print warnings (for 
local packages, not dependencies) to stderr.


--Patrick

___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Patrick Pelletier]

On 9/13/16 1:16 PM, Paolo Giarrusso wrote:
To clarify: I'm not proposing stack to install those GHCs, just to use 
them.


I think the extra work would be limited (calling GHC-X.Y.Z instead of 
GHC) and has other technical advantages 
(https://github.com/commercialhaskell/stack/issues/2433). Mind you, 
I'm willing to contribute the work and not asking anybody—I've just 
been busy.


Right now I have to modify the PATH every time I use GHC 7.8.4 because 
I needed to customize the build (I'm on OS X 10.11), but I still want 
GHC 8 by default.


That reminds me: another thing I'd like to see (from either cabal or 
stack) is better support for cross-compilation.  Cabal supports 
cross-compilation very poorly; you end up having to do ugly stuff like:


alias mcabal="cabal --with-ghc=x86_64-unknown-linux-musl-ghc 
--with-ld=x86_64-unknown-linux-musl-ld 
--with-gcc=x86_64-unknown-linux-musl-gcc 
--with-ghc-pkg=x86_64-unknown-linux-musl-ghc-pkg"


and even then, it doesn't work with non-trivial packages.

As far as I know, stack doesn't support cross-compilation at all. (But 
perhaps it's just not documented, or I've missed the documentation.)


--Patrick

___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Harendra Kumar]

There are multiple ways to achieve this:

1) The env command being discussed is actually "stack exec env". Though it
includes the full environment rather than stack exclusive. You can use
"stack path" to print the stack exclusive environment. You can also use
"stack path --" to pick specific items from that env.

2) Using "stack exec bash" is a very convenient way as suggested by
Christopher Allen.

3) But I prefer to just use "export PATH=$(stack path --bin-path)" instead
which only sets the PATH. The full environment (when using env or bash)
also includes GHC_PACKAGE_PATH which cabal does not like. So if you want to
use cabal on stack installed ghc just setting PATH works fine.

I think stack has a lot of flexibility and features, in fact too many.
Usually there is already a way to achieve something that you want. Though
there are areas where the user experience can be made better including
cosmetic stuff like not throwing confusing or unnecessary warnings.

-harendra


On 14 September 2016 at 01:32, Christopher Allen  wrote:

> I almost never (maybe twice in the last year) do this, but when I need
> an environment that has Stack provided GHC-stuff in the path, I use
> `stack exec my-shell`.
>
>
>
> On Tue, Sep 13, 2016 at 2:55 PM, Brandon Allbery 
> wrote:
> >
> > On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg 
> > wrote:
> >>
> >> Other minor points:
> >> `stack env` does not work for me: my version of stack does not know how
> to
> >> `env`
> >
> >
> > I think they said that was an add-in. IIRC stack is extensible with
> external
> > commands, in roughly the same way git is.
> >
> > (I am also not fond of stack, and even less fond of the politics that go
> > with it, but will stick to the technical here.)
> >
> > --
> > brandon s allbery kf8nh   sine nomine
> associates
> > allber...@gmail.com
> ballb...@sinenomine.net
> > unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
> >
> > ___
> > Haskell-Cafe mailing list
> > To (un)subscribe, modify options or view archives go to:
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> > Only members subscribed via the mailman list are allowed to post.
>
>
>
> --
> Chris Allen
> Currently working on http://haskellbook.com
> ___
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.
>
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Christopher Allen]

Stack is not your shell, a build script, or a Makefile. It already has
path management for the GHC installations it provisions and supports.
It is not Stack's job to mutilate your path to support external GHC
installations.

Make a Makefile or add shortcuts to your bashrc to switch compilers.

On Tue, Sep 13, 2016 at 3:16 PM, Paolo Giarrusso  wrote:
> On Tuesday, September 13, 2016 at 10:05:44 PM UTC+2, Christopher Allen
> wrote:
>>
>> Stack users are moving away from enabling system installed GHCs by
>> default because it breaks the ease of enabling profiling for libraries
>> when you're using a Stack-installed GHC.
>
>
>>
>> I'm not sure why multiple system-installed GHCs needs to be supported
>> in addition to the GHC support Stack already provides. That's extra
>> work for...what? Stack isn't trying to compete with Nix. It's more
>> like a blend of rustup and cargo -- or Clojure's Leiningen.
>
>
> To clarify: I'm not proposing stack to install those GHCs, just to use them.
>
> I think the extra work would be limited (calling GHC-X.Y.Z instead of GHC)
> and has other technical advantages
> (https://github.com/commercialhaskell/stack/issues/2433). Mind you, I'm
> willing to contribute the work and not asking anybody—I've just been busy.
>
> Right now I have to modify the PATH every time I use GHC 7.8.4 because I
> needed to customize the build (I'm on OS X 10.11), but I still want GHC 8 by
> default.
>
>>
>> On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso 
>> wrote:
>> >
>> >
>> > On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard Eisenberg
>> > wrote:
>> >>
>> >> Thanks, many, for explaining better ways to interact directly with GHC
>> >> after using a `stack setup`. Perhaps, then, all that’s stopping someone
>> >> like
>> >> me from liking the ease of `stack setup` is a little missing PR (as in,
>> >> public relations). I understand that many people want to keep GHC
>> >> cloistered
>> >> away to ease version swapping, but others (like me) want GHC available
>> >> front
>> >> and center.
>> >>
>> >> Other minor points:
>> >> `stack env` does not work for me: my version of stack does not know how
>> >> to
>> >> `env`.
>> >
>> >
>> > That's correct—stack env was a feature request.
>> >
>> > The warning on `stack ghci` doesn't happen usually, but I'd say that's a
>> > bug
>> > (probably because it's a new install)?
>> >
>> > I use stack (and have contributed a bit recently), but I agree there's a
>> > few
>> > things stack could do better for this workflow.
>> >
>> > And the transition has a rather annoying learning curve—stack ghci and
>> > stack
>> > ghc are not the same as ghci/ghc. I think that's on purpose to support a
>> > project-based workflow, and it has upsides, but it's a transition
>> > pitfall.
>> >  Lots of things *are* explained in
>> > https://docs.haskellstack.org/en/latest/faq/, but you do need learn a
>> > few
>> > things from scratch.
>> >
>> > You want stack exec ghc and stack exec ghci, and arbitrary options
>> > require a
>> > double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc
>> > --version`. And I'm afraid the command syntax is mostly frozen by now.
>> >
>> > To support a compiler-based workflow, there are a few things planned—I
>> > opened an issue to collect them, starting from Simon Marlow's recent
>> > email:
>> > https://github.com/commercialhaskell/stack/issues/2546
>> >
>> > BTW, a system-installed GHC already works if you stick to one (and only
>> > build projects that need that). But I'd love to support multiple
>> > system-installed GHCs and being able to pick the one you need.
>> >
>> > As others already explained, giving access to stack-installed GHCs can
>> > be
>> > problematic—they're going to work, in part, exactly because you can't
>> > install in their package database.
>> >
>> > Having stack install system-wide GHCs would IMHO risk opening a can of
>> > worms—having working binaries for all Linux distros requires some work,
>> > system installers would be harder and most users would dislike them.
>> >
>> > ___
>> > Haskell-Cafe mailing list
>> > To (un)subscribe, modify options or view archives go to:
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> > Only members subscribed via the mailman list are allowed to post.
>>
>> --
>> Chris Allen
>> Currently working on http://haskellbook.com
>> ___
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.



-- 
Chris Allen
Currently working on http://haskellbook.com
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Theodore Lief Gannon]

Stack *does* allow direct interaction with GHC:

stack exec -- ghc version

Granted this lacks a bit in brevity, but if you want to issue multiple
commands from "inside" stack's private environment, you can also just do
this:

stack exec sh

On Tue, Sep 13, 2016 at 11:58 AM, Richard Eisenberg 
wrote:

> I’ve watched the recent back-and-forth about stack with quite a bit of
> interest (as many of us have). The discussion inspired me to take another
> look at stack. Here are the results of that foray.
>
> First, a disclosure: While I have appreciated the emergence of a new build
> tool for Haskell, I have never much liked stack. One of my chief goals in
> taking another look is to understand better why I do not like it.
>
> My task: Set up a Haskell environment on a new machine (a Mac). This
> machine has no Haskell infrastructure on it.
>
> My approach:
>
> 1. `brew install haskell-stack`. Success.
>
> At this point, I do not have a Haskell project I wish to build. Instead, I
> really just want the ability to run Haskell expressions in GHCi. So I skip
> `stack new` and go straight to
>
> 2. `stack setup`. This succeeds, but prints out some interesting messages
> along the way, including
>
> > Did not find .cabal file for servant-yaml-0.1.0.0 with Git SHA of
> 71c0a55d0a877954d9590e285c0eb861ace2d8cc
> > Right Nothing
>
> At the end, I am helpfully told
>
> > To use this GHC and packages outside of a project, consider using:
> > stack ghc, stack ghci, stack runghc, or stack exec
> >
>
> So I then
>
> 3. `stack ghci`. My computer’s first reaction is to say
>
> > Run from outside a project, using implicit global project config
> > Using resolver: lts-6.17 from implicit global project's config file:
> /home/rae/.stack/global-project/stack.yaml
> > Error parsing targets: The specified targets matched no packages.
> > Perhaps you need to run 'stack init'?
> > Warning: build failed, but optimistically launching GHCi anyway
> >
>
> which doesn’t make me feel all that comfortable, but then I am indeed
> delivered to the GHCi prompt, which works as expected.
>
> Done with GHCi, I quit. I then want to double-check which version of GHC I
> got, so I
>
> 4. `stack ghc --version`. This command reports
>
> > Invalid option `--version’
>
> Grumble. It seems I can’t interact with GHC directly.
>
> 
>
> At this point, I am reminded why I dislike stack:
>
> **It’s optimized for a different workflow than I use.**
>
> And I think this fact (repeated by others’ experiences) is why a segment
> of our community has not celebrated stack as much as other segments have.
> We all have different workflows.
>
> From what I understand about it, stack is great for a project-based
> workflow. In this workflow, you are working on a Haskell project. You are
> happy to specify settings in .cabal and stack.yaml files. And you really
> want your build to work in the future and on other machines.
>
> In my experience, stack is not great with a compiler-based workflow. In
> this workflow, you aren’t quite as organized perhaps and do not have all
> your settings written. You also want the ability just to compile a file
> without changing any configurations. You want to be able to start GHCi with
> a nice set of libraries with which to experiment.
>
> I definitely like a compiler-based workflow. I’m sure that many of you
> prefer a project-based workflow.
>
> The great news here is that we have a choice: use stack for a
> project-based workflow, and don’t use it when you want a compiler-based
> workflow. No one needs to convince others about personal preferences.
>
> But there is one nagging issue: what do we suggest to newcomers? The
> downloads page right now is not serving us well. (I was legitimately
> scratching my head at first trying to figure out how to provision a new
> computer.) Sadly, I don’t see a good option presenting itself. Both
> potential approaches (The Haskell Toolchain vs. stack) have (in my opinion)
> serious shortcomings.
>
> A. The Haskell Toolchain (that is, what’s currently called the Haskell
> Platform Minimal) does appear to lack a “here’s what you do first”
> tutorial. Forgive me if I’ve missed it. It’s also right now quite hard to
> discover — you have to choose the oft-maligned Haskell Platform link before
> you are told that there is a minimal variant.
>
> B. stack sets up GHC in a way that either 1) requires a project-based
> workflow with a stack.yaml file or 2) issues a bunch of somewhat-scary
> warnings every time GHC is invoked outside of a project. Furthermore, stack
> prohibits direct interaction with GHC (as in `ghc --version`).
>
> There’s more good news here! Both of these problems are really easy to fix.
>
> To fix (A), someone just has to write the tutorial.
>
> To fix (B), stack just needs a new option so that `stack setup` installs a
> system GHC. Perhaps it would even be sufficient for `stack setup` to
> clearly tell the user where ghc is installed and what to add to their 

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Brandon Allbery]

On Tue, Sep 13, 2016 at 3:14 PM, John Wiegley  wrote:

> Some other tools provide an "env" sub-command, so that a person can run:
>
> eval $(stack env)
>
> And now ghc, ghci, etc., would be on the PATH, and the user doesn't really
> need to care about where it lives.
>

There's more to it than $PATH --- and I am not sure that making it easy to
accidentally modify the sandboxed package database is in any way a good
idea.

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Brandon Allbery]

On Tue, Sep 13, 2016 at 3:47 PM, Richard Eisenberg 
wrote:

> Other minor points:
> `stack env` does not work for me: my version of stack does not know how to
> `env`
>

I think they said that was an add-in. IIRC stack is extensible with
external commands, in roughly the same way git is.

(I am also not fond of stack, and even less fond of the politics that go
with it, but will stick to the technical here.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Brandon Allbery]

On Tue, Sep 13, 2016 at 3:13 PM, Kyle Ondy  wrote:

> On 16-09-13 12:07, Theodore Lief Gannon wrote:
> > Stack *does* allow direct interaction with GHC:
> >
> > stack exec -- ghc version
> >
> I find `stack ghc -- --version` to be a bit easier. Anything after the
> `--` is
> passed as an argument to ghc.
>

I actually find this part a little unfair; stack parses its parameters the
same way cabal does.

> stack exec -- ghc --version
> cabal exec -- ghc --version
Both need the -- to prevent --version from being eaten by stack/cabal
respectively. (GNU "permute" argument parsing. urgh.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community

Re: [Haskell-community] [Haskell-cafe] technical thoughts on stack

[Christopher Allen]

Stack users are moving away from enabling system installed GHCs by
default because it breaks the ease of enabling profiling for libraries
when you're using a Stack-installed GHC.

I'm not sure why multiple system-installed GHCs needs to be supported
in addition to the GHC support Stack already provides. That's extra
work for...what? Stack isn't trying to compete with Nix. It's more
like a blend of rustup and cargo -- or Clojure's Leiningen.

On Tue, Sep 13, 2016 at 3:01 PM, Paolo Giarrusso  wrote:
>
>
> On Tuesday, September 13, 2016 at 9:47:20 PM UTC+2, Richard Eisenberg wrote:
>>
>> Thanks, many, for explaining better ways to interact directly with GHC
>> after using a `stack setup`. Perhaps, then, all that’s stopping someone like
>> me from liking the ease of `stack setup` is a little missing PR (as in,
>> public relations). I understand that many people want to keep GHC cloistered
>> away to ease version swapping, but others (like me) want GHC available front
>> and center.
>>
>> Other minor points:
>> `stack env` does not work for me: my version of stack does not know how to
>> `env`.
>
>
> That's correct—stack env was a feature request.
>
> The warning on `stack ghci` doesn't happen usually, but I'd say that's a bug
> (probably because it's a new install)?
>
> I use stack (and have contributed a bit recently), but I agree there's a few
> things stack could do better for this workflow.
>
> And the transition has a rather annoying learning curve—stack ghci and stack
> ghc are not the same as ghci/ghc. I think that's on purpose to support a
> project-based workflow, and it has upsides, but it's a transition pitfall.
>  Lots of things *are* explained in
> https://docs.haskellstack.org/en/latest/faq/, but you do need learn a few
> things from scratch.
>
> You want stack exec ghc and stack exec ghci, and arbitrary options require a
> double dash `--` — use `stack ghc -- --version` or `stack exec -- ghc
> --version`. And I'm afraid the command syntax is mostly frozen by now.
>
> To support a compiler-based workflow, there are a few things planned—I
> opened an issue to collect them, starting from Simon Marlow's recent email:
> https://github.com/commercialhaskell/stack/issues/2546
>
> BTW, a system-installed GHC already works if you stick to one (and only
> build projects that need that). But I'd love to support multiple
> system-installed GHCs and being able to pick the one you need.
>
> As others already explained, giving access to stack-installed GHCs can be
> problematic—they're going to work, in part, exactly because you can't
> install in their package database.
>
> Having stack install system-wide GHCs would IMHO risk opening a can of
> worms—having working binaries for all Linux distros requires some work,
> system installers would be harder and most users would dislike them.
>
> ___
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.



-- 
Chris Allen
Currently working on http://haskellbook.com
___
Haskell-community mailing list
Haskell-community@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-community