[31806] in Perl-Users-Digest
Perl-Users Digest, Issue: 3069 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Aug 10 00:09:23 2010
Date: Mon, 9 Aug 2010 21:09:07 -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, 9 Aug 2010 Volume: 11 Number: 3069
Today's topics:
Matrix Ops with Rational Output <dwarnold45@suddenlink.net>
OO instantiate <monkey@joemoney.net>
Re: OO instantiate <spamtrap@piven.net>
Re: OO instantiate <ben@morrow.me.uk>
Re: Question re calling subroutines <kst-u@mib.org>
Re: Question re calling subroutines <uri@StemSystems.com>
Re: Question re calling subroutines <ben@morrow.me.uk>
setting path in command window using perl <amishrughoonundon@gmail.com>
Re: setting path in command window using perl <sherm.pendley@gmail.com>
Re: setting path in command window using perl <ben@morrow.me.uk>
Re: setting path in command window using perl <jurgenex@hotmail.com>
Re: setting path in command window using perl <ben@morrow.me.uk>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 9 Aug 2010 20:25:53 -0700 (PDT)
From: David <dwarnold45@suddenlink.net>
Subject: Matrix Ops with Rational Output
Message-Id: <d9765bcd-439f-4bb8-8311-d939a36f0642@5g2000yqz.googlegroups.com>
All,
I have no experience with Perl modules that do linear algebra. I've
searched CPAN and see several.
Can someone advise me on what to use? I'd like to have the ability to
start with a matrix with integer entries, put it in reduced row
echelon form, with all of the entries as rational numbers, such as:
A =
4 0 0 2
-1 -3 0 1
0 2 0 -1
ans =
1 0 0 1/2
0 1 0 -1/2
0 0 0 0
Suggestions? This has to be in perl.
D.
------------------------------
Date: Mon, 09 Aug 2010 18:50:50 -0400
From: monkeys paw <monkey@joemoney.net>
Subject: OO instantiate
Message-Id: <fe6dnQZvp4XWG_3RnZ2dnUVZ_tKdnZ2d@insightbb.com>
I have a new and execute method in my module. I want
to propogate the args from new to execute, but i get
a null variable, plz see below:
package Cmtname;
use Stnet::DBH;
sub new {
my ($class, %opts) = @_;
my $self = \%opts;
bless $self, $class;
return $self;
}
sub execute {
my ($self, %opts);
use Data::Dumper;die 'DDDEBUG' . Dumper($self); # This is null
}
If i dump $self in "new" i get the correct args, in "execute" it
is null, what am i missing?
here is test script:
#!/bin/perl
use strict;
use lib '/web/docs/secure/dev/'; #Just location specific
use Cmtname;
my $c = new Cmtname(state => 'US', cmt_abbr => 'h');
$c->execute();
------------------------------
Date: Mon, 09 Aug 2010 18:40:09 -0500
From: Don Piven <spamtrap@piven.net>
Subject: Re: OO instantiate
Message-Id: <yOCdnVKASbVLDP3RnZ2dnUVZ_g2dnZ2d@speakeasy.net>
On 08/09/2010 05:50 PM, monkeys paw wrote:
> I have a new and execute method in my module. I want
> to propogate the args from new to execute, but i get
> a null variable, plz see below:
>
> [...]
>
> sub execute {
> my ($self, %opts);
> use Data::Dumper;die 'DDDEBUG' . Dumper($self); # This is null
> }
>
> If i dump $self in "new" i get the correct args, in "execute" it
> is null, what am i missing?
execute() gets passed a reference to the object, followed by any passed
arguments. However, you have to retrieve the object reference yourself
(just as you'd have to do with regular arguments) which you don't do in
your example above. Try:
sub execute {
my $self = shift ; # $self now has reference to object
... # and the args you passed to new()
print $self->{state} ; # can be accessed in the usual way
}
Don
------------------------------
Date: Tue, 10 Aug 2010 00:56:54 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: OO instantiate
Message-Id: <67h6j7-7lb.ln1@osiris.mauzo.dyndns.org>
Quoth monkeys paw <monkey@joemoney.net>:
>
> my $c = new Cmtname(state => 'US', cmt_abbr => 'h');
This is better written
my $c = Cmtname->new(state => 'US', ...);
The form you have used is called 'dative method syntax' or 'indirect
object syntax' and can cause hard-to-debug problems.
Ben
------------------------------
Date: Mon, 09 Aug 2010 19:38:01 -0700
From: Keith Thompson <kst-u@mib.org>
Subject: Re: Question re calling subroutines
Message-Id: <ln1va719bq.fsf@nuthaus.mib.org>
"Uri Guttman" <uri@StemSystems.com> writes:
>>>>>> "KT" == Keith Thompson <kst-u@mib.org> writes:
> KT> I tend to omit parentheses in many cases where they're not necessary.
> KT> For example, I might write:
>
> KT> sub Foo;
> KT> ...
> KT> my $x = Foo 42; # rather than Foo(42)
> KT> ...
> KT> sub Foo {
> KT> my($arg) = @_;
> KT> return $arg + 1;
> KT> }
>
> that only works if you declare Foo before you call it. perl can't tell
> if a bareword is a sub if it hasn't seen it before unless you use parens.
Which is why I always predeclare all my subroutines.
> look at these examples which show why always using parens is a good thing:
>
> perl -we 'sub foo {print "hello\n" } ; foo'
> hello
>
> perl -we 'foo; sub foo {print "hello\n" }'
> Unquoted string "foo" may clash with future reserved word at -e line 1.
> Useless use of a constant in void context at -e line 1.
>
> perl -we 'foo(); sub foo {print "hello\n" }'
> hello
>
> KT> Would you consider this to be a bad habit? (I don't use "&" on
> KT> calls, and I've broken my previous habit of using prototypes.)
>
> yes, as i show above. btw, predeclaring also works for exported subs
> from a module. still i use parens. only with protoyped subs that need to
> look like builtins might i skip the parens.
The examples show that the parentheses are necessary if subroutines
aren't predeclared.
> KT> I know that parentheses are necessary for something like:
>
> KT> print "Foo 42 = ", Foo(42), "\n";
>
> KT> because without them the "\n" is passed to Foo, not to print.
>
> that is a precedence issue, not a predeclared one. if Foo were
> predeclared with a prototype of a single arg, the parens wouldn't be
> needed and it would work.
Right, but I've been persuaded that prototypes (at least as they
currently exist in Perl 5) are generally not as good an idea as I
once thought.
Still, I can certainly see that a policy of using parentheses for all
subroutine calls makes for more consistent code, and relieves you of
worrying about whether you can get away with omitting them or not.
I'll give it some thought.
Thanks.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
------------------------------
Date: Mon, 09 Aug 2010 23:20:49 -0400
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Question re calling subroutines
Message-Id: <8739untapa.fsf@quad.sysarch.com>
>>>>> "KT" == Keith Thompson <kst-u@mib.org> writes:
KT> "Uri Guttman" <uri@StemSystems.com> writes:
>>>>>>> "KT" == Keith Thompson <kst-u@mib.org> writes:
KT> I tend to omit parentheses in many cases where they're not necessary.
KT> For example, I might write:
>>
KT> sub Foo;
KT> ...
KT> my $x = Foo 42; # rather than Foo(42)
KT> ...
KT> sub Foo {
KT> my($arg) = @_;
KT> return $arg + 1;
KT> }
>>
>> that only works if you declare Foo before you call it. perl can't tell
>> if a bareword is a sub if it hasn't seen it before unless you use parens.
KT> Which is why I always predeclare all my subroutines.
and that is a waste of pixels as well. why do more work than you need
to? i review code for my recruiting business and i would downgrade any
code with predeclared subs. putting the subs before the calls makes for
a hard to read file. i put low importance subs at the bottom and order
the rest is some form of logical top down. this allows for easier
understanding of the code as you read it. and that means predeclaring
won't work. remember code is for people, not computers. and code is for
OTHER people, not yourself.
>> look at these examples which show why always using parens is a good thing:
>>
>> perl -we 'sub foo {print "hello\n" } ; foo'
>> hello
>>
>> perl -we 'foo; sub foo {print "hello\n" }'
>> Unquoted string "foo" may clash with future reserved word at -e line 1.
>> Useless use of a constant in void context at -e line 1.
>>
>> perl -we 'foo(); sub foo {print "hello\n" }'
>> hello
>>
KT> Would you consider this to be a bad habit? (I don't use "&" on
KT> calls, and I've broken my previous habit of using prototypes.)
>>
>> yes, as i show above. btw, predeclaring also works for exported subs
>> from a module. still i use parens. only with protoyped subs that need to
>> look like builtins might i skip the parens.
KT> The examples show that the parentheses are necessary if subroutines
KT> aren't predeclared.
and predeclaring is another bad habit.
KT> I know that parentheses are necessary for something like:
>>
KT> print "Foo 42 = ", Foo(42), "\n";
>>
KT> because without them the "\n" is passed to Foo, not to print.
>>
>> that is a precedence issue, not a predeclared one. if Foo were
>> predeclared with a prototype of a single arg, the parens wouldn't be
>> needed and it would work.
KT> Right, but I've been persuaded that prototypes (at least as they
KT> currently exist in Perl 5) are generally not as good an idea as I
KT> once thought.
good, then you are capable of learning and improving your style! :)
KT> Still, I can certainly see that a policy of using parentheses for all
KT> subroutine calls makes for more consistent code, and relieves you of
KT> worrying about whether you can get away with omitting them or not.
KT> I'll give it some thought.
s/some/a lot of/ ;
:)
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 10 Aug 2010 04:51:49 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Question re calling subroutines
Message-Id: <lvu6j7-a6g.ln1@osiris.mauzo.dyndns.org>
Quoth "Uri Guttman" <uri@StemSystems.com>:
> >>>>> "KT" == Keith Thompson <kst-u@mib.org> writes:
>
> KT> "Uri Guttman" <uri@StemSystems.com> writes:
> >>>>>>> "KT" == Keith Thompson <kst-u@mib.org> writes:
> KT> I tend to omit parentheses in many cases where they're not necessary.
> KT> For example, I might write:
> >>
> KT> sub Foo;
> KT> ...
> KT> my $x = Foo 42; # rather than Foo(42)
> KT> ...
> KT> sub Foo {
> KT> my($arg) = @_;
> KT> return $arg + 1;
> KT> }
> >>
> >> that only works if you declare Foo before you call it. perl can't tell
> >> if a bareword is a sub if it hasn't seen it before unless you use parens.
>
> KT> Which is why I always predeclare all my subroutines.
>
> and that is a waste of pixels as well. why do more work than you need
> to? i review code for my recruiting business and i would downgrade any
> code with predeclared subs.
Well, apart from anything else it moves errors from runtime to compile
time, which is always a good thing.
fop();
sub foo { 1; }
will compile just fine,
sub foo;
fop;
sub foo { 1; }
will give a strict error at compile time.
> putting the subs before the calls makes for
> a hard to read file. i put low importance subs at the bottom and order
> the rest is some form of logical top down. this allows for easier
> understanding of the code as you read it. and that means predeclaring
> won't work.
No it doesn't. Predeclarations of the form
sub foo;
or
use subs qw/foo/;
at the top of the file work just fine, no matter where the body of the
sub is.
FWIW I always avoid calling subs with () when I can, though I'm no
longer as convinced as I was that it's a good idea :). Perl's bareword
parsing is frankly terrifying once you understand what it actually does.
Ben
------------------------------
Date: Mon, 9 Aug 2010 13:41:13 -0700 (PDT)
From: Amish Rughoonundon <amishrughoonundon@gmail.com>
Subject: setting path in command window using perl
Message-Id: <e6efae81-34cc-45fd-9af5-f42ae3ab17e9@u26g2000yqu.googlegroups.com>
Hi,
here is my problem. I have a perl script that executes multiple
command line calls as follows:
system("XCOPY", "$s_currentWorkingDirectory\\KCPSM3.EXE",
$s_tempLocation, "/R", "/Y") == 0 or die "File KCPSM3.EXE could not be
copied: $!\n";
system("XCOPY", "$s_currentWorkingDirectory\\ROM_form.coe",
$s_tempLocation, "/R", "/Y") == 0 or die "File ROM_form.coe could not
be copied: $!\n";
This is an example. There are many more with different programs being
called.
My problem is that I need to set the path to a certain batch file
before calling the programs.
It seems everytime I call system though, perl open a command window,
executes the program and closes the window.
So even if I set the path at the beginning, once system is done
running, the path disappears.
Can I force perl to run everything into only 1 command window.
I hope I was clear with my question. Thanks a lot for the help,
Amish
------------------------------
Date: Mon, 09 Aug 2010 17:02:47 -0400
From: Sherm Pendley <sherm.pendley@gmail.com>
Subject: Re: setting path in command window using perl
Message-Id: <m2r5i7h53c.fsf@sherm.shermpendley.com>
Amish Rughoonundon <amishrughoonundon@gmail.com> writes:
> here is my problem. I have a perl script that executes multiple
> command line calls
...
> Can I force perl to run everything into only 1 command window.
Sure, just write all of the commands to a batch file, then use a single
system() call to run that batch file.
sherm--
--
Sherm Pendley
<camelbones.sourceforge.net>
Cocoa Developer
------------------------------
Date: Mon, 9 Aug 2010 23:50:37 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: setting path in command window using perl
Message-Id: <tad6j7-96b.ln1@osiris.mauzo.dyndns.org>
Quoth Amish Rughoonundon <amishrughoonundon@gmail.com>:
> Hi,
> here is my problem. I have a perl script that executes multiple
> command line calls as follows:
>
> system("XCOPY", "$s_currentWorkingDirectory\\KCPSM3.EXE",
> $s_tempLocation, "/R", "/Y") == 0 or die "File KCPSM3.EXE could not be
> copied: $!\n";
> system("XCOPY", "$s_currentWorkingDirectory\\ROM_form.coe",
> $s_tempLocation, "/R", "/Y") == 0 or die "File ROM_form.coe could not
> be copied: $!\n";
>
> This is an example. There are many more with different programs being
> called.
>
> My problem is that I need to set the path to a certain batch file
> before calling the programs.
What do you mean by 'set the path to a batch file'? Do you mean adding
an entry to %PATH%? You can do this by adding to $ENV{PATH} from Perl;
the environment in %ENV will be inherited by all the commands you run
with system.
Ben
------------------------------
Date: Mon, 09 Aug 2010 18:40:17 -0700
From: Jürgen Exner <jurgenex@hotmail.com>
Subject: Re: setting path in command window using perl
Message-Id: <f4b1669oc7qpsflifbl32md4sltcqvvkke@4ax.com>
Amish Rughoonundon <amishrughoonundon@gmail.com> wrote:
>here is my problem. I have a perl script that executes multiple
>command line calls as follows:
[...]
>My problem is that I need to set the path to a certain batch file
>before calling the programs.
No problem, just do so
$ENV{PATH} = .......
>It seems everytime I call system though, perl open a command window,
>executes the program and closes the window.
Of course. That is the semantic of system().
>So even if I set the path at the beginning, once system is done
>running, the path disappears.
Of course. Environment variables are never inherited from the child to
the parent.
>Can I force perl to run everything into only 1 command window.
Yes, you could. Just start all your external commands from the same DOS
command line:
system ("cmd1 & cmd2 & cmd3 & cmd4");
But why?
See also "perldoc -q environment":
I {changed directory, modified my environment} in a perl script. How
come the
change disappeared when I exited the script? How do I get my changes
to be visible?
jue
------------------------------
Date: Tue, 10 Aug 2010 04:42:17 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: setting path in command window using perl
Message-Id: <pdu6j7-a6g.ln1@osiris.mauzo.dyndns.org>
Quoth Jürgen Exner <jurgenex@hotmail.com>:
>
> See also "perldoc -q environment":
> I {changed directory, modified my environment} in a perl script. How
> come the
> change disappeared when I exited the script? How do I get my changes
> to be visible?
This is actually the inverse problem: "I modified my environment with
system(). How come the change disappeared when I got back to Perl?". The
answer is the same, of course, but it's not entirely surprising the OP
didn't find it.
Ben
------------------------------
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 3069
***************************************
