On Thu, 1 Jun 2000, Marc Lehmann wrote:
> It's easy, I just have to kick my ass each time I want to use a lexical
> for data abstraction and use a package variable instead, with only the
> exception that I have to be very careful that I never re-use the same
> name. This is quite difficult for cod
On Thu, Jun 01, 2000 at 11:59:53AM -0700, Doug MacEachern <[EMAIL PROTECTED]> wrote:
> 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
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
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 app
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 wa
Marc Lehmann wrote:
>
>
> However, you can't claim that mod_perl _is_ perl and at the same time
> claim that perfectly valid perl code is broken. Either it's broken code
> in the mod_perl dialect or it's valid code not working due to environment
> constraints.
>
this is definetly perl. it is
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). Bu
> -Original Message-
> From: Marc Lehmann [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, May 25, 2000 9:57 PM
> To: Doug MacEachern
> Cc: [EMAIL PROTECTED]
> Subject: Re: global variables and reparsing question (low priority ;)
>
>
> On Thu, May 25, 200
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
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
[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
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 'PerlFreshRe
> > 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 dif
> 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 Ap
On Tue, 23 May 2000, Marc Lehmann 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'
> It breaks perfectly valid perl code, cr
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:
> package othermodule;
> my $global = 5;
>
> sub set_global {
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
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).
[EMAIL PROTECTED] (Marc Lehmann) wrote:
>=
>package othermodule;
>
>my $global = 5;
>
>sub set_global {
> $global = shift;
>}
>=
>
>And use this
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 mod
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 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 p
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
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 pos
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. Fortuna
On Mon, May 22, 2000 at 11:24:10PM -0700, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> I don't quite understand what you're trying to do,
"compile normal perl code"
> but what you have here is a closure and it looks like you want a real
> global instead.
At leats in the example I sent in there
I don't quite understand what you're trying to do, but what you have
here is a closure and it looks like you want a real global instead.
(man perlref if "closure" doesn't ring a bell.) Some of your language
makes it look like you may have some confusion between global and
lexicals. At any rate,
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.
An
replace my $global with use vars qw($global); and your problem should
disappear.
At 05:40 AM 5/23/00 +0200, Marc Lehmann wrote:
>While I understand how my problem happens, it just caught me again
>(letting me debug another two hours), and so I wanted to ask why this
>peculiar behaviour is reall
28 matches
Mail list logo
