World: r3wp

I've done the same thing as Max, and if there is just one refinement, 
I'll still use EITHER. If you have a scenario where there's an entry 
point that delegates work and requires multiple options, consider 
making it a dialected func.

The APPLY mezzanine in 2.7.7 has a minor, obscure bug that is fixed 
in a later R2/Forward release, and later R2 mezzanine source. But 
aside from that it works fine, and I have used it in production code 
with no errors (the bug was so obscure that it never came up in practice 
or testing).

Maxim, you forgot to copy oblk.

Without APPLY or something like it, you end up having to do some 
tricky stuff sometimes. See this REMOLD backport for instance:

remold: func [
	"Reduces and converts a value to a REBOL-readable string."
	value [any-type!] "The value to reduce and mold"
	/only "For a block value, mold only its contents, no outer []"
	/all "Mold in serialized format"
	/flat "No indentation"
][ ; Nasty, but the best you can do without native APPLY
	do pick pick pick [[[
		[mold reduce :value]
		[mold/flat reduce :value]
	] [
		[mold/all reduce :value]
		[mold/all/flat reduce :value]
	]] [[
		[mold/only reduce :value]
		[mold/only/flat reduce :value]
	] [
		[mold/only/all reduce :value]
		[mold/only/all/flat reduce :value]
	]]] not only not all not flat
]
; Note: Uses APPLY in R3.

good catch on the copy

And that REMOLD should be using get/any 'value instead of :value 
- an R3-ism that crept into the code.

is get/any 'value faster?

No, but it supports molding unset! values and errors.

ok, thought that was the reason

In R3 :value supports that - it means GET/any instead of GET.

cool! its easy to trip R2 when scanning blocks and an unset! value 
lies there

We did a *lot* to make R3 easier and more powerful :)

Nevermind, I think the [any-type!] in R3's REMOLD is the error, not 
the :value in the backport. I'll fix it now and put in a ticket.

See my beloved version :)

remoldx: func [x /all /flat /only][
	do head clear change change change next 'mold/?
		pick [[] all] not all
		pick [[] flat] not flat
		pick [[] only] not only
		reduce x
]

You forgot to copy 'mold/? :)

no, it doesn't matter
because of the clear

The clear clears the end, since that is what CHANGE returns, so it 
has no effect.

it has an efffect because the path is modified inside the source 
after each call

but i have not tested without clear

Yes, but at the position the CLEAR is in the source, it has no effect. 
The modifications to the path persist.

>> source remoldx
remoldx: make function! [[x /all /flat /only][
    do head clear change change change next 'mold/?
    pick [[] all] not all
    pick [[] flat] not flat
    pick [[] only] not only
    reduce x
]]
>> remoldx/all/flat/only [1 2 3]
== [1 2 3]

>> source remoldx
remoldx: make function! [[x /all /flat /only][
    do head clear change change change next 'mold/all/flat/only
    pick [[] all] not all
    pick [[] flat] not flat
    pick [[] only] not only
    reduce x
]]

i tried without 'clear just now, and as I thought, it's broken right 
now

I tried with clear just now, and it was broken.

As demonstrated above.

works well here, try a probe
Are you trying with R2 ?
It's not working with R3

remoldx: func [x /all /flat /only][
	do probe head clear change change change next 'mold/?
		pick [[] all] not all
		pick [[] flat] not flat
		pick [[] only] not only
		reduce x
]

probe remoldx/all [next 'a/a 2] 
probe remoldx/all/flat [next 'a/a 2]
probe remoldx [next 'a/a 2]
probe remoldx/only/all/flat [next 'a/a 2]

>>

mold/all
[#[path![a a]2] 2]
mold/all/flat
[#[path![a a]2] 2]
mold
[a 2]
mold/all/flat/only
#[path![a a]2] 2

Just traced through, and the changes are persistent but the clear 
cleans up any extras. So it works from the outside, though it's not 
recursion-safe in R2 or R3, and not task-safe in R3.

The APPLY mezzanine uses a similar method (building a path), but 
creates a new path every time to be recursion-safe.

Weird one :)

remold: func [x /all /flat /only][

 do head remove-each ref next copy 'mold/all/flat/only [not get in 
 bind? 'x ref] reduce x
]

Jeez , I don't need of the bind stuff...

remoldx: func [x /all /flat /only][

 do probe remove-each ref copy 'mold/all/flat/only [not get ref] reduce 
 x
]

I like this one, short.......

oups, i let the probe, even shorter.....

I didn't know, that even the refinements was bound to the context 
of the main function.

I meant the words in the path

I meant the words in the path

Well, It's needed when the paths are calculated (forget what I said)

Nice. In R3 you'll need a temporary variable for the copied path 
because REMOVE-EACH returns the count removed instead of the value.

Hah! I never thought of doing it that way. Very cool Steeve.

Is there a faster way to replace the first two charcters in the given 
string by the fifth and sixth character of the same string?
 
>> s: "123456789"
== "123456789"

>> change s copy/part at s 5 2
== "3456789"

>> s
== "563456789"

I suppose using pick and poke is not faster.

or:

s/1: s/5
s/2: s/6

this prevents the copy... 

change/part s at s 5 2

Max, but, unfortunately, it does not do what is needed

ah yes... I thought it applied the range on both sides, but it only 
does so in the source string...

Perhaps 'move should have an option to copy ....

Nothing comes to mind Ladislav. You're going to have to copy in any 
case, correct?

Well, I once thought, that there was a way how to circumvent the 
copy, but it looks to me now, that I was wrong

Henrik's method circumvents the extra copy :)

yes, but it does not look to me like a viable way to replace a CHANGE 
X COPY/PART Y by a cycle of that kind, although I did not measure 
the speed difference, yet

forall s [if find [1 2] index? s [s/1: pick head s ((index? s) + 
4)]]

:)

hm .. anyone has any idea why rebpro on linux says "Set-Net not provided." 
I googled but couldn't find the point why is this.
I tried do-ing prot.r and mezz.r