Hi All,

I have looked high and low to work out how to avoid the 'Constant
subroutine redefined' warnings in the error log, followed by the
'Prototype missmatch:' error upon subsequent hits to the apache child
process - but, I have not been able to find an easy solution. The
warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
which attempts to reset/nullify everything - including constants. When a
constant is redefined it causes a warning in the error_log, and when the
constant gets reset upon the next run of the script the prototype doesnt
match as its reset incorrectly.

I found a message from Stass Beckman saying that you could use a
$SIG{__WARN__} handler to filter the warnings. This works for the
'Constant subroutine redefined' warnings, but not the 'Prototype
missmatch:' warnings (even thou I modified it to take both into
account), no matter where i add the $SIG{__WARN__} handler it never gets
called in the case of 'Prototype missmatch:' - not even when its defined
in the startup.pl

So I decided to work out a way to modify Apache::PerlRun so that it
did not redefine constants. There is no need to nullify constants as
they will not and CAN NOT change between child instances, and
documentation indicates that the 'Constant subroutine redefined' warning
means that the original value will be retained anyway (i.e. you cant
change a constants value).

Constants in perl are anonymous code references with a blank
prototype, that is how they are created within constant.pm here is a
snippet:

*{$fullname} =3D sub () { };

So if you had:

use constant TRUE =3D> 1;

it would become:

*{$fullname} =3D sub () { 1 };

where $fullname was main::TRUE

When a subroutine is defined with a prototype of '()' and it returns a
constant result when compiled, it becomes a 'constant subroutine'.
Hence, constants are meerly constant subroutines.

So now for the changes I made to PerlRun.pm, below is the original
code:


if (defined &$fullname) {
no warnings;
local $^W =3D 0;
if (defined(my $p =3D prototype $fullname)) {
*{$fullname} =3D eval "sub ($p) {}";
}
else {
*{$fullname} =3D sub {};
}
undef &$fullname;
}

So, this code would reset every subroutine to a blank anonymous
subroutine, using the correct (current) prototype. And then undefine it.

My patch:

if (defined &$fullname) {
no warnings;
local $^W =3D 0;
if (defined(my $p =3D prototype $fullname)) {
# We DONT want to redefine constant subroutines (sub ())
if ($p) {
*{$fullname} =3D eval "sub ($p) {}";
undef &$fullname;
}
}
else {
*{$fullname} =3D sub {};
undef &$fullname;
}
}

This code will reset every subroutine that does not have an empty
prototype and then undef it. So basically the 'sub () {}' defined
subroutines are not reset (but sub {} and sub ($) {} are reset).

Now, im aware this is not an ideal solution due to the fact that any
subroutines declared in a script with a () prototype will not be reset.
But on the flip side of the coin all constants will be left intact and
any warnings in the error log avoided. My question is, what caveats
would there be in not resetting a subroutine? I have ran some tests to
see how subroutines setup in this way would work and the tests appear to
be good.

For example:

print STDERR 'time_constant =3D '. &time_constant(). "\n";
sub time_constant () {
time. ' '. $$;
}

running under 'httpd -X'

would produce a different time each request, and the same process id.

as did..

my $time_constant =3D sub () { time. ' '. $$ };
print STDERR 'var time_constant =3D '. &{$time_constant}. "\n";


Sorry this email is a tad long, but its quite complicated to explain.

Cheers,


--
David Radunz,
Developer / Programmer

Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz [at] staff.netspace.net.au

This email and any files transmitted with it are confidential and =
intended solely for the
use of the individual or entity to whom they are addressed. Please =
notify the sender
immediately by email if you have received this email by mistake and =
delete this email
from your system. Please note that any views or opinions presented in =
this email are solely
those of the author and do not necessarily represent those of the =
organisation.
Finally, the recipient should check this email and any attachments for =
the presence of
viruses. The organisation accepts no liability for any damage caused by =
any virus
transmitted by this email.


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Also forgot to mention, this is running:

mod_perl 1.29
perl 5.8.4
apache 1.3.27

and ..

SunOS *** 5.9 Generic_112234-08 i86pc i386 i86pc

Cheers


