World: r3wp

hehehe, Don't I love GLASS and its GLOBs.... they actually do know 
 ;-)

I can duplicate globs visuals as many times as I want and actually 
even in the same display and several windows at the same time.

I can't wait for A98, so I can start hitting the metal with GLASS.

In R3, the GUI objects have a reference to their gobs, for high level 
code, and the same gobs have a reference to their higher-level objects 
in their data field, for low-level code. Both of these references 
are necessary. So im most cases there is a reference cycle in real-world 
code.

The object referenced in the gob's data field is the face object, 
at least for the kind of gob that is so high-level that it has a 
face associated with it. Faces can be made up of one or more gobs, 
sometimes a lot more.

New R3 blogs!

- The big binary conversions debate, get it while it's hot!  http://www.rebol.net/r3blogs/0317.html

- Explanation of the rationale of the unset! type.  http://www.rebol.net/r3blogs/0318.html

Note that the binary conversions blog is talking about a99, so rest 
asured: a98 won't be dealyed for this :)

A98 will be Core only, no?

Unknown.

A98 is supposed to be the big host kit revision, and that is supposed 
to mean moving the graphics into the host. So in theory, for that 
to work there needs to be graphics. On the other hand, a98 should 
be the first release where we can build our own core-only releases 
:)

Actual storage

 versus "network order" - do you like the current conversion from 
 integer to binary (network order), or would you like the conversion 
 as in R2 structs, where the endianness was not suppressed?

As far as I am concerned, I see the merits of the "network order", 
which looks more Rebolish to me

I would like TO-BINARY to return network order, and CONVERT to give 
me a choice.

network order ...

Same with TO-INTEGER binary! - network order.

How about this: convert [to: integer! bytes: 4 order: little] #{12345678}

The advantage to having a spec block is that you can return it from 
a function; you can't do that with refinements.

And you could convert to objects from a spec block too:

>> convert [to object [a [integer! bits 3] b [integer! bits 5]]] 
#{ff}
== make object! [a: 7 b: 31]

The to keyword is likely unnecessary. We could likely get away with 
a DELECT-style dialect.

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