World: r3wp

Very nice. This takes Red/System a step beyond C

The only thing I'm not wild about is the print-ws name. Do you think 
something like print-wide would be too long?

Well I consider PRINT-WS already too long, but -WIDE is nicer, so 
it might be a good alternative.

I use a lot of PRIN-* functions every day for debugging purpose, 
so this new, much more powerful PRINT alternative, will save me a 
few hundred keystrokes each day (just not having to type PRIN NEWLINE 
anymore makes me happy). :-)

:-) It also reads a lot more elegant

Indeed.

In PureBasic, there are Print and PrintN functions. PrintN adds new-line 
to the end.
For Print-ws, what about Print-Form ?

we can use PrintN for single argument: PrintN "Hello" --> Print ["Hello" 
lf]

I considered PRINT-FORM but I've found it not meaningful enough. 
PRINT-WIDE is a better hint at what the function does.

I will publish these changes tomorrow morning and will bump the version 
number, as they would break most of existing scripts. I will write 
a blog entry to describe the changes.

Did you do any performance improvements? I just updated after a bit 
over a month and my SDL test, drawing a gradient, is a lot faster 
:-)

I wonder why we use lf, instead of a newline. Then we add a description 
to the doc, something like lf adds a newline :-)

LF is shorter, and newline was already defined

Did you do any performance improvements?

 I did a few small code optimizations, but they should not have noticeable 
 effects. Maybe your code relies on a tight loop that benefited from 
 them?

btw - what's the resolution re floating support in Red/System? Kaj 
is now trying to port SDL, so I wonder if for the gfx (which was 
not planned to be the RED's target),it will be the necessity,or not?

Floating point support will come to Red/System when the float! Red 
datatype will be implemented.

And float is planned, right?

Of course, there is just a lot of other feature that are much higher 
in priority.

features

Basic SDL does not require floats yet, so I have some room left to 
grow :-)

What's becoming a problem first is the lack of 16 bits integers. 
They're in structs and arrays, so I have to do trickery now to access 
them

Maybe I imagined the speed improvement. My previous experiments were 
the night before, and I don't have those executables anymore

Will Arduino support bring us an ARM support? Hmm, maybe not - it 
seems to be an Atmel, not ARM?

The small Arduinos are AVR, the bigger Netduinos are ARM

The first embryonic support for both is already done, if I'm not 
mistaken

Arduino boards use AVR 8-bit MCU (microcontroller), the Netduinos 
use a 32-bit MCU equivalent to an ARMv4 IIRC. The port for AVR 8-bit 
has started but it is still highly experimental. The ARM port started 
by Andreas targets ARMv5 architecture IIRC.

16-bit integers: Red/System does not need them, but interfacing with 
external libraries might require it, especially for struct members. 
I wonder if adding support for a int16! pseudo-datatype, only limited 
to struct members would be hard to add...Will have a look at it, 
once all the current pending tasks will be done.

as for "pending tasks" - is there any list,of what is being currently 
worked on, other than the website roadmap?

16 bits arrays also need to be manipulated, with 16 bits access and 
pointer arithmetic

Lots of external functions take 16 bits arguments. Are they 16 or 
32 bits on the stack?

For IA-32 CPU, it is always 32-bit on stack.

List of tasks: yes, on my paper notebook. They usually cover 1 to 
3 days of work and are updated frequently.

so still mostly working on Red/System, to be powerfull enough to 
write RED in?

I just wonder - if Carl would decide one day to "port" R3 to Red/System, 
would it mean, that the resulting executable would run at the target 
platforms supported by Red/System?

Mostly working on Red now (memory allocator is done, tokenizer will 
start soon), but some Red/System improvements and fixes are still 
needed.

Where you will write stuff like devices (in R3 terminology), events, 
tasking/threading, simply a native stuff? As a RED/System? Or will 
it be RED itself (will not it be slow then?) I just would like to 
understand it a bit :-)

R3 -> Red/System: not sure if it would be an advantage or not. Currently, 
from a performance POV, C is still faster. (Think about current Red/System 
as C without optimizations turned on).

The "native" layer in Red is Red/System, so almost all that stuff 
will be coded in Red/System with some interfacing layer in Red.

Aha, so Red/System is just a general REBOL/C like language. We still 
need to wrap native functionality/libraries, to get tasking, events, 
etc. Btw - do you plan to utilise liboop, libevent, pthreads libraries, 
or will you write everything from scratch/your (REBOL) way?

Tasking

 will be brought by actor! datatype which will use a pool of OS threads 
 underneath. I am not sure what you mean precisely by "events". Liboop 
 and libevent are nice libraries, but probably overkill for Red, so 
 I will implement similar low-level OS bindings specifically for Red 
 (probably merged in the actor abstraction). For OS threads, I will 
 pick up the API provided natively by each OS.

Kaj, do you have already some gfx demo to show using Red/System + 
SDL or are you preparing something for the Software Freedom Day?

Just a lame gradient, but I'm preparing for SylCon, September 3

Do you need one?

For the Software Freedom Day, any Red/System cool demo is welcome.

I'll definitely have more then, that you can show

I'm programming redshift now and I've already found fault with the 
first SDL example ;-)

You mean Redshift in Red/System?

No, in SDL in 24 bits modes

I can finally paint a pixel in any video mode, but the SDL example 
for 24 bits is broken, and I've also hit another bug in Red

Nice! Waiting for your bug report...