World: r4wp

Red is a high-level language with high-level abstract types. Once 
we get optimizations, Kaj's example should run 5-10 faster than R3. 
For some high-level expressions that have low-level counterparts, 
it is possible to achieve very high gains (in the 10-100 range), 
for those that do not have low-level counterparts, you can only expect 
typical gains from moving from an interpreter to a compiler (on average 
5-10 faster).


Also, there is also a source of additional speed gains: the possible 
runtime optimizations enabled by the JIT-compiler.

Yes, and that doesn't magically make it being programmed in machine 
code

Pekr: high-level language have higher level semantics (materialized 
in the case of Red by the runtime code in %runtime/ folder), you 
can't expect all that "disappear by magic" when translated to native 
code. It is not in the domain of possible things. :-)

to be exact R3 is 300-500 time slower than c compiled code in my 
last tests.
So at least Red should be at leatst 30-50 times faster than Rebol

Those high-level layers are what makes Red able to accomplish all 
the things you like instead of being limited to a macro-assember 
level language (like C or Red/System).

Steeve, I look forward to your Red fork that does that

I forfeit

Your own REBOL clone, then?

it's the limit of the stack based compiler, simple to implement, 
slower than a registers based one

Only partly

Steeve, performances gains will depends on the kind of code you run. 
For micro-benchmarks (like loop 10'000'000 [tail? ""]), the target 
compiler should perform 5-10 faster than R3. For "normal apps", you 
should expect a 10-20 gain (very rough early estimates). For math 
intensive apps, you'll be able to go up to x100 speed gains.

(Kaj, I'm trying to port a text editor to R3 currently, gobs are 
terrible and some times horrific)

Steeve, it is not that simple (I wish it would). You forget to account 
for a lot of things like e.g., exceptions handling and the GC.

yeah, I forgot

Steeve - could you outline then, how would you change gobs in some 
other channel or wiki document. I e.g. don't want to support GTK 
or other bloatware yet, so it might be that I might sponsor View 
engine port, of course, being done eventually right. Gobs are definitely 
more optimised than Faces were though ...

I wanted to say terrible, in the sense of nice

I think gobs are very handy, it would be nice to see a portage to 
Red

But they tend to crash R3 a lot when the command api fail

Steeve, so the design is OK, but implementation needs work?

Pekr, Actually I only use gobs for the rendering part in R3, I completly 
rewriten myu own event handler and VID.

I don't use the VID layer furnished by saphirion

Henrik, yes it still needs work to remove the crashs, and the text 
rendering is not perfect on Win7 but l think we can do everything 
R2 did.

I will probably do a Gob-like binding on Enlightenment

never mind, talking about View engine itself. I don't like gobs logic 
in some aspects anyway ... I e.g. don't like separate gobs for text, 
color, image, effect, draw. Dunno low level logic, but it could be 
all in draw dialect. Simply put - always hated when you can do gob/text, 
but then you can do another text in terms of draw, ditto effect, 
etc.

I mean - never mind you did not use VID ...

I will post something on Github but I can't say too much too soon. 
I don't want to announce another abandonware.

If I can finalize the text editing it could be the beginning of... 
something. :-)

Pekr, I resolved the issue by stacking one gob per dialect (draw, 
rich-text, shape) inside one gob container.

I always use the same model and my VID engine manage itself the creation 
of the sub-gobs.

so that the user only see one face (the container)

We should move to REBOL3 probably. Reddians are not interested in 
View anyway, they seem to prefer more heavy-weight tools :-)

I'll make you eat those words :-)

:-)

Well, I don't necessarily like big solutions/libraries. Of course 
it will make sense, if they are already a part of the toolchain, 
e.g. GTK being part of every linux distro, Android, etc. , ditto 
Cairo. So far I could see complaints about AGG not being accelerated, 
and what irritates me about such claims is - we never ever utilised 
full advantage of AGG, yet we complain. And then we are going to 
use crap like Cairo, just becau HW is going to help us. I would rather 
use smaller AGG instead of several times bigger Cairo lib, and orientiate 
myself on HW, which has floating point unit. Before we finish, even 
our small devices are going all to have FPU imo ...

Everybody should use what he likes too, we should not remember though, 
that it was View itself, which attracted many new users, and historically 
we could find many questions, if Red is going to have engine like 
View is ...

Actually, the Fibonacci function should run very fast in the target 
(optimizing) compiler as there are only math expressions and the 
whole body has Red/System counterparts, so in the target compiler, 
it should run half-way from R3 and Red/System performances.

In the end I think, that having easy to maintain GUI is not necessarily 
related to the backend itself, and that keeps me attracted to Red, 
as I know, that Doc will not tolerate any unnecessary bloated solution 
:-)

Yes, we release Core before we release View ;-)

And Core has even been released before Chat :-)

Pekr: you have a wrong view on what the Red ecosystem is and will 
be. It is probably caused by 15 years of limited options from RT 
and closed-source nature of REBOL products.


In Red ecosystem, like in any most other languages ecosystems, you'll 
be able to choose GUI between different options. Don't give a wrong 
picture of Red by assuming that you will be limited to only one choice.

As for /Core, /View, /Command etc, I just wonder - will there be 
any such product separation with Red? I mean - you can have big "ecosystem" 
linked via R/S, so I wonder, if there will be any packaging, or simply 
products, for certain areas, containing related libs, etc.? Or an 
environment builder, where you choose modules, or something like 
that?

Doc - OK, so that user, who wished all the years RT linked View to 
VLC, could find his remedy via Red, being bridged to VLC via R/S, 
right? :-)

Yep

Yep, and that user will live happy in the Red world. ;-)

btw - libVLC is LGPL 2.1, should be OK to link to, licence-wise?

Sure, almost any licence is

The "RT-like product" separation wouldn't have much meaning in Red 
where you can build your  executables with whatever modules you need. 


We'll define a common "extension" standard (probably based on module! 
datatype) that all third-party modules will implement, so that your 
app could easily use any modules at a cost of a simple "import" directive. 
Such extensions will be typically coded in Red, but with all the 
low-level options, like Red/System routines and bindings to external 
libs.


Moreover, you'll have also the alternative option to build everything 
in a single binary (including third-party libs if they can be statically 
linked). Such thing is impossible in R2 or closed-source R3. In  
 open-source'd R3, you'll be able to do that too, but you'll have 
to get your hands dirty by implementing the bindings in C and using 
a C compiler to produce the executable binary.

LGPL: no problem.

Well - can you statically link LGPL lib? I think not?

But - no problem loading libs dynamically ...

You can, if you provide your object code so it can be relinked to 
other versions of the LGPL part

I dug up John's result for World when he fixed it to run Fibonacci: