Compile failure with transient-0.5.3

[hvr]

I just noticed the compile failure below w/ the latest release

(see also http://104.239.175.197:8080/package/transient for an overall status)

Configuring component lib from transient-0.5.3...
Preprocessing library transient-0.5.3...
[1 of 6] Compiling Transient.Internals ( src/Transient/Internals.hs, /tmp/matrix-worker/1490802822/dist-newstyle/build/x86_64-linux/ghc-8.0.2/transient-0.5.3/build/Transient/Internals.o )
[2 of 6] Compiling Transient.Indeterminism ( src/Transient/Indeterminism.hs, /tmp/matrix-worker/1490802822/dist-newstyle/build/x86_64-linux/ghc-8.0.2/transient-0.5.3/build/Transient/Indeterminism.o )
[3 of 6] Compiling Transient.Logged ( src/Transient/Logged.hs, /tmp/matrix-worker/1490802822/dist-newstyle/build/x86_64-linux/ghc-8.0.2/transient-0.5.3/build/Transient/Logged.o )

src/Transient/Logged.hs:74:54: error:
    • Couldn't match expected type ‘Data.ByteString.Lazy.Internal.ByteString’
                  with actual type ‘BS.ByteString’
      NB: ‘BS.ByteString’ is defined in ‘Data.ByteString.Internal’
          ‘Data.ByteString.Lazy.Internal.ByteString’
            is defined in ‘Data.ByteString.Lazy.Internal’
    • In the first argument of ‘deserialize’, namely ‘logstr’
      In the second argument of ‘seq’, namely ‘deserialize logstr’
      In the expression: BS.length logstr `seq` deserialize logstr

src/Transient/Logged.hs:195:33: error:
    • Couldn't match expected type ‘Data.ByteString.Lazy.Internal.ByteString’
                  with actual type ‘Data.ByteString.Builder.Internal.Builder’
    • In the second argument of ‘(==)’, namely ‘show1 n’
      In the expression: s == show1 n
      In the expression:
        if s == show1 n then
            do { setData $ Log recover t full;
                 return $ Just () }
        else
            return Nothing

[agocorona]

Thanks Mistakenly sent from a development branch I upladed a new version. Thanks a lot for the matrix

[hvr]

@agocorona I see; I went ahead and blacklisted that broken release (see https://hackage.haskell.org/package/transient-0.5.3/revisions/) and I'll probably fixup the meta-data for the previous transient releases so the cabal solver can avoid picking install-plans which would result in compile failures (IOW, this will turn the red cells in the matrix build-report into dark green cells).

I've also filed #45 which should help with this in the future.

[agocorona]

Thanks!

the pull request has errors in some compilations in Travis related with the limits of base for older versions of GHC

https://travis-ci.org/transient-haskell/transient/builds/216655477

Can I relax the lower limit of base for your pull request? I'm a bit lost in the middle of many changes in the transient suite.

[hvr]

@agocorona oh sure (actually I just updated the PR myself), I didn't notice that you actually test against GHC 7.10.2 too... :-)

[agocorona]

Great! I merged it.