World: r3wp

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?

thats typical for rebol under linux, and os/x is a unix. two processes 
want to read from the same console and get it alternating. may be 
more of an unix-issue. (but i did never see "pitqi")

Any reason why help no longer works with objects?

	>> system/version
	== 1.3.1.3.1
	>> help system
	SYSTEM is an object of value: >>

compared to:

	>> system/version
	== 1.2.10.3.1
	>> help system
	SYSTEM is an object of value:
		version         tuple!    1.2.10.3.1
		build           date!     30-May-2003/0:59:35-7:00
		product         word!     View
		...

I don't see that Ashley. It still works for me. I think you blew 
away dump-obj or something like that.

Gabriele, can you add an extra bit to the details here http://www.rebol.net/cgi-bin/rambo.r?id=3837&

A reason for wanting this is to be able to generate an image of what 
the style looks like without opening a window, eg. for documentation.

(It's good to see what the original reasons are for each bug report. 
Should make fixing them more satisfying too.)

volker, well I didn't get any trouble under Linux with GNUstep's 
Terminal.app so it may be a terminal issue

If I ssh to a linux box from the terminal where I saw the problem 
originally, there is no problem either

Gabriele, I have some additional information for a ticket:

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


Memory usage climbs, but there is no longer any crash on View 1.3.1

i: 0 until [
	attempt [
		view layout [
		button feel [
		redraw: func [face action pos][
		;if action = 'draw [show face] ; memory use climbs very high
		if action = 'show [show face]  ; memory use looks quite stable
		]
		]
		]
	]
	1000 <= i: i + 1
]
unview

hmm, need to check all tickets with undetermined importance. otherwise 
they get overlooked.

view/new win: layout [] win/changes: reduce [:+] show win  ; crash