World: r3wp

Steeve: Missing 'forall for gobs - you just need to point a word 
at the pane block - it shouldn't be too "expensive" as it is only 
a reference not a copy:

 >> gobs: d/pane
>> forall gobs [probe first gobs]

make gob! [offset: 0x0 size: 100x100 alpha: 0 text: "gob a"]

make gob! [offset: 0x0 size: 100x100 alpha: 0 text: "gob b"]

make gob! [offset: 0x0 size: 100x100 alpha: 0 text: "gob c"]

It is a copy, not a reference. The original pane is not a block, 
it is an internal array.

However, the gob references in the /pane block are references.

Thanks for the clarification. I should have tried same? first:
>> same? d/pane gobs              

== false

A good way to combine the "convert to block and assign to a word 
and then use FORALL" is to use REPEAT:
    repeat gobs d/pane [probe first gobs]

There doesn't seem much to chose between foreach and forall in terms 
of speed:

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

== 0:00:00.125035

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

== 0:00:00.133837


Using a do-it-yourself repeat loop courtesy of Rebolek  seems a little, 
but not much faster :

>> dt [loop 100000 [repeat i length? d[x: d/:i]]] 
== 0:00:00.115478

FOREACH has BIND/copy overhead of its code block, not slower speed.

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 ..