World: r3wp

let's see how it goes with the ones that have proposed so far. if 
i need more i'll ask.

is networking being async, or no need to, as we've got threading?

You can test reliability of networking layer by finishing Chord, 
no? :-)

async

chord - udp not there yet, but i will test that once we have task! 
complete (i don't want to have a mess of callbacks like in r2 chord.r)

task! is not complete yet?

from Carl's presentation, I did not understand plug-ins explanation. 
What are those? Will those replace library interface? Or provide 
means of extending rebol with native functionality via some common 
api?

latter.

task! works but is not complete functionality-wise (and has some 
bugs)

ah, I thought that task is easier part - "just" starting threads 
... well, then that mutex:// thing, and internal isolation of "contexts" 
:-) Hmm, maybe complicated enought to be difficult to implement ...

does this include https ?

Gabriele - how goes work on VID prototype?

no ssl yet.

no vid proto yet.

hmm, sound like kind of delay? Will public beta release of 15th July 
be affected?

maybe, but not sure yet. it could just be that it has incomplete 
vid. or it could be that we are able to do it quickly...

I've made a layer demo to test performance in R2 and R3. The demo 
is coded for R2 using FACE, but I guess you guys can easily convert 
it to R3 using GOBs.

do http://www.fys.ku.dk/~niclasen/rebol/test/layer.r


Use mouse to move squares around. Right-click a square to remove 
it. In the source, you can change the offset and size of the window 
in the beginnig, where playground is defined. The demo produce 100 
squares. A little down, there is the
loop 100 [
Change that to have more squares.
I hope, it can help.

Use <Esc> to quit the script.

I think that Rebolek did some 1000cows script, and reported difference 
was 2fps for R2 vs 20fps for R3 gobs version ....

Yes, you can do http://bolek.techno.cz/reb/1000cows.r, works both 
in r2 and r3.

I've got about 15fps with 1000 cows and 2 fps with 2500 cows (default 
cow-count when you download). R3 can do about 20-25fps in both cases 
on my machine.

that is very impressive improvement ....

I'm wondering, how big the difference is from FACE to GOB? Any documentation 
on GOBs yet?

docs will be public once r3 is public :)

So, will extended release come tomorrow? :-)

15th of July i think

no, July 1st should come extended beta release. What you mention 
is public beta release ....

ah ok

I expect extended beta release comes at least here to AltME folks 
.... but can't be sure of course ....

do we have any news on whether viewand/or vid will be included with 
the Beta?

I think that View is part of the release .... not much was said about 
VID prototype. Last time I asked it was not done yet ...

vid will be there, so we'll be a bit late.

Gabriele - could you say few words about new VID? I will try to not 
ask about details, but I would welcome some general information ...

a litttle more patience :)

According to http://www.rebol.net/r3blogs/0076.html, in REBOL 3, 
CHAR! is a 8bit and 16bit character.


This could be problematic, I guess. Why don't we have two different 
datatypes instead: 16-bit CHAR! and 8-bit BYTE! The 16-bit CHAR! 
is in UTF-16, just like Java.

STRING! is BYTE! string.
UNICODE! is CHAR! string.

How you you think about that?

x x xxb   bxgb      z

Sorry, my kid must have tried to be a "reboler" too.

Is it too late in the game to ask for a 'last result' auto-variable 
as part of the console interpreter?  back-tick ` or dot . maybe, 
something unshifted.  Or am I just being lazy?  It would turn (for 
me at least) an up arrow, home (repeated back cursor actually), insert 
set-word sequence to a set-word last-result sequence.

jerry, what would you need 8-bit chars for?

Not that I need 8-bit chars. I just think that 8-or-16-bit chars 
could make things complicated. They should be of different types, 
or something complicated could happen, such as:

>> insert a-string char8
>> insert a-string char16


now, a-string contains both 8-bit chars and 16-bit chars. How would 
I deal with that.


Since REBOL 3.0 seperate STRING! and UNICODE!, I think that seperating 
BYTE! and CHAR! could be helpful. Let STRING! contains BYTE! only, 
and UNICODE contains CHAR! only.

I think there were going to be VECTOR!s for that

Kai, my point is, I don't want an atomic type (which is CHAR!) to 
present two different sizes. I don't want to write my code like the 
following:

myfunc: func [ ch [ char!] ] 
[
    either ( size? ch ) = 8 [
        ; do something about 8-bit char 
    ] [ ;
        ; do something about UTF-16 char
    ]
]

ah, wait, char! can't be "8 bit or 16 bit". the internal space for 
the value is fixed (64 bits, actually). so it's either always 8 or 
always 16.

currenly, unicode is not there yet, so this has not been defined 
yet (i think char! is still 8 bit). but in principle, append a-string 
char-gt-255 will either error out or automatically encode to utf-8 
(latter would be nice but it must be done for values gt than 127, 
so it would be a problem if you don't want utf-8)

it's like binary! - you can only insert integers up to 255.

Thanks Gabriele.

This is a good question, actually. We need abstract datatypes but 
we also need concrete bitfields, and we need to be able to treat 
certain common values (char and integer at least) in either way.

By the way, how far is R3 ?

doing some work on documentation and reading about the vector! datatype

The latest blog from Carl said the beta would probably be a couple 
weeks late, so maybe something more will be seen or heard by the 
end of the month.

current ETA is August 1st, but don't tell too loud :)