World: r4wp

Kaj: not yet, there are several ways to integrate Red/System in a 
Red program:


- inlined in Red code: it will be done using a #system compiler directive 
followed by a Red/System block of code. You should be able to use 
it pretty much anywhere. Trivial to implement.


- executed at runtime: using a DO/SYSTEM, but we need the Red/System 
compiler written in Red to be implemented first for that.


- through Red/System exposed functions to Red: this needs a native! 
definition in Red. It needs some intermediary code for supporting 
automatic marshalling/unmarshalling arguments passed between Red 
and Red/System. But it could be added quickly. Red's routine! type 
will use the same approach for mapping imports.

- by directly coding the native! in Red using something like:

    foo: make native! [[<spec>] [<Red/System body>]]

Lot of fun in perspective! ;-)

I'm looking for the first "trivial to implement" to get started as 
quickly as possible

The rest sounds good, too :-)

You'll got it by tomorrow. 


And BTW, the generated Red binary is in the working directory by 
default. ;-)

Cool

There will be docs from doc?

Yeah: "print <integer!>"

wow, I'm very happy.. this is great!

Ah.. I need to wait for "print <decimal!>" ....

Here we go: https://github.com/dockimbel/Red/tree/v0.3.0/red

#system directive added.

I will add math ops and basic block actions later today, so we can 
play with it a little. ;-)

(BTW, please read the content of the README file displayed at the 
above link.)

@BrianH: as you can see from the source code, R3 actions are a strong 
inspiration. ;-)


I also plan to add some actions from Topaz, but Topaz is still higher 
level than Red currently.

If you want to see how the boot.red script is compiled, use:

    do/args %red.r "-v 2 %red/tests/hello.red"

Now you know why I want redbin format asap. ;-)

not trying to panick, maybe downloaded bad branch, but:

>> do/args %rsc.r %tests/hello.reds
Script: "Red/System compiler wrapper" (none)
** Syntax Error: Invalid word -- <<<<<<<
** Near: (line 2028) <<<<<<< HEAD

double clicking red.r in the root causes the same error .....

Looks like you made some modifications in your existing code before 
updating and you ended up with merging conflicts (most probably you 
have merged two branches).


You should first do a checkout to the right branch, then issue a 
pull.

Easiest way to solve that is to clone the repo again in another folder.

ok, will do ...

So, I have compiled my first RED program succesfully!

Two notes:


- when in root directory, where %red.r resides, is there a need to 
specify it in compilation process? do/args %red.r - or do we expect 
more compilers here?


- executable is spilled out into the root too. I would probably use 
the way compatible to red/system, and create /builds subdir?


Or is all above intentional to allow to compile/link from working 
dirs?

It is intentional. You can use the -o option to redirect the binary 
where you want.

*Important*: Red will be distributed as a binary to end users and 
the effect of:

    red script.red
    

will be to compile and run it from memory directly. So the -o option 
will become mandatory in the future for generating an executable 
without running it. During the bootstrapping stage, it is complex 
to support that feature, but it will be implementd as soon as possible.

Could you please elaborate? Is red executable going to be kind of 
launcher for our scripts? Hence it compiles them before running it? 
Most probably not a solution for CGI, as the compilation stage will 
happen each time?

For CGI, you should obviously pre-compile them if you want performances. 
The future JIT-compiler should be able to handle such cases fine 
though.


But yes, the goal is to be able to run Red scripts directly in the 
same way REBOL does. The fact that Red compiles them should be transparent 
to users. The -o option will be roughly equivalent to what encap 
provides (except that scripts will be compiled to native code).

The main drawback right now to support direct Red script execution 
is REBOL inability to execute native code from memory. The workaround 
would be to provide a DLL to pass the memory pointer and call the 
Red code, but as I aim at a single Red binary, this option wouldn't 
be very satisfying.

I would prefer Red to compile either to the directory, where the 
source is by default or at least not to the system/options/home path, 
but to the path I get with pwd

Agreed, change done.

That's quick. Thanks

I got math ops for integers working, but I think it's time we get 
a better macro system.

quick-test has been broken by one of the last 13 commits in branch 
v0.3.0. I'll try to sort it out over the weekend.

That was under OS X, it runs okay under Windows.

So time really is running out for REBOL

quick-test is also broken on Linux.

Peter: let me know if I can help.

Very exciting to compile hello.exe on my Windows PC!

Kaj: what do you think of that? (for Red/System)

    #define MAX(a b) [either a > b [a][b]]

    print MAX(78 12)

outputs: 78

Try it the other way around ;-)

Huh! :-)

Works! (was testing in the wrong console)

That's good ;)

I take it for granted that this is just on the way to having maximum: 
max block-of-values ?

and it returns the max in maximum?

I think he's just working on macro support in this example.

that makes sense.

Arnold: it's for Red/System, not Red.

Nice features of the new macro support: 


- the replacement in the argument block operates for any block series 
(includes paths types)

- nested macros in macros are resolved


- you can define the argument as paren! instead of block!, and paren! 
will then stay once macro resolved.

Here's a more complex example:
    
    #define MIN(a b) [ either a < b [a][b] ]
    #define MAX(a b) [ either a > b [ MIN(p/a p/b) ][p/b] ]

    p: "Hello"
    print MAX(2 1)

outputs: H

(in fine, MAX(2 1) resolves to: p/1)