[perl #131766] Specifying the source address of an outgoing connection using IO::Socket::*
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev # Please include the string: [perl #131766] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/Ticket/Display.html?id=131766 > It should be possible to specify the source address of outgoing (client) connections. This is especially useful if the machine has more than one IP address. Examples in other software: * wget supports --bind-address parameter: https://www.gnu.org/software/wget/manual/wget.html#Download-Options * Python accepts optional “source_address” parameter: https://docs.python.org/2/library/socket.html#socket.create_connection * “bind before connect”, a blog post that seems to be relevant: https://idea.popcount.org/2014-04-03-bind-before-connect/ * curl seems to allow it too, but surprisingly it can also accept the interface name: https://curl.haxx.se/docs/manpage.html#--interface It is possible to find more examples of languages that support it, but I'm sold already. My best guess is that it is doable by simply calling uv_tcp_bind for outgoing connections. Relevant links: * https://github.com/MoarVM/MoarVM/blob/2a79727deb78105c8c9f660a1136a3db1179b09b/src/io/asyncsocket.c#L532-L533 * https://github.com/MoarVM/MoarVM/blob/2a79727deb78105c8c9f660a1136a3db1179b09b/src/io/asyncsocket.c#L681-L683
Re: [perl #131686] [BUG] [X] @list-of-lists misbehaves with list of one list
In my opinion, to decide whether it's a bug, you shouldn't look at the implementation of [X] and [X*], but rather at its practical use. In what cases would you use it, and what do you expect it to return when your list of lists happens to be one list? That's what I was trying to do with my example to determine the divisors of a number, given the prime factorization. (That was a simplified version of my actual code where I encountered the bug, and lost about half an hour figuring out what was happening.) If someone states the current behaviour is correct, I'd like them to come up with a practical example where [X] or [X*] currently does the right thing. But perhaps an even easier way to look at it is: [X] (@a, @b, @c) is equivalent to @a X @b X @c [X] (@a, @b) is equivalent to @a X @b so [X] (@a,) is equivalent to @a and [X*] (@a, @b, @c) is equivalent to @a X* @b X* @c [X*] (@a, @b) is equivalent to @a X* @b so [X*] (@a,) is equivalent to @a
Re: [perl #131686] [BUG] [X] @list-of-lists misbehaves with list of one list
In my opinion, to decide whether it's a bug, you shouldn't look at the implementation of [X] and [X*], but rather at its practical use. In what cases would you use it, and what do you expect it to return when your list of lists happens to be one list? That's what I was trying to do with my example to determine the divisors of a number, given the prime factorization. (That was a simplified version of my actual code where I encountered the bug, and lost about half an hour figuring out what was happening.) If someone states the current behaviour is correct, I'd like them to come up with a practical example where [X] or [X*] currently does the right thing. But perhaps an even easier way to look at it is: [X] (@a, @b, @c) is equivalent to @a X @b X @c [X] (@a, @b) is equivalent to @a X @b so [X] (@a,) is equivalent to @a and [X*] (@a, @b, @c) is equivalent to @a X* @b X* @c [X*] (@a, @b) is equivalent to @a X* @b so [X*] (@a,) is equivalent to @a
[perl #131686] [BUG] [X] @list-of-lists misbehaves with list of one list
On Tue, 18 Jul 2017 07:45:16 -0700, joshu...@gmail.com wrote: > My thinking is that doing `[X] ((3,2),)` is kinda like doing `[X] > ((3,2),Empty)`... Assuming I understand your analogy correctly, that's exactly what's *not* happening, and is why this RT exists. See: dd [X] 3, 2; # ((3, 2),).Seq dd [X] (3, 2); # ((3, 2),).Seq dd [X] ((3, 2),); # ((3, 2),).Seq The first two are unsurprising, but note how the third one is *also* being treated as the Cartesian product between the two sets `3` and `2`, rather than the single set `(3, 2)`. Also, scenarios where the argument list to `[X]` or `[Z]` is fixed-sized (like in these examples), isn't what is tripping people up (because there's no reason to write that in the single-sublist case anyway). The problem is with crossing or zipping a variable-sized list of lists, like in `my @transpose = [Z] @matrix;`, which works fine for most inputs but breaks down for the "@matrix has exactly one row" edge-case. I've explained why this is happening and why it ruins people's day in this docs ticket: [1], and this StackOverflow answer: [2]. --- [1] https://github.com/perl6/doc/issues/1400 [2] https://stackoverflow.com/questions/44821983/recursive-generator-manual-zip-vs-operator/44831926#44831926
[perl #131764] Passing stdin to Proc::Async mostly does not work ($proc.print: …; $proc.close-stdin)
Alright, it seems that rakudo is not entirely incorrect here. See this
discussion: https://irclog.perlgeek.de/perl6-dev/2017-07-18#i_14885863
TL;DR, one should use something like this:
whenever $proc.print(“one\ntwo\nthree\nfour”) { $proc.close-stdin }
So it seems that it's not a bug, but a trap maybe?
I'll leave this for somebody else to close.
On 2017-07-17 22:45:01, alex.jakime...@gmail.com wrote:
> Code:
>
> sub get-output() {
> my $proc = Proc::Async.new: :w, ‘head’, ‘-n’, ‘1’;
> my $success;
> react {
> whenever $proc.stdout { $success = True }
> whenever $proc.start { die ‘FAIL!’ unless $success }
>
> $proc.print: “one\ntwo\nthree\nfour”;
> $proc.close-stdin;
> }
> say $++;
> }
>
> loop { get-output }
>
>
> Again, the result depends on your luck. Ideally it should not “die”
> ever, because there should always be one line in the output and
> therefore $success will be set to true. However, sometimes its stdout
> is empty and therefore it fails. It may fail after 20+ executions, and
> sometimes it fails almost immediately.
>
> Related ticket: https://rt.perl.org/Ticket/Display.html?id=131763
[perl #131764] Passing stdin to Proc::Async mostly does not work ($proc.print: …; $proc.close-stdin)
$proc.print is asynchronous while $proc.close-stdin is not. In some cases $proc simply does not get the input because we closed its stdin before printing anything. If .close-stdin is meant to by synchronous, this needs a doc patch. Otherwise we'd probably need to await any outstanding write promises before performing the actual nqp::closefh.
