Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compression > #4053 > unrolled thread
| Started by | Mukesh Jat <mr.jat2310@gmail.com> |
|---|---|
| First post | 2022-07-05 00:35 -0700 |
| Last post | 2022-11-30 14:27 -0800 |
| Articles | 3 — 3 participants |
Back to article view | Back to comp.compression
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Is this a valid LZO compressed byte string? Mukesh Jat <mr.jat2310@gmail.com> - 2022-07-05 00:35 -0700
Re: Is this a valid LZO compressed byte string? apurv khandelwal <apurvk2000@gmail.com> - 2022-11-30 14:19 -0800
Re: Is this a valid LZO compressed byte string? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-11-30 14:27 -0800
| From | Mukesh Jat <mr.jat2310@gmail.com> |
|---|---|
| Date | 2022-07-05 00:35 -0700 |
| Subject | Re: Is this a valid LZO compressed byte string? |
| Message-ID | <bed20e91-27da-4eb5-8ee7-d21f7e840e9fn@googlegroups.com> |
On Friday, September 10, 2010 at 6:53:48 PM UTC+5:30, Slaunger wrote: > Although I am just having a dialogue with myself here, I finally > figured out what the problem is:-) (I cannot solve my problem, but now > I at least know what it is) > The lzo python bindings does not return the exact same array of bytes > as the C-library functions. They add a header, where the first byte is > 0xF= for LZO-1X compr lvl 1, and then an uint 32 representing the > number of bytes in the *uncompressed* byet array. Apparently, this > convenience information is used in the Python binding uncompress > function, to allocate the right sized buffer for the output prior to > calling the lzo library uncompress function. Really crap binding code > if you ask me as it measn that I have to know *in advance* how many > bytes a compressed array of bytes will unpack into *prior* to calling > lzo.uncompress. And if it is compressed data from another data source, > it is really not possible to know that final data size beforehand, > which is...crap. Just use lzo.decompress(data,False,out_len,alogrithm="XYZ")
[toc] | [next] | [standalone]
| From | apurv khandelwal <apurvk2000@gmail.com> |
|---|---|
| Date | 2022-11-30 14:19 -0800 |
| Message-ID | <365db619-a441-4547-ae26-b1c1817a1433n@googlegroups.com> |
| In reply to | #4053 |
lzo.decompress(data,False,out_len,alogrithm="XYZ") this does not work. Shows the error: decompress() takes no keyword arguments Also, the function only takes 3 arguments. Running lzo.decompress(c, False, 512, "LZO1Z") gives the error: function takes at most 3 arguments (4 given)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-11-30 14:27 -0800 |
| Message-ID | <87lensjcxx.fsf@nosuchdomain.example.com> |
| In reply to | #4059 |
apurv khandelwal <apurvk2000@gmail.com> writes:
> lzo.decompress(data,False,out_len,alogrithm="XYZ")
>
> this does not work. Shows the error: decompress() takes no keyword arguments
>
> Also, the function only takes 3 arguments. Running lzo.decompress(c,
> False, 512, "LZO1Z") gives the error: function takes at most 3
> arguments (4 given)
In what language?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [standalone]
Back to top | Article view | comp.compression
csiph-web