World: r3wp

delete-public: func [dir [file!]] [
	foreach file read dir [
		if #"/" = last file [
			attempt [delete-public dir/:file]
		]
		if find [%public/ %Thumbs.db] file [
			attempt [delete dir/:file]
			print dir/:file
		]
	]
]

delete-public %/c/

Just thinking aloud (I would have to reboot into windows to test 
it, and I dont't waht to ;-) 
It it possible to set view-root in rebol.r or user.r ?

(You have to try, 'cause handling of these files differs between 
versions, too)

In the above func on a Mac you could replace %Thumbs.db with %.DS_Store 
;)

When it comes to decrypting, is it easier to hack an encrypted string 
if you know part of the string?

Ie:  If you knew that a stirng always started with   keys: [name 
"     could you decrypt it easier?

just thinking that if you encrypt an object, it probably starts the 
same for all.

I need to sort some French words but REBOL's SORT puts accented characters 
on the end (sorts just by ASCII). Has anybody got some enhanced SORT 
for French?

terry: it depends a lot on the crypt algorithm used and the length 
of the key. it surely helps to know any part of the plain text. however, 
just compression would reduce that a lot (since the result depends 
on the whole string); also good algorithms are usually smart enough 
to resist a simple attack like this.

Sorting: you may be able to adapt this hungarian code:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlMWWJ

thanks Sunanda

a: make object [
  b: make block! []
  c: b
]

same? a/b a/c
== true ; OK

d: make a []

same? d/b d/c
== false ; how do I get this to be TRUE?

apparently I need to do it in the spec block, though i had hoped 
this could be done inside the object to encapsulate that entirely. 
cleaner code.

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?).