World: r3wp

do you test that from console? because console has some limitations. 
if i do in a script
  probe {^{}
that works. in console this works too:
!>load "{^^{}"  
== "{"

see #3873, #3872 . console simplifies a bit.

Ladislav, as I said, you make a good point that I agree with. I find 
it more than annoying that {} nesting without being able to escape 
{ is awkward, often requiring joins with the string "{". They should 
definitely escape {. The REBOL User's Guide doesn't say how escaping 
works, really. I was left with the impression that ^ would always 
escape the next character and any special treatment thereof, but 
unless the next character (or characters for ^(00) style escaping) 
fits the subset that is handled by the current REBOL version, the 
^ is stripped and ignored. At this point the { character is the only 
one that I've found that has special treatment that isn't disabled, 
but I haven't done an exhaustive search.

Volker, all of my testing has been done from the console. It never 
occured to me that there would be any differences. Disturbing.

So, the loader escapes { and } but the console reader doesn't, and 
thinks the string either isn't done yet when it should be, or is 
when it shouldn't, respectively. Weird.

Console has to to do this:
!>[
[    1
[    2
[    ]
== [1 
    2
]

So it cant use the default 'load. So either it was implemented a 
bit lazy, and/or compatible based on some old version. The early 
rebols had really problems with such bracket-things.

;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