World: r3wp

http://www.rebol.net/article/0141.html

Ah.  I did have a ImageMagik library loaded when this crash occured 
but I hadn't used any of its functions.

The image Magik library I had loaded doesn't appear to be using any 
Callback!s so it isn't likely that this crash was related to the 
callback bug.

get-face on a field with hide returns asterisks instead of the text.

Is that a "bug" ?

I've seen this before and it's probably because password fields store 
data a bit differently than normal text fields.

I know, but the get-face accessor function is supposed to help newbies 
avoid having to know these differences

I just think get-face and set-face are not complete, e.g. AFAIK they 
only work properly on textfields, radio and checkboxes

Gabriele had a patch somewhere to set-face, I think

I'd better download and test the latest view before I submit a report.

I've been testing #3403. I can't get it to crash now in the latest 
beta

doesn't crash in 1.3.1 either

repetedly getting this with core 2.6 for os x, the code does a buffered 
ftp copy, is it known issue? should I investigate more what part 
of code is doing this?
** CRASH (Should not happen) - Invalid string width 20 : type 41

it would be nice if make-dir/deep worked with ftp! I use this instead:
make-dir-deep: func [ f /local t u p h][

 h: copy f until [exists? h: copy/part h next find/reverse back tail 
 h "/"]
	t: parse find/tail f h "/"
	u: copy h
	foreach p t [if not exists? append u join p "/" [make-dir u]]
	]

Graham: get-face on hidden fields is a know bug : http://www.rebol.net/cgi-bin/rambo.r?id=3445&

The problem is that #3445 is marked as build, and it's not !!!

ups, sorry! Read to fast, it's clear-face not get-face :-/

so, we need to submit get-face as well then ?

you go ?

done.

Should I submit RAMBO ticket? Rebol.com website refers to View 1.3.1 
and mentions Windows 9x, which is not true. Dunno who and why decided 
that we should cut-off Win95 machines, but it happened. And as I 
will not use old 1.2.1 with all those differences anymore (yes, I 
am that one who prefers adjusts old stuff to new versions), we cut 
off some xy percentage of potential customers. I will have to check 
if Win98SE are affected by that too ... anyway - my point is, that 
such missleading info should be removed from website ...

RAMBO is for technical issues, and not policy issues.

typical reaction ....

could you read twice, please? ;-) IIRC, rambo is also about reporting 
inconsistencies in documentation etc., and if I am not alone who's 
one of Win95 machines does not accept View 1.3 and website tells 
so, then I regard it being incorrect.

sigh ...

:-)

what is sigh? I just asked if RT should be notified about claiming 
something what is not actually true?

:-)

This looks like a bug to me:

f: does [while [if true [return true]][]]  f

;== none  (on Rebol/View versions 1.2.108.3.1 thru 1.2.110.3.1,  
and versions 1.2.113.31 thru 1.3.1.3.1d)

(no ticket appears in RAMBO, searching for "while")

Are there any news about  #3869 CRASH (Should not happen)  - Invalid 
string width 16 : type 41 ?


A few weeks ago I got the same error randomly with the new beta command 
version.


I was now able to boil it down and it seems to be a general problem 
in all new versions.

REBOL [
]       		

On_Data: func [
	port
] [
	msg:  copy port
		
	if any [none? msg  empty? msg] [
		remove find port-list port
		attempt [close port ] 
		return false
	]
	append port/locals/buffer to-string msg
	insert port { }
	false
]

On_Listen: func [
	listen
] [
	conn: first listen
	conn/locals: make object! [
		buffer: make string! 4000
	]
	conn/awake: :On_Data
	sockets: sockets + 1
?? sockets
	append port-list conn  
	false
]


sockets: 0

port-list: reduce [
	listen: open/direct/no-wait/binary tcp://:13011 
]
listen/awake: :On_Listen


forever [
	error?  try [
		conn: wait port-list
	] 
] 
close listen

Just send as many messages as you can from other computers and sooner 
than later it will crash .

Anton: it is not a bug for me.

What do you should like to happen?

Perhaps an error would be a better behaviour.

i got version REBOL/View 1.3.1.3.1 30-Aug-2005 Core 2.6.0 and my 
async ports are not working, open has no refinement called async 
a bad build ? somthing missing ? help

ok i've dowloaded REBOL/Core 2.5.53.3.1 ALPHA VERSION (Aug 17 2004/22:43:09) 
(note both, this 2.5.53 and the last 1.3.1.3.1 are win x86 versions 
running on XP SP1) and works okay ! what wrong here ?

/async is only in alpha releases. official releases do not have the 
async core (it is still considered somewhat experimental)

Gabriele - isn't 'request-date somewhat unfinished?Try 'help request-date 
and look how is /offset described, what it says it accepts (any type) 
and what it really allows to accept (pair) ... Maybe this could be 
improved ...

i guess all request-* require some refinement.

besides that I wonder, if e.g. request-date as an example, works 
with locale element? I think not ... REBOL locale support is really 
terrible - nonexistant, and I wonder why, if system/locale/months 
is available ...

yesterday I got request of my friend Bobik here, asking how to localise 
it  :-) I suggested him to look into RebGUI calendar instead ...

ah, now I tested it, RebGUI works with system locale - besides that, 
the week starts by monday ;-) btw - could RebGUI code be reused in 
official rebol distro? e.g. as far as request-date is concerned, 
or even request-dir, it is of a much more quality than rebol's built-in 
ones  ....

I had done some enhancements to request-date in the days of "View 
1.3" project (2 years ago).

The result is in RAMBO, but not the code http://www.rebol.net/cgi-bin/rambo.r?id=3058&
So you can find it here with some demo code :
do http://membres.lycos.fr/didec/rebol/request-date-enhanced.r

It use locales and can start on monday or sunday, show today with 
red circle, has today button at bottom, and can be initialise with 
a date shown with a red square.

shoul i spent my time on /async ?  i mean im not shure about using 
it it's experimental but will some day applied ?

it will most likely be implemented, but we'll have to wait and see 
if it will be exactly that implementation.