[32869] in Perl-Users-Digest
Perl-Users Digest, Issue: 4147 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Feb 24 03:09:37 2014
Date: Mon, 24 Feb 2014 00:09:05 -0800 (PST)
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, 24 Feb 2014 Volume: 11 Number: 4147
Today's topics:
Re: How do I get "system" to report the correct failure (hymie!)
Re: Improving bad practice <justin.1402@purestblue.com>
Re: Improving bad practice <ben@morrow.me.uk>
Re: obj 8-2 <ben@morrow.me.uk>
Re: obj 8-2 <uri@stemsystems.com>
Re: obj 8-2 <news@todbe.com>
Re: obj 8-2 <news@todbe.com>
Re: obj 8-2 <uri@stemsystems.com>
Re: obj 8-2 <ben@morrow.me.uk>
Re: obj 8-2 <johnblack@nospam.com>
Re: obj 8-2 <hjp-usenet3@hjp.at>
Re: obj 8-2 <kaz@kylheku.com>
Re: obj 8-2 <news@todbe.com>
seo services in hyderabad nanoseoweb@gmail.com
use strict; use warnings; <mach2@hushmail.com>
Re: use strict; use warnings; <marius@ieval.ro>
Re: use strict; use warnings; <kaz@kylheku.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 24 Feb 2014 01:11:32 GMT
From: hymie@lactose.homelinux.net (hymie!)
Subject: Re: How do I get "system" to report the correct failure message?
Message-Id: <530a9c44$0$29168$862e30e2@ngroups.net>
In our last episode, the evil Dr. Lacto had captured our hero,
laredotornado@zipmail.com, who said:
> system("$jbossHome/bin/jboss-cli.sh", "--file=$file");
> if ( $? != 0 )
> {
> die"Failed to deploy $downloadedFile: $!\n";
> }
>Any ideas how I can output the correct error message?
$ perldoc -f system
This is not what you
want to use to capture the output from a command; for that you
should use merely backticks or "qx//", as described in
"`STRING`" in perlop.
--hymie! http://lactose.homelinux.net/~hymie hymie@lactose.homelinux.net
------------------------------
Date: Sun, 23 Feb 2014 12:56:19 +0000
From: Justin C <justin.1402@purestblue.com>
Subject: Re: Improving bad practice
Message-Id: <jo7pta-us8.ln1@moonlight.purestblue.com>
On 2014-02-20, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
>
> NB: This piece of ill thought out advice is rather symptomatic for the
> web page in question.
If it's ill thought out then I'll just ignore it!
Thank you for the reply.
Justin.
------------------------------
Date: Sun, 23 Feb 2014 18:25:59 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Improving bad practice
Message-Id: <n2rpta-lkk1.ln1@anubis.morrow.me.uk>
Quoth Justin C <justin.1402@purestblue.com>:
> On 2014-02-20, Rainer Weikusat <rweikusat@mobileactivedefense.com> wrote:
> >
> > NB: This piece of ill thought out advice is rather symptomatic for the
> > web page in question.
>
> If it's ill thought out then I'll just ignore it!
Sorry, I've been meaning to make a proper reply...
The advice given (extremely poorly expressed) was to get rid of long
lists of parameters, many of which are simply passed down to subordinate
functions, by turning the functions into methods on some object and the
parameters into attributes. This is often good advice, but should not be
applied indiscriminately; there are often less radical changes to the
code which have as much benefit.
This is an example from something I'm working on at the moment. I have a
number of objects which need to be able to draw themselves when
requested. In order to do this, they need several parameters: a graphics
context to draw on, a font to use, information about where they should
draw, and so on. To start with, the drawing method for one of these
objects looked a bit like this:
sub draw {
my ($self, $c, $font, $pos) = @_;
my $wd = $self->_draw_head($c, $font);
my $len = $self->length;
my $up = $pos < 0;
if ($len >= 2) {
my ($ex, $ey) = $self->_draw_stem($c, $up, $wd);
if (my $tail = $self->_tail($font, $up)) {
$self->_draw_tail($c, $tail, $ex, $ey);
}
}
return $wd;
}
As you can see, it calls several subordinate methods, passing them some
of its parameters. As I added different kinds of these objects, it
turned out that some of them needed still more parameters: the width of
the window, the current clef, the current key signature... Changing the
calling convention for ->draw to pass all these separately would quickly
turn into an incomprehensible mess.
The first way to simplify a situation like this is to pack the
parameters up into a hash. At first sight this doesn't make much
difference--after all, you're passing the same information, just
represented slightly differently--but in fact it means that you can add
parameters without needing to affect already-written code. So:
sub draw {
# $pos is still separate because it varies per-note
my ($self, $params, $pos) = @_;
my $wd = $self->_draw_accidental($params);
$params->{c}->translate($wd, 0);
$wd += $self->_draw_head($params);
...
}
Most of the subordinate methods now just take a single parameter, and
pull out the information they need: I no longer need to keep track of
which methods take which arguments, and when I realise a method two or
three calls down needs a new parameter I don't have to change all the
intervening methods. Also, I have in fact already added a new parameter:
the _draw_accidental method needs 'current key signature' information
that wasn't passed before, but ->draw doesn't need to change to
accomodate that.
The next step is to turn the hashref into an object. As ever, this
should not be done 'just to be cool', but there are often concrete
advantages. In my case, several of these draw methods need a function to
look up a glyph in the font by name, so they use a role (like a
superclass, but safer) providing these methods:
sub glyph {
my ($self, $font, $gly) = @_;
return {
name => $gly,
index => $font->get_name_index($gly),
# Cairo gets upset if I don't include these...
x => 0,
y => 0,
};
}
sub glyph_width {
my ($self, $c, $gly) = @_;
$c->glyph_extents($gly)->{x_advance};
}
If I turn my new $params parameter into a DrawCtx object, I can move
these methods into that class, like this:
sub glyph {
# $self is now a DrawCtx; above it was a Note
my ($self, $gly) = @_;
return {
name => $gly,
index => $self->font->get_name_index($gly),
x => 0,
y => 0,
};
}
sub glyph_width {
my ($self, $gly) = @_;
$self->c->glyph_extents($gly)->{x_advance};
}
and again I've simplified the calling conventions because the object
already knows information that previously had to be passed in.
The final step in this sort of reorganisation would be to move the
drawing methods themselves into a Draw::Note class. That is, instead of
having a Note which knows how to draw itself and a DrawCtx which
represents the drawing parameters, I would have a Note object which just
holds the information about the note, a Draw::Note object which knows
how to draw one note, and a DrawCtx that knows how to build a Draw::Note
for a given Note. My top-level drawing function would go from looking
like this:
my $c = DrawCtx->new(
c => Cairo::Context->create(...),
font => ...,
...
);
my $x = 4;
for my $note (@notes) {
my $pos = $note->staff_line($pos);
$c->save;
$c->translate($x, 12 - $pos);
$x += $note->draw($c, $pos);
$c->restore;
}
to looking more like this:
my $c = DrawCtx->new(...);
my $x = 4;
for my $note (@notes) {
my $d = $c->drawer_for($note);
$x += $d->draw;
}
where DrawCtx->drawer_for knows it has to return a Draw::Note for a
Note, a Draw::Rest for a Rest, and so on. Notice that ->draw now doesn't
need any parameters, because they have all been passed in to the various
constructors instead.
The web page you quoted is telling you to jump straight to this step. I
wouldn't necessarily go straight there: it's quite a bit of extra
complexity just to avoid passing a single parameter around. I haven't
made this change yet in my code, though I am considering it, because it
separates 'model' (that is, the data we are representing) from 'view'
(the mechanism we are using to present that data to the user). This is a
useful thing to when there are several different ways to display the
same data: in my case, I can draw it on a window, I can write it to a
file, I can convert it into MIDI, and so on, and stuffing all the
methods for generating all these different representations into the
basic Note class results in a big unwieldy mess.
Hmm, that was rather long... I hope you got to the end, and it made some
sort of sense. This is a rather high-level question of style, meaning
that the 'rules' are much more flexible than rules like 'avoid globals
where possible'. It's important *not* to just 'put all these parameters
in an object, because I read somewhere that's the right thing to do';
instead, you need to think about what your objects represent, and what
they do, and whether perhaps this object is doing two jobs and should be
split into two, and generally try to ensure your code is broken up into
chunks that make sense.
Ben
------------------------------
Date: Sun, 23 Feb 2014 02:16:07 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: obj 8-2
Message-Id: <782ota-7vv.ln1@anubis.morrow.me.uk>
Quoth John Bokma <john@castleamber.com>:
> "Peter J. Holzer" <hjp-usenet3@hjp.at> writes:
> > On 2014-02-23 00:03, John Bokma <john@castleamber.com> wrote:
> >> I prefer (now) this
> >>
> >> $x > 12 or next;
> >>
> >> over:
> >>
> >> next if $x > 12;
> >
> > One of these two lines doesn't do what you think.
>
> Yes, my bad.
>
> next unless $x > 12;
>
> ( or $x > 12 and next; to go with the if )
>
> I still prefer the or/and version, mostly, but like I wrote I recently
> started to fall back to if/unless recently.
perlstyle sez 'put the more important clause first'. So
reactor_is_overheating() and sound_alarm();
but
increase_power_output() unless too_much_already();
As a general rule I would test clauses with side-effects using and/or
rather than postfix-if/unless, since then the reading order follows the
side-effect order. If you were to write
die ... unless open ...;
the 'open' happens before the 'die', so it's confusing to write them in
the other order. (This obviously doesn't apply to full-blown if/unless.)
Ben
------------------------------
Date: Sat, 22 Feb 2014 22:48:37 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: obj 8-2
Message-Id: <87ios67alm.fsf@stemsystems.com>
>>>>> "BM" == Ben Morrow <ben@morrow.me.uk> writes:
BM> perlstyle sez 'put the more important clause first'. So
BM> reactor_is_overheating() and sound_alarm();
BM> but
BM> increase_power_output() unless too_much_already();
peter scott (author of perl medic and other stuff) teaches that 'and',
'or' should be used for flow control and &&, || used for
expressions. this is good also because of their precedence. the word
versions are very low precedence which allows for assignment and other
things in the clauses.
but i prefer the if/unless modifiers vs and/or in simple booleans. i
teach to leave early when you can. i see way too much code like this:
if( some test ) {
do LOTS OF CODE ;
}
else {
next # or return or last
}
it should be:
next unless test() ; # or return or whatver
do LOTS of code at main level ;
it saves block entry, indents, lines of code, braces and pixels. a 5 way
win!
uri
------------------------------
Date: Sat, 22 Feb 2014 21:42:33 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: obj 8-2
Message-Id: <lec1o4$iav$1@dont-email.me>
On 2/22/2014 14:17, Peter J. Holzer wrote:
>
> The indentation of the second and subsequent lines of the expression
> is also critical. Continued lines should not simply be indented to
> the next indentation level. Instead, they should be indented to the
> starting column of the expression to which they belong. That is,
> instead of:
>
> push @steps, $steps[-1]
> + $radial_velocity * $elapsed_time
> + $orbital_velocity * ($phase + $phase_shift)
> - $DRAG_COEFF * $altitude
> ;
>
> one should write:
>
> push @steps, $steps[-1]
> + $radial_velocity * $elapsed_time
> + $orbital_velocity * ($phase + $phase_shift)
> - $DRAG_COEFF * $altitude
> ;
I prefer to just split at the nearest (or most logical operator) and
indent 2 spaces (to conserve H space):
push @steps, $steps[-1] + $radial_velocity * $elapsed_time +
$orbital_velocity * ($phase + $phase_shift) - $DRAG_COEFF * $altitude;
sometimes I'll break like this to get one logical calc per line:
push @steps, $steps[-1] +
$radial_velocity * $elapsed_time +
$orbital_velocity * ($phase + $phase_shift) -
$DRAG_COEFF * $altitude;
always staying in my 80 col space.
------------------------------
Date: Sat, 22 Feb 2014 21:45:57 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: obj 8-2
Message-Id: <lec1uf$j42$1@dont-email.me>
On 2/22/2014 19:48, Uri Guttman wrote:
>
> it should be:
>
> next unless test() ; # or return or whatver
>
> do LOTS of code at main level ;
>
> it saves block entry, indents, lines of code, braces and pixels. a 5 way
> win!
I do that quit a bit - it may not be structured, but saves
a lot of space to short circuit the code.
next if ...;
<more code>
or even like this:
if (...) { <some short code>; next; }
also saves an indent level.
To me all code has to fit in 80 columns or less except for the rare
occasion where you have some really long names/white space that can't
be split.
Sometimes I back-dent code (take 1 or more tabs off and add 2 spaces)
that's long and not easily splittable to make it easier to read (and
since it's fairly rare):
if (...) {
print
"some-really-long-thingy-that-doesn't-split-well\n";
}
------------------------------
Date: Sun, 23 Feb 2014 01:32:58 -0500
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: obj 8-2
Message-Id: <87eh2u72zp.fsf@stemsystems.com>
>>>>> "$" == $Bill <news@todbe.com> writes:
$> On 2/22/2014 19:48, Uri Guttman wrote:
>>
>> it should be:
>>
>> next unless test() ; # or return or whatver
>>
>> do LOTS of code at main level ;
>>
>> it saves block entry, indents, lines of code, braces and pixels. a 5 way
>> win!
$> I do that quit a bit - it may not be structured, but saves
$> a lot of space to short circuit the code.
it is structured. just structured better! using control flow ops is a
good thing. the old 'structured programming' where you must return only
on one place and only leave loops at the top is anal. it was better than
spaghetti code but the langs in those days didn't have the flow power of
perl and other modern langs. anything was better than goto hell.
$> next if ...;
$> <more code>
$> or even like this:
$> if (...) { <some short code>; next; }
$> also saves an indent level.
i generally will never put a real block on one line. just too
dense. maybe in a dispatch table with some short anon subs that can
work and i have done that.
uri
------------------------------
Date: Sun, 23 Feb 2014 08:15:32 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: obj 8-2
Message-Id: <4anota-un71.ln1@anubis.morrow.me.uk>
Quoth "$Bill" <news@todbe.com>:
>
> To me all code has to fit in 80 columns or less except for the rare
> occasion where you have some really long names/white space that can't
> be split.
Perl code can always be split, and IMHO code should always fit into 80
columns. More than that and it becomes hard to read. (Any book designer
will tell you text becomes hard to read with lines of more than 60-70
characters. Code usually has indent on the left, but code is also
usually denser than text, so 80-columns-or-less is a good length.)
The only thing that can't be split is heredocs, and they don't really
count as 'Perl code'. (If you've got identifiers more than 30-odd
characters long I don't want to know...)
> Sometimes I back-dent code (take 1 or more tabs off and add 2 spaces)
I would say that's a sign your code is nested too deeply, though
possibly not if you mean real 8-column tabs. 8-column tabs are good for
C, which shouldn't nest too deep; 4-column is better for Perl, which can
usefully be nested deeper.
> that's long and not easily splittable to make it easier to read (and
> since it's fairly rare):
>
> if (...) {
> print
> "some-really-long-thingy-that-doesn't-split-well\n";
I'd make that a heredoc.
Ben
------------------------------
Date: Sun, 23 Feb 2014 15:10:19 -0600
From: John Black <johnblack@nospam.com>
Subject: Re: obj 8-2
Message-Id: <MPG.2d741fb7b61cbdd39897b3@news.eternal-september.org>
In article <lec1o4$iav$1@dont-email.me>, news@todbe.com says...
> always staying in my 80 col space.
80 columns is so 1980s, no? (maybe 90s)
John Black
------------------------------
Date: Sun, 23 Feb 2014 22:19:04 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: obj 8-2
Message-Id: <slrnlgkpe8.nh1.hjp-usenet3@hrunkner.hjp.at>
On 2014-02-23 21:10, John Black <johnblack@nospam.com> wrote:
> In article <lec1o4$iav$1@dont-email.me>, news@todbe.com says...
>> always staying in my 80 col space.
>
> 80 columns is so 1980s, no? (maybe 90s)
The VT102 could be switched to 132 characters per line.
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, 24 Feb 2014 00:13:26 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: obj 8-2
Message-Id: <20140223160953.682@kylheku.com>
On 2014-02-23, John Black <johnblack@nospam.com> wrote:
> In article <lec1o4$iav$1@dont-email.me>, news@todbe.com says...
>> always staying in my 80 col space.
>
> 80 columns is so 1980s, no? (maybe 90s)
In 1984 I had an Apple II+ compatible computer with an 80 column
card. It was supported by software like ASCII Express Pro, a serial
communication program with terminal emulation. The CP/M operating system
cheerfully used the 80 column card also.
The IBM PC monochrome display had 80 columns, in 1981:
http://en.wikipedia.org/wiki/IBM_Monochrome_Display_Adapter
"The Monochrome Display Adapter (MDA, also MDA card, Monochrome Display and
Printer Adapter, MDPA) introduced in 1981 [...] had only a single monochrome
text mode (PC video mode 7), which could display 80 columns by 25 lines of
high resolution text characters or symbols useful for drawing forms."
That's not to mention all kinds of terminals: DEC, WYSE, you name it.
You could go into any library in North America and do a catalog search
on an 80 column amber or green screener.
------------------------------
Date: Sun, 23 Feb 2014 18:10:33 -0800
From: "$Bill" <news@todbe.com>
Subject: Re: obj 8-2
Message-Id: <lee9mo$gu4$1@dont-email.me>
On 2/23/2014 13:10, John Black wrote:
> In article <lec1o4$iav$1@dont-email.me>, news@todbe.com says...
>> always staying in my 80 col space.
>
> 80 columns is so 1980s, no? (maybe 90s)
You mean back when Perl was created ? ;)
Have you ever heard of an 029 ?
Everything was 80 columns since the 60s when IBM invented
card punches.
Terminals were mostly all 80 columns.
It's more than enough width to keep things easy to read without
sucking up your entire monitor width these days.
------------------------------
Date: Sun, 23 Feb 2014 05:17:05 -0800 (PST)
From: nanoseoweb@gmail.com
Subject: seo services in hyderabad
Message-Id: <55222de3-5017-40a9-9223-feb9d0353c41@googlegroups.com>
SEO is not a one size option. Be very careful not to everyone as the top SE=
O packages . This is not a fixed price or quantity package SEO Keywords , i=
ts price problem thats .
http://nanoseoweb.blogspot.in/2014/02/seo-services.html
Return different results , it is clear that the competition for each keywor=
d, the keyword that has a single amount. Without reverse engineering so the=
y competitiveness of each keyword, x amount of money to the page of Google =
for keywords that someone was able to get x Love is just a charlatan.
------------------------------
Date: Sun, 23 Feb 2014 23:31:59 -0600
From: Marek Novotny <mach2@hushmail.com>
Subject: use strict; use warnings;
Message-Id: <4OKdnZHJl9PSRJfOnZ2dnUVZ_sqdnZ2d@supernews.com>
Hi group,
Tonight I finished up another obj for my class. The class has not yet
started to learn about use strict; and use warnings;
I was given the following to solve:
# Objective 1:
# The pop function "pops" off the last element of an array
# and returns it. It works like this:
#
# $element = pop(@array);
#
# The shift function works the same way, but removes an element
# from the front of an array.
#
# Using pop, shift, push, and the starting code below, write a script
# that sufficiently "shuffles" a simulated deck of cards before printing
# the top five cards. Save this script in your home directory as
# obj10.pl.
#
# The goal of this objective is to familiarize yourself
# with these three functions while using loops and to use them
# together to rearrange the array but not a randomly shuffled array.
@startingdeck = ("A H","2 H","3 H","4 H","5 H","6 H","7 H","8 H",
"9 H","10 H","J H","Q H","K H",
"A D","2 D","3 D","4 D","5 D","6 D","7 D","8 D",
"9 D","10 D","J D","Q D","K D",
"A C","2 C","3 C","4 C","5 C","6 C","7 C","8 C",
"9 C","10 C","J C","Q C","K C",
"A S","2 S","3 S","4 S","5 S","6 S","7 S","8 S",
"9 S","10 S","J S","Q S","K S");
And here is my solution, which does not include the use of use strict;
and use warnings;
#!/usr/bin/perl
# file: obj10.pl
# Objective 1:
# The pop function "pops" off the last element of an array
# and returns it. It works like this:
#
# $element = pop(@array);
#
# The shift function works the same way, but removes an element
# from the front of an array.
#
# Using pop, shift, push, and the starting code below, write a script
# that sufficiently "shuffles" a simulated deck of cards before printing
# the top five cards. Save this script in your home directory as
# obj10.pl.
#
# The goal of this objective is to familiarize yourself
# with these three functions while using loops and to use them
# together to rearrange the array but not a randomly shuffled array.
@startingdeck = ("A H","2 H","3 H","4 H","5 H","6 H","7 H","8 H",
"9 H","10 H","J H","Q H","K H",
"A D","2 D","3 D","4 D","5 D","6 D","7 D","8 D",
"9 D","10 D","J D","Q D","K D",
"A C","2 C","3 C","4 C","5 C","6 C","7 C","8 C",
"9 C","10 C","J C","Q C","K C",
"A S","2 S","3 S","4 S","5 S","6 S","7 S","8 S",
"9 S","10 S","J S","Q S","K S");
# separate the hearts and organize them in order
my $i = 0;
while ($i < 13){
@hearts[$i] = shift(@startingdeck);
$i++;
}
$ace = shift(@hearts);
push(@hearts, $ace);
# separate the diamonds and organize them in order
my $i = 0;
while ($i < 13){
@diamonds[$i] = shift(@startingdeck);
$i++;
}
$ace = shift(@diamonds);
push(@diamonds, $ace);
# separate the clubs and organize them in order
my $i = 0;
while ($i < 13){
@clubs[$i] = shift(@startingdeck);
$i++;
}
$ace = shift(@clubs);
push(@clubs, $ace);
# separate the spades and organize them in order
my $i = 0;
while ($i < 13){
@spades[$i] = shift(@startingdeck);
$i++;
}
$ace = shift(@spades);
push(@spades, $ace);
# put the organized cards back in the starting deck
push (@startingdeck, @hearts, @diamonds, @clubs, @spades);
# sort the suits in reverse high order stating with ace, kings, etc.
my $i = 0;
while ($i < 51){
@sorted[$i] = pop(@hearts); $i++;
@sorted[$i] = pop(@diamonds); $i++;
@sorted[$i] = pop(@clubs); $i++;
@sorted[$i] = pop(@spades); $i++;
}
# print the top 5 highest cards
print "\nThe top five cards are: \n\n";
my $i = 0;
while ($i < 5){
print "@sorted[$i], ";
$i++;
}
print "\n\n";
When I started to try to use the use strict and warnings, I got warnings
such as: Scalar value @diamonds[$i] better written as $diamonds[$i] at ./
obj10.pl line 55.
But the whole point of what I am doing is loading elements into an
array... So I wanted it as @diamonds, not $diamonds, and so on.
I tried to make the code as simple to understand as possible.
Anyone care to take a stab at what it would have to look like with the
use of strict and warnings so I can understand what I should be doing?
--
Marek Novotny
A member of the Linux Foundation
http://www.linuxfoundation.org
------------------------------
Date: Mon, 24 Feb 2014 08:37:06 +0200
From: Marius Gavrilescu <marius@ieval.ro>
Subject: Re: use strict; use warnings;
Message-Id: <87eh2thv8t.fsf@ieval.ro>
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Marek Novotny <mach2@hushmail.com> writes:
> When I started to try to use the use strict and warnings, I got warnings=
=20
> such as: Scalar value @diamonds[$i] better written as $diamonds[$i] at ./
> obj10.pl line 55.
>
> But the whole point of what I am doing is loading elements into an=20
> array... So I wanted it as @diamonds, not $diamonds, and so on.=20
In Perl, the tenth element of array @something is $something[10]. So the
warnings are correct =E2=80=94 you should write $diamonds[$i] instead of
@diamonds[$i].
Another problem is that you declare the $i variable multiple times. You
should only declare it once, the first time you use it. You can also
refactor
my $i =3D 0;
while ($i < 13){
$spades[$i] =3D shift(@startingdeck);
$i++;
}
to
for (my $i =3D 0 ; $i < 13 ; $i++) {
$spades[$i] =3D shift(@startingdeck);
}
Finally, there are several undeclared variables (@hearts, @diamonds,
@spades, @clubs, @sorted, $ace).
After fixing these three problems the code should run without warnings
under use strict; use warnings;
=2D-=20
Marius Gavrilescu
--=-=-=
Content-Type: application/pgp-signature
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1
iQIcBAEBCgAGBQJTCuiSAAoJEMoENb5ewbNiiHEP/jwwTB6zhIUmT28HW1uzsIWF
iwdYvfStkWhMnGuT5O2ZEkEMFIiepFy1PW9/eFzvT0fC6b3fVIAr4AruBQf67Zh/
k5Spkn+Sd+OweUbGJ3lRRaEow4iwPHXTVAfy0O+3qdZaRhXyJnx/dtx363fqjUPo
VyxUHkT6iK/HBD0fqz+GNxT/2c0S1Pi7YED1xr7FbhJ9iO63lDFXlkOw+Woacyv4
gZsw8LEekOZu08AD5ggeMhFNr8SrWsvY59ux5QdU/319/3UoAXiK+VVK6mXy9rvO
2n5GBuPBqAvrgkWmI9cZb9VWuqANSpjz65+z29i9gdRvFa2IJble4scpmtdDSlpw
/w3VobCmuzVBSerSpiXQVQZBavuJ87DIYamDrzdGgThqgSzg9MdGhCbo6EIb7gOm
i5Ph19hdlB7p2RuNITr3X/noYJzEzhOTKYURuuEF92ehMhEVxdh76+YbeDn9jZDO
+ltZ2l1eBRYT4IzIo9KMAq2jyH6ZM+Ah0e2CVPHL3GObiCrGdIiiBYFS2sPBxF85
qpMl3NjI7Ia7J/dIJKpazylV+PtWhxjAM5MA1I9bSpEO3srdQ9sUPXfGwXYRjRUY
uIO+IPOVF0s4bhtwxISY1E1ED2LlhSt+eoh+zQwe7RPRY2r8zxGkLQZO00TPNji2
BQuT1PBMa9MMhChfxSVN
=coba
-----END PGP SIGNATURE-----
--=-=-=--
------------------------------
Date: Mon, 24 Feb 2014 07:35:31 +0000 (UTC)
From: Kaz Kylheku <kaz@kylheku.com>
Subject: Re: use strict; use warnings;
Message-Id: <20140223233047.193@kylheku.com>
On 2014-02-24, Marek Novotny <mach2@hushmail.com> wrote:
> Hi group,
>
> Tonight I finished up another obj for my class. The class has not yet
> started to learn about use strict; and use warnings;
>
> I was given the following to solve:
>
> # Using pop, shift, push, and the starting code below, write a script
> # that sufficiently "shuffles" a simulated deck of cards before printing
^^^^^^^^^^
You implemented:
> # sort the suits in reverse high order stating with ace, kings, etc.
^^^^
>
> my $i = 0;
> while ($i < 51){
> @sorted[$i] = pop(@hearts); $i++;
> @sorted[$i] = pop(@diamonds); $i++;
> @sorted[$i] = pop(@clubs); $i++;
> @sorted[$i] = pop(@spades); $i++;
> }
Nice as it is, your program doesn't implement the requirement of shuffling!
------------------------------
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 4147
***************************************
