World: r3wp

PPC to x86 transition. x86 to x64 transition. OpenGL emulation on 
old video cards that don't support new features. Instruction set 
independence for the iPhone. Objective-C support in the front end 
that can be integrated with their development tools without license 
restrictions. A development commuunity that will accept their patches. 
The list goes on.

guys - shouldn't routine! and  and struct! datatypes be removed from 
R3? How are they usefull without R2 interfacing model? struct! was 
not optimal too (IIRC, some guys requested some enhancement to allow 
better nested structuring ...)

those could by later replaced by utypes, no?

For that matter, we probably don't need  the rebcode! placeholder 
type either.

As for LLVM for a target - what is the plan - to port entire REBOL 
into LLVM? Where can you find LLVM by default? Is it e.g. part of 
Linux distros?

Brian - so we should probably CureCode it, suggesting to remove those 
three?

Or let it in there, with following error message: "routine! is not 
available in REBOL 3. Please look into Extension concept ..." :-)

The standard REBOL DO dialect isn't compilable, though in theory 
PARSE could be if it were made less dynamic. What we could do is 
a compilable dialect that would resemble a subset of the DO dialect, 
similar to RPython of the PyPy project.

That is the theory at least. I haven't yet bought that REBOL isn't 
compilable - noone has proved it to me enough to stop trying :)

its compilable, but the code is self modifying, meaning, you need 
to track when that happens and jit compile it again.

subsets of rebol are more static, or could be with little loss in 
features.

Most of my code would be difficult to compile, but most conventional 
code should be fine :)

Actually, I'm convinced that more of REBOL is compilable, but that 
the process of compiling it is comparable to evaluating it.

my point has always been, that IN GENERAL, REBOL code is not compilable. 
that is, for every compiler you write, i can write a piece of REBOL 
code that is perfectly legit but your compiler can't compile. That, 
however, does not mean that you can't compile 99% of existing REBOL 
code. In fact, I do have a compiler that can handle most REBOL code 
(it's unfinished, i need to add some kind of type inference to make 
it useful enough). it can already take REBOL code as input, and produce 
optimized REBOL code as output.

also, JIT compilation is a whole differen thing than static compilation. 
You can probably JIT compile *all* REBOL code, however, it may be 
slower than the interpreter in some cases.

In either case, compiling REBOL requires thinking about REBOL and/or 
compilation differently, and trying to do so would push the envelope 
of compilation as a subject. And thus would make an interesting project 
:)

In general though, REBOL's semantics have been optimized for interpretation. 
As such, compilation may not give you as much of a speedup as you 
might otherwise think. This is why I was thinking of a dialect with 
semantics that would be more appropriate to compile. The syntax could 
be the same (to save on parsing code), but the semantics subtly different.

I tried to compile an extension for R3. Compiled as a C dll, it's 
ok, but I need to compile it as C++,as I will use com calls. So far 
it seems that R3 is not compatible with a C++ compilation of the 
extensions. Any experience on that ?

yep, the reason is that the labels within the dll change when they 
are applied through the C++ compiler.

there has been talk about the possibility to declare the functions 
differently within the extension libs themselves... but I haven't 
had time to play around with this yet.

BrianH can probably give you some pointers on what to try out if 
you're a proficient C++ coder.

It shouldn't be difficult to wrap the function declarations in the 
extension header files in extern C blocks. That would handle the 
C++ incompatibility. You would be able to write your C++ code within 
your extension, and still talk to R3 through the C model. In the 
longer run we intend to tweak the headers so that they are compatible 
with more compilers, so that you can be binary compatible when your 
code is compiled with a different compiler than R3 is.

Maxim, Brian,
your suggestions were correct. Thanks


I succeded with very few modifications to the example given by Carl:
( tool: Visual Studio 2003)

- the source file extension must be changed from .c to .cpp for a 
cpp compilation
- in reb-ext-lib.h change the line 
#define RXIEXT _declspec(dllexport) to
#define extern "C" RXIEXT _declspec(dllexport) 


I have not fully tested the extension, but I was able to do a simple 
Text To Speak using windows SAPI5

sorry , I made a mistake :- in reb-ext-lib.h change the line 
#define RXIEXT _declspec(dllexport) to
#define RXIEXT extern "C"  _declspec(dllexport)

oh cool, I'll updating that in my own project  :-)

thanks for giving it the time, brian and I didn't have, to make it 
work  !

I have coded a simple Text To Speech Extension, using SAPI5:
http://colineau.societeg.com/rebol/R3_extensions.html

I would be interested to know any other experience in R3 extensions

I did a few tests loading up OpenGL/GLut and it worked without a 
hitch... waiting for Carl to add a few features before I can continue.


screen shot of a rotating cube http://www.pointillistic.com/open-REBOL/moa/steel/R3-OGL.png

Nice !

I remember you posting a similar screenshot a couple of months ago. 
What's the difference now?

none... just reposting it for jocko... 


I believe he wasn't around at the time... and he was asking about 
other work done with extensions so far...

ok

Maxim, let's move here?

I try to keep this as short as possible.

Imagine you have this file, called %test.r:

==file==

REBOL[
    Title: {Simple extension test}
	Name: ext-test
	Type: extension
	Exports: []
]

map-words: command []{
    word_ids = RXI_MAP_WORDS(RXA_SERIES(frm, 1));
    return RXR_TRUE;
}

fibc: command[
    len [integer!]
]{
    RXA_TYPE(frm, 1) = RXT_INTEGER;

    i64 o = 0;
    i64 l = RXA_INT64(frm, 1);
    i64 i;

    for (i = 0; i <= l; i++)
        o = o + i;

    RXA_INT64(frm, 1) = o;

    return RXR_VALUE;
}

add5: command [
    a [integer!]
][
    a: a + 5
    return a
]

==end of file==


And now imagine that in R3 console you are in the directory where 
you have the file %test.r .
Now you type:

>> compile %test.r
>> import %test.dll
>> fibc 10
== 55
>> add5 5
== 10

And that's all.


If you want to try it, you need to have TCC (TinyC Compiler) - get 
it from http://download.savannah.nongnu.org/releases/tinycc/tcc-0.9.25-win32-bin.zip
The script expects it instaled to %/c/tcc/ but it can be changed.
Then go to r3 console and type:

>> do http://box.lebeda.ws/~rebolek/rebol/srec.rip
>> cd %srec/
>> do %srec.r


Then you can try COMPILE etc. (see above). %test.r is included in 
the archive.

SREC is shortcut for Simple REBOL Extension Compiler.
    
Enjoy! (if it works ;)

interesting :-)

Are there Matlab users ? Going on in my investigation of the extensions, 
I have created an extension for executing Matlab instructions from 
R3, by calling the Matlab engine. Exe and source are here : http://colineau.societeg.com/rebol/R3_extensions.html
.

not anymore. I used it some 10 years ago for some astronomy purposes 
:-)

janko congratulations on your extensions... I knew extensions where 
the door to a whole new world of possibilities for REBOL.

Yes, this is all very cool to see things coming from people.

That's cool, Jocko :)

Ass soon as I know how to call a Rebol function from Extension with 
some simple parameters I'm ready to start.

Thanks
Robert: do you mean execute rebol code inside C programs?

The host code will allow that. Extensions are the opposite. The calling 
model will probably be similar though.

Host code will allow what? Callbacks? You want to tell me, that in 
order to call-back some rebol funciton, it has to be in host part?

Not that I'm aware of. Callbacks are a separate issue, which is supposed 
to be handled by devices, afaik.

so, Robert, not sure if you understood all of these replies as even 
I had a bit of a tough time to "get" them.


Right now, Extensions only allow REBOL to call functions from a dll. 
  What I would like is to simply improve the extension model so  
it can also call REBOL code, as a callback or something else, but 
there are a few issues which make this a non-trivial thing to do.


So far there seems to be a generalized idea that there should be 
a different kind of extension which allows this, but I see no reason 
why it should be another, different. api.  having one DLL   for  
REBOL -> DLL  and another for  DLL -> REBOL  makes absolutely no 
sense to me.   IMHO we need a single DLL able to do both.  Even if 
it means a little bit more work to design it.

agreed - just don't put another burden on user. By dismissing DLL 
interface, many users will not be able to make otherwise usefull 
things at all. So if it can be done in terms of current extension 
API, even if it would mean some additional work, let's add it. I 
don't want to hear, that in order to do a callback, feature available 
in R2, I hav to do some other tricks.

I've updated http://box.lebeda.ws/~rebolek/rebol/srec.rip.

The fibonacci function can now be written as:

fibr: command [
    len [integer!]
][
    o: 0
    repeat i len [
        o: o + i
    ]
    return o
]


and compiled to DLL. If you prefer c-code, just use string! with 
c-code in command's body, instead of block! with RebC dialect.

will the rebol code be converted to C prior to compile?

yes