World: r3wp

Pekr, the reason callbacks are so tricky in R3 is that you need a 
way to dispatch to the correct task within REBOL. R3 is not going 
to be single-tasking anymore, so direct callbacks will be impossible: 
You have to coordinate between the task/thread of the external code 
and the tasks/threads of R3. Devices manage that coordination and 
synchronization.

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.

Be sure to BSD the extension wraapper code though, so it can be reused 
by an LLVM wrapper :)

If you mean BSD-license, that's understood. I prefer PD/MIT/BSD licenses, 
GPL is stupid.

(I prefer no licenses at all, but I'm an anarchist)

Well, libtcc is LGPL (2, I think), as is libjit, but LLVM is BSD. 
The extension interface is LGPL compatible, so if you BSD the wrapper 
code (or more permissive, as long as it's LGPL compatible) then you 
should be fine.

I prefer more permissive licenses too :)

especially PD

I'm fine with PD - code is just organized characters. Milion monkeys 
with typewriters can do same thing ;) so why licensing anything. 
But that's offtopic - the license will not be deffinitely more restrictive 
than BSD and it may be PD as well. Depends on my mood when I add 
it to header ;)

libtcc is LGPL 2.1

Playing with the extension example: IMO it's done  to complicated.


- Why do I need make-ext.r? Do I always need it or just for this 
specific example?

- Why is the init block a const char array and not just a plain ASCII 
text?

How do I return a new string back to Rebol?

I seems I need to construct a RX string and set every single char?

This uniton gives a warning/error with mingw:

typedef union rxi_arg_val {

	i64 int64;

	double dec64;

	REBYTE bytes[8];

	struct {

		i32 int32a;

		i32 int32b;

	};
	struct {

		u32 index;

		void *series;

	};
	void *handle;

} RXIARG;

The structs give: warning: declaration does not declare anything

yes, Robert, the other elements clearly declare something, but the 
structs don't declare anything, the compiler is right

generally, struct {...} my-struct; declares my-struct, while struct 
{...}; does not declare anything

(should have been my_struct)

I commented the struct part and than it works. So either we need 
to give it a name, which will result in a ->struct_name.series sequence. 
Not sure if this makes any difference instead of just putting the 
members into the union.

yes, it makes a difference

(since it is a union)

-only one of the variants is correct

Ok, right. Using int32 and ser as struct names.

Works.

BTW: I'm currently making a R3 SQLite extension.

Looks like one need to be carful when designing the command interface 
(arguments) because if you insert an argument, the refinements shift 
to a new position. As the access to arguments on the c side is via 
positions you need to adjust your code. Need to think abou a good 
way to abstract this.

is there a document showing how to define refinements in extensions 
?

What do you mean with "define"? On the Rebol side or on the C side?

Anyhow, yes refinements are no problem.

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

use a block of arguments ?

Yes, of course it is a solution, but not a clean on in my case

in fact, you cannot know, from inside the C part of the code, the 
real number of arguments send to the function.

RXA_COUNT returns the number of arguments defined by the prototype 
of the function, not the actual one

Jocko... you know... it has never been possible in REBOL to define 
functions with a variable number of arguments...

it is possible, but usefull only in console

that is why I was thinking of refinements

The method of calling with refinements is currently awkward. That 
is one of the problems that is intended to be addressed in the near 
future in further revisions of the extensions api.

thanks, ... I hope that another (awkward) item will be callbacks.

It works but it's only done via position, so you don't get the name 
of the refinement. This rule is an unnecessary dependency from Rebol 
code to C code.

Ok, I understand ...

Same as APPLY, actually. Fortunately the C implementation and the 
REBOL declaration are bundled together, so you tend to be the one 
setting the positions in the first place. This makes the whole process 
easier.

Ok, I see

However, don't expect such awkwardness to continue for much longer. 
This is just version 11 :)

11 -> 1 (stupid keyboard)

May be, but that's what's available at the moment.

Is there anyway to do a callback? Or trigger R3 to do something? 
At the moment I use a localhost port for this.

Not at the moment. That is as good a method as any for now. Maxim 
has beeen doing some research on this, and the device model is supposed 
to solve this problem in the long run.

Some parts of R3 are more alpha than others - the extension model 
is one of these.

That's bad because it's IMO an enabler and promoter for R3. As long 
as the GUI is missing, at least R3 can be used on the server with 
extensions.

The API is versioned for exactly this reason. Carl came up with enough 
of an extensions API to actually function and to let people experiment 
with various techniques to make it better. Carl is not the only designer 
of R3 - we all help, and need to. We can't know how to design the 
extensions API until we get an idea of how it will need to be used.