World: r3wp

Sorry if already beingasked, but woul Red run on something like Arduino 
control board platform? http://arduino.cc/en/Main/Hardware- not 
sure the HW is capable enough though. It uses Atmel, might be similar 
to PIC. http://atmel.com/dyn/resources/prod_documents/doc7799.pdf


It might be nice to have the lowest common HW denominator written 
down to know, what HW it could boot on :-)

Pekr, Doc says that he wants it to run on Arduino and NXT at least.

Some hardware will be too small for Red, but Red/System is basically 
C, so it could run on almost anything. That's why I want Red/System 
to be usable on its own, with a full C library binding and such

The smallest hardware is currently defined as a 32 bits CPU, but 
even that could be scaled down

In the example at the end of 9.1, the calling convention for msvcrt.dll 
is specified as stdcall. I think that should be cdecl?

For some functionality, I need to have access to the stdin, stdout 
and stderr identifiers. For syscalls, they're simple integers, but 
in the C library, they're pointers to file descriptors. There's currently 
no way to get their values

C programs import them as external symbols, so it seems to me that 
#import should be extended to do that, as opposed to just importing 
functions

Pekr, as Kaj already said, currently the minimum target is a 32-bit 
CPUs (with an MMU, I'd add). The 8-bit Atmel Arduino will likely 
stay out of reach for a while, but a 32-bit ARM-based Arduino-compatible 
thing (such as the "Netduino" or Microchip's "chipKIT") might be 
realistic sooner.

Kaj, for importing symbols we could use a "value:" keyword similar 
to the "return:" keyword currently used in functions:

#import ["libc.so" cdecl [stdin: "stdin" [value: [integer!]]]]

Fine with me

Msvcrt.dll: thanks, I have pushed a fix for that.

Netduino: this is a platform that could be easily supported by Red/System 
once we'll have an ARM native code emitter.

Andreas: agreed for the #import extension syntax. I am adding that 
feature to the todo-list, and will look into the PE format specs 
to see how it is encoded.  What is required in ELF to support such 
imports?

Pushed a new commit:

- added support for callbacks (just place 'callback in a function 
attribute block, see http://static.red-lang.org/red-system-specs.html#section-6.3)
- specification draft revision 11

Quick-Tests documentation on red-lang.org updated to latest revision.

The callback support has just been tested for correct compilation, 
I haven't tested it with a real case.

Looking at the disassembled code, I forgor to set correctly the callback 
epilog...will push a fix for that in a minute.

Fix pushed.

Implemented date and time functions in the C library binding

Doc, could you please add a more obvious Paypal donation button to 
the Red home page?

Hi Nick, I was waiting to have a new mailbox @red-lang.org set up 
first. In the meantime the donation button at cheyenne-server.org 
can be used, the Paypal account is personal (even if it is @softinnov.com).

I need to read the gmail docs for setting up a custom domain.

Nick, thank you very much for your donation!

I have set up a new account on Google Apps for red-lang.org and added 
MX records, so my new mailbox should be ready by tomorrow. I will 
also create a new Paypal account for Red once the mailbox will be 
ready.

Doc, I have not read anbything about RED and I am just curious.
Which are the main differences between RED and REBOL ?

Red is compiled to native code, REBOL is interpreted.

There is a bit longer description here: http://freshmeat.net/projects/red-language

And more details here: http://www.red-lang.org/p/about.html

Read ! I have understood the differences and why your are leaveing 
the REBOL world for the RED world.

Well, "leaving" might be a little strong. Red is based on REBOL, 
can coexist with REBOL very well (in theory), and most of the people 
working on it are part of the REBOL community in one way or another. 
They're complementary projects.

and REBOL 4 will be written in Red :-)

Implemented a separate binding for the floating point math library

However, it can't work yet, because floats are 64 bits in most implementations, 
and Red can't pass those by value

Ah, I see Doc will need to implement float support to back up his 
n-body boast :-)

Implemented remaining string parsing and file functions

The C and math library binding is now pretty much complete, at the 
level of the original ANSI standard. I've left out some stuff that 
is too implementation dependent and not strictly needed

A few features are waiting for extra support in Red/System

Doc, love the painting you used for the  'What is the state of Rebol 
World?'  I've forgotten who the artist is do you know?

I know it from Asterix :-)

The examples in 10.1 and 10.2 use hex numbers in lowercase

Am I right when I assume that #include does not prevent against double 
inclusion of the same file?

Is NOT evaluated left to right? It seems to have lower priority

#include was changed to only include a file once a little while ago. 
There was a comment to that effect in the commit notes.

Cool, thanks

If Red follows REBOL's evaluation levels, NOT would have lower priority 
than all operators. Two levels: Operators, and everything else.

It would actually make my current code case nicer, but I need to 
be sure it's intended

Does it mean NOT is handled as a function? It's listed as an operator

Operators are infix. Prefix is functions. But it might be implemented 
as a special case builtin, which would make it what other languages 
call prefix operators.

Operators in Red are both infix and prefix

The REBOL manual also fails to note the fundamental difference between 
NOT and the other logical functions/operators