World: r3wp

;APPEND not returning the head of list! 

>> append my-list: make list! [] [value1 value2]  ;== make list! 
[value1 value2]
>> head? my-list  ;== false

>> my-list: append make list! [] [value1 value2]  ;== make list! 
[value1 value2]
== make list! [value1 value2]
>> head? my-list
== true

Volker, well then I guess I'd better check Core 2.5.0 to see how 
it behaves. I still use that version on WinCE - it is still the current 
version on many platforms.


It doesn't seem like it would be difficult to add escape processing 
to the console reader, especially since it would only have to do 
it with { and }, and even then only in {} delimited strings.

>> s: l: next make list! [1 2 3]
== make list! [2 3]
>> remove l
== make list! [3]
>> s
== make list! []

I am not able to call this behaviour consistent, I am sorry

Agreed. I'm glad list! is not commonly used, otherwise someone optimizing 
code will probably throw rebol out of the window due to this "side 
effect"

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 ?