Where I'm getting hosed is that %config and %session have data
I need visible to the Text::Template objects themselves. I've
RTFM'ed until my eyes are pink, and I see no options short of
copying variables wholesale into another Package, but then I
still can't get at them and "use s
All,
I read that if you run scripts under Apache::Registry, its a good idea to
write memory leak proof code. I also read that one should "clean up their"
globals. Any examples in Stas's guide or elsewhere of "cleaning up" globals
or classic memory leaks associated with Apache::Registry.
--- Joseph Crotty [EMAIL PROTECTED] wrote:
I read that if you run scripts under Apache::Registry,
its a good idea to write memory leak proof code.
Since the code is resident in memory between calls to the script, it's
a *very* good idea to be careful of such things.
I also read that one
(see below).
The CGI program has multiple "pages" of potential output depending on the
action requested, and variables are passed around these pages using hidden
input tags. Pretty standard stuff. Here's some sample code:
# UltraForm2 is a module/API I've made. Not a CPAN module
Hi,
thanks for your reply,
Stas Bekman wrote:
On Wed, 20 Dec 2000, Alexander Farber (EED) wrote:
sub mysort
{
my $param = $query - param ('sort') || 'MHO'; # XXX global $query,
# not mod_perl clean?
return $a - {$param} cmp
On Thu, 21 Dec 2000, Alexander Farber (EED) wrote:
Stas Bekman wrote:
On Wed, 20 Dec 2000, Alexander Farber (EED) wrote:
sub mysort
{
my $param = $query - param ('sort') || 'MHO'; # XXX global $query,
# not mod_perl clean?
On Sun, 5 Nov 2000, Hadmut Danisch wrote:
Hi,
sorry if this was discussed before or if it is
a dull question, but I couldn't find any other
help than subscribing to this list:
I have a Perl Handler Module (PerlAuthenHandler)
and want to lookup environment variables set by other
Hi,
http://perl.apache.org/guide/perl.html#my_Scoped_Variable_in_Nested_S
advises not to use external "my $variables"
from subroutines. I have
the following subroutine in my CGI-script, which I would like to keep
mod_perl-kosher, ju
On Wed, 20 Dec 2000, Alexander Farber (EED) wrote:
Hi,
http://perl.apache.org/guide/perl.html#my_Scoped_Variable_in_Nested_S
advises not to use external "my $variables"
from subroutines. I have
the following subroutine in my CGI-script, which I would like to keep
mod_perl-ko
-Original Message-
From: Mark Doyle [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 15, 2000 4:06 PM
To: Jimi Thompson
Cc: [EMAIL PROTECTED]
Subject: Re: Apache::Reload and environment variables
On Friday, December 15, 2000, at 04:01 PM, Jimi Thompson wrote
. It is only Apache::Reload that has the problem.
I suspect it may be that I am running Apache/1.3.9 (Unix)
mod_perl/1.21 and there were probably some patches along
the way to mod_perl that fixed up some bugs with environment
variables. I am also going to try using the latest/greatest
mod_perl and see
Greetings,
I tried using Apache::Reload:
PerlSetEnv ORACLE_HOME /oracle/app/oracle/product/8.0.3/
PerlModule Apache::DBI
[...]
PerlModule Apache::Reload
PerlInitHandler Apache::Reload
PerlSetVar ReloadAll Off
but when I do, the error log gets filled with
"ORACLE_HOME not set!"
Only one module
Mark,
If the variable ORACLE_HOME doesn't change why not just set it as an
environment variable outside the program and export it?
Mark Doyle wrote:
Greetings,
I tried using Apache::Reload:
PerlSetEnv ORACLE_HOME /oracle/app/oracle/product/8.0.3/
PerlModule Apache::DBI
[...]
On Friday, December 15, 2000, at 04:01 PM, Jimi Thompson wrote:
If the variable ORACLE_HOME doesn't change why not just set it as an
environment variable outside the program and export it?
PerlSetEnv ORACLE_HOME /oracle/app/oracle/product/8.0.3/
PerlModule Apache::DBI
[...]
PerlModule
subroutine is only a closure when it sees lexical
variables and must therefore create a distinct clone of the
environment on the way out.
And both named subroutines and anonymous subroutines can be closures.
Here's how to tell if a subroutine is a closure or not:
for (1..5) {
pu
Hi,
sorry if this was discussed before or if it is
a dull question, but I couldn't find any other
help than subscribing to this list:
I have a Perl Handler Module (PerlAuthenHandler)
and want to lookup environment variables set by other
modules, e.g. the variables set by apache-ssl for the
DN
perl is that things persist so
variables don't get cleared, and my closures don't get
recompiled. Your array growing problem sounds like one
that "use strict" programming will take care of because
if you initialize your array with my @arr; then it should
be cleared just fine every script execution.
--Joshua
an update and within the next couple of months I plan
to do so but this software resides on a production box so there's little
room
for mishaps. I am waiting to install all the newest software on a new box
and
then transfer control.
So, as the subject line states, the variables in my .asp's tend
he subject line states, the variables in my .asp's tend to retain
the
values used in previous script runs. If I leave stronghold going for a
while
without a restart, I can go to one of the forms, load it (initially
everything
should be blank) and then see someone else's info already
use an update and within the next couple of months I plan
to do so but this software resides on a production box so there's little
room
for mishaps. I am waiting to install all the newest software on a new box
and
then transfer control.
So, as the subject line states, the variables in my
and putting
them in a perl lib. If that does it I'll let you know.
Thanks,
Demetrios
-Original Message-
From: Joshua Chamas [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 20, 2000 8:09 PM
To: Demetrios C. Christopher
Cc: [EMAIL PROTECTED]
Subject: Re: Apache::ASP : perl variables ten
On Thu, 17 Aug 2000 [EMAIL PROTECTED] wrote:
Let me start with "I'm new".
If this is the wrong forum, let me know now and please direct me to the right
place.
I come from the Mac/Windows world.
I'd like to know howm to check on the status of Apache via perl and what
commands are
Let me start with "I'm new".
If this is the wrong forum, let me know now and please direct me to the right
place.
I come from the Mac/Windows world.
I'd like to know howm to check on the status of Apache via perl and what
commands are possible to check on things like the listeners, DB
2 main things to read for mod_perl apache:
the guide:
http://perl.apache.org/guide/
the book:
http://www.oreilly.com/catalog/wrapmod/
--
___cliff [EMAIL PROTECTED]http://www.genwax.com/
good luck,
[EMAIL PROTECTED] wrote:
Let me start with "I'm new".
If this is the wrong forum, let me
, http://dev:9040/ might be integrated with the main
working database, while http://dev:9041/ works with a testing or training
database. This separation is crucial in development and client use.
Unfortunately, Informix and one of our own libraries depends on environment
variables
Stas Bekman wrote:
I think you confuse,
something. When the script is recompiled all the variables belonging to
the package decalared by Apache::Registry or similar are getting reset. If
you require/use() some modules that declare packages and have global
variables -- these won't be reset
On Fri, 4 Aug 2000, Keith G. Murphy wrote:
Stas Bekman wrote:
I think you confuse,
something. When the script is recompiled all the variables belonging to
the package decalared by Apache::Registry or similar are getting reset. If
you require/use() some modules that declare packages
___cliff rayman___ wrote:
The perl interpreter has a one global symbol table called the stash where
all global variables are referenced by package and by variable name.
Since the interpreter does not go away when a script is recompiled, neither
does the stash or any of the items contained
"Keith G. Murphy" wrote:
___cliff rayman___ wrote:
The perl interpreter has a one global symbol table called the stash where
all global variables are referenced by package and by variable name.
Since the interpreter does not go away when a script is recompiled, neither
does
On Thu, 3 Aug 2000, ___cliff rayman___ wrote:
"Keith G. Murphy" wrote:
___cliff rayman___ wrote:
The perl interpreter has a one global symbol table called the stash where
all global variables are referenced by package and by variable name.
Since the interpreter does n
Stas Bekman wrote:
On Thu, 3 Aug 2000, ___cliff rayman___ wrote:
"Keith G. Murphy" wrote:
___cliff rayman___ wrote:
The perl interpreter has a one global symbol table called the stash where
all global variables are referenced by package and by variable name.
On Thu, 3 Aug 2000, ___cliff rayman___ wrote:
Stas Bekman wrote:
On Thu, 3 Aug 2000, ___cliff rayman___ wrote:
"Keith G. Murphy" wrote:
___cliff rayman___ wrote:
The perl interpreter has a one global symbol table called the stash where
all global
This is probably a very basic question, understood by everyone but...
Why, when I change a script loaded under Apache::Registry, and the
script (verifiably) reloads, do global variables not reinitialize?
I'm running Apache 1.3.9, mod_perl 1.21 on a Debian GNU/Linux system.
Am I the only one
The perl interpreter has a one global symbol table called the stash where
all global variables are referenced by package and by variable name.
Since the interpreter does not go away when a script is recompiled, neither
does the stash or any of the items contained within it. Some programmers
hello.
i am using Tie::IxHash within my Apache::ASP page and
have noticed that the size of my processes are
balooning in size (as told by 'top').
do i need to explicitly untie and undef my tie
variables? or are they automatically freed when my
page exits?
thank you,
remi
Remi Fasol wrote:
hello.
i am using Tie::IxHash within my Apache::ASP page and
have noticed that the size of my processes are
balooning in size (as told by 'top').
do i need to explicitly untie and undef my tie
variables? or are they automatically freed when my
page exits?
If you
OK thanks,
but how I create a global variable, which will be
global for all apache processes together ?
and I have nother problem what is a right usage of
using DBI in script ?
I have a Apache::DBI , DBI and connect_on_init in my
startup.pl and connection is established OK.
what should than i
Hi all,
I am new to mod_perl and i have one problembr
I want to rewrite this simple script from fastcgi to
mdo_perl
-
use FCGI;
$cnt = 0;
while (FCGI::Accept)
{
print "Content-type:text/html\n\n";
print $cnt++;
}
-
This script writes (when i relaod it) 1,2,3,4,5,...
and
I am new to mod_perl and i have one problembr
.
.
.
This script writes 1,1,1,2,2,2,3,3,3,2,2,3,4,2,1 .
randomly !!
Global variables are your problem. The thing is, each global has a
value that is persistent... IN ANY GIVEN APACHE CHILD PROCESS!
So, your increments are working, but you
seems to me, that the script is working as it should.. you are just
hitting several different instances of the script.. one for each
apache child process.. try starting apache with the -X flag.
'./httpd -X' .. this will cause apache to run in single process mode.
hope this helps.
On
, if a module defines variables in the
Apache::ReadConfig:: namespace, they are fed to the apache config gears
just as Perl sections are.
Erhm, I am doing this right now (the functions I call just implant
Location directives etc.. into the caller's package).
Now it would be interesting
forget about mod_perl for a moment. yes, true, Perl's built-in require
will not reload a module if it's already in %INC. but that's doesn't mean
a Perl environment cannot un-cache that entry so it will be reloaded.
consider the code below, pretend that loop is a long-lifetime server,
Tk type
On Fri, 26 May 2000, Marc Lehmann wrote:
I know this and I have no problems with that (as I made very clear in my
last mail). But when mod_perl requires special programming techniques this
does not mean that code not using that techniques is "broken anyway", as
dougm said, at least not in
difficult for code that resides in many files (package
variables are, of course, global to the whole package not just the file or
the block), but not unsolvable.
You see, my first problem was misunderstanding (or not understanding) what
apache does during the "module initialization phase&qu
that resides in many files (package
variables are, of course, global to the whole package not just the file or
the block), but not unsolvable.
The simplest thing is to just not use PerlFreshRestart or Apache::StatINC
(which works in a similar way). These are generally a bad idea for
production
Philip Mak wrote:
I've noticed something peculiar with Apache::ASP. It does not seem to be
initializing variables to 0. That is, if I load one ASP webpage that sets
a variable to X, then in the next ASP webpage the variable is initialized
to X instead of 0. Is this intended behavior
I've noticed something peculiar with Apache::ASP. It does not seem to be
initializing variables to 0. That is, if I load one ASP webpage that sets
a variable to X, then in the next ASP webpage the variable is initialized
to X instead of 0. Is this intended behavior, or is it a bug?
Also, I
On Fri, May 26, 2000 at 10:33:15AM -0400, Geoffrey Young [EMAIL PROTECTED] wrote:
mod_perl sometimes requires special perl coding guidelines, due in part to
the way mod_perl works with and within apache.
I know this and I have no problems with that (as I made very clear in my
last mail). But
On Tue, May 23, 2000 at 10:05:01AM +0200, Marc Lehmann wrote:
On Tue, May 23, 2000 at 12:56:28AM -0500, Autarch [EMAIL PROTECTED] wrote:
On Tue, 23 May 2000, Marc Lehmann wrote:
stable (mod_perl really is very unstable for large applications). Apart
Wow, I wish you'd warned me
On Wed, 24 May 2000, Marc Lehmann wrote:
You must be kidding here!!! Using lexicals on package level is broken??? If
it is broken, then _why_ is it recommended programming practise in perl (see
perltoot for example)?
i'm not kidding. i don't understand whay you mean by 'using lexicals on
from Perl sections, but you can load all
your modules, shared data, etc. from a file pulled in with PerlRequire.
actually you can, if a module defines variables in the
Apache::ReadConfig:: namespace, they are fed to the apache config gears
just as Perl sections are.
On Thu, May 25, 2000 at 12:09:09PM -0700, Doug MacEachern [EMAIL PROTECTED] wrote:
You can only configure Apache from Perl sections, but you can load all
your modules, shared data, etc. from a file pulled in with PerlRequire.
actually you can, if a module defines variables in the
Apache
On Thu, May 25, 2000 at 11:58:38AM -0700, Doug MacEachern [EMAIL PROTECTED] wrote:
You must be kidding here!!! Using lexicals on package level is broken??? If
it is broken, then _why_ is it recommended programming practise in perl (see
perltoot for example)?
i'm not kidding. i don't
On Tue, May 23, 2000 at 04:07:40PM -0700, Perrin Harkins [EMAIL PROTECTED] wrote:
This is a combination of closures and PerlFreshRestart biting
(still no closures)
My example might be misleading, since I used x before it was defined (to make
the example short). Typical examples look like this:
On Wed, May 24, 2000 at 12:52:37AM +0300, Stas Bekman [EMAIL PROTECTED] wrote:
You can control what's being reloaded and what's not:
http://perl.apache.org/guide/config.html#Apache_Restarts_Twice_On_Start
Huh? Why is "do" a bad thing
Do is bad because it is called every time, even if you've already executed
You are confused about the two different forms of do. The do BLOCK form I
used has nothing to do with the do EXPR form you seem to be confused about.
perldoc -f do explains the
On Tue, 23 May 2000, Perrin Harkins wrote:
Your sub x is a closure. That's why it returns the previous value of
No. In perl, a closure is *defined* as "anonymous subroutine" (see the
documentation). If you define it different, you are right, but you are not
talking about perl then.
--
On Tue, May 23, 2000 at 08:22:59PM -0700, Doug MacEachern [EMAIL PROTECTED] wrote:
If this were true, it would be very bad. If there is no technical
need to do this "half-reloading" then it should definitely be turned
off.
it is off by default, you turned it on with 'PerlFreshRestart On'
[EMAIL PROTECTED] (Marc Lehmann) wrote:
flag to keep from compiling again and checking $@ yourself, so you're
getting around these problems, but the file form of do is generally a red
flag.
This is just as saying "division is a bad thing in general, because it
let's you try to divide by
"tayers" == [EMAIL PROTECTED] writes:
tayers Given the above more complete descriptions I would say the usage in
tayers Lperlsub is confusing.
I agree with that, and with your general observation. From my hanging
out on P5P, a subroutine is only a closure when it sees lexical
On Wed, 24 May 2000, Marc Lehmann wrote:
On Wed, May 24, 2000 at 12:52:37AM +0300, Stas Bekman [EMAIL PROTECTED] wrote:
You can control what's being reloaded and what's not:
http://perl.apache.org/guide/config.html#Apache_Restarts_Twice_On_Start
more
lexical variables declared outside the subroutine itself."
When this code gets parsed, the $x goes out of scope at the end of the
block, but show_x keeps a copy of it.
I think that this is the source of the behavior you saw where it looked
like there were multiple versions of subs and
On Wed, May 24, 2000 at 11:30:40AM -0700, Perrin Harkins [EMAIL PROTECTED] wrote:
example did something similar, indeed, but it had to be embedded into the
module source, which is somewhat inconvinient.
If you don't have PerlFreshRestart turned on (it is not recommended on
production
d
very much depends on random factors.
To my pity, _some_ global (non-lexical) variables also get cleared, but
not in all packages.
Now, since this is really hard to debug (the order of function declaration
within the same file and wether the funciton is exported or not, and
wether there are o
On Tue, May 23, 2000 at 12:56:28AM -0500, Autarch [EMAIL PROTECTED] wrote:
On Tue, 23 May 2000, Marc Lehmann wrote:
stable (mod_perl really is very unstable for large applications). Apart
Wow, I wish you'd warned me before I did several large applications using
mod_perl. Fortunately,
On Tue, May 23, 2000 at 12:27:58PM +0800, Gunther Birznieks [EMAIL PROTECTED]
wrote:
replace my $global with use vars qw($global); and your problem should
disappear.
If you had read my mail you would have known that I do not search for a
workaround. While in this simple example it is
On Tue, 23 May 2000, Marc Lehmann wrote:
On Tue, May 23, 2000 at 12:56:28AM -0500, Autarch [EMAIL PROTECTED] wrote:
On Tue, 23 May 2000, Marc Lehmann wrote:
stable (mod_perl really is very unstable for large applications). Apart
Wow, I wish you'd warned me before I did several
On Mon, May 22, 2000 at 11:24:10PM -0700, Perrin Harkins [EMAIL PROTECTED] wrote:
business about being parsed twice only applies to Apache's config file
and Perl sections in it, not to your modules.
A little followup: Looking at the mod_perl source, I see that INC is
tinkered with in a lot of
On Tue, May 23, 2000 at 09:26:13AM +0100, Matt Sergeant [EMAIL PROTECTED] wrote:
Hmm... AxKit does all this, and is very stable for me, and I've only had a
couple of reports of segfaults, none of which went unsolved as far as I
know...
OK. To be fair, I am not 100% sure wether it's an
[EMAIL PROTECTED] (Marc Lehmann) wrote:
=
package othermodule;
my $global = 5;
sub set_global {
$global = shift;
}
=
And use this from
technical aspect is clear (to me at
least, but I am bad at explaining ;): the file is sourced twice, and the
function is compiled twice (and since each "my" generates another instance
of a lexical, there are two variables).
The problem is that some code that was compiled "in betwe
helu.
Marc Lehmann wrote:
And so my question is: why does this behaviour exist, and why is it
necessary (the documents I saw so far only told me that this "has
something to do with apache's configuration file parsing", which doesn't
explain much, especially as it does seem unnecessary).
On Tue, 23 May 2000, Marc Lehmann wrote:
As a related note, I wondered why there isn't a mod_perl callback that is
clled _before_ forking, but after configuration parsing. This would allow
a lot of data sharing between the httpd servers. My module requires you to
call "configured PApp" at
On Tue, May 23, 2000 at 10:08:46AM -0700, Gustavo Duarte [EMAIL PROTECTED] wrote:
I'm not sure this makes sense for your case, but it might help, so...
It probably makes a lot of sense. Thanks!
"When the server [apache] is restarted, the configuration and module
initialization phases are
or perldoc mod_perl / RESTARTING:
PerlFreshRestart On
Please note that setting this option results in parsing your modules
twice at server startup, and reparsing at every restart. Old code and
variables are not cleared and might interfere with your module. Avoiding
lexical variables at gl
On Tue, 23 May 2000, Marc Lehmann wrote:
At leats in the example I sent in there is no sign of any closure.
There is a closure, and this might be the thing that's making trouble for
you, or at least part of it. This is a closure:
that example is only a closure if it's compiled by
On Tue, 23 May 2000, Perrin Harkins wrote:
Your sub x is a closure. That's why it returns the previous value of
$x. When it gets re-defined, it should start looking at the value of the
new $x.
nevermind what i said in the other reply about not being a closure.
you're right, it is by
of set_global, two versions of $global, and which one gets called
very much depends on random factors.
To my pity, _some_ global (non-lexical) variables also get cleared, but
not in all packages.
Now, since this is really hard to debug (the order of function declaration
within the same file and wether
again, _another_ instance of $global gets
created, and another instance of set_global is compiled. Now there are two
versions of set_global, two versions of $global, and which one gets called
very much depends on random factors.
To my pity, _some_ global (non-lexical) variables also get cleared
On Tue, 23 May 2000, Marc Lehmann wrote:
stable (mod_perl really is very unstable for large applications). Apart
Wow, I wish you'd warned me before I did several large applications using
mod_perl. Fortunately, they haven't experienced any mod_perl related
problems. Just a fluke, I guess.
Ime Smits wrote:
| Well, I would like to suggest that you consider including !--#include
| virtual-- in the Apache::ASP distribution, so that included files use the
| same namespace. It doesn't make sense logically that include virtual
| behaves differently from include file (other than the
So, there's no way in Apache::ASP to include a file by specifying a path
relative to DOCUMENT_ROOT, or relative to the directory of the current
file (which is not necessarily equivalent to the request URI, if the
current file is included)?
I managed to get my site to work using !--#include
Philip Mak wrote:
So, there's no way in Apache::ASP to include a file by specifying a path
relative to DOCUMENT_ROOT, or relative to the directory of the current
file (which is not necessarily equivalent to the request URI, if the
current file is included)?
I managed to get my site to
Hello,
I have stumbled upon an issue with Apache::ASP !--#include virtual--
directive. Included files do not seem to be able to access the same scope
of variables. I am using the following test program:
File 1.inc:
!--#include virtual="2.inc"--
% $test .= '1'; %
p$test = %=$test%/p
!--#include virtual--
directive. Included files do not seem to be able to access the same scope
of variables. I am using the following test program:
File 1.inc:
!--#include virtual="2.inc"--
% $test .= '1'; %
p$test = %=$test%/p
File 2.inc:
% $test = '2'; %
One wo
On Sat, 20 May 2000, Joshua Chamas wrote:
Use file includes. virtual includes are meant to execute
anything and include its output, and is handles by Apache::SSI
outside of Apache::ASP. File includes will be executed as perl
asp subroutines in the same perl namespace as the
including
Philip Mak wrote:
I see. There are two problems that I have with file includes though:
(1) I cannot specify a file's location relative to $ENV{'DOCUMENT_ROOT'}.
(2) I cannot specify a file's location relative to the directory the
current file is in.
For #1, I want to do something
On Sat, 20 May 2000, Joshua Chamas wrote:
!--#include virtual="/code/header.asp"--
!--#include virtual="/code/footer.asp"--
For #1, know includes will be picked up from your Global directory,
so you can use that repository to share includes, instead of some
DOCUMENT_ROOT location. You
| Well, I would like to suggest that you consider including !--#include
| virtual-- in the Apache::ASP distribution, so that included files use the
| same namespace. It doesn't make sense logically that include virtual
| behaves differently from include file (other than the way the
|
Hi!
I should migrate Perl-CGIs to mod_perl for performance reasons.
We use many subroutines in our CGIs, which read and write
global (my-defined) variables. Our plain subroutines are not nested,
but they are when the mod_perl wrapper is put around them at execution time.
In this special case
for such subroutines?
A good programming practice is to never let
a sub {} depend nor use any variables which are not explicitly
passed to it. If severel subs should have some kind of globally
used structures to work with, explicitly pass it by reference
to each sub. If you follow that basic rule, you
I'm seconding Ime's suggestion, and adding one piece, you don't have
to use anonymous subroutines for everything..., that would be.., well,
a big pain. Named subroutines where EVERYTHING it uses is passed in
via references. Also it's return values are sent back via reference
as well.
QUESTION: But how should I transform the script, if the
anonymous subs call each other?
Very simple little example:
#!/usr/bin/perl -w
use strict;
my $i = 0;
my $a;
my $b = sub { print "$i\n"; exit if $i++ = 10; $a };
$a = sub { print "$i\n"; exit if $i++ = 10; $b };
$a;
Does that
first time post here :)
I'm having a problem with some varibles changing mid-way thru the code and
then back again. I have a program called 'cr' in the mod_perl directory.
It's not a module, it's just a straight cgi script. It uses strict. Here's
a samepl of the code:
my
To: [EMAIL PROTECTED]
Subject: sticky variables...
first time post here :)
I'm having a problem with some varibles changing mid-way thru
the code and
then back again. I have a program called 'cr' in the mod_perl
directory.
It's not a module, it's just a straight cgi script. It uses
n it's own
namespace and Embperl cleans up all your variables after the request, it
isn't such a problem. It's more a problem of programming style. Anyway the
next release of Embperl (not the next beta, but one of the nexts), will
solve this proble
Hi,
this is a huge problem. I have a module written a module with a form
on it, and for some reason or another if one user fills out the form
and presses the submit button (doing its stuff), and then another
different user happens to access that same module to display the same
form at
Welcome to mod_perl! Since perl persists, your data may
stay around between requests ... try putting "use strict;"
at the top of your programs modules, and work through
those issues. Use 'my $var' when variables should be
localized... give the modperl guide a good couple reads to
the idea, please read:
http://perl.apache.org/guide/porting.html#Exposing_Apache_Registry_secret
http://perl.apache.org/guide/porting.html#Sometimes_it_Works_Sometimes_it
And remember: "mod_perl hates sloppy programmers and punishes them" :)
(hint: *all* variables should be *i
Hi all
I have asked this before, but I still haven't managed to shed any light
on it, so I was hoping that somebody might be able to shed some more
light.
(While you're about it, have a look at the site we have just launched :
http://www.orgasmicwines.com - mod_perl mysql based site.)
If I
101 - 200 of 200 matches
Mail list logo
