r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[RAMBO] The REBOL bug and enhancement database

BrianH
8-Sep-2005
[1125]
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.
Ladislav
8-Sep-2005
[1126x2]
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.
Volker
8-Sep-2005
[1128x2]
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.
BrianH
9-Sep-2005
[1130x3]
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.
Volker
9-Sep-2005
[1133]
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.
JaimeVargas
11-Sep-2005
[1134]
;APPEND not returning the head of list! 

>> append my-list: make list! [] [value1 value2]  ;== make list! 
[value1 value2]
>> head? my-list  ;== false
Ladislav
11-Sep-2005
[1135]
>> my-list: append make list! [] [value1 value2]  ;== make list! 
[value1 value2]
== make list! [value1 value2]
>> head? my-list
== true
BrianH
11-Sep-2005
[1136]
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.
Ladislav
13-Sep-2005
[1137x2]
>> 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
JaimeVargas
13-Sep-2005
[1139]
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"
Ladislav
13-Sep-2005
[1140]
err, both S and L are the same, sorry, it is consistent in that sense
JaimeVargas
13-Sep-2005
[1141x2]
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]
Pekr
13-Sep-2005
[1143]
Jaime - will you report those bugs? That should be fixed, no?
JaimeVargas
13-Sep-2005
[1144]
Yes. I am reporting them.
Pekr
13-Sep-2005
[1145]
#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 ;-)
Tomc
13-Sep-2005
[1146]
any thoughts on   for i 0 0 0[prin "dejavu"]
Graham
13-Sep-2005
[1147]
0 <> 0 ?
Tomc
13-Sep-2005
[1148]
I would expect it to not do anything since the end is reached before 
beginning
Graham
13-Sep-2005
[1149]
I thought 'while was the only iterative control structure that didn't 
execute at least once.
Sunanda
13-Sep-2005
[1150]
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"]
Ashley
13-Sep-2005
[1151]
>> repeat i 0 [print i]
>> foreach i [] [print i]
== none
Will
14-Sep-2005
[1152x5]
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
Anton
14-Sep-2005
[1157]
that's what it says ! ;-)
Ammon
14-Sep-2005
[1158x2]
>> 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...
JaimeVargas
14-Sep-2005
[1160]
Were you playing with callbacks?
Ammon
14-Sep-2005
[1161x2]
No
the actual line that caused the crash:

>> number? "10
JaimeVargas
14-Sep-2005
[1163]
Then some other issue callbacks can crash rebol if the limit of them 
is exceeded.
Ammon
14-Sep-2005
[1164]
What callbacks are we talking about here?
JaimeVargas
14-Sep-2005
[1165]
http://www.rebol.net/article/0141.html
Ammon
14-Sep-2005
[1166x2]
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.
Graham
14-Sep-2005
[1168x2]
get-face on a field with hide returns asterisks instead of the text.
Is that a "bug" ?
Henrik
14-Sep-2005
[1170]
I've seen this before and it's probably because password fields store 
data a bit differently than normal text fields.
Graham
14-Sep-2005
[1171]
I know, but the get-face accessor function is supposed to help newbies 
avoid having to know these differences
Henrik
14-Sep-2005
[1172x2]
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
Graham
14-Sep-2005
[1174]
I'd better download and test the latest view before I submit a report.