World: r3wp

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.

Romano, I was expecting TRUE to be returned from the function.

Maybe this makes it clearer:
>> do func [][while [true][return 'from-body]]
== from-body
>> do func [][while [return 'from-cond][return 'from-body]]
== none

I am expecting the second example to return 'from-cond.

Im really worried about this alpha thing, personaly i belive rebol 
is a great tool and i use it all the time, 

i know there is the time factor in development, but i belive there's 
no priority and the policy about TODO's 

it's crazy, on one side, services, view and graphics, sound formats, 
and on the other, multitasking, async ports, 

OSX support, and so many, many others... all taking place at the 
same time... 

We don't know what's first on the list, rebol changes as fast as 
developers type their code, 

(i dont  mean it in a bad whay, but still worries me) so todays 100 
lines may be tomorrows 10 

and so on ... why to spend time writing code on some issue will never 
leave alpha state, or even workst, be droped down 

some code will loose compatibility with newer versions and refuse 
to work, 

some other cobe, may become obsolete and old as soon we put it on 
the market, i think rebol has loose the KISS strategy. 

i know we love our 600K amazing tool, but don't be fool, this 600K 
don't mean is an easy and standarized 

development tool it's more like an other thing... ok it still is 
a cool tool, bla bla, but we must know 

there's a line conducting rebol upgrades, not just the crazy 600Kilobytes 
limit, 

it would not mind to my even if it whas 600 megas at this point this 
limit has loose the sence to be. 

i think here ideas come and go to fast, development has, in the last 
years, been embeed with the fashion of some lenguages, 

leave out the top then fight, we dont need it, just make it simple, 
i know rebol will reach maturity only if a srtight line traces his 
development

let's wait what Carl will say at devcon on friday - his keynote is 
"Accelerating REBOL improvements"

please note that i know rebol is been maintened by a small goup of 
developers, and with a small budget,i know a LOT of 

work has been done now and in the past, the reach today rebol state 
of development, and there's too many thing to do to make us all happy