AltME groups: search

You're talking 	about Red/system not Red

Uh, what optimisations, Kaj? We are talking Red bing compiled to 
Red/System, so how comes, that the result is only 2 times faster 
than R3? I expected speed of nearly a R/S version. Something must 
be wrong, or Red would not make sense with such poor performance 
at all imo ...

You can get Red/System speed if you write in Red/System, not if you 
write Red

Those high-level layers are what makes Red able to accomplish all 
the things you like instead of being limited to a macro-assember 
level language (like C or Red/System).

Actually, the Fibonacci function should run very fast in the target 
(optimizing) compiler as there are only math expressions and the 
whole body has Red/System counterparts, so in the target compiler, 
it should run half-way from R3 and Red/System performances.

The "RT-like product" separation wouldn't have much meaning in Red 
where you can build your  executables with whatever modules you need. 


We'll define a common "extension" standard (probably based on module! 
datatype) that all third-party modules will implement, so that your 
app could easily use any modules at a cost of a simple "import" directive. 
Such extensions will be typically coded in Red, but with all the 
low-level options, like Red/System routines and bindings to external 
libs.


Moreover, you'll have also the alternative option to build everything 
in a single binary (including third-party libs if they can be statically 
linked). Such thing is impossible in R2 or closed-source R3. In  
 open-source'd R3, you'll be able to do that too, but you'll have 
to get your hands dirty by implementing the bindings in C and using 
a C compiler to produce the executable binary.

I understand that the 2 times faster than R3 includes the compile 
of the Fibonacci program? 

No the performance of the Red program is a bit dissappointing at 
a first glance for the programsource is not very different from that 
in Red/System?

Similarity between the two is not so easily related, as Red is more 
dynamic than Red/System.

I gave the topic of the "speed" more thoughts, and though I am very 
uneducated in lower level internals and language designs, I think 
that I might have more understanding, why I can't think about Red 
being just a compiler to Red/System in a 1:1 manner. In such a case, 
Red would not be needed. What needs to be included in the final exe 
is kind of "engine", supporting stuff like GC, all the dynamic things, 
type checking engine, etc etc. 


When I ask myself, if I am willing to exchange dynamic stuff for 
speed, I say - no, at least not necessarily. It was just that I got 
trapped by first R/S performance tests, and thinking that if Red 
compile, it has to be almost that fast too.


As for waiting for 1.x and possible optimisations - I don't believe 
optimisations can change things drastically, at least non in order 
of a magnitude. But - we will see.

Pekr: there are several layers at which optimizations can be applied. 
With an optimizing Red/System compiler, you'll already get an overall 
x2-4 boost. Then optimizations at Red level can bring us another 
boost (runtime code can be optimized, compilation output can be optimized 
to be closer to 1:1 with Red/System, when possible). The end result 
should give us, on average, a x10-20 boost over R3. I am pretty confident 
that this can be achieved, given the current results.

Will also "self-hosting" - rewrite of Red/System in Red, help too 
in that regard? Or is that unrelated?

Almost. It doesn't "replace" the word in all contexts, it registers 
another spelling for the word in the place where word symbols are 
stored, then when you refer to the word with either spelling it will 
point to the *same* word.
However, if you write code like this: alias 'print 'stampa

then that code, just by being loaded, creates two words in the user 
context with those two spellings. So when the ALIAS function links 
the two spellings then there is a conflict in the user context, where 
"stampa" refers to both the word 'stampa and is an alias for the 
word 'print and at runtime you can't really tell which word you mean. 
If the system resolves this conflict by resolving to the alias then 
you have overriden the original word, which makes ALIAS a security 
exploit. If it resolves to the original word then ALIAS simply doesn't 
work. Either way, the function needs to go away ASAP.

(Sorry Doc about the off-topic stuff) And open-source forks that 
try to alter R3 to make ALIAS possible again will thus be that much 
less stable ond secure, so it will be an argument against their use. 
ALIAS is hostile to the R3 system model, and everything it might 
be a good idea to use ALIAS to do in R2 can be better done with other 
methods in R3.

Right. As opposed to ALIAS, which can bring your system to a crashing 
halt, if you're lucky; if you're not lucky it will fail silently 
and stay a security hole.

