World: r4wp

I'll work on shared libs support for other platfoms very soon.

Good job, guys, especially as R3 being open sourced becomes de-facto 
competition to Red. Nice you are supporting it though ...

Congrats Kaj, the example looks very nice:


http://red.esperconsultancy.nl/Red-REBOL-3/artifact/06f9d09a50394ed9f957f568e29bae8e651e9202

Thanks

Cool work Kaj!

So, would this mean that you maintain eg. the one curl binding for 
red/system and then also use the same for R3 ?

I don't understand the example. My imagination was, that I will have 
some make-native function or make-extension in R3, and somehow very 
easily I just plug in the red/system code, without the need of knowledge 
to cumbersome and cryptic R3 extension interfacing at all - I don't 
want to know anything about RX_Init etc functions ...

... kind like R2 DLL interface in R3 level ....

Yes, I want to rebase my cURL and 0MQ extensions on the Red bindings

On top of the Red bindings, you'll have to do marshalling to the 
R3 extension interface and data types. There's no way around that

A make-extension function to wrap the compilation of the extension 
would require the Red compiler to be ported to R3. In the end, this 
won't work anyway, because it's going to be ported to Red itself

The R2 DLL interface is rather specific functionality: it implements 
dynamic loading and binding of libraries. This could be implemented 
as a specific R3 extension, written in Red

Currently it only works on Windows, and you need the dyn-lib-emitter 
branch of Red/System
 I did n't know you have a Windows machine ;)

He doesn't, I do, that's my contribution to this bridge. ;-)

On several occasions in my life, I've programmed on a machine I don't 
have

Adrian, the R3 interface is abstracted, so the internal implementation 
can change. Making it more efficient can only be done by accessing 
the implementation directly, which would kill the abstraction

Carl put a lot of energy into building his island, on which he could 
remain isolated from the big, bad world. With the source opened, 
it could be argued that this was in vain

(Replying to AdrianS in Announce) R3's extension mechanism is designed 
to make it more possible to make and compile extensions that will 
continue to work even when R3 is updated. Even with the source open, 
that is still a value. The command dispatch model is also really 
useful for implementing native dialects and JIT compilers. The marshalling 
mechanism is also reasonably fast by FFI standards. It could, however, 
use better marshallers for series, and more datatype coverage.

Oh, sorry to duplicate some of your response, Kaj.

If the Red JIT compiler were made available in an extension, you 
could use commands to dispatch to compiled functions withough having 
to write the compiler in R3.

Very cool action, Nick. Thanks for doing that

Thanks Nick.

Cool, Max

Very cool Etsy addition Nick. I agree that this will in the very 
least cause some curiosity about Rebol. And once you try it...

Red test binaries: I will certainly have good use of them (at least 
for regression tests).

I thought so :-)

Carl is asking which Repo to use ... let's have some unity in response 
this time!

Carl seems to be on steroids last days :-) Wonder if he is going 
to be back to active development too at some point ....

Perhaps he's found the courage again to restart his dreams

@ MaxV : r3D is neat

all it needs is an event handler for the 3d view so that rotation 
is clamped to (ZX) / Y axis   and scrollwheel to scale (XYZ)   :-)

Kaj, I'm probably doing this wrong. All examples under MSDOS/Red 
fail with:

---------------------------
empty.exe - Entry Point Not Found
---------------------------

The procedure entry point wprintf_s could not be located in the dynamic 
link library MSVCRT.DLL. 
---------------------------
OK   
---------------------------

I think you've found an important bug, just before release. Thanks! 
:-)

Could you please enter it in the Red issue tracker?

Do the Red/System programs work?

Only those that work with console. The rest seem to fail, because 
I don't have the appropriate DLLs.

Henrik: what Windows platform were you using for that test?

All MSDOS/Red binaries run fine here (Windows 7 32-bit).

MSVCRT.DLL errors are often related to compiling in Debug mode or 
version mismatch in installed redistributables with requried ones.

Henrik, yes, for a number of the examples you need to install the 
corresponding libraries. I'm particularly interested in library names 
for examples that don't work yet

DocKimbel, windows XP 32 bit

Kaj, well, glut-triangle.exe responds with:

---------------------------
GLUT-triangle.exe - Unable To Locate Component
---------------------------

This application has failed to start because LIBGL.SO.1 was not found. 
Re-installing the application may fix this problem. 
---------------------------
OK   
---------------------------

LibGL is usually supplied by Mesa3D. Although after that, you probably 
need to install GLUT separately

This is actually an example by Andreas

---------------------------
OSM-GPS-Map-browser.exe - Unable To Locate Component
---------------------------

This application has failed to start because LIBGTHREAD-2.0-0.DLL 
was not found. Re-installing the application may fix this problem. 
---------------------------
OK   
---------------------------

It's possible that you have some libraries already installed, but 
the library names or versions in Red are wrong

For most of the graphical example, you need to install GTK. GThread 
is a component from GLib, which is usually included in a GTK+ distribution

OSM-GPS-Map is an extra library on top of that

for the windows examples, should there be some indication of failure 
for something like do-sql.exe or GLUT-triangle.com?

when I execute these, I get no output