World: r3wp

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

ah, sorry ... a really old one :-)

what is your issue with the new #issue as words idea?

The issue with issue is, that issue is no more like old issue :-)

my only gripe is that we can't use a digit as the first char... I'm 
wondering if there are other problems.

Max, you still can use digit as the first char. From changelog:

The representation of numeric values (invalid word forms) is still 
supported, so usage for HTML colors or hex numbers, and conversion 
to and from tuples and integers, still works.

>> system/version
== 2.100.106.3.1

>> a: #1
== #1

>> any-word? a
== true

oh, cool .   so I guess the issue is that issues now clobber the 
word space.

is there a word count limit in R3?

I guess there is.

IIRC the word count has raised, as well as recursion level, or it 
is settable via 'enchant or something like that ... can't find the 
function now ...

Should I CC it, so that someone with edit rights can correct docs? 
http://www.rebol.com/r3/docs/functions/stats.html- in R3 'stats 
no more supports /types and /pools refinements ...

.... and other refinements too :-) The text is probably a left-over 
from R2 description, whereas function description is probably auto-generated 
:-)

I've upgraded r3 to the latest version found here:

	http://www.rebol.com/r3/downloads.html

and note the following:

>> system/version
== 2.100.99.2.5
>> make gob! []
== make gob! [offset: 0x0 size: 100x100 alpha: 0]
>> source show
show undefined
>> source size-text
size-text undefined

where did View go and when will we get it back? ;)

Henrik put up a link to his newest build in REBOL3 GUI:
http://rebol.hmkdesign.dk/files/r3/gui/r3-gui.r3

show and size-text are natives not mezz. Without them you can't build 
a GUI.

Should I expect something different?:

>> do %r3-gui.r3
Script: "Untitled" Version: none Date: none
>> source show
show: make command! [[
    {Display or update a graphical object or block of them.}
    gob [gob! none!]
]]
>> source size-text
size-text: make command! [[
    {Returns the size of text rendered by a graphics object.}
    gob [gob!]
]]
>>

system/version?

== 2.100.107.3.1

maybe the file you got from the link you posted is only core?

I built this one using the host kit

That's what I was alluding to ... earlier alpha builds had VIew built 
in, the latest does not. Oh well.

I was trying to make a build with r3-gui.r included, but when running 
the generation step of the build make-host-init.r outputs the error 
"Invalid tuple -- 2.147484e9x2.147484e9" when processing this file. 
Is there something wrong with this tuple?