Anyway, I increased the parameters of both Fibonacci and Mandelbrot 
to have a better benchmarking range for fast languages, such as Red/System

With this parameter and a more exact comparison, Red/System is 70 
times faster than Red

I will happily allow people to use ALIAS on my Try REBOL server, 
just like I'm allowing most other REBOL features, because the server 
operating system is the party that establishes safe boundaries

On Mandelbrot with 50'000 iterations instead of the standard 1000, 
Red/System is 80 times faster than R3

I have just uploaded a basic script to generate Red/System API docs 
to Github. It could do with a lot of polishing, perhaps you could 
take a look?

Red/System API Docs ... Just what I need, Thanks, Peter. :-)

I would like to report a bug in red-system. I would prefer not to 
register myself anywhere. Which is the simplest way ?

red-system question:
How can I create a simple array of constants?

I am trying to write a test red-system program but it is a pain:

I write it in my editor, then open a Rebol console and do change-dir... 
do/args ... then:

If I open a window console and run the program I can not compile 
it anymore (it is locked by the console?), and if I try to run it 
in Rebol with call/console ... it hangs. Which is the right method?

If you have no loop in your code nor system calls that might block, 
you could try disabling your anti-virus program to see if that's 
not the one interfering.

In C/C++, A file which might be included by other files would likely 
start with "#ifndef _OOXX_H #define _OOXX_H" and end with "#endif". 
How would I do that in Red/System? Thanks.

Red/System will only include a file once no matter how many  #includes 
it encounters.

The "step in the middle" is the compilation of:

- the Red/System code generated from Red code (user + boot script)
- the whole Red runtime code (in Red/System)
- the whole Red/System runtime code (in Red/System)

The current "slowness" is caused mainly by:
1) all the runtime parts being recompiled for each user script
2) REBOL relative slowness

The cures are:

- for 1), precompile runtime parts, and recompile them only on changes

- for 2), Red self-hosted compiler will give a good boost (x10 is 
my target)


Also, the self-hosted Red and Red/System compilation speed will be 
improved compared to the current versions. In the end, we should 
have very fast static and dynamic compilation, the target to reach 
for the JIT compilation mode is less than 100ms for short scripts, 
typically, most functions should compile under 10ms.

VID-like: definitely. Not only because it is a simple and efficient 
way to build GUI, but also because it nicely shows the power of dialecting, 
applied rightly, so it "validates" the whole concept behind REBOL 
and Red. 

I was planning two approaches:


- prototype a VID dialect for cross-platforma native GUI once we 
have the right interfaces between Red and Red/System. (That part 
will include also mobile platforms, if possible, else, they will 
have rely on a mobile-oriented GUI dialect). I will probably start 
to play with it around Christmas, and try to reach an alpha/beta 
in Q2 2013.


- prototype a VID dialect for HTML frontend, having GUI frameworks 
as backend targets (Sensha, jqueryUI,...). The hard part here is 
abstracting the client-side coding, Topaz would be great for that, 
if Gabriele can find time to continue working on it. Else, I will 
need to work on my own Red to JS compilateur.


It would be also nice to have a wrapper over R3/View or a Red/System 
port of it, but it would need contributors to take it in charge. 
There are also more possible GUI options.

Now after observing development of several GUI systems, there are 
always some particular things I find wrong with them: They were designed 
with small details in mind rather than the big picture. This means 
that when a developer uses a GUI system, he'll find that some things 
are easy, while others are very hard. For example, none of our GUI 
systems are particularly designer friendly, meaning that building 
a skin requires a programmer with artistic skills. There are not 
many of those around and that's a real problem. Saphirion's R3 GUI 
was derived from Carl's work in a way, where several parts were rewritten, 
because they didn't scale enough for real-world GUIs. The rest of 
the work has been about beefing up the R3 GUI to handle what is needed.


Development often seems to go in isolated sections: Building styles, 
building a layout engine, event handling, skin system, animation 
or whatever, without a properly coherent view on the whole thing. 
We talk about how we have a really nice feature, but that feature 
may not mean much, if it's not functioning in a coherent way with 
the rest.


If I were to restart VID Ext Kit as a new GUI system, I would rewrite 
it top down: Start with an application with the simplest, purest 
GUI description and write the GUI system down from there. I would 
recommend that a GUI system for Red needs to be written like that, 
starting as early as possible and let it grow downwards instead of 
upwards with a real application in mind rather than some neat demos.

In short: Write apps and pretend we have a complete, perfect and 
luxurious GUI system with no work-arounds. Then write that GUI system.

red-system question:
which is the difference between pointer! [byte!] and c-string! ?

It would be great if the GUI system used a combination of vector 
and bitmap rendering for widgets. Vector drawing could be used for 
initial drawing or when a GUI was re-sized. Thereafter, the widgets 
could cache their bitmap (if so configured). Maybe I'm stating the 
obvious and this is already how things are planned to work.

Henrik:I agree with your way of thinking, that is the kind of pragmatic 
approach I take often too when designing any dialects or even APIs. 
For the Red native GUI system, I will prototype it with the first 
big Red app I plan to write: the Red IDE.

also the help system can be sent to a wiki

Well, as for me, it is easy as that - f*ck off native controls :-) 
What does that really mean today? I have really no intention seeing 
GTK or other crap. Either use your own GUI, or HTML, that's almost 
the only standard, which will prevail anyway. We should ask ourselves 
- how relevant is e.g. the Gnome GUI guide? And who cares in the 
big picture? So - for easy embedded stuff, just give me a small GUI 
system, for bigger picture, give me a  HTML5. I e.g. don't understand, 
why Kaj tries to port something like Enlightenment. I really miss 
the big picture. Who and why should ever use it? For personal purposes, 
or some specific stuff - why not, but that's not imo a strategic 
direction ...

I would never want my app to look like GTK, easy as that. Maybe because 
I have zero intention to do Linux native GUI app. Linux, in a big 
picture (desktop), is irrelevant. Alway was. Who claims otherwise, 
lives in separate reality :-) Mobile will prevail classical PC sales 
very soon (if not already). Own GUI, for small niche, might be good. 
But - it has to have attractive design. The situation with Saphirion 
was, that the substantially rewritten Carl's engine. Nice enhancements, 
resizing and other stuff. But I NEVER understood, why the look was 
so totally unattractive. You see, Henrik once again claiming the 
old stuff, which was the basic reason of a failure. Design is a separate 
animal, which was supposed to come later, which could be done by 
anyone, which "just" needs material system which never appeared, 
etc. And result for me (as a sigle person)? Carl's GUI desing attracts 
me by some 60% more, just because of look. Once again - look sells 
...

which 

just" needs material system which never appeared, etc." - the material 
system should be included in the current Saphirion release.

...for easy embedded stuff, just give me a small GUI system, for 
bigger picture, give me a  HTML5


So what do you propose for the GUI, that will allow it to look good? 
i.e., what is your constructive suggestion, rather than criticizing 
all the wrongs of the past.

How many of us would ever need to do a real native Linux app?


