AltME groups: search

FYI, Bruno is working on a Zlib binding for Red/System:
https://github.com/be-red/Red/commits/zlib

ZLib binding for Red/System released by Bruno:

https://github.com/dockimbel/Red/tree/master/red-system/library/zlib

don't want o open this bottle now but another construction zone are 
the codecs like jpeg or zlib. at quick overview shows them very outdated. 
zlib e.g. from 1998 but don't know if carl has 

updated at least critical bugs. this has to be checked, the changelog 
is quite heavy until current. I like the Lua way here. the creators 
just take care about the real core, nothing else but 

this at a very agil and serious level, one reason the core is rock 
solid and very portable. the disadvantage of course is lack of a 
standard lib and a kind of wild growing but I guess this is
the price you have to pay for open source.

Guys, was there any discussion about the COMPRESS/DECOMPRESS natives 
in R3? Do we really need these functions to use some 'custom' compression 
format that noone in the world uses and when it is based on zlib 
anyway? Wouldn't be better to change this in R3 and use for example 
ZIP format? What do you think?

I remember Carl saying the custom format is more efficient but I 
tried to compress couple binary or text files to compare with ZIPped 
results and I don't see any significant difference that would be 
worth the current format incompatibility.

Earlier discussion of COMPRESS vs Zlib.....Basically, the two are 
almost identical already, so it should not take much to make something 
that is compatible:
     http://curecode.org/rebol3/ticket.rsp?id=328

Henrik, I was more thinking to rip the old zlib code out of Rebol 
and put there some more actual(or even smaller) implementation (latest 
zlib or miniz etc.)

Cyphre, Rebol compression is the same as zip deflate, but it's not 
the compressed part that's more efficient, it's the headers. The 
zip format has some fairly extensive headers, and Rebol compression 
doesn't. We do need compression to support compressed scripts though, 
so we need something. That doesn't mean we can't have something more 
flexible, and if we stick to what we can get from zlib (since we're 
linking it anyway) we can get this flexibility nearly for free.

If the latest zlib is better, we should consider switching to it. 
If we need to make sure that R2-compatible compression is an option, 
make it an option. Decompression should be able to autodetect the 
compression model though.

It's not a single-stream model like zlib or gzip - those would be 
better supported by COMPRESS and DECOMPRESS.

BrianH, yup I realized how it works now and I even fixed the /gzip 
quirks in DECOMPRESS...so I can decompress zip chunks with CRC32 
checksums now. But there is still one annoying bug, that the current 
zlib code doesn't handle the CRC32 calculation well on bigger files 
than 32kB :-/ Now I'm trying to fix it so the crc32() calls works 
in the "CRC running" mode where the final CRC32 is calcualted from 
smaller chunks of data which a file consists of.

I'll hopefully push this on github If I manage to fix it succesfully.

Do you think that it is feasible to change the current zlib to a 
more recent version or something else that is better? Keep in mind 
that I would want that zip:// scheme to exist eventually, even if 
I have to write it myself.

