World: r3wp

-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.

I'm not as much help in this as I'd like, since the current API is 
just fine for what I need to do - at least until we get device extensions. 
Maxim has been more help, since his needs aren't met by the current 
system. If you are writing a database API, your experience will likely 
help refine the model too.

R3 needs feedback about the kinds of problems that only arise from 
use. Without that feedback, design stalls.

I have been waiting for extensions for a decade, and its almost there.

a lot of stuff depends on the improvement of extensions and addition 
of device extensions.  not just for me but for Carl also.

Unfortunately I am not at liberty right now to tell what that is, 
but I can assure you extensions will have to improve in the short 
term because a new player (company) in the REBOL community needs 
this, already.


this company might become one of the levers to propel REBOL into 
adoption in (several) very large corporations (fortune 500) & scientific 
organisations around the world, so RT has vested interest into doing 
as much as it can to make this happen... and right now... the host 
code and extensions is the key to most of it.

The Vatican keeps popping up!

Don't be silly - everyone knows the Vatican uses LOLCODE :)

Using Roman numerals has always been a challenge for their coding.

It's that damn i word (for I I X ...)!

Rebolek, that is not really true - the function still takes a fixed 
number of argument, and you're just passing a unset! value to some 
of them (which is a side effect of R2 passing unset! at the end of 
the block, i think R3 does not even do that)

Gabriele, you're right that it's just a R2 side-effect and it's true 
that it does not work in R3. Not that I miss it.

Could someone write gzip compress and decompress functions for rebol3 
extensions? what the cost would be?

There's already zip for R2 ...

Check the rebol.org library

I thought about writing extension for zlib, but haven't started anything 
yet. But it should be easy I think.

you can always use the zlib code in putty.  its MIT licensed  :-).

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.

But I must say that I currently use my time on getting SQLite up 
& running for R3. So far works already very good.

Robert, if you are good at C macros and have a good idea about how 
to improve things, make suggestions. Good safe methods for bulk copying 
of string or binary data into the REBOL values to be returned, or 
from values passed in would be great. Look at the existing extension 
source for an idea about how the current macros work. Safety is a 
priority here, so don't forget the bounds checking.

Interesting comments in R3 Chat about Commands, Extensions, DELECT 
etc.

Ok, so I've not yet provided everything that you'll need to do it. 
I divided the
 extensions release into a few stages:

1. simple - 
just simple access to commands and args
2. series - access to series 
values of various types
3. objects - access to objects (of all types)
4. 
codecs - support for codecs
5. host-lib - ability to bundle extensions 
with the host-lib itself.

So, I need to get you a bit more... in 
fact along the lines that you mention.

Re #6156: Pekr, we ARE NOT giving up on dialects!! There are many 
dialects in RE
BOL, and it is one of the main concepts.

What we 
are doing is removing the strong overlap in DELECT and COMMAND. If 
you l
ook at the DELECT method, it is a small subset of full dialects. 
It implements a
 form of function with optional arguments.

So, it's 
better to move that code into COMMANDS, and allow them to work that 
way
. This makes it much easier for people to learn and use. Even 
me!

Also, REBOL/Services will use this same method, because COMMANDS 
are not limited
 to just extensions... ah the secret is out: COMMANDS 
can also be attached to a
context, making them generally useful in 
REBOL code.

I will check the blog comments to make sure it's not 
misunderstood.