World: r3wp

:))) no, i haven't heard the story yet

I have a variant: A few years ago, a TV station had some famous art 
critics comment on the paintings of a new, unknown artist. They made 
lengthy comments on how wonderful it all was and how it was a new 
style of art. They were not pleased to learn they had been tricked 
into commenting on works made by a monkey.

:P~~~ cool

Picasso once said that when art critics meet, they discuss design 
and architecture and geometry, deeper meaning and social consequences; 
and when artists gather, they talk about where to get cheap turpentine

onetom: I am also glad to see how it is evolving. About PIC support, 
these platforms might be too restricted for Red, but Red/System should 
be portable on some of them.

Doc - as Red/System is relatively close to its completion, are you 
already thinking about the implementation plan of RED itself? I still 
might not understand the architecture well enough (my fault, have 
not read properly docs yet), but what e.g. networking port code? 
Will that be written in RED? RED/System? Or will it be just some 
BSD library code linked to Red?

Well, the details of Red implementation are not have been yet documented, 
but the general idea is to implement as much features as possible 
in Red itself relying only on Red/System's support functions exported 
to Red level. So for networking, Red/System should publish to Red 
the low-level OS mappings required and let Red implement everything 
else. This is the plan, but it not set in stone, it could be changed 
during implementation if a better approach emerges.

Kaj: I will work this weekend on callback support (probably tomorrow).

Great

Implemented some simple type conversions in the C library binding, 
parsing strings to integers and floating point

I think Steve Shireman has done TCP stacks in the past. 


My only recent thought, related to OS dependencies and such, was 
what it would be like if your only interface to files was a memory 
mapped file interface. Thinking about languages and desktop/server 
systems, not the embedded stuff.

I've added many convenience wrappers to the C library binding in 
order to use native data types

This makes many functions return TRUE for success instead of an integer 
(with reversed meaning)

There are also many C functions that return something else for success, 
and take integer parameters for byte values

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