doesn't build on ghc 7.6

[cartazio]

[1 of 1] Compiling Codec.Archive.Zip ( Codec/Archive/Zip.hs, dist/build/Codec/Archive/Zip.o )

Codec/Archive/Zip.hs:202:4: Couldn't match expected type time-1.4.0.1:Data.Time.Clock.UTC.UTCTime' with actual typeClockTime' In the pattern: TOD modEpochTime In a stmt of a 'do' block: (TOD modEpochTime ) <- getModificationTime path In the expression: do { isDir <- doesDirectoryExist path; let path' = zipifyFilePath $ normalise $ path ++ ...; contents <- if isDir then return B.empty else B.readFile path; (TOD modEpochTime _) <- getModificationTime path; .... }

the time update issue! :)

[jgm]

+++ Carter Tazio Schonwald [Sep 25 12 22:33 ]:

[1 of 1] Compiling Codec.Archive.Zip ( Codec/Archive/Zip.hs, dist/build/Codec/Archive/Zip.o )

Codec/Archive/Zip.hs:202:4: Couldn't match expected type time-1.4.0.1:Data.Time.Clock.UTC.UTCTime' with actual typeClockTime' In the pattern: TOD modEpochTime In a stmt of a 'do' block: (TOD modEpochTime ) <- getModificationTime path In the expression: do { isDir <- doesDirectoryExist path; let path' = zipifyFilePath $ normalise $ path ++ ...; contents <- if isDir then return B.empty else B.readFile path; (TOD modEpochTime _) <- getModificationTime path; .... }

the time update issue! :)

This is fixed in the github version. I would upload a new version to hackage, but as noted in my other comment there seems to be a problem with directory 1.2.

[tazjin]

What kind of issue are you having with directory 1.2? I'm using zip-archive in my hs-pkpass package and it works fine with GHC 7.6.1 and directory 1.2, though my only use of the package is extracting a single file from an archive.

Currently the fact that the Hackage version of zip-archive does not build is preventing me from releasing a new version of my package on Hackage, it won't build the docs.

[jgm]

+++ tazjin [Oct 14 12 10:48 ]:

What kind of issue are you having with directory 1.2?

This:

% cabal install directory
Resolving dependencies...
Configuring directory-1.2.0.0...
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for sys/types.h... (cached) yes
checking for unistd.h... (cached) yes
checking for sys/stat.h... (cached) yes
configure: creating ./config.status
config.status: creating include/HsDirectoryConfig.h
config.status: include/HsDirectoryConfig.h is unchanged
configure: WARNING: unrecognized options: --with-compiler, --with-gcc
Building directory-1.2.0.0...
Preprocessing library directory-1.2.0.0...
[1 of 1] Compiling System.Directory ( System/Directory.hs, dist/build/System/Directory.o )

System/Directory.hs:395:12:
    Ambiguous occurrence `try'
    It could refer to either `System.IO.Error.try',
                             imported from `System.IO.Error' at System/Directory.hs:86:1-22
                          or `Control.Exception.Base.try',
                             imported from `Control.Exception.Base' at System/Directory.hs:88:1-29

System/Directory.hs:419:17:
    Ambiguous occurrence `catch'
    It could refer to either `System.IO.Error.catch',
                             imported from `System.IO.Error' at System/Directory.hs:86:1-22
                          or `Control.Exception.Base.catch',
                             imported from `Control.Exception.Base' at System/Directory.hs:88:1-29

System/Directory.hs:485:23:
    Ambiguous occurrence `try'
    It could refer to either `System.IO.Error.try',
                             imported from `System.IO.Error' at System/Directory.hs:86:1-22
                          or `Control.Exception.Base.try',
                             imported from `Control.Exception.Base' at System/Directory.hs:88:1-29

System/Directory.hs:960:4:
    Ambiguous occurrence `catch'
    It could refer to either `System.IO.Error.catch',
                             imported from `System.IO.Error' at System/Directory.hs:86:1-22
                          or `Control.Exception.Base.catch',
                             imported from `Control.Exception.Base' at System/Directory.hs:88:1-29

