r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3 Extensions] REBOL 3 Extensions discussions

Maxim
16-Jul-2010
[981x3]
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.
Carl
16-Jul-2010
[984x5]
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. ;)
Maxim
16-Jul-2010
[989x3]
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.
Carl
16-Jul-2010
[992x3]
Only at the edges.
And, mainly at the human edge.
At the core, a CPU executes a sequence of instructions, not an object.
Maxim
16-Jul-2010
[995x2]
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.
Steeve
16-Jul-2010
[997]
As far I know, Maxim don't use the nested gobs approach but reconstruct 
nested draw blocks instead.
Maxim
16-Jul-2010
[998x3]
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
Steeve
16-Jul-2010
[1001]
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.
Maxim
16-Jul-2010
[1002x2]
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 .
Steeve
16-Jul-2010
[1004]
maybe you could simply convert your object into gobs ;-)
Maxim
16-Jul-2010
[1005]
liquid is at a lower level than gobs (its not strictly gfx related) 
and I need object access for liquid (and other things).
Steeve
16-Jul-2010
[1006]
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.
Carl
16-Jul-2010
[1007x2]
Yes, true and useful too.
I need to find a group to discuss the PAIR changes happening. Suggestions 
anyone?
Maxim
16-Jul-2010
[1009]
Core?
Steeve
16-Jul-2010
[1010]
no !REBOL3
Carl
16-Jul-2010
[1011]
I guess. Kind of general group tho. Was hoping we had a graphics 
or datatypes group.
Maxim
16-Jul-2010
[1012]
there's REBOL3 GUI
Graham
16-Jul-2010
[1013x2]
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 ...
AdrianS
17-Jul-2010
[1015]
would be easier to use something like SWIG

http://www.swig.org/
Graham
17-Jul-2010
[1016]
Got an example of use with R3 extensions?
BrianH
17-Jul-2010
[1017]
SWIG has REBOL support now? R2 or R3?
Graham
17-Jul-2010
[1018]
sure .. just use -r in the options :)
BrianH
17-Jul-2010
[1019]
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 :)
Graham
17-Jul-2010
[1020]
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
Steeve
17-Jul-2010
[1021]
Ok, we can sign the 1 billion contract now
BrianH
17-Jul-2010
[1022]
Has every group become the Humor group now? My grandma would say 
we are getting punchy :)
Graham
17-Jul-2010
[1023x2]
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
Carl
17-Jul-2010
[1025]
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.
jocko
17-Jul-2010
[1026]
Graham, did not visual studio 2010 convert properly the visual 2008 
project file to visual studio 2010 ?
Graham
17-Jul-2010
[1027x3]
I had to do this http://jira.rebolsource.net:8080/browse/REBOLKIT-6
Maybe one would have fewer issues with using profession visual studio 
2010
@Carl, the chicken came first!  So, just give us the A101 download 
link
BrianH
17-Jul-2010
[1030]
It's not done yet.