Regarding the zlib code change/update. I think that is feasible. 
We could try to use the latest version of ZLIB library (hope the 
licensing is ok, haven't checked that) or look at the MINIZ compression 
library (check it on: http://code.google.com/p/miniz/looks interesting 
as it could be more lightweight)

Licensing seems OK http://en.wikipedia.org/wiki/Zlib_License

As I'm updating my old scripts on rebol.org, I'm trying to understand 
the problems with compress/gzip & decompress/gzip , 
and found at least one issue in u-zlib.c . 

When compressing, as the checksum method is assumed to be adler32 
for most of the code, stream->adler (the current checksum) is wrongly 
initialized to 1 in two places, giving an off-by-one checksum in 
the output and making it unusable for decompress/gzip. 

Still no clue for what yields the 
     ** Script error: value out of range: none
error and why calling 
     compress "" 

seems to fix this problem sometimes.It seems that something isn't 
correctly resetted between calls.

compress is uzing zlib compression... just insetad of checksum at 
the tail (last 4 bytes) is used size of the source string

No.. these are based on zlib compression... I was interested in LZW. 
Here is just a compression http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=converter.r
... never mind... I don't need it . It was just for fun.

The error code is probably the one returned by the underlying layer 
(assuming REBOL uses internally zlib) :

#define Z_ERRNO        (-1)
#define Z_STREAM_ERROR (-2)
#define Z_DATA_ERROR   (-3)
#define Z_MEM_ERROR    (-4)
#define Z_BUF_ERROR    (-5)
#define Z_VERSION_ERROR (-6)

(from http://www.zlib.net/manual.html#Constants)

i think compress is from zlib

Oldes made a zlib compressor/decompressor. I found it in my cache:
	public/box.lebeda.ws/~hmm/rebol/zlib/latest/zlib.r

but it's not there on the web, apparently. Try check for his latest 
website.

But it's Rebol?pro version (using a dll) http://oldes.multimedia.cz/rebol/zlib_latest.rip

And yes, Rebol's compress is some older version of zlib compression 
- I use Rebol's compress function to create compressed SWF files, 
but in some cases Rebol is not able to decompress zlib binaries (so 
I use the dll)

I'm embedding JPGs into SWF files without problem, there is not required 
any special operation on the JPG's data to embedd. With the other 
formats I have to count pallete and use Rebol's compress (zlib) to 
embedd such an image (gif or png). It's not so fast, but it does 
what I need (and I don't mind if it takes a second more time to compile)

ZLib, I think

COMPRESS uses the Deflate algorithm, plus an integer on the end for 
the length of the uncompressed data, for allocation purposes. It 
has the same limitations as any other Deflate compressor (zip, gzip, 
zlib, png, ...).

zlib compressor/decompressor using zlib.dll (version 1.2.3)
  http://box.lebeda.ws/~hmm/rebol/zlib_latest.rip
and you will need this Ladislavs' script as well:
  http://box.lebeda.ws/~hmm/rebol/memory-tools_latest.rip

It depends on utf-8 and ucs2 projects, zlib if you want to decompile 
some flashes compiled in Macromedia Flash

It all in one version of the dialect (I simplified the ucs-2 code 
to support only cp1250 charset ) The zlib dll support for decompressing 
foreign swf files is missing. Hope everything else is included - 
I used it to compile this page successfully: http://www.nohyvnebi.cz/

all i read was "he zlib dll support for decompressing foreign swf 
files is missing" and remembering there are some small zip-exes for 
commandline.

you must have zlib.dll (zlib is not zip)

You can compress/decompress swf's, but some of them (the foreign) 
use probably latest zlib and Rebol cannot decompress them

Yes, the compression Rebol's using is zlib, but in Rebol must be 
used old version, because has problems with some zlib streams

anyway, you could use this: http://box.lebeda.ws/~hmm/rebol/zlib_latest.rip

The windows dll called by RWSF is Zlib

there should not be zlib anymore.. it was used for decompress anyway.

guys, how well does parse play with rebcode? It was said that parse 
is VM in itself, it is very right, but now we have some discussion 
about zlib support. Let's suppose we have rebol version on rebol.org 
and that we would like to speed it up. We can simple extend the idea 
to any other datatype (= in amiga terms, simply a file format, or 
protocol one). you will surely want to use parse. The question is, 
if you can speed up some things using rebcode?

Boron just got the choice between compiling COMPRESS with ZLib or 
BZip2

The zlib binding is written in C++, with templates

I thought about writing extension for zlib, but haven't started anything 
yet. But it should be easy I think.

you can always use the zlib code in putty.  its MIT licensed  :-).

I'm completely C/C++ newbie, so I would like to know, how to make 
the extension, if I have precompiled DLL.
For example, In R2 I can simply download the DLL like this one:
http://zlib.net/zlib125-dll.zip

And simply do:

zlib.dll: load/library %zlib1.dll

zlib-version: make routine! [ return: [string!] ] zlib.dll "zlibVersion"
zlib-version
;== "1.2.5"


Is there someone who can write a simple tutorial - C extension with 
the zlib-version command?

Oldes, I've built you a simple "zlib-version" extension.

Great, I will check the zlib:) I'm looking forward to learn something.

No tutorial yet, but see I hope it helps nevertheless:
http://bolka.at/2010/rebol3/ext-zlib-20101108.zip

Extract this into your hostkit folder, so that you'll have an ext-zlib/ 
folder in the hostkit.

Yes, you can create an extension which contains the zlib library.

You'd use

gcc -DTO_WIN32 -I ../src/include -I include -mdll -o zlib.dll zlib.c 
lib/zdll.lib


to statically link zlib into your extension (still called zlib.dll 
in the above).

Andreas, so I must copy all series to REBOL's one as you did in the 
zlib example? I guess I will need to put images into REBOL in pure 
binaries at this moment, right?

TAIL - INDEX looks better, thanks... btw.. https://github.com/Oldes/R3A110/tree/master/extensions/zlib

https://github.com/Oldes/R3A110/blob/master/extensions/zlib/zlib.r3

I don't get it Oldes. Why is it called %zlib-rxt.dll, when it could 
just as easily be called %zlib.rx and not have the platform-specific 
code?

The R3 extension wrapper for ZLib.

Or the R3 extension that statically links ZLib if you like.

In your case you could just rename zlib-rxt.dll to zlib.rx and it 
would work.

You would then import %zlib.rx instead of %zlib.r3. It would work 
on Linux if you made a Linux build of zlib as a R3 extension and 
also called it zlib.rx.

never mind... this is just a minor detail. Form me is important I 
can decompress zlib data as I could with R2. That's all.

If I had more time, it would be good to try some zlib/gz scheme.. 
but that's not important for me at this moment.

Zlib in R3 doesn't work.

so if a rebol zlib interface is installed, I want the r3 module to 
be loadable using   IMPORT zlib     ... not r3zlib.

But I want to do `import-extension 'zlib` and not:

import switch system/platform/1 [Linux [%zlib.so] Win32 [%zlib.dll] 
...]

even for things like zlib.

and its code is beautifull, it even has its own implementation of 
zlib... it rellies on no external lib or code.

That would slow down decompression quite a bit. It looks like a /zlib 
option would be a good idea, to tell it when to try that method.

I don't know how it's on Vista, but on W7 or XP you can place it 
anywhere... I today updated my old zlib script to do late initialisation, 
you can find it here: https://github.com/Oldes/rs/tree/88291b8c720e9026978a080ca40100c3f2fb780f/projects-dll/zlib/latest

Hm, yeah, I'm not sure. I guess, I had zlib in my mind, which PuTTY 
also do a reimplementation of. I'm not too much into SSH and SSL. 
PuTTY also have code for SFTP, if that helps in any way to make a 
SSL implementation.

I am trying to import zlib and had some minor success with an example 
for adler32 function.  Next was compress and now stuck on how to 
align the compress function ZEXTERN int ZEXPORT compress OF((Bytef 
*dest, uLongf *destLen, const Bytef *source, uLong sourceLen));  
 from http://www.zlib.net/manual.html#Utilityis ByteF * 
dest and Btyef * source pointers to bytes  defined was destination 
[pointer! [byte!]]     ?