World: r3wp

That functionality is pretty easy to by evaluating the word inside 
the condition block yourself.
eg.
	while [do cb] [...]

so I don't think it's really necessary.

What should this function be called, and what options does it need?

change-in: funct [key value] [
    either a: find block key [change next a :value][
        repend block [key :value]
    ]
]


It basically implements the a/key: value operation of maps, but for 
series.

Andrew Martin chose ASSOCIATE for that sort of thing:
   http://www.rebol.org/view-script.r?script=associate.r

SQL calls it MERGE, because UPDATE was taken.

I suppose you had FUNCT [BLOCK KEY VALUE] in mind for the above, 
Brian? If so, I think I like MERGE much, but every now and then someone 
has to suggest ALTER

I vote for UPDATE. It should be able to handle more than ports, even 
if the behavior isn't exactly the same.

Yes, of course, Gregg, UPDATE only working on ports seems indeed 
too limited for such a nice word. 


BTW, Brian, is the above behaviour to return after the change for 
updates and at the insertion for inserts intended?

>> update: :change-in
>> attributes: []
== []
>> update attributes 'color red
== [color 255.0.0]
>> update attributes 'color blue
== [] ; or rather [color 0.0.255]

its the natural completement to SELECT, so UPDATE is quite natural.

On the other side, to answer your question, it's related to SELECT 
and should probably support most, if not all, of SELECT's refinements, 
too. That's a bit of a stretch, because for ports UPDATE probably 
needs to be very fast and can't be thwarted by too complicated refinement 
handling?

Ah, Max, you're first ;-)

hehe

UPSERT

Widely used term (in database circles) for this operation.

I wasn't the original author, but I'm willing to bet that the return 
value wasn't considered. The best behavior would be to return the 
head.

Same for the [block yey value] thing :)

Andreas, the recent SQL standards call this operation MERGE, partly 
because UPSERT sounds terrible.

Can anyone suggest a free tool that can be used to decrypt files 
that have been encrypted using Rebol's Rijndael using a 128 bit key?

And not Rebol!

ie. I want to be sure that if I send a file encrypted using AES, 
that someone can decrypt it.

Try here: http://www.movable-type.co.uk/scripts/aes.html

or this http://people.eku.edu/styere/Encrypt/JS-AES.html

those only encrypt/decrypt text .. looking for a file tool

via Google http://www.aescrypt.com/

-1 for UPSERT.

aescrypt looks good .. now to see if it can read a file encrypted 
by Rebol

Hmm ... http://www.rebol.org/view-script.r?script=crypt.r


I changed the strength to 256, and algorithm to rijndael .. and encrypted 
a file, but get an out of memory when I try to decrypt it :(

the other issue is that Carl uses checksum/secure to turn the passphrase 
into a binary encryption so tricky to get another tool to decrypt 
using that binary key

checksum/secure is a SHA-1 hash.....Hashes are not decryptable, but 
you should find other tools that can produce a SHA-1 hash.

the difficulty is pasting the binary as input to the fields used 
by programs such as aescrypt

I'm not even sure that the encryption needs a binary encryption key

encryption port needs ...

Well, I used the encryption key as a string instead and encrypted 
to 256 bits using Rijndael and successfully decrypted with Rebol. 
 But aescrypt was not able to decrypt the file :(

I had padding set to false

If you have counters block and want to increment it, is there some 
better solution than this one?
	b: ["a" 1 "b" 1]
	change f: find/tail b "a" f/1 + 1
	probe b

don't know if any of these are better(and in which sense better):

change n: next find b "b" n/1 + 1

b/("a"): b/("a")  + 1
...

This does it without using a temporary word....and it should work 
even if the counter name is not amenable to Cyphre's path notation 
(ie you are using something more exotic that strings for counter 
ids, or are using an older version of /Core).
   b:  next find/skip head b "a" 2 b b/1: b/1 + 1
Just remember to reset ....
   b: head b
....once in a while:)

b/("a"): b/("a")  + 1
is the winner as it's a little bit faster and shorter.

Isn't this a bug?

>> make-dir %tmp/
== %tmp/
>> write %tmp/test ""
>> exists? probe first reduce [join %.\tmp "\test"]
%./tmp\test
== true
>> delete probe first reduce [join %.\tmp "\test"]
%./tmp\test
** Access Error: Cannot delete ./tmp\test
** Near: delete probe first reduce [join %./tmp "\test"]
>> delete probe first [%.\tmp\test] ;this works
%./tmp/test

I expect that when it's possible to get true on exists?, the delete 
should work.

I get false on the exists? line (linux, 2.7.6)

Oldes, what filesystem ?

EXISTS? creates a port from the file! argument, then queries that.
DELETE doesn't work with ports.

I guess it is the creation of a port or QUERY which is able to handle 
backslashes, and DELETE cannot.

I think you should normalise your files using TO-REBOL-FILE.

ntfs. And yes, I normalise now, just wanted to know, why it's different 
and if it's correct. (because I've spent some time to figure out 
this exists?/delete difference).

in other words.. I was expecting, that when I join something to rebol 
file, it will normalise it for me.

But maybe it's more related how join behaves:
>> join %test as-binary "test"
== %testtest
>> join %test ["test"]
== %testtest
>> join %test [as-binary "test"]
== %test#%7B74657374%7D
>> rejoin [%test as-binary "test"]
== %test#%7B74657374%7D
but you ar right, it's my fault that I was lazy.

There is another way to put a directory together with a file than 
'join, and it handles more cases with the forward/back-slash on its 
own:
>> Dir: %foo/bar
== %foo/bar
>> File: %test  
== %test
>> Dir/:File    
== %foo/bar/test
>> Dir: %foo/bar/
== %foo/bar/
>> Dir/:File     
== %foo/bar/test
>> File: %\test  
== %/test
>> Dir/:File   
== %foo/bar/test

I know, but that does not solve my case where I had to build path 
from external sources, which could contain the backslash. Like:
>> dir: %test/
== %test/
>> file: ".\LIBRARY\something"
== ".\LIBRARY\something"
>> dir/:file
== %test/.\LIBRARY\something

But to-rebol-file makes it valid for sure:
>> to-rebol-file dir/:file
== %test/./LIBRARY/something

To read the content of a shared folder on a machine, it's :
	read %/machinename/sharename/


But how (if its possible) can I read the list of the shared folders 
?

	read %/machine/		...does not work !!