World: r3wp

The problem is, I'm not sure where it happens in the source-code 
file as the output doesn't tell you. But can't I use the (.text+0x867) 
stuff to locate the usage in the source file?

Or is there a better way to map the error message back to the source 
file?

Search thru all your source files for RXARG_SERIES and replace it 
with RXA_SERIES

OMG... this is a good example of seeing RXARG_SERIES and understanding 
RXA_SERIES... I though I did this already.

But RXARG (the old one) was a shortcut to access the .series union 
member. The new RXA_SERIES one needs a frame pointer and a number. 
Which I don't need. So, the new approach is to access the union members 
directly?

Yes.

Ok.

At least there currently is no set of macros to work with "standalone" 
RXIARGs.

Only with RXIARGs contained within an RXIFRM (or frame-like array, 
like in the callback info).

I built my own macros to do exactly this.  I proposed them to Carl, 
he mentioned he'd put them in the official distro... seems like I'll 
have to put them in git hub myself  :-)

Good aproach, Max. Now If Carl mistakenly uploads r3 core DLL, we 
might get in beta after all :-)

Just a question: with the extension model complete is it possible 
to interface to .NET ?

The answer to that question is as yet unknown. Noone has tried it 
yet. Do you mean calling into the .NET APIs from native code, or 
calling into native code from .NET?

If the latter, this question is better suited for the !REBOL3 Host 
Kit group.

Maxim, if you want those macros included in alpha 111, today would 
be good.

Calling .NET API from native code.

I think that there are ways to call .NET APIs from C/C++ using COM 
interop and other methods. MSDN should have the details.

It would be useful to have a general .NET wrapper extension that 
uses Reflection, ActiveX or something to call arbitrary .NET code.

http://msdn.microsoft.com/en-us/library/aa446536.aspx

http://en.wikipedia.org/wiki/Platform_Invocation_Services

Those are both for calling native code from .NET code. Guiseppe was 
requesting the opposite, calling .NET from native.

Exposing .NET Framework Components to COM: http://msdn.microsoft.com/en-us/library/zsfww439.aspx

You can use .NET based DLLs as if there are normal DLLs.

How does the .NET runtime get called to run the functions in the 
DLL?

Must be a function of the system's loader

afaik, .net is a dll too.  so its probably just loading the .net 
libs.    


in fact, looking at some stuff related to C# and p/invoke I realized 
that the rebol .dll and  .net stuff are very similar in scope and 
function  :-)

the difference is that the type system in VM allows them to jit compile 
stuff more completely than can be done with REBOL's just-in-time 
evaluation and binding.

IIRC as soon as you load a .NET based DLL, this will trigger the 
startup of the .NET runtime. So, it's hidden. I don't know if a .NET 
DLL has a dynamic link to the runtime DLL and calls an init code 
sequence or if this is done inside the Windows loader.

Pretty much the same concept as REBOL code in R3 extensions, or OCaml 
bytecode for the interpreter in standard shared libraries

The only thing you can't do is fully strip such a library, because 
then the OCaml bytecode is gone

What is error: ** Script error: invalid command format (extension 
function) ?

hmm... it's possible to use max 7 args for command.

What is error: ** Script error: commaned word is not bound to a context

ech.. just a typo!

Is there any other way how to get series index than from RXA_INDEX 
macro?  http://issue.cc/r3/1858

Oldes, no, there isn't.

And it is quite possible that this may not be doable at all (if the 
index is not stored in the "REBSER" structure and the REBSER has 
no back-pointer to the index-containing rebol value).

The workaround/solution is simple: don't pass REBSERs to function, 
but use the RXIARG instead and then access the index via .index and 
the REBSER via .series.

The command call process does a lot of marshalling to get the values 
into the native code. You only have limited access to the original 
values in REBOL memory.

ok

This is to allow changes to the internal structures to happen without 
breaking host or extension code, and for security reasons.

Oldes, I gained this insight the hard way as well :)

I guess RXA_SERIES is simply too tempting :)

The index is simply not part of a series at the implementation level

What appears to be a series with an index in REBOL is actually a 
reference with an index. That's exactly what an RXIARG is. What the 
hostkit level calls a REBSER is the actual series, not a reference, 
so that doesn't have an index

It takes some massaging of one's brain to arrive at that conclusion 
:-)

I personally think of the RXIARG (which is a neutered REBOL "value") 
as "the series", and of the REBSER as a subordniate helper structure 
(holding width/size/left and data).

Yes, at first REBSER seems an incorrect name, but the reality is 
that RXIARG can be though of as a "REBREF"

The index is part of the reference for series, not part of the series 
itself.

That's what I'm saying