World: r3wp

Submitted.

Did Dide submit his bug above ? It sounded like he wanted me to do 
it. :)

he did.

It looks like split-path was done by Romano. Maybe we should alert 
him.

ok good.

yes, i'll tell him.

thanks

my secure query looks as follows: [net allow library ask shell ask 
file ask %/c/program files/rebol/view [allow read ask write

 ask execute] %/c/documents and settings/ladislav/data aplikací/rebol 
 allow %/c/program%
20files/rebol/view allow]

Is that intended?

What do you mean ? No final slash on those paths ? Or the what's 
allowed ?

Oh yes, I see, view-root is set to ALLOW (the last path) for me too.

actually I see two sandboxes there and I don't think it is in agreement 
with what Gabriele said

About the ticket for 'forall. Cocinelle said it's just a missing 
[catch throw] args to the 'forall function!

Gabriele: I let you check that as I'm not "confortable" with this 
sort of things and maybe add the proposal  correction code to the 
ticket.

yes, it's a missing [throw] both in forall and in throw-on-error

lad: is that from the console? try secure quero from a launcyhed 
script (i.e. a script launched by the desktop)

*query

*launched

yes, it is from console, but is that intended?

i think so. the console runs with the same security settings of the 
desktop.

launched scripts, instead, are kept into a sandbox

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