World: r3wp

That's too complex as on my C side I would like to have just the 
one function. Some enums can be pretty large.

on the other side I could just do range test and use the integer/variable 
from REBOL side.

Would that work? Is it even proper C?

typedef enum {
    PixelsPerInchResolution = RL_MAP_WORD("ppi"),
    PixelsPerCentimeterResolution = RL_MAP_WORD("ppcm"),
    ...     
}

I don't think so.

Why do you think the first idea is too complex? I for now don't get 
the "I would like to have just one function" argument.

How would one function be more simple using only enums?

if (unit == RL_MAP_WORD("PixelsPerInchResolution")) {
    SomeFunc(PixelsPerInchResolution);
} 
elseif (unit == RL_MAP_WORD("PixelsPerCentimeterResolution")) {
    SomeFunc(PixelsPerCentimeterResolution);
}
else {
    SomeFunc(UndefinedResolution);    
}

it just looks strange.

Also this is simplified case, what if I would have more enum args?

No, I didn't mean to dispatch to different functions, it's meant 
as an if/else statement in SomeFunc.

Ah.. yes.. that would be fine, but I would like to write wrapper 
to existing functions, not to write the functions.

I was about to suggest 

RXIEXT int SomeFunc(RXIFRM *frm) {
    int unit = RL_GET_VALUE(frm, 0, RXT_WORD);

    if (unit == RL_MAP_WORD("PixelsPerInchResolution")) {
    }

    elseif (unit == RL_MAP_WORD("PixelsPerCentimeterResolution")) {
    }
    else {
    }      
}

Than you mentioned the wrapper you're going to write. Let me think 
about that a bit.

*Than = Then

So, no creative solutions from me, then, I guess.

I have this one so far:
int unit = RXA_INT64(frm, 1);
if(unit >= 0 && unit < 3) {
	SomeFunc(unit);
	return RXR_TRUE;
}
return RXR_FALSE;

and in REBOL just:
SomeFunc 2
or
PixelsPerCentimeterResolution: 2
SomeFunc PixelsPerCentimeterResolution
or using dialect

I guess there is no easy solution as the enum is converted to the 
integer during compilation. If we are only in C.

How is the above superior to

---- REBOL ----
some-func 'pixels-per-centimeter-resolution

---- C ----
if (unit == RL_MAP_WORD("pixels-per-centimeter-resolution") {
    SomeFunc(unit);
    return RXR_TRUE;
}

But a dialected approach like


>> some-func: func [unit [word!]] [select [pixels-per-inch-resolution 
1 pixels-per-centimeter-resolution 2] unit] 


does look ok to me, though. At least, that way, assigning other numerical 
values to the "keywords" wouldn't harm.

Probably easier to maintain in REBOL than in C.

(Typo in the above, should've read "SomeFunc(2)" instead of "SomeFunc(unit)", 
but that has already been replaced by the REBOL dialect anymways)

the problem with the above is, that in A110:
words: [pixels-per-centimeter-resolution]
export testword: command ['wrd [lit-word!]]
...
case testword: {
   int unit = RL_MAP_WORD("pixels-per-centimeter-resolution");
   RL->print("int: %d\n", unit);
}

prints int: 1399  = something what I don't expect :)

for:
int unit = RXA_WORD(frm, 1);
I get 1381

That is expected ;-) The numbers you'll get are fairly random. You 
would have to get the word-number of a supplied word and compare 
it to the word-number of the allowed words. If they match, act accordingly.

Or, as stated, compare words in REBOL, e.g. as in my SELECT example. 
But just don't rely on  PIXELSPERCENTIMETERRESOLUTION: 2

now I see that in host-graphics.c is used something like:
u32 w = RL_FIND_WORD(graphics_ext_words,RXA_WORD(frm, 1));

            switch(w)
            {
                case W_GRAPHICS_SCREEN_SIZE:
                    x = GetSystemMetrics(SM_CXSCREEN);
                    y = GetSystemMetrics(SM_CYSCREEN);
                    break;

                case W_GRAPHICS_TITLE_SIZE:
                    x = 0;
                    y = GetSystemMetrics(SM_CYCAPTION);
                    break;
...

with:
case CMD_GRAPHICS_INIT_WORDS:
        //temp hack - will be removed later
        graphics_ext_words = RL_MAP_WORDS(RXA_SERIES(frm,1));
        break;

I never got RL_FIND_WORD to work, but I stopped trying around A102 
I guess and forgotten about it since then.

(never mind, time to sleep for a while:)

Yeah, time for bed here too, good night.

hm.. I think I understand how it's supposed to work now, but it looks 
it's just a temp solution. Here is the init part for graphics:
words: [
	;gui-metric
    screen-size
    border-size
    border-fixed
    title-size
    work-origin
    work-size
]
;temp hack - will be removed later
init-words: command [
	words [block!]
]
init-words words

But I think that the easiest way is to define the enum constants 
during the extension init like:
    export PIXELS-PER-INCH-RESOLUTION: 1
    export PIXELS-PER-CENTIMETER-RESOLUTION: 2
    protect/words [
    	PIXELS-PER-INCH-RESOLUTION
    	PIXELS-PER-CENTIMETER-RESOLUTION
    ]
and then just use:
    SomeFunc PIXELS-PER-CENTIMETER-RESOLUTION
or
    SomeFunc 1

with the correct int bound check in the command so only valid numbers 
are processed.  I really like what is possible with R3.. I should 
start real coding in it soon.

Hm.. maybe it's too soon.. the protect seems to be not working if 
used in the extension's init. I can change the values:/

CC: http://curecode.org/rebol3/ticket.rsp?id=1786

hm.. the protect above is not required anyway as long as there is 
the validity check in the command.

Here's how I explained to myself how things went:


With A102, the time I started playing around with extensions, there 
was this RL_FIND_WORD which is supposed to map words against an "extension 
local" word block. But sadly, I never got that working.

It was the "temp hack" comment from which I concluded that the preferred 
method then became RL_MAP_WORD, which maps a word to a global word 
id, hence the 1381 number you've got yesterday. With that, you don't 
need to ENUM in your code but can just compare words supplied with 
words known.


But, I may be totally off track with that reasoning ... wouldn't 
take me any wonder :-)

Guys, I put the comment about 'temp hack' couple of months ago when 
I discussed this issue with Carl. Not sure but the init-words trick 
will probably stay as is because it works fine that way. Ofcourse 
I may be wrong if there is some better method and Carl decides differently.

Ah, good, to know. So I'm off track indeed, I was expecting that.

When I have:
#if defined(_WIN64) 
#  define ssize_t  __int64
#else
#  define ssize_t  long
#endif


and function which arg is ssize_t type, how I should get the right 
value from REBOL in command?
Is this correct?:
(ssize_t)RXA_INT64(frm, 1))

Yes, Oldes.

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.