Ryan Newton | 14 Jan 17:41 2014
Picon

Releasing containers 0.5.3.2 -- before GHC 7.8?

Hi guys,

I'm wondering if we can do a hackage release of 0.5.3.2?  That "splitRoot" function is in there, and my ability to deploy parallel code that uses containers depends on people getting it!  Are there any other changes since 0.5.3.1?

Replacing containers seems like a real pain for end users, so it would be great if 0.5.3.2 could come with GHC 7.8.  Currently, it looks like the GHC repo is up to date in that it includes 0.5.3.1.

I realize it is late days for this, but:
  • It's been a month since we put splitRoot in; I've been using it heavily and it I'm pretty confident that it's correct.  (It's so simple!)
  • Nothing else is touched, so there is very little liability associated with this version bump.
And, as you know, if we don't make this round it's a long latency before the next chance.  That is, before we can expect people to do parallel folds over Data.Set or Data.Map without installation headache.

Any objections?
  -Ryan

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Roman Cheplyaka | 14 Jan 18:01 2014

Re: Releasing containers 0.5.3.2 -- before GHC 7.8?

* Ryan Newton <rrnewton <at> gmail.com> [2014-01-14 11:41:48-0500]
> Replacing containers seems like a real pain for end users

Is it a real pain? Why?

I just tried 'cabal install containers', and it went flawlessly.

To make it clear, I'm not in any way opposed to containers upgrade, but
that phrase struck me as odd.

The only issue I'm aware of is related to the GHC API, but
high-performance parallel algorithms and the GHC API are rarely used
together in the same project.

Roman
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ryan Newton | 14 Jan 20:19 2014
Picon

Re: Releasing containers 0.5.3.2 -- before GHC 7.8?




On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka <roma-e10UterjXHviB9QmIjCX8w@public.gmane.org> wrote:
* Ryan Newton <rrnewton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [2014-01-14 11:41:48-0500]
> Replacing containers seems like a real pain for end users

Is it a real pain? Why?

One thing I ran into is that cabal sandboxes want consistent dependencies.  And when users get to this point where they need to grab our latest containers, they've got a bunch of core/haskell platform packages that depend on the old containers.

I didn't mean that there was anything difficult about containers itself, just that almost everything else depends on it.

  -Ryan


_______________________________________________
ghc-devs mailing list
ghc-devs@...
http://www.haskell.org/mailman/listinfo/ghc-devs
Carter Schonwald | 14 Jan 20:23 2014
Picon

Re: Releasing containers 0.5.3.2 -- before GHC 7.8?

have you tried installing a newer version of containers yourself globally, and making the other one hidden? Or just making the global one ghc comes with hidden?


On Tue, Jan 14, 2014 at 2:19 PM, Ryan Newton <rrnewton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:



On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka <roma-e10UterjXHviB9QmIjCX8w@public.gmane.org> wrote:
* Ryan Newton <rrnewton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [2014-01-14 11:41:48-0500]
> Replacing containers seems like a real pain for end users

Is it a real pain? Why?

One thing I ran into is that cabal sandboxes want consistent dependencies.  And when users get to this point where they need to grab our latest containers, they've got a bunch of core/haskell platform packages that depend on the old containers.

I didn't mean that there was anything difficult about containers itself, just that almost everything else depends on it.

  -Ryan



_______________________________________________
ghc-devs mailing list
ghc-devs-HC+Z4NTRIlBAfugRpC6u6w@public.gmane.org
http://www.haskell.org/mailman/listinfo/ghc-devs


_______________________________________________
ghc-devs mailing list
ghc-devs@...
http://www.haskell.org/mailman/listinfo/ghc-devs
Reid Barton | 14 Jan 21:15 2014
Picon

Re: Releasing containers 0.5.3.2 -- before GHC 7.8?

On Tue, Jan 14, 2014 at 2:19 PM, Ryan Newton <rrnewton <at> gmail.com> wrote:
On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka <roma-e10UterjXHviB9QmIjCX8w@public.gmane.org> wrote:
* Ryan Newton <rrnewton-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> [2014-01-14 11:41:48-0500]
> Replacing containers seems like a real pain for end users

Is it a real pain? Why?

One thing I ran into is that cabal sandboxes want consistent dependencies.  And when users get to this point where they need to grab our latest containers, they've got a bunch of core/haskell platform packages that depend on the old containers.

I didn't mean that there was anything difficult about containers itself, just that almost everything else depends on it.

In addition to the general pain of updating packages at the base of the dependency hierarchy, there is also the fact that the template-haskell package depends on containers. As far as I know upgrading template-haskell is impossible, or at least a Very Bad Idea, so any library that wants to use an updated version of containers can't use template-haskell, or even be linked into an application that uses template-haskell directly or through another library.

As far as I am concerned as a GHC user, versions of containers that aren't the one that came with my GHC might as well not exist. For example if I see that a package has a constraint "containers >= 0.10", I just assume I cannot use the library with GHC 7.4. Thus I'm strongly in favor of synchronizing containers releases with releases of GHC.

Regards,
Reid Barton
_______________________________________________
ghc-devs mailing list
ghc-devs@...
http://www.haskell.org/mailman/listinfo/ghc-devs
Carter Schonwald | 14 Jan 21:40 2014
Picon

Re: Releasing containers 0.5.3.2 -- before GHC 7.8?

ok, thats a good point


On Tue, Jan 14, 2014 at 3:15 PM, Reid Barton <rwbarton <at> gmail.com> wrote:
On Tue, Jan 14, 2014 at 2:19 PM, Ryan Newton <rrnewton <at> gmail.com> wrote:
On Tue, Jan 14, 2014 at 12:01 PM, Roman Cheplyaka <roma <at> ro-che.info> wrote:
* Ryan Newton <rrnewton <at> gmail.com> [2014-01-14 11:41:48-0500]
> Replacing containers seems like a real pain for end users

Is it a real pain? Why?

One thing I ran into is that cabal sandboxes want consistent dependencies.  And when users get to this point where they need to grab our latest containers, they've got a bunch of core/haskell platform packages that depend on the old containers.

I didn't mean that there was anything difficult about containers itself, just that almost everything else depends on it.

In addition to the general pain of updating packages at the base of the dependency hierarchy, there is also the fact that the template-haskell package depends on containers. As far as I know upgrading template-haskell is impossible, or at least a Very Bad Idea, so any library that wants to use an updated version of containers can't use template-haskell, or even be linked into an application that uses template-haskell directly or through another library.

As far as I am concerned as a GHC user, versions of containers that aren't the one that came with my GHC might as well not exist. For example if I see that a package has a constraint "containers >= 0.10", I just assume I cannot use the library with GHC 7.4. Thus I'm strongly in favor of synchronizing containers releases with releases of GHC.

Regards,
Reid Barton

_______________________________________________
ghc-devs mailing list
ghc-devs <at> haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Milan Straka | 14 Jan 22:33 2014
Picon

Re: Releasing containers 0.5.3.2 -- before GHC 7.8?

Hi Johan,

I think releasing 0.5.4 is a good idea. Could I ask you to do the
release as usual, please?

We added the splitRoot function, so it should really be 0.5.4 and not
only 0.5.3.2. Actually, we added Functor instance to Graph.SCC and
Functor and Applicative instances to Graph.SetM, but Graph is rarely
used, so I would deliberately break PVP and not do a major version bump.

Thanks,
cheers,
Milan

> -----Original message-----
> From: Ryan Newton <rrnewton <at> gmail.com>
> Sent: 14 Jan 2014, 11:41
>
> Hi guys,
> 
> I'm wondering if we can do a hackage release of 0.5.3.2?  That "splitRoot"
> function is in there, and my ability to deploy parallel code that uses
> containers depends on people getting it!  Are there any other changes since
> 0.5.3.1?
> 
> Replacing containers seems like a real pain for end users, so it would be
> great if 0.5.3.2 could come with GHC 7.8.  Currently, it looks like the GHC
> repo is up to date in that it includes 0.5.3.1.
> 
> I realize it is late days for this, but:
> 
>    - It's been a month since we put splitRoot in; I've been using it
>    heavily and it I'm pretty confident that it's correct.  (It's so simple!)
>    - Nothing else is touched, so there is very little liability associated
>    with this version bump.
> 
> And, as you know, if we don't make this round it's a long latency before
> the next chance.  That is, before we can expect people to do parallel folds
> over Data.Set or Data.Map without installation headache.
> 
> Any objections?
>   -Ryan
Johan Tibell | 14 Jan 22:47 2014
Picon

Re: Releasing containers 0.5.3.2 -- before GHC 7.8?

I'll make a release in the next few days.


On Tue, Jan 14, 2014 at 10:33 PM, Milan Straka <fox-+ZI9xUNit7I@public.gmane.org> wrote:
Hi Johan,

I think releasing 0.5.4 is a good idea. Could I ask you to do the
release as usual, please?

We added the splitRoot function, so it should really be 0.5.4 and not
only 0.5.3.2. Actually, we added Functor instance to Graph.SCC and
Functor and Applicative instances to Graph.SetM, but Graph is rarely
used, so I would deliberately break PVP and not do a major version bump.

Thanks,
cheers,
Milan

> -----Original message-----
> From: Ryan Newton <rrnewton <at> gmail.com>
> Sent: 14 Jan 2014, 11:41
>
> Hi guys,
>
> I'm wondering if we can do a hackage release of 0.5.3.2?  That "splitRoot"
> function is in there, and my ability to deploy parallel code that uses
> containers depends on people getting it!  Are there any other changes since
> 0.5.3.1?
>
> Replacing containers seems like a real pain for end users, so it would be
> great if 0.5.3.2 could come with GHC 7.8.  Currently, it looks like the GHC
> repo is up to date in that it includes 0.5.3.1.
>
> I realize it is late days for this, but:
>
>    - It's been a month since we put splitRoot in; I've been using it
>    heavily and it I'm pretty confident that it's correct.  (It's so simple!)
>    - Nothing else is touched, so there is very little liability associated
>    with this version bump.
>
> And, as you know, if we don't make this round it's a long latency before
> the next chance.  That is, before we can expect people to do parallel folds
> over Data.Set or Data.Map without installation headache.
>
> Any objections?
>   -Ryan

_______________________________________________
ghc-devs mailing list
ghc-devs@...
http://www.haskell.org/mailman/listinfo/ghc-devs
Herbert Valerio Riedel | 16 Jan 08:54 2014
Picon

Re: Releasing containers 0.5.3.2 -- before GHC 7.8?

On 2014-01-14 at 17:41:48 +0100, Ryan Newton wrote:
> I'm wondering if we can do a hackage release of 0.5.3.2?  That "splitRoot"
> function is in there, and my ability to deploy parallel code that uses
> containers depends on people getting it!  Are there any other changes since
> 0.5.3.1?
>
> Replacing containers seems like a real pain for end users, so it would be
> great if 0.5.3.2 could come with GHC 7.8.  Currently, it looks like the GHC
> repo is up to date in that it includes 0.5.3.1.

Done (actually is do.. erm... containers-0.5.4.0):

http://git.haskell.org/ghc.git/commitdiff/69cf5c4cb8aba309e5c495008b69089e5431a095

Cheers,
  hvr

Gmane