World: r3wp

At least that's how it worked the last time for me.

I thought the newer releases stopped doing that. There were a number 
of builds that did it though. Very annoying.

it has never done it for me, but it has always done it for others. 
so, it's not clear yet how/when that happens. afaik the code does 
a make-dir view-root/public so in theory it should always be in view-root 
not in the cd.

I thought it only did it when you invoked the viewtop

... or any of the *-thru funcs

Yes very annoying, I use the following func to clean things up:

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