World: r3wp

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

anton: confirmed

Thanks Henrik. You can also try putting different functions, natives, 
ops, in there for the same result. (I haven't tried them all, though.)

none does not cause a crash, though.

I have searched for "changes" in rambo and I did not find a similar 
ticket.

add it :)

OK done. :)

Hi, #3545 is marked as High importance. Actually, it is underestimated, 
because such problems are critical even for pre-alpha Rebol programs 
e.g. when trying to send keep-alive type messages to a port using 
Romano's ATCP scheme. I  wonder what is an optimal work-around for 
the current (Core 2.6 - based) scripts? (see #3465 too, marked - 
underestimatedly - as Medium importance) .

(I know, that we can use Timers for View scripts, but that does not 
solve the Core case)

timeouts are a problem for normal (non-async) core, but should work 
fine on async core.

the "solution" (a trick, with its own problems...) i use for the 
detective is http://www.colellachiara.com/soft/Libs/timers.r

anyway - this is something we *need* for /services... so i guess 
there will be a real solution very soon.

just a few weeks ago I wrote that with the new rebcmd for Win my 
problems with odbc and catch were gone.

Now I encountered a "Crash, should not happen" with a script doing 
not more than receiving data from tcp sockets, parsing the data, 
writing to files and sending a response back.

Some almost identical scripts were working with the old cmd for months 
without interruption.

Can you isolate the problem?

I will try, but I am not very optimistic

It's reproducible
Crash (should not happen) invalid string width 16: type 41

Now I get the crash every second day

Isolation is key to fix the problem. If you can't isolated it, please 
post the full script.