World: r3wp

REPEAT has the same BIND/copy overhead, but REPEAT w number! has 
less work to do, so it's faster. I wouldn't be surprised if REPEAT 
w series! is comparable to FORALL.

Repeat with series! seems a little slower than forall and foreach:

>> dt [loop 100000 [repeat gobs d/pane [x: first gobs]]]

== 0:00:00.175092

I can understand your REPEAT code being slower than FOREACH: You 
put an extra FIRST in the code block, so the code isn't comparable 
in speed. Compared to FORALL, there's the added BIND/copy overhead.

Try comparing without the FIRST, just put x: gobs in there, or better 
yet leave the code block empty.

I simply modified your code ... without thinking :-)

.. and it does seem equivalent to the forall example above.

>> dt [loop 100000 [repeat x [1 2 3 4] []]]
== 0:00:00.062792
>> dt [loop 100000 [repeat x 4 []]]
== 0:00:00.060991
>> dt [loop 100000 [foreach x [1 2 3 4] []]]
== 0:00:00.064321
>> dt [loop 100000 [x: [1 2 3 4] forall x []]]
== 0:00:00.026746

Gotta love that BIND/copy overhead :(

>> dt [loop 100000 [x: [1 2 3 4] forskip x 1 []]]
== 0:00:00.031414

>> dt [loop 100000 [loop 4 []]]
== 0:00:00.019578
>> dt [loop 100000 [x: 4 while [0 > -- x] []]]
== 0:00:00.043203

I am trying to understand why the forall gob example isn't faster 
than the foreach example:


>> dt [loop 100000 [foreach gob d/pane [x: gob]]]                
    

== 0:00:00.123409


>> dt [loop 100000 [gobs: d/pane forall gobs [x: first gobs]]]   
    
== 0:00:00.129035

It's the FIRST you added to the code - it makes the code slower.

But the first is needed for the code to be equivalent isn't it?

You aren't testing code equivalence. FORALL is used in different 
circumstances than FOREACH. If the code is huge it adds to the BIND/copy 
overhead. If you have to use FIRST all the time it slows down FORALL 
because you're not using the right function.

The functions aren't equivalent, so whichever is faster depends on 
the needs of your code and data.

I am trying to find which is the faster way to iterate through the 
sub-gobs! that are contained within a gob!. I am not trying to compare 
the speed of the basic looping functions.

Of course this is all for R3. For R2, FORALL, FORSKIP and FOR are 
mezzanine, so they're a *lot* slower. The proposed FOREACH enhancement 
for 2.7.8 should allow it to be used instead of FORALL and FORSKIP.

In that case, I'd go with FOREACH if you expect to have a lot of 
subgobs and you aren't doing much to them, or with FORALL if you 
have a lot of code in the code block, but not a huge number of subgobs 
in a given gob.

So far I haven't seen a gob with enough subgobs to make FOREACH the 
right choice. I'd go with FORALL.

btw, in R3, gobs/1 is a little faster than [first gobs] IIRC

To answer your question, Pekr, R3 alpha 98 has been released! http://www.rebol.com/r3/downloads.html

hmm, 395 KB, so GUI-less release. Preparation for View externalisation 
:-)

I start the countdown, for new tickets in CC - "Demo does not work 
in A98 anymore" :-)

Going through the tickets now, two were not fixed due to a misunderstanding, 
many more test perfectly, including one dismissed years ago.

Have some display bugs though that need more testing, and a weird 
new bug in HELP.

Simple parsing does not work for large gatasets
 bug fixed. Nice - http://curecode.org/rebol3/ticket.rsp?id=1480

And Carl's mods to the tests for that were nice too. Also, take a 
look at #1452 - note the limitations.

what limitations?

I wrote them in a comment. You can only insert/append blocks containing 
values of these types: binary!, string!, char!, and integers from 
0 to 255 which are inserted as bytes. Anything else will need explicit 
conversion.

Note: No compressed modules yet. They'll get in as part of the mezzanine 
review.

ah, ok (re limitiation), I just tried joining two binaries and it 
worked. Did not try with integer value ...

I tried everything I could :)

I can see those protect/uprotect/hide bugs mentioned in various tickest. 
Aren't those blocking us? Maybe you should push their priority?

They are blocking us, but not as badly as the a98-derived host kit 
is. I would like more feedback on the security model they propose.

BrianH: can you sum-up, what works in A98, re Extensions/Host Kit? 
What things are still missing? Any docs anywhere?

No, I haven't tested them yet, because there aren't enough docs yet. 
I was only able to test core stuff.

Came up with a proposal for the binary conversions - take a look: 
http://www.rebol.net/cgi-bin/r3blog.r?view=0317#comments

Let me guess .. none of the network protocols have been added ...

Almost none of the mezzanine fixes either - this was a release with 
native focus.

And by that I mean the *already posted* mezzanine fixes.

yes, Hostkit is a priority right now, absolutly. Other fixes might 
wait. I even think, that we should "finish" the low-level route .... 
hence add Extension support for devices, add tasking, a utypes ... 
then we can state the Core is almost finished for beta ...

Already posted a fix to the new HELP bug #1604.

If we can build our own cores .. I guess we can add our own protocols

or not ..

Did you submit your changes to DevBase? I'm verifying the submissions 
there now - it looks like *some* of the mezzanine fixes were included 
in a98.

We should do a poll of what OS everyone is using.  Seems to me odd 
to release two OSX builds and no Linux

Aggh... no polls here.  I was thinking of IOS

Is it odd, or just nighttime? Let Carl sleep - it's almost 2am there. 
We'll see if they are still not built tomorrow.

even then

only 9 pm here ...

Graham - it is all because Apple is being popular in US ....