World: r4wp

I think most SD problems are solved with recent boot loaders, anyway.

I have a few SanDisk Class 10 Extreme myself, which didn't work initially 
when I got my first RPi, but work just fine now.

http://uk.farnell.com/raspberry-pi-accessories#operatingsystem
has some more SD cards and accessories - as described in my new book 
: The Raspberry Pi - a quick start guide - by Maik Schmidt pubished 
by pragmatic programmers

Thanks Gerard!

Implemented IF and EITHER, I just wanted to share their implementation 
with you (extract from Red compiler source)::

	comp-if: does [
		comp-expression		
		emit compose [	
			if (logic-true?)
		]
		comp-sub-block
	]
	
	comp-either: does [
		comp-expression		
		emit compose [	
			either (logic-true?)
		]
		comp-sub-block
		comp-sub-block
	]

Shouldn't be more complex than that, no? ;-)

Turing is calling

forth computers are single stack .. they haven't conquered the world

Are you sure?

I wonder for some time why you give long c-like prefix names to every 
functions. 
Is the context not enough? like rebol style does prefer.
Or is that you fear to forget what's doing your own code ? ;-)
Or maybe there is a technical reason behind it I missed.

No offense intedended here Doc, just a genuine question about your 
prefered coding style.

I'm not sure what you mean by "long c-like prefix names to every 
functions."?

comp-*

You talk about the "comp-" prefixes I use in the compiler code?

yep

is the context not enough ? I mean you use a dffierent context when 
compiling.

Well I'm not sure if what I'm saying makes sense even for me, sorry 
;-)

I should go read some manga and relax

It adheres to REBOL convention for naming functions (starting with 
a verb) but it also serves other purposes:


- as a way to classify the compiler internal functions by category 
or compilation stages, e.g., comp-* functions do the translation 
+ code generation, fetch-* just fetch source code, check-* perform 
type or spec verifications, emit-* just generate target code, etc...


- as a way to stratify the code in compiler context. As I want to 
keep the compiler internal code in one piece (because of too many 
common dependencies). It helps me navigate quickly in the code when 
searching for a bug for example.

Ok I see your point with the depedencies, different contexts could 
be annoying.

They might do more harm than good.

(in this specific use case)

The model you're using to compile is nested functions which in the 
end emit code.

Don't you think several well separated stages which emit their own 
dialect would avoid to much depedencies in your code ?

Another benefit of stages is that you can easly add/remove specific 
phase like optimization ones

In return it would be slower

but more flexible

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