World: r3wp

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)

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?