On Mon, 2004-10-04 at 16:15, David Radunz wrote:
> Hi All,
>
> I have looked high and low to work out how to avoid the 'Constant
> subroutine redefined' warnings in the error log, followed by the
> 'Prototype missmatch:' error upon subsequent hits to the apache child
> process - but, I have not been able to find an easy solution. The
> warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
> which attempts to reset/nullify everything - including constants. When a
> constant is redefined it causes a warning in the error_log, and when the
> constant gets reset upon the next run of the script the prototype doesnt
> match as its reset incorrectly.
>
> I found a message from Stass Beckman saying that you could use a
> $SIG{__WARN__} handler to filter the warnings. This works for the
> 'Constant subroutine redefined' warnings, but not the 'Prototype
> missmatch:' warnings (even thou I modified it to take both into
> account), no matter where i add the $SIG{__WARN__} handler it never gets
> called in the case of 'Prototype missmatch:' - not even when its defined
> in the startup.pl
>
> So I decided to work out a way to modify Apache::PerlRun so that it
> did not redefine constants. There is no need to nullify constants as
> they will not and CAN NOT change between child instances, and
> documentation indicates that the 'Constant subroutine redefined' warning
> means that the original value will be retained anyway (i.e. you cant
> change a constants value).
>
> Constants in perl are anonymous code references with a blank
> prototype, that is how they are created within constant.pm here is a
> snippet:
>
> *{$fullname} = sub () { };
>
> So if you had:
>
> use constant TRUE => 1;
>
> it would become:
>
> *{$fullname} = sub () { 1 };
>
> where $fullname was main::TRUE
>
> When a subroutine is defined with a prototype of '()' and it returns a
> constant result when compiled, it becomes a 'constant subroutine'.
> Hence, constants are meerly constant subroutines.
>
> So now for the changes I made to PerlRun.pm, below is the original
> code:
>
>
> if (defined &$fullname) {
> no warnings;
> local $^W = 0;
> if (defined(my $p = prototype $fullname)) {
> *{$fullname} = eval "sub ($p) {}";
> }
> else {
> *{$fullname} = sub {};
> }
> undef &$fullname;
> }
>
> So, this code would reset every subroutine to a blank anonymous
> subroutine, using the correct (current) prototype. And then undefine it.
>
> My patch:
>
> if (defined &$fullname) {
> no warnings;
> local $^W = 0;
> if (defined(my $p = prototype $fullname)) {
> # We DONT want to redefine constant subroutines (sub ())
> if ($p) {
> *{$fullname} = eval "sub ($p) {}";
> undef &$fullname;
> }
> }
> else {
> *{$fullname} = sub {};
> undef &$fullname;
> }
> }
>
> This code will reset every subroutine that does not have an empty
> prototype and then undef it. So basically the 'sub () {}' defined
> subroutines are not reset (but sub {} and sub ($) {} are reset).
>
> Now, im aware this is not an ideal solution due to the fact that any
> subroutines declared in a script with a () prototype will not be reset.
> But on the flip side of the coin all constants will be left intact and
> any warnings in the error log avoided. My question is, what caveats
> would there be in not resetting a subroutine? I have ran some tests to
> see how subroutines setup in this way would work and the tests appear to
> be good.
>
> For example:
>
> print STDERR 'time_constant = '. &time_constant(). "\n";
> sub time_constant () {
> time. ' '. $$;
> }
>
> running under 'httpd -X'
>
> would produce a different time each request, and the same process id.
>
> as did..
>
> my $time_constant = sub () { time. ' '. $$ };
> print STDERR 'var time_constant = '. &{$time_constant}. "\n";
>
>
> Sorry this email is a tad long, but its quite complicated to explain.
>
> Cheers,
>
>
> --
> David Radunz,
> Developer / Programmer
>
> Netspace Online Systems Pty Ltd
> Ground Floor, 293 Camberwell Road
> Camberwell, Victoria 3124
> Ph: +613 9811 0087
> Fx: +613 9811 0044
> Mo: +614 0549 9719
> Em: david.radunz [at] staff.netspace.net.au
>
> This email and any files transmitted with it are confidential and intended solely for the
> use of the individual or entity to whom they are addressed. Please notify the sender
> immediately by email if you have received this email by mistake and delete this email
> from your system. Please note that any views or opinions presented in this email are solely
> those of the author and do not necessarily represent those of the organisation.
> Finally, the recipient should check this email and any attachments for the presence of
> viruses. The organisation accepts no liability for any damage caused by any virus
> transmitted by this email.
--
David Radunz,
Developer / Programmer

Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz [at] staff.netspace.net.au

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

On Mon, 2004-10-04 at 08:15, David Radunz wrote:
> My patch:

This looks like a good idea to me. I'd say we should put it in.

> For example:
>
> print STDERR 'time_constant = '. &time_constant(). "\n";
> sub time_constant () {
> time. ' '. $$;
> }
>
> running under 'httpd -X'
>
> would produce a different time each request, and the same process id.

That's okay, since it would give a different time under CGI as well.

My advice in general is that you just shouldn't use constants in Perl.
The subroutine thing is kind of a hack, and the confusing problems with
stringification are not worth the performance boost. Just use package
variables instead. This doesn't work so well for running other people's
code though.

- Perrin


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Your quite right about constants in perl - they are a big hack. I could
have used the internals of constant.pm to determine for sure if
something was a constant (see: TECHNICAL NOTES documentation of the
constant man page). However, that doesnt work when using imported
(Exporter) constants because they arent setup using constant.pm, rather
pointers set to the reference of the parent package. So this is the only
way I can think of.

Thanks for your feedback

On Tue, 2004-10-05 at 03:29, Perrin Harkins wrote:
> On Mon, 2004-10-04 at 08:15, David Radunz wrote:
> > My patch:
>
> This looks like a good idea to me. I'd say we should put it in.
>
> > For example:
> >
> > print STDERR 'time_constant =3D '. &time_constant(). "\n";
> > sub time_constant () {
> > time. ' '. $$;
> > }
> >
> > running under 'httpd -X'
> >
> > would produce a different time each request, and the same process =
id.
>
> That's okay, since it would give a different time under CGI as well.
>
> My advice in general is that you just shouldn't use constants in Perl. =

> The subroutine thing is kind of a hack, and the confusing problems =
with
> stringification are not worth the performance boost. Just use package
> variables instead. This doesn't work so well for running other =
people's
> code though.
>
> - Perrin
--
David Radunz,
Developer / Programmer

Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz [at] staff.netspace.net.au

This email and any files transmitted with it are confidential and =
intended solely for the
use of the individual or entity to whom they are addressed. Please =
notify the sender
immediately by email if you have received this email by mistake and =
delete this email
from your system. Please note that any views or opinions presented in =
this email are solely
those of the author and do not necessarily represent those of the =
organisation.
Finally, the recipient should check this email and any attachments for =
the presence of
viruses. The organisation accepts no liability for any damage caused by =
any virus
transmitted by this email.


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

David Radunz wrote:
> Hi All,
>
> I have looked high and low to work out how to avoid the 'Constant
> subroutine redefined' warnings in the error log, followed by the
> 'Prototype missmatch:' error upon subsequent hits to the apache child
> process - but, I have not been able to find an easy solution. The
> warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
> which attempts to reset/nullify everything - including constants. When a
> constant is redefined it causes a warning in the error_log, and when the
> constant gets reset upon the next run of the script the prototype doesnt
> match as its reset incorrectly.

David, take a look at the ModPerl::PerlRun which now
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-Regist ry/lib/ModPerl/RegistryCooker.pm?r1=1.50&r2=1.51&diff_format =h
uses:
http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_unlo ad_package_
which Philippe has just added recently. (you will need the current mp2 cvs
to see it at works). It solves all these problems in a much cleaner way.
It's still too new to new to be sure that it doesn't have side-effects,
but once it's proved to be good by users, we can just port it back to mp1.

If you want to look at the C code that does that, it's
modperl_package_unload in:
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/pe rl/modperl_util.c?view=markup

--
____________________________________________________________ ______
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas [at] stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Heya Stas,

I like that alot, as you say heaps cleaner. For the time being thou
can you see any problems with us using my patch internally? I have run a
few more tests and it seems everything still works pretty good. And of
course keeping an eye out for Apache::RegistryCooker.. or will it be
ported under Apache::PerlRun?

Cheers

On Tue, 2004-10-05 at 11:34, Stas Bekman wrote:
> David Radunz wrote:
> > Hi All,
> >
> > I have looked high and low to work out how to avoid the 'Constant
> > subroutine redefined' warnings in the error log, followed by the
> > 'Prototype missmatch:' error upon subsequent hits to the apache =
child
> > process - but, I have not been able to find an easy solution. The
> > warnings are caused by the 'flush_namespace' routine of =
Apache::PerlRun
> > which attempts to reset/nullify everything - including constants. =
When a
> > constant is redefined it causes a warning in the error_log, and when =
the
> > constant gets reset upon the next run of the script the prototype =
doesnt
> > match as its reset incorrectly.
>
> David, take a look at the ModPerl::PerlRun which now
> =
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-Regist ry/lib/ModPer=
l/RegistryCooker.pm?r1=3D1.50&r2=3D1.51&diff_format=3Dh
> uses:
> =
http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_unlo ad_package_
> which Philippe has just added recently. (you will need the current mp2 =
cvs
> to see it at works). It solves all these problems in a much cleaner =
way.
> It's still too new to new to be sure that it doesn't have =
side-effects,
> but once it's proved to be good by users, we can just port it back to =
mp1.
>
> If you want to look at the C code that does that, it's
> modperl_package_unload in:
> =
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/pe rl/modperl_ut=
il.c?view=3Dmarkup
--
David Radunz,
Developer / Programmer

Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz [at] staff.netspace.net.au

This email and any files transmitted with it are confidential and =
intended solely for the
use of the individual or entity to whom they are addressed. Please =
notify the sender
immediately by email if you have received this email by mistake and =
delete this email
from your system. Please note that any views or opinions presented in =
this email are solely
those of the author and do not necessarily represent those of the =
organisation.
Finally, the recipient should check this email and any attachments for =
the presence of
viruses. The organisation accepts no liability for any damage caused by =
any virus
transmitted by this email.


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

David Radunz wrote:
> Heya Stas,
>
> I like that alot, as you say heaps cleaner. For the time being thou
> can you see any problems with us using my patch internally?

Looks fine to me.

> I have run a
> few more tests and it seems everything still works pretty good. And of
> course keeping an eye out for Apache::RegistryCooker.. or will it be
> ported under Apache::PerlRun?

Ported under PerlRun.

You are more than welcome to do the porting to mp1. It shouldn't be too
much work, since the C code should be pretty much copy-n-paste. At the
moment we just don't want to touch mp1 and potentially break stable
things. So we would like to have that new implementation (courtesy of
Philippe Chiasson) to be thoroughly tested by users first.

p.s. please don't CC your posts to other address at your domain since it
bounces.

--
____________________________________________________________ ______
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas [at] stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

On Tue, 2004-10-05 at 12:39, Stas Bekman wrote:
> David Radunz wrote:
> > Heya Stas,
> >
> > I like that alot, as you say heaps cleaner. For the time being =
thou
> > can you see any problems with us using my patch internally?
>
> Looks fine to me.
>

Thanks, we'll put it into production.

> > I have run a
> > few more tests and it seems everything still works pretty good. And =
of
> > course keeping an eye out for Apache::RegistryCooker.. or will it be
> > ported under Apache::PerlRun?
>
> Ported under PerlRun.
>
> You are more than welcome to do the porting to mp1. It shouldn't be =
too
> much work, since the C code should be pretty much copy-n-paste. At the =

> moment we just don't want to touch mp1 and potentially break stable
> things. So we would like to have that new implementation (courtesy of
> Philippe Chiasson) to be thoroughly tested by users first.
>

I would love to, but I dont really know much C. If its just copying and
pasting then I guess it wouldnt be that bad, did you mean make a new
Apache::* module, say Apache::ModPerlUtil (since Apache::Util is used)
and then modify Apache::PerlRun to use that?

> p.s. please don't CC your posts to other address at your domain since =
it
> bounces.

Sorry - I didnt know that the internal mailing lists didnt allow
external emails.

Thanks

--
David Radunz,
Developer / Programmer

Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz [at] staff.netspace.net.au

This email and any files transmitted with it are confidential and =
intended solely for the
use of the individual or entity to whom they are addressed. Please =
notify the sender
immediately by email if you have received this email by mistake and =
delete this email
from your system. Please note that any views or opinions presented in =
this email are solely
those of the author and do not necessarily represent those of the =
organisation.
Finally, the recipient should check this email and any attachments for =
the presence of
viruses. The organisation accepts no liability for any damage caused by =
any virus
transmitted by this email.


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

David Radunz wrote:
> On Tue, 2004-10-05 at 12:39, Stas Bekman wrote:
>
>>David Radunz wrote:
>>
>>>Heya Stas,
>>>
>>> I like that alot, as you say heaps cleaner. For the time being thou
>>>can you see any problems with us using my patch internally?
>>
>>Looks fine to me.
>>
>
>
> Thanks, we'll put it into production.

