World: r3wp

File associations only affect the main script though, not the modules 
it uses. You can't use an Explorer to load a module.

And since the module lookup process doesn't apply to scripts, this 
is a bit of a non-issue.

>> system/version
== 2.100.96.2.5

>> to decimal! 1%
== 0.01
>> to binary! 0.01
== #{3F847AE147AE147B}
>> to binary! 1%
** Script error: invalid argument: 1%
** Where: to
** Near: to binary! 1%

>> to binary! %a 
** Script error: invalid argument: %a
** Where: to
** Near: to binary! %a

>> to binary! 0x0
** Script error: invalid argument: 0x0
** Where: to
** Near: to binary! 0x0


I think pair! should be binary! encoded/decoded something like this 
(in R2 it was to-binary formed):

to-raw-pair!: make function! [[
	pair [pair!]
	/local x y
][
	x: to binary! pair/x
	y: to binary! pair/y
	while [all [zero? first x zero? first y]][remove x remove y]
	append x y
]]

to-rebol-pair!: make function! [[
	pair [binary!]
	/local length
][

 to pair! reduce [to integer! copy/part pair length: (length? pair) 
 / 2 to integer! skip pair length]
]]

>> to-raw-pair! 0x255 
== #{00FF}
>> to-raw-pair! 0x256 
== #{00000100}

>> system/version
== 2.100.97.3.1

Recently I made some tests comparing the speed of  R3 to R2.

After getting results of R3  up to 100 times slowlier than R2 and 
more, I found that parse is now almost unusable for simple parsing 
under some circumstances.

I will later add a Curecode ticket.

sqlab. Post your tests ... I can't believe you :-)

not optimized ...

There is nothing to optimize in simple 
parse data "^/" .(

Ah, special mode parsing ... you try to get block of lines, correct? 
I wonder if using some parse rules instead would show so much of 
a difference between R2 and R3?

split produces the expected behaviour bit , but is still 10x slowlier.

c: ""
for i 0 255 1 [	append c to-char i ]
data: to-string array/initial 255 * 255 random c 
m: parse data "^/"
l: length? m

I get always diferent values for l.

>> trim/with #{001100} #{00}
== #{11}
>> trim/head/with #{001100} #{00}
** Script error: incompatible or invalid refinements
** Where: trim
** Near: trim/head/with #{001100} #{00}

sqlab - 'split is a mezzanine, hence slower imo ...

Is that behaviour somewhere documented, that this "special mode parsing" 
does not work anymore?

>> dt [ loop 1000000 [ parse "abc def" none ]]
== 0:00:01.842453


>> t1: now/precise loop 1000000 [ parse "abc def" none ] t2: now/precise
== 8-Feb-2010/23:00:21.43+13:00

>> difference t1 t2
== -0:00:01.004
>>

sqlab - I did not say it should not work, it should work. But there 
might be some bug or something like that, because parse was highly 
modified ...

G: Dont parse some chars many times, parse many chars a few times.

0 < 2 < 100 ... so still in the range

Especially look at the outcome of the parsing, even with the same 
data I get alyways different results

Graham - I don't understand your test at all :-)

just try my example

different results .. you're using 'random

let's try to compare following for R2 vs R3: 


 parse "abc^/def^/ghi^/" [start: any [end: newline (print copy/part 
 start end) start: | skip]]

well, just remove (print ...) ... I just want to find out the traversal 
time ....

I normally just parse short bits of text .. so R2 looks to be 2x 
faster than R3

s: now/time/precise loop 1000000 [parse "abc^/def^/ghi^/" [start: 
any [end: newline start: | skip]]] now/time/precise - s

Three consecutive runs:
R2:
0:00:03.11
0:00:02.941
0:00:03.089

R3:
0:00:01.732
0:00:01.679
0:00:01.724

the above code does not run in R3. Dunno if "end" is forbidden or 
became a keyword, but I get following error, if I don't change end: 
to en:


>> s: now/time/precise loop 1000000 [parse "abc^/def^/ghi^/" [start: 
any [end: n
ewline start: | skip]]] now/time/precise - s
** Script error: PARSE - command cannot be used as variable: end:
** Where: parse loop
** Near: parse {abc
def
ghi
} [start: any [end: newline start: | skip...

So - for basic traversal, R3 is faster .... for my example ....

even with my random generated data, the number of parts should be 
always the same.

But you can also parse the same data a few times. Every times it 
will be parsed in a different number of parts

end is a keyword!

The data I parse, are oftly in the 10s of MB and more.
With R2 I had no problems

>> start: now/time/precise loop 1000000 [parse "abc^/def^/ghi^/" 
[s: any [e: newline (append blk copy/part s e) s: | skip]]] now/time/precise 
- start
== 0:00:05.359

Hmm... tried to parse 4M chars a few times and r2 ran out of memory 
... r3 worked fine

There really is some problem:

R2:

>> start: now/time/precise loop 1000000 [parse "abc^/def^/ghi^/" 
"^/"] now/time/precise - start
== 0:00:00.933

R3:
==  0:00:04.259

I would curecode it, along with my example, and ask Carl about the 
possible cause ...

I did it already.

But your example does not show the real problem. just use my example 
and you will see why.

it shows very big time penalty ...

... which does not correspond to my manual parse example above ...

WTF? I get strange beeps when running your test code :-)

try running following code:

c: ""
 for i 0 255 1 [append c to-char i]

I get a beep here ....

each time I parse the dataset  ... I get it alternating between two 
lengths

I have no speaker at my pc.)

hmm, we are appending char into string ... who knows what it does 
internally :-) In charset, there are some escape/control codes, so 
maybe it causes a beep, I don't know :-)

I reported the strange beep into CC too ...

I copied the dataset before each parse ... very odd

Pekr, are you sure it's not just control chars printing to windows 
console causing beep?

could be a GC problem? Maybe above "beep" means there might be some 
memory leak?

maybe ... who knows ... should not beep ....

it surely is about control chars ...

why should it not beep?