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

sqlab
1-Dec-2005
[1351]
no secret meaning, but i think, this is a bug.
Pekr
1-Dec-2005
[1352]
what does to 5 mean in this case when you parse string? To fifth 
char?
Chris
1-Dec-2005
[1353x2]
Five times the next rule...
>> parse "aaaaa" [5 #"a"]
== true
Pekr
1-Dec-2005
[1355]
but there is 'to in there ...
Chris
1-Dec-2005
[1356x2]
Ah right --[ to 5 ]-- doesn't work, any more than --[ to some ]-- 
or --[ to any ]-- would.
And integers are specificly used as part of the parse rule:
>> parse [5][5]
== false
Pekr
1-Dec-2005
[1358]
is the last case correct returning false?
sqlab
1-Dec-2005
[1359]
parse "12345" [copy a to 2 copy b to 3 copy c to 4 copy d to 5 copy 
e to 6]
== true
>> a
== "1"
>> b
== "2"
>> c
== "3"
>> d
== "4"
>> e
== "5"
Chris
1-Dec-2005
[1360x2]
>> parse "abcde" [to 4 #"e"]
== false
>> parse "abcde" [to 5 #"e"]
== true
Interesting...
Pekr
1-Dec-2005
[1362x3]
copy e to 6? Should be false imo!
that is imo bug :-)
hmm, so it means to fifth char?
Chris
1-Dec-2005
[1365]
Unless it is to an index position...
Pekr
1-Dec-2005
[1366x2]
from sqlabs example it seems to be index position, otherwise if it 
counted num of chars, it would not start from the beginning of the 
string each time ...
so 6 in his example is equal tail ... index? tail "abcde" = 6
Chris
1-Dec-2005
[1368x4]
>> parse "abcde" [to 6 mk: (probe index? mk) to 1 mk: (probe head? 
mk) to 6]
6
true
== true
This may be painfully obvious, I'd never noticed it before...
I would say that sqlab's example was a bug, except that it is consistent 
with:
>> skip "" 5
== ""
>> head? skip "" 5
== true
Geomol
1-Dec-2005
[1372]
>> parse "54321" [to 2 mk: (print mk)]
4321
== false
>> parse "54321" [to "2" mk: (print mk)]
21
== false

I didn't know that either. Good to learn something new. :-)
Henrik
1-Dec-2005
[1373x2]
>> parse "54321" [to 5 mk: (print mk)]
1
== false
>> parse "54321" [to 4 mk: (print mk)]
21
== false
>> parse "54321" [to 3 mk: (print mk)]
321
== false
>> parse "54321" [to 2 mk: (print mk)]
4321
== false
>> parse "54321" [to 1 mk: (print mk)]
54321
== false
that would be the position in the string, not the actual digit in 
the string...
Geomol
1-Dec-2005
[1375x4]
Exactly!
Also works with thru:
>> parse "abcde" [to 2 mk: (print mk)]
bcde
== false
>> parse "abcde" [thru 2 mk: (print mk)]
cde
== false
Why do we write this under "RAMBO"? :-) It's not a bug!
Put it in the Wiki.
Chris
1-Dec-2005
[1379]
I think the original point is -- parse "" [to 5] -- perhaps should 
not return true.
Pekr
1-Dec-2005
[1380]
Chris - maybe it should, if you look at how skip "" 5 works. 'skip 
operation here is simply kind of doing "nothing" - trying to jump, 
but already at the end, so it jumps nowhere :-)
sqlab
1-Dec-2005
[1381]
Maybe my point is better explained with this example

 parse "12345" [to 6  copy a to 10 (print 1)]
1
== true

If  to 6 parses all positions, I do not expect that after the tail 
to 10 gives true
Volker
1-Dec-2005
[1382x2]
IMHO that is a bug. 
!> parse "123" [5 skip (print 1)]
== false
!> parse "123" [to 5 (print 1)]      
1
== true
skip makes more sense
Anton
2-Dec-2005
[1384x6]
[to 5] seems to be jumping off the end of the input.
event/key bugs with View 1.3.60 and 1.3.61
view layout [b: box feel [engage: func [face action event][if action 
= 'key [print event/key]]] do [focus b]]
(better make that PRINT a PROBE...)  My results when pressing various 
keys:
page-up -> "clipboard"
page-down -> "object"
home -> #"^@"
end -> "event"
insert -> "file"
etc... other keys are giving strange values too.
Anybody else see this ?
Doesn't seem to be reported in rambo anywhere.
Brett
2-Dec-2005
[1390x2]
>> parse {ab} [to {a} to {a} to {a} to {a} {b}]
== false
>> parse {ab} [to #"a" skip #"b"]
== true
>> parse {ab} [to #"a" to #"a" to #"a" skip #"b"]
== true
>> parse {ab} [to #"a" to #"a" to #"a" to #"a" skip #"b"]
== true
>> parse {12345} [to end to end to end to end]
== true
>> parse {12345} [to end to 6 to 10 to 100 to end]
== true
>> parse {123} [thru 4 (print 1)]
== false
>> parse {123} [to 5 skip]
== false
Thru seems closer semantics to skip. "To" seems to check before move 
and after move.  Which is wrong behaviour or expectations - I don't 
know.
Rebolek
2-Dec-2005
[1392]
Anton: It's same here. Function keys give strange results too. F1-console 
F2-listen F3-tcp F4-udp and so on.
Pekr
2-Dec-2005
[1393]
strange - then it seems like someone tried to do some experiments 
with either events or keyboard code, which can be a good sign of 
things to come :-)
Rebolek
2-Dec-2005
[1394]
things like what? :)
Anton
2-Dec-2005
[1395]
Strings in the rebol executable were changed to be stored differently. 
Maybe it has something to do with that.
Rebolek
2-Dec-2005
[1396]
You should RAMBO it
Pekr
2-Dec-2005
[1397]
things like key-up, ability to generate events, etc., simply things 
which were planned, don't yoy remember, Kru ;-)
Rebolek
2-Dec-2005
[1398]
I remember lot of things Pekr :)
Pekr
2-Dec-2005
[1399]
then you are good. I feel older and older, that I don't sometimes 
remember, what I wanted to remember :-)
Rebolek
2-Dec-2005
[1400]
It may be better not to remember everything that was promised :)