World: r3wp

Hence, we are working on getting incremental steps done, that are 
useful. Maybe not for everyone but a lot can be done with R3 now.

And we will keep the high pace of new releases. Each one delivering 
more stuff.

Maybe something breaks existing code than. Yes, not to nice and takes 
some work but it's not killing us.

While R3 moves forward, we will use it for all our projects. Add, 
what's missing on the way and move forward.

In this stream tasks will come. I just don't know yet, if next week, 
month or in 6 months at the moment.

But Carl has put it onto the roadmap, so it's already in the near 
range radar.

But tasks is not just about "want".... its about something that has 
the *potential* (we don't know) to break other R3 components down 
the road.


so My point is not that I want it now.... I just want R3 to stay 
"freed from locking" until tasks are revised by carl.

The message that's important to all (including Lad here ;-)) is that 
R3 is useable for quite some stuff and should be used. Maybe not 
for everything yet. But you can start to use it today.

I agree... its very nice already.  I will be looking into the A 105 
release next week.

If tasks break things, yeah, than that's how it is. I take the risk, 
we adopt our code once and that's it.

I'm not afraid of it. I know that I take a high risk here to break 
some code.

And if a good task implementation takes 6 months... than it takes 
6 months and is of good quality than.

one question for you Robert... is the A105 view/agg code stabilized 
wrt what I was reading for A104?

What part do you mean with stabilized?

low-level use of AGG... not the R3GUI

A105 is the first one to integrate our AGG code line. So, bringing 
Carls work and our work much more in sync with less hassels for new 
releases.

I think with A105 the AGG externalization is done. There are some 
quirks left, to be fixed. But we can now do this on our own.

And yes, it's stable WRT AGG. I don't expect major architecture changes.

ok, that's what I meant...  thanks.  I'll probably be delving more 
deeply into the whole graphics structure next week.

the only thing I have been wondering is how the gob type interfaces 
with the AGG... isn't gob! part of the core?

for example, could I build a gob! which uses another rendering package?

I'm not yet an expert, but I think that the GOB! get's converted 
to the AGG world. Hence, you can take the GOB! from Rebol and however 
you bring it on screen, just do it.

ok I'll try to figure out the Architecture from the code (its a pretty 
big codebase... a bit daunting, I admit)

the codebase is really rather small. src/os/, the hostkit "core", 
has ~9k lines (wc -l).

most stuff in src/agg/ is "just" the agg sources. the rebols-specific 
stuff in src/agg/ is in ~7 .cpp files, totaling just over 7k lines 
(agg_{compo,effects,graphics,truetype_text}, compositor, graphics, 
rich_text).

(but it may well be that i missed some stuff, haven't yet looked 
too deeply into the agg parts)

I meant the whole graphics sources including AGG.


there are many files... figuring out the whole calling order is going 
to be fun  :-)

but its still manageable... it could be much worse..

A106 is planned to have call/wait and launch/wait.

nice ... btw - is that call/wait/output? without the output, you 
can't easily catch the output ...

Pekr, asking him now.

call/wait/output was (for me) the most used scenario, wrapping some 
command-line tools and obtaining the result. That way you can simply 
wrap e.g. SQLite.exe result, without the need to have proper driver 
...

It's pure /wait at the moment.

From Carl:

Adding /output is a many-days/weeks addition. 


The R2 CALL function required 5 programmers over several months... 
3 of which were even world-class programmers.

5 programmers over several months? :-) Last I heard from Carl, it 
was 5 screens of code or so ... so it took 5 programmers 5 months? 
Hmm ....

Adapt Doc and Gab's async-call code.

that's REBOL level code, no?

or it uses library calls, dunno ...

Yes, uses library calls.

From Carl:


License statement:  if someone makes the R2 shell.c streams work 
in R3, then we'll release it as open source in the host-kit as host-call.c 
(or host-shell.c).  And, the community can support it directly.


In other words, we'll contribute the R2 code to the R3 host project. 
(I just wanted to clarify that.)

If we find a qualified person to port this code, we can invite them 
here, or on another world.  (Only 1 in perhaps 1000 programmers are 
skilled enough.)
 :-)

How big is the actual code? Not that I would be the one to pick-up 
the challenge :-)

I'm not sure it's particularly large. It seems that just interfacing 
is very difficult:


The difficulty is not inherent in the design requirements... it's 
because stdio methods are very old (as old as modern computing) and 
have been messed with (inside the OS) for such a long time.

he posted some comments from the code (I'm not allowed to repost) 
and it does not look simple.

Why are we not surprised.

Well, if Carl is ready to open-source R3 *fully*, I'll be more than 
happy to take that (and other) challenge(s). ;-)

Dockimbel - you have been warned - this is not Humor channel :-)))

I don't like issues as words. The advantage of  faster acces to #include, 
that is only used one time at startup or even less when encapping 
does not outweight  that I shall no longer generate large numbers 
of issues, but instead strings or binaries for lists.

Pity there is no blog article, so you can't bring your opinion to 
Carl's eyes. Maybe on R3 Chat? Well, it seems the decision is final 
though ...

there is http://www.rebol.net/r3blogs/0108.html