World: r3wp

I suspect that this nesting behavior was intended to better enable 
using REBOL to generate code in languages with C-like block structure. 
I know it is useful for putting Javascript in generated web pages. 
There may even be such generation of C code as part of the REBOL 
build process. For that matter, it can be useful when specifying 
REBOL source code in strings when that code also contains strings.

OK, I submitted it as a special case.

What I wanted to say is, that this property works against the possibility 
to specify a string containing some possible sequences of characters. 
The fact, that such strings can be read from file doesn't suffice 
as an argument, that Rebol can handle any string - Rebol cannot handle 
some strings using the escape convention defined in the Rebol/Core 
User's Guide.

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.