Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.compression > #4053 > unrolled thread

Re: Is this a valid LZO compressed byte string?

Started byMukesh Jat <mr.jat2310@gmail.com>
First post2022-07-05 00:35 -0700
Last post2022-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.


Contents

  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

#4053 — Re: Is this a valid LZO compressed byte string?

FromMukesh Jat <mr.jat2310@gmail.com>
Date2022-07-05 00:35 -0700
SubjectRe: 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]


#4059

Fromapurv khandelwal <apurvk2000@gmail.com>
Date2022-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]


#4060

FromKeith Thompson <Keith.S.Thompson+u@gmail.com>
Date2022-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