World: r3wp

When I have func's arg:  void *pixels  which should be pointer to 
allocated binary buffer, how to provide it from the REBOL side?

Using just RXA_SERIES(frm, 1) does not work.

RL_GET_STRING(RXA_SERIES(frm, 1), 0 , (void**)&pixels); doesn't work 
as well... I think we need RL_GET_BINARY macro...

hm... it must be something like:

REBYTE *pixels = ((REBYTE *)RL_SERIES((RXA_ARG(frm,7).series), RXI_SER_DATA));

but still miss something important.

I'm so stupid! I was testing on wrong data all the time.. the last 
one is correct:)

Fine that it works :)

I just would like to know if it's possible for example to change 
the series tail on C side (and to avoid a need to init the series 
on REBOL side).

because now I must do for example this:
	pixels: make binary! num
	insert/dup pixels #{00} num
before I can use the value in C

(I can use it in C without the insert, but I get empty script back 
to REBOL - there must be updated the TAIL)

Would have to try again, but as far as I remember, RL_SET_VALUE would 
update the tail.

When I have func which require something like:  double *distortion 
  so it modifies the value of existing REBOL variable, how to do 
it?

I know I could just do it with different approach, but I'm still 
in a learning phase.

I think you cannot modify such rebol value directly. You have to 
return it by the command! function.

That's the approach I was thinking about. It probably makes a sense 
as REBOL internal storage may differ.

For one thing, REBOL storage is made up of 128bit variant value slots.

But I would like to know, if I can just change the provided variable 
without returning it back as a command result. (as it's possible 
with series).

yes, for example you never know where the decimal! is in the memory...it 
can be even just on the stack so or can be GCed so I think it is 
unsafe to just modify it on the C side and then rely that it'll be 
reflected on the REBOL side without explicit returned value.

All value slots are either in blocks, objects or function contexts 
(using the generic terms). There are no free value slots.

Oldes, the different situation is for series values (string, image, 
block...) though. You can directly modify them and use RL_Protect_GC() 
to make sure GC won't mess with your changes.

And you don't have to worry about the GC collecting a double since 
it will always be in a value slot, so all you have to do is protect 
the series or context it is in.

Brian, I'm not sure about that. IIRC the value slot of double passed 
as command! arg is just on the 'function command frame' at the time 
the command! is executed so it is a copy of the real value you are 
refering to.

He was asking about changing the original. The only way to do that 
is to pass a reference to the series or context that contains the 
original value slot.

if the frame is just a copy, is it possible to get the original?

yes, that's correct.  I though he want's to do something like:
d: 0.0
change-decimal d
probe d
== 1.234

The frame is just another set of value slots that the values are 
copied into. You can only get the original by passing a reference 
to the value slot container. There are no free value slots.

yes.. that's what I wanted to do:)

(whic is not possible)

yes, that won't work for you

ok

because the arg passed to the command function is just a copy of 
the real value

you need to return it

or as Brian said you could do:
d: [0.0]
change-decimal d
probe d/1
== 1.234

(but you should be using the protext_GC function to be safe)

better to avoid it.

but it a little bit complicates the automatic building of wrappers 
for functions like that. btw... at this moment I can build imageMagick 
extension by parsing it's doc (~4500 lines of C code:).  Just must 
solve a few functions where it's using this approach to return multiple 
values and add some validity checks to make the extension safer.

Brian: actually the values on the 'command frame' are 'free value 
slots' as they are not part of any series...they are just in plain 
fixed size array. But  this is probably just playing with words ;)

They are in the command frame :)

ok :)

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?