[32940] in Perl-Users-Digest
Perl-Users Digest, Issue: 4216 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon May 19 14:09:21 2014
Date: Mon, 19 May 2014 11:09:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Mon, 19 May 2014 Volume: 11 Number: 4216
Today's topics:
Re: A question about grep <rweikusat@mobileactivedefense.com>
Re: Correct design for parallel opening of sockets to r <ben.usenet@bsb.me.uk>
Re: Correct design for parallel opening of sockets to r <news@lawshouse.org>
Re: Correct design for parallel opening of sockets to r <ben.usenet@bsb.me.uk>
Re: Correct design for parallel opening of sockets to r <rweikusat@mobileactivedefense.com>
Re: Correct design for parallel opening of sockets to r <m@rtij.nl.invlalid>
Re: Help with an operator precedence (?) puzzle <justin.1401@purestblue.com>
Re: Help with an operator precedence (?) puzzle <rm-dash-bau-haus@dash.futureapps.de>
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Re: Help with an operator precedence (?) puzzle <rm-dash-bau-haus@dash.futureapps.de>
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 19 May 2014 11:51:38 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: A question about grep
Message-Id: <87oayurqh1.fsf@sable.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> In article <8738g628cb.fsf@sable.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>>should also, should document the result when negating a false value,
>>which happens to be a 'special truth value' whose numerical value is
>>1 and whose string value is '1').
>
> I'm afraid I'm not following you. The negation of a true value does
> indeed have a slight difference from both normal '' and 0:
>
> $ perl -e 'use warnings; use strict; my $x = ""; print($x + 5, "\n"); print ("($x)\n");'
> Argument "" isn't numeric in addition (+) at -e line 1.
> 5
> ()
>
> $ perl -e 'use warnings; use strict; my $x = !1; print($x + 5, "\n"); print ("($x)\n");'
> 5
> ()
>
> But 1 or '1' has no such specialness: you can perform arithmetic with
> either without a warning, for example, and each converts to the other
> in the appropriate circumstances. In what way is the value of !0 a
> special value?
In exactly the same way as the other:
[rw@sable]~/work#perl -MDevel::Peek -e 'Dump(!0), Dump(!1)'
SV = PVNV(0x817a634) at 0x817851c
REFCNT = 2147483646
FLAGS = (PADTMP,IOK,NOK,POK,READONLY,pIOK,pNOK,pPOK)
IV = 1
NV = 1
PV = 0x817b618 "1"\0
CUR = 1
LEN = 4
SV = PVNV(0x817a620) at 0x817850c
REFCNT = 2147483647
FLAGS = (PADTMP,IOK,NOK,POK,READONLY,pIOK,pNOK,pPOK)
IV = 0
NV = 0
PV = 0x817a610 ""\0
CUR = 0
LEN = 4
In particular, it has all the *OK flags set from the start. Also, it is
"a special truth value" because there's an infinite set of other values
which are also regarded as 'true' but this particular one happens to be
used. As far as the documentaton goes, this
[rw@sable]~/work#perl -e 'use Scalar::Util "dualvar"; $a = dualvar(-9, "Wot?!?"); print("$a\n") if $a;'
Wot?!?
would just be as possible.
------------------------------
Date: Mon, 19 May 2014 02:53:41 +0100
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: Correct design for parallel opening of sockets to remote hosts?
Message-Id: <0.c24e112510e32299a470.20140519025341BST.87y4xy1ql6.fsf@bsb.me.uk>
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
<snip>
> [...] See IO::select.
I meant IO::Select of course.
> I am sure I could give you some code if it were not so late!
Not too late it seems. Here is a cut-down example based on you loop:
for my $host (@$hosts) {
my $fh;
if (open($fh, "-|")) {
$h_set->add($fh);
}
else {
my $delay = int(rand(10));
warn "[child] Simulating $delay seconds delay in contacting host $host->{name}.\n";
sleep $delay;
print STDOUT "data for $host->{name}"; # Simulating the data returned
warn "Child for $host->{name} finishing\n";
exit;
}
}
while (my @rd = $h_set->can_read) {
for my $fh (@rd) {
while (my $data = <$fh>) {
print "[Parent] Read '$data'\n";
}
$h_set->remove($fh);
close $fh ||
warn "Child process has exited: $?\n";
}
}
--
Ben.
------------------------------
Date: Mon, 19 May 2014 08:05:14 +0100
From: Henry Law <news@lawshouse.org>
Subject: Re: Correct design for parallel opening of sockets to remote hosts?
Message-Id: <9oWdncIy0OqqMOTOnZ2dnUVZ8lCdnZ2d@giganews.com>
On 19/05/14 02:53, Ben Bacarisse wrote:
> Not too late it seems.
You stayed up till 3AM writing code to help me! That's an extra mile
and a half.
Here is a cut-down example based on you loop
Thank you very much. I've worked it up and incorporated it into my code
and it's exactly right.
I knew it would be simple if someone who knew what he was talking about
worked on it. And by extension I have a tutorial on IO::Select, which
I'd never worked with before.
--
Henry Law Manchester, England
------------------------------
Date: Mon, 19 May 2014 10:16:07 +0100
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: Correct design for parallel opening of sockets to remote hosts?
Message-Id: <0.752193f3a5803caef412.20140519101607BST.87r43q163s.fsf@bsb.me.uk>
Henry Law <news@lawshouse.org> writes:
> On 19/05/14 02:53, Ben Bacarisse wrote:
>> Not too late it seems.
>
> You stayed up till 3AM writing code to help me! That's an extra mile
> and a half.
Well, I happened to be up *and* a wrote a little code. Not exactly the
same! Anyway, I'm glad it was helpful.
<snip>
--
Ben.
------------------------------
Date: Mon, 19 May 2014 15:15:00 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Correct design for parallel opening of sockets to remote hosts?
Message-Id: <877g5hc0t7.fsf@sable.mobileactivedefense.com>
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> <snip>
>> [...] See IO::select.
>
> I meant IO::Select of course.
>
>> I am sure I could give you some code if it were not so late!
>
> Not too late it seems. Here is a cut-down example based on you loop:
>
> for my $host (@$hosts) {
> my $fh;
> if (open($fh, "-|")) {
> $h_set->add($fh);
> }
> else {
> my $delay = int(rand(10));
> warn "[child] Simulating $delay seconds delay in contacting host $host->{name}.\n";
> sleep $delay;
> print STDOUT "data for $host->{name}"; # Simulating the data returned
> warn "Child for $host->{name} finishing\n";
> exit;
> }
> }
Instead of doing this, it should usually also be possible to switch all
sockets to non-blocking mode prior to calling connect and then select
for 'writable'. This means a so-called 'non-blocking connect' will be
done by the kernel and each socket with some kind of 'final result'
available (connection established or an error occured while trying) will
become writable.
Another, possibly simpler idea would be to connect all 'connecting
processes' to the same pipe and let them write the name/ address of the
host they're connecting to to that upon success. The supervisor process
can then just do a blocking read on the pipe, dealing with the results
as they arrive. Once the last 'connecting process' has exited, trying to
read from the pipe will return 'an EOF' (aka 'read of size 0').
NB: While that's a nice and simple idea, it is probably somewhat beyond
the abilities of the available 'canned system call wrappers'.
------------------------------
Date: Mon, 19 May 2014 20:04:50 +0200
From: Martijn Lievaart <m@rtij.nl.invlalid>
Subject: Re: Correct design for parallel opening of sockets to remote hosts?
Message-Id: <2ntp4b-bv3.ln1@news.rtij.nl>
On Mon, 19 May 2014 01:55:31 +0100, Ben Bacarisse wrote:
>>
>> My head is spinning. I wake up thinking about fork statements and
>> zombie processes ... There's an easy answer to this; can someone help
>> me find it?
...
> If instead of looping to read each child's output in turn (which will be
> sub-optimal since you can't be sure to read the data in the order it
> becomes available),
If you need all the results, it is not sub optimal, but almost optimal
and much simpler to program.
And using Parallel::ForkManager makes it almost trivial.
HTH,
M4
------------------------------
Date: Mon, 19 May 2014 09:55:41 +0100
From: Justin C <justin.1401@purestblue.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <dhto4b-vdk.ln1@zem.masonsmusic.co.uk>
On 2014-05-17, Martijn Lievaart <m@rtij.nl.invlalid> wrote:
> On Fri, 16 May 2014 09:27:29 -0700, Jürgen Exner wrote:
>
>> "Dave Saville" <No-Spam@deezee.org> wrote:
>>>Recently been involved in an project where the original authors were cut
>>>n paste happy. The lead programmer of today christened it "the curse of
>>>the duplicated code"
>>
>> Oh come on. I am waaaaayyyyy more productive than you are, I produce 5
>> times the number of lines of code.
>> And lines of code is the only thing the bean counters and penny pinchers
>> know how to measure .....
>
> My most productive sessions have a negative LOC count.
Amen.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Mon, 19 May 2014 13:24:42 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <5379e9fa$0$6661$9b4e6d93@newsspool3.arcor-online.net>
On 18.05.14 14:50, Rainer Weikusat wrote:
> and is a conditional operator supposed to evaluate its right hand
> operand when evaluating its left-hand operand yielded a true value.
> 'comma' is a sequencing operator supposed to evaluate it's right-hand
> operand after evaluating its left-hand operand, regardless of the value
> that resulted in.
>
> $frog = 'green' and return if blort();
>
> causes a compiler warning because the compiler assumed, based on the
> fact that and was used despite the left-hand operand always evaluates to
> true, that someone might erroneously have used an assignment operator
> ('=') instead of a comparison operator ('=='), IOW, that the complex
> 'unconditional' expression was meant to be a conditional
> expression. Considering that it wasn't, using an operator without this
> property, ie
>
> $frog = 'green', return if blort();
>
> seems like a pretty natural choice.
The choice seems to match the nature, and possibly the interest,
of a competent Perl consultant, since interpreting it correctly
requires substantial knowledge of Perl, as you have explained (when
referring to existing code). The choice becomes a less
natural one as soon as one considers the structural ambiguity
that remains. The grouping is unclear when compared to a "more"
natural use of language; "natural" in the sense of "usual",
even in programming languages. Rephrasing the comma,
"First,
C<$frog = 'green',>
"and after that, while ignoring the result of what is before C<,>",
C<return if blort();>
Now, where is the "break" (non-Perl term) in the second part?
The ambiguity that remains is one of grouping: What, in natural
understanding, does C<..., return if ...> mean? Actually, I
mean, referring to programmers' trying to understand, not to
Perl interpreting the text.
If "nature" is referring to programmers in general, will an
uninitiated programmer understand correctly? Absurd as the following
interpretations might seem to the Perl savvy consultant, will
the line then be understood to mean
"assign only if and return only if",
thus to both assign and return conditionally? Or, again subtracting
the Perl savvy deciphering competence of the "natural" programmer,
could the line mean
"assign if and then return no matter what"?
Or, still,
"assign no matter what and then return if"?
All of the shortening seen requires a technical amount of inference
from Perl's definition. Which is why consultants might like it.
A reader may wish to learn the control flow instead. As a rule,
I try to put a maximum of one "flow indicator" on any single line.
Adding more always hurts the maintainer.
--
Georg Bauhaus
------------------------------
Date: Mon, 19 May 2014 16:52:30 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <871tvp935t.fsf@sable.mobileactivedefense.com>
"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
> On 18.05.14 14:50, Rainer Weikusat wrote:
>> and is a conditional operator supposed to evaluate its right hand
>> operand when evaluating its left-hand operand yielded a true value.
>> 'comma' is a sequencing operator supposed to evaluate it's right-hand
>> operand after evaluating its left-hand operand, regardless of the value
>> that resulted in.
>>
>> $frog = 'green' and return if blort();
>>
>> causes a compiler warning because the compiler assumed, based on the
>> fact that and was used despite the left-hand operand always evaluates to
>> true, that someone might erroneously have used an assignment operator
>> ('=') instead of a comparison operator ('=='), IOW, that the complex
>> 'unconditional' expression was meant to be a conditional
>> expression. Considering that it wasn't, using an operator without this
>> property, ie
>>
>> $frog = 'green', return if blort();
>>
>> seems like a pretty natural choice.
>
> The choice seems to match the nature, and possibly the interest,
> of a competent Perl consultant, since interpreting it correctly
> requires substantial knowledge of Perl, as you have explained (when
> referring to existing code). The choice becomes a less
> natural one as soon as one considers the structural ambiguity
> that remains. The grouping is unclear when compared to a "more"
> natural use of language; "natural" in the sense of "usual",
> even in programming languages. Rephrasing the comma,
>
> "First,
> C<$frog = 'green',>
>
> "and after that, while ignoring the result of what is before C<,>",
> C<return if blort();>
>
> Now, where is the "break" (non-Perl term) in the second part?
This is a nice opportunity to post one of my first actual uses of the
comma-operator in C (which can't be reproduced in Perl because someone
fell prey to "Dangling else"-hoax (OMG! Differents amounts of nothing
not giving raise to dom!!) when designing it). It's (the body of) and
implementation of strcpy, namely
while (*d = *s) ++d, ++s;
Obviously, using the same reasoning, one can interpret an ambiguity into
this as well, namely, as the obviouly either endless or nothing at all
loop
while (*d = *s) ++d
followed by a lone ++s in case the loop terminated, however, the grammar
of the language says it ain't so. After the while (expression), there's
a statement which is the expression-statement ++d, ++s; in this case.
And the same is true for Perl: A 'simple statemenent' is an expression
evaluated for its side effects, eg
$frog = 'green', return
and a (single) 'statement modifier' may be attached to this statement in
order impose a condition on its execution.
[...]
> If "nature" is referring to programmers in general, will an
> uninitiated programmer understand correctly?
When I have to learn a new programming language, I start with reading
the documentation, at least thorough enough that I generally know what
it says and where to look in case I'm stuck. This has proven to be very
helpful over the course of some years and I can only wholeheartedly
recommend it.
------------------------------
Date: Mon, 19 May 2014 18:41:13 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <537a3428$0$6665$9b4e6d93@newsspool3.arcor-online.net>
On 19.05.14 17:52, Rainer Weikusat wrote:
> Obviously, using the same reasoning, one can interpret an ambiguity into
> this as well,
Yes, this is similar, though not equal reasoning, about comma in Perl
vs comma in C. And it illustrates the point: The consistency of
any such reasoning offers an opportunity for the consultant to keep
the "natural" ambiguities in programs (and languages) and then
recommend trained staff to resolve the "naturally" ensuing issues.
I think universities should teach "artificial complexity". The
subject might, paradoxically, sharpen students' awareness of language
definitions, since it means money for syntax experts.
------------------------------
Date: Mon, 19 May 2014 18:24:44 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87wqdh7kbn.fsf@sable.mobileactivedefense.com>
"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
> On 19.05.14 17:52, Rainer Weikusat wrote:
>> Obviously, using the same reasoning, one can interpret an ambiguity into
>> this as well,
>
> Yes, this is similar, though not equal reasoning, about comma in Perl
> vs comma in C. And it illustrates the point: The consistency of
> any such reasoning offers an opportunity for the consultant to keep
> the "natural" ambiguities in programs (and languages) and then
> recommend trained staff to resolve the "naturally" ensuing issues.
>
> I think universities should teach "artificial complexity". The
> subject might, paradoxically, sharpen students' awareness of language
> definitions, since it means money for syntax experts.
Except that it sounds vaguely repulsive, I have no idea what this is
supposed to mean ...
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 4216
***************************************
