World: r3wp

There are a number of bad links in the extensions-embedded.html document 
... are they just docs yet to written? Or has the doc been moved 
destroying the links?

I looked at the example ext-test.c and it lacks the extension header 
as specified in the docs

The extensions docs say that dealing with handles is undocumented 
...  but if it's just an integer, can we just pass that back and 
forth between rebol and the extension?

the idea of handles is for an extension to give a key to a script, 
and make sure the script can't play with it.   by key, I mean an 
arbitrary value which makes sense for the extension (pointer, index, 
value, etc).

Quick check in. Hmmm... flooded.

carl... just look above my mock up of object access within extensions... 


does it makes sense to use the current API in given or other format?

I tried to send this on R3 chat but server is down..

Maxim: let's see if I can get you a Reb_Get_Object(obj, word) function. 
That would work ok, right?

one of the reasons I want to use objects directly within extensions 
is that I am noticing GC recycling interruptions while scrolling 
stuff in R2 AGG driven interface.

yes that would be great.  the important detail is the need for this 
accessor to be able to get objects too, so that we can browse a whole 
object structure.

re: "GC recycling interruptions"  if we can browse the objects directly 
from extensions a lot of the need to "bake" command access within 
blocks and execute via do-commands is alleviated in the first place.

Yep, I think it is a reasonable request.  The trick would be that 
you'd add any field names to the WORDs block of your ext module.

And, actually, the RXI_API would be RXI_GET_FIELD (because RXI_GET_OBJECT 
should be reserved for later obtaining parameters related to the 
object itself, such as number of values stored, etc.)

sure.


would there be a way to inspect an object to build something like 
in native C ?:

foreach words-of object [
	; ... do something ...
]

if you can add some object reference to the hostkit, I'll be switching 
over all of my tools to R3, may even help with low-level AGG, and 
finally start forgetting about R2.

:-)

as an example, we could just represent a draw structure using primitives 
as objects (which can include several AGG primitives) and call AGG 
native code directly from the object tree.

something like 
draw context [
	prim: 'cross-box
	offset: 10x10
	size: 20x20
	thickness: 1
	border: black
	cross-color: red 
]


would draw a box and two cross lines, without the need to reduce 
this at every refresh when its refreshed and data comes from external 
manipulators:

draw compose [
	pen (prim/border)
	fill-pen none 
	line-width (prim/thickness)
	line-pattern none
	box  (prim/offset) (prim/offset + prim/size - 1x1)
	pen (prim/cross-color)		
	line (prim/offset) (prim/offset + prim/size - 1x1)

 line (prim/offset  + (prim/size * 1x0)) (prim/offset  + (prim/size 
 * 0x1))
]

Both examples above reduce.

Passing attributes via objects vs block of args is one of those edge 
cases where picking the best choice really depends on the source 
of the data.

For example, many graphical objects will be cached in their reduced 
blocks, so it's not a GC problem.

but the first one becomes a persistent object and doesn't need to 
reduce over and over.  


when the structure becomes somethings which goes beyond 50kb of draw 
source,  reducing over and over hits the GC very fast.

In addition,  REDUCE on blocks now supports REDUCE/into that generates 
no garbage.

Well... I find that most coders don't pay close attention to their 
garbage side effects, but in a GUI sysetm, it's wise to do so.

yes, but if the structure is nested, you have to reduce things so 
they become flat.


also, not all situations allow you bind values directly to objects,

Again, it really depends... because the DRAW block is constructed, 
objects are not that good of a substitute, because their only benefit 
is named fields, which in a constructed domain offer no clear advantage.

also note that I gave this example as a Draw, since we can all quickly 
see what is happening, but the above applies to many other datasets 
which are used libs, and for which objects are much more user-friendly 
than objects.


think of C libs which use deep struct trees. I'd rather keep the 
user interface object related.

Object fields primary advantage is in human domains where the named 
fields make code more clear.

yes... but they also allow context on the REBOL source side.


note that with the example above using objects, I don't need to go 
thru a draw block on the native side.  I could inspect the object 
and fire AGG (or other lib ;-) commands directly

as you say, its a case by case issue, but in most of my larger projects, 
i end up using object for a variety of management reasons.

Yes, but there is a problem in your example above in that one is 
an apple and the other an orange.

An object does not represent sequence, it represents state. A DRAW 
block represents sequence. They can be as long as you need.

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  ;-)