World: r3wp

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)

Sorry, wrong system. I mean loading extensions into the program, 
not the operating system.

That was just an example. I do mean the R3 system

Is the module system meant to manage the code in a program, or the 
code in an entire operating system?

Just in a program, not the OS. Each program loads its own modules 
and extensions. Unless R3 *is* the operating system.

Then the program has a problem with portability due to different 
file extensions on different operating systems

You can use different IMPORT blocks depending on the OS, in the same 
code. The highest-level script is usually a not a module, so you 
can call IMPORT directly. Then your modules can just do their requirements 
by (word) name instead of specifying filenames.

But the .rx filenames are supposed to make things easier, and will 
for many OSes.

Exactly, so every program needs to test on which OS it runs and execute 
different IMPORT branches. So why not pull that into IMPORT itself?

IMPORT uses the OS's dynamic library loader, which searches through 
the system's locations where libraries are registered. So you install 
R3 extensions there, in the system. If you use .rx extensions, they 
will be the only ones, awkwardly between lots of .so files on POSIX 
systems and lots of .dll files on Windows

For one thing: system/options/default-suffix. For another thing, 
platform-specific stuff doesn't go in the mezzanines, it goes in 
the host code, as a (really strict) rule. For most code that needs 
extensions there is assumed to be a bit of platform-specificity, 
due to the nature of extensions. Nonetheless, this is why LOAD-EXTENSION 
is implemented in the host code, and why we can reference functions 
by word name.

I don't care if the implementation is in mezzanine or in the host. 
My question was if IMPORT can look for .so on POSIX and .dll on Windows?

Also, look at system/options/file-types. You can find the file extensions 
that are loaded as R3 extensions, and then go through them, adding 
them to your file's base name to find your file. Or you can add a 
one or two line platform-specific wrapper for your module code.

default-suffix is .reb and that is meant for a mezzanine module, 
not for an extension

file-types contains "%.so extension" so we're halfway there, but 
IMPORT doesn't act on it

You don't want IMPORT to do automatic lookup for more than one file 
extension because it's a potential security hole. For that matter, 
you should know if you're loading an extension instead of a module, 
because extensions could break the rules that REBOL source modules 
can't. And system/options/default-suffix can be set by your program. 
For that matter, the host code for LOAD-EXTENSION could translate 
.rx to .so on platforms that require .so and won't load .rx - that 
is a platform-specific restriction.

That's why I don't want to use .reb for extensions

I said system/options/default-suffix because it's settable, even 
at runtime, not to suggest that you can use .reb for your extensions.

That seems to me to be a much bigger security hole

It's program-local. The program should protect that setting if it 
is going to load untrusted code.

The translation of .rx to .so and .dll sounds like the proper solution