World: r3wp

in split-path is missing an "head" command

while I am posting this I notice the foreign characters under Linux 
is not yet solved. Using Debian Ubuntu with brazilian ABNT2 keyboard 
layout I am not able to input some usual characters in Portuguese 
such as ´a ´e ´i ´o `u `a ^o ~a .

Not sure if it goes here.. but Rebol 1.3 doesn't seem to like the 
bit on a Draw animation in the cookbook: http://www.rebol.net/cookbook/recipes/0047.html
 (specifically, the adding and subtracting in the draw block...)

Nevermind, I haven't been paying much attention to the Draw dialect 
evolution - but the Cookbook ought to still be updated, right?

Is the Rambo CGI code public ?

Izkata, right, submitted a rambo ticket with fixed code for that 
cookbook entry.

RAMBO code is not public at this time.

ANton: if you ask Carl you may get lucky.

Oh, I just wanted to make a suggestion for the green "RAMBO Statistics" 
box. I would like each number to be a link that is the rambo search 
query which gives the tickets in question. ie. "New tickets: 1"  
 - when you click on the "1",  you should get a page with the summary 
of the new ticket.

But before I did that, I wanted to see if I could help by writing 
the code to implement the change.

this looks strange:
>> o: make object! [test-word: none]

>> do bind probe reduce [to set-path! 'test-word to lit-word! 'test-contents] 
in o 'self
[test-word: 'test-contents]
== test-contents
>> probe o

make object! [
    test-word: none
]

it looks like needing Rambo presence, doesn't it?

simplified:

>> do probe reduce [to set-path! 'tst-word 1]
[tst-word: 1]
** Script Error: tst-word has no value
** Near: tst-word: 1

ah, sorry, it is 1.2.48

this is 1.3 result:

>> probe reduce [to set-path! 'tst-word 1]
[tst-word: 1]
== [tst-word: 1]
>> tst-word
** Script Error: tst-word has no value
** Near: tst-word

ah, I missed do when pasting, the results of 1.2.48 and 1.3. are 
the same, sorry for any confusion

Lad what is exactly the problem for you?

it is strange, that a set-path behaves this way

do probe reduce [to set-path! 'tst-word 1] should set tst-word without 
protests

set-path! should fire an error in this case, right?

no

should behave like a set-word!?

why not?

i think that a path! with only 1 slot is a bad formed path

can be useful for insert/remove, but not for evaluate

it already behaves like a set-word in case its length is higher than 
one, that is why I think, that the behaviour is natural

I needed to handle this:


foreach [path value] [a 1 o/b 2] [do reduce [to set-path! path value]]

and was very surprised, that it didn't work

The problem i think is the first slot has a different meaning from 
second, third and so on

nevertheless, the behaviour is wrong and unnatural, I vote for the 
least surprising behaviour in this case

It is a surprise for me that a set-path! == set-word!

but it can be useful

even an error may be more natural than the observed behaviour, but 
if the operation is valid, then there is no other choice

that 'a in your example is a global word?

in my example yes, but I had a more complicated code originally

where it wasn't a global word

I wanted to manipulate an object or its subobjects using this notation 
and had to find and circumvent this bug

i agree on one fact! it should at least rise the bad-path error!

OTOH, it seems logical to allow expression:

    to set-path 'a-word

and if such an expression isn't illegal, then there is not much choice 
left

I think that give too importance to the fact that a set-path with 
1 slot is molded like a set-word (anc cannot be loaded as a set-path). 
But the first word of a set-path is not the same of a word! of a 
set-word!: the set-path word must be get and then selected.

The set-word word is like a second word in a path, the first hidden, 
implicit word! in a set-word is the context bound to the word.

funny and "stupid" example:

do reduce [sp: to set-path! [] 1]

but i agree: your proposal can  be useful, it is like to have to-set-word 
which does not change the context of a word

OTOH you are right, that it *may* slow down set-path handling (?)

i do not think too much, but it is true it needs a separate test 
and handling

also because the action "set the value" is not done by the set-path 
datatype! it is like an  action sent to the datatype of the value 
1 slot before the end of the path

another experiment:

>> a: func [/b] [print b]
>> a/b: "OK"
true
== "OK"
>> get second second :a
== true

yarg... 'try was changed.. I just spent a half hour trying to figure 
out why a -short- peice of code would work!

>> try [to-time {Hi}]
== none
>> ? try
USAGE:
    TRY block

DESCRIPTION:

     Tries to DO a block and returns its value or an error. ;What happend 
     to the error?
     TRY is a native value.

would->wouldn't*

It has nothing to do with TRY at all.