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")

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)

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 */