Ben Davies

The way I had planned out the work I'm doing for the IP6NS grant, there would be the same degree of support for IPv6 as there is for IPv4. This...

I think it'd be a good idea to have one unified address type, but I don't think that type is where DNS queries should be handled from, since there are...

Update: - The v6.c changes are certainly doable. - M̵o̵a̵r̵V̵M̵ ̵w̵i̵l̵l̵ ̵p̵r̵o̵b̵a̵b̵l̵y̵ ̵n̵e̵e̵d̵ ̵a̵n̵ ̵a̵s̵y̵n̵c̵ ̵D̵N̵S̵ ̵l̵i̵b̵r̵a̵r̵y̵ ̵o̵f̵ ̵s̵o̵m̵e̵ ̵s̵o̵r̵t̵ ̵i̵n̵ ̵o̵r̵d̵e̵r̵ ̵t̵o̵ ̵d̵o̵ ̵t̵h̵e̵ ̵v̵6̵.̵e̵ ̵c̵h̵a̵n̵g̵e̵s̵,̵ ̵a̵s̵ ̵t̵h̵i̵s̵ ̵i̵s̵...

The v6.e changes are doable as well! I tried to use c-ares to implement them on MoarVM, but I found there were a couple of issues with it that made...

My design for how DNS resolution should be implemented has changed since my previous posts here. There is now an `IO::Resolver` role, which stubs a single `lookup` method for resolving...

Which resolver `IO::Socket::INET` and `IO::Socket::Async` use is already configurable with the `$*RESOLVER` variable and `:$resolver` parameters in their methods that depend on it, so not having `IO::Resolver::Stub` or `IO::DNS` in...

I propose adding the following methods: - `Routine.multi_declarator` Returns the multi declarator the routine was declared with (or `Nil` if there is none). - `Routine.declarator` Returns the routine declarator the...

> You mean, whether the routine is a `multi` or not? Isn't that already available in the `Routine.multi` bool? I mean if it was declared with `proto`, `multi`, or `only`....

I think v6.e should deprecate the current behaviour of `IO::Socket::INET.new` and have methods something like this for socket creation instead: ``` method new(::?CLASS:_: Bool:D :$listen, :$family, :$type, :$protocol --> ::?CLASS:D)...

I've been giving @jnthn's comment on https://github.com/Raku/nqp/pull/597 some more thinking and I don't think handling sockets like this will entirely work anymore. Not every backend provides a networking API that...