Open taktoa opened 7 years ago
@taktoa The Haddock documentation doesn't make it obvious, but the functions under http://hackage.haskell.org/package/lzma-0.0.0.3/docs/Codec-Compression-Lzma.html#g:6 are actually the field accessors. So you can in fact use record-update syntax such as e.g.
defaultDecompressParams { decompressAutoDecoder = True, decompressMemLimit = 16777216 }
Btw, the reason for not exposing the constructor is so that we don't have to perform major version bumps each time a new field is added to DecompressParams
or CompressParams
; so this way we only need to perform a minor version increment, as a new field is purely a backward compatible API addition.
Why do you believe that the deprecated .lzma format should be auto-detected by default?
Ah, my bad. Is there a way to convince Haddock to output more sane documentation for this?
Regarding the .lzma
format: on several occasions I've compressed files with the lzma
command line utility (resulting in a file in the deprecated format) and then tried to decompress them with this library only to be confronted by a relatively cryptic error. I think most users expect a library called lzma
to be able to decompress files produced by lzma
by default. If you think having support for a deprecated format is bad design, then at least add something to the documentation to warn naive users.
Good point. I'll try to add some visible hints in the documentation for both, the auto-decoder-default as well as the Haddock-rendering issue of showing field updaters as ordinary functions.
Fwiw, I went with what the default was with the liblzma
C library, whose default entrypoints are designed to accept .xz
only by default,
LZMA_FORMAT_ERROR = 7,
/**<
* \brief File format not recognized
*
* The decoder did not recognize the input as supported file
* format. This error can occur, for example, when trying to
* decode .lzma format file with lzma_stream_decoder,
* because lzma_stream_decoder accepts only the .xz format.
*/
There's currently no function exported from
Codec.Compression.Lzma
that allowsdefaultDecompressParams
to be customized. It seems to me that, this being the case, either the constructor/fields ofDecompressParams
should be exported, or, if this was the intended semantics, there is no point in exportingdecompressWith
orDecompressParams
at all. SinceLibLzma
is not an exposed module there is simply no way to create a value of typeDecompressParams
other than the default.The same argument also applies to
CompressParams
. The current interface is about as useful as a module with the following exports:So, IMO, the interface should be simplified to the above (if this is what is intended), or the constructor/fields for
CompressParams
/DecompressParams
should be exposed.BTW, unless I'm ignorant of some other factor,
decompressAutoDecoder
should probably default toTrue
.