World: r3wp

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?

the offending line in r3-gui is:
        max-size: 2.147484e9x2.147484e9

Ashley, you need to build your own R3 .. the downloadable ones are 
old

This is A105 that I built http://r3alpha.s3.amazonaws.com/r3.exe

did you include Henrik's view source?

Is there something wrong with this tuple?

 - sure, first of all, it is not a tuple, it is a pair, which your 
 version does not recognize

heh, of course it's not a tuple - my brain was trying to focus too 
hard on what was wrong with the pair - why wouldn't my bersion recognize 
it? Because make-host-init was done before the float pair support 
was added?

and it's confusing the definition with a tuple somehow?

No, it doesn't need Henrik's view source which is a moving target