[32942] in Perl-Users-Digest
Perl-Users Digest, Issue: 4218 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed May 21 09:09:23 2014
Date: Wed, 21 May 2014 06:09:05 -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 Wed, 21 May 2014 Volume: 11 Number: 4218
Today's topics:
Re: A question about grep (Tim McDaniel)
Re: A question about grep <whynot@pozharski.name>
Re: A question about grep <rweikusat@mobileactivedefense.com>
Re: A question about grep <rweikusat@mobileactivedefense.com>
Re: Correct design for parallel opening of sockets to r <rweikusat@mobileactivedefense.com>
Re: Correct design for parallel opening of sockets to r <ben.usenet@bsb.me.uk>
Re: Help with an operator precedence (?) puzzle <hjp-usenet3@hjp.at>
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 <rm-dash-bau-haus@dash.futureapps.de>
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Re: Help with an operator precedence (?) puzzle <rweikusat@mobileactivedefense.com>
Re: Push regex search result into hash with multiple va <ben.usenet@bsb.me.uk>
Re: Push regex search result into hash with multiple va <rvtol+usenet@xs4all.nl>
Re: Push regex search result into hash with multiple va fmassion@web.de
Re: Push regex search result into hash with multiple va <justin.1401@purestblue.com>
search.cpan.org <gravitalsun@hotmail.foo>
Re: search.cpan.org (Jens Thoms Toerring)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 20 May 2014 06:10:20 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: A question about grep
Message-Id: <llerkc$o7f$1@reader1.panix.com>
In article <87oayurqh1.fsf@sable.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>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.
I'm sorry, but I don't have any idea what that output might mean.
When I ran the same one-liners, but with $x = 1 the first time and !0
the second time, in both cases they output
6
(1)
without any messages, unlike the !1 case. So from the point of view
of the user, at least in this test there is nothing special about the
value produced by !0 -- it appears to act identically to 1 regardless
of what the perl internals happens to represent it. So, so far as I
can tell, there's nothing special about it.
>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.
I think that's a much weaker definition of "special". Yes, it could
choose an unbounded number of possible true values, and one of a few
possible false values, but there need not be anything further
unusual. In fact, for truth it does not choose a dualvar of -9 and
"Wot?!?", but an apparently ordinary 1. But !1 is special other than
being a particular fixed value.
--
Tim McDaniel, tmcd@panix.com
------------------------------
Date: Wed, 21 May 2014 09:37:15 +0300
From: Eric Pozharski <whynot@pozharski.name>
Subject: Re: A question about grep
Message-Id: <slrnlnoicr.q2f.whynot@orphan.zombinet>
with <llerkc$o7f$1@reader1.panix.com> Tim McDaniel wrote:
> In article <87oayurqh1.fsf@sable.mobileactivedefense.com>,
> Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
*SKIP*
>>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.
> I think that's a much weaker definition of "special". Yes, it could
> choose an unbounded number of possible true values, and one of a few
> possible false values, but there need not be anything further unusual.
> In fact, for truth it does not choose a dualvar of -9 and "Wot?!?",
> but an apparently ordinary 1.
There outght to be a module for fine tuning this.
> But !1 is special other than being a particular fixed value.
That's why I don't read Rainer -- he always messes things. Probably
time will cure him and I'll enjoy his company too (probably, time will
cure me and Rainer won't be my problem anymore). Anyway:
% perl -MDevel::Peek -wle 'Dump !1; Dump 0; Dump ""; Dump undef'
SV = PVNV(0x945d688) at 0x945b524
REFCNT = 2147483647
FLAGS = (PADTMP,IOK,NOK,POK,READONLY,pIOK,pNOK,pPOK)
IV = 0
NV = 0
PV = 0x945d680 ""\0
CUR = 0
LEN = 12
SV = IV(0x9477f68) at 0x9477f6c
REFCNT = 1
FLAGS = (PADTMP,IOK,READONLY,pIOK)
IV = 0
SV = PV(0x945c760) at 0x947800c
REFCNT = 1
FLAGS = (PADTMP,POK,READONLY,pPOK)
PV = 0x947bfd8 ""\0
CUR = 0
LEN = 12
SV = NULL(0x0) at 0x945b510
REFCNT = 2147483608
FLAGS = (READONLY)
Do you see difference now? Then back to '!0':
% perl -MDevel::Peek -wle 'Dump !0'
SV = PVNV(0x8ebb6a0) at 0x8eb9538
REFCNT = 2147483644
FLAGS = (PADTMP,IOK,NOK,POK,READONLY,pIOK,pNOK,pPOK)
IV = 1
NV = 1
PV = 0x8ebc570 "1"\0
CUR = 1
LEN = 12
There's kind-of-special-perl-truth (IIRC, I've doen once something like
$count += !!$parsed; obviously '!0 + 0 == 42' would be totaly
unwelcome). However, either TRUTH or FALSE are made special inside
negation op (what renders negation op some kind of magic blender).
--
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom
------------------------------
Date: Wed, 21 May 2014 12:20:09 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: A question about grep
Message-Id: <87oayridjq.fsf@sable.mobileactivedefense.com>
tmcd@panix.com (Tim McDaniel) writes:
> Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>>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.
>
> I'm sorry, but I don't have any idea what that output might mean.
[...]
> So from the point of view of the user, at least in this test there is
> nothing special about the value produced by !0 -- it appears to act
> identically to 1 regardless of what the perl internals happens to
> represent it. So, so far as I can tell, there's nothing special about
> it.
AFAICT, there's nothing special about the 'special false value', either,
it behaves just like any other empty string:
[rw@sable]~#perl -e '$v = ""; print $v + 3; $v = !"a"; print $a + 3;'
33[rw@sable]~#
...
The difference is this here (irrelevant parts deleted):
FLAGS = (IOK,NOK,POK,pIOK,pNOK,pPOK)
This signifies a multivalue object which is 'ok to use as integer'
(IOK), 'ok to use as floating point number' (NOK) and 'ok to use as a
string' (POK) [AFAIK, the p-prefix flag mean "privately OK ..." but I
didn't examine the source to determine what this exactly means]. This is
a property ordinary Perl scalars don't usually have, cf
[rw@sable]~#perl -MDevel::Peek -e '$v = ""; Dump($v); $v += 0; Dump($v)'
SV = PV(0x81796d8) at 0x8195c80
REFCNT = 1
FLAGS = (POK,pPOK)
PV = 0x8190770 ""\0
CUR = 0
LEN = 4
SV = PVNV(0x817a9a4) at 0x8195c80
REFCNT = 1
FLAGS = (NOK,pNOK)
IV = 0
NV = 0
PV = 0x8190770 ""\0
CUR = 0
LEN = 4
and a side effect of that is that using such a 'special boolean scalar'
won't trigger warnings someone put into the type-conversion code. Such
warnings wouldn't happen for the 'special truth value' case, anyway, but
it is nevertheless constructed in the same way as the other.
>>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.
> I think that's a much weaker definition of "special".
It's another definition.
> Yes, it could choose an unbounded number of possible true values, and
> one of a few possible false values, but there need not be anything
> further unusual. In fact, for truth it does not choose a dualvar of -9 and
> "Wot?!?", but an apparently ordinary 1. But !1 is special other than
> being a particular fixed value.
Insofar 'external appearance' goes, it's not really different from any
other Perl-scalar which doesn't require a string-to-number conversion
for a non-numeric string value anymore:
[rw@sable]~#perl -we '$v = "bla"; { no warnings; $v += 0; }; $v += 0;'
[rw@sable]~#
AFAIK, after the embedded block, $v can be used as number as anyone
might see fit, without ever triggering a warning again (provided its
value doesn't change).
------------------------------
Date: Wed, 21 May 2014 12:22:30 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: A question about grep
Message-Id: <87k39fidft.fsf@sable.mobileactivedefense.com>
Eric Pozharski <whynot@pozharski.name> writes:
[...]
> That's why I don't read Rainer -- he always messes things. Probably
> time will cure him and I'll enjoy his company too (probably, time will
> cure me and Rainer won't be my problem anymore).
Neither the inbred assumption that whatever one doesn't understand MUST
surely be wrong (and a sign of a deranged mind) nor the habit to make
uncalled for nasty remarks about others for no particular reason does
usually become better with (even) old(er) age.
But good luck trying!
------------------------------
Date: Mon, 19 May 2014 20:14:50 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Correct design for parallel opening of sockets to remote hosts?
Message-Id: <87iop17f85.fsf@sable.mobileactivedefense.com>
Martijn Lievaart <m@rtij.nl.invlalid> writes:
> On Mon, 19 May 2014 01:55:31 +0100, Ben Bacarisse wrote:
[...]
>> 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.
'Almost optimal' is nothing but 'sub optimal'. Even leaving other issues
aside (eg - unsurprisingly - ForkManager also doesn't exit correctly
from child processes), this module is intended to be used in a situation
where a large number of parallellizable jobs are supposed to be executed
by a limited number of 'worker processes'. That's not applicable here.
------------------------------
Date: Mon, 19 May 2014 20:25:59 +0100
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: Correct design for parallel opening of sockets to remote hosts?
Message-Id: <0.6ea78887e155fd62a315.20140519202559BST.878upxzi2g.fsf@bsb.me.uk>
Martijn Lievaart <m@rtij.nl.invlalid> writes:
> 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.
Yes, there won't be much in it. I wonder what the maths says? It might
make a neat theoretical problem...
<snip>
--
Ben.
------------------------------
Date: Mon, 19 May 2014 23:33:17 +0200
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <slrnlnku4t.7k1.hjp-usenet3@hrunkner.hjp.at>
On 2014-05-19 11:24, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
> 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,
It requires knowledge of the comma operator and statement modifiers. I
consider both "basic Perl". In addition, the comma operator is present
in C and many languages derived from it (not in Java, though).
When writing Perl, assume that the readers of your code are Perl
programmers. Don't assume that they are Fortran or Java or Cobol
programmers (and of course, unless you are writing a tutorial for
beginners, don't assume that they aren't programmers at all).
Also, how do the alternatives
$frog = 'green' and return if blort();
do { $frog = 'green' } and return if blort();
require less "substantial knowledge of Perl"? How are they "more
natural" to a non-Perl programmer?
hp
--
_ | Peter J. Holzer | Fluch der elektronischen Textverarbeitung:
|_|_) | | Man feilt solange an seinen Text um, bis
| | | hjp@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
------------------------------
Date: Mon, 19 May 2014 22:55:14 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87y4xx5t8d.fsf@sable.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2014-05-19 11:24, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
>> On 18.05.14 14:50, Rainer Weikusat wrote:
[...]
>>> $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,
>
> It requires knowledge of the comma operator and statement modifiers. I
> consider both "basic Perl". In addition, the comma operator is present
> in C and many languages derived from it (not in Java, though).
>
> When writing Perl, assume that the readers of your code are Perl
> programmers.
While I agree that this is sensible, I think I sort-of understand the
reasoning behind Georg's standpoint: Practically, it can be assumed that
at least a sizable minority of 'programmers' (IMHO, 'a large majority'
seems more realistic) have encountered exactly one more-or-less formal
'programming language definition' in their life, namely, the one
which happened to be used in some long-forgotten undergraduate course
and even for that, they won't have spent more time dealing with than was
absolutely necessary to pass the exams, and any other "programming
language knowledge" will have been acquired in the course of a "someone
threw this heap of code at me and asked me to do something with it"
maneuvre. Even then, the natural reaction will likely not be "spend the
next 3 - 5 hours with familiarizing oneself with the docs" but rather "I
need to get shit[*] done quickly. What can I copy?".
[*] An eminent case of 'poetic justice' :->
------------------------------
Date: Tue, 20 May 2014 13:21:57 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <537b3ad5$0$6614$9b4e6d93@newsspool4.arcor-online.net>
On 19.05.14 19:24, Rainer Weikusat wrote:
>> 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 ...
What will motivate students of Perl to dive into a comparatively
large set of rules that will let them correctly use punctuation
in Perl?
A first group comprises programmers who take an interest in "clever"
uses of syntax, usually called "geeks" or logicians or similar.
Or Perl hackers just enjoying the odd parts of TIMTOWTDI. (I wouldn't
be surprised to read "elegant" in this context.)
Then there are those whose focus is on something else.
The first group does not need motivation. Its programmers
create correct, although "clever", code. (Even when the task is
simply to conditionally (assign and then return) ...)
Members of the second group will need a different incentive to
familiarize themselves with what it takes to understand clever
Perl expressions.
Conclusion:
If universities teach comparatively complex syntax, and also
make it known that real life offers only jobs involving the latter,
then both groups of students will see an incentive to become
familiar with the uses of comma, or with language definitions
in general. (Or some rebellion dispenses with heavily overloaded
punctuation in context. I doubt it.)
"Corollary":
Discussions such as "Help with an operator precendece (?) puzzle"
will no longer abound, or else get more intricate.
------------------------------
Date: Tue, 20 May 2014 13:24:06 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <537b3b55$0$6614$9b4e6d93@newsspool4.arcor-online.net>
On 19.05.14 23:33, Peter J. Holzer wrote:
>>> $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,
>
> It requires knowledge of the comma operator and statement modifiers. I
> consider both "basic Perl".
Comma is "basic", but not simple, as demonstrated by this thread.
The problem, however, *is* simple!
("IF bla-bla THEN <assign>; <return>; FI")
In the presence of TIMTOWTDI, a programmer is free to prefer more
or less obscure modes of statement, or reject them. Because they
seem boring, or because they take more than 1 line of code,
or because the programmer likes clever modes of statement, or
because a short statement clearly and briefly conveys the intent
---if it does, assuming the author knows the "audience".
> In addition, the comma operator is present
> in C and many languages derived from it (not in Java, though).
The presence of some comma operator in similar or related languages
makes discerning the comma even more tricky, in particular if you
frequently need to switch languages (Perl, C, sh, Python). A slight
change of meaning only adds pitfalls.
Unless, maybe, both the programmer and readers of the program are
in that luxurious position of using just one language.
Thus this comma requires thinking (obviously), a valuable resource
that could be spent on solving the "real" problem.
> Also, how do the alternatives
>
> $frog = 'green' and return if blort();
> do { $frog = 'green' } and return if blort();
>
> require less "substantial knowledge of Perl"? How are they "more
> natural" to a non-Perl programmer?
These, too, require substantial knowledge of Perl.
They, too, mix several aspects of: conditionality, precedence
(associativity), absence of presence of punctuation, ... all on 1 line.
Don't write English when programming! ;)
------------------------------
Date: Tue, 20 May 2014 22:01:49 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87mwecjhaa.fsf@sable.mobileactivedefense.com>
"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
> On 19.05.14 19:24, Rainer Weikusat wrote:
>>> 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 ...
>
> What will motivate students of Perl to dive into a comparatively
> large set of rules that will let them correctly use punctuation
> in Perl?
'punctuation' doesn't really exist in programming languages (there are
some exceptions, eg, the fact that a semicolon is optional after the
last statement in a block makes that 'a punctuation character' --
something which doesn't strictly have a meaning itself but which is
supposed to make 'perusing the text' easier for humans).
> A first group comprises programmers who take an interest in "clever"
> uses of syntax, usually called "geeks" or logicians or similar.
> Or Perl hackers just enjoying the odd parts of TIMTOWTDI. (I wouldn't
> be surprised to read "elegant" in this context.)
Did it already occur to you that something you consider to be clever,
possibly from a position of relative ignorance, might not at all seem
'clever' to anyone else? I also can't escape from the nagging suspicion
that something like a '... in the end, that's a masturbatory
exercise, but - oh well - people ...' is invisibly lingering around this
paragraph.
The programming language is there to help me and whoever came up with
the features considered them useful, presumably, based on some
experience he had I might still be lacking (it took me more than five
years of writing a lot of C before I encountered an "Oh! I really need
a postincrement here!" situation for the first time). Random 'first
example' of a statement similar to the one under discussion I found
$rc = rmdir($_[0]);
$rc or $sysc = "rmdir $_[0]", last;
That's part of a multi-step algorithm for deleting a directory
including its contents. It contains a few more 'error handling'
statements of the general form
<success> or sysc = <description of failure>, last
and turning these into
if ($rc) {
$sysc = "rmdir $_[0]";
last;
}
wouldn't exactly make the code easier to read as the
not-really-important parts would take up a lot more space.
[...]
> The first group does not need motivation. Its programmers
> create correct, although "clever", code. (Even when the task is
> simply to conditionally (assign and then return) ...)
Something which happens to be familiar to you isn't necessarily
inherently simpler than something else which isn't (although "familiar"
::= "good", "unfamiliar" ::= "bad" is an erroneous assumption many
people will happily make).
[...]
> Conclusion:
> If universities teach comparatively complex syntax, and also
> make it known that real life offers only jobs involving the latter,
> then both groups of students will see an incentive to become
> familiar with the uses of comma, or with language definitions
> in general.
In general, universities teach one thing: "How to get past the exams"
(maybe two things, "how to bed students of a suitable, other sex") ...
------------------------------
Date: Tue, 20 May 2014 22:08:09 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87iop0jgzq.fsf@sable.mobileactivedefense.com>
Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
[...]
> In general, universities teach one thing: "How to get past the exams"
> (maybe two things, "how to bed students of a suitable, other sex") ...
"21st century modification"
s/^(.*)ed st(.*), other (.*)/$1ed other st$2 $3/
(SCNR)
------------------------------
Date: Mon, 19 May 2014 20:22:08 +0100
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Subject: Re: Push regex search result into hash with multiple values
Message-Id: <0.2b11179c74f3b0bf9020.20140519202208BST.87egzpzi8v.fsf@bsb.me.uk>
fmassion@web.de writes:
> Thank you, Ben
>
>> These comments just create noise. If the reader does not know what the
>> commented line does, the comment won't really help.
>>
> Your're right.
>
>> use strict;
>> use warnings;
>>
> I've now done so until all Messages stating that a global symbol
> requires an explicit package Name disappear. However, I get no result
> anymore. If I use my previous code (without "my" and without "use
> strict" I get the results
>
> Here the new code:
> #!/usr/bin/perl -w
> use strict;
> use warnings;
> open(WORDLIST,$ARGV[0]) || die("Cannot open $ARGV[0]!\n");
> my @words = <WORDLIST>;
> close(WORDLIST);
> open(PHRASELIST,$ARGV[1]) || die("Cannot open $ARGV[1])!\n");
> my @phrase = <PHRASELIST>;
> close(PHRASELIST);
You need to have one @result array whose scope spans all uses, so put
my @results = ();
here.
> for my $phrase (@phrase) {
> chomp $phrase;
> for my $word (@words) {
> chomp $word;
> if ($phrase =~ m/\b$word\b/i) {
> my $found = $word."\t".$phrase;
> push (my @result, $found);
remove the "my" here and the one int the foreach below.
> print @result."\n";
> }}}
> foreach (my @result){ # go through the result array
> my ($word, $phrase) = split(/\t/,$_);
> print "$word --> $phrase\n";
> }
--
Ben.
------------------------------
Date: Tue, 20 May 2014 01:38:08 +0200
From: "Dr.Ruud" <rvtol+usenet@xs4all.nl>
Subject: Re: Push regex search result into hash with multiple values
Message-Id: <537a95e0$0$2974$e4fe514c@news2.news.xs4all.nl>
On 2014-05-19 19:22, Thomas 'PointedEars' Lahn wrote:
> Dr.Ruud wrote:
>> On 2014-05-19 11:42, Thomas 'PointedEars' Lahn wrote:
>>> it appears to be prudent to create a hash whose keys are the
>>> original keys, and the corresponding values are the quoted keys
>>
>> Or use the compiled regular expressions as values. Also because Perl
>> keeps moving forward with them.
>
> What do you mean by that?
It is mainly about the speed. In previous versions of Perl, keeping the
simple string version of a regular expression in a variable,
performed faster. So for a /$re/ in big loops, it paid off to use:
my $re = "some-regex";
in stead of:
my $re = qr/some-regex/;
But effort has been, and is still being, put in to make the qr// variant
the right choice in all normal contexts.
--
Ruud
------------------------------
Date: Tue, 20 May 2014 23:52:04 -0700 (PDT)
From: fmassion@web.de
Subject: Re: Push regex search result into hash with multiple values
Message-Id: <3ffec31f-2c5e-4ce1-a9c3-9f73a558e2ed@googlegroups.com>
Hi,
sorry to reply so late.
> my @results = ();
> here.
(...)
> remove the "my" here and the one int the foreach below.
> > print @result."\n";
I have changed the code accordingly to :
10 my @results = ();
11 for my $phrase (@phrase) {
12 chomp $phrase;
13 for my $word (@words) {
14 chomp $word;
15 if ($phrase =~ m/\b$word\b/i) {
16 my $found = $word."\t".$phrase;
17 push (@result, $found);
18 print @result."\n";
19 }}}
20 foreach (@result){ # go through the result array
21 my ($word, $phrase) = split(/\t/,$_);
22 print "$word --> $phrase\n";
When I run the script I get:
Global symbol "@result" requires explicit package name at test.pl line 17.
Global symbol "@result" requires explicit package name at test.pl line 18.
Global symbol "@result" requires explicit package name at test.pl line 20.
Execution of test.pl aborted due to compilation errors.
------------------------------
Date: Wed, 21 May 2014 09:18:17 +0100
From: Justin C <justin.1401@purestblue.com>
Subject: Re: Push regex search result into hash with multiple values
Message-Id: <934u4b-6rj.ln1@zem.masonsmusic.co.uk>
On 2014-05-21, fmassion@web.de <fmassion@web.de> wrote:
> Hi,
>
> sorry to reply so late.
>> my @results = ();
>> here.
> (...)
>> remove the "my" here and the one int the foreach below.
>> > print @result."\n";
>
> I have changed the code accordingly to :
>
> 10 my @results = ();
[snip]
> Global symbol "@result" requires explicit package name at test.pl line 17.
Typo.
Justin.
--
Justin C, by the sea.
------------------------------
Date: Wed, 21 May 2014 14:20:16 +0300
From: George Mpouras <gravitalsun@hotmail.foo>
Subject: search.cpan.org
Message-Id: <lli24d$m8$1@news.ntua.gr>
what is going on with search.cpan.org , is it down ? e.g.
http://search.cpan.org/~cindy/AnyEvent-MySQL-v1.1.1/
------------------------------
Date: 21 May 2014 11:54:02 GMT
From: jt@toerring.de (Jens Thoms Toerring)
Subject: Re: search.cpan.org
Message-Id: <bu3ieoF9pgeU1@mid.uni-berlin.de>
George Mpouras <gravitalsun@hotmail.foo> wrote:
> what is going on with search.cpan.org , is it down ?
Yes, seems to have major problems since at least two days:-(
--
\ Jens Thoms Toerring ___ jt@toerring.de
\__________________________ http://toerring.de
------------------------------
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 4218
***************************************
