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
Comments
+++ Carter Tazio Schonwald [Sep 25 12 22:33 ]:
This is fixed in the github version. I would upload a new |
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. |
+++ tazjin [Oct 14 12 10:48 ]:
This:
I'm using GHC 7.4. Perhaps there has been a change in base that affects try and catch?
|
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. |
I've tried it and I can build the current Github version of zip-archive on GHC 7.4.1 and 7.6.1 |
Yes, after a 'cabal update' I can now install directory 1.2.0.1. +++ tazjin [Oct 14 12 14:09 ]:
|
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 ;-) |
Just uploaded 0.1.2.1. Note: there's a problem with recent binary, too. For now I've +++ tazjin [Oct 15 12 14:26 ]:
|
whats the problem with recent binary versions? |
They decided to remove a couple of the combinators that +++ Carter Tazio Schonwald [Oct 16 12 11:49 ]:
|
you could just add a module that you conditionally import with the code! -- | Run @ga@, but return without consuming its input. -- | Like 'lookAhead', but consume the input if @gma@ returns 'Just _'. -- | Like 'lookAhead', but consume the input if @gea@ returns 'Right _'. -- | Get the next up to @n@ bytes as a lazy ByteString, without consuming them. |
altenratively, what would be needed to rewrite the broken code to support the decoder a api that they've transitioned to? |
I'm not sure. Probably it could be rewritten so that it +++ Carter Tazio Schonwald [Oct 16 12 12:17 ]:
|
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! |
Fixed now. |
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.
[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 type
ClockTime'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! :)
The text was updated successfully, but these errors were encountered: