World: r3wp

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

Actually, it's not rebol code, it just looks like rebol code :)

I see the len function hehe.   Do you have the dialect documented 
somewhere?

actually len here is an input... doh.

yes it is documented but the documentation needs to be converted 
to some format that everyone can read. Also the dialect  needs to 
be checked if it's without problems - it's three years old and probably 
needs more fixes to work with r3 without problems.

AFAIK, it supports most of the math, loops (loop, repeat, if...), 
conditions (if, either...).

Anyway, if you don't use the dialect (the command body is string! 
with c-code), the compilation should work without any problem.

Have you build it from the ground, or is it based on some of the 
opensource REBOLs (R#, ORCA)?

It's build from the ground. It parses the dialect and translates 
it to c equivalent (a: 5 becomes a = 5 and so on).

How is loops and conditions perform compared to REBOL, plain C, Lua, 
Python, ...? Maybe you have rough estimate on this?

well, now I read your comments again, I bet it perform very well, 
as it is simple translation to C, right? What about blocks, have 
you implemented them?

IIRC (the dialect is 3 years old and I haven't touched it for few 
years, I just made some fixes in last few days to run it under R3), 
most loops are translated to C's WHILE. You can try writing some 
RebC code and when you COMPILE it, in the %work/ directory you can 
find %your-filename.c file, where you can see the dialect translated 
to C. Do not expect it to be optimized in any way :)

Yes, exactly, it just translates to C.

Interesting anyway. :)

IIRC, there was some support for blocks as long as they can be converted 
to arrray. Now that the COMPILE part works ok, I can focus more on 
the RebC dialect to enhance it.

The main reason I wrote the dialect was to convert mathematic functions 
in Sintezar to C to make it faster and not write it in C as C syntax 
makes my eyes hurt :)

Good idea. And you have strong typing rules, right? So if a var is 
defined as an integer, you can't change it to something else along 
the way?

Hm, I'm not sure right now, I think it was possible to change it, 
but I may be wrong. But I think there were no error checks, it was 
just a basic version that can produce something working and I haven't 
much time to improve it since. That has changed recently.

Rebolek, about documentation, feel free to use NicomDoc: http://www.fys.ku.dk/~niclasen/nicomdoc/

It can easily produce HTML output as (MakeDoc), but also PDF output 
by first producing LaTeX.

Geomol thanks. Currently the documentation is written in special 
version of MakeDoc that supports literate programming so it's mixed 
with the source code.

rebolek, I will definitely check this out.  if you have any docs 
converted to html, I will read them, so know it will not have been 
done in vain ;-)

I was looking at making a libtcc extension, which would allow something 
like RebC to be used as a JIT compiler.

You wouldn't need to package your generated code as an extension, 
just generate to memory and run it from there.

Hm, that would be interesting.

The command! type makes this possible, since commands can dispatch 
to dynamically generated code if  need be.

Eventually I was going to make a libjit or LLVM backend, but it looks 
like I can get libtcc working sooner.

Not the first thing on my list though (which is HTTP) so if you want 
to take a crack at it first, I can help with the extension/module 
model.

It looks like libtcc can be statically linked into an extension, 
only providiing an extension interface to its functions.