World: r3wp

if your just looking for evaluating the value then use equal? instead.

Henrik: this may not be what you want, but it works:
    d: make a [c: b]

(your problem is, that cloning does not use much "intelligence", 
in the case of d: make a [], the cloning code just copies both a/b 
and a/c and therefore it is obvious, that two copies aren't the same 
block

ladislav, yes, that's what I had to come up with.

paul, d/b and d/c must be the same block, so equal? is not enough.

Is there any script for LZW decompression?

Oldes. These might help? http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=gunzip.r

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=rebzip.r

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.

this is puzzling me ... it's a little loop to remove old files

foreach f read %./ [
			if f <> %. [
				inf: info? f
				probe d: inf/date
				if all [ inf/type = 'file (difference now d) > 1:00:00 ][
					attempt [ delete f ]
				] 
			]	
		]

** Script Error: difference expected set1 argument of type: series 
bitset
** Where: do-boot
** Near: difference now d

using  2.5.0.10.1

ok, fixed.  updated to latest Rebol for Solaris sparq.

Is this consistent? I don't think so:

>> a: make hash! []
== make hash! []
>> b: make block! []
== []
>> a
== make hash! []
>> b
== []
>>

The hash! property shouldn't be returned, instead just an internal 
flag.

I can use hash? to check for it.

well, I think returning the type in the console can be quite useful. 
if anything, it's block! that's being inconsistent.

In the console yes, but this longer stuff will be returned in code 
as well. And this makes parsing a bit complex.

>> reduce [a]
== [make hash! []]
>> reduce [b]
== [[]]
>>

how? parsing will immediately return whether it's a hash! or a block!. 
if you need to keep that information, the block of hash! blocks should 
be serialized first.

>> type? first reduce [a]
== hash!
>> type? first reduce [b]
== block!

>> c: mold/all reduce [a b]
== "[#[hash![]] []]"
>> load c
== [make hash! [] []]
>> first load c
== make hash! []
>> type? first load c
== hash!

No information loss.

I mean if you provide a reduce [...] to some parse rules and you 
have a "make hash!..." in the block you need to parse this. Hence, 
the parse rules change if you use block or hash.

I'm not sure I understand. If you have "make hash!..." as words, 
then your block is not properly serialized.

which would indeed make the parsing a bit more complex.

Hi Robert, can you give us a an example, where you have this problem? 
I can't see it.

>> h: make hash! [3 4 5]                                    
== make hash! [3 4 5]
>> b: [1 2 3]                                               
== [1 2 3]
>> parse reduce [b] [into [some [set i integer! (print i)]]]
1
2
3
== true
>> parse reduce [h] [into [some [set i integer! (print i)]]]
3
4
5
== true

'key-word set key-word [block! | word!] (...

So, not when parsing for the content but for the block as is.

Robert, what you see at the console is the output of MOLD. there 
is no 'make and no 'hash! there. if you are *saving* the hash in 
a file or sending thru tcp and so on, use MOLD/ALL (or SAVE/ALL) 
so that hash! can be loaded properly afterwards.

Is there a built-in function that returns the platform we're running 
on (Windows or Linux or Mac or whatever)?

it's encoded in system/version
this script decodes it for you:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=environ.r

Thanks, Sunanda, much appreciated.

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=environ.r

arg !!! too slow

:) Thanks to you, Steeve.

Hi Robert, do you mean, this?

>> b: [a b c]                   
== [a b c]
>> h: make hash! [a b c]        
== make hash! [a b c]
>> parse reduce [b][block!]     
== true
>> parse reduce [h][block!]     
== false

because a hash!, is a hash! and not a block?

>> parse reduce [h][hash!]      
== true

Then you should use any-block!

>> parse reduce [h][any-block!]
== true
>> parse reduce [b][any-block!]
== true

There is a nice script that encodes strings to utf-8. It is by Romano 
Paolo & Oldes. I'd like the reverse:  decoding utf-8 strings. I found 
a script by Jan Skibinski proposing to do that, but the script doesn't 
load in rebol, exiting with an error ('map has no value). What's 
next?

Ok, I think I got what I need. Jan's script can be salvaged, if only 
part of it.

BTW, I noticed that rebol.org serves pages in utf-8 encoding, but 
the scripts themselves are latin-1. This is not a problem for the 
code, but it is a problem for the comments, which may contain accented 
characters. For example, names of authors (hint: Robert Müench), 
and they consequently appear garbled. I'm not saying pages should 
be served as latin-1, on the contrary, I am an utf-8 enthusiast, 
I think rebol scripts themselves should be encoded as utf-8, (it 
is possible with python, for example). I hope Rebol3 will be an all 
encompassing utf-8 system (am I dreaming?).

UTF-8 is being discussed as part of R3 Unicode support.  All encompassing? 
 Dunno.  Well thought out and robust?  I'd bet on that one.

Well, on that same note of optimism, allow me to declare in forthcoming 
R3 syntactic style, rebol: "vive la rébolution"

And why not even rébol: "rébolution"?

That is to say, not only should there be utf-8 string datatype, but 
words themselves should be utf-8 compliant.

It's on the discussion plate.  Gabriele mentioned that unicode will 
help REBOL open up in Asia, so it's a topic at the high levels.  
A couple of rebols have done some very nice work on fonts and character 
sets.  Jerry Tsai comes to mind ... check the Unicode group for some 
of his links.  Oldes has also pulled off some nice translators...again 
links in the Unicode group.  To name but two.  Even Bi-Di is being 
discussed.

Daniel, afaik, R2 words are already utf-8 compliant. (thanks to the 
way utf-8 is designed)

What is current R2 recursion limit? Bobik reports me, that he does 
some tree, and it hits the barrier with 2000 iterations ....

Daniel: just read Unicode group in this world.

2000 sounds about the limit for R2. There's a script here that tests 
various limits like that:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/view-script.r?script=rebol-stress-test.r

Pekr, I think it depends how many local vars are used in the function. 
With one local var, I got 14263 recursions before stack overflow. 
Maybe he can optimize by moving some variables out into a shared 
context.

Thanks everybody, I'll follow your advice.