World: r3wp

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.

But, you started it. ;) -- all related to the meaning of "quit"

What about suggested names to FOR-ALL? Not important, but there were 
some suggestions in related tickets (and blog) ... e.g. FORFOUND 
(sounds a bit weird, so maybe FORFIND)? :-)

The question on tuples was related to IPv6 addresses. Just thinking 
about how the 128 bits might map into a type and syntax.

Having a different datatype for IPv6 addresses would pay off in practice 
- the networking code would be more efficient. Even if that other 
type is binary!, you would get better efficiency as long as it isn't 
tuple.

I'm all for having an IPv6 type.

And that doesn't even get into the syntax issues: IPv6 syntax is 
really different, not the same as dotted. A different type would 
allow different syntax. But that syntax is really specific, only 
used for that one thing, and not necessarily a very common thing 
at that (do you tend to type out IPv6 addresses, or the domain names 
that refer to them?). It's not like tuples, that get used outside 
of the networking realm. It really might not be bad to just use strings 
for the IPv6 syntax, and binaries for the decoded values. We don't 
have to wait for syntax changes to get started. And once we get something 
running, the syntax changes would be easier to justify :)

yeah the ipv6 addresses really are different.

They are quite a complex data structure, or can be.


Perhaps a first step would be for someone to write a parse rule to 
identify/vaidate IPv6 strings and, optionally, translate them to 
a normative form.


Link to someone who has made  a stab at a BNF defintion for  IPv6, 
and then produced a regex:

   http://crisp.tweakblogs.net/blog/2031/ipv6-validation-%28and-caveats%29.html

funny how all of his problems seem to disapear when we look at it 
with a parse mindset  :-)

PEG beats BNF :)

but even the BNF is something I can use almost directly in parse 
and its easy.   now trying to use that in regexp or a loop/conditionals 
driven function ... yeah... mental.

I stripped all rule tracing from the following. Tests not included 
either, to save space here.

ipv6-parser-ctx: context [
    IPv6address: [
        (=IPv6address: none)
        copy =IPv6address [

                                           6 [h16 ":"] ls32     ; 8

            |                         "::" 5 [h16 ":"] ls32     ; 7

            | opt [h16]               "::" 4 [h16 ":"] ls32     ; 6-7   0-1::6

            | opt [h16 0 1 [":" h16]] "::" 3 [h16 ":"] ls32     ; 5-7   0-2::5

            | opt [h16 0 2 [":" h16]] "::" 2 [h16 ":"] ls32     ; 4-7   0-3::4

            | opt [h16 0 3 [":" h16]] "::"    h16 ":"  ls32     ; 3-7   0-4::3

            | opt [h16 0 4 [":" h16]] "::"             ls32     ; 2-7   0-5::2

            | opt [h16 0 5 [":" h16]] "::"    h16               ; 1-7   0-6::1

            | opt [h16 0 6 [":" h16]] "::"                      ; 0-7   0-7::0
        ]
    ] 
    h16: [
        (=h16: none)

        copy =h16 mark: 1 4 HEXDIG ;(print ['h16 mold =h16  mold mark])
    ] 
    ls32: [
        (=ls32: none)
        copy =ls32 [[h16 ":" h16] | IPv4address]
    ] 
    IPv4address: [
        (=IPv4address: none)

        copy =IPv4address [dec-octet "." dec-octet "." dec-octet "." dec-octet]
    ] 
    charset-1: (charset [#"1" - #"9"]) 
    charset-2: (charset [#"0" - #"4"]) 
    charset-3: (charset [#"0" - #"5"]) 
    dec-octet: [
        copy =dec-octet [
              "25" charset-3               ; 250-255
            | "2"  charset-2 DIGIT         ; 200-249
            | "1"  2 DIGIT                 ; 100-199
            | charset-1 DIGIT              ; 10-99
            | DIGIT                        ; 0-9
        ]
    ]
    DIGIT: charset "0123456789"
    HEXDIG: charset "0123456789ABCDEFabcdef"
    

    set 'parse-ipv6-address func [address [any-string!]] [
        reduce [parse/all address IPv6address  =IPv6address]
    ]
]

It's a mechanical translation of the ABNF, with some rules reordered 
for PARSE.

Is it worth pursuing? If so, what should be next?

Dealing with the formatted addresses is kind-of the last step. The 
first step in looking at the native TCP code and seing what needs 
to be done to support connecting over IPv6. There might be some native 
API changes required.