We are talking about a cross-platform GUI framework, that means: 
write once, run everywhere. Using native widgets from the OS is an 
option, using custom ones (with non-standard look'n feel like /View) 
is another option. So, you write a Red GUI app on whatever system 
you like and your Linux users will be able to run it.

It's hard to imagine that the native UI interface would meet with 
criticism from any main stream developers - by definition, it's the 
_native UI.  Doing things that way just takes longer to port.  I 
honestly don't care which way it goes, as long as there's a usable 
GUI system with a _productive syntax_.

That is, if Doc creates your dream GUI system, what is it?

Gregg - I will see how Red evolves in regards to events etc., so 
that later on I can have someone look, how difficult would it be 
to port View from R3 to Red/System. AGG is just platform agnostic 
(I think), then there's a windowing system, maybe not so difficult, 
but Doc might have some other plans for events, etc.

I can do this in C, define something based on another defination 
=> #define a 0 #define b (a + 1) ... Can I do the same thing in Red/System?

Hun, So we did can do that in Red/System ... Thanks, Peter.

It even works if b is defined before a:

Red/System []

#define b [a + 5]
#define a 10

print [b lf]

Arnold: I think that FUNCT is an interesting function constructor, 
but has a horrible name, and as FUNCTION is rarely used, I thought 
it would be good to make it act like FUNCT, it will be easier for 
newcomers and look less awkward than the truncated FUNC name. Also, 
we might want to make FUNCTION act the same way in Red/System (I 
don't remember if there was some show-stopper for that).

It is in my plans since the beginning to support internal profiling 
feature for Red, though I was thinking about processing them in the 
IDE mainly. In the Red/System v2 specs, I have already made some 
provision for low-level profiling of native functions.


I know about DTrace but never used it. I would need to study how 
it implements probe points to see if same technic could be used internally.


Currently, it would be quite easy to add a profiler to Red layer, 
it would just need to extend the stack/mark*, stack/unwind* and stack/unroll 
function to collect the data. But as we have other high-priority 
features to implement first, it will probably wait a few months (unless 
someone wants to implements it, I would be glad to give the basic 
hints on how to achieve it easily).

Doc, Is is possible to support something like VFS in SQLite (http://www.sqlite.org/c3ref/io_methods.html), 
So we (OK, me) can develop a simple RDBMS on Red, instead of doing 
it using Red/System

I'm not sure what you mean exactly by "support". I haven't implemented 
yet the interface for cross-access between Red and Red/System. A 
minimal interface will probably appear in the next weeks.

That VFS is about the file system interface. Do you want to write 
your own RDBMS on top of it, or do you want to use SQLite?

Lowercase letters are not allowed in hexadecimal literals (both in 
Red and Red/System), so ffffffffh is not a valid syntax. 0x prefix 
is colliding with pair! syntax, so you can't tell if, e.g., 0x13 
is a pair! or an hex literal.

I have found an issue with word! value casing in Red. The Red/System 
code generated for:
	print 'a = 'A
is:
          stack/mark-native ~print
          stack/mark-native ~strict-equal?
	word/push ~a
          word/push ~A
          natives/strict-equal?*
          stack/unwind
          natives/print*
          stack/unwind


The problem is that Red/System is case-insensitive, so ~a and ~A 
are the same variable. So, no way to make it work like that. I see 
two options for solving it:

1) Make Red/System case-sensitive.

2) Deep encode each Red generated symbol to distinguish lower and 
uppercases.


Solution 2) works, but it makes symbol decoration operation very 
costly (each symbol letter is prefixed with a sigil for lowercases 
and another one for uppercases). The example above becomes:

          stack/mark-native ~_p_r_i_n_t
          stack/mark-native ~_s_t_r_i_c_t_-_e_q_u_a_l_?
          word/push ~_a
          word/push ~-A
          natives/strict-equal?*
          stack/unwind
          natives/print*
          stack/unwind


So, it is not nice, it doubles every Red symbol size that is handled 
by Red/System and slows down Red compilation by 25%.

So, my questions are:
a) Does anyone see another cheaper solution to this problem?

b) In case of option 1), do you have anything against making Red/System 
identifiers case-sensitive?

Hm, I like that Red/System is case-insensitive like REBOL, so I would 
consider it an offer to have to let go of that

Anyway, I don't think we use different casing for identifiers in 
Red/System. Even in REBOL, I don't remember ever using same words 
with different casing in the same app.

Case-sensitivity could trip up a lot of REBOLers. I know this is 
Red/System, but still. You may also find that people treat it as 
a feature and start giving things names that differ only in case, 
as happens in C.

What are the biggest downsides to having Red/System remain case-insensitive? 
That is, what does case sensitivity buy us?

In REBOL, 'a and 'A are aliases of the same symbol. Red/System converts 
them to their integer identifier, right? I'd say you need different 
identifiers for aliases somehow to implement the REBOL semantics 
of distinguishing equal? and strict-equal?

In REBOL, 'a and 'A are aliases of the same symbol. Red/System converts 
them to their integer identifier, right?


Symbols have two representations in Red compiler, one is at runtime 
(like in REBOL), the other is a compile-time, in the form of Red/System 
variables. In a very early version of the compiler, I was using integers 
(indexes in symbol table) instead of variables, but quickly realizef 
that it was obfuscating the generated Red/System code a lot, making 
it difficult to debug. Also, the integer approach had an additional 
runtime cost at it required to make an array access in order to retrieve 
the symbol value.


