World: r3wp

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.

you are only working against the argument list.  I use args outside 
of the commands in other functions which manipulate rebol values.

I always have to track the types manually, when they could be a property 
of the data.

I'm not so far... I'm just a C newbie:)

which is why I built this structure when I know I am going to be 
using the data outside of my command block...

typedef struct ht_value HTVAL;
struct ht_value {
	RXIARG value;
	u32 type;
};

it can be used in place of RXIARG directly, but it can also store 
the type right there.  so other functions can ask for type, just 
like we do in Rebol.

(because some functions act on several different types)

Oldes, to get the length of the series use:
RL_SERIES(ser, RXI_SER_TAIL) - RXA_INDEX(frm, 1)

I just realized that it sucks that that index position is also part 
of the argument frame and not the argument itself  :-(

Well, it actually is part of the _argument_, but not of the REBSER 
"series" (which is really the series data).

I.e. if you have an RXIARG of of a series type (RXT_BINARY, RXT_STRING, 
etc), this arg also holds the index.

And a pointer to the series data.

ok. so it does hold the value.

TAIL - INDEX looks better, thanks... btw.. https://github.com/Oldes/R3A110/tree/master/extensions/zlib

Has it ever been discussed that R3 should be able to do IMPORT %file 
and know to look for %file.so on POSIX systems and %file.dll on Windows?

thing is you can import  %file   for     %file.r   too.

You can import 'file for %file.r (or whatever system/options/default-suffix 
is), but when specifying a file you are assumed to know what name 
it is. And you can use %.rx if you want a cross-platform file extension 
for your extension.

Operating systems may react badly to that, because they may expect 
their standard file extension. R3 extensions are OS dynamic libraries 
and are expected to be registered that way in the system

On Windows at least this is not a problem - libraries can have any 
extension, even .exe.

But the real trick is to load your platform-specific filenames ahead 
of time and then refer to them by module name.

How would you know ahead of time which program a user wants to start?

You can load your extensions delayed. Beyond the pre-delayed extensions 
the "user" should probably not be loading them. Unless the user is 
you, at which point you know. Modules are imported into the system, 
they aren't sandboxed.

How come? Computer is started. User may start a program on Monday 
that needs to load cURL extension. May decide to start a program 
on Tuesday that needs to load 0MQ extension

Earlier in the session of the call to the interpreter. When the program 
starts it loads the extensions and modules it needs. If you need 
to load things from specific filenames, do that before you load the 
other code. The module system is designed to help you organize and 
manage the code in a program.

I really don't want to load all extensions in the system on all days 
of the week. Just like I don't load the thousand libraries in a Linux 
system into every program (well, almost, but that's the gruesome 
consequence of this going wrong)