bzstream
The file builtins/bzstream.e (not an autoinclude) contains routines for in memory bzip handlng,
using any block size (all the way down to just 1 byte).
The distribution includes builtins/bz32.dll and builtins/bz64.dll however while I foresee no problems it has not been tested on Linux and the equivalent .so files must be obtained by other means, perhaps by downloading and compiling the bzip sources from (say) https://gitlab.com/federicomenaquintero/bzip2.
Used in and expressly written for https://rosettacode.org/wiki/WiktionaryDumps_to_words#Phix. At the point of writing that is the only example, and as good as anything else I could write.
Please refer to that example or the official bzip documents for more details regarding the use of these routines, and possibly make suggestions for what (if anything) should be added here.
Mainly it is a case of keeping a sharp eye on avail_in and avail_out, sometimes next_in and next_out might be easier, to know when it wants more input and/or when you have to deal with some output, plus BZ_RUN/BZ_FINISH for BZ2_bzCompress. Quite when it will spit out a block is of course a total mystery, until it does.
I would suggest it is probably not worthwhile bothering with or fretting over blockSize100k, verbosity, workFactor, or sml settings and just rely on the defaults.
Designed to work on a single (internal) stream, but you can (/should be able to) create multiple streams easily enough, eg unpack from one straight into another.
Aside: by stream I just mean any source of bytes, manually handled, rather than some weird opaque thing that does some weird thing using some weird kind of syntax.
Depends on cffi internally, and, fairly obviously then, none of these routines are supported by pwa/p2js (which does not even bother to try and syntax colour them).
The distribution includes builtins/bz32.dll and builtins/bz64.dll however while I foresee no problems it has not been tested on Linux and the equivalent .so files must be obtained by other means, perhaps by downloading and compiling the bzip sources from (say) https://gitlab.com/federicomenaquintero/bzip2.
Used in and expressly written for https://rosettacode.org/wiki/WiktionaryDumps_to_words#Phix. At the point of writing that is the only example, and as good as anything else I could write.
Please refer to that example or the official bzip documents for more details regarding the use of these routines, and possibly make suggestions for what (if anything) should be added here.
Mainly it is a case of keeping a sharp eye on avail_in and avail_out, sometimes next_in and next_out might be easier, to know when it wants more input and/or when you have to deal with some output, plus BZ_RUN/BZ_FINISH for BZ2_bzCompress. Quite when it will spit out a block is of course a total mystery, until it does.
I would suggest it is probably not worthwhile bothering with or fretting over blockSize100k, verbosity, workFactor, or sml settings and just rely on the defaults.
Designed to work on a single (internal) stream, but you can (/should be able to) create multiple streams easily enough, eg unpack from one straight into another.
Aside: by stream I just mean any source of bytes, manually handled, rather than some weird opaque thing that does some weird thing using some weird kind of syntax.
Depends on cffi internally, and, fairly obviously then, none of these routines are supported by pwa/p2js (which does not even bother to try and syntax colour them).
constants
|
| - struct id for a stream |
| p_bzs | - the default stream |
| BZ_RUN | = 0 -- (an action) |
| BZ_FLUSH | = 1 -- ("") |
| BZ_FINISH | = 2 -- ("") |
| BZ_OK | = 0 -- (success result code) |
| BZ_RUN_OK | = 1 |
| BZ_FLUSH_OK | = 2 |
| BZ_FINISH_OK | = 3 |
| BZ_STREAM_END | = 4 |
|
| = -1 |
| BZ_PARAM_ERROR | = -2 |
| BZ_MEM_ERROR | = -3 |
| BZ_DATA_ERROR | = -4 |
|
| = -5 |
| BZ_IO_ERROR | = -6 |
| BZ_UNEXPECTED_EOF | = -7 |
| BZ_OUTBUFF_FULL | = -8 |
| BZ_CONFIG_ERROR | = -9 |