Closed samoconnor closed 8 years ago
I have mixed feelings about this PR. On one hand, these seem like pretty useful functions.
On the other, all other gz
prefixed functions in GZip.jl
are simple wrappers around the same functions provided by zlib. They're exposed and exported, but the higher level access is really meant to be done through Julia's IO
interface.
It's also the case that, while this library isn't deprecated, Libz.jl will probably give you a bit better performance. (Although it's function interface is rather nonstandard....)
(Travis failures are unrelated.)
closing in favour of https://github.com/BioJulia/Libz.jl/pull/12
Despite my belief that Libz
is probably a better library to use for new projects, I would be in favor of updating GZip.jl
to follow the convention set by https://github.com/JuliaLang/julia/pull/14660
.
I'm not as concerned about the gz*
functions, but more the read*
functions (although more of an argument could be made for the former now...)
Hi @kmsquire,
Fair enough, it's probably easiest for someone with commit access to Libz to just paste in sorting like the following:
readgz(filename::AbstractString) = gzopen(read, filename)
readgzstring(filename::AbstractString) = gzopen(readstring, filename)
writegz(filename::AbstractString, data) = gzopen(io -> write(io, data), filename, "w")
Just curious, are the changes to read
and readstring
backwards compatible? This package still works with Julia v0.3
, so wondering if any of those changes would require a bit more scaffolding.
I don't see why the new read
methods and readstring
couldn't be back ported to v0.3 or v0.4 without breaking anything.
Anything that adds or changes functionality probably won't actually be backported--my understanding for Julia is that, by convention (and following Semantic Versioning), patch version number changes (changing y
for v0.x.y
) imply only bug fixes.
(That, and backporting would probably inadvertently break someone's code when they target the new API and then try to run on a slightly older version of Julia.)
But, they could be added to Compat.jl
, and then used in code targeting multiple Julia versions.
Indeed, @samoconnor, could you add the changes you made in https://github.com/JuliaLang/julia/pull/14660 to Compat.jl?
Convenience functions to read/write directly from/to a named file.
I'm doing a cleanup of my local stash of convenience functions and thought that these might be generally useful.