[32417] in Perl-Users-Digest
Perl-Users Digest, Issue: 3684 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon May 7 16:09:32 2012
Date: Mon, 7 May 2012 13: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 Mon, 7 May 2012 Volume: 11 Number: 3684
Today's topics:
Re: Goodbye, Tad McClellan <tzz@lifelogs.com>
How do I find an old Perl module on CPAN? <davidfilmer@gmail.com>
Re: How do I find an old Perl module on CPAN? <ben@morrow.me.uk>
Re: How do I find an old Perl module on CPAN? <brian.d.foy@gmail.com>
Re: How do I find an old Perl module on CPAN? <ben@morrow.me.uk>
Re: modifying dns zone TTL <ben@morrow.me.uk>
Re: modifying dns zone TTL <hjp-usenet2@hjp.at>
Re: passing a reference to a hash to another page <ben@morrow.me.uk>
Re: passing a reference to a hash to another page <cartercc@gmail.com>
Re: WWW::Mechanize and 3rd party APIs (Google) greymausg@mail.com
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 06 May 2012 10:23:44 -0400
From: Ted Zlatanov <tzz@lifelogs.com>
Subject: Re: Goodbye, Tad McClellan
Message-Id: <m28vh5v15b.fsf@lifelogs.com>
On Thu, 03 May 2012 09:16:22 -0700 merlyn@stonehenge.com (Randal L. Schwartz) wrote:
RLS> Longtime friend and senior Stonehenge trainer and manager Tad McClellan
RLS> lost his battle with lung cancer on Sunday. Rest in peace, my friend.
We'll miss him.
Ted
------------------------------
Date: Sat, 5 May 2012 18:28:02 -0700 (PDT)
From: David Filmer <davidfilmer@gmail.com>
Subject: How do I find an old Perl module on CPAN?
Message-Id: <f1bcfa36-ce3e-497f-94bf-2f219f03898a@qg5g2000pbc.googlegroups.com>
I am running old CGIs on a new box. I use the module
Convert::ASCII::String, which no longer appears on CPAN searches.
In the past, I was able to find an old module (Tools::SQL) because I
was able to determine the author's name (Kane) and found it on
backpan.perl.org. But this time, I have no knowledge of the module
except its name - I do not know the author's name (and have no readily
available means to find it). backpan seems to support only searches
by author name, not module name.
Thanks!
--
Sad news about Tad - condolences to his family and friends. He will
be missed on this newsgroup, and by me.
------------------------------
Date: Sun, 6 May 2012 02:47:54 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How do I find an old Perl module on CPAN?
Message-Id: <ar1h79-5nh.ln1@anubis.morrow.me.uk>
Quoth David Filmer <davidfilmer@gmail.com>:
> I am running old CGIs on a new box. I use the module
> Convert::ASCII::String, which no longer appears on CPAN searches.
>
> In the past, I was able to find an old module (Tools::SQL) because I
> was able to determine the author's name (Kane) and found it on
> backpan.perl.org. But this time, I have no knowledge of the module
> except its name - I do not know the author's name (and have no readily
> available means to find it). backpan seems to support only searches
> by author name, not module name.
In the general case I would try asking modules@perl.org. Once a
namespace has been registered on CPAN, it never gets unregistered, even
if the module is no longer present, so the PAUSE admins ought to be able
to tell you who last uploaded a registered version of that module.
In this particular case, a quick Google search suggests the module was
written by Steven Schubiger, and indeed SCHUBIGER's BackPAN directory
has several versions ending with 0.32 from 2004.
That said, you would do well to upgrade your CGIs as soon as possible.
Running unmaintained code in production is pretty dangerous.
Alternatively, of course, you could volunteer to maintain the module
yourself. The PAUSE admins have a procedure for handing over change
control for a namespace: essentially, you have to either get the
original author's permission, or demonstrate you have made an honest
attempt to get in touch with them and they are not responding.
Ben
------------------------------
Date: Sun, 06 May 2012 14:05:21 -0500
From: brian d foy <brian.d.foy@gmail.com>
Subject: Re: How do I find an old Perl module on CPAN?
Message-Id: <060520121405210687%brian.d.foy@gmail.com>
In article <ar1h79-5nh.ln1@anubis.morrow.me.uk>, Ben Morrow
<ben@morrow.me.uk> wrote:
> Quoth David Filmer <davidfilmer@gmail.com>:
> > I am running old CGIs on a new box. I use the module
> > Convert::ASCII::String, which no longer appears on CPAN searches.
> In the general case I would try asking modules@perl.org.
In the general case, before you bother them, try BackPAN:
http://backpan.perl.org, which has almost every distribution
ever uploaded. As you note, Google is helpful too.
> Once a
> namespace has been registered on CPAN, it never gets unregistered,
That's not quite true. If you look the bottom of your Module Metadata
page, you'll see a "Lifecycle" field. One of the options is "Can be
removed from database".
------------------------------
Date: Sun, 6 May 2012 22:45:00 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: How do I find an old Perl module on CPAN?
Message-Id: <sv7j79-8i01.ln1@anubis.morrow.me.uk>
Quoth brian d foy <brian.d.foy@gmail.com>:
> In article <ar1h79-5nh.ln1@anubis.morrow.me.uk>, Ben Morrow
> <ben@morrow.me.uk> wrote:
>
> > Quoth David Filmer <davidfilmer@gmail.com>:
> > > I am running old CGIs on a new box. I use the module
> > > Convert::ASCII::String, which no longer appears on CPAN searches.
>
> > In the general case I would try asking modules@perl.org.
>
> In the general case, before you bother them, try BackPAN:
> http://backpan.perl.org, which has almost every distribution
> ever uploaded. As you note, Google is helpful too.
The OP knew about BackPAN, but since he didn't know the author of the
module he was looking for, didn't know where to look. I don't believe
there is a by-module index of BackPAN?
But yes, a Google search (which took me all of about a minute) should
definitely come before bothering busy people, even those on Usenet.
> > Once a
> > namespace has been registered on CPAN, it never gets unregistered,
>
> That's not quite true. If you look the bottom of your Module Metadata
> page, you'll see a "Lifecycle" field. One of the options is "Can be
> removed from database".
I had forgotten that.
Ben
------------------------------
Date: Sun, 6 May 2012 00:40:51 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: modifying dns zone TTL
Message-Id: <3dqg79-f3g.ln1@anubis.morrow.me.uk>
Quoth herbert.burnswell@gmail.com:
>
> I'm looking to write a perl script to edit TTL's in zone files.
> Ideally, I'd like to write it as:
>
> ./script -f <filename> <newTTL>
>
> and
>
> ./script -d <directoryname> <newTTL>
>
> to either edit just one file or all files in a directory.
>
> I've installed and read the perldoc information on DNS::ZoneParse but
> still don't see how to set it up to edit the TTL.
>
> Questions:
>
> - Is DNS::ZoneParse indeed the best way to obtain the desired
> functionality or is there a better way to do this?
I'm not sure I entirely like the look of it, myself. For this job you
would have to iterate over all the individual record types, changing the
TTL for each, and it has no support for record types it isn't expecting.
(This may not be an issue, of course.) It will also completely reorder
your zone file when rewriting it.
I might try Net::DNS::ZoneFile instead. That will give you a list of
Net::DNS::RR objects, and you can then adjust the TTL and print each one
out in the same order as they came in. They will be completely
reformatted, of course, and you will lose all your comments.
The other option is to try to replace the TTLs using regexes. There are
people here who thoroughly disapprove of this approach, and in principle
they are right: it's extremely difficult to be sure your patterns won't
do anything unexpected, especially with a format as badly-specified as
the zone file format. I would only want to take this route if the new
files were going to be checked by a human before being put into
production: carefully checking a diff between old and new files should
be enough to make sure nothing stupid has happened.
The third option, which would be the one I would go for, is to change
your system so the zone files are generated. Find a macro-expansion
system you like--you could use something relatively crude like m4, or
you could use something Perl-based like Template::Simple or even
TT2--and go through all the files, once, by hand or with an editor
macro, replacing all the TTLs with a macro reference. Then you can
change them all by changing the definition of your macro and
regenerating them all.
Ben
------------------------------
Date: Sun, 6 May 2012 10:11:13 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: modifying dns zone TTL
Message-Id: <slrnjqcch2.1v2.hjp-usenet2@hrunkner.hjp.at>
On 2012-05-04 23:21, herbert.burnswell@gmail.com <herbert.burnswell@gmail.com> wrote:
> I'm looking to write a perl script to edit TTL's in zone files. Ideally, I'd like to write it as:
>
> ./script -f <filename> <newTTL>
>
> and
>
> ./script -d <directoryname> <newTTL>
>
> to either edit just one file or all files in a directory.
Not a direct answer to your question, but it may simplify the problem:
If you want all the records in the zone file to have the same TTL,
add a $TTL directive at the top and omit the TTL in the individual
records.
hp
--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | hjp@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on asrg@irtf.org
------------------------------
Date: Sun, 6 May 2012 00:17:38 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: passing a reference to a hash to another page
Message-Id: <i1pg79-ctf.ln1@anubis.morrow.me.uk>
Quoth ccc31807 <cartercc@gmail.com>:
>
> What I need is a button on the display that will allow the user to
> print a document using the same hashref. I don't want to run the query
> again, and don't particularly want to store the data (using Storable,
> perhaps), but to pass the hashref to another page via an HTTP request,
> and have the second page open a file, print to the file, close the
> file, and return a link to the user.
>
> Unfortunately, the hashref doesn't persist between invocations of the
> script and new HTTP requests. For example, I can do this:
> <a href="mydata?what=printcsv&data=HASH(0xDEADBEEF)"
> target="_blank">Print a file</a>
>
> But all I get is the value 'HASH(0xDEADBEEF)". I can't dereference it
> to get at the data.
This is the same problem as that addressed by perldoc -q 'reference as a
hash key', with (as Rainer pointed out) the added problem that you have
no guarantee that the second request will be handled by the same process
as the first. Even if you set up some sort of persistent perl process,
and (somehow) arrange for a given user to always talk to the same
instance, you have to assume the server might crash and restart between
one response and the next, at which point all in-memory data is lost.
Given that, you *have* to serialise the hash somewhere between requests.
Sending it down to the client, as a hidden form field or a cookie, seems
like an attractive option; but it is only practical for small amounts of
data. For large amounts, or for data the client shouldn't be able to
change in arbitrary ways, you need to serialise it server-side.
Unless your query takes a long time to run, re-running the query is
probably the simplest option. (You should seriously consider whether you
can make this possible.) If that takes too long, all the other options
basically boil down to some sort of cache:
- You may be able to change your database schema to make the query
run faster: probably this means denormalising it in some way. Can
you arrange to store the results you need in another table or
tables, possibly with triggers or stored procedures or something
inside the database to keep it up to date?
- Otherwise, you will need to serialise the Perl data structure and
store it somewhere. The simple-minded way of doing this would be
to use Storable, and either put it in plain files or in some sort
of DBM file. You would then need to pass the filename or the key
down to the client, and retrieve the data when the client passes
it back. You would also need to think *carefully* about
concurrency and locking, unless you use something like the later
versions of BDB (with the BerkeleyDB module, rather than with
DB_File) which will handle this for you.
- This only works if all your requests are handled by one machine,
or at least if they all have access to the same filesystem (and
that filesystem is completely reliable wrt multiple concurrent
writes from different machines, which most network filesystems
aren't). A good cross-machine solution is memcached; the
Cache::Memcached module will handle the Storing for you
transparently, though of course you do have to make sure your data
structure is suitable for Storing.
You could of course also just serialise the data into a blob in a
database column, but that always seems like a bad idea to me. The whole
point of an SQL database is that it can see inside the structure of your
data and make intelligent decisions about how to plan queries based on
that; if all you need is a key-value store, something like BDB or
memcached which was designed to be that and no more will be both faster
and cleaner.
> Seems like I should be able to tell the program to hold onto the
> hashref between invocations of the script,
Only because you haven't yet understood that HTTP is a stateless
protocol. This is what that means: that keeping data across requests has
to be done explicitly.
Ben
------------------------------
Date: Sun, 6 May 2012 18:46:32 -0700 (PDT)
From: ccc31807 <cartercc@gmail.com>
Subject: Re: passing a reference to a hash to another page
Message-Id: <08e6faeb-af20-4ed7-86b1-48b453f49973@f37g2000yqc.googlegroups.com>
On May 4, 6:20=A0pm, Rainer Weikusat <rweiku...@mssgmbh.com> wrote:
> This is impossible except if you're using a persistent perl
> interpreter (eg mod_perl) and the next request of the user happens to
> be processed by the same process and the hashref hasn't been
> deallocated in the meantime, say, because an entry in a 'global' hash
> table points to it. You'll either have to store it locally, possibly,
> using some module which provides session support or send it to the
> user and have him send it back, for instance, putting a textual
> representation of the hashref in a hidden form field.
Thanks, Ranier and Ben.
I've decided to hit the database every time a user requests data,
regardless of the purpose.
I'm sending the search parameters via a form, and I have modularized
both the presentation of the form and the response to the form.
Instead of printing the output back to Apache, I'll just open a file
and send it to the file.
Lest you think that I was confused, let me assure you that I was
indeed confused. The idea that I had was that, since the data resided
somewhere in memory, and since I had the address of that memory,
instead of losing the reference to the hash I would reuse it. I do
this routinely with scripts that I have written for the purpose of
printing reports, i.e., printing them directly without displaying them
to the user, and thought I could both print the data to HTML output
and print the data to a file afterward with an intervening HTTP
request, but just couldn't think it through.
Thanks for your time and help -- I appreciate it.
CC.
------------------------------
Date: 5 May 2012 21:44:23 GMT
From: greymausg@mail.com
Subject: Re: WWW::Mechanize and 3rd party APIs (Google)
Message-Id: <slrnjqb0p1.2dv.greymausg@gmaus.xxx>
On 2012-05-03, Adam Russell <ac.russell@live.com> wrote:
> On 4/23/12 9:41 AM, Justin C wrote:
>> I'm trying to mechanize a site which returns data
>> depending the location you enter into a form, and a
>> distance from that location (selected from a
>> drop-down). I was completing the form and submitting
>> it, as I would in a browser, but not getting the
>> result I expected.
>>
>> On further investigation it appears that the site
>> sends the location information to GoogleMaps
>> (JavaScript), which returns a location that gets
>> substituted into the form before it is submitted.
>>
>> Has anyone automated a site like this before? Can you
>> offer any suggestion as to how I interact with
>> Google's API?
> I have never interacted with Google's API at all. Randal's
> advice is certainly sound.
> I would like to add that, in general, I have had good advice
> with WWW::Scripter which subclasses WWW::Mechanize and allows
> for use of plugins to handle the JavaScript.
> Sadly, the available plugins seem to work best with only the more
> basic JavaScript out their. In my experience JE is super slow
> and the SpiderMonkey plugin is buggy. For more complicated sites
> I have had the best results with WWW::Mechanize::Firefox which, of
> course, requires you to have FireFox up and running with the Mozrepl
> plugin. If you can work with those constraints I would just use that.
>
>
>
Be aware the Google does not like strangers (non-registered)
scraping their screens
--
maus
.
.
...
------------------------------
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 3684
***************************************
