[30064] in Perl-Users-Digest
Perl-Users Digest, Issue: 1307 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Feb 25 14:19:34 2008
Date: Mon, 25 Feb 2008 11:19:26 -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, 25 Feb 2008 Volume: 11 Number: 1307
Today's topics:
Re: setting %ENV in a module <ben@morrow.me.uk>
Re: setting %ENV in a module <pgodfrin@gmail.com>
Re: Spreadsheet::ParseExcel - How to get certain Cells <glex_no-spam@qwest-spam-no.invalid>
Threading NOT working as expected <r.ted.byers@rogers.com>
Re: Threading NOT working as expected <joost@zeekat.nl>
Re: Threading NOT working as expected xhoster@gmail.com
Re: Threading NOT working as expected <r.ted.byers@rogers.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 25 Feb 2008 16:46:30 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: setting %ENV in a module
Message-Id: <608b95-qj4.ln1@osiris.mauzo.dyndns.org>
Quoth pgodfrin <pgodfrin@gmail.com>:
>
> Thanks for the advice. Yes this is only example or testing code. And
> thanks for explaining the RE - that helps a lot. I wasn't aware that
> it was OK to permit file handles to close by going out of scope,
This only applies to lexical filehandles (those opened like
open my $FH, ...
) of course. Global filehandles (those opened like
open FH, ...
) never go out of scope.
> So essentially all I want to do is the DBA stuff, using perl instead
> of shell, which is why you see me asking questions about environment
> variables and executing processes in the background :).
There's no problem with that :). Perl was designed for systems
administration, after all. If you get to the point of actually talking
to a database, you may want to check out the DBI module, which provides
an extremely flexible interface to practically every database there is
from Perl. It's often easier to use than trying to feed commands to the
database-provided utilities.
> In any case, the reason I predeclared the $VERSION and the @...
> subroutines is because I saw that in an example in some discussion of
> making perl modules. Could you suggest a definitive doc for creating
> modules?
Yes, there's an *awful* lot of bad Perl advice out there. A good place
to start is perldoc perlnewmod; you can ignore some of the advice that
assumes you will be uploading your module to CPAN (presumably you
won't), but from experience I would recommend packaging your modules up
into proper CPAN-style distributions. It's not hard, and the 'extra'
work you are prompted to do (writing documentation and tests) is well
worth doing anyway, and makes it much easier to install them on a new
machine, which inevitably turns out to be necessary :).
> About the use Env and Env::import - my goal for these perl scripts
> (programs?) was to make them executable from either the command line,
> cron or some other scheduling package. So, I am indeed trying to avoid
> a hash lookup, mostly for cosmetic's sake, but also for other DBA's
> who have never seen perl and refuse to be brought into the [perl]
> fold. It would be easier for them to see $mydir="$HOME" as opposed to
> $mydir=$ENV{HOME}.
Really? I would have thought if they are unwilling to learn even that
much Perl there's little point them even trying to modify the scripts.
> However, I am in the habit of calling Env qw(HOME); so as to minimize
> what I'm using.
Yes, that is better.
> But to be honest I really don't fully understand module coding and
> "EXPORTing" and what the difference is between use Mymod and use Mymod
> qw(setrun) really is. which is why I asked about a definitive doc for
> that...
perldoc perlmod, and perldoc Exporter which that points you to. Note
that the code examples in perldoc Exporter, at least as of 5.8.8, do not
'use strict', which is against current best practices.
Ben
------------------------------
Date: Mon, 25 Feb 2008 10:06:45 -0800 (PST)
From: pgodfrin <pgodfrin@gmail.com>
Subject: Re: setting %ENV in a module
Message-Id: <96904467-cad3-4548-bf78-4c768b4d01e5@p73g2000hsd.googlegroups.com>
On Feb 25, 10:46 am, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth pgodfrin <pgodf...@gmail.com>:
>
>
>
> > Thanks for the advice. Yes this is only example or testing code. And
> > thanks for explaining the RE - that helps a lot. I wasn't aware that
> > it was OK to permit file handles to close by going out of scope,
>
> This only applies to lexical filehandles (those opened like
>
> open my $FH, ...
>
> ) of course. Global filehandles (those opened like
>
> open FH, ...
>
> ) never go out of scope.
>
> > So essentially all I want to do is the DBA stuff, using perl instead
> > of shell, which is why you see me asking questions about environment
> > variables and executing processes in the background :).
>
> There's no problem with that :). Perl was designed for systems
> administration, after all. If you get to the point of actually talking
> to a database, you may want to check out the DBI module, which provides
> an extremely flexible interface to practically every database there is
> from Perl. It's often easier to use than trying to feed commands to the
> database-provided utilities.
>
> > In any case, the reason I predeclared the $VERSION and the @...
> > subroutines is because I saw that in an example in some discussion of
> > making perl modules. Could you suggest a definitive doc for creating
> > modules?
>
> Yes, there's an *awful* lot of bad Perl advice out there. A good place
> to start is perldoc perlnewmod; you can ignore some of the advice that
> assumes you will be uploading your module to CPAN (presumably you
> won't), but from experience I would recommend packaging your modules up
> into proper CPAN-style distributions. It's not hard, and the 'extra'
> work you are prompted to do (writing documentation and tests) is well
> worth doing anyway, and makes it much easier to install them on a new
> machine, which inevitably turns out to be necessary :).
>
> > About the use Env and Env::import - my goal for these perl scripts
> > (programs?) was to make them executable from either the command line,
> > cron or some other scheduling package. So, I am indeed trying to avoid
> > a hash lookup, mostly for cosmetic's sake, but also for other DBA's
> > who have never seen perl and refuse to be brought into the [perl]
> > fold. It would be easier for them to see $mydir="$HOME" as opposed to
> > $mydir=$ENV{HOME}.
>
> Really? I would have thought if they are unwilling to learn even that
> much Perl there's little point them even trying to modify the scripts.
>
> > However, I am in the habit of calling Env qw(HOME); so as to minimize
> > what I'm using.
>
> Yes, that is better.
>
> > But to be honest I really don't fully understand module coding and
> > "EXPORTing" and what the difference is between use Mymod and use Mymod
> > qw(setrun) really is. which is why I asked about a definitive doc for
> > that...
>
> perldoc perlmod, and perldoc Exporter which that points you to. Note
> that the code examples in perldoc Exporter, at least as of 5.8.8, do not
> 'use strict', which is against current best practices.
>
> Ben
cool beans about lexical file handles vs global filehandles - I've
learned something important there. I have 'graduated' to the DBI -
much easier than the dorky sqlplus & spool "interface". I'll examine
the perlnewdoc and others closer.
thanks again,
pg
------------------------------
Date: Mon, 25 Feb 2008 11:15:42 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Spreadsheet::ParseExcel - How to get certain Cells
Message-Id: <47c2f7bf$0$3579$815e3792@news.qwest.net>
Tom Brown wrote:
> Dear J.,
>
> many many thanks for your assistance. With your explanation it was quite
> easy to get the values I was looking for.
>
> Unfortunatelly, when I invoked the script on the live sheet (what the
> script is intended for), I am facing a new challenge. Before I start to
> describe it, please have a look on the data source/structure:
>
> [ A ] [ B ][ C ]
> [13] 1 Cell_B1 192.168.0.11
> [23] 2 Cell_B2 192.168.0.56
> [37] 3 Cell_B3 192.168.0.112
> [41] 4 Cell_B4 10.10.12.158
> [64] 5 Cell_B5 172.17.54.232
> [71] 6 Cell_B6 192.168.15.12
> [80] 7 Cell_B7 172.17.90.254
>
> As can be seen, the index is not consecutively numbered (due to some
> makros and VBS inside the Excel-sheet). Therefore, column A is the point
> of reference where I have to define the range to get the values from
> column C.
Ahhh... what? Where does column A come in to all of this?
The module processes rows and columns. If the worksheet
looks like that, and you want column 3, rows 3-6, then your code
looks OK. If you want something else, then I don't understand.
>
> I've tried it already by myself, but I do not get the correct values.
> Here is the failing candidate:
>
> [------------------------start of code--------------------------]
> my $oBook = $Excel_file->Parse('devices.xls');
> my ($oWkS, $oWkC);
>
> my $iSheet = $oBook->{Worksheet}[4];
> $oWkS = $oBook->{Worksheet}[$iSheet];
> print "--------- SHEET: ", $oWkS->{Name}, "\n"x2;
>
> for my $indexRow ( 3 .. 6 ) {
> my $indexColumn = 1;
^^^^^^^ that's not used.
> $oWkC = $oWkS->{Cells}[$indexRow][3];
> #print "( $iRow , $iColumn ) =>", $oWkC->Value, "\n" if($oWkC);
> print $oWkC->Value, "\n" if($oWkC);
> }
> [------------------------End of code--------------------------]
>
> In plaintext: I would like to get the values in column C for the range
> A3 .. A6. So, as result the script should give the following IP
> addresses back:
>
> 192.168.0.112
> 10.10.12.158
> 172.17.54.232
> 192.168.15.12
>
> So, where is my fault?
What values are you seeing?
>
> Once again, many thanks for any assistance.
I don't see anything wrong, so I'm guessing its maybe
that the macro's aren't supported, so the worksheet isn't
what you expect, or it's the wrong worksheet.
Uncomment the print, so you can tell what row and column is being
processed, compare it to your worksheet, and modify as needed. Maybe
print the upper left corner of values ( rows 0-6 and columns 0-3 )
to see how the values compare to the worksheet you're expecting.
for my $row ( 0 .. 6 ) {
for my $col ( 0 .. 3 ) {
my $oWkC = $oWkS->{Cells}[$row][$col];
print "[$row,$col]=", $oWkC->Value, " ";
}
print "\n"
}
------------------------------
Date: Mon, 25 Feb 2008 08:36:46 -0800 (PST)
From: Ted <r.ted.byers@rogers.com>
Subject: Threading NOT working as expected
Message-Id: <4333f09c-7a90-4abd-97f9-e5cecf3ec50d@e10g2000prf.googlegroups.com>
When I first tried creating perl threads, the main process ended after
the threads where created but before any of them really started. On
reading further, I saw that I had to join the threads so that the main
process would sit idle waiting for the threads to finish. So I added
statements to join each thread. But now, it looks like the
consequence of this is that the code in each thread is executed one
after the other, as if it was a single process rather than a set of
independantly executing threads. I had thought of joining only the
last created thread, but there is no guarantee that the last thread
will take the longest time to complete. So how do I create these
threads and guarantee that they will execute in parallel, and that the
main process will wait idle until all have finished? I am trying to
use a script to manage this analysis since there may be, in any given
batch, several dozen SQL scripts that need to be executed (each is
independant, of course, with no possibility of interacting with the
others), and I want to run these scripts by invoking a single perl
script that allows them to run in parallel making full use of all the
available computing resources.
Thanks
Ted
------------------------------
Date: Mon, 25 Feb 2008 17:51:28 +0100
From: Joost Diepenmaat <joost@zeekat.nl>
Subject: Re: Threading NOT working as expected
Message-Id: <874pbxughb.fsf@zeekat.nl>
Ted <r.ted.byers@rogers.com> writes:
> When I first tried creating perl threads, the main process ended after
> the threads where created but before any of them really started. On
> reading further, I saw that I had to join the threads so that the main
> process would sit idle waiting for the threads to finish. So I added
> statements to join each thread. But now, it looks like the
> consequence of this is that the code in each thread is executed one
> after the other, as if it was a single process rather than a set of
> independantly executing threads.
It shouldn't.
#!/usr/local/bin/perl -w
use strict;
use threads;
my @thrds = map { my $i = $_; threads->new(sub {
print "started $i\n";
sleep 2;
print "stopped $i\n" } ) } 0 .. 10;
$_->join for @thrds;
output:
started 0
started 1
started 2
started 3
started 4
started 5
started 6
started 7
started 8
started 9
started 10
stopped 0
stopped 1
stopped 2
stopped 3
stopped 4
stopped 5
stopped 6
stopped 7
stopped 8
stopped 9
stopped 10
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
------------------------------
Date: 25 Feb 2008 17:30:17 GMT
From: xhoster@gmail.com
Subject: Re: Threading NOT working as expected
Message-Id: <20080225123018.795$na@newsreader.com>
Ted <r.ted.byers@rogers.com> wrote:
> When I first tried creating perl threads, the main process ended after
> the threads where created but before any of them really started. On
> reading further, I saw that I had to join the threads so that the main
> process would sit idle waiting for the threads to finish. So I added
> statements to join each thread. But now, it looks like the
> consequence of this is that the code in each thread is executed one
> after the other, as if it was a single process rather than a set of
> independantly executing threads.
The problem is in line 42.
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Mon, 25 Feb 2008 10:18:11 -0800 (PST)
From: Ted <r.ted.byers@rogers.com>
Subject: Re: Threading NOT working as expected
Message-Id: <97695ff8-decb-43c7-b8c2-870364b5112d@h11g2000prf.googlegroups.com>
On Feb 25, 12:30=A0pm, xhos...@gmail.com wrote:
> Ted <r.ted.by...@rogers.com> wrote:
> > When I first tried creating perl threads, the main process ended after
> > the threads where created but before any of them really started. =A0On
> > reading further, I saw that I had to join the threads so that the main
> > process would sit idle waiting for the threads to finish. =A0So I added
> > statements to join each thread. =A0But now, it looks like the
> > consequence of this is that the code in each thread is executed one
> > after the other, as if it was a single process rather than a set of
> > independantly executing threads.
>
> The problem is in line 42.
>
> Xho
>
> --
> --------------------http://NewsReader.Com/--------------------
> The costs of publication of this article were defrayed in part by the
> payment of page charges. This article must therefore be hereby marked
> advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate=
> this fact.
Will calling 'system' within a thread block all other threads in the
process until it has returned? If so, then that may be where my
problem lies?
If not, then I am puzzled.
Thanks
Ted
------------------------------
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:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#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 1307
***************************************
