World: r3wp

As Robert mentioned Photothead library few days ago ( http://www.sics.se/~adam/pt/
), I do remember finding some interesting event libraries in the 
past - liboop ( http://freshmeat.net/projects/liboop/)          
     and libevent ( http://monkey.org/~provos/libevent/- some other 
references there too) ... so just for a sake of a reference ...

Kaj: do you have a web page for your C binding that I could reference 
on red-lang.org?

most likely http://red.esperconsultancy.nl/Red-C-library/

Thanks

it's awesome to see the growing of a language and the environment 
around it being fully documented! it will be very useful for the 
next generations

regarding bare metal version, i would be happy to help with a Microchip 
PIC version, in case it can fit into one...

my father would be a happy user probably, since he is using rebol/view 
now to write interfaces for those pic controllers he was programming 
in flash forth. however, im not sure if we can beat the interactivity 
of a forth system on such a resource constrained device...

Doc, I'll make a real website for the Red bindings later. For now, 
you can indeed link the Fossil frontend

Kaj: regarding chimpanzees...

my father in law has some monkeys which normally help to twist off 
coconuts from palm trees. as these little guys get older, they get 
slower and also grumpier. 2 different ones already bit my father 
in law.

we might give these retired, veteran monkeys a second life as random 
number generator! i would be a great business in thailand if i think 
about how many coconut trees and monkeys do they have here :)

Sounds familiar :-)

onetom, put them on TV to comment on current events around the world. 
That would likely be more insightful than what media provide today.

I don't know if people know the Chimpanzee story. Several years ago, 
journalists at an investment publication here in the Netherlands 
if I'm not mistaken, started having a Chimpanzee throw darts at a 
list of funds every year. The Chimp turned out to almost match the 
performance of high-end investment firms. They may still be doing 
it

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