Currently, the Red/System ~<name> variables directly point to a word! 
value version, instead of a symbol! for simplicity and efficiency.

I have implemented a compile-time aliasing system for same words 
but different casing. It works fine so far and is cheap compared 
to other options (it requires a conversion table (symbol->alias) 
to be maintained during the compilation).

What are the biggest downsides to having Red/System remain case-insensitive? 
That is, what does case sensitivity buy us?


Good question. I think it doesn't buy us anything nor does it remove 
us any useful feature. Actually, I think that as long as you are 
consistent in the way you name your identifiers (variables, functions, 
contexts,...), you are case-neutral. So, having Red/System case-sensitive 
wouldn't change anything for me and I guess it would be the same 
for others.


Anyway, I prefer to keep it case-insensitive for now, for the sake 
of consistency with Red, unless I really need to change it.

I haven't implemented EQUIV? yet, I'll look at it when we'll have 
a complete IEEE-754 support (we are missing INFs and NaN handling 
in Red/System).

Red 0.3.1 released: http://www.red-lang.org/2012/12/red-v031-functions-support-added.html

- function support
- path get/set notation support
- refinement support for native functions
- expressions in parentheses compilation

- new datatypes: function!, paren!, path!, lit-path!, get-path!, 
set-path!

- new actions and natives: find, select, copy, reflect, type?, halt,...

- extended mold, form and comparison operators to all new and existing 
datatypes
- many new mezzanines functions

- modulo and remainder operators on floats implemented for ARM backend
- Quick-Test testing framework ported to Red
- a truckload of new unit tests
- many bugfixes
- about 200 new commits to the Github repository
- updated Red/System formal description document

Red/System Question: In Struct A, there is a menber which points 
to struct B. In Struct B, there is a member which is a function pointer, 
whose parameter is a pointer to Struct A. ... How can I do this in 
Red/System. This is not a fiction case. I am studying SQLite surce 
code, struct sqlite3_file and struct sqlite3_io_methods are exactly 
like this.

This any help?

Red/System []

a!: alias struct! [
  a1  [integer!]

  a2  [integer!]            ;; this is used to hold address of struct 
  b
  a3  [integer!]
]    

f!: alias function! [s [a!]]
f: func [s [a!]] [print [s/a1 lf]]

b!: alias struct! [
  b1 [f!]
]
  
a: declare a! 
b: declare b!


a/a1: 5
a/a2: as integer! b 
a/a3: 0
b/b1: as f! :f

foo: as f! b/b1           
foo a

Jerry: if I understand correctly, what you want to achieve is:

    Red/System [ ]

    structA!: alias struct! [
        p [structB!]
    ]

    structB!: alias struct! [
        fun [function! [a [structA!]]]
    ]


