r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Pekr
20-Jun-2007
[3504x5]
:-)
I could theoretically do it, but I would be probably more interested 
in plain tcp, as I can work with WireShark etc.
but only week and a half to finish the strategy
and as for July, I will be just few days at work, then vacation, 
most of it off-line (rock festival for few days, High Tatras from 
21.7., but that time, it should be already a public beta release 
....)
what about trying to ask on ML?
Gabriele
20-Jun-2007
[3509]
let's see how it goes with the ones that have proposed so far. if 
i need more i'll ask.
Pekr
20-Jun-2007
[3510x2]
is networking being async, or no need to, as we've got threading?
You can test reliability of networking layer by finishing Chord, 
no? :-)
Gabriele
20-Jun-2007
[3512x2]
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)
Pekr
20-Jun-2007
[3514x2]
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?
Gabriele
20-Jun-2007
[3516x2]
latter.
task! works but is not complete functionality-wise (and has some 
bugs)
Pekr
20-Jun-2007
[3518]
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 ...
Graham
20-Jun-2007
[3519]
does this include https ?
Pekr
20-Jun-2007
[3520]
Gabriele - how goes work on VID prototype?
Gabriele
20-Jun-2007
[3521x2]
no ssl yet.
no vid proto yet.
Pekr
20-Jun-2007
[3523]
hmm, sound like kind of delay? Will public beta release of 15th July 
be affected?
Gabriele
20-Jun-2007
[3524]
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...
Geomol
21-Jun-2007
[3525x2]
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.
Pekr
21-Jun-2007
[3527]
I think that Rebolek did some 1000cows script, and reported difference 
was 2fps for R2 vs 20fps for R3 gobs version ....
Rebolek
21-Jun-2007
[3528]
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.
Pekr
21-Jun-2007
[3529]
that is very impressive improvement ....
Geomol
22-Jun-2007
[3530]
I'm wondering, how big the difference is from FACE to GOB? Any documentation 
on GOBs yet?
Gabriele
22-Jun-2007
[3531]
docs will be public once r3 is public :)
Pekr
30-Jun-2007
[3532]
So, will extended release come tomorrow? :-)
ICarii
30-Jun-2007
[3533]
15th of July i think
Pekr
30-Jun-2007
[3534]
no, July 1st should come extended beta release. What you mention 
is public beta release ....
ICarii
30-Jun-2007
[3535]
ah ok
Pekr
30-Jun-2007
[3536]
I expect extended beta release comes at least here to AltME folks 
.... but can't be sure of course ....
PhilB
30-Jun-2007
[3537]
do we have any news on whether viewand/or vid will be included with 
the Beta?
Pekr
30-Jun-2007
[3538]
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 ...
Gabriele
30-Jun-2007
[3539]
vid will be there, so we'll be a bit late.
Pekr
30-Jun-2007
[3540]
Gabriele - could you say few words about new VID? I will try to not 
ask about details, but I would welcome some general information ...
Gabriele
1-Jul-2007
[3541]
a litttle more patience :)
Jerry
13-Jul-2007
[3542]
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?
amacleod
13-Jul-2007
[3543x2]
x x xxb   bxgb      z
Sorry, my kid must have tried to be a "reboler" too.
btiffin
14-Jul-2007
[3545]
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.
Gabriele
14-Jul-2007
[3546]
jerry, what would you need 8-bit chars for?
Jerry
14-Jul-2007
[3547]
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.
Kaj
14-Jul-2007
[3548]
I think there were going to be VECTOR!s for that
Jerry
14-Jul-2007
[3549]
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
    ]
]
Gabriele
14-Jul-2007
[3550x3]
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.
Jerry
14-Jul-2007
[3553]
Thanks Gabriele.