World: r3wp

phew... I'd forgotten how much work it was to express this in C...

variable: new-def: make type? other-def none data

that is... when the other-def isnt' a trivial integer... but something 
like a definition of a callback function ...

Max - please share your needs with Carl in R3 Chat .... I mean - 
the need to move some stuff into Host ....

I will, don't worry... but I need to have some meat for him to chew 
on if I can get this callback thing working, then we can talk about 
something concrete, not just thin air.  :-)

I know what you mean, but the thing is, that Carl might be doing 
some design decisions right now. So it might be better to act before 
it is too late for the change ....

good point.  I was planning on getting his attention (by any & all 
means necessary ;-)  tomorrow

Maxim, you are taking the wrong approach. If you are having problems, 
don't work around them, fix them. Working around is the R2 way.

I could have something working for non multi-threaded stuff
 Not good enough. Tasks are going to be in R3. Prepare :)

Don't look at how the existing ports are implemented, look at the 
port model. You can create your own port types if you like.

They don't have to be network or file port types either :)

How do I put NONE into a block?

I guess, that it is like integer 0, except, that the datatype should 
be RXT_NONE

So it will be int64 in the union.

But this could than be interpreted as integer 0.

But I will try to do this and specify the datatype. We will see.

If the c-level side uses UTF-8 strings as well, can I just use the 
Rebol series as is? get_string returns a decoded string.

I got my SQLite R3 extension working. Really nice. Overall it takes 
about 10KB of C code.

very nice

:-)  and its probably really fast :-)

in my tests, extensions are quite performant.

I will do a stress-test with a triple engine I have for R2. We will 
see.

there is no reason for it being any faster than R2 version, no? Most 
of the work in DB area is done by DB engine anyway ... the rest is 
passing the arguments around ... or do you think extension interface 
is faster than R2 DLL interface?

In R2 the collection loop to build the result was done on the Rebol 
side. Now it's done on the C-side. This is a lot faster.

And, I directly build internal R3 block, this is directly used I 
think. So no copying, internal handling etc.

Performance test will show.

can I give a guess that the series building part of the request will 
be about 100 times faster now?

@ brian: I understand what you say about working around... but, with 
the host right now, I can't do anything else than hack up a solution 
in order for extensions to have callbacks.  99% of the real work 
is inside the extension.  when the host will be improved, the extension 
work won't change.  I can't wait for things to happen... this solution 
is just for my own use, and it gives me a good perspective on how 
to help with a real solution.  


I'm also brushing up on my C skills (I haven't done any in over a 
decade!) so doing this stuff is a good exercise anyways.


right now, if I can show to Carl how complicated it is to do some 
stuff, he will have an explicit example and have a better reference 
for practical solutions.  Doing anything... its all just theories. 
 look at the notes on delect and command... this is similar... lets 
start with something.  see where that leads us and then, we have 
a reference to pick on and critique.  


We can have better ideas for the api, just by having something bad 
to start with.... and believe me.. I know my hack sucks ... but I've 
got part of the solution complete, and compiling without warnings, 
and some code sharing between extensions api and the host.  :-)

Maxim, are you preparing a Glass extension ?

Maxim, you do realize that the purpose of the current host release 
is to test and improve the host model, right? Not to build final 
projects? If you run into problems in the host model, try to fix 
them, not work around them. Otherwise your work is a waste since 
the host interfacing model is going to change in the next version, 
hopefully based on your and my feedback. And a callback solution 
that doesn't integrate with R3's multitasking model is worse than 
having none at all - since any code that might be written to use 
it would need rewriting, and probably rearchitecting, very soon.

On the other hand, if you are really trying to test the model to 
destruction as an example to base the next version's revisions on, 
then cool. I would like to see how your code integrates with devices, 
even if it has to be moved out of an extension and into the host 
for now, at least until we get device extensions. Code that works 
with the model won't need as much rearchitecting.

I've checked the host code and afaict, you can add your own device 
types. You don't have to stick with just file, network and clipboard.

jocko,  yes and no.   ;-)  


Glass is going to be rebol code only, but its going to be based on 
rebogl, the OpenGL extension I am currently working on (as I write 
this).  Rebogl its going to be an evolutionary process, starting 
with simple high-level pre-defined primitives and colors and then 
will get more and more customisable (deformers, animation, textures, 
programmable shaders, etc).


I am still not sure how the Glass engine will evolve, but there is 
a good chance that it will be based on the scene graph technology 
I am working on for the Scream game engine.  This has the benefit 
that Glass can be used to build the interfaces within the games themselves. 
 But it most definitely won't require you to load a complete  (and 
