Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doesn't build on ghc 7.6 #4

Closed
cartazio opened this issue Sep 26, 2012 · 15 comments
Closed

doesn't build on ghc 7.6 #4

cartazio opened this issue Sep 26, 2012 · 15 comments

Comments

@cartazio
Copy link

[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
Copy link
Owner

jgm commented Sep 26, 2012

+++ 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
Copy link

tazjin commented Oct 14, 2012

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
Copy link
Owner

jgm commented Oct 14, 2012

+++ 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. doesn't build on ghc 7.6 #4 (comment)

@tazjin
Copy link

tazjin commented Oct 14, 2012

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
Copy link

tazjin commented Oct 14, 2012

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
Copy link
Owner

jgm commented Oct 15, 2012

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. doesn't build on ghc 7.6 #4 (comment)

@tazjin
Copy link

tazjin commented Oct 15, 2012

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
Copy link
Owner

jgm commented Oct 16, 2012

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. doesn't build on ghc 7.6 #4 (comment)

@cartazio
Copy link
Author

whats the problem with recent binary versions?

@jgm
Copy link
Owner

jgm commented Oct 16, 2012

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. doesn't build on ghc 7.6 #4 (comment)

@cartazio
Copy link
Author

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
Copy link
Author

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

@jgm
Copy link
Owner

jgm commented Oct 16, 2012

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. doesn't build on ghc 7.6 #4 (comment)

@cartazio
Copy link
Author

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
Copy link
Owner

jgm commented Dec 31, 2012

Fixed now.

@jgm jgm closed this as completed Dec 31, 2012
jgm pushed a commit that referenced this issue Dec 31, 2012
joshado pushed a commit to joshado/pkgsrc-wip that referenced this issue Nov 6, 2013
changes:
0.1.3.4
  - mv Codec/Archive/Zip.hs src/Codec/Archive/Zip.hs

0.1.3.3
  - Add back binary 0.5 support

0.1.3.2
  - Fixed digital signature magic numbers

0.1.3.1
  - fix build failure against directory-1.2 (missing liftM)
      Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

0.1.3
  - Rewrote to use new binary API (binary >= 0.6).
      Closes jgm/zip-archive#7
      Closes jgm/zip-archive#4
  - Removed unneeded pragma.
  - Removed unnecessary import.

0.1.2.1
  - Added proper cabal test suite.
  - Constrain binary to < 0.6, since 0.6 removes lookAhead.
      We'll need to find a workaround going forward, but for now
      the constraint is needed in order for zip-archive to compile.
  - Support directory 1.2
      The type of getModificationTime has changed, leading to some CPP

0.1.1.8
  - Fix parsing of "version needed to extract" field
      This field consists of two bytes, upper one indicating host OS and
      lower one indicating version of Zip (de)compressor. Tomake sure if
      one can unpack given archive it's only lower byte which is needed to
      be checked, but library used to check both.

0.1.1.7
  - Correctly calculate length of file paths.
      Be sure to use zipifyFilePath and convert to UTF8 before
      calculating length.
  - Fixed problems with zipifyFilePath:
      + Don't ever put drive in zip file path!
      + Don't put leading "./" supplied by some versions of
        System.FilePath.splitDirectories.
  - Fixed Test.hs so it will pick up right zip executable on Mac OSX.

0.1.1.6
  - epochTimeToMSDOSDateTime: return minimum DOS datetime for earlier epoch times.
      The previous behavior was just to crash. Epoch times start in 1970,
      while DOS datetimes start in 1980.
      Returning the minimum seems the best solution,
      since you simply can't create a zip archive entry with an earlier time.
      This is also the solution used by zip30.
      Thanks to Radoslav Dorcik for reporting.

0.1.1.5
  - Fixed warnings uncovered by GHC 6.12.

0.1.1.4
  - Added explicit upper bound for base version
  - Removed -O2 option
  - Version bump in Zip executable
  - Handle data descriptor record
      OpenOffice-created zip archives sometimes use the "data descriptor
      record" to store checksums and lengths.
      getLocalFile now checks the general purpose bit flags to see
      if there is a data descriptor record; if there is,
      it ignores the compressed size field and instead reads data
      until the data descriptor record is encountered.

      This patch should fix problems reading ODS and other OpenOffice created
      zip archives.
      Thanks to Joel Lehtone for calling the problem to my attention.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants