World: r3wp

I would put small wait before the 'call.  What about call/wait? Hmm, 
that would wait before next function call. This is strange ...

'delete calls 'remove. The question is, if that native really waits 
for the result, or just submits the call to OS layer and returns. 
Then, especially with crappy sloppy Windows FS you might get some 
delay ...

I treid wait
I tried alert to stop it at certain points

I thought that was the problem  (too much delay with OS cleaing up 
deletes and writes etc...) but the waits and alerts seem to be ignored

your script is buggy anyway, no? You delete %captain.exe but you 
rename %NEW.exe to %client.exe, which you run in the end. So:

1) what is %captain.exe good for?
2) why not to directly write/binary to %client.exe then?

I write a batch script to do this .. ie. write the new file name 
as temp.exe or something.

Then do a call/quit to the update.cmd script.

Just pulled the bullet from my foot.


buffer: copy {} ;works better than buffer: {}   I was suspecting, 
then finally tried (fixed a random-looking problem)

Anyone know the efishantsea between these?

buffer: copy {}

vs

clear buffer

I think clear is faster but surprisingly seems to use more memory:
>> fastest [buffer: copy {}] [clear buffer]

The first code took 0:00:00.012196

The second code took 0:00:00.008569

>> fastest [buffer: copy {}] [clear buffer]

The first code took 0:00:00.011403

The second code took 0:00:00.008293

>> stats

== 63378943

>> loop 100000 [buffer: copy {}
]
== ""

>> stats

== 66979663
>> recycle

>> stats

== 63378971

>> loop 100000 [clear buffer]

== ""

>> stats

== 63379907

>> recycle

>> stats

== 63378971

wow, nice analysis, Peter.  Almost feel like AltME makes a good benchtop 
software scope...;-)   Where does 'fastest come from?

Peter, I read you example, as clear use *less* memory than the copy 
method.
>> 66979663 -  63378943
== 3600720
>>  63379907 - 63378971
== 936

I would expect
clear buffer
to be faster and use less memory than
buffer: copy {}

And it seems to be so.

there would be less GC with clear, too, wouldn't there?

yes

Thanks, John. I only looked at the last few digits. I must read more 
carefully. Now the results are as I'd expect.

eFistAnt, Ladislav has some timing functions here: http://www.fm.tul.cz/~ladislav/rebol/timblk.r
I just use:

time: func [:f /local t][
    t: now/time/precise 
    do f 
    now/time/precise - t
]

And then time many loops of some code, like:

>> time [loop 10000 [buffer: copy {}]]
== 0:00:00.245122

Fastest is a trivial script that I use. I think many people have 
better ones.

>> source fastest
 
fastest: func [

     f
 
    s
 
    /local
 
    st
 
    en
][

     st: now/precise
 
    loop 10000 [do f]
 
    ed: now/precise
 
    print ["The first code took" difference ed st]
 
    st: now/precise
 
    loop 10000 [do s]
 
    ed: now/precise
 
    print ["The second code took" difference ed st]

]

Making the GC (Garbage Collector) to as little as possible is a good 
thing! (TM) :-)

This looks strange to me:

>> a: [a1 b1 a2 b2 a3 b3 a4 b4]
== [a1 b1 a2 b2 a3 b3 a4 b4]

>> extract/index a 2 1
== [a1 a2 a3 a4]
>> extract/index a 2 2
== [b1 b2 b3 b4]
>> extract/index a 2 3
== [a2 a3 a4 none]
>> extract/index a 2 4
== [b2 b3 b4 none]
>> extract/index a 2 5
== [a3 a4 none none]

Why is NONE returned? I would expect just a shorter block.

I don't see any cause to fill up the returned block with "virtual 
values".

You can use my replacement for it

skip+: make function! [
    {Returns a series matching the skip sequence}
    series [series!] "Series to return skip values from."
    interval [integer!] "Skip interval"
    start [integer!] "Series index to start skipping from."
    /local blk
    ][
    blk: copy []
    if interval > (length? series) [return none]
    series: at series start
    while [not tail? series][

        if (index? series) = start [insert tail blk first series start: start 
        + interval]
        series: next series
    ]
    series: head series
    if empty? blk [return none]
    blk
]

Can I limit the end as well? Something like a SLICE?

not sure what you mean.

I have a long series of fixed width and need to extract starting 
from a current position backwad/forward the x-th value.

Your verison runs until the end of the series. I just need to skip 
the next 10 entries.

just copy that part of the series into a new series.

copy/part

I wanted to avoid the copy.

But OK.

:)

Is there an easy way to break out of a nested loop?

eg.

forever [
	forever [ 
		if true [ break outside both loops ]
	]
]

use throw and catch I guess

You could try to convert one of your loops to a function and do something 
like this:

>> y: func [] [             
[    forever [                
[        i: i + 1                 
[        print i                  
[        if i > 3 [return [break]]
[        ]
[    ]
>> i: 0
== 0
>> forever [do y]                                               
1
2
3
4

In other cases where you want ot break out of the inner loop, just 
return an empty block:

>> z: func [] [return []]
>> forever [do z]        
(escape)

Graham, catch and throw

hehe .. that's what I said

ah... yes

Continuing from Puzzle Answers. Isn't this a bit funny or strange?

First some failed attempts to make 2 a word of value 1:

>> 2: 1
** Syntax Error: Invalid time -- 2:
>> set '2 1
** Syntax Error: Invalid word-lit -- '2
>> set [2] 1 
** Script Error: Invalid argument: 2


So 2 shouldn't be a word. But then it's possible anyway with this 
trick:

>> set to-word "2" 1
== 1

2 is still a number:

>> 2
== 2

But 2 as a word exists:

>> get to-word "2"
== 1


I think, it's a bit strange. If it's intentional or not, I don't 
know.

the first behaviour (the error) would be the expected behaviour if 
you assume that base symbols such as number are protected from modification 
- this protection in R2 at least is not complete.

consider trying to audit code with blocks made in word form.. another 
source of insecurity / bugs

The only thing that blocks numbers to become word! values is the 
lexical scanner. When you type anything in console (or DO a file 
script), your input is first a string! value that gets LOADed (that's 
where the lexical scanner raises errors). TO-WORD allows to bypass 
the LOAD phase and force the conversion of any symbol to word! value.

Maybe it would be a good idea, if constructors like TO-WORD etc. 
would do a lexical scanning of the result?

Anyway, this gives us a probably unique method for strong code obfuscation. 
:-)

heh indeed!

heh, yeah! It's fun at times, but is it really a good idea?

the set to-word "2 + 2" with spaces is a bit of a worry

I agree, TO-WORD should enforce word! syntax rules on argument and 
raise syntax errors accordingly. That would be a more logical behavior. 
Maybe Carl had some design issues to workaround by allowing this 
(or maybe it's just an implementation flaw).

>> set to-word " " "secret"
== "secret"
>> blk: reduce [to-word " "]
== [ ]
>> reduce blk
== ["secret"]