World: r3wp

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.

to-time {hi} is returning none. so therefore there is no error for 
TRY to trap

oh.. sorry then  =^\


then I guess it was 'to that was changed?  Well either way it doesn't 
matter, at least now I know lol

to-time {hi} has returned 'none at least as far back as 1.2.1.
Maybe that is a bug :-)

#3832: why? it's normal that SIGINT interrupts apps.

it looks to me, that the initial-vector is not taken into account 
by the encryption ports?

nevermind, problem solved

TO-TIME with rubbish input, already reported, see -> http://www.rebol.net/cgi-bin/rambo.r?id=3643&

Yeah, thanks... I was confused because I was certain I had gotten 
if error? try [to-time Whatever][..] to work before

maybe you used to-date

I don't find in RAMBO the bug about View crash when you change screen 
resolution (almost under XP) !
Is it already there or not ?

Perhaps it is fixed?  I submitted it in Feb 2004

http://www.rebol.net/cgi-bin/rambo.r?id=3382&

Ah ok. Thanks

my most hated bug in Rebol: Invalid data type during recycle

Regarding Carl's last blog, I guess rebcmd25125 is the pre-release 
version.
I am testing the Win version with my scripts since a few days.
Recently I saw  some error messages I saw never before.


The script is reading periodically from a remote drive via UNC with 
	load join work.dir [isodate work-date ".log"]
where 
	work.dir:  %/REMOTE/D$/DATA/
and 
	isodate: func [x] [..]  
producing something like "20050705".

Before I saw error messages like 
	Access Error: Cannot open /REMOTE/D$/DATA/20050705.log
	Where ...
	Near: load join work.dir [isodate work-date ".log"] 
 , if the file was not accessible.


This time the error messages were different after running for some 
time ,  e.g.
	Near: load join work.dir [ isodate 5-Jul-2005 ".log"]
or 
	Near: load join wor[isodate work-date ".log"] 

Has anyone seen something simlar ?

Forget the message above.

I guess I can it explain, as probably two instances of my script 
where running at the same time and writing to the same log file and 
thereby overwriting their mesages.

I found a rather peculiar bug in rebol/core for OSX under Tiger:
start rebol/core and type:

>> launch "test"
(new process starts)
>> quit
** Script Error: pitqi has no value
** Near: pitqi
>> quit
** Script Error: pitqi has no value
** Near: pitqi
>> quit
** Script Error: utqi has no value
** Near: utqi

Any command is mangled semi-randomly. Can anyone confirm?