inherently complex) 3d world manager, just to build a window with 
a form.  if possible, I'd like to have window masks, so that the 
3D forms can actually live like 3d models direclty on the desktop... 
so some of the nice 3d feature isn't wrapped within an OS window 
border.

That does sound cool :)

brian, yes we can add our own devices... in fact, it seems quite 
easy, and I will probably be adding a DB trigger device within a 
week or two.  :-)


the thing is that there aren't any exposed or documented *native* 
hooks from the host into the core... 


so far, I've got a callback library (called wire) working which executes 
rebol code in global context using the Reb_Do_String() r3lib.dll 
exported function  :-)


now I just need to use that library within the extension and see 
how it goes... the moment I have *something* which works... I'll 
stop improving the hack... from there on, I'll just work on the architecture 
of the caller and callee, to see how we could make it simple and 
easy to setup, from the extension and within the application using 
that extension... generically.


the code in between can change completely, it wouldn't actually change 
the extension or application code (that's the idea anyways)... just 
a few includes and headers which map how to link to the callback 
system.  I'll also try to build a device, just to see how that can 
be used instead of callbacks... but I still need to use a callback 
from the extension in order to access the host... so for now my hack 
is essential, whatever I do.


in this case, I'll be dispatching the GLUT events within the rebol 
using this architecture... I should have an interactive OpenGL window 
by tomorrow... crossing my fingers.


for now I am busy rebuilding my old OpenGL project within the new 
cleaned-up MSVS solution I've been working on for 2 days now... there 
are soooo many properties, its scary and long to setup... especially 
in this setup where there are several interdependent projects within 
the solution... but now, at least, when I change stuff at any layer 
and build, it builds all the stuff correctly in one step...

I have no idea how async triggers will be handled inside Rebol. Will 
these be added to the event-queue?

Perhaps RT could provide a service to build encapped exe.

Via a a simple web page where we could post a script then the service 
would return an executable (after the choose of a platform).

so, people would not be obliged to control the construction of extensions 
with this simple use case.

Max - so now you talk Glass, few week ago you talked Liquid. How 
are both related?

Guys - do you have any special comm channel with Carl? If not, then 
I feel some info might get lost here. E.g. Max expressing the need 
for Extensions being at least partially moved into Host. So my question 
is - does Carl know about your needs and opinions?

No I don't. there are zillions to choose from but I don't know which 
one is really good and leads to a result.

answer.

If no special AltME world is started for it, then R3 Chat is the 
answer. If I want to get Carl's attention, then magic command is: 
pu Carl - it will post private message to him ...

there is no secret channel AFAIK.  R3 chat is the best place to reach 
him.  he still doesn't reply in real-time... it depends if he's in 
the batcave or not.

liquid is a dependency engine, its like a kernel but managing individual 
operations (functions/procedures) instead of whole applications (processes/tasks). 
 Scream uses liquid to build data and make sure it stays up to date 
with whatever data it is based on.. if you change sphere radius... 
the 3d model representing that sphere will rebuild itself... no need 
to know how the sphere model itself works.  


If Glass is based on some of the technology within scream, which 
uses liquid, then things like dependencies between input data, their 
 forms, and the result of that input become impossible to break. 
 there is, as such, no action function as we had in VID.  the interconnections 
from data and process is what defines an application.

Pekr, Carl already said in a recent blog that the ability to have 
extensions built into the host is already planned, and he is working 
on it.

Which, among other things, what he is currently doing in the batcave 
:)

I successfully used the OpenGL extension with a host I compiled myself 
 :-)

I know have added callbacks to extensions using a little hack with 
an intermediary dll I built, loaded by the host and any extension 
that needs to run rebol code.   so its fun to know that in the end... 
we already have ways to tailor the executable to what we need even 
when it officially doesn't support what you need.  :-)


obviously we can't do everything, but this little test is already 
nice.  right now I execute code when the OpenGL window is resized....

I will be adding events for mouse clicks and keyboard presses, so 
I can start interacting with the 3D rendered stuff.

yes... R3 is a completely different ball game than R2    :-D

awsome!

I have started to use WORDs as types in my extension arguments, but 
The code doesn't seem to follow the implementation...


In the docs it says that the words I define will start at 1 2 3... 
but the word I defined, seems to give me 152 when I pass it via the 
command...   here is a simplified code example:

in rebol:
import %my-extension.r
my-extension-func 'ext-defined-word


in C
RXIEXT int RX_Call(int cmd, RXIFRM *frm) {
	u32 action = 0;
	action = RXA_WORD(frm, 1);

	printf("%d", action);
}

prints out:    152

anyone else test word! as parameters in R3 extensions?

the data passing seems to be right since inserting the following 
code in RX_Call( ) 		

action =  RXA_TYPE(frm, 1);
	printf("%d", action);

prints 16