World: r3wp

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

things like key-up, ability to generate events, etc., simply things 
which were planned, don't yoy remember, Kru ;-)

I remember lot of things Pekr :)

then you are good. I feel older and older, that I don't sometimes 
remember, what I wanted to remember :-)

It may be better not to remember everything that was promised :)

Ok, submitted to RAMBO.

I noticed Rebol/View 1.3.60 and 1.3.61 seem to have a problem making 
routine!s with a callback! arg in them. Anybody else ?

eg.
** Script Error: Invalid argument: callback!
** Near: setErrorHandler: make routine! [
    errorProc [callback! [string! integer! return: [int]]]
    return: [integer!]
] COMLib

The above routine has no problem being made in View 1.3.1.3.1

Cyphre has noticed that too.

Ah, just reading through rambo tickets, looks like this one is fixed 
already for View 1.3.2

:)

note that 1.3.2 is lesser than 1.3.61. ;) A lot of experimental code 
has been removed for the 1.3.2 release. They will be back in 1.4.

When can we expect 1.3.2 and when 1.4 ?

1.3.2 should be very soon. 1.4 i don't know.

So what can we expect from 1.3.2 ? Bugfixes? yes. Rebcode? no. Rebservices? 
don't know. Rich-text? probably no, as we haven't seen this in alphas. 
new datatypes? probably not. Something else? don't know.

kru, probably what you see in RAMBO :-)

Henrik in RAMBO I can see only bugfixes, but no informations on what's 
going to be added (if anything will be added).

rebservices would probably be considered a major change, so maybe 
that won't get in until 1.4.0

It would be great to know when can we expect 1.4.0 . In a month, 
two, half a year...I know that it's hard to predict release date, 
but give us some estimation, please :)

if i would, you'd then quote me on that. :P and anyway, only Carl 
could possibly tell you a date.

OK, I was just trying ;)

Ah no - temporal instability again :)

3896 Load {#[object! ...]} doesn't create global words as expected.

I thought that was a feature. My concern are tcp-daemons with open 
clients. The old way someoneId:	 cant overflow the word-table with 
garbage data. If data-words are added too, someone can.

Yuks, mouselcick to much..

3896 Load {#[object! ...]} doesn't create global words as expected.

I thought that was a feature. My concern are tcp-daemons with open 
clients. The old way someone cant overflow the word-table with garbage 
data. If data-words are added too, someone can.

not adding words to the global table leads to crashes, unless you're 
using them strictly as symbols (which is not the case if you are 
creating objects...)

Crashes or errors?

But yes, the words have to exist in case something in a block wants 
to bind to it. Or it gets complicated.