World: r3wp

Passing around heap-allocated structs should work right now.

Ah, struct!, sorry, I misread.

..because I somehow miss what is struct useful for in R3 without 
routines.

I think struct! is just a datatype for future use. Not used at the 
moment.

yes, struct! is 'reserved' for now. It may be even removed later.

What if I expect float on the C side, but still want to allow to 
use integer from REBOL (using number!).. what's the best way to do 
it?

Maybe a wrapper interface function in the init block?

That's possible, but I was more thinking how to do it on the C side 
and not end with wrapper for each extension command.

Yeah, more elegant, but more work

How about defining the command with `command [arg [integer! decimal!]]` 
and then detecting in C when you where passed an int and converting 
it to a float?

Yes.. but how? Remember, I'm still C newbie:)

and the command can be just  [number!]

Then you'll have to handle percent! as well :)

oh.. right.. but that could be fine in some cases.. like volume.

also decimal! and percent! are both as RXA_DEC64

In the extension examples in the docs are examples of detecting multiple 
types

I guess I can use RXA_TYPE(f,n) to get the value type, but hot to 
convert the integer to decimal?

I don't think it's very easy to get at the REBOL conversion functions

float value = (float)RXA_DEC64(frm, 1);
if (RXA_TYPE(frm, 1) == RXT_INTEGER)
  value = (float)RXA_INT64(frm, 1);
}

thanks, that looks good

In fact, this is not really necessary, as both integer and decimal 
values are stored in a union anyway. But if you want to rely on as 
little implementation internals as possible, that's probably the 
way to go.

And your compile will quite possibly optimise the redundancy away 
for you behind your back :)

compiler*

I was trying to do just  (float)RXA_DEC64(frm, 1) with integer value 
and it was not working.

Do you think it's better to export all commands in flat structure 
like:
	export System_GetNumDrivers: command[]
	export System_GetDriverInfo: command[id [integer!]]
	...
Or rather close them to contexts like:
	export system: context [
		GetNumDrivers: command[]
		GetDriverInfo: command[id [integer!]]
		...
	]

Depends on the purpose of the module

It depends on the situation, and how the commands are supposed to 
be used. In that case above, don't export 'system.

I think that was just an example :-)

Direct word access is faster than path access, but some words are 
logically grouped (like enums).

You mean the name?

Yes :)

At this moment I have a flat structure, but problem is, that there 
is so much exported commands that I tender to froup them... I know 
it's slower, but how many times one need to know driver name like 
in the commands used in the example above?

For instance, in the AGG wrapper the commands that are used to implement 
the Draw dialect are exported in their own context rathar than globally, 
because they aren't meant to be called directly as functions. Other 
APIs may need to do the same thing for similar reasons.

In a lot of cases you want to make commands at the marshaling boundary, 
and make REBOL wrapper code that you export. REBOL code can encapsuate 
a lot of functionality, whether you are doing so in an object type, 
a scheme or a dialect.

Back to the name..  what if I export System extension context into 
main context, where is already System defined? Now it looks it just 
silently do not overwrites the existing one.. shouldn't it throw 
an error?

If you are just exporting the native API then make the extension's 
module private rather than public, and just import the extension 
into the module that provides a simple REBOL-like public API for 
others to use.

The current build doesn't have most of the security protections implemented. 
We want to fix the *many* protection bugs first.

So do you want me to add CC ticket?

There already is one.

For that matter there is a message warning about this problem at 
startup of 109 and 110.

ok.. fine... so do you think I can safely use 'system' like exported 
names and believe, that if someone want's to use the extension, he 
will imported like:
	fmod: import %ext-fmod.dll
to avoid conflicts and not:
	import %ext-fmod.dll
?

fmod: import/no-user/no-lib %ext-fmod.dll

That combination was Carl's suggested replacement for the /only option. 
More fine-grained control.

Keep in mind that exported words that are predefined are not overriden 
by the export process. Your export of the word 'system will not change 
the setting of the word 'system in the user context. In order to 
change that you need to assign it manually. Word precedence is first-come-first-serve, 
so even if the 'system word in the user or lib contexts is protected, 
there will still be no error triggered because the export was going 
to just silently not work anyways.

The protection of the system words (that isn't working at the moment) 
only affects explicit assignment.

Yes, but we should be warned when you are trying to import word into 
context where the word already exists.. it looks that now it just 
silently does nothing, which could lead to suprices later.

It's only a surprise because the module system is not particularly 
well documented at the moment. The override policy is very consistent.

Documentation will not help in cases where you have unexpected name 
conflict.

There will always be a name conflict somewhere. That is why we have 
an override policy. Of course anything unexpected will be surprising, 
but in this case the unexpected thing is that there was a name conflict 
in the first place, not the behavior of the system in reaction to 
the conflict. That is of course assuming that the developer has read 
the docs, and that we have written them, neither of which I am really 
assuming at this point.

But the module system has had a first-come-first-served policy for 
a couple years now, with manual overrides if need be.