World: r3wp

There is a good reason not to be in the specific case of system/contexts/user: 
RESOLVE overriding. So this is an example of the "unless" part :)

That is not exactly what I had in mind. (especially when taking into 
account, that the usage of RESOLVE does not need to be considered 
"initialization") What I had in mind was, that:


1) there are two different values used to initialize variables: #[unset!] 
and #[none!]

2) because of that, the situation cannot be considered "consistent", 
unless one of the above values ceases to be used for initialization 
purposes, no matter whether we move some of the variables from the 
category of "initialized to #[unset!]' to the category of 'initialized 
to #[none!]'

Moreover, the local words in functions (I mean function arguments) 
actually are not initialized to #[none!]. The only observation that 
is true is, that after a function call, and only when the corresponding 
refinement is not used in the function call, the corresponding "refinement 
variables" are set to #[none!] - notice, that I intendedly did not 
use the notion of "initialized", since the function variables (do 
not confuse with closure variables) "exist" even before a function 
call is made in a sense, that can be easily demonstrated.

Carl went alive in the R3 Chat, stating he would like to once again 
start posting status messages more frequently now. Let's hope :-)

Does anyone know about some cross-platform decent serial communication 
library? I miss serial port in R3. We are playing with some devices, 
and serial communication is still being widely used method. We could 
ask Carl to release it for R3, or just map some existing open-source 
library as an extension. I could start bounty on that ....

Pekr, are you on Windows or Linux?

Windows. But I expect Linux, ARM, BeagleBoard, etc :-)

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.