World: r3wp

There is still a lot of work haead. It will take 1 and half year...

Well, in last 3-4 month, look at the roadmap, and all those already 
completed things. Some VERY significant changes happened lately (host-kit, 
View transition to being fully external, modules, etc.)

You can always wait for the next release or until you have all dreamed 
on features. Whatevery product you use. It's about taking what you 
have and making the best from it.

in my opinion, R3 is already useable, apart from GUI, maybe pop, 
ftp, proxy support (nowadays I don't need it though), and ugly console 
:-)

Depends on your needs.

Actually what is stopping me from using REBOL3 is the lack of GUI 
and SQLite support but I have them in REBOL2 and I'll continue using 
it.

In REBOL3 I am only a spectator. I do not complain on the time it 
gets to be complete. I do not need the very last feature. I am passionate 
about the work you are doing on it. It is very hard.  It is nice 
to see you, genius, at work.

Finally implemented http://curecode.org/rebol3/ticket.rsp?id=637
thanks to a bugfix in alpha 108.

Congratulations

My dreamed feature is to have a release, instead of a not-for-distribution 
- which effectively doesn't exist

Please reconsider http://www.curecode.org/rebol3/ticket.rsp?id=1734.

Checking... I thought it was still open.

Added clarification. Changed bug status.

Thanks.

The question is what a script writer should do.

And I guess the answer is always using QUIT/now/return.

No, you don't want to do that.

The example script you gave is valid: for what you've written, I 
consider there to be a bug.

Can we have this particular bug fixed in A110 :) ?

I need a reliable way to QUIT with a return value from a script. 
But I do not know how this script is called.

Fixed in A110.

Great!

A friend of mine is asking about support for IPV6 addresses in REBOL 
3. he figured that REBOL 3 would have to support 128-bit numbers. 
I told him that there might be a separate datatype for it, but would 
it possible or would there a different way?

We can keep the addresses in strings, and the decoded addresses in 
binary data, and then make R3 support IPv6 without syntax changes 
(except to the URL parser). In theory.

my friend was interested in comparing address ranges, which was why 
he wanted to map them to 128-bit numbers.

If the addresses are stored in binary then the comparisons can be 
done on the binary values. Almost no system that supports IPv6 has 
or uses 128bit numbers.

ok

Almost no system = no system at all that I am aware of, but maybe 
there are mainframes or super computers out there that use 128bit 
numbers and have IPv6 support :)

Hey, the VAX had 128-bit integers, IIRC :)

perhaps this could be used: http://gmplib.org/

(he keeps asking for large-number support :-))

Andreas, coincidentally, he owns and actively uses a VAX :-)

Hehehe. Well, that's probably where that comes from :)

Do I recall correctly that there was a reason tuple! values couldn't 
be extended to 16 slots? I don't know that it's a great idea to map 
IPv6 addresses to them, or the feasibility of adding an ipv6! type. 
A utype! may be good enough, but I don't know how those are going 
to work either.

I use VAX 6151 SX - http://www.simsim.lv/published/publicdata/WEB59DB1/attachments/SC/products_pictures/m_120311_VAX6151SX.jpg

:-)

If we go all out for IPv6 integration then we can do a utype or even 
a built-in type with syntax (utypes won't have literal syntax). But 
we don't need to do that to get IPv6 support; we can get that now 
using the existing datatypes and some functions to work on the data, 
in theory.

yeah, as long as the functions know its an ipv6, there's nothing 
stopping us... in the end, its only bits  ;-)

Brian, You meant the vtypes not the utype, aka "the virtual types"
Huhu...

No, I meant utypes. That utype! datatype is short for user-defined 
datatypes, a planned feature (for R3.1). But literal syntax for utypes 
is *not* planned.

(I think Steeve was joking about utypes still being some virtual 
concept... after years of talk... ;-)

Oh, the "Huhu...". Sorry, cultural differences in depicting laughter 
in text :)

Yes, utypes are a bit vaporware right now. But we've given the concept 
a great deal of thought, and their constraints are known already.

before utypes, we could finish e.g. vectors, sound is non-existant 
too ... tasking, new codec model - still lots of things to do :-)

actually utypes are an enabler, much like extensions... I'd do them 
just after tasks.

but since its been decided they'll be for R3.1, I'm bitting my tongue 
in asking for them.

You know our rules Max :-)
All askings break down in the  Brian's FIFO.
(First In - Fail Out)

I'm not the one who set *that* priority. I need utypes more than 
most of you (except maybe Maxim).

If you're going to complain about something I did, I have nicely 
provided an excellent example with the a109 module system bugs.

Sure, but you sound like a good culprit :-)

just a joke Brian

I know, which is why I was going with it :)