World: r3wp

Oldes: I don't think you can do it different way since REBOL has 
no c-like pointers.

The only way is to generate rebol wrapper func which will pass the 
args in a block! or object! imo.

(Or binary! :)

ok.. no problem.. I was just asking as I'm learning. It's just something 
like educative free time project for me as I don't need it.. I use 
maybe 20 functions of IM in real life.

(and I could use Jocko's extension for the rest if needed of course)

Next question.. when I have:
		case CMD_MagickGetImageColors: {
			if(current_wand) {
				RXA_INT32(frm, 1) = MagickGetImageColors(
					current_wand);
				RXA_TYPE(frm, 1) = RXT_INTEGER;
			}
			return RXR_VALUE;
		}

While compilation using GCC I get this warning: use of cast expressions 
as lvalues is deprecated

The command is working, just would like to know if I can improve 
it somehow. The function is defined as:
	size_t MagickGetImageColors(MagickWand *wand)

That's due to how RXA_INT32 is defined.

Use RXA_INT64 instead, and the warning will go away.

Right.. that's it.

Having:
	double mean, standard_deviation;
What I must do to get REBOL block with these two values in it?

This seems to be working, but is this the best solution?
	REBSER* block = RL_MAKE_BLOCK(2);
	RXIARG val;
	RXV_DEC64(val) = mean;
	RL_SET_VALUE(block, 0, val, RXT_DECIMAL);
	RXV_DEC64(val) = standard_deviation;
	RL_SET_VALUE(block, 1, val, RXT_DECIMAL);
	RXA_TYPE(frm, 1) = RXT_BLOCK;
	RXA_SERIES(frm, 1) = block;

I have MP3 playing from R3 console using FMOD extension... at this 
moment just a very first test:) Must go sleep unfortunately.

really cool.

I started using Code::Blocks and now I get error:
	invalid conversion from 'const char*' to 'REBYTE*'
for code:
	RL->print("init\n");
Which was fine with GCC. Any idea why?

Also I see such a warnings:

 ..\src\include\reb-config.h|109|warning: ignoring #pragma warning 
 |

A110?

yes

Windows? Linux?

Windows

I've got it... the file was .cpp instead of .c

(the warning is still there, but I can print again)

Do you know, if it's (or will be) possible to get struct! from handle!?

Or to return struct! from the C side?

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.