World: r4wp

Good point and I totally agree with that. That's basically the plan 
for Red/System v2. But, as you say, it can become quickly very costly, 
so it needs to be done carefully (needs time) and *sparingly*.

yeah but you could have different path containing different stages 
to allow fast or slow compilation (with full optimization)

My goal with the bootstrapped current version was to try some experiments, 
as all the current REBOL code will be trashed at the rewrite in Red 
stage. I wanted to see how far I could get with very simple design, 
so I can test how REBOL features can help or get in the way for writing 
complete compilers.

Also, the implementation speed factor also weighed a lot in architectural 
choices for the bootstrap code.

I could have gone by the (Dragon) book and done it in classic way, 
but that would have been a shame IMHO, to not try new approaches 
with a language like REBOL.

I think the way you've approached it so far is great Doc, though 
I haven't said much.

This coming saturday october the sixth,  Kaj will show his work (in 
progress) to get the Red Programming Language running on the Raspberry 
Pi.

http://www.hardwarefreedomday.nl/2012/Red-Rasperry-Pi.html

Please tweet this etc. if possible.

This during Hardware Freedom Day.

at the TkkrLab Hackerspace Enschede

At walking distance from Enschede Railway Station.

Entrance is free, registration required.

Great news!

Bas, the link is working but should be Red-Raspberry-Pi.html?

Too late for changing the URL (unless Bas puts a redirection).

Arnold, thanks for pointing this out.

Wrong link will now redirect to

http://www.hardwarefreedomday.nl/2012/Red-Raspberry-Pi.html

(with b)

In a near future we can hope to program our own NAO robot with Red, 
isn't it ? http://fr.wikipedia.org/wiki/Nao_%28robotique%29 or http://en.wikipedia.org/wiki/Nao_%28robot%29

Funny you're mentioning NAO, I was thinking just before starting 
Red, to apply at Aldebaran Robotics who's building them. ;-) (I was 
living not far from their office in Paris).

It runs Intel Linux, so it should be no problem, even right now

Actually, I'm using the much more affordable Robotis Bioloid to play 
a bit with robotics, Red/System AVR8 experimental port (targeting 
Atmel328) was meant to let me, not only play with Arduino boards, 
but also drive Bioloids. ;-) Too bad I don't have time these days 
to go further on that port.

Nice Doc, you could afford to get  your own robot to play with - 
and I agree it's unpleasant having to pause playing with it so long 
 - more often than we can afford to - for now, at least. Keep up 
the good work ...

I know I asked in the past, but - what is the minimal HW requirement 
for Red to be ported onto, and still being efficient? I mean - we 
were looking into Ubicom chipset replacement, and specifically at 
some PIC32 controllers, as well as ARM M controllers. I know some 
commercial development tools, which span across various chipsets 
....

The minimal requirements for Red would be something like: a 32-bit 
CPU or MCU and 1MB of RAM. 


For Red/System, a 32-bit CPU/MCU and 32KB of RAM (at least 1KB for 
stack) would be enough to run some small programs. A 8-bit version 
is still possible though.


ARM Cortex-M controllers: no problem for running on them as long 
as we implement a Thumb instruction-set backend (could be merged 
with current ARM backend).

Doc, will it be necessary or possible to have a debug version of 
Red with deep level of integration with debugging tools as well as 
a non-debug version with higher performance, or is this something 
that can be turned on/off in the same runtime?

Depend on what you mean by "debug version" and what debugging tools 
you're thinking about. My plan for Red is to deeply integrate it 
with the IDE, so that you'll be able to have advanced debugging capabilities, 
like step-by-step debugging. Such feature could maybe also be ported 
to the console version, so you'll be able to use it even without 
the IDE installed.


Also, I have thought the Red execution architecture to be as reflective 
as possible in order to try to support memory image loading/saving 
and stopping/resuming (think Smalltalk). It's very tricky (not sure 
we'll have it in the end), but if we can achieve it, you'll be able 
to get a snapshot of a running Red program on file, transfer it and 
resume it somewhere else....ideal for reproducing exact bugs occuring 
conditions. EDIT: the right expression for that is "Image-based persistence".


In the meantime, we already have some "debug mode": -d switch for 
Red and -g switch for Red/System (we'll probably adopt -d for both, 
-g will be reserved for gdb support). It's mainly intended for internal 
usage for now, the Red/System one can be useful to locate runtime 
errors in source code (usable, but still needs some fixes though).

As long as I don't have to tug the IDE around, then it all sounds 
great. :-) Sometimes you just want to spend 10 seconds installing 
Red and then quickly run a script, just like REBOL.

installing? I will break your hands, if you create an installer :-)) 
Guys, just copy & run :-)

Pekr: Red will come packaged in one binary, so no installation required 
(but we still need to offer the option to associate file extension 
with the binary, among other things).

I would like to ask about the architecture of Red. I am looking into 
datatypes directory, e.g. string. Those functions don't have any 
arguments, they seem to work with the stack directly? Strange concept. 
Are those real Red functions? But what I don't understand is e.g. 
'back function, its body contains block/back. Where does "block" 
come from? It is not passed as an argument, so is that any kind of 
system wide value?

There are dispatcher wrappers in actions.reds

block

 it's a context, the one that contains all the block! datatype related 
 code.

Yes, all actions and natives work from the stack. Sometimes they 
are just wrappers other equivalent functions that pass arguments 
in a classical way, so they can more easily be called internally 
by other parts.

Strange concept

 It looks pretty classic to me, but there are some specific reasons 
 behind such choice, that I will detail them in a future blog entry. 
 Basically, it simplifies the tracking of Red values on stack (making 
 the work of the GC easier) and stack serialization becomes almost 
 trivial (to memory, for continuation support, or to file, for image 
 support). I think that R3 doesn't do it that way, but probably uses 
 recursion, passing all R3 values on C stack instead. It's a faster 
 approach but less flexible.

Kaj, I just watched your talk. It was great, but you can probably 
benefit by putting in a diagram or two, showing the relationship 
between REBOL, Red and Red/System.

Thanks. I know, I'm low on glitz. It's because I don't want to take 
the preparation of those talks more time than they already do. I 
prepare by making sure that as much as possible works, and then I 
do a guided tour of it on the machine itself

It's the same reason why I have written only limited documentation. 
I have to prioritise my time to do the things that I need myself, 
and I don't need the documentation and the presentations that are 
a goal in themselves

R2 and R3 use their own stacks, though recursive PARSE may use the 
C stack. The stack frames of R2 and R3 are different, but I wouldn't 
be able to tell you how.

Nenad, a small donation from me via Paypal underway.

Thanks Arnold, all donations count and are much appreciated. I'll 
see what we can do for "numbers representing money", but anyway they 
will be less flawed than in REBOL (no approximated internal representation). 
;-)

binary coded decimals?

Red numbers mean you are in debt, that's not what we want is it ;-)

cheers!

This is the plan for handling numbers with decimals:

- decimal!: BCD
- real! or float!: floating point numbers

- money!: BCD or just integer with a scaling of 100 on input/output.

Arnold: got it...now! ;-)

Pekr: your remark about the stack made me think about it. I might 
change a bit the current internal API, collecting arguments from 
stack in trampoline functions (actions.reds) instead, and then calling 
datatypes-specific actions passing them the arguments directly. This 
would reduce the runtime code size a little bit and might simplify 
the construction of the future public API. I need to see first if 
they are drawbacks before deciding to refactor the code in that way.

Those functions don't have any arguments, they seem to work with 
the stack directly? Strange concept. Are those real Red functions?


They are Red actions (the datatype "methods" if you prefer). Polymorphism 
support is implemented through a dynamically created actions jump 
table. If you really want to see how this internal API works, just 
compile small Red test scripts with the -v 1 option (-v 2 will also 
give you the generated output of boot.red compilation).