Re: Publishing with Lzip

[Pierre Neidhardt <mail@ambrevar.xyz>]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]


> I can give it a spin.

Thanks!

> It’d be great to gain some confidence about these things.  :-) I haven’t
> looked at the patch yet, but if you haven’t done it yet, I’d suggest
> having tests like the one in tests/zlib.scm (compress and decompress a
> bytevector of a random size with random contents), and you could
> possibly perform more “stressful” tests manually as well (try to
> compress/decompress tarballs, etc.)

I've copied your test for zlib, it passes! :)

> I’d also recommend to re-read the API doc in the headers or whatever.
> IME these APIs are very tricky to use and one has to pay attention to
> every small detail.

I read the manual too many times.  The headers are not documented.  The examples
don't tell us more about the API.

I might be too inexperienced in the area, so maybe you or someone else could
have a look at the manual.

Else we could contact the maintainer and ask directly :D

> According to the C standard an enum is an ‘int’.  So mapping them is
> just a matter of producing/consuming ints.  The values of the enum start
> from 0 and are incremented by 1 from then on, unless specific values are
> provided.

My question was whether it's possible to have the mapping done "symbolically."
In C, you would match error values again the symbols of the enum, not against
the number.  So if we map the error numbers manually in Guile, it would break
whenever the API updates the enum.

Maybe I'm just being overly picky here :p

Cheers!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]