World: r3wp

http://www.rebol.com/r3/downloads.html

A111, 27 Feb Linux PPC, 5 Mar Amiga OS 4 and there has supposedly 
been a Linux ARM build for a while

Why on earth doesn't Carl announce/blog/tweet this? He has plenty 
to tell, but seems to be intent on letting all supporters believe 
he and REBOL are dead

#7988: post from Carl 3d ago:
I want to get back to posting status messages on a regular basis.

the question is, what means "regular basis" for Carl :)

As Dr Phil once said: "Before I die"

yes, on regular basis, but no further reply to my comment ...

Carl sucessfully burries REBOL under ...

please move your rants to a more appropriate group

I'm stuck again. To start porting the R3 graphics to Syllable, I 
need A111 with Cyphre's FreeType enhancements. Carl hasn't published 
the A111 host kit, but RMA has. However, unlike the host kit in Git, 
RMA's version has the Linux library compiled for the newer GLibC 
2.11. It doesn't run on Syllable Desktop due to a missing symbol

Unfortunately, A111 hostkits are only available for 3.1 (Win32) and 
4.4 (Linux libc6 2.11) so far.

Not that the hostkits themselves matter much, but this also means 
libr3 is only available for those two platforms.

>> m: map [a: 42]
>> protect m
>> m/a
** Script error: protected value or series - cannot modify

Known bug? Not a bug, but a feature?

I believe that's a feature, but maybe that's wishful thinking on 
my part.

A bug. Report it.

Bug #1825 "Crash in RESOLVE" (and/or #1865 "SIGSEGV when importing 
modules") are getting annoying really soon, once you try to seriously 
use R3 modules.s

I am now regularly tripping over this in my own code, and I know 
of several people who do as well.

Where are we at with R3 ?  Is it  A110 or A111 or higher these days?

I saw that Carl was going to post A111 a month or two ago ... did 
that happen?

A111 is the current version.

Available for 9 platforms (which makes it the most widely built R3 
alpha so far). Released between Feb-20 and Mar-5.

(http://www.rebol.com/r3/downloads.html)

Carl has been marking tickets as built in a112 lately.

Sorry, I meant posted to Github ...

Is there an ARM build yet?

No published one.

A111 hostkit sources where not posted to Github.

were*

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