World: r3wp

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"]

Good one! Nothing can be something in REBOL. :-)

There is no spoon
 or "The truth is elsewhere" could make nice REBOL baselines. ;-)

R3 however does do a whitespace check thankfully

whitespace characters appear invalid in words in R3 - although if 
they are able to be redefined that could be an issue/weakness

Geomol <funny or strange>

It gets odder ( or less consistent) as '+ does seem to be given special 
handing......

What I really wanted to do to solve the puzzle was:
    -- set to-word "2" 5
    -- set to-word "+" none
The block then becomes (in effect)
   do [5 none 5]
   == 5
      

But DOing the gimmicked block in R2 fell found of '+ being both a 
native and some hardwired syntax in the interpreter:

    set to-word "2" 5
    set to-word "+" none
    blk: copy []
    blk: reduce [to-word "2" to-word "+" to-word "2"]
    probe blk
        == [2 + 2]
    do blk
        ** Script Error: Invalid operator: +
        ** Near: 2 + 2

In R2 the operators are special-cased by DO. In R3 they handle themselves 
(quicker that way).