World: r3wp

err, both S and L are the same, sorry, it is consistent in that sense

More errors with list. TAIL? and HEAD? throwing errors.

>> l: next make list! [1 2 3]
== make list! [2 3]
>> remove l
== make list! [3]
>> l
== make list! []
>> tail? l
** Script Error: Out of range or past end
** Near: tail? l
>> head? l
** Script Error: Out of range or past end
** Near: head? l
>> l: head l
== make list! [1 3]

Jaime - will you report those bugs? That should be fixed, no?

Yes. I am reporting them.

#3898 shows what I too reported as a critical - total annoyance of 
how View "works" in behind the firewall environment. I am glad I 
am not alone. Either rebol proxe detection code should be made smart 
(and I posted analysis how), or it should not try to connect to internet 
at all, gee! If it at least would be possible to shut the task down, 
but it isn't ;-)

any thoughts on   for i 0 0 0[prin "dejavu"]

0 <> 0 ?

I would expect it to not do anything since the end is reached before 
beginning

I thought 'while was the only iterative control structure that didn't 
execute at least once.

0 seems to be a buggy increment value....Worth reporting:
for i 99 99 0[prin "dejavu"]


Graham: for can execute zero times if the end condition is already 
true -- even with a zero incr:
for i 99 -99 0[prin "dejavu"]

>> repeat i 0 [print i]
>> foreach i [] [print i]
== none

bug?

>> to-idate 30-dec-2004/0:00+2
== "Thu, 30 Dec 2004 00:00:00 +0000"
>> to-idate 30-dec-2004/0:00+2:0
== "Thu, 30 Dec 2004 00:00:00 +0200"

getting this:

** CRASH (Should not happen) - Invalid string width 20 : type 41

rebol2600024

that's what it says ! ;-)

>> About
REBOL/Command 2.5.55.3.1 8-Nov-2004 Core 2.6.0
Copyright 2000-2004 REBOL Technologies.  All rights reserved.
REBOL is a trademark of REBOL Technologies. WWW.REBOL.COM
>> ? datatype!
   ...
   number!         datatype! number!
   ...
>> ? number!
No information on number! (word has no value)


This doesn't seem very consistant.  I'd love to have the help function 
return a list of datatypes within a specific seudo-type such as all 
datatypes included in the Number! type.

While playing with this REBOL I got a "** CRASH (should not happen)" 
 and spewed a bunch of garbage on the console.  Unfortunately I haven't 
been able to reproduce this.  I did get a screenshot of the console, 
 however, if you're interested...

Were you playing with callbacks?

No

the actual line that caused the crash:

>> number? "10

Then some other issue callbacks can crash rebol if the limit of them 
is exceeded.

What callbacks are we talking about here?

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 ...