World: r3wp

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.

currently the GC outputs every time it GCs, but I don't know if that 
will become a debug functionality as it's just being printed unconditionally 
on the console right now.

hmm, it would be nice to have some debug hooks, for folks like you 
to being able to build proper debugger :-)

My biggest fear is when R3 comes out... it will have so many new 
things, areas to cover, projects that will be made possible. It's 
seriously going to require at least 50 people to cover it all, and 
it will take a long time to cover it all and I think R3 will be vastly 
under utilized for the first 1-2 years, possibly longer, if people 
won't join up to fight for the cause.

It's amazing to think that this little nucleus that is R3 will make 
all that possible. I keep thinking that if PHP is a firecracker, 
Python is a handgrenade, Ruby is a box of dynamite, R3 will be a 
nuclear bomb.

Then I like bombs :-)

The champignon shape is so beautiful! ;-)

yes, I always have to wear welding googles, when coding Rebol :-)