World: r3wp

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

A110 released.

Btw, as of alpha 108, bug#885 has upgraded itself to a potential 
crash bug, though it is partially fixed in other ways. See here for 
details: http://www.curecode.org/rebol3/ticket.rsp?id=885

Ok... odd.

I'm testing again with a110.

Same behavior.

The ASSERT in FIND-ALL has SERIES! instead of SERIES?. Doesn't affect 
the behavior normally, but doesn't screen for the error either.

I noticed that FIND-ALL is just as Scheme-like as ANY-OF and ALL-OF 
:)

lol ;)

Ok, A110 is out, but I'm going to be away for 2 days. I'll try to 
check-in to see if there are any questions here.

I'll add a ticket for the FIND-ALL bug (it's minor and only affects 
erroneous code).

will Maxim's #1716 be resolved somehow?

Yes, but we haven't yet determined the option name. Delayed embedded 
extensions should work now though.

Do I recall correctly that there was a reason tuple! values couldn't 
be extended to 16 slots?
 - yes

Is the safe R3 way to execute a script to use:
   do load %script-name
rather than R2's way:
   do %script-name
?


The reason I ask is the different behaviours I see here (I'd expect 
them both to print a 1)....
    n: 1 try [do %test-script.r ] print n
    n: 1 try [do load %test-script.r ] print n

....where test-script.r is these two lines:
    rebol []
    0 / 0

Yes, that difference is related to bug#851

Thanks.....Looks like you and Brian have some deep dialog going around 
those issues.
Hope it all comes clear in the end :)

B: I figure funcs like FIND-ALL will go thru various stages of revision.

B, P: probably post lib should be extension default. Then we can 
just add prelib as word for those done prior.


This can be added to A111.  For now, use delay, as Brian mentioned.

If you need a 16 slot tuple, you're using the wrong datatype.

Sunanda, yes... a bug we know about.