World: r3wp

AGG and FOG may perform better, but I'm not sure. The choice between 
those two is difficult. AGG is basically abandoned, but still more 
popular than Fog

I have heard about Skia, I agree, it seems like a nice library. Never 
heard about Fog before, but its performances are impressive: http://code.google.com/p/fog/wiki/Benchmarks

Comparing against Cairo is like taking candy from a kid :-)

I'd like to know how it compares to AGG and Skia

I also want to know if rendering quality in Skia is as good as in 
AGG. It sucks in Cairo, or at least it always did. Fog is likely 
to be as good as AGG, because it builds on the same principles

Implemented character set tests and case conversion in the C library 
binding

talking about the C library... will Red compile against the uclibc?

Red/System is written in REBOL

From conversations that I have followed, it does not directly access 
C libraries.

Sorry, I should have written "does not access C libraries"

From a quick check of the source - none of the compiler, the emitter 
or the linker reference any external library.

The first Red complier will be also be written in REBOL. The Red 
Roadmap shows that a beta of Red should be published in Septermber 
2011.

As far as i know, Red/System executables don't rely on C libraries 
either unless they are explicitly declared in the program.

Correct. The question would presumably be: "Will the Red C library 
binding link with uCLibC?"

I'm binding against the ANSI C specification of the standard C library, 
so I have no reason to think that not any C library would work

However, Red will probably soon start using parts of the C library 
binding, so it's likely that future Red programs will almost all 
need to link with a C library

Kaj, you stated: "In the past two years I made a lot of effort to 
get R3 running on Syllable Server and then Syllable Desktop, and 
just now that it was becoming somewhat usable, it's being abandoned."


What exactly is being abandoned? I tried to read back through the 
previous messages, but I'm missing something.

Carl has disappeared for a while .. with no indication as to when 
active R3 development is to recommence

ddhaing - Carl does not do any active R3 development (unless something 
is being done without our knowledge) since 10/2011. That is half 
a year. Carl also does not treat REBOL community well, so some ppl 
get the impression of R3 being "abandoned". Carl replied to Oldes, 
that he is working on some Linux embedded contact, which even does 
not allow him to use the R3. Any question about the R3 development 
plan, stays being unanswered. My take is, that if Carl does not resurface 
soon enough, clearly stating how he plans to proceed with R3, he 
effectively burries R3 under, as ppl might get their free time to 
Red instead.

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?