World: r4wp

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:

I fixed the compile bug in World, so Kaj's Fibonacci test now takes 
8.7s to run in World on my machine. R2 takes 17s and C less than 
1s.

Those results are quite similar to Red's current performance

Is World being compiled?

Yes

I understand that the 2 times faster than R3 includes the compile 
of the Fibonacci program? 

No the performance of the Red program is a bit dissappointing at 
a first glance for the programsource is not very different from that 
in Red/System?

Similarity between the two is not so easily related, as Red is more 
dynamic than Red/System.

the performance of the Red program is a bit dissappointing

 Maybe I should have kept Red project secret until v1.0 to avoid "deceiving" 
 people who thinks that any v0.x version should be equal to a v1.0...;-)

Well the compile is not a simple 1-to-1 translation. 

I am glad you did not keep it a secret, I enjoy seeing the developments. 
And it IS already faster then R3! :D

The speed difference with R3 is not a constant, the more code you 
put in the loop, the bigger the speed difference.

Doc, can you make both MOLD and LOAD support /BINARY refinement to 
input/output Redbin format?

Arnold, the time does not include the compilation. That's a one-time 
operation, so it would be unusual to include it

For World, it does include the compilation, because its operation 
mimics an interpreter

AFAIK, World compiles to bytecode, then runs the bytecode in an interpreter.

Yes, rather different model

Jerry: it's a bit premature, but yes, that should be the way to create 
and consume redbin data. You can also add SAVE to that list.

I gave the topic of the "speed" more thoughts, and though I am very 
uneducated in lower level internals and language designs, I think 
that I might have more understanding, why I can't think about Red 
being just a compiler to Red/System in a 1:1 manner. In such a case, 
Red would not be needed. What needs to be included in the final exe 
is kind of "engine", supporting stuff like GC, all the dynamic things, 
type checking engine, etc etc. 


When I ask myself, if I am willing to exchange dynamic stuff for 
speed, I say - no, at least not necessarily. It was just that I got 
trapped by first R/S performance tests, and thinking that if Red 
compile, it has to be almost that fast too.


As for waiting for 1.x and possible optimisations - I don't believe 
optimisations can change things drastically, at least non in order 
of a magnitude. But - we will see.

Personally, I feel that Google's V8 & Apple's Nitro give orders of 
magnitude speed improvements over early JavaScript Compilers.

Peter - in the case of JS engines - is that only about the compilers, 
or also about an overal architecture change?

Pekr: there are several layers at which optimizations can be applied. 
With an optimizing Red/System compiler, you'll already get an overall 
x2-4 boost. Then optimizations at Red level can bring us another 
boost (runtime code can be optimized, compilation output can be optimized 
to be closer to 1:1 with Red/System, when possible). The end result 
should give us, on average, a x10-20 boost over R3. I am pretty confident 
that this can be achieved, given the current results.