World: r3wp

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

which is the proper result for an argument of type word...  :-( this 
is mighty strange.

yay!  real event model in place and functional for the OpenGL extension... 
its not a permanent solution but it will do for now.f


now the tedious job of creating stubs for a few hundred functions 
begins!


and hopefully by next week the first applications to show this off 
will be demoable  :-)


currently, including callbacks which create an object at each refresh, 
I can't  resize the window faster than the engine can redraw it (up 
to 1440x900, in 32 bit color, with a few shaded polygons ) , and 
this includes hundreds of lines of rebol being printed in the DOS 
shell.

Go Maxim go !

He may respond better to "Allez, Maxim, Allez!!"

de course ! bien sûr ! C'est un cousin de la "Belle province", n'est-ce 
pas ?

:-)

eh oui  :-)

R3 SQlite update: I added SQL statement caching so that these are 
re-used if once seen, which speeds up things a lot. And driver supports 
multiple database connections as well now.

because of web site availability problems, i have changed my site 
: you will find here the three  "experimental" extensions that I 
have done to learn the extension mechanism : a text to speech extension, 
a matlab engine extension, a simple windows api extension with some 
useful calls : http://www.colineau.fr/rebol/R3_extensions.html

cool ...

Great  ! Jocko

In theory it would by possible to make an extension that could implement 
the /Library dialect, or a better version of it.

I'm just saying that salaried workers may have different requirements 
than those working by themselves

I would like to point out, that wiki somewhere contains Ladislav's 
input on that ... I will try to find it ....

The trick is that the struct! and routine! types would only exist 
within the dialect - they would be handle! and command! outside of 
it.

I still don't get the point of !handle.  its useless within R3 no? 
 otherwise any integer can be used for !handle... no?

We wouldn't be able to create a proper struct! type until we have 
user-defined datatypes.

or is !handle, secretely, an UNsigned integer?  ;-)

http://www.rebol.net/wiki/DLL_Interface

The point of handle! is to store a value that REBOL can't really 
do anything with without native code. So it's a great place to put 
pointers.

is it protected in any way?

And handles, for that matter.

Yes, it's protected. From REBOL code you can't do *anything* with 
a handle aside from modifying operations. It's an immediate type 
so it's not modifiable in any way.

defining a struct dialect is actually quite easy, as long as we stay 
close to the basic types.


the only real issue, still, is the incapacity to have UNsigned values 
in REBOL which is annoying in many cases.

aside from modifying operations -> aside from assigning it to something

so I can assign a handle to an integer?  and the extension with get 
a  64int *myhandle ?

In native code, yes. Not in REBOL code.

We don't have unsigned *operations* in REBOL. We can have unsigned 
*values* in REBOL by making our own operations that treat the signed 
values of the same size that we do have as if they were unsigned.