Using features from containers-0.5

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Using features from containers-0.5

Joachim Breitner-2
Hi, especially to Austin with his Release Manager hat on,

in my nested-cpr branch I have a few nice patches that clean up,
refactor and especially Note?ify the demand analyzer. I?d like to see
both my branch to be shorter, and to see those improvements in the
mainline independent of whether nested-cpr will turn out to be useful,
so I invested some time to rebase my branch and move all these patches
below those that actually change the code.

The result is the contents of the wip/nested-cpr branch up to and
including the patch ?Make types of bothDmdType more precise?, which I
find especially useful (currently c26d31, but I tend to rebase while I
add more polish or remove typos). I am confident that this is a pure
refactoring (validate passes without changes to the testsuite, nofib
shows identical Allocation numbers), and I?d like to push this to
master.

But one of the patches, ?Clarify the default demand on demand
environments? (currently 2b6a6a), uses a function from containers
(IntMap.mergeWithKey) which was only added in containers-0.5, which
ships with GHC 7.6, but not with 7.4. But especially that change is
nice, as removes the confusing modifyEnv function and makes the code
(IMHO) easier to understand.

What is the policy here? Is it ok to expect the user to upgrade the
containers package of the bootstrap compiler? Or can we start building
containers before stage-1, so that we can expect the new code (but when
I tried it seems that this needs some adjustments to the build system)?
Or should I add an alternative definition via CPP in
compiler/utils/UniqFM.lhs? Or is it not worth it and I should wait until
7.9 (which would then drop the requirement to be bootstrappable with
7.4, right?)


Thanks,
Joachim

--
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131215/3dbbda2f/attachment.sig>

Reply | Threaded
Open this post in threaded view
|

Using features from containers-0.5

Simon Marlow-7
GHC's policy is:

  - we do not require that the user installs any libraries or
    upgrades any libraries in order to build GHC.

  - we support bootstrapping with the two previous major releases
    of GHC.

So that means, after the 7.8 release, the HEAD will support only 7.6 and
7.8.  So that means you'll be able to use containers-0.5 after the 7.8
branch split (but not merge any patches that require it onto the branch).

The other way around this is to make containers into a zero-boot
package, but we typically wouldn't do this for just one function.  The
main use case for this is Cabal, which in the past has changed quickly
and in tandem with changes in GHC, so we want stage 1 to see the same
Cabal as stage 2.

Cheers,
Simon

On 15/12/2013 16:35, Joachim Breitner wrote:

> Hi, especially to Austin with his Release Manager hat on,
>
> in my nested-cpr branch I have a few nice patches that clean up,
> refactor and especially Note?ify the demand analyzer. I?d like to see
> both my branch to be shorter, and to see those improvements in the
> mainline independent of whether nested-cpr will turn out to be useful,
> so I invested some time to rebase my branch and move all these patches
> below those that actually change the code.
>
> The result is the contents of the wip/nested-cpr branch up to and
> including the patch ?Make types of bothDmdType more precise?, which I
> find especially useful (currently c26d31, but I tend to rebase while I
> add more polish or remove typos). I am confident that this is a pure
> refactoring (validate passes without changes to the testsuite, nofib
> shows identical Allocation numbers), and I?d like to push this to
> master.
>
> But one of the patches, ?Clarify the default demand on demand
> environments? (currently 2b6a6a), uses a function from containers
> (IntMap.mergeWithKey) which was only added in containers-0.5, which
> ships with GHC 7.6, but not with 7.4. But especially that change is
> nice, as removes the confusing modifyEnv function and makes the code
> (IMHO) easier to understand.
>
> What is the policy here? Is it ok to expect the user to upgrade the
> containers package of the bootstrap compiler? Or can we start building
> containers before stage-1, so that we can expect the new code (but when
> I tried it seems that this needs some adjustments to the build system)?
> Or should I add an alternative definition via CPP in
> compiler/utils/UniqFM.lhs? Or is it not worth it and I should wait until
> 7.9 (which would then drop the requirement to be bootstrappable with
> 7.4, right?)
>
>
> Thanks,
> Joachim
>
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

Reply | Threaded
Open this post in threaded view
|

Using features from containers-0.5

Joachim Breitner-2
Hi,

Am Montag, den 16.12.2013, 10:21 +0000 schrieb Simon Marlow:
> So that means, after the 7.8 release, the HEAD will support only 7.6 and
> 7.8.  So that means you'll be able to use containers-0.5 after the 7.8
> branch split (but not merge any patches that require it onto the branch).
>
> The other way around this is to make containers into a zero-boot
> package, but we typically wouldn't do this for just one function.

ok; I changed the code to use the older containers functions, with the
new implementation in a comment, to be used later.

Greetings,
Joachim

--
Joachim ?nomeata? Breitner
  mail at joachim-breitner.de ? http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  ? GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131216/25aaa854/attachment.sig>