That’s a tremendously helpful summary, thank you Iavor. And Michail’s summary
was also very helpful.
Most of this is doubtless well-known to habitual cabal users, but it might be
useful to explain the user model, in a way that covers these points, somewhere
close to the Cabal home page.
Hi Brandon,
On Mon, 15 Apr 2019 at 23:46, Brandon Allbery wrote:
>
> Mikhail, the use case not addressed here is people who are used to v1-style
> and want to keep using it — and possibly aren't in a great position to rewire
> their setup to fit how v2 thinks. Personally, I have situations
But it fails this way instead, because 3.x works differently. Probably
should have checked docs given it's a new major version of cabal-install.
On Mon, Apr 15, 2019 at 6:44 PM Simon Peyton Jones
wrote:
> Simon has a cabal-install that claims to be 3.0.0.0
>
>
> Ah yes, I installed it thus:
>
>
Mikhail, the use case not addressed here is people who are used to v1-style
and want to keep using it — and possibly aren't in a great position to
rewire their setup to fit how v2 thinks. Personally, I have situations
where I use v2 and others where v1 works better.
On Mon, Apr 15, 2019 at 6:43
Simon has a cabal-install that claims to be 3.0.0.0
Ah yes, I installed it thus:
·sudo add-apt-repository ppa:hvr/ghc-wsl
·sudo apt-get update
·sudo apt install cabal-install-3.0
Why did I do that? Because earlier versions of cabal crashed with a mysterious
“The
Hello Simon,
On Mon, 15 Apr 2019 at 23:14, Simon Peyton Jones via ghc-devs
wrote:
>
> It is terribly mysterious that “cabal install hspec” doesn’t, well, install
> hspec.
In the cabal v2-* model [1] installing libraries globally is no longer
the recommended mode of operation, which is why you
Hello,
in case it is useful, here is how I think about what's happening with
cabal. At present, `cabal-install` supports two different modes of
operation: the old style (aka `v1`) and the new style (aka `v2`) and---at
least for me---the two require a slightly different mental model of what is
The facts here are in the original message: Simon has a cabal-install that
claims to be 3.0.0.0, and is treating "install" as "v2-install". So
evidently *someone* has released it in some fashion, perhaps
inappropriately.
On Mon, Apr 15, 2019 at 6:22 PM Oleg Grenrus wrote:
> cabal-install-3
cabal-install-3 isn't released. Please check the facts.
- Oleg
On 16.4.2019 1.17, Brandon Allbery wrote:
I vaguely recall seeing that bug come up with respect to v2-install.
And in fact am a bit surprised that 3 has been released, since this is
highlighting that neither it nor the Haskell
I vaguely recall seeing that bug come up with respect to v2-install. And in
fact am a bit surprised that 3 has been released, since this is
highlighting that neither it nor the Haskell ecosystem is quite ready for
it.
I'd also have expected (and thought I'd seen) "cabal install" in recent 2.x
Aha! That works. I would never in a million years have found that by myself.
Thank you.
But
* It is terribly mysterious that “cabal install hspec” doesn’t, well,
install hspec.
* It must surely be a bug that “cabal install –lib hspec” simply crashes.
Simon
From: Brandon Allbery
Yes, I think a lot of documentation will need to be updated because this.
You want "cabal v1-install" with cabal 3.
On Mon, Apr 15, 2019 at 6:00 PM Simon Peyton Jones
wrote:
> Thanks. But alas I have no clue about whether I want a v1-install or a
> v2-install, nor how to achieve them if I knew
If you want to install it globally for use by GHC, I think you want
v1-install.
On 4/15/19 5:00 PM, Simon Peyton Jones via ghc-devs wrote:
>
> Thanks. But alas I have no clue about whether I want a v1-install or
> a v2-install, nor how to achieve them if I knew what they were. I
> just want to
Thanks. But alas I have no clue about whether I want a v1-install or a
v2-install, nor how to achieve them if I knew what they were. I just want to
install ‘hspec’ so that I can use it when compiling a program. How would I do
that?
The instructions here
I'm trying to install 'hspec' on my WSL (Windows subsystem for Linux) system.
But I fail; see below.
For some reason cabal complains about installing a library. (That seems
peculiar - isn't that what cabal is for?) But it helpfully suggests adding
-lib.
Alas, cabal then crashes outright, which
Hey,
sorry, I'm a little late to respond. I didn't push to GitHub, at least not
consciously.
Let me know if you find that I screwed up somewhere.
Cheers,
Sebastian
Von: Ben Gamari
Gesendet: Samstag, April 6, 2019 8:28 PM
An: Ryan Scott; Sebastian Graf
Cc:
It seems if you move all the metainfo to above the title then it
renders correctly.
Should be easy enough to fix if someone feels strongly about how these
are rendered.
Matt
On Mon, Apr 15, 2019 at 5:45 PM Matthew Pickering
wrote:
>
> The ..sectnum is necessary so that when you render all the
The ..sectnum is necessary so that when you render all the proposals
together then the numbering is coherent.
What happens if you move the ..sectnum to above the title?
On that note, I think there should be a site where you can view the
rendered proposals rather than having to do so via github
Simon Peyton Jones via ghc-devs writes:
> Why does this proposal
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0036-kind-signatures.rst
> start with Section 36? (It is proposal 36.)
> Lots of other proposals do this too.
That's a great question. The header contains
Why does this proposal
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0036-kind-signatures.rst
start with Section 36? (It is proposal 36.)
Lots of other proposals do this too.
Can it be fixed?
Thanks
Simon
___
ghc-devs mailing list
sounds good to me!
| -Original Message-
| From: Moritz Angermann
| Sent: 15 April 2019 14:29
| To: Simon Peyton Jones
| Cc: Matthew Pickering ; Andrey Mokhov
| ; ghc-devs@haskell.org
| Subject: Re: Hadrian
|
| I guess we could add
|
| $root/ghc-stage1 (shell script)
|
Ah. I hadn't even tried the stage2 compiler (in the stage1/ directory). Yes,
that works. But perhaps a script to get to it would be helpful, otherwise
invoking stage1 will look entirely different to invoking stage2. Not a bid
deal, I grant you!
S
| -Original Message-
| From:
Does the stage2 compiler which is found in `stage1/bin/ghc` not work
for you? I thought the issue was that the stage1 compiler doesn't
work.
Matt
On Mon, Apr 15, 2019 at 1:11 PM Simon Peyton Jones via ghc-devs
wrote:
>
> as a temporary workaround we could create a top-level wrapper script, say
as a temporary workaround we could create a top-level wrapper script, say
`ghc-stage1.sh` that will call Stage1 GHC with the right arguments, just like
Hadrian itself does during the build.
That sound fine, thanks. Same for ghc-stage2.sh?
My difficulty is that as of today I simply do not know
Hi Simon,
Apologies it's taking so long. It's not obvious how to fix this properly, and
as a temporary workaround we could create a top-level wrapper script, say
`ghc-stage1.sh` that will call Stage1 GHC with the right arguments, just like
Hadrian itself does during the build.
Will this work
Andrey and other Hadrian heros
Just to say that I am 100% stalled on using Hadrian because the in-tree binary
uses the wrong library files. I reported this a few weeks ago, but it still
seems unchanged
Simon
Bash$ ~/code/HEAD/_build/stage0/bin/ghc --version
The Glorious Glasgow Haskell
26 matches
Mail list logo
