World: r3wp

They were not even announced or published at all, but are available 
via the usual URL-guessing.

And RMA of course publishes their A111-based hostkit.

It's probably time to reactivate my Git hostkit mirror, and update 
it with those recent sources ...

official R3 a111 sources are here : 
http://www.rebol.com/r3/downloads/r3-host-kit-a111.zip

yes.. but never officialy announced.

And for Linux libc6 2.11:
http://www.rebol.com/r3/downloads/r3-host-kit-a111-44.tar.gz

Carl just posted an answer to Oldes question in R3 chat -  he seems 
to be working on  Linux embedded systems. The worrying part is, that 
he admits R3 would be fine there, but he is not using it, and also 
no mention, what's his further plan with R3 .....

He's right about REBOL fitting well in that situation. Interpreters 
are used a lot in embedded code for just that reason.

Could someone tel me where I can find out the REBOL3 VM specification 
, because I am very interesting for that , I am trying designing 
a  Forth CPU with FPGA , I hope it can run REBOL3 well also!

REBOL isn't run on anything approaching a bytecode VM. The block 
data is interpreted directly by the DO function. There is no compilation 
beyond the loading phase.

Cherngchin, consider this code:

either a = 1 [f: func [b] [b + 42]] [f: 2]
f 1


You can't define a single vm instruction for 'f' in the last line. 
'f' can be a function or a simple integer.

f: either a = 1 [func [b] [b + 42]] [2] ;would be more REBOL way:)

Hi, I roughtly watch the RedCode they are not look like Stack Machine 
, but more like Register Machine ,  a little bit like 68K Address 
Mode ,  that mean the REBOL3 VM has better performance on the RISC 
Machine , not  Stack Machine , it is right  or not ?

Red is compiled. REBOL is not, and many REBOL features aren't compilable 
to any kind of bytecode. Red won't have those features.

REBOL 3 doesn't have a VM at all.

We would of course welcome any attempts to accelerate Red on an FPGA, 
or even REBOL if you can figure out what that would mean. One thing 
to consider is that Red doesn't have a VM either. The Red/System 
compiler compiles to native code directly. In the future, Red will 
have a JIT compiler, but even that will probably be direct from the 
data structures rather than from a bytecode.

You might find that R3 could be accellerated by FPGA implementations 
of its function dispatch model, and especially action dispatch (redirecting 
to type-specific implementations of standard functions). Direct support 
for its data model might help too, for operating on blocks of value 
slots. The REBOL execution model doesn't really correspond to either 
a register-based or stack-based model, but the interpreter does have 
its own semantic model and you might be able to come up with a minimized 
core of that model that you could implement in hardware directly. 
I don't have enough knowledge of the limits of FPGAs to know for 
sure.

It would be possible to make hardware that interprets REBOL values 
directly (it would be VLIW in the sense, that REBOL values are usually 
large, ie. 16 bytes in R2), however the hard part is striking a balance 
between complexity and utility.


The simple fact that code would not be "flat" but more like a tree 
would pose a lot of issues compared to the mainstream hardware architectures.

Unlike JVM bytecodes, which were designed to be implemented in hardware, 
or CLR bytecodes, which were designed for JIT compilation, REBOL's 
semantic model was designed for efficient interpretation from the 
start, and then made more efficiently interpreted over time. A machine 
interpreter for the REBOL semantics would not really resemble the 
machine architectures with which you are familiar (maybe the Lisp 
machine?).

If you were going to be doing this in hardware, it would be likely 
that there would be some changes to the details of the data model 
to make that more efficient. However, to keep the real advantages 
to REBOL's semantic model, the core principles would still need to 
stand.

who cares the developpement is on hold Carl have better more profitable 
things to do than loose his time with rebol 3

brianH none of the non compilable programming languages was a success. 
Face it Softwares companies want to steal idea from public domain 
but don't want anyone to steal from them that's how it is. And as 
compilation hum brianH SDK is a half assed intent to hide source 
codes of rebol scripts to people common view no ? So the statement 
I'm making Carl made it like 9 years ago when he create the sdk branch...

what are the things not compilable ? list them and then we will see 
if there are of any interrest in fact, if you want to discuss  things 
come with arguments for the discussion and not

come with hum it's not possible cause the guru said so.

Carl is killing rebol for many years now you don't believe it but 
that's how it is...

Now close is R3 to first beta?  Now that Carl has a job ... it looks 
live the core development is going to be stalled for a while yet.

So close and yet so far away. It could easily be called a beta right 
now, and a release with some more bugs fixed and just a bit more 
implementation, for example in SORT

But obviously, if no progress is made towards that anymore, it can 
still take a long time

Can't sorts be done as an extension?

Yes, but that's not really relevant to beta status

I'm using a REBOL implementation

I think someone else did a binding to a sort library

Ok, I guess the question is then , how blocking is Carl's absence 
going to be ?

R3 has a real chicken and egg problem. Much work could be done without 
Carl's direct involvement but for many people Carl's work is not 
yet sufficiently complete for them to do it. (A good example being 
the work you've put into R3 schemes, Graham).


The RM-Asset team are doing a great job of making progress with R3/GUI. 
Lets hope that they can continue and don't hit some issues which 
will need a lot of Carl's time to fix.

Peter, as far as I recall, the schemes I worked on 2 years ago did 
work .. but I was waiting for Carl's promised review so everyone 
would know whether this was the way he wanted things done or not. 
 Nobody wants to have the same issue that Gabriele had of writing 
code ( VID, http ) which is then deemed to complex or hard to maintain.

In this respect ... I did not want history to repeat

In Carl's absence .. we need a project lead who is going to take 
over .. or we just do the Milton thing

If your schemes had been used for the last two years wouldnt they 
be the de-facto schemes by now?

I never completed the user interface to them ... just tested that 
the basic functionality was present.

No point in polishing them if Carl had something else in mind

The big question is where to publish them as there isn't a single 
repository for REBOL as there is for other languages CPAN, PEAR, 
GEMS etc.

Pretty much most things are now on github are they not?

I disagree with there being no point in polishing things if Carl 
has something else in mind. Code only needs Carl's approval if it 
is to be included inside the executables that he publishes.

github is popular for source code but not for distributable modules. 
Many Ruby/Gems source code can be found on github but they are still 
distributed via GEMS.

Peter, I think schemes come into that class

Nobody can take over from Carl as he has complete control over the 
source of the "core" of REBOL. Different people could take the lead 
for different "non-core" projects. Robert is taking the lead with 
R3/GUI. (Perhaps because he has a need for R3/GUI). You had taken 
the lead with R3/Network schemes.

Why do you think schemes need to be included in the executables published 
by Carl?

because people would expect to have things like ftp, smtp, pop3 in 
the distributed exe

Why? Because they were included with R2?

because http is included with r3