World: r3wp

File extensions: Can we all agree to use .r3 for R3 related scripts? 
IMO a lot of people will use R2 and R3 in parallel for some time. 
Hence, it's necessary to seperate the two to select the correct interpreter 
etc.

I use .r3 from the beginning.

me too !

I too, but VID34 code etc. uses .r

I think the current VID3.4 source naming was before we talked about 
the .r3 extension.

I am not sure. There was a proposal to use REBOL3 [] in a header 
of a script ....

but as for me, generally, I don't mind. But as Amigans we always 
hated Windows for making decisions upon stupid file extension :-) 
OTOH if you would like to set associations, it is really better to 
use r3 for R3. That way you can have .r associated with R2 version 
....

That won't help a lot. As Windooze uses the extension to select the 
correct program.

You can use .r3 if you like. Aside from file extensions that are 
used by codecs or R3 extensions, the file extension is considered 
irrelevant if you specify it explicitly. One gotcha: If you import 
by module name and the module isn't loaded yet, the process of searching 
the library paths currently only looks for .r files. That can be 
worked around by including a module or script in your project that 
imports those modules explicity by filename - after that the import 
by name method will use the loaded module.

Was just  looking over some of the new features in R3.  What is funco?

Why was motive behind it rather.

FUNC does a COPY/deep of its spec and code block, for safety and 
recursion-safe use within functions (see the source of COLLECT for 
an example of this). However, the internal code uses a non-copying 
version to lower overhead. That non-copying version is assigned to 
FUNCO as the last thing, and the copying version assigned to FUNC. 
FUNCO is left defined for power users who can asses the safety of 
not copying their function specs and bodies.

Can you give me a quick example of how to understand those ramifications 
if we don't copy?

make function! [spec body] doesn't copy the spec or body, it just 
uses them (or does a BIND/copy, I'm not really sure). If that spec 
or body contains literal values that get modified later, they get 
modified in the function as well.

ahhh got ya.

What kinda value do you pass to to-utype?

None. User-defined datatypes don't work yet. The datatype is a placeholder 
for now.

ok, got ya.

how about to-typeset?

And before you ask, I don't know what EVAL is used for either, just 
what it does: It does a DO on block! arguments, but returns the argument 
unevaluated otherwise. I've asked Carl what it's used for and haven't 
gotten an answer yet.

yeah ask about dump also.

TO-TYPESET creates typeset! values. We don't have R2's pseudo-datatypes 
like series! anymore, we now have typeset!, sort-of an immediate 
bitset for datatypes. It speeds up function calling and allows all 
sorts of other things. I backported a fake version of typesets to 
R2 as well in the 2.7.7 release.

TYPES-OF function! returns a block of argument words and typesets.

Docs need more examples.  If someone just went thought the R3 Functions 
page and separted it into a seciton that says NEW in R3 and explained 
those and gave an example for each we would have awesome docs.

There's already been a blog about that recently: http://www.rebol.com/article/0456.html

Check the comments - it talks about reorganizing the docs.

TYPES-OF works on other function types as well - we have a lot of 
them.

Brian, please add that .r3 scripts are searched for as well. And 
that .r3 takes priority over .r if filenames are the same.

The strategy that seems to work best is to have platform-specific 
scripts in different directories and set system/options/module-paths 
to pick the sets of files that are appropriate.

Since this isn't just a R2 vs. R3 problem, it's also a Mac vs. Linux 
problem, etc.

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