World: r3wp

Two new bugs discovered originally by Cyphre posted:

	load {#object! [...]} bug

and

    VALUE? crashes the interpreter

to the VALUE? crash: the following code crashes too:


    x: bind make block! {error? try [any-type? get/any 'variable]} 'system
    do x

to #3885

It might be useful to add the info, that

    f: does [g print "version 1"]
    g: does [unset 'f recycle]
    do :f

circumvents the crash

OT: Is the RAMBO script somewhere accessible?

I don't think it has been released.

I agree.

do you guys think someone could look into #3822 red-icons related 
bug? I think that we should close that issue once and for all. The 
test case is very clearly described. It is either bug in REBOL or 
in Windows, but if not solved, timestamping is not reliable with 
REBOL in any way ...

Didn't Carl say red icons was now history?

no, I do not remember it .... I openly flamed his blog article, as 
it was really rudiculous ;-) He stated it no more appears on his 
machine, so the problem is solved ;-) But other ppl including me 
identified the problem exists even with WindowsXP for us ....

Doesn't it also occur with Linux?

Or, is it a specific Windows bug?

dunno, really - I tried that on linux and it did not appeared. The 
difference is only in one thing - you let os pass time-switch point, 
or you skip it. In linux, when you report time in console, you can 
see one other letter, which signals you if time shift is accounted 
for or not, but dunno how it is with Windows ...

#3885, #3895, #3896 and speed of 1.3.2 beta OK, passed all my tests

1.3.2 beta? I had to miss that one :-)

bad name - the official name is 1.3.1d

is there a list of fixes/additions somewhere? Or can I query RAMBO 
somehow to show me what tickets were done for certain version?

I think, that the tickets are the ones I listed above

search for "1.3.2"

I want timestamp bug resorted :-)

and don't even dare releasing new View without fixing rebol.exe -i 
script.r (launching desktop, ignoring -i) :-)) ... because then rebol.exe 
can't be used for batch processing on machines, where you simply 
don't go via manual installation process ....

Bug #3873 isn't a bug. REBOL does nesting of { and } when strings 
are specified with {}, and ignores { and } when strings are specified 
with "". The ^ is unnecessary in "{^}" because the } doesn't need 
escaping. The ^ is a syntax error in {{^}} because the } would already 
be escaped by the first { inside the string (the second overall), 
so escaping it again means that the string is never finished, as 
there must be one unescaped } after every unescaped { because of 
nesting. In both cases you either shouldn't put the ^ ( "{}" or {{}} 
), or should escape the ^ if you want it in the resulting string 
( "{^^}" or {{^^}} ). Sorry if that was a little confusing - I'm 
sure someone else can explain it better.

with all respect on I completely disagree.

1) I am not able to understand, why {^{} is a syntax error

2) I completely disagree, that Rebol should check pairs of {} inside 
a string - I do want to be able to handle strings with arbitrary 
contents

Hi Ladislav, about 1) I completely agree ...

>> {^{}
{    }
** Syntax Error: Invalid string -- }
** Near: (line 2) }
>> {^}}
== "}"
>>

these should both be OK.


About 2) I agree partly ... if rebols parser counts pairs of {} I 
don't need to escape them, as long as I only have paired braces in 
a string. So that may be a nice feature ...

If the said feature works against the main purpose of strings - the 
ability to contain any sequence of characters, then I am wholeheartedly 
against it.

Well, what I meant to say on 2) if counting of braces frees me from 
escaping, fine with me. But escaping should obviously work. and it 
doesn't (at least not for opening brace)

Ladislav, I agree that since ^} is usable, so should be ^{. Counting 
of braces can be quite awkward without this. This should be submitted 
to RAMBO.


In any case, this behavior doesn't affect the ability to work with 
strings or limit the characters that they can contain. This only 
affects how strings are specified in REBOL source code. Once they 
are parsed by load, it doesn't matter where any ^ is in their contents. 
Try reading (READ native) data with arbitrary ^, { and } from a file 
and there will be no escaping performed. A load (LOAD native) of 
that same file will check REBOL data syntax and do any escaping it 
can.

Still, the behavior described in bug #3873 was actually intentional 
and documented.

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 ?