The following reddit thread:
http://www.reddit.com/r/haskell/comments/e6o0y/ghc_701_released/c15s7rj
brought up some problems building cabal-install with GHC 7. I think
increasing the upper bounds on Cabal and cabal-install as below will
get them to compile with GHC 7.
Cabal:
filepath 1.2
On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley acow...@seas.upenn.edu
wrote:
The suggestion to use cabal install --dependencies-only ... instead
of cabal freeze in that issue is really nicely presented. cabal
freeze is close to the right thing, but it's just not as fully
featured as cabal
On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley acow...@seas.upenn.edu
wrote:
On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman mich...@snoyman.com
wrote:
On Wed, Mar 25, 2015 at 4:17 PM Anthony Cowley acow...@seas.upenn.edu
wrote:
The suggestion to use cabal install --dependencies
On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley acow...@gmail.com wrote:
On Mar 25, 2015, at 10:51 AM, Michael Snoyman mich...@snoyman.com wrote:
On Wed, Mar 25, 2015 at 4:30 PM Anthony Cowley acow...@seas.upenn.edu
wrote:
On Wed, Mar 25, 2015 at 10:24 AM, Michael Snoyman mich
On Mon, Mar 23, 2015 at 11:53 AM Simon Peyton Jones simo...@microsoft.com
wrote:
It's already a huge source of confusion for people using GHCi what they
get messages about ByteString is not ByteString.
Reading your blog post [1] it seems that we are addressing different
questions:
·
, 2015, at 3:21 AM, Michael Snoyman mich...@snoyman.com wrote:
On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley acow...@gmail.com wrote:
On Mar 25, 2015, at 11:03 AM, Michael Snoyman mich...@snoyman.com
wrote:
On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley acow...@gmail.com wrote:
On Mar
On Wed, Mar 25, 2015 at 7:35 PM Anthony Cowley acow...@gmail.com wrote:
On Mar 25, 2015, at 11:03 AM, Michael Snoyman mich...@snoyman.com wrote:
On Wed, Mar 25, 2015 at 4:58 PM Anthony Cowley acow...@gmail.com wrote:
On Mar 25, 2015, at 10:51 AM, Michael Snoyman mich...@snoyman.com
OK, should be working now:
http://www.stackage.org/lts/build-plan?package=warp
On Thu, Mar 26, 2015 at 5:03 PM Michael Snoyman mich...@snoyman.com wrote:
It's trivial for me to include them all, and equally trivial for me to
call out which ones are shipped with GHC somehow (such as an extra
be easier to parse with the usual shell tools.
Anthony
On Mar 26, 2015, at 9:41 AM, Michael Snoyman mich...@snoyman.com wrote:
Is the idea that you'd be able to make a query such as:
GET
https://www.stackage.org/lts/1.14/build-plan?package=foopackage=barpackage=baz
And get a result
on the road at the moment and not terribly capable of thought.
Anthony
On Mar 26, 2015, at 10:50 AM, Michael Snoyman mich...@snoyman.com wrote:
And do you want the information on the core packages (e.g., base,
template-haskell, containers) as well, or should they be left out?
On Thu, Mar 26, 2015
I'm in favor of adding support to Cabal to allow for this situation.
However: I highly doubt this will be the panacea as predicted. It's already
a huge source of confusion for people using GHCi what they get messages
about ByteString is not ByteString. In fact, this confusion is so
prevalent that
On Tue, Apr 28, 2015 at 4:40 PM Gershom B gersh...@gmail.com wrote:
In that case, perhaps we really should lean only towards the “shell out”
solution. Or, I suppose, we could hide the ssl implementation behind a flag
— but that feels rather awkward in comparison.
So let’s try this: can
”
dependencies?
Well, not really. We have an ugly bootstrapping script that downloads
the other dependencies:
https://github.com/haskell/cabal/blob/master/cabal-install/bootstrap.sh
Speaking of which...
On Tue, Apr 28, 2015 at 7:38 AM, Michael Snoyman mich...@snoyman.com
wrote:
On Tue, Apr 28
On Tue, Apr 28, 2015 at 4:22 PM Herbert Valerio Riedel hvrie...@gmail.com
wrote:
On 2015-04-28 at 10:21:04 +0200, Michael Snoyman wrote:
[...]
I have no intention of playing the minimal dependency game (though I
don't mind dropping data-default, which accounts for 6 of the
dependencies
On Tue, Apr 28, 2015 at 2:56 PM Thomas Tuegel ttue...@gmail.com wrote:
On Tue, Apr 28, 2015 at 3:21 AM, Michael Snoyman mich...@snoyman.com
wrote:
I have no intention of playing the minimal dependency game (though I
don't
mind dropping data-default, which accounts for 6 of the dependencies
On Wed, Apr 29, 2015 at 10:00 AM Herbert Valerio Riedel hvrie...@gmail.com
wrote:
On 2015-04-28 at 18:13:47 +0200, Michael Snoyman wrote:
[...]
Your analysis is accurate. There are some interesting approaches we could
take to further mitigate things. For example: newer versions of
cabal
On Tue, Apr 28, 2015, 6:08 PM Thomas Tuegel ttue...@gmail.com wrote:
On Tue, Apr 28, 2015 at 8:52 AM, Michael Snoyman mich...@snoyman.com
wrote:
Thank you :)
Yes, the code is part of the stackage-server code base, available here:
https://github.com/fpco/stackage-server/blob/master
On Tue, Apr 28, 2015 at 5:32 PM Herbert Valerio Riedel hvrie...@gmail.com
wrote:
On 2015-04-28 at 15:50:26 +0200, Michael Snoyman wrote:
[...]
PS: We shouldn't forget that there's also an existing deployed
cabal-install user-base we can't get rid off so easily, which may
still
On Tue, Apr 28, 2015 at 11:12 AM Herbert Valerio Riedel hvrie...@gmail.com
wrote:
On 2015-04-28 at 06:08:38 +0200, Michael Snoyman wrote:
[...]
I offered Duncan last week that I'd port cabal-install over to
http-client/http-client-tls to add SSL support. That offer still stands.
I did
-commons-0.1.12
http-client-0.4.11.2
http-client-openssl-0.2.0.1
On Tue, Apr 28, 2015 at 11:08 AM Herbert Valerio Riedel hvrie...@gmail.com
wrote:
On 2015-04-28 at 06:08:38 +0200, Michael Snoyman wrote:
[...]
I offered Duncan last week that I'd port cabal-install over to
http-client/http
A few months ago I noticed that pull request 2617[1] implements a change
I'd love to see in Cabal: not requiring a global package database for GHCs
that support this (7.6 and on). The change is small and self-contained, and
looks like a good one to me, but it hasn't been merged. Any chance someone
I'm +1 on nailing down an LTS release cycle, I've been pushing for it, and
planning that it would happen after the first few releases. I'm fine with
doing it starting with the next release if that's desired.
The cygwin/msys conflict is a problematic one. stack has more flexibility
addressing this
anywhere on your path.)
On Sunday, July 12, 2015, Michael Snoyman mich...@snoyman.com wrote:
I'm +1 on nailing down an LTS release cycle, I've been pushing for it,
and planning that it would happen after the first few releases. I'm fine
with doing it starting with the next release if that's
tance either.
> But there is `Distribution.Pretty.Pretty` instance (`prettyShow`).
>
> - Oleg
>
>
> On 20.02.2018 20:28, Michael Snoyman wrote:
> > Alright, I've updated the PR to use `Either SPDX.License License`:
> >
> > https://github.com/commercialhaskell/stack/pull/3878/com
Hi all,
Oleg mentioned to me on Reddit that a 2.2 branch has been cut for Cabal,
and recommended we try to upgrade Stack to it. I'm sharing information here
on that process in case it's useful to others, either as feedback on the
API changes, or help for others going through similar upgrades. If
oncept (IIRC it's converted to
> LicenseRef:OtherLicense which is valid SPDX-License-Id). This might be
> necessary if you plan to read (human readable) text back.
>
> Oleg
>
> On 20.02.2018 15:47, Michael Snoyman wrote:
> > Hi all,
> >
> > Oleg mentioned to me on Redd
b/32fea06a1023a507d7dc16b29f5425
> 38c0b55e46/Cabal/Distribution/Simple/Program/HcPkg.hs#L246
>
>
> On 20.02.2018 19:45, Michael Snoyman wrote:
> > I'm sorry, I'm not quite sure I understand your recommendation. Are
> > you saying that I should ideally replace all usages
Looks like it came through safely to me!
On Tue, Jun 4, 2019, 2:03 AM Simon Peyton Jones via cabal-devel <
cabal-devel@haskell.org> wrote:
> Dear Cabal-devs
>
> My earlier messages to cabal-devel was flagged as spam by the time it
> reached Michael and Carter. (Perhaps others too.)
>
> Gershom
28 matches
Mail list logo