As is, it won't compile in Red/System as structB! is not yet defined 
when defining structA! (and the compile is making a single pass only, 
so can't look ahead). 


The workaround is to define `p` as integer! and use type casting 
when accessing it.


Also note that if you reverse the order of definitions and start 
by defining structB!, you could use the same workaround for `a` argument 
type (define it as integer!, then apply type casting when appropriate).

I have added a new function type today: routine!. It allows to write 
a Red/System function in a Red program. The compiler will marshal 
(or type-cast) the arguments back and forth automatically.

Here is the Fibonacci example rewritten as a routine:

Red [ ]

fibonacci: routine [
    n          [integer!]
    return: [integer!]
][
    either n < 2 [
        n
    ][
        (fibonacci n - 1) + (fibonacci n - 2)
    ]
]


The function body is Red/System code, so it will run at full Red/System 
speed.


Integer! and logic! values are converted automatically, other Red 
datatypes are passed boxed but type-casted as Red/System counterparts 
(as defined in the Red runtime). Hint: floats will be converted automatically 
too.

So, passing and processing a block! series would look like this:

Red [ ]

add-one: routine [
    blk       [block!]
    return: [block!]
    /local value tail int
][
    value: HEAD(blk)
    tail: TAIL(blk)
	
    while [value < tail][
        if TYPE(value) = TYPE_INTEGER [
                int: as red-integer! value
                int/value: int/value + 1
        ]
        value: value + 1
    ]
    RETURN(blk)
]


I haven't yet released the code, it needs a bit more work, it should 
be ready by tomorrow.


The purpose of routine! datatype is to provide access to ultra-fast 
and low-level code for Red program in a simple way. The design is 
not yet fully set in stone, so suggestions and comments are welcome.

That's cool, it's something like rebcode.

How about something like having a block of Red/System code inside 
Red code?

System [...some R/S code...]

Endo, what you want is described in Section 17 in the Red/System 
Spec   http://static.red-lang.org/red-system-specs.html#section-17

In C, struct astruct { char c; int values[3]; }; How do I write this 
in Red/System? Thanks. It's the integer array which confuses me.

There are no arrays in this bootstrap version of Red/System. So you 
have to manage this with a pointer:

Red/System []

s: declare struct! [
  c  [byte!]
  i1 [integer!]
  i2 [integer!]
  i3 [integer!]
]

; intialise the structure
s/c: #"a"
s/i1: 1
s/i2: 2
s/i3: 3

;create a pointer and point it at the first integer
i: as integer! s

i: i + 4                          ;; set i to address of first integer
ip: as pointer! [integer!] i

;; add the integers
sum: 0
count: 3
until [
  sum: sum + ip/value
  ip: ip + 1
  count: count - 1
  count = 0
]

print ["The sum of the integers is " sum lf]

There is a probable issue with value alignment as explained in http://static.red-lang.org/red-system-specs.html#section-4.7

I'm not sure how to handle "packed" stucts in Red/System.

That's cool, it's something like rebcode.

It has a broader range of usage and it's faster than rebcode.


How about something like having a block of Red/System code inside 
Red code?

System [...some R/S code...]


This is already implemented since a while in form of a Red compiler 
directive: #system [...]

There's not much that can be done currently for #define, you can 
use #enum instead to workaround it in such cases. 


Anyway, we will need to rethink the preprocessor in Red/System v2, 
and if possible, remove it. It has been added at the beginning of 
Red/System because Red was not yet there to provide a higher-level 
macro system. Now that Red is alive, we could start thinking of a 
better alternative to the current Red/System preprocessor.

It would have to be something that can be processed by Red but still 
able to generate stand-alone Red/System

I would like to get rid of it, for many reasons. Firstly because 
it was not meant to be part of Red/System, but added later for practical 
needs, secondly because Red/System code could be built/composed more 
efficiently from Red.

In other words, we need some kind of Red wrapper (or maybe dialect) 
on top of Red/System to make it easier to construct programmatically.

Kaj, just a remark about Red and bindings: there is still  an additional 
feature to come that will allow to import both Red/System and external 
libs functions directly in Red in a declarative way. It will use 
almost the same syntax as #import in Red/System but will convert 
the datatypes automatically (in the same way R2 does with routines 
and structs). A struct! datatype would then be added also to Red. 
The routine! datatype primary purpose is provide a way to write ultra-fast 
code and enable system programming, even if it can be also used to 
wrap Red/System bindings. I'm still unsure which approach would work 
the best for building bindings to C libraries. I guess you'll be 
the first to find out. ;-)

Red/System Question: In a function, a local variable v1 is declared 
as struct! [ v2 [integer!]  ]. Once the function is called, v1 is 
in stack, v2 is in heap. When the function call is over, v1 is gone, 
but v2 is still in heap, right?

Doc, thanks for the heads-up. I'm also unsure which route to go, 
but I want to have the option to write Red/System only programs, 
so I guess I will usually build a Red binding on a Red/System binding

### Red/System Question ###
To get cpu count, I can do this in C:
   
   sysctlbyname("hw.ncpu", &cpuCount, &len, ((void *)0), 0);


But Red/System doesn't support &. How can I do this in Red/System? 
Thanks.

Red/System Questions:


I am translating a piece of code from C to Red/System, I don't know 
how to translate the following C code:


success = OSAtomicCompareAndSwapPtrBarrier(NULL, newzone,  (void 
* volatile *)&_zone_); // C

my problems are: 

