World: r3wp

Thanks again Rebolek - I hadn't worked that out as the probe results 
led me to believe that the append had an implicit copy as it seems 
to do for blocks:

>> a: []      

== []


>> b: [1 2 3] 

== [1 2 3]


>> append a b 

== [1 2 3]


>> a

== [1 2 3]


>> b/1: 4

== 4


>> a

== [1 2 3]

Actully there's no copy in append - you're appending only values 
of 'b to 'a, not 'b. See this:

>> a: []
== []
>> b: [1 2 3]
== [1 2 3]
>> append/only a b
== [[1 2 3]]
>> b/1: 4
== 4
>> a
== [[4 2 3]]

..but isn't it a copy of the value when you use append:

>> a: copy ""                            

== "


>> b: 
hello"                           
 
== "hello"


>> append a b

== "hello"


>> b/1: #"j"

== #"j"


>> b

== "jello"


>> a

== "hello"

I've also found that the gob! pane field provides a neater way of 
iterating through the gob!s inside a gob!:

>> foreach gob d/pane [probe gob]

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

Cool, I thought there was something like that Peter :)

but there is a memory overhead, so take it with care... (actually 
it's not suited for intensive computings inside a GUI,, just my opinion)
>> same? d/pane d/pane
== false

Giuseppe - Ouch!

Missing 'forall for gobs

It should be possible to have FOREACH iterate through the pane of 
a gob directly. I'll request it, or see if such a request is there 
already. FORALL wouldn't be possible because a gob pans has no position.

not agree
find works with gobs, allowing things like:
>> remove find gob-parent gob
So, a position is somewhere

However, if you are doing intensive computing with gobs with REBOL 
code, a simple creation of a block of references to the existing 
gobs isn't that much overhead, compared to most REBOL operations. 
Gobs are designed to be efficient to compute by native code at display 
time, not for REBOL code.

Scrolling a pane with hundred of gobs, that's what i call intensive. 
And it 's not rare use case to my mind.

Hence the FOREACH suggestion.

A98 is somehow dalyed, isn't it?

somehow...

It's possible that it was delayed already because of some host kit 
blockage, and we got all of the 'self and bug fix goodness while 
Carl was thinking it through. I'm not worried yet.

the hostkit extraction is a pretty huge endeavour, because he has 
to change the core model and open it up much more.


the GUI pokes at just about every level into the core things like 
actions (callbacks into the core), devices, object access, these 
can't be side-stepped IMHO.


yes the A98 (or whichever release fully extracts view from the core 
as an extension), will be the mother of all releases.   The only 
REBOL release I have been waiting for... for over a decade.

Tickets #1595, #1596, #1597, #1598 and #1599 added, and #810 finally 
has some test code. Sorry, I didn't know before that gobs had reference 
position :)

I went through all of the series! functions to see which apply to 
gobs, and didn't support them already. Apparently, all of the loop 
functions make sense to support, and all of the access, ordinal and 
traversal functions are supported already. The only ones that don't 
make sense to add are the set functions, SORT and comparisons; otherwise 
it would make sense to add gob! back to series!.

COPY gob! doesn't work either. So gob! in series! is not really an 
option.

COPY !gob should work though.

Gobs are unique, and copying one can't copy its subgobs. In theory, 
COPY/deep gob! could work, or COPY of a gob! with no subgobs, but 
COPY gob! with subgobs would need to trigger an error. Instead of 
doing that (since COPY doesn't otherwise trigger an error), it was 
decided to ger rid of COPY gob! altogether, and use MAKE gob! instead.

Not my decision though, it was Carl's, and he would know more than 
anyone what is and is not possible with gobs. At least until the 
new host kit comes out.

I'd prefer to have copy work on gobs and yes, enforcing /deep since 
it can't be done any other way.


I can see situations where one would want to store gobs and duplicate 
them as bunches, especially when they are small bits and pieces strung 
together.

but yes, its Carl's call so far.

For one thing, gobs can't copy their data references even if you 
use COPY/deep, because gobs don't understand what is in those references, 
and because in almost all cases there are reference cycles in the 
GUI between the gob and the object referred to by the data. I can't 
imagine it ever being safe to copy gobs in a real GUI.

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