World: r3wp

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 :)

13 more sleeps.  :)

Gabriele - including VID prototype? :-)

yes.

hehe, cool! :-)

I think there are 22 alpha versions by now.

so many?

mainly bugfixes?

mainly bugfixes, but a few releases introduce new things (also things 
that have not been covered anywhere) :-)

not been covered? What do you mean? New features, which are going 
to be a surprise? :-)

any teasers? :-)

I don't know if they are surprising, they didn't take long to get 
in, and I don't know if they'll stay, but a few mundane things that 
are difficult to do in under 10 lines in R2 can be done in 1-2 lines 
in R3.

particularly operations on blocks

So, as for me, I don't expect to be functional - unicode, rif, rebin, 
plug-ins ....

ah, nice ... I found that Python has very nice block handling too, 
and I found some operations, which were not possible so easily in 
R2.

I hope rebcode is there already? :-) And that it was improved? And 
also that parser got some improvements, which were suggested for 
years? (not by me, but by others :-)

I think the main focus will be to make a good .dll core for now with 
a VID prototype. Getting that right first will make plugins, rif 
and all that easier.

wait, view is in the dll core?

rebcode is in there, but I haven't used it.

I actually don't know :-)

no, view is exe afaik

:-)

203 bugreports listed here.

and rebcode is there same way as unicode

wait, because unicode in fact is not supposed to be there, at least 
according to blog ...

but rebcode, at least in R2, was factual implementation ....

so if rebcode is there just as a wrapper = datatype to be recognised, 
but you can't actually use it, then it is not there :-)

I tried a lot of the bug reports in RAMBO that crash R2 just for 
fun, and R3 handles them just fine. Of course the code has been rewritten, 
so you can't make a direct comparison, but it looks to me as Carl 
was going through RAMBO in order to avoid making those mistakes, 
or the code quality has just improved for R3.

Henrik - it was the same with R1 vs R2 ... R1 was slow, it did not 
contain even networking, and was some 400 KB big. Then came secret 
Contra project, later released as Core 2.0, and including networking, 
it was actually some 150KB in size, much more stable and much more 
faster ...

Rewrites are a healthy thing to do. :-)

I don't expect R3 core being any faster, but hopefully it will be 
natively extensible, and some strange GC bugs will be gone, or at 
least debuggable ...

the new trace is much more useful. you can see variable contents 
for example now.