World: r3wp

above - 10/2010

That is annoying, Carl should at least say when he is going to come 
back to R3, even if it is 6 or 9 months later, we should know. Red 
is going great, but I think we'll need them both because Red is a 
compiled language. I use many Rebol scripts on my customer's servers 
to be able to change them easily on the fly.

Red will support high-level scripting through thanks to its JIT-compiler. 
So, building or loading new scripts on-the-fly from your compiled 
Red app will be possible.

(-through)

That will be great. How about binding? Will be similar to Rebol?

Sorry I didn't follow all the threads about Red. I'm sure you already 
think/write about it.

Binding: only static binding. See my presentation slides: http://www.red-lang.org/p/about.html

When an extra script is JIT-compiled, will it bind to the already 
running environment?

Or an environment of choice?

If by "environment", you mean "namespace", I guess it would be wise 
to support both, using a specific DO refinement for the sandboxed 
version.

By default, it would "bind" the script to the global context.

We could optionaly "bind" to a given module (namespace) or to a sandboxed 
execution context.

I say environment, because I would like it to bind to a stack of 
contexts. If it can do that, it would be enough for me

Only following this whole cool stuff here from the side, but what 
would be really cool is, if Red can live without any specific C lib 
binding. Either by providing the used functions itself in a sideeffect 
free version or by adding support to a OS free lib that can run on 
bare metal.

Robert: being free from any dependency (including C lib) is my intention, 
but:
- C lib is available as system library in any major OS

- C lib functions are more optimized, so will run faster than Red/System 
alternatives


However, as I would like to be able to make Red (or just Red/System) 
run on many embedded platform too (e.g. Arduino and NXT), I don't 
want to have to statically link with C lib there (because of the 
memory footprint). My current idea is to provide both: C lib bindings 
and alternative functions coded in Red/System only, in a transparent 
way for the user.

That is the most preferable way I think.

Doc, hah! I was about to ask about the Arduino. :-)

Doc, the thing is, yes on an OS there is a c lib. But what if you 
don't have an OS or don't need one?

With all the plug computers coming with server sized ARM processors, 
being able to create bare-matel appliances that you just plug in 
and which are than balzing fast, is a pretty cool setup.

So, how about a way to always keep a list of external used functions? 
This make it simpler to make Red totally stand-alone later. The hard 
part to get rid of all the lics & OS stuff is, that you have to find 
out, which functions you have to "clone".

I would be suprized if there was no C compiler for all those plug 
computers, but anyway, I will do my best to have a dependency-free 
Red core option. I will keep all the core bindings in separate per-OS 
files, so it will be easier to track them.


I guess it would be fun to implement a micro-OS in Red/System for 
these micro-platforms, I always wanted to get my hand on a custom 
TCP/IP stack implementation :-) .

I just hope that this will not make development time much longer.

There is a C compiler but the clib is mostly dependent on the OS 
as well. So, no standalone, bare metal C lib. That's the problem. 
Using the clib, you need to have the OS as well.

Like this stuff here: http://sourceware.org/newlib/

See section 14.1

Endo: I will not let those sub-projects interfere with the main roadmap, 
they should just blend in. For example, the SheevaPlug could be a 
nice platform to develop and test the ARM port for Red/System: http://en.wikipedia.org/wiki/SheevaPlug

The manufacturer is Marvell, that's fun :)

Implemented pseudo-random numbers in the C library binding. Everybody 
can start writing console games now ;-)

and stock prediction tools

I wouldn't want to put the chimpanzee out of work that they're using 
here

Doc, I have a SheevaPlug here. :-) That's the bare metal system I 
want to use :-)

Well, it runs on Linux I guess, so no issue with libc?

Implemented signals in the C library binding

So you can now for example make a server program that properly reacts 
to system signals

However, it may not yet work until Red generates cdecl functions

To get a handle on why Red/System tries to replace C, I think it's 
interesting to compare this function prototype:

void (*signal(int sig, void (*handler)(int)))(int)

Here's the Red binding, basically the same prototype in Red/System:

on-signal: "signal" [  ; Register handlers for receiving system signals.
	signal		[integer!]
	handler		[function!]  ; Flag or callback with integer! parameter
	return:		[function!]
]

I don't even know if I've translated that right, because I get a 
headache trying to read the C prototype

typedef void (*sighandler_t)(int);
sighandler_t signal(int signum, sighandler_t handler);


Easier to read :) So yes, the translation looks correct. It does 
not carry the same amount of information, though (the signatures 
of the signal handler functions is missing).

Yes, no typed pointers in Red yet

Implemented ABSOLUTE, quicksort and binary search

Again, SORT and binary search may not work yet, because they take 
a comparison function, that should be cdecl

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