[21778] in Perl-Users-Digest
Perl-Users Digest, Issue: 3982 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Oct 16 18:10:50 2002
Date: Wed, 16 Oct 2002 15:05:15 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Wed, 16 Oct 2002 Volume: 10 Number: 3982
Today's topics:
[OT] Re: silent detection of cgi completion problem <jeff@vpservices.com>
Re: [OT] Re: silent detection of cgi completion problem <flavell@mail.cern.ch>
Re: [OT] Re: silent detection of cgi completion problem <jeff@vpservices.com>
Anything better than eval("\$$class\::x") ? <heather710101@yahoo.com>
Re: Anything better than eval("\$$class\::x") ? <pinyaj@rpi.edu>
Re: Anything better than eval("\$$class\::x") ? <mike_constant@yahoo.com>
Re: Anything better than eval("\$$class\::x") ? <mike_constant@yahoo.com>
Re: Anything better than eval("\$$class\::x") ? <heather710101@yahoo.com>
Capitalizing letters in the middle of "word" (Dan Skadra)
Re: Capitalizing letters in the middle of "word" <depesz@depesz.pl>
Re: Capitalizing letters in the middle of "word" <krahnj@acm.org>
Re: CGI-related error (Tad McClellan)
DBI::Proxy-alike on Windows <pkent77tea@yahoo.com.tea>
Re: defining subroutines on the fly in a module <bkennedy@hmsonline.com>
Re: defining subroutines on the fly in a module <novalid@email.oops>
Re: dump not dumping Was: Re: Perl Memory Management <pkent77tea@yahoo.com.tea>
Re: How to know if packed as binary? <philip@zaynar.demon.co.uk>
Re: HTTP Command help....? <asimmons@mitre.org>
Re: http://lists.perl.org (slightly OT) (trwww)
Is perlmonks.com down today? Or is just me. (Russell Cecala)
Re: Opinion on using Perl or JavaScript for Web develop (trwww)
Re: Opinion on using Perl or JavaScript for Web develop (Brian)
Re: Opinion on using Perl or JavaScript for Web develop (Brian)
Re: Opinion on using Perl or JavaScript for Web develop <asimmons@mitre.org>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Wed, 16 Oct 2002 11:01:39 -0700
From: Jeff Zucker <jeff@vpservices.com>
Subject: [OT] Re: silent detection of cgi completion problem
Message-Id: <3DADA983.8070106@vpservices.com>
[posted and courtesy cc mailed]
Alan J. Flavell wrote:
> On Oct 15, Steve inscribed on the eternal scroll:
>
> [snip]
>
> And by the way, you don't seem to have a Perl language problem.
Except for omitting binmode :-).
> Why do you want to "detect when the cgi has finished"? The idea of a
> CGI script is that the client invokes a URL, the server prepares the
> data for the script, the script runs for a short time, and returns a
> result to the server, which in turn returns the HTTP protocol response
> to the client. End of story.
Yes, in most cases, end of story. But, heading out of perl-land here,
the DOM includes several facilities which both make it not the end of
story and which make the Status 204 solution not relevant. For example,
if a page has an iframe whose src is set to a CGI script and whose
visibility is set to hidden and whose onLoad() is set to some DOM
compatible script function, then here's the scenario:
1. when the main page loads, the hidden iframe sends a CGI request to
the server via its src property
2. server sends back a full page (not a 204) which becomes the content
of the hidden iframe
3. the iframe's onLoad handler alerts a DOM function that the server's
response has been recieved
4. the function then uses DOM to parse the tags of the page content in
the hidden iframe and uses that information to dynamically change
something else on the main page without reloading the main page.
The transactions between the client and server are still, of course,
stateless. But those stateless transactions can be integrated into a
dynamic page that uses the information from those transactions to
preserve and dynamically update state on the client side.
> The initial HTTP request, and the closing HTTP response, are the only
> communications which take place between the client and the server in a
> single transaction cycle: there's no kind of intermediate opportunity
> for any "detection" to occur.
I think that applies to 95% of the situations out there, but unless I'm
mistaken, there is room for a standards compliant solution to the other
5%. (statistics made up, of course, but I think you know what I mean).
--
Jeff
------------------------------
Date: Wed, 16 Oct 2002 21:47:45 +0200
From: "Alan J. Flavell" <flavell@mail.cern.ch>
Subject: Re: [OT] Re: silent detection of cgi completion problem
Message-Id: <Pine.LNX.4.40.0210162026140.18684-100000@lxplus071.cern.ch>
On Oct 16, Jeff Zucker inscribed on the eternal scroll:
> Alan J. Flavell wrote:
> > And by the way, you don't seem to have a Perl language problem.
>
> Except for omitting binmode :-).
Well spotted! Next time I'll try to remember to say "by the way, what
you were _asking_ about wasn't a Perl language problem". :-}
> > Why do you want to "detect when the cgi has finished"? The idea of a
> > CGI script is that the client invokes a URL, the server prepares the
> > data for the script, the script runs for a short time, and returns a
> > result to the server, which in turn returns the HTTP protocol response
> > to the client. End of story.
>
> Yes, in most cases, end of story. But, heading out of perl-land here,
> the DOM includes several facilities which both make it not the end of
> story and which make the Status 204 solution not relevant.
[..fairly complex example elided...]
Sure: a much simpler example would be a page which is returned with a
meta--refresh, and after the specified delay, calls up a script (maybe
the same one) to see what's what.
> The transactions between the client and server are still, of course,
> stateless.
That's the key...
> But those stateless transactions can be integrated into a
> dynamic page that uses the information from those transactions to
> preserve and dynamically update state on the client side.
Right, but they don't involve re-connecting to some long-running
script on the server. In fact, it's quite usual for servers to hit
CGI scripts over the head if they appear to be running for an
unreasonable time.
There's a CGI (not Perl ;-) FAQ about how do I arrange for a script to
kick-off a long-running process, and then later come back for the
answer. That's do-able - if it's essential, but I was trying to get
an idea of the scale of the real-world problem before suggesting
resorting to such complexity.
> I think that applies to 95% of the situations out there, but unless I'm
> mistaken, there is room for a standards compliant solution to the other
> 5%.
As you say, though, each interaction with the server will be a
stateless exchange, involving the usual to-and-fro of: present this
request to that URL, the server runs the script, the script responds
to the server, and the server returns the HTTP response to the client.
Maybe the client keeps the party going by initiating some new
transaction - but the key to understanding is that each one is a
separate HTTP transaction in itself. Inherently stateless, as you
said.
So, going back to the original question "how do I detect that the CGI
script has finished?", my answer still is that the client simply
awaits the HTTP transaction response - there's no "detection" needed
beyond that.
cheers
------------------------------
Date: Wed, 16 Oct 2002 14:06:41 -0700
From: Jeff Zucker <jeff@vpservices.com>
Subject: Re: [OT] Re: silent detection of cgi completion problem
Message-Id: <3DADD4E1.7060304@vpservices.com>
Alan J. Flavell wrote:
> On Oct 16, Jeff Zucker inscribed on the eternal scroll:
>
> [..fairly complex example elided...]
>
> Sure: a much simpler example would be a page which is returned with a
> meta--refresh, and after the specified delay, calls up a script (maybe
> the same one) to see what's what.
Except your example omits the "detection" phase, which is what the OP
was asking about.
> [snip other good points about state]
> There's a CGI (not Perl ;-) FAQ about how do I arrange for a script to
> kick-off a long-running process, and then later come back
But what we're discussing here is not long-running CGI scripts, rather
quick CGI scripts which send responses to "long running" DHTML pages.
> So, going back to the original question "how do I detect that the CGI
> script has finished?", my answer still is that the client simply
> awaits the HTTP transaction response - there's no "detection" needed
> beyond that.
Well, true, there's no point in knowing literally "when the CGI script
has finished" if "finished" means that the script has finished running
or finished a given task. But if "finished" means that the CGI script
has finished its task and the server has finished sending the response
to the client and the client has completely recieved that response, then
there certainly is a way to detect that state and that detection
certainly is needed in the kind of example I gave (though not in the one
you gave). The onLoad event handler's sole purpose is to detect exactly
that definition of "finished" -- when the client has fully recieved the
response. In the example I gave, the main page can't begin parsing the
embedded iframe's CGI-generated content until that content is fully
recieved and therefore needs to detect when that happens with onLoad or
some sort of setTimeOut loop.
--
Jeff
------------------------------
Date: Wed, 16 Oct 2002 20:23:13 +0000 (UTC)
From: Da Witch <heather710101@yahoo.com>
Subject: Anything better than eval("\$$class\::x") ?
Message-Id: <aokhrh$saf$1@reader1.panix.com>
Consider a method like this:
sub static_x {
my $proto = shift;
my $class = ref $proto || $proto;
my $x = "\$$class\::x"; # $x holds a string of the form '$Foo::x'
if(@_) {
eval("$x = $_[0]");
}
eval($x);
}
For example, if Foo is a class that has inherited this method, then
Foo->static_x(3) sets $Foo::x to 3, and returns this value.
Is there a way to achieve this (i.e. accessing a global from a package
determined at runtime) without using eval?
Thanks!
h
------------------------------
Date: Wed, 16 Oct 2002 16:32:52 -0400
From: Jeff 'japhy' Pinyan <pinyaj@rpi.edu>
To: Da Witch <heather710101@yahoo.com>
Subject: Re: Anything better than eval("\$$class\::x") ?
Message-Id: <Pine.A41.3.96.1021016162924.31856A-100000@vcmr-104.server.rpi.edu>
[posted & mailed]
On Wed, 16 Oct 2002, Da Witch wrote:
> sub static_x {
> my $proto = shift;
> my $class = ref $proto || $proto;
>
> my $x = "\$$class\::x"; # $x holds a string of the form '$Foo::x'
# class->some_var(name, [value]);
sub some_var {
my $class = shift() . "::";
my $name = shift;
my $var = $::{$class}{$name};
$$var = shift if @_;
return $$var;
}
Why do you need this?
--
Jeff "japhy" Pinyan RPI Acacia Brother #734 2002 Acacia Senior Dean
"And I vos head of Gestapo for ten | Michael Palin (as Heinrich Bimmler)
years. Ah! Five years! Nein! No! | in: The North Minehead Bye-Election
Oh. Was NOT head of Gestapo AT ALL!" | (Monty Python's Flying Circus)
------------------------------
Date: Wed, 16 Oct 2002 13:44:44 -0700
From: "Newbie" <mike_constant@yahoo.com>
Subject: Re: Anything better than eval("\$$class\::x") ?
Message-Id: <aokj3t$nfh9c$1@ID-161864.news.dfncis.de>
"Da Witch" <heather710101@yahoo.com> wrote in message
news:aokhrh$saf$1@reader1.panix.com...
>
>
> Consider a method like this:
>
> sub static_x {
> my $proto = shift;
> my $class = ref $proto || $proto;
>
> my $x = "\$$class\::x"; # $x holds a string of the form '$Foo::x'
>
> if(@_) {
> eval("$x = $_[0]");
> }
> eval($x);
> }
>
> For example, if Foo is a class that has inherited this method, then
> Foo->static_x(3) sets $Foo::x to 3, and returns this value.
>
> Is there a way to achieve this (i.e. accessing a global from a package
> determined at runtime) without using eval?
>
> Thanks!
>
> h
Not sure why you want something like this, but you can always use a method
to set/get an attribute, then can dynamically call it at runtime like this
my $code = \&{ref($foo)."::static_x"};
my $value = $code->(3);
where $foo is an object of Foo, and static_x (should be something like do_x)
is defined in Foo, which basically resembles the following
sub static_x
{
shift;
return (defined $_[0] ? ($x = shift} : $x;
}
------------------------------
Date: Wed, 16 Oct 2002 13:46:23 -0700
From: "Newbie" <mike_constant@yahoo.com>
Subject: Re: Anything better than eval("\$$class\::x") ?
Message-Id: <aokj6u$nll09$1@ID-161864.news.dfncis.de>
"Newbie" <mike_constant@yahoo.com> wrote in message
news:aokj3t$nfh9c$1@ID-161864.news.dfncis.de...
>
> "Da Witch" <heather710101@yahoo.com> wrote in message
> news:aokhrh$saf$1@reader1.panix.com...
> >
> >
> > Consider a method like this:
> >
> > sub static_x {
> > my $proto = shift;
> > my $class = ref $proto || $proto;
> >
> > my $x = "\$$class\::x"; # $x holds a string of the form '$Foo::x'
> >
> > if(@_) {
> > eval("$x = $_[0]");
> > }
> > eval($x);
> > }
> >
> > For example, if Foo is a class that has inherited this method, then
> > Foo->static_x(3) sets $Foo::x to 3, and returns this value.
> >
> > Is there a way to achieve this (i.e. accessing a global from a package
> > determined at runtime) without using eval?
> >
> > Thanks!
> >
> > h
>
> Not sure why you want something like this, but you can always use a method
> to set/get an attribute, then can dynamically call it at runtime like this
>
> my $code = \&{ref($foo)."::static_x"};
> my $value = $code->(3);
>
> where $foo is an object of Foo, and static_x (should be something like
do_x)
> is defined in Foo, which basically resembles the following
>
> sub static_x
> {
> shift;
> return (defined $_[0] ? ($x = shift} : $x;
> }
return defined $_[0] ? ($x = shift) : $x;
------------------------------
Date: Wed, 16 Oct 2002 22:00:16 +0000 (UTC)
From: Da Witch <heather710101@yahoo.com>
Subject: Re: Anything better than eval("\$$class\::x") ?
Message-Id: <aoknhg$17h$1@reader1.panix.com>
In <Pine.A41.3.96.1021016162924.31856A-100000@vcmr-104.server.rpi.edu> Jeff 'japhy' Pinyan <pinyaj@rpi.edu> writes:
>[posted & mailed]
>On Wed, 16 Oct 2002, Da Witch wrote:
>> sub static_x {
>> my $proto = shift;
>> my $class = ref $proto || $proto;
>>
>> my $x = "\$$class\::x"; # $x holds a string of the form '$Foo::x'
> # class->some_var(name, [value]);
> sub some_var {
> my $class = shift() . "::";
> my $name = shift;
> my $var = $::{$class}{$name};
> $$var = shift if @_;
> return $$var;
> }
>Why do you need this?
I want to have inheritable methods that can get/set globals in the
subclass's package.
h
------------------------------
Date: 16 Oct 2002 11:27:39 -0700
From: dskadra@yahoo.com (Dan Skadra)
Subject: Capitalizing letters in the middle of "word"
Message-Id: <c1bd7661.0210161027.5ce00f3e@posting.google.com>
I'm trying to reformat a list of user names in the form 'smith_bob'
where the first leters of the fist and last names are sometimes
capitalized, sometimes not. What I'd like to do is find a way to
capitalize those letters if they aren't already. So, I'd like it to
look like 'Smith_Bob', no matter how it is capitalized.
I'm fairly new to perl, so I'm having some trouble building an
expression. I think it can be done with tr/// or s///, just not sure
how.
Any ideas?
Thanks!
--------------------
Dan Skadra
dskadra@yahoo.com
'If you can't beat your computer at chess, try kickboxing.'
------------------------------
Date: Wed, 16 Oct 2002 21:14:34 +0200
From: hubert depesz lubaczewski <depesz@depesz.pl>
Subject: Re: Capitalizing letters in the middle of "word"
Message-Id: <slrn.pl.aqrekq.4to.depesz@depeszws.depesz.pl>
Dan Skadra wyrzeĽbił(a):
> I'm fairly new to perl, so I'm having some trouble building an
> expression. I think it can be done with tr/// or s///, just not sure
> how.
s/(^|_)([a-z]+)/$1\u\L$2/ig
depesz
--
hubert depesz lubaczewski http://www.depesz.pl/
------------------------------------------------------------------------
Mój Boże, spraw abym milczał, dopóki się nie upewnię, że naprawdę mam
co¶ do powiedzenia. (c) 1998 depesz
------------------------------
Date: Wed, 16 Oct 2002 21:23:44 GMT
From: "John W. Krahn" <krahnj@acm.org>
Subject: Re: Capitalizing letters in the middle of "word"
Message-Id: <3DADD8AE.CEF957A1@acm.org>
Dan Skadra wrote:
>
> I'm trying to reformat a list of user names in the form 'smith_bob'
> where the first leters of the fist and last names are sometimes
> capitalized, sometimes not. What I'd like to do is find a way to
> capitalize those letters if they aren't already. So, I'd like it to
> look like 'Smith_Bob', no matter how it is capitalized.
$ perl -le'$_ = "smith_bob"; s/([a-z]+)/\u$1/g; print'
Smith_Bob
John
--
use Perl;
program
fulfillment
------------------------------
Date: Wed, 16 Oct 2002 15:44:36 -0500
From: tadmc@augustmail.com (Tad McClellan)
Subject: Re: CGI-related error
Message-Id: <slrnaqrjtk.1so.tadmc@magna.augustmail.com>
Colby <yorokobi@sisna.com> wrote:
> Subject: CGI-related error
Your problem is not CGI related.
If it _was_ CGI related, then you should have posted it in
the CGI newsgroup instead.
> I have a CGI script accessing a MySQL DB via DBI, the script executes
> almost flawlessly on my home Linux box running Apache 1.3.26 and Perl
> 5.8.0 (with the usual modules installed and then some :) (The warning
> my Linux box gives me is related to the concatenation operator '.')
That may well be part of the same problem.
You should be able to code it so that you never get _any_ warnings.
Got code? Got the exact text of the warning message?
> However, the web host that I've just signed up with (running RH Linux
> with Apache 1.3.? and Perl 5.6.1) won't execute my script and returns
> the following errors when run from the command line:
> _________________________________________
>
> Global symbol "" requires explicit package name at ./myscript.cgi line
> 60, 70, 90, 108
> _________________________________________
> I don't have
> a variable that has no name or is "" and so the above
> error has really stumped me.
> Any ideas folks?
Show code if you need help debugging code.
Try to make a short and complete program that we can run
that illustrates the problem you are having, and I'm sure
we could help you fix it.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Wed, 16 Oct 2002 20:59:23 GMT
From: pkent <pkent77tea@yahoo.com.tea>
Subject: DBI::Proxy-alike on Windows
Message-Id: <pkent77tea-FCF948.21592316102002@news-text.blueyonder.co.uk>
hi all,
I've had much fun at work failing to get the DBI::Proxy server (run from
the dbiproxy.bat script) to run on a Win2K machine in forking or
threading mode. In single-thread mode it works fine. Any attempt to use
the fork or thread modes leads to a fatal error.
From a little searching on google it seems that this is an inherent
problem which is Just The Way It Is... correct me if I'm wrong.
So is there something like DBI::Proxy that we can use with, say, CGI
programs on the windows machine? That way we could use Apache as a very
reliable preforked server which would handle the incoming connections,
and our CGI program would only have to do a single database connection
etc.
Or is there a better way? Our aim is to have a database gateway running
on a windows machine that will accept an arbitrary number of connections
to the same port. Naturally the less coding we have to do the better.
We're even considering editing the existing DBI::Proxy code and creating
a new module which doesn't rely on PlRPC etc.
We're using build 631, i think, of activeperl 5.6.1.
P
--
pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
Remove the tea to reply
------------------------------
Date: Wed, 16 Oct 2002 14:45:47 -0400
From: "Ben Kennedy" <bkennedy@hmsonline.com>
Subject: Re: defining subroutines on the fly in a module
Message-Id: <CNKdnWxXcKaWKTCgXTWcqg@News.GigaNews.Com>
"Keith A. Clay" <novalid@email.oops> wrote in message
news:3dad7ec5$1_4@news.teranews.com...
>
> Folks,
>
> I have a list of variables separated by a semicolon and are defined in
> the module object ($self->{'USER_VARS'}). Is there a way in a
> subroutine to define each of these with a subroutine that can be called
> like $self->set_user_name.
>
> How do I accomplish this??
See "perldoc -f eval". Basically you generate the code that contains the
subroutine, eg $var = "sub your_sub { bleh }". Then just "eval $var" - but
be sure to check $@ afterwards to diagnose any bugs in your dynamically
generated code. Aftwerwards, your_sub() is available in the namespace you
eval'ed in.
--Ben Kennedy
------------------------------
Date: Wed, 16 Oct 2002 17:04:36 -0500
From: "Keith A. Clay" <novalid@email.oops>
To: Ben Kennedy <bkennedy@hmsonline.com>
Subject: Re: defining subroutines on the fly in a module
Message-Id: <3DADE274.2020108@email.oops>
Ben Kennedy wrote:
> "Keith A. Clay" <novalid@email.oops> wrote in message
> news:3dad7ec5$1_4@news.teranews.com...
>
>
> See "perldoc -f eval". Basically you generate the code that contains the
> subroutine, eg $var = "sub your_sub { bleh }". Then just "eval $var" - but
> be sure to check $@ afterwards to diagnose any bugs in your dynamically
> generated code. Aftwerwards, your_sub() is available in the namespace you
> eval'ed in.
Ben,
Thanks for the info. It solved the problem. here is what it looks like
for those who may be interested:
sub cr_user_subs {
my ($self)=@_;
foreach my $ul ( split(':',$self->{'USER_VARS'}) ) {
my $name=lc($ul);
my $sname="set_" . $name;
my $tvar;
my $gname="get_" . $name;
$tvar="sub $sname { my
(\$self,\@arr)=\@_;\$self->change_user_var(\@arr) }";
eval $tvar;
if ( $@ ) {
print "Error creating subroutine '$sname' -- exiting.";
return 1;
}
$tvar="sub $gname { my
(\$self,\@arr)=\@_;\$self->query_user_var(\@arr) }";
eval $tvar;
if ( $@ ) {
print "Error creating subroutine '$gname' -- exiting.";
return 1;
}
}
}
keith
------------------------------
Date: Wed, 16 Oct 2002 20:48:21 GMT
From: pkent <pkent77tea@yahoo.com.tea>
Subject: Re: dump not dumping Was: Re: Perl Memory Management
Message-Id: <pkent77tea-809F06.21482116102002@news-text.blueyonder.co.uk>
In article <CK0r9.1330$rU3.71764026@newssvr13.news.prodigy.com>,
Darren Dunham <ddunham@redwood.taos.com> wrote:
> Do other processes create dumps? If you have coredumpsize limited to 0,
> I imagine you will not get one.
Aha, there seems to be something called ulimit in bash that lets me set
this. Core dumps happen now. ta.
P
--
pkent 77 at yahoo dot, er... what's the last bit, oh yes, com
Remove the tea to reply
------------------------------
Date: Wed, 16 Oct 2002 20:22:18 +0100
From: Philip Taylor <philip@zaynar.demon.co.uk>
Subject: Re: How to know if packed as binary?
Message-Id: <D5VOUBAqxbr9EwHW@zaynar.demon.co.uk>
In article <3DAC1C28.9060500@web.de>, edgue@web.de writes
>My hope was that pack() would create some "magic type information"
>that I could use later on.
my $x = unpack F => pack L => 0xffffffff;
print "$x\n", unpack(H8 => reverse pack F, $x), "\n\n";
my $y = unpack F => pack L => 0xfffffffe;
print "$y\n", unpack(H8 => reverse pack F, $y), "\n";
outputs
-1.#QNAN
ffffffff
-1.#QNAN
fffffffe
It appears that while $x seems to contain "-1.#QNAN" in both cases,
there must also be some extra data about the original unpacked value so
that unpack is able to return the original input correctly.
So pack does hide some information with the variable -- but I'm not
aware of any way to access it, so it's not all that useful :-(
--
Philip Taylor
philip@zaynar.demon.co.uk
------------------------------
Date: Wed, 16 Oct 2002 15:39:01 -0400
From: "Aaron Simmons" <asimmons@mitre.org>
Subject: Re: HTTP Command help....?
Message-Id: <aokf7k$1bh$1@newslocal.mitre.org>
My only problem with your replies is that you claim I am "feeding newbies a
lot of inaccurate detail" -- all I did was reply to the message explaining
how my code, which does what I beleive the poster was asking about, works.
I even re-stated the question at the top to make sure I was clear as to what
question I was answering.
Is the way I explained it the only way to do it--no.
Did I offer the "correct solution" first--yes, I pointed him to CGI.pm and
its redirect method. But I thought the poster would also like to know the
HTTP response message that the CGI.pm's redirect method sends back. Your
point about nph vs. parsed headers is completely accurate, but since I was
including the HTTP line, one as knowledgable as you should be able to deduce
I am referring to nph.
I just recently started reading comp.lang.perl.misc postings with the
intention of responding to questions that I have personal experience with.
I don't claim to be an all-knowing Perl expert, but I have done a lot of
things with Perl, and I feel it is only right to give back to the Perl
community. But I don't understand how people like you Alan can be so
controlling. Is it your duty to patrol the newsgroups and correct the
wrongs? And if so, exactly what again was wrong about my correctly working
suggestions? I beileve you just felt the need to communicate your opinion
about my response, and I suppose you have that right, but don't go around
saying I am feeding newbies a lot of inaccurate detail because that just
isn't true.
--
Aaron Simmons
G066-Software Systems Eng, Lead
(703) 883-3394
AaronSimm1 (AIM)
"Alan J. Flavell" <flavell@mail.cern.ch> wrote in message
news:Pine.LNX.4.40.0210151508070.7201-100000@lxplus071.cern.ch...
> On Oct 14, brian d foy inscribed on the eternal scroll:
>
> > it would be nice if people who answered Perl questions actually
> > knew how to help people, or at least correctly answered the
> > question.
>
> That was pretty-much my feeling too. If they disagree with the FAQ,
> which they have every right to do, they should take that up with those
> who wrote the FAQ, rather than undermining it by feeding newbies a lot
> of inaccurate detail. Knowing where to find the authoritative specs
> and citing the relevant sections in support of their reply is always
> good for some bonus points too; fortunately, on Usenet the TOFU-style
> still seems to be a widely-applicable bogosity alert.
>
> > you seemed to have confused the two types of redirections, and if
> > you knew who Alan was you would take your lumps and move on.
>
> Hey, I'm nothing special: on Usenet we stand or fall by what we post,
> not by who we are or what impressive job title we can parade.
>
> all the best
>
------------------------------
Date: 16 Oct 2002 11:21:40 -0700
From: toddrw69@excite.com (trwww)
Subject: Re: http://lists.perl.org (slightly OT)
Message-Id: <d81ecffa.0210161021.44c3505b@posting.google.com>
Rocco Caputo <troc@netrus.net> wrote in message news:<slrnaqoksn.8ma.troc@eyrie.homenet>...
> On 15 Oct 2002 14:46:16 GMT, Tassilo v. Parseval wrote:
> >
> > anyone has an idea what happened to lists.perl.org? It doesn't appear to
> > be accessible (at least not since yesterday). This is a little bit
> > unfortunate since I intended to subscribe to the perl-xs mailing list and
> > now can't find the necessary data (subscription address and so on).
>
> Nearly all of the mailing lists at perl.org respond to a blank message
> to <listname-help@perl.org>.
>
> Also check if your newsfeed has a perl.xs newsgroup.
>
> -- Rocco Caputo / troc@pobox.com / poe.perl.org / poe.sf.net
You can also access all the mailing lists through a news reader at
nntp.perl.org that interfaces with all the people that use the list
through an email interface. Its nice because I really hate mailing
lists.
Theres even a web interface if you point your web browser to
http://nntp.perl.org/ if you only feel like browsing.
Todd W.
------------------------------
Date: 16 Oct 2002 14:22:44 -0700
From: russellcecala@netscape.net (Russell Cecala)
Subject: Is perlmonks.com down today? Or is just me.
Message-Id: <14d3c801.0210161322.4a236e6@posting.google.com>
Anyone know what's up with perlmonks.com?
------------------------------
Date: 16 Oct 2002 11:13:06 -0700
From: toddrw69@excite.com (trwww)
Subject: Re: Opinion on using Perl or JavaScript for Web development
Message-Id: <d81ecffa.0210161013.5777ebc9@posting.google.com>
BChirhart@fnni.com (Brian) wrote in message news:<9d13498b.0210151551.7dc7f22f@posting.google.com>...
> This is more of an opinion question than anything. Hopefully I will
> go down the right track after your responses...
>
> I need to develop a web page. It will need to have radio buttons,
> drop downs, and list boxes. The drop down menus need to be cascading
> (i.e. change an option in the first menu and the values listed in the
<snip />
> My problem is:
> If I use all Perl - <snip />
> If I use CGI - <snip />
> If I use Javascript... <snip />
> The last option is PHP - <snip />
>
> I am not against learning any of these things, but if you had my
> assignment, what route would you take?
>
You are a bit ahead of yourself. Basically, if you want to do
something like this, its not about learning _any_ ( i.e. one or the
other ) of these things, its about learning _all_ of these things.
perl, cgi, dhtml, php, all these things are different tools, and none
of them replace each other, although some may slightly overlap on the
edges.
If you would like to ask more questions about the subject, a good
general purpose web app development list is
comp.infosystems.www.authoring.cgi, as this post is off topic for
c.l.p.m
HTH
Todd W.
------------------------------
Date: 16 Oct 2002 11:24:15 -0700
From: BChirhart@fnni.com (Brian)
Subject: Re: Opinion on using Perl or JavaScript for Web development
Message-Id: <9d13498b.0210161024.6d226430@posting.google.com>
"Ron Savage" <ron@savage.net.au> wrote in message news:<aojd3t$2of2
>
> There is a new module, DBIx::HTML::LinkedMenus available from CPAN and from http://savage.net.au/Perl-modules.html
>
> It has not appeared in comp.lang.perl.announce yet.
Ron - It's funny that you should reply - I had your site open before i
read this post.
I looked at that module, but I could not find the example for the
code. Am I not looking in the right spot?
------------------------------
Date: 16 Oct 2002 12:08:23 -0700
From: BChirhart@fnni.com (Brian)
Subject: Re: Opinion on using Perl or JavaScript for Web development
Message-Id: <9d13498b.0210161108.2f38a12a@posting.google.com>
Thanks Clyde for all your advice. I figured I could do it with the
tools that I have, but just don't know how.... I seem to have a good
chunk of time to try to do this though. That is good. I will get to
reading then.
------------------------------
Date: Wed, 16 Oct 2002 16:05:24 -0400
From: "Aaron Simmons" <asimmons@mitre.org>
Subject: Re: Opinion on using Perl or JavaScript for Web development
Message-Id: <aokgp2$1eb$1@newslocal.mitre.org>
Clyde's response is exactly how I would attack this problem. You will be
using both Perl and JavaScript--Perl on the server-side; JavaScript as part
of the response back to the browser.
Another approach along the same lines would be to write some moderately
complex JavaScript (or find something out there) that acts as your drop down
menu engine. I did this a few years ago for my last company--I labeled it
DDDL (dynamic drop down lists). It had two kinds of JavaScript objects:
Lists and Actions -- Lists were value/text pairs representing one set of
options for a <select> element; actions defined what to do when selectA was
changed to optionB. I would post this JS code, but unfortunately it's
propreitary.
It works pretty well if you have a finite amount of data that you know up
front i.e. car make and model. Another nice thing is it works for any
number of inter-connecting menus.
I really like what I saw in DBIx::HTML::LinkedMenus -- it looks like a great
framework for this problem space.
--
Aaron Simmons
G066-Software Systems Eng, Lead
(703) 883-3394
AaronSimm1 (AIM)
"Brian" <BChirhart@fnni.com> wrote in message
news:9d13498b.0210151551.7dc7f22f@posting.google.com...
> This is more of an opinion question than anything. Hopefully I will
> go down the right track after your responses...
>
> I need to develop a web page. It will need to have radio buttons,
> drop downs, and list boxes. The drop down menus need to be cascading
> (i.e. change an option in the first menu and the values listed in the
> second menu change). Also, the second menu has to be populated by
> reading the directory structure of a server. The list box is
> populated from the list of files that are in the directory of the
> second drop down. Because of that, I can not get CGI (or CGI.pm) to
> work. Once the values are entered in the radio buttons and the drop
> downs, the user will need to click a button (submit or otherwise) and
> a perl script will need to run that will create a JPG or PNG file.
> Then a new web page will need to open displaying some text and the
> file.
>
> My problem is:
> If I use all Perl - I can not get a GUI web interface. If this is
> wrong and I can do this whole thing in Perl PLEASE TELL ME!!! I
> already have most of the code written in Perl and would really hate to
> change it.
>
> If I use CGI - I can not get cascading menus to work correctly and can
> not access the directories on the server. This is a limitation of CGI
> - correct?
>
> If I use Javascript... Well - I don't know much about Javascript and I
> thought that was going to be my answer. But then I read a bunch of
> posts where people are talking about server side/client side JS and
> basically that you should not mix perl and JS.
>
> The last option is PHP - which I know NOTHING about other than how to
> spell it.
>
> I am not against learning any of these things, but if you had my
> assignment, what route would you take?
>
> TIA for all your input and suggestions.
> Brian
------------------------------
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 3982
***************************************
