World: r4wp

For 1., you can achieve it this way:

    s: declare struct! [n [integer!]]
    p: declare int-ptr!
    p/value: as-integer s

then `p` becomes a pointer on `s`.


I might extend get-word syntax to struct! and pointer! too, someone 
just needs to add a ticket to Github to remind me of that.

Thanks, Doc

I usually solve such double references by wrapping the needed pointer 
in an extra struct. See the *-reference! types here:

http://red.esperconsultancy.nl/Red-common/artifact/aad3c29d7fb6647bb1e5d8b404d05211f5ed33c1

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

Perhaps an atomic! type for an integer with guarantees about the 
generated code?

What are the chances that current integer operations already have 
atomic behaviour?

I'm not sure what you mean by "atomic operation"?

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).

Re atomic operation: atomic "x: x + 1", for example.

Atomic means safe from corruptions by other CPU cores accessing the 
same memory

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

These become vital when you start doing multi-core concurrency

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

For example, there are spinlock-like constructions in Syllable's 
PThreads implementation that can often prevent having to call a kernel 
mutex. This makes them much more efficient, but you need atomic operations 
on access flags and counters to implement the user-space spinlocks 
and mutex shells

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.

Something like that is what I have in mind. From what CPUs on are 
they supported?

From a quick googling, I've found:


- x86: CMPXCHG (compare and exchange) is supported from 486. LOCK 
instruction seems to be available from PentiumPro only.


- ARM: Starting with the ARMv6 architecture ARM has the LDREX/STREX 
instructions that can be used to implement an atomic compare-exchange 
operation.

So it would bump Red's requirements a little, but I guess it's worth 
it

http://en.wikipedia.org/wiki/Compare-and-swap

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

So how can I break/continue a loop now?

BREAK will probably be implemented before 2.0 (not sure for CONTINUE). 
So, you can't break from a loop currently. 


As a workaround, you can EXIT/RETURN instead. So if you write your 
loop in a separate function, you'll get similar effect as with BREAK.

I'm a bit late for the Xmas release, sorry...still fixing bugs...

I thought we already had a Xmas release :-)

Actually, it is not really a new release, as I did too many changes 
and it would need a week at least to stabilize and fully complete. 
But it will be a significant revision. ;-)

revision = commit

I've stressed the current Red runtime source code a bit so it keeps 
"tilting" as I try to make it work. :-)

Doc, will you spend some time making Red/Sys support loop BREAK/CONTINUE 
in the near future? or at least GOTO. Thanks. Programming without 
them is like drinking soup without a spoon ...

BREAK is on my todo list. I might add CONTINUE too. GOTO could be 
useful for implementing fast FSM, but having some specific feature 
for FSM support would probably be a cleaner option than GOTO.


I personally very rarely need BREAK/CONTINUE, their usage depends 
on your programming style and the way you implement algorithms.

There are many way in which break and continue are being used amongst 
the different programming languages, most notable in case or switch 
statements.

BREAK in CASE/SWITCH statement is IMHO a very bad design choice leading 
to countless bugs. I'm glad Red and REBOL are doing it the right 
way.

Xmas feature teaser: http://t.co/jTYwNzfb

Implementing that feature revealed a few deep bugs in the current 
Red runtime code, I hope to be able to finish fixing them by tonight.

great stuff :-)

Console support! I'm waiting for it impatiently!!

BREAK/CONTINUE: I had to use those a few times in REBOL, it would 
be nice to have CONTINUE in Red too.

Awesome Doc!  Didn't expect to see a console so early.

It's a full REPL, so it's an interpreter + console. I was thinking 
about adding an interpreter since this summer in order to fill the 
gaps until the JIT-compiler will be there. Even when Red will gain 
JIT-compilation ability, for dynamic code with no loops, interpreting 
the code will be faster. Also, on some platforms, JIT-compilation 
is not allowed, so the interpreter will be handy to workaround those 
limitations.

Now, you have a better picture about the "full-stack" approach of 
Red language. :-)

The console is currently just a Red script, once we get devices and 
ports, it will be replaced by a proper console:// port.

This will make it much easier for everyone to pick it up and experiment 
quickly and easily.

It still misses a lot of features, but I think it could be fairly 
complete (on par with Red compiler) in early January.

I guess all this means we have to think a bit more about how to benchmark 
things rather than simply profile code pieces directly in the console?

Right, if you bench from the console, currently, you're just measuring 
the speed of the interpreter. When the JIT will be there, loops from 
the console might get JIT-compiled, so it will be even less relevant 
to bench from the console. My plan since the beginning is to add 
a profiler to Red, so you'll be able to make precise comparisons 
whatever way the code is run.

Great progress Nenad.

oh man, console, wooo hooo :-)

so, what does it mean, in R/S and Red scenario, that console code 
is "interpreted"?

Yes REBOL and Red do case/switch right way agreed!