[22457] in Perl-Users-Digest
Perl-Users Digest, Issue: 4678 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Mar 7 00:05:49 2003
Date: Thu, 6 Mar 2003 21:05:08 -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 Thu, 6 Mar 2003 Volume: 10 Number: 4678
Today's topics:
Auto save an image everyday (gonky)
Re: Auto save an image everyday <tony_curtis32@yahoo.com>
Re: Auto save an image everyday <alex@alexbanks.com>
Re: Auto save an image everyday <jurgenex@hotmail.com>
Desktop rotator <black_universe@msn.com>
Re: dynamically define constants <goldbb2@earthlink.net>
Re: dynamically define constants <REMOVEsdnCAPS@comcast.net>
Re: dynamically define constants <wksmith@optonline.net>
Re: I want to know the line n umber of the error ! <flavell@mail.cern.ch>
Re: I want to know the line n umber of the error ! <jurgenex@hotmail.com>
Re: I want to know the line n umber of the error ! <noreply@gunnar.cc>
Re: I want to know the line n umber of the error ! <tore@aursand.no>
Re: I want to know the line n umber of the error ! <tore@aursand.no>
Re: I want to know the line n umber of the error ! <tore@aursand.no>
Re: I want to know the line n umber of the error ! <noreply@gunnar.cc>
Re: I want to know the line n umber of the error ! <flavell@mail.cern.ch>
Re: Lightweight CGI module? <tore@aursand.no>
Re: Lightweight CGI module? <goldbb2@earthlink.net>
Re: New module proposed: Class::Accessor::NoviceArray (Ronald Schmidt)
Non-fatal error, "script not found or unable to stat" (Mike)
Re: perlcc error (cl and link) (Bryan Castillo)
Re: printing hash values <spamtrap@nowhere.com>
Put perl in old page (distrex)
Re: Put perl in old page (Walter Roberson)
question about "new" in a module <spamtrap@nowhere.com>
Re: Question about Forking & Win32 <goldbb2@earthlink.net>
Re: Regular Expressions <abigail@abigail.nl>
Re: Substitution and regex question <tore@aursand.no>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: 6 Mar 2003 17:25:12 -0800
From: gonkylime@yahoo.co.uk (gonky)
Subject: Auto save an image everyday
Message-Id: <d996e8b3.0303061725.3a8d9b0e@posting.google.com>
I want to know how i can auto schedule a perl script to run at a
certain time daily.
I would like to save a pie chart of the information automatically
everyday.. Is that possible??
------------------------------
Date: Thu, 06 Mar 2003 19:34:38 -0600
From: Tony Curtis <tony_curtis32@yahoo.com>
Subject: Re: Auto save an image everyday
Message-Id: <87smu0c635.fsf@limey.hpcc.uh.edu>
>> On 6 Mar 2003 17:25:12 -0800,
>> gonkylime@yahoo.co.uk (gonky) said:
> I want to know how i can auto schedule a perl script to
> run at a certain time daily.
That's an issue for your OS, not perl. (Under UNIX or
feel-a-likes, this would be cron.)
> I would like to save a pie chart of the information
> automatically everyday.. Is that possible??
Yes. There are plenty of "chart" modules for such things.
http://search.cpan.org/
(or "ppm" if you're Windows-bound)
hth
t
------------------------------
Date: Fri, 7 Mar 2003 01:32:43 -0000
From: "Alex Banks" <alex@alexbanks.com>
Subject: Re: Auto save an image everyday
Message-Id: <3e67f6be$0$234$cc9e4d1f@news.dial.pipex.com>
"gonky" <gonkylime@yahoo.co.uk> wrote in message
news:d996e8b3.0303061725.3a8d9b0e@posting.google.com...
> I want to know how i can auto schedule a perl script to run at a
> certain time daily.
'at' jobs on nt (try help at) or cronjobs on unix (man crontab).
these are timed jobs that you can point at your script.
Alex
------------------------------
Date: Fri, 07 Mar 2003 01:40:59 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: Auto save an image everyday
Message-Id: <LMS9a.39286$V42.29896@nwrddc03.gnilink.net>
gonky wrote:
> I want to know how i can auto schedule a perl script to run at a
> certain time daily.
Depends on your OS.
On Unix use cron, on Windows use at, on Mac I've not idea.
jue
------------------------------
Date: Fri, 07 Mar 2003 01:01:47 GMT
From: "Dl" <black_universe@msn.com>
Subject: Desktop rotator
Message-Id: <%bS9a.158532$na.2664510@news2.calgary.shaw.ca>
I would like to make a desktop changer that changes every week. I have perl
experience but not in a win32 environment. Any suggestions to code or faq's
or tutorials would be appreciated. Thanks.
-D
------------------------------
Date: Thu, 06 Mar 2003 20:28:05 -0500
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: dynamically define constants
Message-Id: <3E67F5A5.78257882@earthlink.net>
Nan wrote:
>
> All-
>
> I need to read a data file containing "event numbers and event names
> and build a list of constants dynamically in my perl program.
[snip]
Two things -- first, it needs to be in a BEGIN block to be treated as a
constant later on; second, if you're defining constants dynamically,
you're probably better off without using the 'constant' pragma.
#!/usr/bin/perl -w
use strict;
use warnings;
BEGIN {
my $eventName = "FILE_READ_ERR";
no strict 'refs';
*$eventName = sub () { 1000 };
}
print FILE_READ_ERR;
__END__
PS: Leaving out 'strict' and 'warnings' will result in much less help
from perl and from this newsgroup.
--
$;=qq qJ,krleahciPhueerarsintoitq;sub __{0 &&
my$__;s ee substr$;,$,&&++$__%$,--,1,qq;;;ee;
$__>2&&&__}$,=22+$;=~y yiy y;__ while$;;print
------------------------------
Date: Thu, 06 Mar 2003 21:33:17 -0600
From: "Eric J. Roode" <REMOVEsdnCAPS@comcast.net>
Subject: Re: dynamically define constants
Message-Id: <Xns9336E575DBB3Asdn.comcast@216.166.71.239>
-----BEGIN xxx SIGNED MESSAGE-----
Hash: SHA1
nandagopalj@hotmail.com (Nan) wrote in
news:8193246.0303061358.18a08abc@posting.google.com:
> All-
>
> I need to read a data file containing "event numbers and event
names
> and build a list of constants dynamically in my perl program.
>
> This following does not work (no surprise):
> use constant "$constant_var_name" = 1000;
> Is there any other way I can get this to work ?
You could try my Readonly.pm module, available on CPAN.
- --
Eric
print scalar reverse sort qw p ekca lre reh
ts uJ p, $/.r, map $_.$", qw e p h tona e;
-----BEGIN xxx SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32) - WinPT 0.5.13
iD8DBQE+aBL/Y96i4h5M0egRAsuMAJ9IviEQ78nNFfo4glCPYLdSPbb2RgCg+x4L
KDASpGqDJgeRnJwNNuX3Fs0=
=LxZj
-----END PGP SIGNATURE-----
------------------------------
Date: Fri, 07 Mar 2003 04:44:32 GMT
From: "Bill Smith" <wksmith@optonline.net>
Subject: Re: dynamically define constants
Message-Id: <QsV9a.35009$gf7.7205670@news4.srv.hcvlny.cv.net>
"Nan" <nandagopalj@hotmail.com> wrote in message
news:8193246.0303061358.18a08abc@posting.google.com...
> All-
>
> I need to read a data file containing "event numbers and event names
> and build a list of constants dynamically in my perl program.
>
> This following does not work (no surprise):
> use constant "$constant_var_name" = 1000;
>
> --snip--
Refer to perldoc -q "variable name" for information on how to put a
variable name in another variable, and why this is a bad idea.
Bill
------------------------------
Date: Thu, 6 Mar 2003 23:14:33 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: I want to know the line n umber of the error !
Message-Id: <Pine.LNX.4.53.0303062257480.6225@lxplus072.cern.ch>
On Thu, Mar 6, Gunnar Hjalmarsson inscribed on the eternal scroll:
> You know what, Eric? I'm convinced that the vast majority of those who
> take every chance to praise CGI.pm previously reinvented the wheel, over
> and over again. They did it until they had learned all the stuff you are
> mentioning, among other things.
No argument with that. But what message do you draw from that lesson?
[...]
> I have
> never regretted that wrote it without using either CGI.pm or cgi-lib.pl,
> since it forced me to learn a lot more about CGI than else would have
> been the case. That knowledge has been invaluable when providing support
> to the users of my application, who typically know very little about
> both Perl and CGI.
Well, speaking for myself, I have never regretted playing around with
coding CGI stuff "by hand" and learning in and out how it works. But
although that found its way into some early scripts of mine, I soon
realised that I ought to consider that stuff more as lab experiments.
It hit me that each of those hand implementations was different, and
incomplete, and hard to debug, and hard to extend, and often
differently-buggy, and I realised that writing production code is very
different from a lab experiment. Especially in a situation where you
are, in effect, writing an extension to a web server, and putting it
at risk from whatever the worst of the Internet can throw at it.
That's where I started recommending CGI.pm for production work. No
reason not to go back to hand coding when there are lab experiments to
be done, e.g to challenge the specifications at the edges and
understand what goes wrong: but not for production work.
Last point: if a bug is found, or a new exploit that hadn't been
thought of before, then a corrected version of CGI.pm is slotted in
and all the scripts which use it get the benefit. Compare that with
having to ferret through each hand-coded and slightly-different chunk
of inline code in the CGI area.
cheers
------------------------------
Date: Thu, 06 Mar 2003 23:30:31 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: I want to know the line n umber of the error !
Message-Id: <rSQ9a.29216$ES3.10156@nwrddc04.gnilink.net>
Eric Osman wrote:
> Someone asked why I don't debug my perl script locally before putting
> it on RCN's server.
>
> Well, right now, the perl script depends on a "method = post"
> directive in the html code to send the script the stuff it expects.
So? CGI.pm provides methods to pass that kind of data as command line
arguments.
Anyway, AFAIR we were talking about syntax errors. You don't even need to
execute the program to find syntax errors. Just run it through perl using
"perl -c .....". Further details see "perldoc perlrun".
Only when you want to test the functionality, then you need to provide test
data.
> So for one thing, to test the script locally, I'd need to figure out
> how to "fake up" some posted data.
True. You need to know what input your program expects and can handle.
But that has nothing to do with any client or server or browser or whatever.
> I could avoid having to fake up posted data if I ran an actual web
> server on my local computer, which I don't currently.
Well, you could install a local web server if you would like to.
Of course that is not necessary at all to debug a Perl CGI program.
> Thirdly, I'm not even currently running a perl compiler/interpreter
> on my local machine.
Well, that of course is a major problem. How do you even access the man
pages without a local Perl installation? That's like fighting with both
hands tied behind your back.
> (perhaps you can suggest which ones are
> preferrable to run ? I'm on xp right now ).
Doesn't matter, there is only one Perl. Ideally you may want to use the same
version as run on your web server, otherwise you may run into problems with
incompatibilities between e.g Perl5 and Perl6.
If you are some sort of MS Windows then you may be interested in
ActiveState's Perl package.
jue
------------------------------
Date: Fri, 07 Mar 2003 01:01:24 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: I want to know the line n umber of the error !
Message-Id: <b48nfp$1t7fg2$1@ID-184292.news.dfncis.de>
Alan J. Flavell wrote:
> On Thu, Mar 6, Gunnar Hjalmarsson inscribed on the eternal scroll:
>>You know what, Eric? I'm convinced that the vast majority of those who
>>take every chance to praise CGI.pm previously reinvented the wheel, over
>>and over again. They did it until they had learned all the stuff you are
>>mentioning, among other things.
>
> No argument with that. But what message do you draw from that lesson?
Well... The readers of this and similar groups are at very different
levels of experience. Compared to you, and many of the other regulars
here, I'm doubtlessly a beginner.
My message may be: *Please* let us beginners reinvent a few wheels,
without being regarded as 'morons'. By doing so, we learn stuff that may
prove to be very useful knowledge later on.
I don't know if you have any kids, Alan. I have not, but if I had, I
would *not* tell them that they don't need to learn how much is 7 x 8,
since there are calculators and computers that can solve that problem
for them. ;-)
Note that I'm *not* arguing against using CGI.pm, or any other module.
The rational for using modules is obvious.
But quite a few topics in this group are questions from people at a
relative beginner level, who, while struggling with improving our
programming skill, have got stuck with some problem. Advises like: "use
[module_x]", without addressing the actual problem, are not necessarily
the best help we can get.
I do agree that people should be required to give the docs and FAQ a try
before posting here, but I do not support the thought that each
programming problem, that has been dealt with in a module, is not worth
discussing.
> Well, speaking for myself, I have never regretted playing around with
> coding CGI stuff "by hand" and learning in and out how it works. But
> although that found its way into some early scripts of mine, I soon
> realised that I ought to consider that stuff more as lab experiments.
>
> It hit me that each of those hand implementations was different, and
> incomplete, and hard to debug, and hard to extend, and often
> differently-buggy, and I realised that writing production code is very
> different from a lab experiment. Especially in a situation where you
> are, in effect, writing an extension to a web server, and putting it
> at risk from whatever the worst of the Internet can throw at it.
>
> That's where I started recommending CGI.pm for production work. No
> reason not to go back to hand coding when there are lab experiments to
> be done, e.g to challenge the specifications at the edges and
> understand what goes wrong: but not for production work.
>
> Last point: if a bug is found, or a new exploit that hadn't been
> thought of before, then a corrected version of CGI.pm is slotted in
> and all the scripts which use it get the benefit. Compare that with
> having to ferret through each hand-coded and slightly-different chunk
> of inline code in the CGI area.
All that makes sense to me, too. :)
/ Gunnar
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Fri, 07 Mar 2003 01:11:24 +0100
From: "Tore Aursand" <tore@aursand.no>
Subject: Re: I want to know the line n umber of the error !
Message-Id: <pan.2003.03.06.23.42.22.161894@aursand.no>
On Thu, 06 Mar 2003 15:26:47 -0500, Eric Osman wrote:
>> #!/usr/bin/perl
>> #
>> use strict;
>> use warnings;
> Well, I tested it and those two lines, the one with "strict" and the one
> with "warnings", give problems.
That's why you took _two_ lines out of _my whole_ script and inserted them
at the beginning of your poorly written script.
In this case, that's suicide; 'use strict' and 'use warnings' required you
to write _clean_ code. Example:
> @dcLines = split (/\r\n/ , $dcWhole);
Where do you specify '@dcLines'? Answer: Nowhere. You have to specify
_every_ variable in your script with 'my' when using 'strict'.
> $outName = "out.txt";
Same with this. You _must_ be able to debug your scripts properly, and
that's why we've been telling you to install Apache + Perl on your local
computer.
Run this script from the command line, and Perl will instantly tell you
what's wrong. If you add 'use diagnostics' to your script, Perl will even
tell you in plain English what's wrong, and what you ought to do. :)
> Maybe once I have apache server running locally the reason for these
> errors will become apparent.
No shit, Sherlock?!
--
Tore Aursand <tore@aursand.no>
------------------------------
Date: Fri, 07 Mar 2003 01:11:24 +0100
From: "Tore Aursand" <tore@aursand.no>
Subject: Re: I want to know the line n umber of the error !
Message-Id: <pan.2003.03.06.23.36.17.323078@aursand.no>
On Thu, 06 Mar 2003 20:57:51 +0100, Gunnar Hjalmarsson wrote:
>> Do NOT attempt to parse CGI input yourself. Only geniuses and morons
>> do that -- and the geniuses don't do that unless they have a VERY good
>> reason.
> You know what, Eric? I'm convinced that the vast majority of those who
> take every chance to praise CGI.pm previously reinvented the wheel, over
> and over again.
That's not relevant in the cases where we are "bashing" people using their
own way of retrieving the CGI data.
I think it's a good time that people try out stuff without using the
modules out there (which are there to help other people). But! You
_must_ consider the following:
a) Most probably, any module on CPAN is far better than any
solution you come up with. Not always of course, but in
the majority of cases.
b) Whenever you feel you're done experimenting on your own,
go back to a well-known module which does the job for you.
Running into trouble and posting about it here, gives us
no other option than to recommend one of the CPAN modules,
_even_ if you're trying to learn something new.
I am one of those who always recommends existing modules, even if it's
"only a script which is supposed to be run twice and then ditched", and "I
wrote the HTML code myself, so I don't need NASA approved modules to parse
it".
Funny as it is, though; I myself requested a lightweight CGI replacement
earlier today. *g*
--
Tore Aursand <tore@aursand.no>
------------------------------
Date: Fri, 07 Mar 2003 01:24:24 +0100
From: "Tore Aursand" <tore@aursand.no>
Subject: Re: I want to know the line n umber of the error !
Message-Id: <pan.2003.03.07.00.18.10.58406@aursand.no>
On Fri, 07 Mar 2003 01:01:24 +0100, Gunnar Hjalmarsson wrote:
> My message may be: *Please* let us beginners reinvent a few wheels,
> without being regarded as 'morons'. By doing so, we learn stuff that may
> prove to be very useful knowledge later on.
By all means, reinvent the carbon molecule if you want to. But don't
expect anything else than "it's already invented" when you post to perl
newsgroups.
Why should _we_ be bothered with people whose problems occur because of
their need to reinvent the wheel every time? Isn't in it's place to tell
those people _how_ one should do things The Right Way (tm)?
> But quite a few topics in this group are questions from people at a
> relative beginner level, who, while struggling with improving our
> programming skill, have got stuck with some problem. Advises like: "use
> [module_x]", without addressing the actual problem, are not necessarily
> the best help we can get.
I think newsgroups are like this one is for _helping_ people. Of course
you are helping them if you yourself invents the wheel for them.
But - in the long run - it won't help much. Let's take the CGI example;
The _right_ thing to do is to recommend using CGI.pm to people. In turn,
the right thing for _them_ to do - if they want to learn those nasty query
parsing tricks, is to explore CGI.pm for themselves (ie. look at the
source code).
Discussing existing solutions (ie. code and/or algorithms) is all nice,
but you can't ask for help in this newsgroup is you want an answer to a
questions that is already answered (and floats around on your hard disk as
plain text in something called a Perl module).
--
Tore Aursand <tore@aursand.no>
------------------------------
Date: Fri, 07 Mar 2003 02:13:37 +0100
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: I want to know the line n umber of the error !
Message-Id: <b48rn6$1st0c9$1@ID-184292.news.dfncis.de>
Tore Aursand wrote:
> Why should _we_ be bothered with people whose problems occur because of
> their need to reinvent the wheel every time? Isn't in it's place to tell
> those people _how_ one should do things The Right Way (tm)?
TIMTOWTDI. But, yes, people should indeed be *recommended* to make use
of applicable modules. They'd better not be told that they are stupid if
they don't...
> I think it's a good time that people try out stuff without using the
> modules out there (which are there to help other people). But! You
> _must_ consider the following:
>
> a) Most probably, any module on CPAN is far better than any
> solution you come up with. Not always of course, but in
> the majority of cases.
>
> b) Whenever you feel you're done experimenting on your own,
> go back to a well-known module which does the job for you.
> Running into trouble and posting about it here, gives us
> no other option than to recommend one of the CPAN modules,
> _even_ if you're trying to learn something new.
I understand that we wheel-reinventors may be trying the patience of the
most experienced regulars here. One approach could then be to let the
less experienced help each other with 'old' problems, without bashing us. :)
> Funny as it is, though; I myself requested a lightweight CGI replacement
> earlier today. *g*
I couldn't help noticing that. :)
/ Gunnar
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Fri, 7 Mar 2003 03:11:27 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: I want to know the line n umber of the error !
Message-Id: <Pine.LNX.4.53.0303070303241.15463@lxplus094.cern.ch>
On Fri, Mar 7, Gunnar Hjalmarsson inscribed on the eternal scroll:
> My message may be: *Please* let us beginners reinvent a few wheels,
> without being regarded as 'morons'. By doing so, we learn stuff that may
> prove to be very useful knowledge later on.
Point taken, but I think the problem is that we don't know how to
distinguish between attempted production solutions, and lab-bench
student exercises, unless the questioner tells us clearly what they
have in mind.
It's not as if the people who rushed their lab-bench exercises into
widespread production use are all called "Matt", after all, or can be
recognised in any other obvious way. We need some way to recognise
them, and as most of the regulars around here are real practitioners
(I don't really count myself among them, despite best efforts), they
tend to assume that any question is intended for production deployment
unless otherwise stated, and so they respond accordingly.
cheers
------------------------------
Date: Fri, 07 Mar 2003 01:11:23 +0100
From: "Tore Aursand" <tore@aursand.no>
Subject: Re: Lightweight CGI module?
Message-Id: <pan.2003.03.06.23.56.40.898164@aursand.no>
On Thu, 06 Mar 2003 14:24:28 -0500, Ben Kennedy wrote:
>> I think you're missing my main point here; I'm only talking about the
>> CGI module here; "All" the other modules I can somehow cache in
>> memory, so I don't care about them.
> What makes you think you can cache everything but CGI.pm?
Well. Almost everything. Of course, something is _impossible_ to parse,
due to the course of the application, but most of it is cached. The most
important things, if I remember correctly, must be:
o Database connection(s)
o Templates
o Configuration
o Miscellaneous modules (string handling, nifty methods etc)
These are put in memory as long as the underlying software supports it. I
have only tested it on these combinations so far:
o Linux + Apache + mod_perl
o Win32 + Apache + mod_perl (IndigoPerl)
o Win32 + IIS + PerlEx (ActiveState)
Hmm. These combinations will cover most of the installations. I'm eager
to try out Zeus, but haven't got that far yet.
The problem with the CGI module, however, is that I can't cache it once
it's been created. If so, how am I able to read the contents of the query
for each request?
A plain test script which just loads all the required modules (and does
the required initialisation stuff like checking for an autenticated user,
connecting to the database etc) runs approx 1-1.2 times per second on a
"standard Linux with Apache installed". I haven't bothered trying to tune
the Apache configuration yet.
After caching the modules, I easily can handle almost 200 requests per
second. Expect that number to drop when my script actually _does_
something useful. :)
> Again, either you have a misunderstanding of how CGI (the interface)
> works, or we are missing something about your implementation.
> Furthermore, even a persistently loaded (cached) CGI.pm works just fine
> - simply create a new query object.
Ah. I might have been trying to fool everyone here. I suddenly became
aware that I might have been saying 'loading' when I actually mean
'creating a new instance of'.
The time it takes CGI.pm to spit out an instance of itself is the same, I
guess, wether the module itself is preloaded or not. (And remember that I
can't rely on the compile option here).
> Just because something is slow or could possibly made faster doesn't
> mean its a bottleneck.
I know. Bad use of the bottleneck from me. I _know_ that CGI.pm is
pretty bloated, and I _know_ that it'll give me better overall performance
if I had a smaller/lighter one.
And - please allow me to repeat myself: This is _not_ important for me,
as my application seems to be fast enough. But consider this as a lab
experiment or something, as my application will be even faster with a CGI
module that doesn't turn heaven into hell each time it's instanciated. ;)
--
Tore Aursand <tore@aursand.no>
------------------------------
Date: Thu, 06 Mar 2003 20:29:50 -0500
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Lightweight CGI module?
Message-Id: <3E67F60E.AEB907E@earthlink.net>
Tore Aursand wrote:
>
> On Thu, 06 Mar 2003 14:24:28 -0500, Ben Kennedy wrote:
> >> I think you're missing my main point here; I'm only talking about
> >> the CGI module here; "All" the other modules I can somehow cache
> >> in memory, so I don't care about them.
>
> > What makes you think you can cache everything but CGI.pm?
>
> Well. Almost everything. Of course, something is _impossible_ to
> parse, due to the course of the application, but most of it is cached.
> The most important things, if I remember correctly, must be:
[snip]
You mistook the important part of Tore's question.
If you can cache everything else, why can't you cache CGI.pm?
--
$;=qq qJ,krleahciPhueerarsintoitq;sub __{0 &&
my$__;s ee substr$;,$,&&++$__%$,--,1,qq;;;ee;
$__>2&&&__}$,=22+$;=~y yiy y;__ while$;;print
------------------------------
Date: 6 Mar 2003 18:23:36 -0800
From: RonaldWS@software-path.com (Ronald Schmidt)
Subject: Re: New module proposed: Class::Accessor::NoviceArray
Message-Id: <86f16f82.0303061823.7cf96382@posting.google.com>
"Ben Kennedy" <bkennedy@hmsonline.com> wrote in message news:<pi2dnedIWNWSHvqjXTWcog@giganews.com>...
> > I am also very much interested in comments regarding other modules that
> > may fill the same purpose and to what degree these modules fill a
> > significant need in Perl programming. From the POD:
>
> The Class::MethodMaker module allows you to create list-style accessors,
> e.g. foo_push, foo_pop, etc. As for as I can tell though, there are no
> options for a read-only list.
>
> --Ben Kennedy
I have taken a look at Class::MethodMaker and can see that it provides
similar functionality to Class::Accessor::NoviceArrayManip for push,
shift and similar operations. In scalar context however
Class::MethodMaker seems to return a plain reference to the array. In
scalar context Class::Accessor::NoviceArray returns a blessed
reference with operator overloading so that one can write:
my $foo = Foo->new;
$foo->array_el('el1', 'el2');
if ($foo->array_el == 2) {
print "two elements\n";
}
as well as
my @copy = $foo->array_el;
Would anyone care to comment on the relevance of this fine point of
array like behavior in scalar context?
Ronald Schmidt
------------------------------
Date: 6 Mar 2003 20:46:05 -0800
From: csdude@hotmail.com (Mike)
Subject: Non-fatal error, "script not found or unable to stat"
Message-Id: <46cdc619.0303062046.6bcc485c@posting.google.com>
Hey, guys,
I'm running my scripts on a remote host, and when I checked the error
log I found that the following error is in there on literally every
script on my site:
script not found or unable to stat: /www/mydomain/cgi-bin/[object]
The scripts are running fine, and when I added the -w switch to
troubleshoot them all I didn't find anything relevant (I get things
like "/\n/ should probably be \n" when I split or join by \n, so I
usually leave the -w out). Unfortunately, though, my error log is
purged every couple of days, so I have no idea how long this is been
going on.
What's more, though, is the following non-fatal error shows on all of
my SSI files:
File does not exist: /www/mydomain/company/[object]
This particular example does nothing more than use SSI to include a
separate html file as a header, and I've been doing it that way on
this host for years!
The only thing I could find in Google was in reference to server
errors, but my host says that nothing has changed on their end. Am I
overlooking something?
TIA,
Mike
PS, I only have one html file on my site that doesn't use SSI, and
it's the only page on my site that's not giving me an error.
------------------------------
Date: 6 Mar 2003 20:32:41 -0800
From: rook_5150@yahoo.com (Bryan Castillo)
Subject: Re: perlcc error (cl and link)
Message-Id: <1bff1830.0303062032.1eacf5c5@posting.google.com>
> > this is the error I get, I'm using active perl for windows.
> >
> > 'cl' is not recognized as an internal or external command,
> > operable program or batch file.
> > 'link' is not recognized as an internal or external command,
> > operable program or batch file.
> >
> >
> > anyone know what's going on?
>
>
> cl is the cmdline version of M$VC++ AFAIK. I assume 'link' has
> something to do with that too. Either they're not installed, or not
> in your %PATH%.
You can look at this batch file to see how your environment should be
set for compiling and linking with MS. (substitute your install dir
though)
C:\Program Files\Microsoft Visual Studio\VC98\Bin\Vcvars32.bat
------------------------------
Date: Fri, 07 Mar 2003 03:31:28 GMT
From: Andrew Lee <spamtrap@nowhere.com>
Subject: Re: printing hash values
Message-Id: <tf4g6vom3ti7ngsgfb2qtpivf2e0g6bbtg@4ax.com>
On 6 Mar 2003 12:51:34 -0800, dwlepage@yahoo.com (david) wrote:
>Andrew Lee <spamtrap@nowhere.com> wrote in message news:<srme6vko3ai0t4db9vf1u5tj9un583cfft@4ax.com>...
>> On 5 Mar 2003 19:22:43 -0800, dwlepage@yahoo.com (david) wrote:
(snip)
>
>
>Great thanks all. Mission accomplished. I think it will take time, but
>it does make more sense to be able to visualize this.. At least for
>dense folks like myself..
>Dave
Dave,
I don't know if you are dense but hashes are :-) They are one of the
very powerful features of Perl and take some time to digest. Play with
examples and feel free to ask questions and, most of all, enjoy!
------------------------------
Date: 6 Mar 2003 18:18:21 -0800
From: distrex@hotmail.com (distrex)
Subject: Put perl in old page
Message-Id: <d9ea2696.0303061818.460e8fb0@posting.google.com>
I have just learned some perl and i would like to put it into my site
I already have up (it makes random quotes). Is there a way to just
call the program from HTML or something simialr.
------------------------------
Date: 7 Mar 2003 02:57:52 GMT
From: roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson)
Subject: Re: Put perl in old page
Message-Id: <b491rg$9oh$1@canopus.cc.umanitoba.ca>
In article <d9ea2696.0303061818.460e8fb0@posting.google.com>,
distrex <distrex@hotmail.com> wrote:
:I have just learned some perl and i would like to put it into my site
:I already have up (it makes random quotes). Is there a way to just
:call the program from HTML or something simialr.
No, HTML itself does not offer any way to call programs.
You need to talk to your WWW server administrator to find out what
kinds of dynamic HTML or CGI scripts that they support. Depending on
what is supported, you -might- be able to embed a line in your HTML
that signals that the program should be called. [You would probably
have to rename the files slightly to get the server to recognize
that it should process them specially.]
--
Rome was built one paycheck at a time. -- Walter Roberson
------------------------------
Date: Fri, 07 Mar 2003 03:27:24 GMT
From: Andrew Lee <spamtrap@nowhere.com>
Subject: question about "new" in a module
Message-Id: <9d3g6v09kgsmi2li12bs18qvhi87ocunn1@4ax.com>
Hello,
I am getting an error in the following code, I wonder if anyone can
explain the error and tell me how to avoid it :
package DT::AssetManager;
use 5.006;
use strict;
use warnings;
use DBConf;
my $conf = DBConf::new("/PATH-TO-CONFIG/myconfig");
# this works in a .pl file
# more stuff snipped
sub new {
my $classname = shift;
>>error : Subroutine new redefined at blib/lib/DT/AssetManager.pm line 22.
It seems like I am fully qualifying 'new' for the module DBConf. Why is
there a name clash?
DBConf starts with :
package DBConf;
require Exporter;
our @EXPORT = qw/new get_dbh getVars DB_Connect getMaxId getMaxRow/;
... other stuff
sub new { .. etc, like above
Thank you for any insight.
------------------------------
Date: Thu, 06 Mar 2003 20:20:21 -0500
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Question about Forking & Win32
Message-Id: <3E67F3D5.8B96F1ED@earthlink.net>
Extended Partition wrote:
>
> In Linux there are certain programs I can start that fork into the
> background and return me to the command prompt. I can then close the
> console and the program keeps running. In Windows NT this is probably
> the same as a service. But is there anyway to do this under Win32? I
> am talking about forking a Perl program into the background in this
> manner.
Not quite -- there's a *sortof* workaround that you can do, but you
can't stick it at an arbitrary point in your program.
In Linux or other *nix Operating Systems, you can fork yourself into the
background at any time.
On windows, you can pretend to fork yourself into the background using
the following trick, but you can really only do it at the beginning of
your program.
#!perl.exe -w
use strict;
use warnings;
unless( @ARGV && $ARGV[0] eq "-no_bg_self" ) {
require Win32::Process;
require FindBin;
Win32::Process::Create( my($procobj),
$^X, "perl $FindBin::RealScript -no_bg_self @ARGV",
0, Win32::Process::CREATE_NO_WINDOW(), "." )
or die $^E;
exit;
}
shift(@ARGV); # discard "-no_bg_self"
# rest of script here.
In other words, create a new, windowless, instance of ourself, with the
same command line arguments as we got, plus a "-no_bg_self" argument,
then exit.
(Actually, you *can* do this at any point in your program, but you'll
have to pass all the information of your parent process to the child
process via @ARGV, or via inherited filehandles.)
--
$;=qq qJ,krleahciPhueerarsintoitq;sub __{0 &&
my$__;s ee substr$;,$,&&++$__%$,--,1,qq;;;ee;
$__>2&&&__}$,=22+$;=~y yiy y;__ while$;;print
------------------------------
Date: 07 Mar 2003 00:10:50 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Regular Expressions
Message-Id: <slrnb6fosa.c8.abigail@alexandra.abigail.nl>
bach (bach@nospamworld.com) wrote on MMMCDLXXIV September MCMXCIII in
<URL:news:vJP9a.185194$Zr%.154617@news01.bloor.is.net.cable.rogers.com>:
;; Dear Brian:
;;
;; I hope your ego feels a little better after showing off your
;; holier-than-thou attitude. A "wrong newsgroup for this post" would have
;; been just fine. "No quickly scribbled response will help you as much as
;; RTFM." And so won't your feather fluffling.
*PLOINK*
Abigail
--
map{${+chr}=chr}map{$_=>$_^ord$"}$=+$]..3*$=/2;
print "$J$u$s$t $a$n$o$t$h$e$r $P$e$r$l $H$a$c$k$e$r\n";
------------------------------
Date: Fri, 07 Mar 2003 01:11:24 +0100
From: "Tore Aursand" <tore@aursand.no>
Subject: Re: Substitution and regex question
Message-Id: <pan.2003.03.07.00.00.54.350637@aursand.no>
On Thu, 06 Mar 2003 20:45:20 +0000, Brian McCauley wrote:
> I think newsgroups should not be used as an alternative to reference
> manuals.
Could you emphasize the 'not' next time? Please? You scared the sh*t out
of me for a moment. :)
--
Tore Aursand <tore@aursand.no>
------------------------------
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.
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 4678
***************************************
