World: r3wp

the most simple client causing the receiving sever to crash

forever [
	con: open/binary/direct/no-wait tcp://receiver:13011
	insert con "a"
	wait con
	if not copy con [break]
	close con
]

what do you think about

>> parse "" [to 5 (print 1)]
1
== true

:-)

can't decode it s meaning:-)

no secret meaning, but i think, this is a bug.

what does to 5 mean in this case when you parse string? To fifth 
char?

Five times the next rule...

>> parse "aaaaa" [5 #"a"]
== true

but there is 'to in there ...

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

is the last case correct returning false?

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"

>> parse "abcde" [to 4 #"e"]
== false
>> parse "abcde" [to 5 #"e"]
== true

Interesting...

copy e to 6? Should be false imo!

that is imo bug :-)

hmm, so it means to fifth char?

Unless it is to an index position...

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

>> 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

>> 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. :-)

>> 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...

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.

I think the original point is -- parse "" [to 5] -- perhaps should 
not return true.

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 :-)

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

IMHO that is a bug. 
!> parse "123" [5 skip (print 1)]
== false
!> parse "123" [to 5 (print 1)]      
1
== true

skip makes more sense

[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.

>> 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.

Anton: It's same here. Function keys give strange results too. F1-console 
F2-listen F3-tcp F4-udp and so on.

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 :-)

things like what? :)

Strings in the rebol executable were changed to be stored differently. 
Maybe it has something to do with that.

You should RAMBO it