1. In Red/Sys, _sqliteZone_ is a struct! (which is a pointer in Red/Sys), 
so I cannot use :_zone_ to get it's address.
2. "(void * volatile *)" in C => "as byte-ptr!" in Red/Sys ??

Thanks!

1) Is _zone_ a struct or a struct pointer? If it is a struct, then 
in Red/System, you just pass the struct! variable.

2) Correct, use "as byte-ptr!" in such case.

Speaking about atomic operations, any thought to get them in Red/System? 
I could use them well

Red/System integer! operations are as atomic as the CPU permits.

Red/System maps its datatypes as closely as possible to the CPU (the 
same way C does).

http://syllable.cvs.sourceforge.net/viewvc/syllable/syllable/system/sys/include/atheos/atomic.h?view=markup

Ok, I see what you mean. Like in C, you can already write "thread-safe" 
code in Red/System by using only variables on stack. If you need 
concurrent access to global variables, usually, the OS are already 
providing some API for that (locks, semaphores, mutex,...). I haven't 
chosen yet how it will be implemented at Red/System level, there 
are different options. For example, it could be handled by the language 
directly using a similar construct as in Java:

    synchronize [ x: x + 1 ]


In my early design notes, I have researched only how to handle concurrency 
at Red level, I've left the underlying Red/System part as an "implementation 
detail". I plan to start working on it after I/O will be implemented.

I'm thinking about  the case where you want to implement operating 
system level code yourself. For example, I have been fixing many 
bugs in Syllable's PThreads implementation, but I would like to replace 
it with a Red/System implementation. PThreads adds quite a few constructs 
that Syllable's kernel primitives don't implement as such, so to 
add them you need to write extra concurrency code

Modern CPU usually provide a way to make such atomic operations (e.g. 
CAS-type  instructions), Red/System might provide access to them 
if it is required.

In current Red/System, there is no break/continue keywords (for loop), 
I wish they will show up in Red/System 2.0

Is the intepreter written in Red/System, or in Rebol?

(Red/System or Red.)

Red/System

Yes, RSharp works well in the little test I did here (until I did 
PRINT MOLD SYSTEM/WORDS). :-)

A partial system object was even present.

I didn't need native/action tables until now, the interpreter made 
me add them sooner than I planned. Extending Red with new natives 
is already possible using simply routines. For new dynamically added 
datatypes , it will be soon possible too at Red/System level and 
with an appropriate interface, from Red directly (with routines when 
needed).

And my "remerciements" have to go to every direct and indirect contributor 
too (Carl S, KaJ, Peter, Andreas, Ladislav, BrianH, Nick, Maxim, 
Pekr,  Jerry, many guys of the French and other international communities 
too ... name them - there's too much to name all of them without 
leaving someone behind). My best wishes to you all Gang- you're forming 
an exceptionally tight and prosperous team. Your tools are the best 
I saw for being productive and easyness of use. Let's the Red/Red-System 
combination, to be the future C language replacement as the new World's 
low/high level language mix of choice.  Not to be without mentioning 
the REBOL and its loyal followers too (many of the same Red contributors 
but many more like Robert, Cyphre, Henrik ... and many others which 
have found their way while we were waiting for R3 to become open 
source, like Gabriele, Geomol ... - without which we would never 
be here now.

Kaj: congrats on the first binding made available to Red! :-)


I've noticed in %examples/do-sql.red the comment for #include:  "FIXME: 
#252". Actually, #252 is for Red/System, Red  implements its own 
#include which behaves differently than the Red/System version. I've 
tried to make it more intuitive, but it still needs some adjustments, 
so feel free to open new tickets about that (with simple concrete 
test cases I can reproduce). 


Also keep in mind that #include at Red level is intended to be a 
temporary feature until we get DO, LOAD and READ working with files. 
I would like an include system that could work both for the interpreter 
and compiler without having to change any code. I'm not sure this 
is achievable, so in worst case, we'll keep #include as fall-back.

I think SQLite-binging was misplaced in "Red/System contributions" 
Section in Red-lang.org. It's Red not Red/System. ... Good to know 
that SQLite Binding is done. Thanks. Kaj.

Until ten minutes ago it was a Red/System binding. :-) Now it's both 
a Red/System and a Red binding, built on top of the Red/System one