World: r4wp

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

float!'s are rational!'s, aren't they?

All numbers representable in binary floating points are rational 
numbers, but not all rational numbers can be represented (exactly) 
in binary floating point.

Yes. real!'s are even less well covered, though

Kaj: right, strictly speaking, it covers rationals numbers only.

(at least, as subset of rational numbers)

*a subset

Good news everyone: it seems I've removed the reception limitations 
on my Paypal account, so feel free to send new donations.

I have finally recovered after my credit card fraud. I (hopefully) 
sent 50 EUR, Doc. Please let me know if it arriwes, as for the first 
time, the last name on my Card contains czech char, and my Paypal 
profile does not have any. Hopefully it all resolves well ...

Got it Peter, thank you!

Good! :-)

Just finally got my Raspberry to work, after running around all week 
buying additional needed equipment. So maybe I'll have something 
to talk about tomorrow

I got it to work also three hours ago (had only a VGA monitor, passive 
adapters didn't work, I had to find another monitor)

Yeah, we bought a new one, too, but also an adapter cable from HDMI 
to VGA

My USB wifi device works, but the screen resolution is so small that 
I can see only half of the wifi config window. I can't change the 
resolution from the preferences, it just errors out saying it doesn't 
recognize the monitor...

I'll try to fix it in boot config tomorrow.

Most of the bindings don't work on ARM

Does that concern only bindings that rely on callbacks?

I will try to fix those bindings issues on ARM once I release v0.3.0 
in a few days.

Ah Kaj, could you put up a shopping list of thing to buy too when 
you buy a RaspberryPi?

RED FUNDING DRIVE, MATCHING FUNDS CHALLENGE:  to help ensure that 
Doc can continue to work on Red without disruption, I'll match funds 
donated to him by November 1, 2012, up to a total of $1000.

Kaj, we need to get you funded too.

Perhaps some discussion about forming a Red foundation would be helpful 
to organize anticipated future actitivies involving community relations 
or other activities that will keep Doc and other core developers 
from focusing on code.

Yes, the hope is that we can rally support to do the things, like 
web sites, forum moderation, etc. so core developers (i.e. Doc) can 
focus on development.