Hmm. Well, I said that it looks fine, but you probably want to test it by
yourself to ensure that it works well. I certainly can't guarantee that.

>>>I have run a
>>>few more tests and it seems everything still works pretty good. And of
>>>course keeping an eye out for Apache::RegistryCooker.. or will it be
>>>ported under Apache::PerlRun?
>>
>>Ported under PerlRun.
>>
>>You are more than welcome to do the porting to mp1. It shouldn't be too
>>much work, since the C code should be pretty much copy-n-paste. At the
>>moment we just don't want to touch mp1 and potentially break stable
>>things. So we would like to have that new implementation (courtesy of
>>Philippe Chiasson) to be thoroughly tested by users first.
>>
>
>
> I would love to, but I dont really know much C. If its just copying and
> pasting then I guess it wouldnt be that bad, did you mean make a new
> Apache::* module, say Apache::ModPerlUtil (since Apache::Util is used)
> and then modify Apache::PerlRun to use that?

More or less yes. But let's just wait and see how the mp2 solution scores
first.

--
____________________________________________________________ ______
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas [at] stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

--------------enigAA48A4F7944E93FDB8E85506
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stas Bekman wrote:

> David Radunz wrote:
>
>> Hi All,
>>
>> I have looked high and low to work out how to avoid the 'Constant
>> subroutine redefined' warnings in the error log, followed by the
>> 'Prototype missmatch:' error upon subsequent hits to the apache child
>> process - but, I have not been able to find an easy solution. The
>> warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
>> which attempts to reset/nullify everything - including constants. When a
>> constant is redefined it causes a warning in the error_log, and when the
>> constant gets reset upon the next run of the script the prototype doesnt
>> match as its reset incorrectly.
>
>
> David, take a look at the ModPerl::PerlRun which now
> http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-Regist ry/lib/ModPerl/RegistryCooker.pm?r1=1.50&r2=1.51&diff_format =h
>
> uses:
> http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_unlo ad_package_
> which Philippe has just added recently. (you will need the current mp2
> cvs to see it at works). It solves all these problems in a much
> cleaner way. It's still too new to new to be sure that it doesn't have
> side-effects, but once it's proved to be good by users, we can just
> port it back to mp1.

It's also available as a yet to be released on CPAN module
(Devel::Unload) here: http://svn.ectoplasm.org/projects/perl/Devel-Unload/

You might just try installing Devel::Unload and plugging it into
PerlRun.pm and see if it works

(untested patch)

