World: r3wp

This should set it at the head:

RXA_INDEX(arguments, 1) = 0;

But it should already be at that value

I've located where is the problem.. it's returning the image at the 
tail if the command is used in exported context!

Correction... it returns image index at tail when there is any exported 
context.. the command can be out of the context.

http://issue.cc/r3/1809

btw... I was trying to use: RXA_INDEX(frm, 1) = 0;  but in my complex 
extension I was even able to crash REBOL. But I'm not able to simplify 
it. The sample.c included with the bug report must be enough, it 
clearly shows that there is something wrong.

It's also strange that it returns correct index before I eval the 
exported context.

I added that last sentence to the ticket, as it might help diagnose 
the problem.

The callbacks documentation is incomplete, and refers to the host-ext-test.c 
file for examples, but this isn't in the current host kit

RL_Protect_GC protects unreferenced series from disappearing, but 
does it also protect them from being moved?

If not, how can an extension be sure that a pointer to a series is 
still valid?

I don't think the REBOL GC is copying or compacting. Series are only 
moved when they are expanded (a reallocation) so if you don't want 
it to move, preallocate the length you want.

OK, I gathered that it must work like that if it is to be stable 
now. But I wonder if it won't get complicated by tasking

I saw a warning somewhere in the documentation that series can be 
moved, but maybe that is indeed limited to their own isolated memory 
management

It would explain some of REBOL's high memory usage, because it it 
doesn't do compacting, there can be a lot of unusable, fragmented 
memory

if it

I don't understand, though, how the RL_SET_CHAR and RL_SET_VALUE 
functions could extend a series when necessary without ever moving 
it

There must be a guarantee that the description data that is pointed 
to will stay immobile, while the actual data does get moved

REBOL must have a global series descriptors registry, much like the 
words registry

It must be only the references to descriptors that get moved when 
in blocks

I would like to make a dialect for making extensions... so far I 
parsed spec for MagickWand and PixelWand API -
https://github.com/Oldes/R3-extension-iMagick

But I have a question... in some cases, like in this one:

MagickGetImageChannelRange: [
	"Gets the range for one or more image channels"
	wand	"MagickWand *"	"the magick wand."
	channel	"ChannelType"	"the image channel(s)."

 minima	"double *"	{The minimum pixel value for the specified channel(s).}

 maxima	"double *"	{The maximum pixel value for the specified channel(s).}
	return: "MagickBooleanType"
]


The command should return block [minima maxima] or FALSE... any idea 
how to specify it in the dialect?

It's quite clear, what it should return, when you see it in REBOL 
like form, but it's quite difficult to do such a decision when parsing 
the spec.. that's also the main reason, why I decided to work on 
human readable dialect. (I was trying to generate the extension directly, 
it's possible, but it seems to be hard to maintain.)

Just to make clear what's the issue.. for above example, the extension 
command should looks like:

MagickGetImageChannelRange: command [
	"Gets the range for one or more image channels"
	wand       [handle!] "the magick wand."
	channel  [integer!] "the image channel(s)."
]


The minima, maxima are just pointers to values which are used to 
return the result, which I must convert to REBOL block.

I'm using this piece of code to get pointer to binary argument:
            char *srcData;
            REBSER *ser = RXA_SERIES(frm, 1);
            srcLen = - RL_GET_STRING(ser, 0, (void **) &srcData);
But also must do this:
	srcData+=RXA_INDEX(frm,1);

To fix the pointer to correct position if the source binary index 
is > 0.
Is this a bug or is it normal? Should it be reported in CC?

OH... forget it... the correct way is using:

	REBSER *ser = RXA_SERIES(frm, 1);
            char *srcData  = RL_SERIES(ser, RXI_SER_DATA);
            u32 srcLen = RL_SERIES(ser, RXI_SER_SIZE);

Correction... the right result is:

	srcData = RL_SERIES(ser, RXI_SER_DATA) + RXA_INDEX(frm,1);

 srcLen =  RL_SERIES(ser, RXI_SER_SIZE) - RL_SERIES(ser, RXI_SER_LEFT) 
 - RXA_INDEX(frm,1) -1;

so I don't know what is better.

the recapitulation: http://issue.cc/r3/1836

Also added comment to related bug http://curecode.org/rebol3/ticket.rsp?id=1816&cursor=21#comments

Oldes, AFAIK its normal... in C we always have access to the full 
string.  

we use RL_SERIES to figure out the portion of the string which is 
used by a specific Series reference.

so basically if you call:

a: [1 2 3]
b: next a


and use A or B in the command, you get the same string (logically, 
not physically), but with only the RL_SERIES and RXA_INDEX() which 
are set to different values.

I'd say your option 2) is the more "correct" method.  though both 
are OK.

basically, one counts from the end, the other from the start.

I expect the pointer in the correct position. Reload the issue http://issue.cc/r3/1816
and read my last comment.

nice note about the RL_GET_STRING bug though...

yes for binaries, the use of wide chars makes no sense.

and yes.. it's fine that RL_SERIES(ser, RXI_SER_DATA) returns string 
at it head. Than I would like to have the RXI_SER_LENGTH as a shorthand 
for: RL_SERIES(ser, RXI_SER_SIZE) - RL_SERIES(ser, RXI_SER_LEFT) 
- RXA_INDEX(frm,1) -1 


and the bug is, that the binary is not using wide, but reports it 
and counts the pointer position as wide - as Kay reported.

I never liked that Carl wrapped all pointer data as SERIES... they 
share very little in fact.


I added quite a few MACROS in my hostkit to make working with a few 
of the types more xplicit in code...  I also wished Carl stored the 
type right in the RXA_ARG ... which is why I did a superset of it 
which has the type value at the end...  then I can just look it up 
instead of passing it as an argument within my own code all the time.

(but its been 2 months since I last played with this... so its a 
little far in my head)

just propose it in the 1836 CC, Carl is quite open to improvements 
of these kind.

I've had a few things added with obvious requests like this.

especially when they are One liners and quite usefull.

 I also wished Carl stored the type right in the RXA_ARG
 ... what about => RXA_TYPE(f,n)

I wish Carl had more time for extensions and devices as well.

that only works when you use the types within the argument list... 
when you are creating things and passing them over to functions, 
you must always pass the type as well as the data.

I wonder if we can somehow solve that you must provide handle in 
most cases for each command..

In Kaj'scurl it's the SESSION handle, in iMagick it's the WAND handle... 
etc. what we can expect from the devices?

yes.. I hope he gets devices done and current devices end up in the 
open source part of the hostkit.

Oldes, CC it as a wish (RXA_TYPE(f,n))

that's how it is... and that is the problem.

we should be able to do   arg.type directly.

I don't see it as a problem when I write:
    RXA_SERIES(frm, 1) = destSer;
    RXA_TYPE(frm, 1)   = RXT_BINARY;
    RXA_INDEX(frm, 1)  = 0;

At least it's clear in the source, what you can expect. Or what you 
want to propose. It's Maxim's wish:)

Or you want to use:
   RXA_BINARY(frm, 1) = destSer;
? That would be just a cosmetic thing.