[22169] in Perl-Users-Digest
Perl-Users Digest, Issue: 4390 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Jan 12 18:05:54 2003
Date: Sun, 12 Jan 2003 15:05:09 -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 Sun, 12 Jan 2003 Volume: 10 Number: 4390
Today's topics:
ANNOUNCE: DBIx::Hash2Table V 1.00 <ron@savage.net.au>
ANNOUNCE: DBIx::HTML::ClientDB V 1.02 <ron@savage.net.au>
ANNOUNCE: DBIx::HTML::LinkedMenus V 1.03 <ron@savage.net.au>
ANNOUNCE: DBIx::HTML::PopupRadio V 1.04 <ron@savage.net.au>
ANNOUNCE: DBIx::Table2Hash V 1.00 <ron@savage.net.au>
Re: CGI - HTML Generation problems with images - script <flavell@mail.cern.ch>
Re: CGI - HTML Generation problems with images - script (Stephen Adam)
Re: CGI - HTML Generation problems with images - script <jurgenex@hotmail.com>
Re: CGI - HTML Generation problems with images - script <flavell@mail.cern.ch>
Re: CGI - HTML Generation problems with images - script <bongie@gmx.net>
Re: How does one determine why perl prog runs so slow?? (Peter Scott)
Re: How does one determine why perl prog runs so slow?? (Bob Mariotti)
Re: How does one determine why perl prog runs so slow?? (Mark Jason Dominus)
Re: How does one determine why perl prog runs so slow?? (Tad McClellan)
Re: How does one determine why perl prog runs so slow?? (Tad McClellan)
i'm sorry <estrunk@home.nl>
Re: I've never used the Win32::Daemon <nuts@nutlands.com>
Re: Isogest 3.1 New release <l.ortolani@ecosystemspa.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 12 Jan 2003 13:41:31 +1100
From: "Ron Savage" <ron@savage.net.au>
Subject: ANNOUNCE: DBIx::Hash2Table V 1.00
Message-Id: <3e21d6f5$2_2@news.teranews.com>
The pure Perl module DBIx::Hash2Table V 1.00
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.
This module is not yet formally registered,
so a simplistic CPAN search will not find it.
An extract from the docs:
NAME
DBIx::Hash2Table - Save a hash into a database table
FAQ
Q: What is the point of this module?
A: To be able to save a hash to permanent storage via a database rather than
via a file.
Q: Can your other module DBIx::Table2Hash reconstruct a hash written by this
module?
A: No. Sorry. Perhaps one day.
------------------------------
Date: Sun, 12 Jan 2003 13:31:06 +1100
From: "Ron Savage" <ron@savage.net.au>
Subject: ANNOUNCE: DBIx::HTML::ClientDB V 1.02
Message-Id: <3e21d681$1_5@news.teranews.com>
The pure Perl module DBIx::HTML::ClientDB V 1.02
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.
This module is not yet formally registered, and so
won't be found by simplistic CPAN searches.
The story so far:
1.02 Wed Dec 11 14:29:00
- Minor documentation changes. No need to upgrade
1.01 Sat Oct 26 14:29:00
- Minor documentation changes. No need to upgrade
1.00 Tue Oct 15 12:37:29 2002
- original version
------------------------------
Date: Sun, 12 Jan 2003 13:32:29 +1100
From: "Ron Savage" <ron@savage.net.au>
Subject: ANNOUNCE: DBIx::HTML::LinkedMenus V 1.03
Message-Id: <3e21d68c$2_2@news.teranews.com>
The pure Perl module DBIx::HTML::LinkedMenus V 1.03
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.
This module is not yet formally registered, and so
won't be found by simplistic CPAN searches.
The story so far:
1.03 Wed Dec 11 11:41:13 2002
- Minor documentation changes - no need to upgrade
1.02 Tue Nov 5 11:44:20 2002
- Make new() return undef if the base menu's SQL returns 0 rows
1.01 Tue Oct 15 11:41:13 2002
- Minor documentation changes
1.00 Sat Oct 08 12:37:29 2002
- original version
------------------------------
Date: Sun, 12 Jan 2003 13:33:53 +1100
From: "Ron Savage" <ron@savage.net.au>
Subject: ANNOUNCE: DBIx::HTML::PopupRadio V 1.04
Message-Id: <3e21d6ec$1_3@news.teranews.com>
The pure Perl module DBIx::HTML::PopupRadio V 1.04
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.
This module is not yet formally registered, and so
won't be found by simplistic CPAN searches.
The story so far:
1.04 Wed Dec 11 12:53:57 2002
- Minor documentation changes. No need to upgrade
1.03 Mon Nov 18 12:53:57 2002
- Fix sub radio_group so that if there is no default,
the items are counted, and the first becomes the default.
This was the plan all along, but it was so clear in my
mind I did not transfer the logic to the code
1.02 Sat Oct 26 14:29:00 2002
- Minor documentation changes. No need to upgrade
1.01 Tue Oct 15 11:41:13 2002
- Change the meaning of the 'default' parameter so it refers
to the visible menu item and not the value associated with
the visible menu item. This now matches the meaning of the
'default' parameter used in DBIx::HTML::ClientDB
- Add a primitive test program t/test.t
- Minor documentation changes
1.00 Sat Sep 28 12:37:29 2002
- original version
------------------------------
Date: Sun, 12 Jan 2003 13:44:23 +1100
From: "Ron Savage" <ron@savage.net.au>
Subject: ANNOUNCE: DBIx::Table2Hash V 1.00
Message-Id: <3e21d704$1_3@news.teranews.com>
The pure Perl module DBIx::Table2Hash V 1.00
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.
This module is not yet formally registered,
so a simplistic CPAN search will not find it.
An extract from the docs:
NAME
DBIx::Table2Hash - Read a database table into a hash
FAQ
Q: What is the point of this module?
A: To be able to restore a hash from a database rather than from a file.
Q: Can your other module DBIx::Hash2Table be used to save the hash back to
the database?
A: Sure.
Q: Are there any other modules with similar capabilities?
A: Yes:
[snip]
See docs for details.
------------------------------
Date: Sun, 12 Jan 2003 15:09:25 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: CGI - HTML Generation problems with images - scripts etc
Message-Id: <Pine.LNX.4.40.0301121452480.8087-100000@lxplus067.cern.ch>
On Jan 12, Jay Tilton inscribed on the eternal scroll:
> "Alan J. Flavell" <flavell@mail.cern.ch> wrote:
>
> It's probably just for local testing.
Oh, I see. thanks for stepping-in...
> But it doesn't work because of the backslashes in the
> double-quotish <<HERE doc.
Good point, though if it's a last resort test, then it isn't really
what the O.P wants to do in the real-life production situation. So
taking it out and concentrating on the other approaches would be a
better move.
> As for the other image and script URLs, the OP should try putting them
> somewhere other than the cgi-bin directory.
Agreed, if those *.gif images are static files (which their name very
much suggests), rather than scripts which dynamically generate images.
The usual server setup for the cgi-bin path defines everything which
is referenced in that path to be an executable script, and will merely
cause a server error if the client (e.g browser) attempts to retrieve
a static file from there. Which is what the O.P seems to be
provoking.
> And read the server logs.
Indeed. I guess I wasn't very helpful on the details, while
concentrating on the mental-picture issue. Sorry.
------------------------------
Date: 12 Jan 2003 09:57:49 -0800
From: 00056312@brookes.ac.uk (Stephen Adam)
Subject: Re: CGI - HTML Generation problems with images - scripts etc
Message-Id: <945bf980.0301120957.21dd3094@posting.google.com>
Hey guys
This was just an example I was trying to get working on my home
machine,
I know the path would pointless when I get it on web server and will
alter it when I put it up. I am just fustrated as I can get text
coming up but not images, the example I put up does "work" or rather
not work on my machine.I wanted to sort this out manually instead of
using CGI.pm to know what was going on behind the scenes. This is not
full code, just the smallest amount possible to show what was not
working as apposed to what was working (I know it is invalid html).
And yes I've read perl faq 9 (and I HAVE read the posting guidlines).
Thanks for the advice Jay, it now works better, the middle example now
displays an image but neither of the other two work. Here is the
updated script.
#!C:\perl\perl.exe -w
print <<'END';
<p>This text works fine </p>
#This still doesn't
<img src="./sketchies.gif" alt="HOME PAGE HEADER">
#This now works!
<img src="C:\Program Files\sambar41\cgi-bin\sketchies.gif" alt="HOME
PAGE HEADER">
#This still doesn't
<img src="http://localhost/cgi-bin/sketchies.gif" alt="HOME PAGE
HEADER">
END
exit(0);
Here is the source my web browser shows
<p>This text works fine </p>
<img src="./sketchies.gif" alt="HOME PAGE HEADER">
<img src="C:\Program Files\sambar41\cgi-bin\sketchies.gif" alt="HOME
PAGE HEADER">
<img src="http://localhost/cgi-bin/sketchies.gif" alt="HOME PAGE
HEADER">
Any idea's why only the middle one works? I really need to bottom
example working, whats the problem. I called a friend up and he said I
needed to escape the quotation marks with forward slashes, I don't
think this matters due to the "<<'END'" context, I tried it anyway and
it still does not work.
>Agreed, if those *.gif images are static files (which their name very
>much suggests), rather than scripts which dynamically generate
images.
>The usual server setup for the cgi-bin path defines everything which
>is referenced in that path to be an executable script, and will
merely
>cause a server error if the client (e.g browser) attempts to retrieve
>a static file from there. Which is what the O.P seems to be
>provoking.
As I said this is just for home testing and i'm using sambar which
doesn't care (as far as I know), and I will sort directories and a
good structure out when i've got "some" code working.
And I have tried putting the image in an /images directory but this
does not help either.
Thanks fot the advice.
Steve
------------------------------
Date: Sun, 12 Jan 2003 18:07:02 GMT
From: "Jürgen Exner" <jurgenex@hotmail.com>
Subject: Re: CGI - HTML Generation problems with images - scripts etc
Message-Id: <a9iU9.12841$%V.12073@nwrddc02.gnilink.net>
Stephen Adam wrote:
>[...]
>I wanted to sort this out manually instead of
> using CGI.pm to know what was going on behind the scenes.
Ok, fair enough.
> This is not
> full code, just the smallest amount possible to show what was not
> working as apposed to what was working (I know it is invalid html).
[Perl code snipped]
> Here is the source my web browser shows
[HTML text snipped
> Any idea's why only the middle one works? I really need to bottom
> example working, whats the problem.
Again: is that HTML code the code you want to send to the client? Does it do
what you expect it to do? Apparently it is not because you keep saying it
does not work.
In that case you have a problem with HTML. HTML!!! Not with Perl.
So go to a newsgroup which actually deals with HTML, and ask them how to fix
your HTML code.
Then come back here and we will be happy to help you with how to generate
this fixed HTML code using Perl.
jue
------------------------------
Date: Sun, 12 Jan 2003 23:35:31 +0100
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: CGI - HTML Generation problems with images - scripts etc
Message-Id: <Pine.LNX.4.40.0301122314150.13083-100000@lxplus070.cern.ch>
On Jan 12, Stephen Adam inscribed on the eternal scroll:
> Here is the source my web browser shows
>
> <p>This text works fine </p>
>
> <img src="./sketchies.gif" alt="HOME PAGE HEADER">
>
> <img src="C:\Program Files\sambar41\cgi-bin\sketchies.gif" alt="HOME
> PAGE HEADER">
>
> <img src="http://localhost/cgi-bin/sketchies.gif" alt="HOME PAGE
> HEADER">
What you need to grasp is that the client (browser or whatever) does
not know or care that this HTML has been generated by a Perl script.
As far as it's concerned, it's just a piece of HTML. Perl plays no
part in that particular loop.
> Any idea's why only the middle one works?
Yes, and you've already been told it by one or other posting on this
thread, but it has nothing to do with Perl.
> I really need to bottom example working, whats the problem.
IMHO you told your server that the cgi-bin directory contains
executable scripts, not static resources, so the poor thing is trying
to execute the .gif file as program code. If you'd look in the server
log, as you were already advised but have said nothing about, you
would likely find evidence of this. This too has nothing to do with
Perl, but is an issue involving CGI and web server configuration
(hint: there are better groups for discussing those aspects).
> I called a friend up and he said I
> needed to escape the quotation marks with forward slashes,
That's a Perl question alright, and it's one that you'll need the
answer to quite soon, (so look up 'quote and quote-like operators' in
the Perl documentation, perldoc perlop); but it isn't the problem that
you're tackling right now, since you already accepted a different
solution to that issue.
> I don't think this matters due to the "<<'END'" context,
correct
> As I said this is just for home testing and i'm using sambar which
> doesn't care (as far as I know),
I can't believe that. A server needs to know whether to return the
contents of a file to the client, or to execute it as a CGI script.
How are you telling it?
> And I have tried putting the image in an /images directory but this
> does not help either.
Then you're doing it wrong - but this is the wrong place to go into
such non-Perl detail.
My initial hunch seems to be borne out: you are making this a lot
harder for yourself because you need to develop your skills in problem
domain partitioning, or whatever you call it. You've got several
technologies in the same bucket and don't know which does what.
There's no shame in that - everyone has to start somewhere, but you do
need to work on it a bit yet. Working your way through some tutorial
material could be helpful in the long run. See if anything cited in
the FAQs appeals.
Hope this helps.
------------------------------
Date: Sun, 12 Jan 2003 23:51:02 +0100
From: "Harald H.-J. Bongartz" <bongie@gmx.net>
Subject: Re: CGI - HTML Generation problems with images - scripts etc
Message-Id: <1050182.3mgNTmrnco@nyoga.dubu.de>
Stephen Adam wrote:
> This was just an example I was trying to get working on my home
> machine,
> I know the path would pointless when I get it on web server and will
> alter it when I put it up.
Hm. Well, you *do* have a web server running on your home machine, don't
you? Or just how do you call that script from your browser? It should
be using something like
http://localhost/cgi-bin/scriptname.pl
[...]
> Thanks for the advice Jay, it now works better, the middle example now
> displays an image but neither of the other two work. Here is the
> updated script.
>
> #!C:\perl\perl.exe -w
>
>
> print <<'END';
>
> <p>This text works fine </p>
This should already give a 500 error in your browser, because there is
not HTTP header. Again, how do you call this script? I suspect that
you really don't have the web server running or you just don't access
it correctly, but either
a) use the script on the command line to create an HTML file, which you
call from your browser, or
b) open the script in your browser using file://..., such displaying its
contents (where I suppose, IE may be happily rendering the HTML part).
> #This still doesn't
> <img src="./sketchies.gif" alt="HOME PAGE HEADER">
This should work if accessed using a web server and if sketchies.gif is
in the same dir as the script.
> #This now works!
> <img src="C:\Program Files\sambar41\cgi-bin\sketchies.gif" alt="HOME
> PAGE HEADER">
This should always work. It's a local access and totally unrelated to
server function.
> #This still doesn't
> <img src="http://localhost/cgi-bin/sketchies.gif" alt="HOME PAGE
> HEADER">
This only works if your web server is configured correctly and
sketchies.gif is in the right dir.
> Here is the source my web browser shows
>
>
> <p>This text works fine </p>
>
> <img src="./sketchies.gif" alt="HOME PAGE HEADER">
>
> <img src="C:\Program Files\sambar41\cgi-bin\sketchies.gif" alt="HOME
> PAGE HEADER">
>
> <img src="http://localhost/cgi-bin/sketchies.gif" alt="HOME PAGE
> HEADER">
Where are the Perl "comments" from your code? They should not vanish,
just because they are inside a here-document.
> As I said this is just for home testing and i'm using sambar
Did you test that the server's demo documents are accessible? (I just
assume that Sambar provides something like that.)
> which
> doesn't care (as far as I know), and I will sort directories and a
> good structure out when i've got "some" code working.
> And I have tried putting the image in an /images directory but this
> does not help either.
... and called it with href="/images/sketchies.gif" ?
HTH,
Harald
--
Harald H.-J. Bongartz <bongie@gmx.net>
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
At my lemonade stand I used to give the first glass away free and
charge five dollars for the second glass. The refill contained the
antidote. -- Emo Phillips
------------------------------
Date: Sun, 12 Jan 2003 18:17:01 GMT
From: peter@PSDT.com (Peter Scott)
Subject: Re: How does one determine why perl prog runs so slow????
Message-Id: <xiiU9.21257$Yo4.1520064@news1.calgary.shaw.ca>
In article <Kw%T9.645059$%m4.814438@rwcrnsc52.ops.asp.att.net>,
"Dick Penny" <penny1482@attbi.com> writes:
>However, I have offered before, and I still offer, to help or write
>revisions to the standard doc junk that comes with Perl, at least AS Perl.
>
>Since I have not received one shred of interest, I feel obliged to 'whine' a
>bit.
Then head over to http://pdp.perl.org, where you'll find plenty of opportunity
to write all the Perl documentation you want.
--
Peter Scott
http://www.perldebugged.com
------------------------------
Date: Sun, 12 Jan 2003 19:43:12 GMT
From: R.Mariotti@FinancialDataCorp.com (Bob Mariotti)
Subject: Re: How does one determine why perl prog runs so slow????
Message-Id: <3e21c441.8752732@news.cshore.com>
On Sat, 11 Jan 2003 09:16:41 -0600, tadmc@augustmail.com (Tad
McClellan) wrote:
>Bob Mariotti <R.Mariotti@FinancialDataCorp.com> wrote:
>> Honestly! I HAVE searched this group, other perl sites, perlfaqs, etc
>> and I cannot find anything that actually covers this topic.
>
>
>You missed it then.
>
>
>> So, here's my question for the perl guru's that I could not find in
>> the faqs or other resources:
>>
>> How does one go about determining what may be the cause of this
>> unacceptable performance?
>
>
> perldoc -q profile
>
> "How do I profile my Perl programs?"
>
>
>--
> Tad McClellan SGML consulting
> tadmc@augustmail.com Perl programming
> Fort Worth, Texas
Well, what a thread. I must state that the first "meaningful"
response I received was from Benjamin Goldberg posted at 13 minutes
past midnight last Friday night. It was also the FIRST time I was
advised of the term "profiler". The second was from Tad McClellan,
also mentioning "profile".
And, now for my own two cents: Having been a top level programmer
for over 25 years and for the last 10 years concentrating on the *nix
environment I have been using perl since 1996. I am also a member of
the Hartford Perl Mongers and also attended some Boston PM meetings.
Usenet is one of the best resources I have ever seen in all my years.
I read many groups daily (even on weekends) and if I feel qualified to
provide a meaningful answer to someone's question I do so willingly
hoping to make that persons task somewhat easier.
I also thing that I personally have funded much of O'Reilley's empire
based solely on the number of their titles I have purchased. So,
published/printed documentation is NOT foreign to me. In addition to
usenet I also frequent several private tech support sites (i.e.:
tek-tips and others). Again, give and take is the way it works.
It also has been my experience that not all persons involved in perl
can spend their entire waking hours concentrating on an issue. Some
of us, being gainfully employed, are responsible for the care and well
being of our clients' production systems and well as our own. And, in
addition the well being of multiple servers, both in our own employ
and those of our client's. Not to mention the applications that are
NOT written in perl. (go figure!)
So, it is NOT unwarranted for someone to post a query in the HOPE that
perhaps someone else "might have" experienced the same situation and,
thus, could provide a pointer to how to resolve the issue. You will
notice that the post was 1) in the perl.misc group and NOT the
perl.moderated or perl.modules and 2) NOT cross posted (this time).
Wouldn't one who frequents usenet make an educated attempt to post to
what he/she believes would be the group where the most skilled gutu's
would reside just hoping to get a quick response?
I personally have learned a great deal from frequenting usenet and
while my entire cache of technical knowledge might not wholely come
from usenet, it certainly was the catalyst that most likely got me to
the right area of research.
So, please, those of you on high horses... get the HELL down to
earth where reality is. And if you don't like to help someone who
might not possess the exact piece of knowledge the you think you do,
then move on to the next topic. It's THAT easy.
And, in closing, the absolute BEST response I got to this posting was
perhaps the last one posted by Xho (ctcgag@hotmail) because he/she
methodically explained how to insert exit points at various point
throughout the program trying to isolate the problem area. While
this kind description was simply common debugging and what any
self-respecting tech person could and should do, at least he did
provide a logical approach. And, he didn't whine. He also asked
that when the area cuasing the extreme slowdown is identified and
resolved to please post the results. This too is a learning benefit.
After all... some of us don't know everything already.
Bob
Hartford PM
always trying to learn more and still get my job(s) done.
------------------------------
Date: Sun, 12 Jan 2003 20:09:20 +0000 (UTC)
From: mjd@plover.com (Mark Jason Dominus)
Subject: Re: How does one determine why perl prog runs so slow????
Message-Id: <avsi1g$m3f$1@plover.com>
In article <x7of6nfr7j.fsf@mail.sysarch.com>,
Uri Guttman <uri@stemsystems.com> wrote:
>>>>>> "AF" == Abernathey Family <family2@aracnet.com> writes:
>
> AF> Feeling obligated to make a contribution to continue a 24x7 presense on
> AF> this newsgroup Tad McClellan wrote:
>
>you are killfile material for that. i can here the plonks from all over
>the world.
I agree with him. It was a useless answer.
>you don't have the right to whine about an answer unless you provide
>better help yourself.
Oh? And who died and made you king?
------------------------------
Date: Sun, 12 Jan 2003 15:49:30 -0600
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: How does one determine why perl prog runs so slow????
Message-Id: <slrnb23ona.avc.tadmc@magna.augustmail.com>
Bob Mariotti <R.Mariotti@FinancialDataCorp.com> wrote:
> On Sat, 11 Jan 2003 09:16:41 -0600, tadmc@augustmail.com (Tad
> McClellan) wrote:
>
>>Bob Mariotti <R.Mariotti@FinancialDataCorp.com> wrote:
[snip]
>>> How does one go about determining what may be the cause of this
>>> unacceptable performance?
>>
>>
>> perldoc -q profile
>>
>> "How do I profile my Perl programs?"
[snip quoted .sig]
> Well, what a thread. I must state that the first "meaningful"
> response I received was from Benjamin Goldberg posted at 13 minutes
> past midnight last Friday night. It was also the FIRST time I was
> advised of the term "profiler". The second was from Tad McClellan,
> also mentioning "profile".
I assume that learning that term was of value to you?
> And, now for my own two cents:
About what?
There were several (unlabeled) sub-threads on various subjects
in this thread.
How to find out what is slowing down a program
The helpfulness of being referred to the standard docs
(this subthread launched by a demonstrated troll, check
the family's posting history)
The quality of the std docs
How easy or hard it is to contribute a change to the std docs
Notice where the anger and bickering entered the thread?
None of it had to do with you missing something in the docs...
> Usenet is one of the best resources I have ever seen in all my years.
> I read many groups daily (even on weekends) and if I feel qualified to
> provide a meaningful answer to someone's question I do so willingly
> hoping to make that persons task somewhat easier.
Since you've inserted your followup where you did, I assume
that you are discussing the first of those.
> published/printed documentation is NOT foreign to me.
Consulting books doesn't (or shouldn't anyway) matter here.
I don't recall ever seeing someone taken to task here for
not consulting a book. Some people do not have all, or even any,
Perl books.
I see daily folks being taken to task for not consulting the
std docs though. Everyone that has a properly installed
perl has those.
But that did not happen in this thread, nor in my followup.
I didn't say you did anything wrong. You didn't do anything wrong.
You are not required to _find_ the applicable part in the std docs,
they're awfully big. You _are_ expected to look there before
posting.
You did, so no problem.
>Again, give and take is the way it works.
I've done a measurable amount of giving here in the past.
I even gave _you_ what you were looking for.
I've never happened to do the "taking" part yet. I had to read the
docs for my newsreader the other day to figure out how to make
an original post rather than a followup. :-)
> It also has been my experience that not all persons involved in perl
> can spend their entire waking hours concentrating on an issue.
I do not see what it was in my post that implied that I expected
that folks did that.
You are seeing things that are not there. (or you meant to attach
your followup to some other post in the thread)
> So, it is NOT unwarranted for someone to post a query in the HOPE that
> perhaps someone else "might have" experienced the same situation and,
> thus, could provide a pointer to how to resolve the issue.
Again, I do not see what it is the post you quoted that said or
implied that that was unwarranted.
And I *did* provide a pointer to how to resolve the issue.
You quoted it yourself!
> So, please, those of you on high horses... get the HELL down to
> earth where reality is.
Since you are following up to my post, I guess I must be
one of the lofty equestrians to which you refer?
> And if you don't like to help someone who
> might not possess the exact piece of knowledge the you think you do,
> then move on to the next topic. It's THAT easy.
I _do_ like to help folks.
I _did_ help folks, including you in this very thread.
What are you going on about?
Or did you mean to followup to some other post in the thread?
> And, he didn't whine.
You seem to be implying that I _did_ whine.
I'm not seeing any whining in the post you quoted.
Please point it out to me.
> After all... some of us don't know everything already.
But you knew more after my followup then before it, so
what is your beef with me?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 12 Jan 2003 15:56:21 -0600
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: How does one determine why perl prog runs so slow????
Message-Id: <slrnb23p45.avc.tadmc@magna.augustmail.com>
Mark Jason Dominus <mjd@plover.com> wrote:
> In article <x7of6nfr7j.fsf@mail.sysarch.com>,
> Uri Guttman <uri@stemsystems.com> wrote:
>>>>>>> "AF" == Abernathey Family <family2@aracnet.com> writes:
>>
>> AF> Feeling obligated to make a contribution to continue a 24x7 presense on
>> AF> this newsgroup Tad McClellan wrote:
>>
>>you are killfile material for that. i can here the plonks from all over
>>the world.
>
> I agree with him. It was a useless answer.
Are you saying that Devel::DProf is useless for finding out
what is slowing down a Perl program?
I'm willing to learn from my mistakes, but I need to recognize
the mistake to be able to do that.
I cannot see the uselessness in my, nor the FAQ's, answer.
Where is it?
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sun, 12 Jan 2003 18:22:41 +0100
From: "estrunk" <estrunk@home.nl>
Subject: i'm sorry
Message-Id: <LuhU9.19135$J6.1781043@zwoll1.home.nl>
I'm sorry just told you i'm a newbie, and in an english language i didn't
know wat is the diffrence
i just posted it in comp.unix shell.
Hope that's the right thing to post in.
--
Kind regards and thanks for your help.
Met Vriendelijke Groeten,
E. Strunk
------------------------------
Date: Sun, 12 Jan 2003 20:21:47 GMT
From: nuts <nuts@nutlands.com>
Subject: Re: I've never used the Win32::Daemon
Message-Id: <v7kU9.657171$P31.483445@rwcrnsc53>
mike wrote:
> I've never used the Win32::Daemon.
think you should use it. Dave Roth's Modules are some of the very best
out there for NT APPLICATION/SYS MANAGEMENT support point. This is not a
sales pitch as i have used them.
Win32::Daemon was not available when while back i had used SRVANY Stub
from the resource kit to make my scripts a service.
they read a job file and execute certain fuctions based on the request.
the job file get ftp'ed and part of the script mails out the output
Win32::Daemon would let me get rid of the resource kit part.
>
> What I want to do is to be able to call some fairly simple Perl applications
> routines.
>
> Actually I have to convince the guy running our Win2000 server that we can call some
> Perl routines from some server applications without causing too much trouble to the
> rest of the server.
>
> I want to be able to run some Robot and Lint type programs from a call from a browser
> so that they can complete without being killed under a time-out.
checkout Parallel::forkmanager @CPAN (not sure if this is available on
NT)....
>
> Should I plan to start the daemon running and then use it for each such call, or
> should I start and stop the daemon each time I kick off the called applications ?
>
> Is there a way to use the daemon in this fashion ?
>
> Does starting and stopping the daemon (or a given daemon) run into problems I don't
> see yet ?
you should not have any issues. Just be sure no to have memory leaks.
>
> Mike
> <mike@mainstreet-software.com>
>
cheers
prasanth mudundi
pmudundi - a t - a t t b i . c o m.
------------------------------
Date: Sun, 12 Jan 2003 23:17:04 +0100
From: Dante Ortolani <l.ortolani@ecosystemspa.com>
Subject: Re: Isogest 3.1 New release
Message-Id: <avsoli$35c$1@lacerta.tiscalinet.it>
Try now!!
Clay Irving wrote:
> In article <avkuge$fuu$1@lacerta.tiscalinet.it>, Dante Ortolani wrote:
>> Hi,
>> you can try on line by a demo the last release of my software written in
>> pure perl.
>> Isogest is a Office Suite that work with Mysql or Postgres.
>>
>> Site http://isogest.sourceforge.net/
>> Demo http://isogest.sourceforge.net/Demo/
>
> Which gives:
>
> Internal Server Error
> The server encountered an internal error or misconfiguration and was
> unable to complete your request.
>
------------------------------
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 4390
***************************************
