• Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r4wp

[!REBOL3] General discussion about REBOL 3

AdrianS
25-Feb-2013
[1098]
Andreas, did you discover this by just playing with parse or did 
you read through the source? I wondering if there are other goodies 
in there.
Andreas
25-Feb-2013
[1099x2]
Reading the source.
But this was pretty much the first thing I started looking at, which 
already lead me down the rabbit hole of testing it in R2 and R3, 
looking for documentation, filing a documentation request against 
R3 and discovering and reporting a bug against R3 (and I'll probably 
continue down the hole and fix that bug). So I didn't get much further 
towards other goodies, yet :)
Scot
25-Feb-2013
[1101]
A worthwhile hole, me thinks.
Cyphre
26-Feb-2013
[1102]
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.
Sunanda
26-Feb-2013
[1103]
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
26-Feb-2013
[1104]
I agree that it should be easily compatible with other compression 
formats, but it does not take much to make it compatible (can be 
done via a mezz).
Cyphre
26-Feb-2013
[1105x2]
Sunanda, thanks for the link.
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.)
Pekr
26-Feb-2013
[1107x2]
maybe, historically, also the licence was a problem? Remember, R3 
was not open-sourced back at that time ...
I am fully for new, more standard way. I e.g. did not like .RIP format. 
E.g. Winamp uses normal zip format for their skin modules, etc. I 
would like to just hit enter or double click, getting into the archive/package.
Henrik
26-Feb-2013
[1109x2]
Cyphre: that sounds fine to me.
Pekr, I don't think .RIP was meant for basic temporary compression, 
but a more fully fledged file format to store serialized REBOL data 
efficiently?
Pekr
26-Feb-2013
[1111x3]
Henrik - RIP was crap :-)
I would prefer my app being packaged in default zip anyday ...
For me it was just another way of reinventing the wheel, with almost 
no added value ...
Henrik
26-Feb-2013
[1114x2]
Pekr, I don't think it's the same thing, plain and simple.
Would you not want a single, universal way to store and retrieve 
application state from disk? ZIP does not do that.
Pekr
26-Feb-2013
[1116x2]
why not? Because you can just 'do the .rip? I would not mind do decompress 
%my-app.zip :-)
Well, then I am wrong, ok. Not sure .rip format was anything in common 
with app state serialisation. I thought it was just plain and simple 
packaging mechanism - having a header, and binary container for compressed 
app modules/scripts ...
Henrik
26-Feb-2013
[1118x2]
Zip does not manage bindings or words transparently. It's simply 
not the same thing.
(and if it turns out, that it was not the goal with .rip, then the 
goal should be changed to do this)
Pekr
26-Feb-2013
[1120]
Then we talk two different things though. But - don't push anything 
like .rip on me, just to package my app. I want more transparent 
way, a zip archive I can inspect in Total Commander, Windows Explorer, 
etc.
Henrik
26-Feb-2013
[1121]
I would not want that a requirement for .rip anyway.
Oldes
26-Feb-2013
[1122]
If you want something modern, add support for LZMA compression. And 
please don't mix compress with zip - zip is high level, compress 
should be low-level function (idealy supporting more formats)
Pekr
26-Feb-2013
[1123]
Oldes - we don't mix anything. It was zip vs rip discussion. I say 
- let's .rip RIP :-)
Oldes
26-Feb-2013
[1124]
regarding zip versus rip - I can imagine runable zip - just add special 
file in it which would be used as a starter - actually that's how 
works for example APK, which is zip with different extension.
Henrik
26-Feb-2013
[1125]
I say - let's .rip RIP :-)

 - how can you say this, when we want a way to store application states?
Pekr
26-Feb-2013
[1126]
store them in zip, simply some storage format inspectable from other 
tools. I still don't understand, what is so special on rip, it is 
imo just a storage format, nothing special.
Henrik
26-Feb-2013
[1127]
Pekr, there is a lot more to storing application states than simply 
zipping data.
Oldes
26-Feb-2013
[1128]
It's quite a long time I used rip last time so my memory may be faded 
out, what do you mean with the application states?
Pekr
26-Feb-2013
[1129]
Henrik - maybe you meant a Rebin format? I really thoght, that .rip 
is just packaged scripts with header in order to being runnable? 
So I would like to ask about the app states too?
Henrik
26-Feb-2013
[1130x2]
Storing bindings, managing upgrades of data structures, structural 
checks and error handlign, type assertion, etc.
Pekr, ah, you are probably right. I forgot there was another name 
there.
Pekr
26-Feb-2013
[1132]
Well, rebin was not imo finished, even for R3, although maybe R3 
was closer to get to that idea. IIRC .rip appeared somewhere around 
IOS times, as a means of package scripts. It was imo a typical way 
of Carl, introduce his own way, instead of going with some "standard", 
e.g. zip.
Henrik
26-Feb-2013
[1133]
OK, then sorry, I was wrong. As far as .rip is concerned, then it 
should be some kind of installer, for it to be justified.
NickA
26-Feb-2013
[1134]
I'm ALL for using a standard compression format.  Then with a little 
work, .rip files could basically be SFX files. That would enable 
a super simple packaging method for delivery of executable REBOL 
applications.
Endo
26-Feb-2013
[1135]
+1 for NickA
Maxim
26-Feb-2013
[1136]
as far as i know, zip files allow prefix payload, so you can put 
stuff before the actual .zip file starts... just like REBOL allows 
stuff before the header.   I've seen a demo of a single file which 
is  an .exe,  .pdf ,  and .zip all at the same  time!
Bo
26-Feb-2013
[1137]
Old Bug, New Bug, Red Bug, Blue Bug?


I'm using the ARM build from rebolsource.net and getting the following 
unexpected behavior:

>> template: read %template.html


It outputs template as if it was a binary file, although it is plain 
text.

The build date on the package was 24-Jan-2013.
Andreas
26-Feb-2013
[1138]
No bug, READ does no longer automatically decode binary to strings. 
Use READ/string to obtain a a Unicode string obtained by decoding 
the binary with UTF-8.
BrianH
26-Feb-2013
[1139]
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.
Bo
26-Feb-2013
[1140]
@Andreas: Good to know!  Thanks!
BrianH
26-Feb-2013
[1141x2]
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.
R3's existing compressed scripts feature is better than RIP already, 
so we can safely let that fall into history.
Gregg
26-Feb-2013
[1143]
ZIP support would be great. I've wanted it for a long time, but want 
more than just a "compress this value" function. i.e. it needs to 
work like a port or have an interface that lets us navigate, list, 
etc.
BrianH
26-Feb-2013
[1144x2]
The ZIP format is supposed to be like a directory/file structure. 
I would rather have it supported as a zip:// port scheme, like file:// 
is for files and directories.
It's not a single-stream model like zlib or gzip - those would be 
better supported by COMPRESS and DECOMPRESS.
Gregg
26-Feb-2013
[1146]
Agreed.
Cyphre
26-Feb-2013
[1147]
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.