World: r3wp

So, for the above DRAW with object example to be useful, it would 
require a sequence of objects, so you're back to a block.

It's funny, I go back and forth a lot on my own designs in regard 
to object vs block.

For the human side, such as providing a style sheet containing graphics 
attributes, object is the winner. However, as that style sheet is 
processed, it is flattened into a sequence of commands sent to the 
AGG rendering engine.


Now, it's probably possible to change our API into AGG to use objects, 
and that's probably find, but I'm not sure that it's really any more 
efficient.

find = fine

true, but objects can be nested. and a single small object, like 
in the above, may actually represent MANY draw commands.
 

for example... a single block of text strings... may actually represent 
all the items of a text list.  parsing that list to fit things within 
bounds. 

re-creating the whole AGG block as you scroll the list, forces you 
to possibly generate a few hundred draw items in a block.


but you have to build that block using intepreted code, which only 
ends up being an intermediate in order to pass the visuals to the 
rendering.


with an object, constructing that visual can all be handled on the 
native side and will save a lot of work on the interpreter and the 
GC.

the object will contain a few parameters and it represents the list... 
but rendering it will all be managed in the native side.

though, as I said, this is not specifically Draw related... if I 
want to represent a node structure which has properties, methods 
as well as data, doing so using blocks is impossible to manage.

The above block of texts example is puzzling to me. Here's why... 
normally, the display is constructed from nested layers of GOBs, 
each with offsets. So, scrolling a specific area of the display does 
not require any reconstruction of the blocks.

What I find odd about your argument is that it implies that individual 
fields of objects would be selectively updated.

That means that those field references are specifically coded in 
the program... which to me means you're not really writing REBOL 
code, you're writing C++ in REBOL code.

It seems to me that the such a method result will be a program that 
is many times the size and complexity... and hence cost and brittleness.

Of course, I may not be understanding precisely your method.

(I know your code is usually nano-sized. ;)

I admit that I am one of the rare REBOLers to write what we can call 
"large" applications.

at some point, the benefits of context and object instantiation become 
invaluable.

I want to use R3 in a project that means I will need to manage hundreds 
of thousands of "things".


If I can shove all of the heavy lifting into the native side of things, 
then I use REBOL for what its good at, high-level control.  but the 
datasets might still be huge.

Only at the edges.

And, mainly at the human edge.

At the core, a CPU executes a sequence of instructions, not an object.

I guess I'd have to show you in actual code so you'd "see" it  ;-)

liquid is at the center of this, of course, but without objects, 
I coudn't easily hold state, process , cache and data together.

As far I know, Maxim don't use the nested gobs approach but reconstruct 
nested draw blocks instead.

liquid uses state to control processing.  each node is like a mini 
kernel only aware of itself.  by linking stuff together and with 
messaging, all the nodes cooperate.


right now, liquid is able to completely control a complete GUI forking 
of only the refresh of data which actually changes.  but i cannot 
implement some liquid's low-level code within extensions because 
they can't look up the nodes.

steeve, right, because in R2 there is other way to make a 100% AGG 
interface.

there is *no* other way

nested draw blocks may be slower in R3, but I see a benefit with 
Maxim's way. It allows easy composing and inheritance of transformations 
in the sub-blocks, like skewing, rotation, translation, scaling.

in R3 I could go far beyond, actually dumping some of liquid's processing 
directly in the native side of an extension.


in fact, I could use AGG or OpenGL directly without even using gobs 
or draw blocks since the interface is built by how you link things 
together and this linking and messaging will automatically fire-off 
AGG commands, without the need to go through an intermediate.

anyhow... object use is central to this, since its the most approachable 
way to group & bind things in context .

maybe you could simply convert your object into gobs ;-)

liquid is at a lower level than gobs (its not strictly gfx related) 
and I need object access for liquid (and other things).

off the topic, 

Gobs are not specifically related to graphics if they are not rendered 
(showed)

Gobs could be used to implement some efficient data structures, like 
linked list or tree.

As far I tested, dealing with structures of gobs is faster than with 
standard objets.

A really cool feature is that when a gob is append as a child to 
a gob, it's removed from its current parent automaticly.

Yes, true and useful too.

I need to find a group to discuss the PAIR changes happening. Suggestions 
anyone?

Core?

no !REBOL3

I guess. Kind of general group tho. Was hoping we had a graphics 
or datatypes group.

there's REBOL3 GUI

How to compile the sample ext-test.c using MinGW http://jira.rebolsource.net:8080/browse/REBOLKIT-5

Looks like it should be possible to call Java libraries from a C 
extension using the Java native interface ...

would be easier to use something like SWIG

http://www.swig.org/

Got an example of use with R3 extensions?

SWIG has REBOL support now? R2 or R3?

sure .. just use -r in the options :)

And then it magically reads your mind and chooses REBOL, rather than 
the R that it does support. We could use that ability in REBOL - 
it would allow us to implement half of the CureCode tickets we've 
had to dismiss :)

As you can see here .. Max took it upon himself to do something about 
swig R3B0L support http://www.rebol.net/cgi-bin/r3blog.r?view=0231

Ok, we can sign the 1 billion contract now

Has every group become the Humor group now? My grandma would say 
we are getting punchy :)

I guess we have to prove we're not a joke ...

Jocko, I was able to compile your tts example under visual studio 
express 2010 but with a lot of difficulties :(  
Size of the dll was 19.5 kbs vs your example which is 8.5kb

Maxim: Get and set of object fields has been added to the extension 
API in A101. So, great things can happen now?


But... before A101 is released I need a decent test for extensions, 
and Robert will be coordinating that project.

Graham, did not visual studio 2010 convert properly the visual 2008 
project file to visual studio 2010 ?