System/Directory.hs:974:4:
    Ambiguous occurrence `catch'
    It could refer to either `System.IO.Error.catch',
                             imported from `System.IO.Error' at System/Directory.hs:86:1-22
                          or `Control.Exception.Base.catch',
                             imported from `Control.Exception.Base' at System/Directory.hs:88:1-29
cabal: Error: some packages failed to install:
directory-1.2.0.0 failed during the building phase. The exception was:
ExitFailure 1

I'm using GHC 7.4. Perhaps there has been a change in base that affects try and catch?

I'm using zip-archive in my hs-pkpass package and it works fine with GHC 7.6.1 and directory 1.2, though my only use of the package is extracting a single file from an archive.

Currently the fact that the Hackage version of zip-archive does not build is preventing me from releasing a new version of my package on Hackage, it won't build the docs.

-- Reply to this email directly or [1]view it on GitHub. [Jshd8sI44GVrKZBvymxqKI1tAR5dLUorWYkP5X7eG54FvPXCZ1fv5PUoXaoIV_eg.gif]

References

1. https://github.com/jgm/zip-archive/issues/4#issuecomment-9423581

[tazjin]

Yes, these functions are no longer in System.IO.Error (see http://hackage.haskell.org/packages/archive/base/4.6.0.0/doc/html/System-IO-Error.html ) - they were already marked as deprecated and have now been removed.

The new directory package is apparently only intended for use with GHC >= 7.6.1.

The patch that was recently applied ( @f91df6fec9b9a510fabd1e57da32ba9f1799ad2a ) should dynamically switch between directory 1.1.* and directory 1.2* depending on the installed version - I'll try that though to be sure.

[tazjin]

I've tried it and I can build the current Github version of zip-archive on GHC 7.4.1 and 7.6.1

[jgm]

Yes, after a 'cabal update' I can now install directory 1.2.0.1. Good.

+++ tazjin [Oct 14 12 14:09 ]:

I've tried it and I can build the current Github version of zip-archive on GHC 7.4.1 and 7.6.1

-- Reply to this email directly or [1]view it on GitHub. [Jshd8sI44GVrKZBvymxqKI1tAR5dLUorWYkP5X7eG54FvPXCZ1fv5PUoXaoIV_eg.gif]

References

1. https://github.com/jgm/zip-archive/issues/4#issuecomment-9427785

[tazjin]

I guess it would be possible to just use directory >= 1.2 now, since it works for GHC pre 7.6.1 as well? That would remove the need for the CPP flag that is currently in and could allow you to push to Hackage ;-)

[jgm]

Just uploaded 0.1.2.1.

Note: there's a problem with recent binary, too. For now I've constrained to binary < 0.6.

+++ tazjin [Oct 15 12 14:26 ]:

I guess it would be possible to just use directory >= 1.2 now, since it works for GHC pre 7.6.1 as well? That would remove the need for the CPP flag that is currently in and could allow you to push to Hackage ;-)

-- Reply to this email directly or [1]view it on GitHub. [VSwkxVEeA99YeK9Uz0w5k0AlSDBzHtdF-PnJQeSFycWMOyVCLC0vqX_gt2AQYcRE.gif]

References

1. https://github.com/jgm/zip-archive/issues/4#issuecomment-9462310

[cartazio]

whats the problem with recent binary versions?

[jgm]

They decided to remove a couple of the combinators that I was using (lookAhead, lookAheadM).

+++ Carter Tazio Schonwald [Oct 16 12 11:49 ]:

whats the problem with recent binary versions?

— Reply to this email directly or [1]view it on GitHub. [J6T91GIPIyhU-8ti4GCGP7AlC2fiocPKodp06RQqyLwNimHVO5Kgwv-OF7gNI_B8.gif]

References

1. https://github.com/jgm/zip-archive/issues/4#issuecomment-9501970

[cartazio]

you could just add a module that you conditionally import with the code!

-- | Run @ga@, but return without consuming its input. -- Fails if @ga@ fails. lookAhead :: Get a -> Get a lookAhead ga = do s <- get a <- ga put s return a

-- | Like 'lookAhead', but consume the input if @gma@ returns 'Just _'. -- Fails if @gma@ fails. lookAheadM :: Get (Maybe a) -> Get (Maybe a) lookAheadM gma = do s <- get ma <- gma when (isNothing ma) $ put s return ma

-- | Like 'lookAhead', but consume the input if @gea@ returns 'Right '. -- Fails if @gea@ fails. lookAheadE :: Get (Either a b) -> Get (Either a b) lookAheadE gea = do s <- get ea <- gea case ea of Left -> put s _ -> return () return ea

-- | Get the next up to @n@ bytes as a lazy ByteString, without consuming them. uncheckedLookAhead :: Int64 -> Get L.ByteString uncheckedLookAhead n = do S s ss _ <- get if n <= fromIntegral (B.length s) then return (L.fromChunks [B.take (fromIntegral n) s]) else return $ L.take n (s join ss)

[cartazio]

altenratively, what would be needed to rewrite the broken code to support the decoder a api that they've transitioned to?

[jgm]

I'm not sure. Probably it could be rewritten so that it doesn't use lookaheads at all. The lookaheads were convenient in allowing me to split different parts of the parsing into different functions.

+++ Carter Tazio Schonwald [Oct 16 12 12:17 ]:

altenratively, what would be needed to rewrite the broken code to support the decoder a api that they've transitioned to?

— Reply to this email directly or [1]view it on GitHub. [J6T91GIPIyhU-8ti4GCGP7AlC2fiocPKodp06RQqyLwNimHVO5Kgwv-OF7gNI_B8.gif]

References

1. https://github.com/jgm/zip-archive/issues/4#issuecomment-9502925

[cartazio]

ok, cool, I'll try to find some time to see if i can patch things up to use the new binary api. The new binary api is sort of attoparsec in style, so (hopefully) that means it yields really nice performance improvements too!

[jgm]

Fixed now.