"RB" == Robin Berjon [EMAIL PROTECTED] writes:
RB At 13:24 08/02/2001 -0500, Vivek Khera wrote:
Ok... Upgrade to "Apache/1.3.17 (Unix) mod_perl/1.25_01-dev" fixed the
object destroy issue. Yay!
RB I'm glad your problem is soved, but does anyone have any idea what
RB triggered that problem ?
"PH" == Perrin Harkins [EMAIL PROTECTED] writes:
PH Okay, I just tried the code you posted under mod_perl and it worked fine.
PH I changed a couple of lines having to do with locations and package names,
Ok... Upgrade to "Apache/1.3.17 (Unix) mod_perl/1.25_01-dev" fixed the
object destroy
At 13:24 08/02/2001 -0500, Vivek Khera wrote:
Ok... Upgrade to "Apache/1.3.17 (Unix) mod_perl/1.25_01-dev" fixed the
object destroy issue. Yay!
Old versions were Apache 1.3.14 and mod_perl 1.24_02-dev.
Why that fixes it, I dunno. (Nor do I care at this point ;-)
I'm glad your problem is
"dc" == darren chamberlain [EMAIL PROTECTED] writes:
dc Vivek Khera ([EMAIL PROTECTED]) said something to this effect on 02/06/2001:
However, at the end of the template processing, the object is not
destroyed; that is, the DESTROY() method is never called, and
dc You aren't clear about the
"PH" == Perrin Harkins [EMAIL PROTECTED] writes:
PH Hmmm... If I'm reading the code correctly, what's supposed to happen is
PH that the stash (where your plugin instance lives) gets localized when you
PH call $tt-process() and de-localized at the end, which should result in
PH anything you
On Wed, 7 Feb 2001, Vivek Khera wrote:
Ok... here's a mini-plugin that exhibits this behavior, and a command
line script for it.
This all looks like it should work, and the plugin object should get
destroyed. Until someone finds the source of the problem, you could work
around it by keeping
"PH" == Perrin Harkins [EMAIL PROTECTED] writes:
PH On Wed, 7 Feb 2001, Vivek Khera wrote:
Ok... here's a mini-plugin that exhibits this behavior, and a command
line script for it.
PH This all looks like it should work, and the plugin object should get
PH destroyed. Until someone finds the
On Wed, 7 Feb 2001, Vivek Khera wrote:
Did you (or anyone else) reproduce the non-destroy of my mini-plugin?
I didn't actually run it; just poked through the code.
I'd like to at least know if I'm doing something wrong in mod_perl. I
find it disconcerting to have my plugin objects sitting
"PH" == Perrin Harkins [EMAIL PROTECTED] writes:
PH To find out if this is a mod_perl probelm or not, try makiing your command
PH line script call $tt-process twice in a row. If the object gets
PH destroyed twice, this is mod_perl-related. Otherwise, it's a TT
PH problem and officially [OT]
On Wed, 7 Feb 2001, Vivek Khera wrote:
Did you (or anyone else) reproduce the non-destroy of my mini-plugin?
I'd like to at least know if I'm doing something wrong in mod_perl. I
find it disconcerting to have my plugin objects sitting around unused
and unreaped, aka, memory leakage.
Okay, I
I sent this to the Template Toolkit list but got no responses. I'm
pretty sure it is a mod_perl issue, but I can't for the life of me
figure out why the object doesn't get destroyed in the mod_perl
context. A standalone test program always destroys the object at the
expected time.
This bug
Vivek Khera ([EMAIL PROTECTED]) said something to this effect on 02/06/2001:
However, at the end of the template processing, the object is not
destroyed; that is, the DESTROY() method is never called, and
therefore the tied hash never gets untied and Apache::Session::MySQL
doesn't get a
On Tue, 6 Feb 2001, Vivek Khera wrote:
However, at the end of the template processing, the object is not
destroyed; that is, the DESTROY() method is never called, and
therefore the tied hash never gets untied and Apache::Session::MySQL
doesn't get a chance to write the data back to the
On Tue, 6 Feb 2001, darren chamberlain wrote:
Vivek Khera ([EMAIL PROTECTED]) said something to this effect on 02/06/2001:
However, at the end of the template processing, the object is not
destroyed; that is, the DESTROY() method is never called, and
therefore the tied hash never gets
14 matches
Mail list logo