Index: lib/Apache/PerlRun.pm
============================================================ =======
RCS file: /home/cvs/modperl/lib/Apache/PerlRun.pm,v
retrieving revision 1.41
diff -u -I$Id -r1.41 PerlRun.pm
--- lib/Apache/PerlRun.pm 8 Mar 2003 04:11:09 -0000 1.41
+++ lib/Apache/PerlRun.pm 8 Oct 2004 23:08:02 -0000
[at] [at] -118,6 +118,8 [at] [at]
$_r->clear_rgy_endav;
$_r->log_error("Apache::PerlRun->compile") if $Debug && $Debug & 4;
Apache->untaint($$eval);
+ use Devel::Unload;
+ Devel::Unload::unload_package_xs($pr->namespace);
{
no strict; #so eval'd code doesn't inherit our bits
eval $$eval;

> If you want to look at the C code that does that, it's
> modperl_package_unload in:
> http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/pe rl/modperl_util.c?view=markup
>
>


--------------enigAA48A4F7944E93FDB8E85506
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBZx3tyzKhB4jDpaURAm4hAKCik9UhkvdNZpO4/6PR/+w8ihsZaACf SQZG
M3yUkVfajrIh+U2iHm6LMYc=
=zKNg
-----END PGP SIGNATURE-----

--------------enigAA48A4F7944E93FDB8E85506--

Hey,

Thanks for your help. I tried using Devel::Unload to see how it works
and encountered something unexpected. Basically I put the
'unload_package_xs' call just above the 'flush_namespace' call. Then I
printed from within the namespace clearing loop (expecting nothing to be
printed), yet something did get printed..

Flushing
Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_ 2dpr::charges=
page_2ecgi::qs
Flushing
Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_ 2dpr::payment=
spage_2ecgi::qs
Flushing
Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_ 2dpr::homeads=
lclientpage_2ecgi::qs

Which isnt that bad, because the rest of the namespace had been cleared,
except this lonley scalar - I printed it to see if it contained anything
and got the following:

Scalar =3D SELECT DECODE.... (i wont paste the whole scalar here, its
basically a huge SQL statement, about 2000 characters).

Perhaps the scalar was too big to be cleared?

Cheers,

DJ


On Sat, 2004-10-09 at 09:08, Philippe M. Chiasson wrote:
> Stas Bekman wrote:
>
> > David Radunz wrote:
> >
> >> Hi All,
> >>
> >> I have looked high and low to work out how to avoid the 'Constant
> >> subroutine redefined' warnings in the error log, followed by the
> >> 'Prototype missmatch:' error upon subsequent hits to the apache =
child
> >> process - but, I have not been able to find an easy solution. The
> >> warnings are caused by the 'flush_namespace' routine of =
Apache::PerlRun
> >> which attempts to reset/nullify everything - including constants. =
When a
> >> constant is redefined it causes a warning in the error_log, and =
when the
> >> constant gets reset upon the next run of the script the prototype =
doesnt
> >> match as its reset incorrectly.
> >
> >
> > David, take a look at the ModPerl::PerlRun which now
> > =
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-Regist ry/lib/ModPer=
l/RegistryCooker.pm?r1=3D1.50&r2=3D1.51&diff_format=3Dh
> >
> > uses:
> > =
http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_unlo ad_package_
> > which Philippe has just added recently. (you will need the current =
mp2
> > cvs to see it at works). It solves all these problems in a much
> > cleaner way. It's still too new to new to be sure that it doesn't =
have
> > side-effects, but once it's proved to be good by users, we can just
> > port it back to mp1.
>
> It's also available as a yet to be released on CPAN module
> (Devel::Unload) here: =
http://svn.ectoplasm.org/projects/perl/Devel-Unload/
>
> You might just try installing Devel::Unload and plugging it into
> PerlRun.pm and see if it works
>
> (untested patch)
>
> Index: lib/Apache/PerlRun.pm
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> RCS file: /home/cvs/modperl/lib/Apache/PerlRun.pm,v
> retrieving revision 1.41
> diff -u -I$Id -r1.41 PerlRun.pm
> --- lib/Apache/PerlRun.pm 8 Mar 2003 04:11:09 -0000 1.41
> +++ lib/Apache/PerlRun.pm 8 Oct 2004 23:08:02 -0000
> [at] [at] -118,6 +118,8 [at] [at]
> $_r->clear_rgy_endav;
> $_r->log_error("Apache::PerlRun->compile") if $Debug && $Debug & =
4;
> Apache->untaint($$eval);
> + use Devel::Unload;
> + Devel::Unload::unload_package_xs($pr->namespace);
> {
> no strict; #so eval'd code doesn't inherit our bits
> eval $$eval;
>
> > If you want to look at the C code that does that, it's
> > modperl_package_unload in:
> > =
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/pe rl/modperl_ut=
il.c?view=3Dmarkup
> >
> >
--
David Radunz,
Developer / Programmer

Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz [at] staff.netspace.net.au

This email and any files transmitted with it are confidential and =
intended solely for the
use of the individual or entity to whom they are addressed. Please =
notify the sender
immediately by email if you have received this email by mistake and =
delete this email
from your system. Please note that any views or opinions presented in =
this email are solely
those of the author and do not necessarily represent those of the =
organisation.
Finally, the recipient should check this email and any attachments for =
the presence of
viruses. The organisation accepts no liability for any damage caused by =
any virus
transmitted by this email.


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Further to that - I just tested with an even bigger string and this one
did get cleared fine, so it musnt be the size :(

Not sure what the problem is,

DJ

On Mon, 2004-10-11 at 12:13, David Radunz wrote:
> Hey,
>
> Thanks for your help. I tried using Devel::Unload to see how it works
> and encountered something unexpected. Basically I put the
> 'unload_package_xs' call just above the 'flush_namespace' call. Then I
> printed from within the namespace clearing loop (expecting nothing to be
> printed), yet something did get printed..
>
> Flushing
> Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_ 2dpr::chargespage_2ecgi::qs
> Flushing
> Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_ 2dpr::paymentspage_2ecgi::qs
> Flushing
> Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_ 2dpr::homeadslclientpage_2ecgi::qs
>
> Which isnt that bad, because the rest of the namespace had been cleared,
> except this lonley scalar - I printed it to see if it contained anything
> and got the following:
>
> Scalar = SELECT DECODE.... (i wont paste the whole scalar here, its
> basically a huge SQL statement, about 2000 characters).
>
> Perhaps the scalar was too big to be cleared?
>
> Cheers,
>
> DJ
>
>
> On Sat, 2004-10-09 at 09:08, Philippe M. Chiasson wrote:
> > Stas Bekman wrote:
> >
> > > David Radunz wrote:
> > >
> > >> Hi All,
> > >>
> > >> I have looked high and low to work out how to avoid the 'Constant
> > >> subroutine redefined' warnings in the error log, followed by the
> > >> 'Prototype missmatch:' error upon subsequent hits to the apache child
> > >> process - but, I have not been able to find an easy solution. The
> > >> warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
> > >> which attempts to reset/nullify everything - including constants. When a
> > >> constant is redefined it causes a warning in the error_log, and when the
> > >> constant gets reset upon the next run of the script the prototype doesnt
> > >> match as its reset incorrectly.
> > >
> > >
> > > David, take a look at the ModPerl::PerlRun which now
> > > http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-Regist ry/lib/ModPerl/RegistryCooker.pm?r1=1.50&r2=1.51&diff_format =h
> > >
> > > uses:
> > > http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_unlo ad_package_
> > > which Philippe has just added recently. (you will need the current mp2
> > > cvs to see it at works). It solves all these problems in a much
> > > cleaner way. It's still too new to new to be sure that it doesn't have
> > > side-effects, but once it's proved to be good by users, we can just
> > > port it back to mp1.
> >
> > It's also available as a yet to be released on CPAN module
> > (Devel::Unload) here: http://svn.ectoplasm.org/projects/perl/Devel-Unload/
> >
> > You might just try installing Devel::Unload and plugging it into
> > PerlRun.pm and see if it works
> >
> > (untested patch)
> >
> > Index: lib/Apache/PerlRun.pm
> > ============================================================ =======
> > RCS file: /home/cvs/modperl/lib/Apache/PerlRun.pm,v
> > retrieving revision 1.41
> > diff -u -I$Id -r1.41 PerlRun.pm
> > --- lib/Apache/PerlRun.pm 8 Mar 2003 04:11:09 -0000 1.41
> > +++ lib/Apache/PerlRun.pm 8 Oct 2004 23:08:02 -0000
> > [at] [at] -118,6 +118,8 [at] [at]
> > $_r->clear_rgy_endav;
> > $_r->log_error("Apache::PerlRun->compile") if $Debug && $Debug & 4;
> > Apache->untaint($$eval);
> > + use Devel::Unload;
> > + Devel::Unload::unload_package_xs($pr->namespace);
> > {
> > no strict; #so eval'd code doesn't inherit our bits
> > eval $$eval;
> >
> > > If you want to look at the C code that does that, it's
> > > modperl_package_unload in:
> > > http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/pe rl/modperl_util.c?view=markup
> > >
> > >
> --
> David Radunz,
> Developer / Programmer
>
> Netspace Online Systems Pty Ltd
> Ground Floor, 293 Camberwell Road
> Camberwell, Victoria 3124
> Ph: +613 9811 0087
> Fx: +613 9811 0044
> Mo: +614 0549 9719
> Em: david.radunz [at] staff.netspace.net.au
>
> This email and any files transmitted with it are confidential and intended solely for the
> use of the individual or entity to whom they are addressed. Please notify the sender
> immediately by email if you have received this email by mistake and delete this email
> from your system. Please note that any views or opinions presented in this email are solely
> those of the author and do not necessarily represent those of the organisation.
> Finally, the recipient should check this email and any attachments for the presence of
> viruses. The organisation accepts no liability for any damage caused by any virus
> transmitted by this email.
--
David Radunz,
Developer / Programmer

Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz [at] staff.netspace.net.au

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Philippe I know your buisy with mod_perl 2 stuff at the moment, but I
hope you get a chance to look at this when your free - unless the author
of the code is someone else and you just recommended it?

Anyway, Let me know.

David

On Mon, 2004-10-11 at 12:25, David Radunz wrote:
> Further to that - I just tested with an even bigger string and this one
> did get cleared fine, so it musnt be the size :(
>
> Not sure what the problem is,
>
> DJ
>
> On Mon, 2004-10-11 at 12:13, David Radunz wrote:
> > Hey,
> >
> > Thanks for your help. I tried using Devel::Unload to see how it works
> > and encountered something unexpected. Basically I put the
> > 'unload_package_xs' call just above the 'flush_namespace' call. Then I
> > printed from within the namespace clearing loop (expecting nothing to be
> > printed), yet something did get printed..
> >
> > Flushing
> > Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_ 2dpr::chargespage_2ecgi::qs
> > Flushing
> > Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_ 2dpr::paymentspage_2ecgi::qs
> > Flushing
> > Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_ 2dpr::homeadslclientpage_2ecgi::qs
> >
> > Which isnt that bad, because the rest of the namespace had been cleared,
> > except this lonley scalar - I printed it to see if it contained anything
> > and got the following:
> >
> > Scalar = SELECT DECODE.... (i wont paste the whole scalar here, its
> > basically a huge SQL statement, about 2000 characters).
> >
> > Perhaps the scalar was too big to be cleared?
> >
> > Cheers,
> >
> > DJ
> >
> >
> > On Sat, 2004-10-09 at 09:08, Philippe M. Chiasson wrote:
> > > Stas Bekman wrote:
> > >
> > > > David Radunz wrote:
> > > >
> > > >> Hi All,
> > > >>
> > > >> I have looked high and low to work out how to avoid the 'Constant
> > > >> subroutine redefined' warnings in the error log, followed by the
> > > >> 'Prototype missmatch:' error upon subsequent hits to the apache child
> > > >> process - but, I have not been able to find an easy solution. The
> > > >> warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
> > > >> which attempts to reset/nullify everything - including constants. When a
> > > >> constant is redefined it causes a warning in the error_log, and when the
> > > >> constant gets reset upon the next run of the script the prototype doesnt
> > > >> match as its reset incorrectly.
> > > >
> > > >
> > > > David, take a look at the ModPerl::PerlRun which now
> > > > http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-Regist ry/lib/ModPerl/RegistryCooker.pm?r1=1.50&r2=1.51&diff_format =h
> > > >
> > > > uses:
> > > > http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_unlo ad_package_
> > > > which Philippe has just added recently. (you will need the current mp2
> > > > cvs to see it at works). It solves all these problems in a much
> > > > cleaner way. It's still too new to new to be sure that it doesn't have
> > > > side-effects, but once it's proved to be good by users, we can just
> > > > port it back to mp1.
> > >
> > > It's also available as a yet to be released on CPAN module
> > > (Devel::Unload) here: http://svn.ectoplasm.org/projects/perl/Devel-Unload/
> > >
> > > You might just try installing Devel::Unload and plugging it into
> > > PerlRun.pm and see if it works
> > >
> > > (untested patch)
> > >
> > > Index: lib/Apache/PerlRun.pm
> > > ============================================================ =======
> > > RCS file: /home/cvs/modperl/lib/Apache/PerlRun.pm,v
> > > retrieving revision 1.41
> > > diff -u -I$Id -r1.41 PerlRun.pm
> > > --- lib/Apache/PerlRun.pm 8 Mar 2003 04:11:09 -0000 1.41
> > > +++ lib/Apache/PerlRun.pm 8 Oct 2004 23:08:02 -0000
> > > [at] [at] -118,6 +118,8 [at] [at]
> > > $_r->clear_rgy_endav;
> > > $_r->log_error("Apache::PerlRun->compile") if $Debug && $Debug & 4;
> > > Apache->untaint($$eval);
> > > + use Devel::Unload;
> > > + Devel::Unload::unload_package_xs($pr->namespace);
> > > {
> > > no strict; #so eval'd code doesn't inherit our bits
> > > eval $$eval;
> > >
> > > > If you want to look at the C code that does that, it's
> > > > modperl_package_unload in:
> > > > http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/pe rl/modperl_util.c?view=markup
> > > >
> > > >
> > --
> > David Radunz,
> > Developer / Programmer
> >
> > Netspace Online Systems Pty Ltd
> > Ground Floor, 293 Camberwell Road
> > Camberwell, Victoria 3124
> > Ph: +613 9811 0087
> > Fx: +613 9811 0044
> > Mo: +614 0549 9719
> > Em: david.radunz [at] staff.netspace.net.au
> >
> > This email and any files transmitted with it are confidential and intended solely for the
> > use of the individual or entity to whom they are addressed. Please notify the sender
> > immediately by email if you have received this email by mistake and delete this email
> > from your system. Please note that any views or opinions presented in this email are solely
> > those of the author and do not necessarily represent those of the organisation.
> > Finally, the recipient should check this email and any attachments for the presence of
> > viruses. The organisation accepts no liability for any damage caused by any virus
> > transmitted by this email.
> --
> David Radunz,
> Developer / Programmer
>
> Netspace Online Systems Pty Ltd
> Ground Floor, 293 Camberwell Road
> Camberwell, Victoria 3124
> Ph: +613 9811 0087
> Fx: +613 9811 0044
> Mo: +614 0549 9719
> Em: david.radunz [at] staff.netspace.net.au
--
David Radunz,
Developer / Programmer

Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz [at] staff.netspace.net.au

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

--------------enigD1293E945159E55316F343C2
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David Radunz wrote:

>Philippe I know your buisy with mod_perl 2 stuff at the moment, but I
>hope you get a chance to look at this when your free - unless the author
>of the code is someone else and you just recommended it?
>
>
Oh, no, I am the author of this code, and I am indeed busy with mod_perl
2 stuff, but
that's not a good reason for having waited so long to follow up on this
issue.

I think that you have just uncovered a small bug in the unload_package()
implementation
and I'd like to know exactly how you've reproduced this. After looking
over code, it is
now clear to me that any namespace entry that has a name <= 2 characters
long (e.g 'qs')
will not be deleted. That's a bug, and I expect to have it fixed both in
mp2 and in Devel::Unload
soon.

I'll let you know when there is another version of Devel::Unload you can
try out. In the meantime,
could you please give me more information about how you have tested
this, since the size of the
string doesn't matter AFAIK.

Thanks!

>Anyway, Let me know.
>
>David
>
>On Mon, 2004-10-11 at 12:25, David Radunz wrote:
>
>
>>Further to that - I just tested with an even bigger string and this one
>>did get cleared fine, so it musnt be the size :(
>>
>>Not sure what the problem is,
>>
>>DJ
>>
>>On Mon, 2004-10-11 at 12:13, David Radunz wrote:
>>
>>
>>>Hey,
>>>
>>> Thanks for your help. I tried using Devel::Unload to see how it works
>>>and encountered something unexpected. Basically I put the
>>>'unload_package_xs' call just above the 'flush_namespace' call. Then I
>>>printed from within the namespace clearing loop (expecting nothing to be
>>>printed), yet something did get printed..
>>>
>>>Flushing
>>>Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2din fo_2dpr::chargespage_2ecgi::qs
>>>Flushing
>>>Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2din fo_2dpr::paymentspage_2ecgi::qs
>>>Flushing
>>>Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2din fo_2dpr::homeadslclientpage_2ecgi::qs
>>>
>>>Which isnt that bad, because the rest of the namespace had been cleared,
>>>except this lonley scalar - I printed it to see if it contained anything
>>>and got the following:
>>>
>>> Scalar = SELECT DECODE.... (i wont paste the whole scalar here, its
>>>basically a huge SQL statement, about 2000 characters).
>>>
>>>Perhaps the scalar was too big to be cleared?
>>>
>>>Cheers,
>>>
>>>DJ
>>>
>>>
>>>On Sat, 2004-10-09 at 09:08, Philippe M. Chiasson wrote:
>>>
>>>
>>>>Stas Bekman wrote:
>>>>
>>>>
>>>>
>>>>>David Radunz wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi All,
>>>>>>
>>>>>> I have looked high and low to work out how to avoid the 'Constant
>>>>>>subroutine redefined' warnings in the error log, followed by the
>>>>>>'Prototype missmatch:' error upon subsequent hits to the apache child
>>>>>>process - but, I have not been able to find an easy solution. The
>>>>>>warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
>>>>>>which attempts to reset/nullify everything - including constants. When a
>>>>>>constant is redefined it causes a warning in the error_log, and when the
>>>>>>constant gets reset upon the next run of the script the prototype doesnt
>>>>>>match as its reset incorrectly.
>>>>>>
>>>>>>
>>>>>David, take a look at the ModPerl::PerlRun which now
>>>>>http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-R egistry/lib/ModPerl/RegistryCooker.pm?r1=1.50&r2=1.51&diff_f ormat=h
>>>>>
>>>>>uses:
>>>>>http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C _unload_package_
>>>>>which Philippe has just added recently. (you will need the current mp2
>>>>>cvs to see it at works). It solves all these problems in a much
>>>>>cleaner way. It's still too new to new to be sure that it doesn't have
>>>>>side-effects, but once it's proved to be good by users, we can just
>>>>>port it back to mp1.
>>>>>
>>>>>
>>>>It's also available as a yet to be released on CPAN module
>>>>(Devel::Unload) here: http://svn.ectoplasm.org/projects/perl/Devel-Unload/
>>>>
>>>>You might just try installing Devel::Unload and plugging it into
>>>>PerlRun.pm and see if it works
>>>>
>>>>(untested patch)
>>>>
>>>>Index: lib/Apache/PerlRun.pm
>>>>======================================================== ===========
>>>>RCS file: /home/cvs/modperl/lib/Apache/PerlRun.pm,v
>>>>retrieving revision 1.41
>>>>diff -u -I$Id -r1.41 PerlRun.pm
>>>>--- lib/Apache/PerlRun.pm 8 Mar 2003 04:11:09 -0000 1.41
>>>>+++ lib/Apache/PerlRun.pm 8 Oct 2004 23:08:02 -0000
>>>> [at] [at] -118,6 +118,8 [at] [at]
>>>> $_r->clear_rgy_endav;
>>>> $_r->log_error("Apache::PerlRun->compile") if $Debug && $Debug & 4;
>>>> Apache->untaint($$eval);
>>>>+ use Devel::Unload;
>>>>+ Devel::Unload::unload_package_xs($pr->namespace);
>>>> {
>>>> no strict; #so eval'd code doesn't inherit our bits
>>>> eval $$eval;
>>>>
>>>>
>>>>
>>>>>If you want to look at the C code that does that, it's
>>>>>modperl_package_unload in:
>>>>>http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modul es/perl/modperl_util.c?view=markup
>>>>>
>>>>>
>>>>>
>>>>>
>>>--
>>>David Radunz,
>>>Developer / Programmer
>>>
>>>Netspace Online Systems Pty Ltd
>>>Ground Floor, 293 Camberwell Road
>>>Camberwell, Victoria 3124
>>>Ph: +613 9811 0087
>>>Fx: +613 9811 0044
>>>Mo: +614 0549 9719
>>>Em: david.radunz [at] staff.netspace.net.au
>>>
>>>This email and any files transmitted with it are confidential and intended solely for the
>>>use of the individual or entity to whom they are addressed. Please notify the sender
>>>immediately by email if you have received this email by mistake and delete this email
>>>from your system. Please note that any views or opinions presented in this email are solely
>>> those of the author and do not necessarily represent those of the organisation.
>>>Finally, the recipient should check this email and any attachments for the presence of
>>>viruses. The organisation accepts no liability for any damage caused by any virus
>>>transmitted by this email.
>>>
>>>
>>--
>>David Radunz,
>>Developer / Programmer
>>
>>Netspace Online Systems Pty Ltd
>>Ground Floor, 293 Camberwell Road
>>Camberwell, Victoria 3124
>>Ph: +613 9811 0087
>>Fx: +613 9811 0044
>>Mo: +614 0549 9719
>>Em: david.radunz [at] staff.netspace.net.au
>>
>>


--------------enigD1293E945159E55316F343C2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBeXNHyzKhB4jDpaURAmRPAJ9GKsVb2ADN99VBBJ0t89487bJfwgCg gekz
CQRojks20wd99zSpMHpqxbw=
=Tjbi
-----END PGP SIGNATURE-----

--------------enigD1293E945159E55316F343C2--

--------------enig785303BBA24D6ED98BF92F0B
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Philippe M. Chiasson wrote:
> David Radunz wrote:
>
> [...]
>
> I think that you have just uncovered a small bug in the unload_package()
> implementation
> and I'd like to know exactly how you've reproduced this. After looking
> over code, it is
> now clear to me that any namespace entry that has a name <= 2 characters
> long (e.g 'qs')
> will not be deleted. That's a bug, and I expect to have it fixed both in
> mp2 and in Devel::Unload
> soon.

I've found and fixed the bug.

> I'll let you know when there is another version of Devel::Unload you can
> try out.

It's available at the same place as before:
http://svn.ectoplasm.org/projects/perl/Devel-Unload/

> In the meantime,
> could you please give me more information about how you have tested
> this, since the size of the
> string doesn't matter AFAIK.
>
> Thanks!
--
------------------------------------------------------------ --------------------
Philippe M. Chiasson m/gozer\ [at] (apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

--------------enig785303BBA24D6ED98BF92F0B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFBfUSAyzKhB4jDpaURAucaAKCga4quOXbRfEn5ZjwxwAJjXcv5iQCX UJdo
u/K5BS9aDQwBIlaWbfwlbA==
=vZa+
-----END PGP SIGNATURE-----

--------------enig785303BBA24D6ED98BF92F0B--

Hey,

I just tested it and it works perfectly - I wont be able to roll out the
next version that encorporates Devel::Unload for a week or two, but if I
encounter any problems I will let you know.

Cheers,

David

On Tue, 2004-10-26 at 04:22, Philippe M. Chiasson wrote:
> Philippe M. Chiasson wrote:
> > David Radunz wrote:
> >
> > [...]
> >
> > I think that you have just uncovered a small bug in the =
unload_package()
> > implementation
> > and I'd like to know exactly how you've reproduced this. After =
looking
> > over code, it is
> > now clear to me that any namespace entry that has a name <=3D 2 =
characters
> > long (e.g 'qs')
> > will not be deleted. That's a bug, and I expect to have it fixed =
both in
> > mp2 and in Devel::Unload
> > soon.
>
> I've found and fixed the bug.
>
> > I'll let you know when there is another version of Devel::Unload you =
can
> > try out.
>
> It's available at the same place as before:
> http://svn.ectoplasm.org/projects/perl/Devel-Unload/
>
> > In the meantime,
> > could you please give me more information about how you have tested
> > this, since the size of the
> > string doesn't matter AFAIK.
> >
> > Thanks!
--
David Radunz,
Developer / Programmer

Netspace Online Systems Pty Ltd
Ground Floor, 293 Camberwell Road
Camberwell, Victoria 3124
Ph: +613 9811 0087
Fx: +613 9811 0044
Mo: +614 0549 9719
Em: david.radunz [at] staff.netspace.net.au

This email and any files transmitted with it are confidential and =
intended solely for the
use of the individual or entity to whom they are addressed. Please =
notify the sender
immediately by email if you have received this email by mistake and =
delete this email
from your system. Please note that any views or opinions presented in =
this email are solely
those of the author and do not necessarily represent those of the =
organisation.
Finally, the recipient should check this email and any attachments for =
the presence of
viruses. The organisation accepts no liability for any damage caused by =
any virus
transmitted by this email.


--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html