World: r3wp

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.

yeah but unsigned could be a bit in the integer.  it would help for 
many things... MANY values can't be negative.  I would love to have 
an quantity! type. which is just like integer but without possibility 
for negation.

A handle is a 64bit value that can be treated in any way that the 
relevant native code wants it to be treated. It is returned by native 
functions or commands and is taken by native functions or commands.

ok.

when I said "a bit in the integer" I meant in the integer's internal 
datatype... but a quantity! type would be even better.

If you want user-defined datatypes, they're planned. Or you can just 
fake them using techniques similar to those in R2/Forward.

yeah... but quantity! should be a default type... its just such a 
basic part of programming.

returning an errror whenever math operations would make it negative.

Its a complicated thing to manage manually.  I know how negative 
values work... but its a REAL pain to work around it.

anyhow.  I wonder, can anyone tell me if its easy to load dll and 
map functions dynamically on LINUX?

(*.so)

Possible, yes. Easy, that's up to you to decide.

on windows its a simple function call,   does it require to have 
an extra package installed, or it part of the basic kernel?

There are simple APIs, though they might be different depending on 
which object format the distribution uses. ELF is common.

That's ok, its up to platform distros to accomodate.