World: r3wp

just the fact that you can retarget the whole 3D engine to direct 
X, OpenGL (or another if you wanted to do so) is really impressive.

I guess this comes with some visual difference, but it means you 
can make it as optimised as you need it depending on platform.

I wonder how well does REBOL work with such kind of stuff. What will 
you use? Kind of direct linking to functions? Or kind of dialect 
abstraction as we use for AGG (draw)?

What is the best method to hold data/config to external systems and 
their data structure? Is that an object? Or utypes? :-)

both, scene creation will be dialect based, with a full mapping of 
EVERY single public class, member & method

utypes would allow us to abstract the interface, so that would be 
my preference.  

otherwise I usually use objects or nested blocks for complex structures.

above: "with a full mapping"  I meant that  "there will *also* be 
a full mapping"

with vector support this will make it very fast to xfer data between 
3D apps & rebol, since the data will be usable AS-IS in both directions 
 :-)

which always part of the point of implementing vectors AFAIK.

do we have multidimensional vectors?

I don't remember... Not in the first releas IIRC

Probably to BrianH: is it possible to open file in Rebol and transfer 
the filehandle to extension C routine? Or is it neccessry to give 
the filename as parameter and reopen in extension subroutine?

I forwarded the question to R3 Chat IIRC, but no reply. We will see, 
once we get back to the Extensions topic. Now there are some big 
changes to 'parse happening, so I would probably not disturb Carl 
with additional questions :-)

Is it even possible to unload extension? IE where and when RX_Quit 
comes into action?

Practically when you want to restart/exchande extension you have 
to close whole rebol process.

exchande=exchange

I've seen no documented way,  so far, but I am assuming this will 
possible when extensions will be fully done.

I would guess that they unload when collected by the GC, and definitely 
when R3 quits.

Answers to Pavel: 1) Don't know, but I doubt it. I'll check the port 
model. 2) Probably.

but we *should* be allowed to unload extensions ... eventually... 
if only for testing purposes. even if its "dangerous".  its up to 
the developper to be clean if he wants to  attempt unloading... I 
woudn't want R3 to prevent me.... "for my own protection"

Actually, you don't want to be able to load extensions without freeing 
references to them, as memory corruption would result. Memory references 
including all of the exported commands.

I know... but we can build code around the fact that its symbols 
won't be used for a long time.  like I say, its not something you 
do without knowing what you are doing.  any commands refereing to 
the old lib, can be replaced with no-ops raising errors... this would 
make it safe.

I haven't read everything here--just trying to clear a few groups 
so it's not as overwhelming next time I make it back here, but shouldn't 
it be possible to write the equivalent of R2's library interface 
*as* an extension in R3?

IMO probably yes when you are satisfied with types extensions are 
able to work with so far.

yes, its the way I think it should be done. we could provide pseudo 
type middle ware in the extension to accomodate incompatible types 
like Unsigned integers or structs, much better.


I plan on building a block->struct interface when I start doing my 
more serious extension development... (waiting for next extension 
enhanced release.)

If you are willing to give up support for MAKE, MOLD, built-in reflectors 
and path access, you can implement structs as handles. You would 
access them through accessor commands, and struct and routine declarations 
would be a dialect that would be compiled to calls to extension code.

yeah, that's the idea... using a block to struct dialect to build 
the structs from scratch, then just refer to them after.

but the hard part actually is to resolve all the different macros 
which define the types and the enums.

That's what SWIG is for, or human analysis. Or you could reimplement 
SWIG in REBOL if you like.

I already did a header file scanner a few years ago... but it wasn't 
recursive... nor did it resolve macros.

Some C compilers have preprocessors that can be called separately, 
or standalone.

but it did resolve all the enums, the functions and their input types, 
generating equivalents in rebol, to build C code dynamically by rebol.

that is a great idea... generate the intermediate C files, and convert 
them into rebol extensions... using only the top-level headers as 
what is exported as commands and defined structures.

Sounds cool. Now all you have to do is run it on the output of the 
preprocessor.

I also thought of a very neat way to map c methods and struct access 
 :-)

exactly.

Hey, can you help me with my libjit project?

use "." in the words.   just like if they where paths in rebol  :-)

libjit?

It's the JIT compiler that is used as the backend of DotGNU Portable.NET, 
among other projects. LGPL, generates x86, x64 and (experimentally 
so far) ARM. SSA intermediate code. We can make a compatible SSA 
REBOL dialect and build up a compiled dialect from there. The *existing* 
extension model is sufficient, no more changes required.

Tiny (about the same size as TCC), and a good first project that 
could be adapted to wrap LLVM if we like, as long as we keep our 
portion of the extension code license compatible with BSD.

this is REALLY interesting... that is exactly what my header scanner 
was being used for... indirectly.

it generated C code compiled by a (very high-eng) compositing software.

In case you were wondering, this is the main reason I was working 
so hard on R3 - so I could work on a project like this. Now that 
the parsing advancements are happening, soon R3 will be good enough 
for me to do my projects. For me, R3 will be released.

the reason this software (shake, now owned by apple) was so much 
faster at rendering, is that it wasn't a rendering software... it 
was just a C disguised C compiler :-)

when you pressed the render button, it actually compiled your project 
(in a matter of a few micro-seconds) and ran it.

Apple is moving rapidly to LLVM because they can't get the GCC project 
to cooperate. They already use it for iPhone development and OpenGL. 
Having a path to get to LLVM would be a good thing.

yes very.

and yes I'm interested.

I need this for ElixirOS.  its part of my roadmap for it  :-)