[32949] in Perl-Users-Digest
Perl-Users Digest, Issue: 4225 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed May 28 14:09:22 2014
Date: Wed, 28 May 2014 11:09:04 -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, 28 May 2014 Volume: 11 Number: 4225
Today's topics:
Re: copy "sub" hash? <rweikusat@mobileactivedefense.com>
Re: copy "sub" hash? <stevem_@nogood.com>
Re: copy "sub" hash? <rweikusat@mobileactivedefense.com>
Re: copy "sub" hash? <derykus@gmail.com>
Re: copy "sub" hash? <tzz@lifelogs.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 <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: 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>
sorting file according to a unicode column ehabaziz2001@gmail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 27 May 2014 16:52:08 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: copy "sub" hash?
Message-Id: <87ppizte1j.fsf@sable.mobileactivedefense.com>
Steve May <stevem_@nogood.com> writes:
> On 05/27/2014 05:29 AM, Rainer Weikusat wrote:
>> Steve May <stevem_@nogood.com> writes:
>>> On 05/26/2014 06:32 PM, catebekensail@yahoo.com wrote:
>>>> how can you extract "mary" into another hash?
>>>>
>>>> %a = ('mary'=>
>>>> {'address'=>11, 'zip'=>12},
>>>> 'john'=>
>>>> {'address'=>21, 'zip'=>22},
>>>> );
>>>>
>>>> %b = $a{'mary'}; ???
>>>>
>>>
>>> You are copying a reference above.
>>
>> [...]
>>
>>> Reference found where even-sized list expected
>>
>> Not really. Assigning a list to a hash causes the contents of the list
>> to be turned into key/value pairs as they're encountered, eg this code
>
> Well, that was directly copied from the error message generated when I
> ran the code shown and I would expect the same message to show up for
> the OP if they ran the same code. Which is why.... well you catch my
> drift.
Except that, as I already wrote, the reference isn't copied: It is
stringified and the result of that is used as a hash key (which will be
mapped to undef because nothing except the reference was provided on the
right-hand side of the assignment).
[...]
>>> The outer brackets are not mandatory, but I tend to use them in
>>> dereferencing as they are an immediate visual clue as to what the code
>>> is doing.
>>
>> They are mandatory in this case:
>
> Yes, I was thinking about other cases, but in this case they are. I
> didn't catch that as I tend to use them all the time in dereferencing
> anyway.
As I also already wrote: There's no relation between 'brackets' and
'dereferencing': A block returning a reference of an appropriate type
can be used instead of an ordinary identifier. That's a requirement in
case such a reference isn't simply stored in a scalar variable and it
isn't possible to use the 'infix dereference operator' (->)
instead. The latter should usually be preferred, cf (other posting by me
about this topic)
https://groups.google.com/forum/#!original/comp.lang.perl.misc/sF52WmASiJ0/m8NXDrQqj5wJ
------------------------------
Date: Tue, 27 May 2014 10:03:29 -0700
From: Steve May <stevem_@nogood.com>
Subject: Re: copy "sub" hash?
Message-Id: <Cz3hv.425016$643.263856@fx30.iad>
On 05/27/2014 08:52 AM, Rainer Weikusat wrote:
> Steve May <stevem_@nogood.com> writes:
>> On 05/27/2014 05:29 AM, Rainer Weikusat wrote:
>>> Steve May <stevem_@nogood.com> writes:
>>>> On 05/26/2014 06:32 PM, catebekensail@yahoo.com wrote:
>>>>> how can you extract "mary" into another hash?
>>>>>
>>>>> %a = ('mary'=>
>>>>> {'address'=>11, 'zip'=>12},
>>>>> 'john'=>
>>>>> {'address'=>21, 'zip'=>22},
>>>>> );
>>>>>
>>>>> %b = $a{'mary'}; ???
>>>>>
>>>>
>>>> You are copying a reference above.
>>>
>>> [...]
>>>
>>>> Reference found where even-sized list expected
>>>
>>> Not really. Assigning a list to a hash causes the contents of the list
>>> to be turned into key/value pairs as they're encountered, eg this code
>>
>> Well, that was directly copied from the error message generated when I
>> ran the code shown and I would expect the same message to show up for
>> the OP if they ran the same code. Which is why.... well you catch my
>> drift.
>
> Except that, as I already wrote, the reference isn't copied: It is
> stringified and the result of that is used as a hash key (which will be
> mapped to undef because nothing except the reference was provided on the
> right-hand side of the assignment).
>
Sigh.... I believe we're saying much the same thing, just with different
spins. You are probably more technically correct given that I'm just a
shade tree hacker and that's fine.
In my limited understanding the reference was not copied (correctly)
since Perl does not implicitly dereference references. Given that all
Perl arrays and hashes ONLY hold scalar values ( a string, number, or a
reference), and the OP tried to assign that single internal scalar
(reference pointer) to a hash, Perl said:
'Reference found where even-sized list expected'
Works for me.
> [...]
>
>>>> The outer brackets are not mandatory, but I tend to use them in
>>>> dereferencing as they are an immediate visual clue as to what the code
>>>> is doing.
>>>
>>> They are mandatory in this case:
>>
>> Yes, I was thinking about other cases, but in this case they are. I
>> didn't catch that as I tend to use them all the time in dereferencing
>> anyway.
>
> As I also already wrote: There's no relation between 'brackets' and
> 'dereferencing': A block returning a reference of an appropriate type
> can be used instead of an ordinary identifier. That's a requirement in
> case such a reference isn't simply stored in a scalar variable and it
> isn't possible to use the 'infix dereference operator' (->)
> instead. The latter should usually be preferred, cf (other posting by me
> about this topic)
>
> https://groups.google.com/forum/#!original/comp.lang.perl.misc/sF52WmASiJ0/m8NXDrQqj5wJ
>
Whatever, but I think I'll continue to go with the approach shown in
http://perldoc.perl.org/perldsc.html
"If you want to get at the thing a reference is referring to, then you
have to do this yourself using either prefix typing indicators, like
${$blah} , @{$blah} , @{$blah[$i]} , or else postfix pointer arrows,
like $a->[3] , $h->{fred} , or even $ob->method()->[3] ."
Again, works for me and I don't really care if there are technical
quibbles. Life is too short.
I DO appreciate your comments though, they make me at least think about
the box though not necessarily outside of it. :-)
\s
------------------------------
Date: Tue, 27 May 2014 21:37:47 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: copy "sub" hash?
Message-Id: <878upnt0tg.fsf@sable.mobileactivedefense.com>
Steve May <stevem_@nogood.com> writes:
> On 05/27/2014 08:52 AM, Rainer Weikusat wrote:
>> Steve May <stevem_@nogood.com> writes:
>>> On 05/27/2014 05:29 AM, Rainer Weikusat wrote:
>>>> Steve May <stevem_@nogood.com> writes:
>>>>> On 05/26/2014 06:32 PM, catebekensail@yahoo.com wrote:
>>>>>> how can you extract "mary" into another hash?
>>>>>>
>>>>>> %a = ('mary'=>
>>>>>> {'address'=>11, 'zip'=>12},
>>>>>> 'john'=>
>>>>>> {'address'=>21, 'zip'=>22},
>>>>>> );
>>>>>>
>>>>>> %b = $a{'mary'}; ???
>>>>>>
>>>>>
>>>>> You are copying a reference above.
>>>>
>>>> [...]
>>>>
>>>>> Reference found where even-sized list expected
>>>>
>>>> Not really. Assigning a list to a hash causes the contents of the list
>>>> to be turned into key/value pairs as they're encountered, eg this code
>>>
>>> Well, that was directly copied from the error message generated when I
>>> ran the code shown and I would expect the same message to show up for
>>> the OP if they ran the same code. Which is why.... well you catch my
>>> drift.
>>
>> Except that, as I already wrote, the reference isn't copied: It is
>> stringified and the result of that is used as a hash key (which will be
>> mapped to undef because nothing except the reference was provided on the
>> right-hand side of the assignment).
>
> Sigh.... I believe we're saying much the same thing, just with
> different spins. You are probably more technically correct given that
> I'm just a shade tree hacker and that's fine.
>
> In my limited understanding the reference was not copied (correctly)
> since Perl does not implicitly dereference references.
The usual term for copying what some 'reference' (or pointer) refers to,
instead of copying the reference itself, would be 'deep copy' (as
opposed to 'shallow copy') but that's yet something completely
different.
-----------
my %hash_of_hopelessness = (
anger => { address => 'hell', zip => 'Ha!'},
despair => { address => 'heller', zip => 'Ha!ler'},
ragnaroek =>{ address => 'gone', zip => '?' });
my (%well_of_measles, %saubohne_des_verderbens);
# associate a copy of the reference anger refers to with fear
#
$well_of_measles{fear} = $hash_of_hopelessness{anger};
$hash_of_hopelessness{anger}{address} = 'damnation';
print($well_of_measles{fear}{address}, "\n");
# make a deep copy of the hash despair points to
#
$well_of_measles{trostlosigkeit} = {%{$hash_of_hopelessness{despair}}};
$well_of_measles{trostlosigkeit}{address} = 'Asterdam';
print($hash_of_hopelessness{despair}{address}, "\n");
# copy the keys and values of the ragnaroek hash
#
%saubohne_des_verderbens = %{$hash_of_hopelessness{ragnaroek}};
print("$_ -> $saubohne_des_verderbens{$_}\n") for keys(%saubohne_des_verderbens);
# try to use a reference as hashkey
#
my %turn_of_the_stew;
$turn_of_the_stew{{}} = {};
# key isn't a reference anymore
#
printf("%s, %s(!)\n", $_, ref($_)) for keys(%turn_of_the_stew);
--------------
[...]
>>>>> The outer brackets are not mandatory, but I tend to use them in
>>>>> dereferencing as they are an immediate visual clue as to what the code
>>>>> is doing.
>>>>
>>>> They are mandatory in this case:
>>>
>>> Yes, I was thinking about other cases, but in this case they are. I
>>> didn't catch that as I tend to use them all the time in dereferencing
>>> anyway.
>>
>> As I also already wrote: There's no relation between 'brackets' and
>> 'dereferencing': A block returning a reference of an appropriate type
>> can be used instead of an ordinary identifier. That's a requirement in
>> case such a reference isn't simply stored in a scalar variable and it
>> isn't possible to use the 'infix dereference operator' (->)
>> instead. The latter should usually be preferred, cf (other posting by me
>> about this topic)
>>
>> https://groups.google.com/forum/#!original/comp.lang.perl.misc/sF52WmASiJ0/m8NXDrQqj5wJ
>
> Whatever, but I think I'll continue to go with the approach shown in
> http://perldoc.perl.org/perldsc.html
>
> "If you want to get at the thing a reference is referring to, then you
> have to do this yourself using either prefix typing indicators, like
> ${$blah} , @{$blah} , @{$blah[$i]} , or else postfix pointer arrows,
> like $a->[3] , $h->{fred} , or even $ob->method()->[3] ."
I figure you believe to have found some contradiction between a text
from the 'Perl data structures intro' tutorial and the perlref exceprt
you're apparently incorrectly ascribing to me but at least insofar I'm
concerned, I have no idea what this contradiction is suppse to be ...
------------------------------
Date: Tue, 27 May 2014 21:41:54 -0700
From: Charles DeRykus <derykus@gmail.com>
Subject: Re: copy "sub" hash?
Message-Id: <lm3peu$9fk$1@speranza.aioe.org>
On 5/26/2014 6:32 PM, catebekensail@yahoo.com wrote:
> how can you extract "mary" into another hash?
>
> %a = ('mary'=>
> {'address'=>11, 'zip'=>12},
> 'john'=>
> {'address'=>21, 'zip'=>22},
> );
>
> %b = $a{'mary'}; ??
FYI, in case you missed mention of "deep copy" in this thread:
If you don't want sharing between the hashes, you'll need to clone
rather than copy. If you just "copy" the reference ("shallow copy"),
changes in one hash will be mirrored in the other.
A simple example:
%b = %a;
$b{mary}{address} = 'foo'; ## $a{mary{address} changes too;
Whereas, with a "deep copy":
use Storable qw(dclone);
my %b = %{ dclone(\%a) };
$b{mary}{address}=12; ## $a{mary}{address} stays same
See: perldoc -q recursive
--
Charles DeRykus
------------------------------
Date: Wed, 28 May 2014 10:23:30 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: copy "sub" hash?
Message-Id: <878upm3rtp.fsf@lifelogs.com>
On Mon, 26 May 2014 18:32:02 -0700 (PDT) catebekensail@yahoo.com wrote:
c> how can you extract "mary" into another hash?
c> %a = ('mary'=>
c> {'address'=>11, 'zip'=>12},
c> 'john'=>
c> {'address'=>21, 'zip'=>22},
c> );
c> %b = $a{'mary'}; ???
Nothing to add to the great answers so far, except that the newly
released Perl 5.20.0 actually has this built-in, called a hash slice.
For a friendly summary, see
http://perltricks.com/article/92/2014/5/27/Perl-v5-20-what-you-need-to-know
Ted
------------------------------
Date: Tue, 27 May 2014 18:27:57 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <5384bd0c$0$6653$9b4e6d93@newsspool3.arcor-online.net>
On 27.05.14 00:22, Rainer Weikusat wrote:
> what's the base for assuming that people won't be
> familiar with the first five paragraphs of 'perldoc perlsyn' but will be
> familiar with all kinds of "strange, other programming languages"?
Properly understanding every word of these fine five paragraphs
requires advanced computer literacy and experience. (As is seen
by observing the number of words that have a formal definition
in Perl, or in computer science.) The perldoc pages can be
called "reference material" for a reason, one being that one
may start writing Perl programs without having learned the
reference material by heart, time-saving as that may be.
------------------------------
Date: Tue, 27 May 2014 18:38:15 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <5384bf76$0$6668$9b4e6d93@newsspool3.arcor-online.net>
On 26.05.14 23:12, Peter J. Holzer wrote:
> On 2014-05-26 13:08, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
>> On 24.05.14 15:26, Peter J. Holzer wrote:
>>>> 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.
>>>
>>> So I guess we should avoid the ”+” operator like the plague, since it is
>>> present in most programming languages.
>>
>> Typically, the + operator in programming languages triggers
>> very much the same assumption (intuitively? training received
>> at school?), slight changes in meaning is a rare exceptions.
>> I can't believe that any programmer will be so puzzled by +
>> that he or she won't recognize "add", or "concatenate".
>
> There, you said it and didn't even realize it.
The argument starts from the number of programmers
who can tell the difference in + between
C<"Hello, " + "World">
and
C<3 + 4>
say, and programmers who struggle (justifiably) when seeing
any combination of C<,>, C<and>, C<=>, C<return>, and C<if>
on a single line.
> you have to watch
> out for the differences.
Precisely.
> I freely admit that Perl has a lot of dark corners and that
> it is not an easy language to learn to read well to survive in the wild.
All the more it seems important to know the audience when
one wishes to put things from the dark corners to good use.
------------------------------
Date: Tue, 27 May 2014 18:40:18 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <5384bff1$0$6668$9b4e6d93@newsspool3.arcor-online.net>
On 26.05.14 19:47, Rainer Weikusat wrote:
> Can you please substantiate your apparent conviction that people who
> aren't even superficially familiar with the Perl documentation write
> Perl code and further, could you please provide a reason why this would
> be relevant for anything?
Their familiarity with the Perl documentation is, as I have tried
to indicate many times now, I think, at a level that produces puzzled
programmers in need of help.
(Familiarity with languages' documentation is generally (and
naturally?) limited and this cannot be surprising: insofar as real
clarity is only available from "standards", and since "standards"
are complex, it is not surprising when use of formal programming
languages creates puzzles. More so when the set of (syntactical)
possibilities of a language like Perl is richer than that of
other languages, yet tempting, maybe useful after years of thinking,
or by someone exceptionally skilled.)
A reason why and when and how this is relevant was part of the
message to which you have just replied. I won't repeat it here.
------------------------------
Date: Tue, 27 May 2014 18:00:32 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87ha4btavj.fsf@sable.mobileactivedefense.com>
"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
> On 26.05.14 23:12, Peter J. Holzer wrote:
>> On 2014-05-26 13:08, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
>>> On 24.05.14 15:26, Peter J. Holzer wrote:
>>>>> 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.
>>>>
>>>> So I guess we should avoid the + operator like the plague, since it is
>>>> present in most programming languages.
>>>
>>> Typically, the + operator in programming languages triggers
>>> very much the same assumption (intuitively? training received
>>> at school?), slight changes in meaning is a rare exceptions.
>>> I can't believe that any programmer will be so puzzled by +
>>> that he or she won't recognize "add", or "concatenate".
>>
>> There, you said it and didn't even realize it.
>
> The argument starts from the number of programmers
> who can tell the difference in + between
>
> C<"Hello, " + "World">
> and
> C<3 + 4>
Oh, that's easy. The result of the first is 0 and the result of the
second is 7:
[rw@sable]/tmp#perl -e 'print "Hello, " + "world", 3 + 4, "\n"'
07
Any number of C++-programmers (or 'people considered not quite smart
enough to be trusted with C++' aka 'Java programmers') are completely
free to expect something different based on the well-established human
virtue to confuse a perfectly arbitrary convention one happens to have
learnt with a law of nature, if not even universal morality, and they're
as free to whine and complain loudly for years on end based on the
assessment that having to learn something new after the age of 25 and
outside of an established education instutirion is Clearly (!!!!) beyond
everything one can reasonably expect from mere humans, however, this is
their problem alone.
------------------------------
Date: Tue, 27 May 2014 18:55:36 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87d2ezt8br.fsf@sable.mobileactivedefense.com>
"Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> On 2014-05-26 22:01, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>> "Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
>>> On 2014-05-26 13:08, G.B. <rm-dash-bau-haus@dash.futureapps.de> wrote:
>>>> On 24.05.14 15:26, Peter J. Holzer wrote:
>>
>> [...]
>>
>>>>> “$frog = 'green', return if blort();” is relatively simple.
>>
>> [...]
>>
>>> the 4 line alternative is of course much more conventional and simpler
>>> for someone not so familiar with Perl, at least when taken out of
>>> context).
>>
>> if (blort()) {
>> $frog = "magenta";
>> return;
>> }
>>
>> is a syntactical construct which exists in this form in C and in (AFAIK)
>> all languages whose syntax was directly or indirectly derived from
>> C. This implies that it can be called 'more common' or 'more widespread'
>> but I'd be wary of regarding it as 'more conventional':
>
> I don't have hard figures, and I may be biased by my unix background,
> but I think that languages derived from C are now more widespread than
> languages derived from Algol[1]. So «if (...) { ... }» should be a very
> familiar construct to most programmers. In Algol-derived languages it's
> «if ... then begin ... end» which is basically the same, and Python uses
> indentation instead of keywords/symbols to delimit the block, but the
> basic structure is still the same. Tacking on a condition at the end of
> a statement is very rare (I'm sure Perl isn't the only language which
> does this, but I can't think of another example off the top of my head).
> Using bare conditions for control flow is a bit more common, but still
> rare (It is frequently used in shell scripts, rarely in C, any other
> languages?). And even those languages which have alternative constructs
> (Perl, C, Shell, ...) have the «if condition block» construct and it is
> used at least as frequently as the alternatives.
>
> So yes, I think I'm justified in calling this construct "much more
> conventional".
You've mentioned three different constructs:
- the 'C-style'
if (...) {...}
- the 'Algol-style'
if ... then begin ... end
- a generalization encompassing both:
if condition block,
although it really doesn't because C uses
if condition statement
(as do Java and C++) and 'block' is 'a kind of statement', while
Perl requires a block.
There's additionally the 'Algol 68' style
if ... then ... fi
used by the shell and the PL/PgSQL (PL/SQL)
if ... then ... end if
and requiring 'then ... fi' as block separators instead of {} is totally
sufficient to make people go ballistic and declare "total war on the
shell". Which is all of these represents "the convention"?
The answer I was trying to get at was "It depends" [on the cultural
background of the people who are supposed to answer this
question]. Statement modifiers have existed in Perl at least since Perl
4,
http://www-cgi.cs.cmu.edu/afs/cs.cmu.edu/Web/People/rgs/pl-simple.html
and (as pointed out by Ben Morrow in the past) they actually came from
BASIC-PLUS RSTS/E runtime environment for DEC PDP-11 computers,
http://en.wikipedia.org/wiki/BASIC-PLUS
(mentioned at the end of the first section)
which means they're surely old enough to be regarded as 'convention' of
their own, just not 'a universal convention' (but that's true for the
others as well).
Differently worded and more concise: 'Conventionaly, humans speak a
Chinese dialect and understand one or more others' is a nonsensical
statement despite "the numbers say so".
------------------------------
Date: Wed, 28 May 2014 17:54:55 +0200
From: "G.B." <rm-dash-bau-haus@dash.futureapps.de>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <538606ce$0$6610$9b4e6d93@newsspool4.arcor-online.net>
On 27.05.14 19:00, Rainer Weikusat wrote:
> beyond
> everything one can reasonably expect from mere humans,
Which is another way of slipping the claim in: that some
expectations are reasonable. I'm trying to point out that
"reasonable" cannot just refer to a subjective view,
or to some select group of Perl savvy programmers
whenever software is part of the work of average programmers.
Solving language puzzles is above average.
> however, this is their problem alone.
No, it typically becomes someone else's problem, in at least
three ways. First, there is a need to work with their produce.
Second, someone needs to pay for that and, initially, very likely
for the time it takes to tackle the problems that premature
writing of complicated statements may entail.
All very good for consulting, though.
A third way in which someone's problem can become someone
else's problem is demonstrated by the existence of this thread.
------------------------------
Date: Wed, 28 May 2014 17:36:13 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <87egzddfnm.fsf@sable.mobileactivedefense.com>
"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
> On 27.05.14 19:00, Rainer Weikusat wrote:
>> beyond
>> everything one can reasonably expect from mere humans,
>
> Which is another way of slipping the claim in: that some
> expectations are reasonable. I'm trying to point out that
> "reasonable" cannot just refer to a subjective view,
> or to some select group of Perl savvy programmers
> whenever software is part of the work of average programmers.
> Solving language puzzles is above average.
If 'the average programmer' doesn't know Perl (and is unwilling to learn
it), 'the average programmer' ought to stay away from Perl-related jobs
and in case this 'average programmer' gets hired for one despite both
his lack of applicable skills and his unwilligness to acquire them, this
would be (as I already pointed out) a 'HR failure' 'management' should
be made aware of. In any case, your musings about what fictional
'average people' do or don't know and might or might not be willing to
learn are totally off topic here.
Further, stating that 'opinions of people who know Perl are not relevant
for Perl' is absurd nonsense as the opposite is actually true: Opinions
of people on topics they aren't familiar with a generally irrelevant.
[...]
> All very good for consulting, though.
You might want to tone down the conspiracy theories 'a little'. A
practical hint: Most 'consultants' I've encountered so far were 'totally
average' in the sense you seem to use this, namely, incompentent, lazy
crooks. Furhter, few of them (if any) would be willing to work for my
nominal salary.
------------------------------
Date: Wed, 28 May 2014 18:57:32 +0100
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: Help with an operator precedence (?) puzzle
Message-Id: <878upldbw3.fsf@sable.mobileactivedefense.com>
"G.B." <rm-dash-bau-haus@dash.futureapps.de> writes:
> On 27.05.14 19:00, Rainer Weikusat wrote:
>> beyond
>> everything one can reasonably expect from mere humans,
>
> Which is another way of slipping the claim in: that some
> expectations are reasonable. I'm trying to point out that
> "reasonable" cannot just refer to a subjective view,
> or to some select group of Perl savvy programmers
> whenever software is part of the work of average programmers.
> Solving language puzzles is above average.
As a more reasoned reply: I'm sorry but I'm completely unable to find
any coherent content in this paragraph, let alone coherent relevant
content: Your subjective view is that objectively elementary features of the Perl
programming language qualify as 'puzzles', whatever that is supposed to
mean precisely, and that they're thus beyond the abilities of some
fictional group of people defined as being 'average' by virtue of surely
becoming very puzzled in face of something you'd like to call a puzzle
and ... then nothing.
[...]
> All very good for consulting, though.
Considering the context, this is not only ridiculous but also abusive in
a very irrational way: What you believe about other people's 'nasty
hidden motives' communicates something about you, not about anyone else.
------------------------------
Date: Wed, 28 May 2014 07:22:10 -0700 (PDT)
From: ehabaziz2001@gmail.com
Subject: sorting file according to a unicode column
Message-Id: <16465f0d-e77f-4a71-92f4-5005cfe48596@googlegroups.com>
Dear All,
I need to use that below script but with no success . Even I try to use the ucsort script but also with no success . Any help
The files columns separated with '|' and the column position 9 with length 200.
use encoding 'utf8';
my @File;
my %Positions_and_lenghts = (
9 => 180 ,
);
#For external file
open FILE, '>:utf8', 'F:\programs\sedawk\xerox_scripts\AlexBank\logs\all_cycle_data.sorted' or die "$^E\n";
binmode STDOUT, ':utf8';
while (my $line = <DATA>) {
my $row;
foreach my $POS (sort {$a<=>$b} keys %Positions_and_lenghts) {
push @{$row}, substr $line, $POS, $Positions_and_lenghts{$POS}
}
push @File, $row
}
#use Data::Dumper; print Dumper(\@File);exit;
foreach my $row (sort {$a->[0] cmp $b->[0] || $a->[2] cmp $b->[2]} @File) {
print "@{$row}\n"
}
------------------------------
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 4225
***************************************
