World: r3wp

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

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