World: r3wp

I just wonder if R2 serial communication was cross-platform? Then 
it might be best, if Carl would release the code ...

Does R3 for Windows have DLL access? You could just use the Windows 
API to access the serial port -- http://msdn.microsoft.com/en-us/library/ms810467.aspx

This looks like a simpler start -- http://www.robbayer.com/files/serial-win.pdf

Not exactly cross platform, though

Aargh

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.