World: r3wp

I think they are complete, but the official word is that the host 
kit will be separated under two licenses: one part open source and 
one part not open source. Both projected licenses are still unspecified

The interfaces between REBOL and AGG are rather REBOL specific. I'm 
not sure it's worth it to try to use them in Red

Cyphre says that it's easily possible to use the AGG part outside 
of R3.

License is a question for Carl. Perhaps it's simpler to just interface 
AGG directly. Not sure.

If you get a BSD licence. The purpose of the other unspecified licence 
is specifically to prevent REBOL competitors

Well, latest AGG version (2.5) is distributed under GPL, development 
has stopped in 2006, it doesn't support hardware acceleration AFAIK, 
so it's a no-go. Cairo seems like a more modern graphic vector engine. 
Anyway, it is open to any contributor, as I don't plan to work personally 
on a View-like engine for Red.

2.4 is BSD. 2.5 is only slightly improved. A residual community around 
AGG has been continuing with 2.4 and has made a few fixes to it

http://agg.svn.sourceforge.net/viewvc/agg/

There are basically four options: AGG, Fog, Cairo and Skia

I was always unimpressed with Cairo. If you want a full-featured 
library, Skia looks better

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