[24070] in Perl-Users-Digest
Perl-Users Digest, Issue: 6265 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Mar 16 14:05:41 2004
Date: Tue, 16 Mar 2004 11:05:06 -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 Tue, 16 Mar 2004 Volume: 10 Number: 6265
Today's topics:
ANNOUNCE: Javascript::MD5 V 1.01 <ron@savage.net.au>
Re: array performance- references problem <andreas.goetz.external@fujitsu-siemens.com>
Re: array performance- references problem <nobull@mail.com>
Can anybody help me use Perl to login to my account? (S. Brown)
Re: Errors installing Template CPAN module (FIXED!) <knocte@NO-SPAM-PLEASE-hotmail.com>
Re: Errors installing Template CPAN module (FIXED!) <1usa@llenroc.ude>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 16 Mar 2004 09:13:29 GMT
From: Ron Savage <ron@savage.net.au>
Subject: ANNOUNCE: Javascript::MD5 V 1.01
Message-Id: <HuoFt6.wCn@zorch.sf-bay.org>
The pure Perl module Javascript::MD5 V 1.01
is available immediately from CPAN,
and from http://savage.net.au/Perl-modules.html.
On-line docs, and a *.ppd for ActivePerl are also
available from the latter site.
An extract from the docs:
NAME
Javascript::MD5 - Calculate the MD5 digest of a CGI form field
Recent changes:
1.01 Tue Mar 16 14:36:00 2004
- Correct the docs, which somehow got chopped off in V 1.00
- There are no code changes, so there is no need to upgrade
--
Cheers
Ron Savage, ron@savage.net.au on 16/03/2004
http://savage.net.au/index.html
------------------------------
Date: Tue, 16 Mar 2004 17:18:05 +0100
From: "Andreas Goetz" <andreas.goetz.external@fujitsu-siemens.com>
Subject: Re: array performance- references problem
Message-Id: <c379bt$or2$1@nntp.fujitsu-siemens.com>
> > from @statements:
> > foreach $statement (@statements){
> > @lines = split("\n", $statement)
> > }
>
> You should always declare all variables as lexically scoped in the
> smallest applicable lexical scope unless there is a positive reason to
> do otherwise.
Agreed. Left out for clarity- shouldn't have done so :|
> > Comes Approach 2: Just use arrays: push @statements, [@lines]
> > later:
> > foreach $statement (@statements){
> > # use @{$statement}
> > }
> >
> > This should take care of the unneeded join/splits. Only problem:
performance
> > is worse by a factor of 5, probably due to pushing an array onto an
array?
> >
> > Approach 3: Use references: push @statements, \@lines
> > laster:
> > foreach $statement (@statements){
> > # use @$line;
> > }
>
> Note: both 2 and 3 use references. The difference is that 2 creates a
copy.
>
> push @statements, [@lines]
>
> Is much the same as
> {
> my @copy_of_lines = @lines;
> push @statements, \@copy_of_lines;
> }
OK. Then obviously copying the array is much slower than joining the data
and storing one string. Makes sense the longer I think about it :)
> > Only problem here: as I parse the log file into chunks of lines, I need
to
> > reuse the @lines array during parsing (after the push). Question is- how
do
> > I clean out (or recreate) @lines without destroying the reference stored
in
> > the array?
>
> If by "clean out" you mean clear then, you sould note that you should
> always declare all variables as lexically scoped in the smallest
> applicable lexical scope unless there is a positive reason to do
> otherwise. Doing so usually avoids this issue.
>
> > I think what I need is a 'fresh' variable that keeps the referenced data
> > intact.
>
> You mean something like
>
> my @copy_of_lines = @lines;
Indeed- but then again I'm copying the array which causes the performance
issue.
> You can even say...
>
> my @lines = @lines;
>
> ... but you'll get a warning if you are at the same scope where @lines
> was previously declared.
>
> > More or les like removing the link from @lines to the actual array
> > data it represents. Does this make sense?
>
> Only vaguely. If you want to have a two instances of the contents of
> @lines and be able to change one without changing the other then you
> are going to need to make a copy. It was the creating of a second
> copy that slowed you down in the first place.
Yes. But when I'm done with @lines I just want to store it (the data) in the
@statements array. But the code obviously needs to run again, using the
@lines variable.
I'd need to take the contents of @lines, put it somewhere and tell @lines to
remove the reference to the actual data and start clear.
ctcgag suggested that my @lines in the loop would leave the referenced data
intact, but unfortunately I need to declare it just a bit outside :(
> Are you sure you really need a copy? Could you perhaps alter the
> algorithm that reuses the @lines array during parsing (after the push)
> so that it doesn't alter the contents of @lines?
Mhhm. I'll need to think about that, but might be a bigger change.
Anyway- I do now understand that join/split is faster than array copy, but
couln't yet find a way to avoid either...
Thanks a lot,
Andi
------------------------------
Date: 16 Mar 2004 17:51:31 +0000
From: Brian McCauley <nobull@mail.com>
Subject: Re: array performance- references problem
Message-Id: <u9ekrsn0ik.fsf@wcl-l.bham.ac.uk>
"Andreas Goetz" <andreas.goetz.external@fujitsu-siemens.com> writes:
> Yes. But when I'm done with @lines I just want to store it (the data) in the
> @statements array. But the code obviously needs to run again, using the
> @lines variable.
> I'd need to take the contents of @lines, put it somewhere and tell @lines to
> remove the reference to the actual data and start clear.
>
> ctcgag suggested that my @lines in the loop would leave the referenced data
> intact, but unfortunately I need to declare it just a bit outside :(
You appear to be contradicting yourself above.
Can you produce mimimal but complete example script to illustrate of
what sort of thing you are doing such that you _need_ to declare @lines
outside the loop but it would be acceptable for the data to no longer
be accessible outside the loop.
--
\\ ( )
. _\\__[oo
.__/ \\ /\@
. l___\\
# ll l\\
###LL LL\\
------------------------------
Date: 16 Mar 2004 10:25:39 -0800
From: sallybonbons@yahoo.com (S. Brown)
Subject: Can anybody help me use Perl to login to my account?
Message-Id: <bba4f85b.0403161025.15ab4846@posting.google.com>
I am trying to login and grab information from my account on espn.com
so I can track my progress. Problem is I can't login and handle
cookies the right way. I have the following code. The out.html page
just shows a login screen with my username already filled in. So, it
identifies my POST variables, but it won't log me in. Any help?
Thanks.
#!perl -w
use LWP::UserAgent;
use HTTP::Cookies;
$ua = LWP::UserAgent->new;
$ua->cookie_jar(HTTP::Cookies->new(file =>
"lwpcookies.txt", autosave => 1));
# Create a request
my $req = HTTP::Request->new(POST =>
'https://r.espn.go.com/espn/fantasy/login');
$req->content_type('application/x-www-form-urlencoded');
# Login
$req->content('username=<username>&password=<pass>');
#$req->authorization_basic('gratner', 'motley');
# Pass request to the user agent and get a response back
my $res = $ua->request($req);
# Check the outcome of the response
if ($res->is_success) {
open (OUT, ">out.html");
print OUT $res->content;
}
else {
print $res->status_line, "\n";
}
------------------------------
Date: Tue, 16 Mar 2004 18:30:25 +0100
From: knocte <knocte@NO-SPAM-PLEASE-hotmail.com>
Subject: Re: Errors installing Template CPAN module (FIXED!)
Message-Id: <c37ddo$t0m$1@nsnmpen2-gest.nuria.telefonica-data.net>
knocte:
>>> Now enter the data source (DSN) for the test database.
>>> Many DBD drivers require only a database name (e.g. 'test') while
>>> others may require an alternate format or additional parameters
>>> (e.g. 'dbname=test'). Please consult your DBD documentation for
>>> further details.
>>>
>>> Database name: [test] test
>>> Enter user name : []
>>> Enter password : []
>>
>>
>>
>> do you have MySQL on your system? Is it running? Username and password
>> set properly (you haven't set these values - is this by design or did you
>> just blindly hit 'Enter'?)?
>
>
> I simply hit Enter... BUT, I know that I have MySQL running, and that
> there is a database called 'test', with all permissions granted to any
> user (I can enter mysql with no user and no password and change the
> database with insertions).
The problem was here: I had to use the mysql option: --database=name, so
I wrote 'database=test' (without the quotes). I think there should be a
FAQ about this on the Bugzilla page (www.bugzilla.org: the tool I am
trying to set up).
However, I yet get some errors (although the 'tests' are told to be OK
and the module is installed correctly):
t/dbi............ok 3/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 5/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 7/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 9/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 17/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 19/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 21/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 23/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 25/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 27/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 29/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 31/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 33/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 37/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 39/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 41/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 43/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 47/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 49/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 51/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
t/dbi............ok 53/63Use of uninitialized value in join or string at
/usr/lib/perl5/site_perl/5.8.3/i386-linux-thread-multi/DBI.pm line 1300,
<DATA> line 1.
Perhaps it's a bug of the Template module (or a Warning that gives the
compiler, which should be fixed).
Regards.
------------------------------
Date: 16 Mar 2004 18:28:17 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude>
Subject: Re: Errors installing Template CPAN module (FIXED!)
Message-Id: <Xns94AE8909F8CEDasu1cornelledu@132.236.56.8>
knocte <knocte@NO-SPAM-PLEASE-hotmail.com> wrote in
news:c37ddo$t0m$1@nsnmpen2-gest.nuria.telefonica-data.net:
> knocte:
> The problem was here:
...
Frankly, at this point, I am not sure anyone has the any goodwill left
towards you to give a hoot where your problem was or to help with new
problems.
Sinan
--
A. Sinan Unur
1usa@llenroc.ude (reverse each component for email address)
------------------------------
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 V10 Issue 6265
***************************************
