[24118] in Perl-Users-Digest
Perl-Users Digest, Issue: 6312 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Mar 27 21:05:39 2004
Date: Sat, 27 Mar 2004 18: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 Sat, 27 Mar 2004 Volume: 10 Number: 6312
Today's topics:
Re: Choosing Perl/Python for my particular niche <fma@doe.carleton.ca>
Re: Choosing Perl/Python for my particular niche <fma@doe.carleton.ca>
Re: Choosing Perl/Python for my particular niche <Petri_member@newsguy.com>
Combinatorics of dual-language use (was: Choosing Perl/ (Cameron Laird)
Re: Combinatorics of dual-language use <paul@prescod.net>
Re: Filehandles Referenced with a Variable <mikeflan@earthlink.net>
Re: Filehandles Referenced with a Variable <mikeflan@earthlink.net>
Re: Filehandles Referenced with a Variable <uri@stemsystems.com>
life time of $1? <geoffacox@dontspamblueyonder.co.uk>
Re: life time of $1? <tadmc@augustmail.com>
Re: life time of $1? <geoffacox@dontspamblueyonder.co.uk>
Re: Loss of privledges in a perl app <tadmc@augustmail.com>
Re: match pattern with $ failed (nickelstat)
problem/help with using LWP <rbell01824@earthlink.net>
Re: problem/help with using LWP <invalid-email@rochester.rr.com>
Quality control for CPAN? <none@none.com>
Re: SCALAR(0x82dea94) <tadmc@augustmail.com>
Re: Select with named pipes example (John Saalwaechter)
Solved: Does anyone know what this switch does? <vunderink@t-online.de>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 28 Mar 2004 00:28:07 GMT
From: Fred Ma <fma@doe.carleton.ca>
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <40661C14.8365E058@doe.carleton.ca>
Re: Choosing Perl/Python for my particular niche
"Eric @ Zomething" wrote:
>
> Roy Smith wrote:
>
> > For most general purpose tasks, I reach for Python first. But if I needed
> > to provide a quick scripting interface to an existing C library,
>
> I would suggest that one might take an option other than the either/or
> (Perl/Python/____). It sounds like having at least some comfort with Perl is
> important to OP based on relevant code base. However, Python is so simple to
> learn, at least at the beginner/intermediate level, that there is not much
> cost to learning some Python as well.
>
> Personal experience: I struggled to becoming proficient with Perl due to its
> syntax and perhaps my lack of bottomless commitment (knowing Perl would not be
> my bread and butter). Somehow I stumbled upon a little bit of Python and got
> sucked in. Now I am probably more proficient at Perl than I was before I
> started using Python (except for needing to look up Perl syntax from time to
> time) because working with Python took my head out of the syntax and let my
> mind focus on the problem solving... and more importantly, the objective.
>
> Python has me feeling like I can make a program to do _anything_ I want, even
> though I doubt it is any more capable than Perl, etc. It's matter of clarity
> and better being able to see the forest, rather than a whole lot of trees.
>
> This might sound like something less than a firm choice, but perhaps OP might
> decide to start digging into Perl in April, but allow one weekend in that
> month for Python and let things evolve as best suits his situation.
Eric, you voiced exactly the opinion that was forming in my mind upon reading
the responses. There is a complicating factor (actually the most pressing
factor) behind my either/or approach. That is, I must wrap up my thesis very
soon, and what I've proposed is alot more than what there is time for. However,
given the responses, I agree that that most reasonable approach is to adopt one
and keep tabs on the other. Perl seems to be the natural choice for the first,
since I see it in alot of places, meaning I will probably have to poke through
it often. And the ease of Python will make it feasible to keep in touch with
it, if not immediately, then with time.
Aside from hacking other people's Perl code, I've already bloodied my nose on
Perl composition (quite a bit harder than small modifications to other people's
code, I found), so I'm already down that path a bit. I expect to be using this
primarily for "glue" work i.e. to mulch information meant for one utility (e.g.
verilog) so that it can be used for another e.g. verilator, or my own code.
For the computation engine, I will stick with C++ and matlab (for its graphing),
again due to the lack of time to ramp up thoroughly on something else. Also,
despite the availability of Perl code for evolutionary algorithms, I found that
in exploring algorithms, one can very quickly depart from the funcionality
offered by a standard package. Even C/C++ libraries for these algorithms
presume a certain general framework which can impact speed; I didn't use them,
but if I did, I expect I would have diverged from the code base very early.
On the topic of speed, It's surprising to hear that this can be possibly rivaled
by Perl/Python, considering that even my matlab code is about 10x slower than
C++. That's with extensive profiling and round-about coding styles to exploit
vectorization tricks, and no such effort in the C++ code. Some of the
limitations are pretty fundamential e.g. large speed penalties for invoking
nonbuiltin functions. Such limitations discourage clear coding practice e.g.
huge swaths of code to avoid encapsulating some functionality in its own
function. Together with the sometimes roundabout coding style, it can detract
from the matlab's high level ease of programming and clarity, especially
considering that C++ can be brought to a high level with its STL library. And
this speed disparity shows up despite matlab's mission to develop in a way that
rivals 3G languages. Speed considerations aside, however, matlab is infinitely
easier to use and to read. With time, perhaps the limitations will shrink.
This is not to say that Perl/Python will have the same limitations. They are,
however, more general purpose languages, so I expect that speed is less of a
priority than in scientific computing (compared to other important priorities).
Hence, learning curve aside, some time needs to be invested in exploring its
speed in a realistic scientific applications. For me, this is an option for the
more distant future rather than the immediate term. I spent quite alot of time
in this phase with matlab, trying to squeeze out all possible speed before
conceding that some of the limits were fundamental, at least in the current
release.
One thing I learned was that speed characterization was not a simple. Many of
the tasks found in scientific computing are done blistering fast by matlab. It
is not until you put together a larger application when you start running into
the limitations. Aside from the speed penalties of calling nonbuiltins,
roundabout coding style is not such a big deal for small chunk of code. It can
be debilitating when you're trying to wrap your head around something large.
The large chunks of inline code exacerbate this.
A final reason to stick with C++ is the hardware simuation library ("SystemC").
The Perl translator I alluded to in an earlier post translates code in hardware
description language ("verilog") to C++ specifically for use with SystemC (well,
it does more than that, but that's my main use of it). This allows my C++ code
to more directly control the hardware model and its simulation, in contrast to
using a standalone simulator to simulate the original verilog. Depending on the
level of poking and prodding, it can be extremely arduous to go through the API
of the verilog simulator. This is especially true if you intend to change the
hardware models alot between simulations (or do things to achieve the same
effect), and all the more true if the functionality outside of the verilog
simuation is meant to supervise the various simulations instead of being
subordinate to them. An alternative is to have the C++ (or whatever) parent
program generate different verilog code between simulations and invoke the
simulator each time. This would be far too slow.
I realize that my inclination to write my own code sort of contradicts my want
to springboard off of existing Perl code base. I only had a vague idea of the
benefits of this, since I don't actually program in Perl right now. There are
several points I've tried to determine the relevance of. On one hand, I've
looked at and hacked Perl code to get things done, so knowing Perl helps. On
the other hand I need a good way to repackage data for different applications,
in which case I'll compose code from scratch. For this, I would appricate the
lesser pain and greater ease of Python (I imagine). On yet another hand, I use
Perl-based packages like the verilog-to-C++ translator, but I don't expect to
delve into such a complicated package, whose complexity probably lies in more
than just use of the Perl language. Finally, and most vaguest of all, I have
this idea that I might eventually be sharing Perl code, collaborating in its
composition, or revising/maintaining it. If "synergy" in that form is actually
typical in my area of specialization, then of course it would make sense to
start with Perl first, since that is the prevalent language in this area.
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
------------------------------
Date: 28 Mar 2004 00:54:08 GMT
From: Fred Ma <fma@doe.carleton.ca>
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <4066233C.56E5D3DD@doe.carleton.ca>
"Tassilo v. Parseval" wrote:
>
> Also sprach Fred Ma:
>
> > No XML processing or database interaction in what I do.
>
> Who knows, though. The desire to do certain things grows with the skills one
> acquired.
You might be right. Some digital CAD data is stored in XML.
> This is a strong reason to use Perl. While it may not always be desirable to
> toe the line, here it is. The availability of tools that can easily be
> integrated into one's own work will save you a lot of work on the long run. I
> didn't know that Perl was particularly strong in the field of IC design. If
> so, good then.
>
> Apart from this particular case, it's generally a good thing when pre-written
> code exists that can be used. The amount of such code for Perl is immense
> (several thousand libraries) and gathered all in one place (the CPAN) with a
> unified interface to access and install them and a vast infrastructure built
> around it.
>
> I don't know how much or whether at all the situation for Python has
> significantly improved over the recent past. A while ago at least there was no
> such thing.
SNIP
> As with text processing, both Python and Perl offer all the essential things
> needed for that. On a cursory glance, the score of them is tied.
>
> Perl wins when it comes to one-liners and maybe replacing shell scripts. As I
> tend to forget the syntax of bash's scripting language easily, I've replaced
> it entirely with Perl.
>
> Perl's bad reputation for big projects is probably due to the variance of
> those people using Perl. One large group is sys-admins who use Perl in an
> entirely different way as compared to someone building larger systems.
> However, there are enough very large Perl projects that show that it can be
> used for that just as easily (at least as long as one keeps the sys-admins
> away from the source;-).
>
> > I've seen mention of parrot and perl6, which is quite a ways off. I'm not
> > sure how much that should weigh into my decision, since it isn't real yet.
>
> It shouldn't. Perl6 is mostly yet another leap towards fitness for large
> projects. I don't think it will gain much for those more hackish tasks. Also,
> no one quite knows when Perl6 will be due.
Thanks for the commentary on Perl, for clarifying the source of unweldiness in
big Perl projects, as well as its nonuniversality.
Fred
------------------------------
Date: 27 Mar 2004 16:47:09 -0800
From: Petri <Petri_member@newsguy.com>
Subject: Re: Choosing Perl/Python for my particular niche
Message-Id: <c457ad029rc@drn.newsguy.com>
In article <40652B0D.7C313F77@doe.carleton.ca>, Fred Ma says...
> One thing I expect to have to do is to modify design
> files. For example, there is a tool which takes ASCII
> hardware desscription language (HDL) and converts it
> to a C++ (augmented by hardware simulation library).
> The translator is freeware, so has limitations which I
> have to make up for by tweaking the HDL code.
The translator, is it doing the Verilog stuff you mention later in the thread?
Why not check if you can't replace the translator altogether with an existing
Perl module:
http://search.cpan.org/search?query=verilog&mode=all
Well, I know nothing about your problem area, but it's a tip in case you hadn't
thought about checking CPAN.
Petri
------------------------------
Date: Sat, 27 Mar 2004 19:21:01 -0000
From: claird@lairds.com (Cameron Laird)
Subject: Combinatorics of dual-language use (was: Choosing Perl/Python for my particular niche)
Message-Id: <106bl0t31fub51f@corp.supernews.com>
In article <c44ine$ad6$1@nets3.rz.RWTH-Aachen.DE>,
Tassilo v. Parseval <tassilo.parseval@post.rwth-aachen.de> wrote:
.
.
.
>When it comes to embedding C/C++ into Perl, SWIG is the last thing that
>I'd recommend. It may be capable of transforming such a library into a
>Perl module on its own with no user intervention. However, C/C++ doesn't
>map particularly well onto Perl from an interface point-of-view: A 1:1
>translation of a C++ API doesn't look particularly good.
>
>Those things should be done manually. How much work this is depends on
>the library. Some only require a few lines of XS. XS' learning curve is
>admittedly a bit steep. Not because it is difficult in itself but rather
>because the documentation leaves a few things to be desired. There are
>some actions on completing perlxstut.pod on its way right now, though.
>
>There is also Inline::CPP, although I don't think it is as mature as
>Inline::C. And since you have mentioned Tcl, even that can be inlined
>with the help of Inline::Tcl.
.
.
.
As I think about it more, maybe Inline::C (or Tcl's
Critcl, for that matter) *is* something that would
suit the original poster roughly as well as Pyrex.
Incidentally, I've heard that Inline::Tcl might be
an area of renewed interest; it has an inverse in
tclperl.
--
Cameron Laird <claird@phaseit.net>
Business: http://www.Phaseit.net
------------------------------
Date: Sun, 28 Mar 2004 00:53:04 GMT
From: Paul Prescod <paul@prescod.net>
Subject: Re: Combinatorics of dual-language use
Message-Id: <406621F0.3020903@prescod.net>
Cameron Laird wrote:
>...
> .
> .
> .
> As I think about it more, maybe Inline::C (or Tcl's
> Critcl, for that matter) *is* something that would
> suit the original poster roughly as well as Pyrex.
Neither Pyrex nor Inline::C are going to be great for C++. They were
both created by C programmers for C programmers (I'd like to see this
change about Pyrex some day). BOOST::Python, on the other hand, is
probably a good fit.
Paul Prescod
------------------------------
Date: Sat, 27 Mar 2004 19:29:24 GMT
From: Mike Flannigan <mikeflan@earthlink.net>
Subject: Re: Filehandles Referenced with a Variable
Message-Id: <4065D631.959190EB@earthlink.net>
> why did you quote the FAQ here? we all have copies already.
Mainly just to make sure I had found the right one. I guess
I could have just posted the question part.
> MF> I read the IO::Handle documentation and gave it a try. The error
> MF> I get is "Can't call method "fdopen" on an undefined value at
> MF> line 16.
>
> you didn't read it well.
I didn't understand it well - that's for sure.
> look at IO::File for file opening. i said IO::Handle is to get a HANDLE
> not to open a file. i also said it is inherited by other IO:: modules.
>
> MF> I went through perldoc perlopentut twice. It's quite long.
>
> so go over it several more times. look for the parts on lexical file handle.
I suspect you are referring to the Single Argument Open, but I
haven't made that work correctly yet.
This looked good to be, but not to Perl:
use IO::File;
my %fhname;
. . .
foreach $st (@states) {
$fhname{$st} = new IO::File;
$fhname{$st}->open ("> $st");
}
foreach $st (@sttemp) {
print <$fhname{$st}> $line; #THIS LINE
}
I also tried:
foreach $st (@states) {
$fhname{$st} = new IO::File "> $st";
}
foreach $st (@sttemp) {
print $fhname{$st} "$line"; #THIS LINE
}
Both give "String found where operator expected" at THIS LINE.
I have more than 3 hours invested in a problem that I already
have a solution for. Call me stupid, but you must admit I
don't give up easily.
Mike
------------------------------
Date: Sat, 27 Mar 2004 19:46:10 GMT
From: Mike Flannigan <mikeflan@earthlink.net>
Subject: Re: Filehandles Referenced with a Variable
Message-Id: <4065DA1C.4C02A6AC@earthlink.net>
> what does 'It did not work for me at all' mean? that is a useless
> statement. did it cause your computer to burst into flames? did it empty
> your bank account? what didn't work?
Actually, I think it ran but produced no output to the filehandle.
That did not surprise me. Like I said, the programming
structure made no sense to me either.
I must be misinterpretting what you guys are trying to tell me,
because you are all saying the same thing, but I can't get
it to work. Sorry.
> MF> Perhaps I was wrong about me being promoted from
> MF> newbie to novice :-)
>
> yep.
>
> it is SO easy. i don't know why you seem to have this mental block on
> it.
>
> a NAMED handle is a symbolic reference so it doesn't work under
> strict. creating anonymous handle references is EASY.
>
> MF> Thanks for the help. I really appreciate it.
>
> but you aren't listening to the advice. you need a FRESH DYNAMICALLY
> created ANONYMOUS HANDLE for each state STORED in a HASH indexed by the
> STATE name. what more do you need to be told?
>
It may be easy for you, but believe me, it's not easy for me.
I'm looking at page 367 of my Cookbook right now. It supplies
a table of named (referenced) variables and their anonymous
counterparts. Yet despite all I know about Perl, it makes no
sense to me at all.
Give me a few weeks for months and I will eventually figure
it out.
I think the only part of what you say that I don't understand
is: ANONYMOUS HANDLE. I'm still looking.
Mike
------------------------------
Date: Sat, 27 Mar 2004 19:46:15 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: Filehandles Referenced with a Variable
Message-Id: <x7vfkqul89.fsf@mail.sysarch.com>
>>>>> "MF" == Mike Flannigan <mikeflan@earthlink.net> writes:
MF> This looked good to be, but not to Perl:
MF> use IO::File;
MF> my %fhname;
MF> . . .
MF> foreach $st (@states) {
MF> $fhname{$st} = new IO::File;
MF> $fhname{$st}->open ("> $st");
MF> }
you seem to be guessing. that is not programming. io::file does the OPEN
for you and returns a file handle. the synopsis has examples. whr
MF> foreach $st (@sttemp) {
MF> print <$fhname{$st}> $line; #THIS LINE
MF> }
keep guessing away. did you think about checking the result of the open
and maybe it FAILED?
MF> I also tried:
MF> foreach $st (@states) {
MF> $fhname{$st} = new IO::File "> $st";
MF> }
MF> foreach $st (@sttemp) {
MF> print $fhname{$st} "$line"; #THIS LINE
MF> }
MF> Both give "String found where operator expected" at THIS LINE.
read up on print.
print FILEHANDLE LIST
print LIST
print Prints a string or a list of strings. Returns true
if successful. FILEHANDLE may be a scalar variable
name, in which case the variable contains the name
of or a reference to the filehandle,
$fhname{$st} is NOT a variable, it is an expression.
Note that if you're storing FILEHANDLES in an array
or other expression, you will have to use a block
returning its value instead:
print { $files[$i] } "stuff\n";
print { $OK ? STDOUT : STDERR } "stuff\n";
see that? it is all there in the docs.
MF> I have more than 3 hours invested in a problem that I already
MF> have a solution for. Call me stupid, but you must admit I
MF> don't give up easily.
no you don't. but being dogged is one thing. guessing for hours is
another.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Sat, 27 Mar 2004 19:05:20 GMT
From: Geoff Cox <geoffacox@dontspamblueyonder.co.uk>
Subject: life time of $1?
Message-Id: <bkjb60pifupb8va9lkv6gq4nevcfi93q11@4ax.com>
Hello
I am confused re the $1 issue below
say I have
&fred($1)
sub fred {
my $data = $1
my $line =~ /.*jim(.).*?fred(.)
}
can I use $1 (and $2) again?
Cheers
Geoff
------------------------------
Date: Sat, 27 Mar 2004 14:13:29 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: life time of $1?
Message-Id: <slrnc6bo39.tia.tadmc@magna.augustmail.com>
Geoff Cox <geoffacox@dontspamblueyonder.co.uk> wrote:
> I am confused re the $1 issue below
Have you read what the docs have to say about $1 et. al. ?
The numbered variables ($1, $2, $3, etc.) and the related punctuation
set ($+, $&, $`, $', and $^N) are all dynamically scoped
until the end of the enclosing block or until the next successful
match, whichever comes first. (See L<perlsyn/"Compound Statements">.)
> say I have
>
> &fred($1)
You shouldn't use the ampersand on function calls unless you know
what it does, and what it does is what you want (it usually is
not what you want).
> sub fred {
>
> my $data = $1
>
> my $line =~ /.*jim(.).*?fred(.)
^^^ huh?
Do not re-type Perl code
Use copy/paste or your editor's "import" function rather than
attempting to type in your code. If you make a typo you will get
followups about your typos instead of about the question you are
trying to get answered.
Have you seen the Posting Guidelines that are posted here frequently?
(I have asked you this before.)
> }
>
> can I use $1 (and $2) again?
What happened when you tried it?
You should never use the dollar-digit variables unless you
have first ensured that the match _succeeded_. (I have
pointed this out to you before.)
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sat, 27 Mar 2004 21:57:38 GMT
From: Geoff Cox <geoffacox@dontspamblueyonder.co.uk>
Subject: Re: life time of $1?
Message-Id: <91ub609j3m3nkg6mn8ho7kkf3vdmle153f@4ax.com>
On Sat, 27 Mar 2004 14:13:29 -0600, Tad McClellan
<tadmc@augustmail.com> wrote:
>Geoff Cox <geoffacox@dontspamblueyonder.co.uk> wrote:
>
>> I am confused re the $1 issue below
>
>
>Have you read what the docs have to say about $1 et. al. ?
Tad,
thanks for your patience - I accept all you say and will take more
care!
geoff
>
> The numbered variables ($1, $2, $3, etc.) and the related punctuation
> set ($+, $&, $`, $', and $^N) are all dynamically scoped
> until the end of the enclosing block or until the next successful
> match, whichever comes first. (See L<perlsyn/"Compound Statements">.)
>
>
>> say I have
>>
>> &fred($1)
>
>
>You shouldn't use the ampersand on function calls unless you know
>what it does, and what it does is what you want (it usually is
>not what you want).
>
>
>> sub fred {
>>
>> my $data = $1
>>
>> my $line =~ /.*jim(.).*?fred(.)
> ^^^ huh?
>
>
> Do not re-type Perl code
> Use copy/paste or your editor's "import" function rather than
> attempting to type in your code. If you make a typo you will get
> followups about your typos instead of about the question you are
> trying to get answered.
>
>
>Have you seen the Posting Guidelines that are posted here frequently?
>
>(I have asked you this before.)
>
>
>> }
>>
>> can I use $1 (and $2) again?
>
>
>What happened when you tried it?
>
>
>You should never use the dollar-digit variables unless you
>have first ensured that the match _succeeded_. (I have
>pointed this out to you before.)
------------------------------
Date: Sat, 27 Mar 2004 14:03:56 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Loss of privledges in a perl app
Message-Id: <slrnc6bnhc.tia.tadmc@magna.augustmail.com>
perl coder <perlcdr@mail.rumania> wrote:
> # clean up environment
> foreach (keys %ENV) { delete $ENV{$_} }
> $ENV{'PATH'} = '/bin:/usr/bin';
# a cleaner way to clean up environment
%ENV = qw( PATH /bin:/usr/bin );
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 27 Mar 2004 13:40:41 -0800
From: nickelstat@sbcglobal.net (nickelstat)
Subject: Re: match pattern with $ failed
Message-Id: <21160ba4.0403271340.60de05bc@posting.google.com>
Thank you.
Both of your suggestions work.
I guess I was asking the wrong question.
I wanted the string $s2 not to be expanded. I should have asked that
the $ sign not to be interpreted as an end of line.
Again thanks a million
------------------------------
Date: Sat, 27 Mar 2004 23:43:29 GMT
From: Richard Bell <rbell01824@earthlink.net>
Subject: problem/help with using LWP
Message-Id: <3r3c60ts5ulimmjq19prdpah1vf17osuru@4ax.com>
I'm trying to use LWP to scrape some data from a web site fronting a
database of some sort (don't really know/care what). To use the site
from a browser you enter (at some point you get a session cookie, not
really sure when) and proceed to navigate through many pages (they are
all frames with the top part having various navigation widgets and the
bottom part having both visible and hidden forms - the hidden forms
are used to hold data being entered through the process). As each
page is navigated, the site sends various cookies (many) and refreshes
the hidden form. When all is said and done a form is POSTed to
retrieve the data (data is actually a .csv file, but that doesn't
matter). The navigation to the final POST always creates the same
hidden form data. I've used wsp and template.pl to figure out what is
happening and build a perl app that works, at least until the session
cookie expires!! That's the rub.
How do I find out which of the MANY cookies is the ONE that I must
refresh?
How do I refresh it?
Thanks for any help.
R
------------------------------
Date: Sun, 28 Mar 2004 01:46:22 GMT
From: Bob Walton <invalid-email@rochester.rr.com>
Subject: Re: problem/help with using LWP
Message-Id: <40662E44.1020805@rochester.rr.com>
Richard Bell wrote:
> I'm trying to use LWP to scrape some data from a web site fronting a
Then you should consider using a web scaping proxy:
http://www.research.att.com/~hpk/wsp/
...
> R
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
------------------------------
Date: Sat, 27 Mar 2004 23:28:53 +0000
From: Garry Heaton <none@none.com>
Subject: Quality control for CPAN?
Message-Id: <3ao9c.27349$Y%6.3195068@wards.force9.net>
I've had problems getting some CPAN modules to compile in the past. Is there
any way of deciding which CPAN modules are more or less reliable other than
trial 'n error?
Garry
------------------------------
Date: Sat, 27 Mar 2004 14:14:53 -0600
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: SCALAR(0x82dea94)
Message-Id: <slrnc6bo5t.tia.tadmc@magna.augustmail.com>
Todd Anderson <todd@asgweb.net> wrote:
> i have not had one minute of formal programming training.
We could tell.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: 27 Mar 2004 11:55:31 -0800
From: saalwaechter_jw@hotmail.com (John Saalwaechter)
Subject: Re: Select with named pipes example
Message-Id: <154bae9.0403271155.6ce70689@posting.google.com>
To get a little more careful with buffered/unbuffered reading,
here is a revision that uses sysread to explicitly drain the fifo
whenever it contains data.
#!/usr/bin/perl -Tw
#
# Example of using a named pipe and 4-way signal()
# to both manage a periodic task and an asynchronous
# task.
#
use strict;
# Parameters
my $interval=10; # seconds
my $signal_fifo="/tmp/signalfifo"; # create with "mkfifo /path/to/fifo"
# Verify the named pipe
if (!(-p $signal_fifo && -w _ && -r _))
{
print STDERR "Problem with fifo $signal_fifo!\n";
exit(1);
}
# Open the fifo read/write, not just read. This is necessary because
# of the POSIX rules about using select() on named pipes when no writers
# are present.
open(FIFOFH,"+<",$signal_fifo) || die $!;
# Now go into a select()-loop on the fifo.
my $rin='';
my $rout='';
vec($rin,fileno(FIFOFH),1)=1;
while(1)
{
my $nfound=select($rout=$rin,undef,undef,$interval);
# We got to this point because the blocking select()
# returned. It happened because 1) data came into the
# fifo, or 2) the timeout occurred.
print "===== select() returned at ",scalar(localtime),"\n";
if($nfound) # data is in the fifo
{
# Completely drain the fifo, since we don't really
# care what the message is -- only that it exists.
print "fifo contains this data:\n";
my $fifodata;
while(select($rout=$rin,undef,undef,0)) # non-blocking select
{
sysread FIFOFH,$fifodata,1024;
print $fifodata;
}
}
# For safety, just go ahead and perform the periodic and the
# async task any time we get here. A particular application
# may want to alter this strategy.
periodic_task();
async_task();
}
# Infinite loop above... we'll never get here.
# Something that needs to be done at least every n minutes
sub periodic_task
{
print "Periodic task...\n";
return;
}
# Something to do only when signalled
sub async_task
{
print "Asynchronous task...\n";
return;
}
__END__
------------------------------
Date: Sat, 27 Mar 2004 21:15:51 +0100
From: Rob Vunderink <vunderink@t-online.de>
Subject: Solved: Does anyone know what this switch does?
Message-Id: <c44ndn$fis$01$3@news.t-online.com>
I've solved it: it's an upload problem that causes corrupt line endings
that some servers pay attention to, while others don't. The solution is
to upload an empty cgi file, write a small script inside it online and
then, after chmodding, check it. If it works, replace the main body of
the cgi text by the wanted script leaving the shebang line and the next
line intact. It worked.
On 2004-03-27 16:31:15 +0100, Rob Vunderink <vunderink@t-online.de> said:
> Hi,
>
> I have a question. It is related to the following situation.
>
> Check out this url:
> http://www.opstartpagina.nl/cgi-bin/ipadres.cgi
>
> It works.
>
> Now check out this url:
> http://angel.regioportals.nl/gelderlander/cgi-bin/ipadres.cgi
>
> It does not work, although the scripts are the same in both cases:
>
> = - = - = - = - = - = - = - = -
> #!/usr/bin/perl
>
> print "Content-type: text/html\n\n";
> print "Uw IP-adres is: $ENV{REMOTE_ADDR}";
> = - = - = - = - = - = - = - = -
>
> Now check out this url:
> http://angel.regioportals.nl/gelderlander/cgi-bin/ipadres2.cgi
>
> It works. The script is:
>
> = - = - = - = - = - = - = - = -
> #!/usr/bin/perl --
>
> print "Content-type: text/html\n\n";
> print "Uw IP-adres is: $ENV{REMOTE_ADDR}";
> = - = - = - = - = - = - = - = -
>
> Her comes the question.
> The difference is the " --" on the shebang line. What does this switch
> do? Why does it make a difference?
>
> Thanks if anybody knows the answer.
> Rob Vunderink
------------------------------
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 6312
***************************************
