deepseq-generics 0.2.0.0

[DanBurton]

deepseq-generics-0.2.0.0 depended on by:

• pandoc-1.16 (==0.1.*). No maintainer. @jgm
• pandoc-types-1.16 (==0.1.*). No maintainer. @jgm

[DanBurton]

If this issue is resolved, it may become blocked by #1094.

[jgm]

OK, I've released pandoc-types-1.16.0.1, which should
help with this. (It still depends on deepseq-generics
for ghc < 7.10, but for ghc 7.10 it just uses deepseq.)

+++ Dan Burton [Jan 03 16 10:30 ]:

deepseq-generics-0.2.0.0 depended on by:
* pandoc-1.16 (==0.1.). No maintainer. [1]@jgm
* pandoc-types-1.16 (==0.1.). No maintainer. [2]@jgm

—
Reply to this email directly or [3]view it on GitHub.

References

1. https://github.com/jgm
2. https://github.com/jgm
3. deepseq-generics 0.2.0.0 #1096

[peti]

I thought that deepseq-generics is obsolete with modern versions of GHC? deepseq versions 1.4.x or later have that functionality builtin.

[peti]

According to http://hackage.haskell.org/package/deepseq-1.4.1.2/docs/Control-DeepSeq.html#v:rnf:

Starting with GHC 7.2, you can automatically derive instances for types possessing a Generic instance.

{-# LANGUAGE DeriveGeneric #-}

import GHC.Generics (Generic)
import Control.DeepSeq

data Foo a = Foo a String
             deriving (Eq, Generic)

instance NFData a => NFData (Foo a)

data Colour = Red | Green | Blue
              deriving Generic

instance NFData Colour

[jgm]

+++ Peter Simons [Jan 08 16 09:29 ]:

I thought that deepseq-generics is obsolete with modern versions of
GHC? deepseq versions 1.4.x or later have that functionality builtin.

Yes, pandoc-types uses deepseq 1.4.x when we can, and deepseq-generics for older GHCs.

[bergmark]

@jgm pandoc still depends on deepseq-generics unconditionally.

This is also blocked by #1094

[jgm]

+++ Adam Bergmark [Jan 11 16 02:46 ]:

[1]@jgm pandoc still depends on deepseq-generics unconditionally.

No it doesn't (pandoc-types-1.16.0.1) -- it's conditional on the
ghc version:

if impl(ghc < 7.10)
   Build-depends:   deepseq-generics >= 0.1 && < 0.2
 else
   Build-depends:   deepseq >= 1.4.1 && < 1.5

[bergmark]

https://github.com/jgm/pandoc/blob/master/pandoc.cabal#L279

[jgm]

+++ Adam Bergmark [Jan 11 16 12:01 ]:

[1]https://github.com/jgm/pandoc/blob/master/pandoc.cabal#L279

Ah, sorry...I wasn't even aware it was used there.

[bergmark]

Thanks! This is resolved but pandoc is still held back by (edit: typo) #1094 so I'll track it there.

[jgm]

Note, I haven't actually released a new version yet, but
I can probably do that in the next week or so.

+++ Adam Bergmark [Jan 11 16 16:08 ]:

Thanks! This is resolved but pandoc is still held back by [1]#1096 so
I'll track it there.

—
Reply to this email directly or [2]view it on GitHub.

References

1. deepseq-generics 0.2.0.0 #1096
2. deepseq-generics 0.2.0.0 #1096 (comment)

[bergmark]

Sorry, my bad this time. I thought I checked hackage...

[DanBurton]

I've reopened this issue to properly track the following.

deepseq-generics-0.2.0.0 depended on by:

• cryptol-2.3.0 (==0.1.*). Adam C. Foltzer acfoltzer@galois.com @acfoltzer. @GaloisInc

Is there any compelling reason to push for deepseq-generics-0.2 in lts-5, or are we fine with 0.1?

[acfoltzer]

AFAIK the main change with 0.2 is GHC 8 compatibility, so if lts-5 is targeting 7.10.3, there's probably limited benefit

[snoyberg]

Issue closed in the GHC 8 release. If packages have been removed temporarily, please sent a pull request to update build-constraints.yaml (search for GHC 8 or BLOCKED).