AltME groups: search

Max - I like your idea of 1 callback dispatcher per one extension! 
It is just elegant enough to start with! It is the opposite of rxi 
principles (rxi_call), just on rebol side ... I will try to support 
it with Carl ...

and then you can call the commands inside the dll using rebol values 
natively.  its the plugin in C which does the mapping... look at 
the docs, you'll see that its quite easy to setup.

I think not yet. All it is about is to be able to call DLL functions 
from C level. There should be some examples around the web. Once 
you work-it-out, connecting it to the REBOL side should not be so 
much problematic ...

thanks, will look it to it too... although I have anidea for the 
ogre...  using "." for the member separations  :-)

ex: Ogre.FreeImageCodec.startup


all the extension has to do is wrap the call to its proper class 
path.   I would also have to build a struct/class lookup mechanism 
(which is the hard part)

yep, programmatically binding the engine is what I plan to do... 
especially since it will allows us to rebuild the binding at any 
moment just by flicking a switch and update it without any user-intervention.

so far, my options are:

 -a direct wrapper generator coded in REBOL using C++ sources, with 
 an advanced  C++ declaration to R3 Extension converter, 
	-I try out SWIG build an R3 extension output module for it, 

 -I use another language binding as the one to base mine with, and 
 make a specific tool to convert it to an R3 extension.

 -do a manual (and painfull) convertion, using a few generic scene 
 interaction commands.


One thing I'd like, is to add some way for the OGRE extension to 
be able to call REBOL code directly via callbacks, using their Extensive 
hooks throughout the api.


Although this will be slower than if the callbacks where in C, obviously, 
some parts of REBOL are swift enough (like series management) that 
they just might make the cut for REAL time rendering hooks.  Well 
implemented, they would be fast enough for common GUI interaction 
events for sure.

Ass soon as I know how to call a Rebol function from Extension with 
some simple parameters I'm ready to start.

Host code will allow what? Callbacks? You want to tell me, that in 
order to call-back some rebol funciton, it has to be in host part?

so, Robert, not sure if you understood all of these replies as even 
I had a bit of a tough time to "get" them.


Right now, Extensions only allow REBOL to call functions from a dll. 
  What I would like is to simply improve the extension model so  
it can also call REBOL code, as a callback or something else, but 
there are a few issues which make this a non-trivial thing to do.


So far there seems to be a generalized idea that there should be 
a different kind of extension which allows this, but I see no reason 
why it should be another, different. api.  having one DLL   for  
REBOL -> DLL  and another for  DLL -> REBOL  makes absolutely no 
sense to me.   IMHO we need a single DLL able to do both.  Even if 
it means a little bit more work to design it.

A command! is an indexed dispatch function, and the index has no 
inherent meaning. You could dynamically generate functions with libtcc, 
which would all have the same function signiature because they would 
just take command! call frames. These generated functions could be 
referenced from an array of function pointers. After you generate 
a new function and assign it to a new array slot, return the index 
of that slot to the calling REBOL code (embedded in the libtcc extension) 
and it can then make a command! with the libtcc extension's handle 
and that index. Then that command! can be called like any other REBOL 
function.


A trick though is that the generated C code would need to use the 
extension macros to manipulate the function arguments, rather than 
direct variable access. In other words, your generated functions 
would be extension-style code, not regular C code.

Bolek, if you have the commands that are exported from the libtcc 
extension themselves implemented as functions with the same signiature 
as the generated functions, you can call them through the dispatch 
array as well. This would reduce your RX_Call function to just a 
few lines.

well in fact I have not found any mechanism to call a function with 
a changing number of arguments, like, for instance: 
my-func a b
my-func a b c
or, 
my-func a b
my-func/my-refinement a b c

Doing a R3 extension for this would be a no-brainer if the gzip code 
is simple to call. Getting the data to/from Rebol is easy.

It's the dispatch. Right now with extensions, when you make a command! 
it makes a function that is dispatched by a function in the extension 
based on a number (which you can think of ay a key), to code that 
handles the command (the value associated with the key). In theory 
this is not that different from an object! grabbing data from one 
of its slots based on the keyword you pass it. Apparently commands 
will be able to dispatch to objects soon, and the functions assigned 
to slots of that object will handle the command code.


The DELECT dialect model was based on rebcode, mostly on its JIT 
binding. DELECT added the out-of-order, possibly optional argument 
handling to the dialect decoding phase, but the dispatch phase was 
mostly left out (I commented on this at the time). The command! type 
has the dispatch model, but uses the function call model for calling 
the commands. The overlap that Carl mentions is in the mapping of 
keys to command handlers.


If you unify the command mapping models between DELECT and command!, 
then that code can be shared. This means that the DELECT function 
could do the out-of-order dialect decoding, then dispatch the operations 
as commands. Values of the command! type would continue to be called 
like regular functions in DO code or by APPLY, and then dispatch 
using the same dispatch code as above. On the other end, commands 
would either dispatch to objects (including modules perhaps) or extensions.


By the sound of it, this might also allow the command! type to serve 
as a method pointer, but we'll have to wait to see about that :)

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

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

Max: "on windows its a simple function call" Could you tell us which 
one? I don't remember seeing such thing in win32...but I didn't looked 
at it since a long time.

/Library is tricky to implement, it requires constructing a C function 
call dynamically (using so-called trampoline functions) unrolling 
arguments in right format and order on the stack, then calling the 
C function, then retrieving result from stack.

so I've been looking into this a litle bit, and it seems like a portion 
of the /library extension might be a pain to implement... so far 
it seems like I will have to add in-line assembly, since I haven't 
found any C routines or macros which handle the puch/call/pop aspect 
of the program stack (not saying it doesn't exist, just that I haven't 
found any).

tom, yes.    that will start out simple, but will be handled in the 
rebol & extension part of the code.  


once I have the actuall subroutine jump (ASM call) code in place 
with an unlimited number of run-time functions registering, we'll 
see how the community wants to evolve the struct! dialect.


I am thinking of a rebol to struct converter and a way to keep handles 
to those structs, and even use them within sub structs, so that we 
can easily reuse allocated structures without doing the convertion 
over and over.

so you can work like draw, keeping just the rebol version and convert 
it at every call, or manually convert it once, and then reuse it 
over and over.  

this will allow us to chose between ease of use or raw speed (with 
a bit more management in our code).

internally, it won't make a difference.  depending on how you call 
the library function, it will convert on the fly or reuse the handle.

Max, I don't know what you do but the overall concept would be:
1. Loading the DLL dynamically

2. Finding all requested functions dynamically (Windows has a call 
for this where you provide a string of the function name (just can't 
remember the call name)).

3. Implementing a generic R3 extension function that will be marshalled 
on Rebol site so that the first parameter will the function name 
and than all paraemters (I would use a block here).
4. Rearrange all this to call the Win32 function.

Robert,  even if you know the function arguments, how do you call 
the function itself?


the extension will be compiled, so we can't create generic function 
calls.   The calling convention is part of a function's compilation 
process, on Windows any DLL may have three different argument passing 
methods simultaneously!!


get the problem is that you have to push arguments on the stack and 
retrieve them.  there are NO C functions which manipulate the stack 
directly.  these are always done via assembly, either inline or libraries.

So, decision made: Serializing BLOCK within in Extensions is a PITA. 
As long as you want to walk a BLOCK and don't have to deal that much 
with nested BLOCKs it's OK.


But it's not possible to make a to-string block! within an extension 
with a simpe to-string call.


Overall I think we need a way to serialize Rebol datatype into a 
char* or void* in a way that it can be stored and brought back into 
Rebol.

a little question... how will the gui be able to call rebol functions?

continuing Request for object lookup within host/extensions here....



Here is a proposal (using example C code) for OBJECT access within 
extensions  this uses the EXACT same API as commands, and with just 
a little bit of work on the extensions API by Carl and a single hook 
within the r3core, we could allow callbacks within objects.


the advantage is that we re-use the same safe sand box as commands, 
and don't require to do much coding to enable it, AFAICT.


since object lookup is performed on demand, we can very rapidly supply 
an object to the command, and it doesn't cause any heavy-handed conversion 
at each command call if the object isn't needed.  more fine-grained 
control could be added so we don't need to frame the whole object, 
but it would be usefull as-is already.

RXIEXT int RX_Call(int cmd, RXIFRM *frm) {
	i64 i;
	
	// objects are frames, exactly like command arguments.
	RXIFRM *obj;
	

 // return values are also frames (with one argument), for type-checking 
 purposes.
	RXIFRM *rval;
	
	if (cmd == 1) {
		// ask the core for a frame which represents object.
		// attributes are returned in order they appear in object
		//

  // the command frame doesn't include the object frame, only a handle 
  to the

  // object which the core can understand. we then ask for the object 
  frame on-demand.
		obj = RXA_OBJ(frm, 1);
		
		switch (RXA_TYPE(obj, 1)) {
			case RXT_INTEGER:
	            i = RXA_INT64(obj, 1);
				break;
			
			// we could build a frame for supplying arguments to the eval
			case RXT_FUNCTION:
				rval = RXA_EVAL(obj, 1);
				if (RXA_TYPE(rval, 1) == RXT_INTEGER){
	            	i = RXA_INT64(rval, 1);
				} else {
					// return error
				}
				break;
			
			// wrong type
			default:
				// return error
				break;
		}
		
		// do something with the value
		my-native-function(i);

	}
}

so what do you guys think?

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

I admit that I am one of the rare REBOLers to write what we can call 
"large" applications.

Looks like it should be possible to call Java libraries from a C 
extension using the Java native interface ...

Except there's no way to call or declare commands with argc, argv 
style of arguments in REBOL.

Call to Community to help us get the next host-kit released:

one fun thing is that we do not have to use the C source types as 
the interfaces for the commands.

my next test is to build a generic object to parameter map.

so, if you have a C func declared as:
int myFunc (int a, int b)

you'll be able to call it from rebol using:

obj: context [a: 1 b: 2]
myFunc obj

Is there no way for an extension to call a R3 function?

Seems like I should be able to call Qt's sql or network functions

If I bring up a GUI in Qt or something .. I'll need a way to call 
rebol from the GUI as otherwise I have no way of communicating except 
on exiting the GUi

don't know if this has been discussed wrt callbacks, but it would 
be good to be able to call back into REBOL for purposes of controlling 
execution, say for debugging from a non REBOL editor/IDE

But we can't do that at present ... start a thread to call our extension

the way I see it, when a thread is launched, it should Copy the whole 
environment and become completely independent.  data exchange between 
tasks is done explicitely, and no GC allocated data should be able 
to cross thread boundaries.  obviously using external libs you may 
have some fun, but then its OS allocated and not managed by the core, 
so its your call.

utility functions like  synchronise would be nice. but they would 
be something you call manually.   I find its always better when the 
code actually implements the paradigm, rather than trying to hide 
it.   a bit like Apple's GDC.  you explicitely create little tasks 
which you launch and wait for completion.  its simple, obvious and 
highly scalable.

and since we can specify as many alternate command formats as we 
want per C function, we can build a library of parameter-less rebol 
commands which call the C functions with usefull values built-in 
to the extension.

Note that while my sample.c it may _look_ just like the example given 
in http://www.rebol.com/r3/docs/concepts/extensions-making.html#section-2, 
it differs in that `RX_Call` takes three arguments instead of two.

http://www.rebol.com/r3/docs/concepts/extensions-making.html#section-17
says it's out of date and I'm really having trouble including words 
as symbols in a result block of an extension command. 

It works fine with an *INIT_BLOCK defined as


 const char *init_block = "REBOL [\nTitle: {Power Management}\nName: 
 power\nType: extension\nExports: [power-status]\n]\n"

     "lib-boot:           does [map-words words] ;-- Is that a good idea?\n"

     "words:             [ac-line battery remains of high low critical 
     charging]\n"
	    "map-words:    command [words [block!]]\n"
	    "power-status: command []\n"
;

if after IMPORT %power.dll I call SYSTEM/MODULES/POWER/LIB-BOOT.


Is there a way to have IMPORT automatically execute the LIB-BOOT 
code with a simple extension not included into the host code with 
host-kit?

I'm trying to return a block containg a word not taken from a commands 
arguments. Say, I want to return a block like [BATTERY CHARGING]: 

That works with

	u32 *word_ids = 0; // used to hold word identifiers
	enum power_words {W_POWER_BATTERY = 1, W_POWER_CHARGING};

	RXIEXT int RX_Call(int cmd, RXIFRM *frm, void *data) {
		/* .... */

		v.int32a = word_ids[W_POWER_BATTERY];
		RXI_SET_VALUE(s, pos++, v, RXT_WORD); 
		v.int32a = word_ids[W_POWER_CHARGING];
		RXI_SET_VALUE(s, pos++, v, RXT_WORD);
	
		/* .... */
   	}


only after importing the DLL I "manually" init the words with a MAP-WORDS 
command. I was thinking that IMPORT eventually triggers LIB-BOOT 
init-code from the INIT_BLOCK. It seems like the init code is not 
executed.

Ok, you need to make a call to your lob-boot function out of this 
init function.

Hmm, I think I've to check this again. At least, a simple 

    RXIEXT int RX_Call(int cmd, RXIFRM *frm, void *data) {
        return RXR_VALUE
    }
    
returns a proper date value for

    test-date: command [date [date!]]
    
I'll see if I can find some time to work on this evening.

all RL_* functions are safe to call from extensions

btw.. what is difference between simple CALL with args and using 
the ImageMagickObject?

but with error:

wand.c:81: error: incompatible type for argument 3 of indirect function 
call

That's not working, the function I'm trying to call is:

char **MagickQueryConfigureOptions(const char *pattern, unsigned 
long *number_options)
And I would like to use REBOL input for the *pattern.

Actually it's:

../src/include/reb-lib.h:270:49: warning: __VA_ARGS__ can only appear 
in the expansion of a C99 variadic macro

wand.c:74:43: macro "RL_PRINT" passed 3 arguments, but takes just 
2
wand.c: In function `RX_Call':

wand.c:74: error: `RL_PRINT' undeclared (first use in this function)

We want to be able to automaticall store all this run-time state 
information with one call.

the invention of zero was a considerable breakthrough, taking into 
account, that even nowadays there are people hesitating to call zero 
"a number"

Within the VIEW part the resizing is a simple call:

As I see it, your goal is actually different: you would like to have 
a VID-replacement dialect compatible with VID in properties you call 
"non layout specific". Yes, that is possible too, of course.

maxim yeah but push is not optimal  in rebol 2 bloacks you think 
only the pushed is drawn but the show call force the redrawing of 
all killing perfs

ie. the dll needs to be able to call into the host kit code, and 
you can't solve that with callback!

I wanted it for dialogs, and correctly, it's just another option, 
since CLOSE offers the ability to set a value (logic!, block!, word!) 
in the window face, as the window is closed. The SUBMIT reactor allows 
a call-back.

call it jigsaw :)

Although I've implement 5 complete GUI frameworks, so far I've stayed 
relatively silent on the R3 GUI front cause I'm building my own framework 
and I don't want to interfere with the R3 system.


but I will pitch in here and say that what Henrik proposes is a good 
idea (I use the same name for a relatively similar feature), though 
it needs one thing if it is to be usable by newbies.


a way for do-face NOT to call attach.  the reason is that if you 
want several cooperating controls, they must not create feedback.

BOOPSI used an intermediate structure which acted as a controler 
to which you connect everything that has dependencies. then you call 
do on IT.

we needed to know the size of the letters displayed on screen because 
first of all in R2 when you call 2 times a text instruction the rendering 
at piled up at same place and not disposed one after another on the 
X axis with natural spacing... so draw [ text 10X10 "a" text "b"] 
renders a "b" over the "A" and not "A" followed by "B". And it's 
logical ... text instruct was then designed to handle a serie a letter 
or several series of letter organised in distinct block we can call 
words... but you see that concept doesn't fit with the need of having 
an interaction anytime with any letter componing the words.

and in the richtext proposition of Carl made 2 years ago (times flyes..) 
we find again this block concept wich is related to the way MakeDoc 
format handle things ...  like in HTML  for example you have flags 
that defines a rendering style. But the things betwin the flags can't 
evolve... they are not supposed to change font style or font size 
or font color. See that's what i would call a we treat text as block 
and not as single element able to singularly evolve on their own 
without affecting the surrounding elements.

Get rid of the call to LAYOUT, and it will create and show a layout 
with a button titled "test Brian". When that button is clicked, the 
button's action will be triggered, and the result of NOW will be 
printed to the console.

Actually there are several changes by Bolek and Cyphre, that I've 
not yet studied, but much of the work that was handled by LAYOUT 
before is now relegated to PANEL and GROUP, which is why we talk 
so much about them and not a central LAYOUT function. They call various 
subfunctions that specifically focus on creating faces and laying 
them out and resizing them.


So the styles themselves are capable of custom layouts and resizing 
mechanisms and also mechanisms such as face init and triggers. So 
that means you are no longer a "slave" of the LAYOUT function.

That's also why:


1. I was talking a while ago about that you can build a style that 
emulates VID, complete with a dialect, or replace the layout mechanism 
with your own, by rewriting PANEL or GROUP or adding new panel styles.

2. That whenever you want to do a new thing, you should make it as 
a style. That's where you start.

There is no confusion, sooner or later we do reach the matrix's "there 
is no spoon" = there is no R2 - old, forgotten, boring. Do you call 
Delphi 6 not a Delphi, because you can't run the code in Delphi 2 
anymore? Does Perl 6 rename, even if different to the old generation? 
VID is a good name. Simply put version 3.x is not compatible with 
version 2.x, easy as that ... I can't see any confusion, if we talk 
about VID in R3 related channels ...

I call it R3GUI to not confuse it with old VID, but I don't know 
if it's final name (not that I care right now).

I liked VIVID too. The most important thing is to not call it VID 
though.

call/wait is something we will need.

call/wait .... kissing your hands! :-) That is an integration problem 
with R3, thanks for that ....

currently validation is triggered on window open to init state. then 
you can call it on the window as needed and it runs also as a reactor, 
hence every time a field is unfocused or a button is pressed. it 
also is triggered on window close, given the button that closes the 
window is a dialog button.

btw - back to my DOS app generator (Clipper + Zachary) :-) There 
was one other interesting feature. Let's say you have an invoice. 
And you have field to enter a company. That field is validated against 
customers table. There was a validation option named 'must-exist, 
may-not-exist. That way user could either enter new value, or only 
choose from existing values. But - the customer table was not probably 
a good example. 


And then - each grid/table had options too, called AED (Add, Edit, 
Delete), plus option, if you allow ADD option caused by validation. 
Example - you enter customer name - it is not found in customer table. 
If you allow 'Add option for grid, when user entered new customer 
name, and not found, it automatically popped-up a form, to enter 
new customer. If 'Add option was not allowed, then the person had 
to call someone, who had rights to enter the data directly into Customer 
table ... well, probably confusing description :-)

no one answered my call for more versions in curecode

another question.  if I have a region of ram which contains rgba 
pixel data as an array.    what is the function I need to call within 
the compositor::cp_process_gobs() func so that I can copy that array 
within a gob's pixel buffer?


I've been running around the source and its a bit complicated... 
there are so little comments in the agg code... I'm not sure what 
does what.


I was thinking that the clue lies somewhere in the undefined code 
within 
case GOBT_IMAGE:

hum... using stylize doesn't seem to add to the global style sheet... 
is there a function to call first to setup or assign to a specific 
stylesheet?

such as to replicate stylize/master   in R2..

I like r3.exe name ... maybe new marketing name for rebol could be 
simply - r3 - we all call it like that anyway :-)

That's not bloat of code, but bloat of functionality I tam talking 
about. My experience is as follows - sometimes I like to use frameworks, 
but I don't like using frameworks just for the sake of frameworks 
themselves. Young guys did new SW for our old kiosks we installed 
around, and it seems so complicated (all xamp, web, replicated mysql), 
that they had to call their guru to set-it up.

Pekr, I understand what you say, but I would call it "going the long 
way around".

well, I would call it expected behavior. you have a known model you 
can simulate in your head.

Bolek +1 - Don't use GRID for these names, unless we call it a canonical-grid. 


Christian, I thought of across/below as well, but understand Cyphre's 
reasoning.

Panel 1

 or "group 2" give little meaning to the numbers. H and V prefixes 
 make things clear, but...


groups flow faces by their individual size, like Google Images, while 
panels use a grid of cells.
 


What are the use cases for each style? Is it accurate to say that 
PANEL is for cases where you want things neatly aligned, and GROUP 
is for cases where alignment isn't important, and tighter positioning 
based on face size is desired?

having written  a few, I recommend making it an external api which 
is fully "gui enabled"   this way, undo events can automatically 
call face accessors,  and you can put the undo stuff in the logic 
rather than the gui.   many times, the logic might generate a few 
undo, or none, based on things which the gui can't properly be aware.

yep... what I call actions above.

Rebolek, architecturally, it may be a good idea to provide such thumbnails 
as part of the help system, when it comes along. The help system 
is what will allow us to use layouts and gobs as tool-tips for any 
face, so hopefully it will be possible to call up an image in 1-2 
lines of code.

and they dare to call it a platform? Without a free GUI?

I also see as a priority to fix the status of gui :

- declare publicly if r3-gui is the official gui development or not
- then fix the load-gui call function
- and finally update the gui official documentation page.

It should not be too difficult, and, to my opinion, it it really 
important and urgent, because it prevents to develop experimental 
visual applications.

Could the gui development team meet Carl in order to convince him 
to take a decision ?

having consistent naming conventions across the board is imo always 
a tough call. Naturally I can understand, why you have selected short 
"faces", and adding question mark ...

It would be hard to do a code injection with this code, since SAME? 
takes two arguments so you can't easily inject with a function that 
takes an argument, without causing an error in the call to SAME?. 
The only other way to inject code would need debug permissions. So 
it's not a big deal here.

this looks to me like a lot of call to the win32 API  OLDES  !!!!

hum.. this seems like an annoying limitation (in the least it must 
bewell documented)....  I'll see if there's another place I can call 
the RL_extend() on my embeded extension so it has access to mezz 
code.

sorry, phone call...

And automated tests. The kids call it "continuous integration" these 
days.

And whatever you want to call it, the process is simple: you have 
a single code base, version controlled. Upon every change to this 
code base, you automatically build and test on all supported platforms.

What we want eventually is for host-kit to detect ESC, and call RL_Escape 
for that too.  But, that requires that we use raw stdio processing 
(or use an OS that's good enough to detect and signal us on a specific 
key press), so it's not implemented yet.

I just implemented CTRL-C checking in OS event handler and I call 
RL_Escape() when it is detected. Seems to work fine now.


On Amiga, all signals must be explicitly checked for. This is both 
good and bad of course. The control is nice but the code duplication 
for things like CTRL-C is not.

Yup. Or in scripts, you can call it self.

Too good a feature to call it a workaround.

At least I couldn't figure out how to call R3 so that it respects 
the boot-level flag.

Call the exports r3-<datestamp>-<revision>.zip.

Carl's call, I guess.

I would prefer r3-hostkit and call the thing "hostkit".