Redux: Devel::Reloader ==> Modules::Reload::Selective
Hi Joshua and other esteemed modules members,
Please recall the exchange below from back in July 2000:
http://www.xray.mpe.mpg.de/mailing-lists/modules/2000-07/msg00246.html
in which I requested to upload a module called Devel::Reloader which was similar
to your Module::Reload. You guys on the list helped me realize that
Module::Reload::Force or something would be a better name for my module.
Joshua, you perhaps jokingly suggested renaming your module (Module::Reload) to
Module::Autoreload presumably so that mine could take the name of yours, which was a
kind gesture, but obviously not practical or helpful to those already using your
module.
Anyway, eventually there seemed to be no particular further interest in the thread --
see:
http://www.xray.mpe.mpg.de/cgi-bin/w3glimpse/modules?query=reloader&errors=0&case=on&maxfiles=100&maxlines=30
and I got busy and never uploaded anything.
Anyway, I'm finally ready to make this module available.
Considering the discussions that were had, I would be happy to rename my module
Module::Reload::Selective or some such similar.
If there are no objections, I'll consider that I have tacit approval to do so and will
prepare to package it accordingly and upload (I already have a PAUSE ID).
Sincerely,
-chris
Re: May I put Devel::Reloader into Devel::?
* From: Joshua N Pritikin <[EMAIL PROTECTED]>
* To: [EMAIL PROTECTED]
* Cc: [EMAIL PROTECTED]
* Date: Fri, 28 Jul 2000 20:29:42 -0400
* Message-ID: <[EMAIL PROTECTED]>
On Fri, Jul 28, 2000 at 02:01:13PM -0700, [EMAIL PROTECTED] wrote:
> I feel dumb for not having found that one in CPAN before writing mine :-).
Oops :-)
> Yes, I think mine could maybe be a replacement, BUT it doesn't do the
> one feature that yours does: namely, reload based on file-changed-time.
Hm hm.
> That's an optimization that's probably missing from mine, but I
> intentionally didn't add that because some modules have load-time side
> effects (such as BEGIN blocks) and so forcing an unconditional reload is
> slightly different from reloading only changed files.
Agreed.
> In light of that, maybe mine should be a different module, maybe called:
>
> Module::Reload::Force
Or maybe I should rename mine to Module::Autoreload?
> but one of the biggest aspects of mine is its ability to do
> nothing during end-user runtime, but kick in selectively at Development
> time -- i.e. it doesn't always force the Reload. That's why I thought
> Devel:: might be the best place for it.
do_stuff() if $ENV{TESTING}; # pretty trival
> I think naming is very important and I
> do want to come up with the best name.
Oh good. Me too.
--
Chris Thorman (413) 473-0853 e-fax
May I put Devel::Reloader into Devel::?
re and after and set some derived hashes.
if ($Devel::Reloader::Debug->{INCHashBefore} &&
$Devel::Reloader::Debug->{INCHashAfter})
{
($Devel::Reloader::Debug->{NotReloaded},
$Devel::Reloader::Debug->{NewlyLoaded},
$Devel::Reloader::Debug->{Reloaded}) =
CompareHashKeys($Devel::Reloader::Debug->{INCHashBefore},
$Devel::Reloader::Debug->{INCHashAfter});
## CompareHashKeys leaves the values undefined; for
## convenience, we pick up the values from the Before and
## After hashes.
foreach ($Devel::Reloader::Debug->{NotReloaded},
$Devel::Reloader::Debug->{NewlyLoaded},
$Devel::Reloader::Debug->{Reloaded})
{
@{$_}{keys %$_} = (map
{($Devel::Reloader::Debug->{INCHashAfter }->{$_} ||
$Devel::Reloader::Debug->{INCHashBefore}->{$_})} keys %$_);
}
## Finally make another debugging hash of anything that got
## loaded for any reason, whether newly, or re-loaded.
$Devel::Reloader::Debug->{GotLoaded} = {};
@{$Devel::Reloader::Debug->{GotLoaded}}{keys
%{$Devel::Reloader::Debug->{NewlyLoaded}}} = values
%{$Devel::Reloader::Debug->{NewlyLoaded}};
@{$Devel::Reloader::Debug->{GotLoaded}}{keys
%{$Devel::Reloader::Debug->{Reloaded }}} = values
%{$Devel::Reloader::Debug->{Reloaded }};
## Copy entries for the items that changed into the non-local %INC
hash.
@INC{keys %{$Devel::Reloader::Debug->{GotLoaded}}} = values
%{$Devel::Reloader::Debug->{GotLoaded}};
}
return($ReturnVal);
}
# Utility routines ##
sub CompareHashKeys
{
my ($Hash1, $Hash2) = @_;
my $In1NotIn2 = {}; @$In1NotIn2{keys %$Hash1 } = undef; delete
@$In1NotIn2{keys %$Hash2 };
my $In2NotIn1 = {}; @$In2NotIn1{keys %$Hash2 } = undef; delete
@$In2NotIn1{keys %$Hash1 };
my $Subset= {}; @$Subset {keys %$Hash1, keys %$Hash2} = undef; delete
@$Subset {keys %$In1NotIn2, keys %$In2NotIn1};
return($In1NotIn2, $In2NotIn1, $Subset);
}
1;
Chris Thorman (413) 473-0853 e-fax
May I put Devel::Reloader into Devel::?
abled_Because} = "No environment
variables were set.";
}
done:
## if %INC was messed with, we analyze the differences between the
## before and after and set some derived hashes.
if ($Devel::Reloader::Debug->{INCHashBefore} &&
$Devel::Reloader::Debug->{INCHashAfter})
{
($Devel::Reloader::Debug->{NotReloaded},
$Devel::Reloader::Debug->{NewlyLoaded},
$Devel::Reloader::Debug->{Reloaded}) =
CompareHashKeys($Devel::Reloader::Debug->{INCHashBefore},
$Devel::Reloader::Debug->{INCHashAfter});
## CompareHashKeys leaves the values undefined; for
## convenience, we pick up the values from the Before and
## After hashes.
foreach ($Devel::Reloader::Debug->{NotReloaded},
$Devel::Reloader::Debug->{NewlyLoaded},
$Devel::Reloader::Debug->{Reloaded})
{
@{$_}{keys %$_} = (map
{($Devel::Reloader::Debug->{INCHashAfter }->{$_} ||
$Devel::Reloader::Debug->{INCHashBefore}->{$_})} keys %$_);
}
## Finally make another debugging hash of anything that got
## loaded for any reason, whether newly, or re-loaded.
$Devel::Reloader::Debug->{GotLoaded} = {};
@{$Devel::Reloader::Debug->{GotLoaded}}{keys
%{$Devel::Reloader::Debug->{NewlyLoaded}}} = values
%{$Devel::Reloader::Debug->{NewlyLoaded}};
@{$Devel::Reloader::Debug->{GotLoaded}}{keys
%{$Devel::Reloader::Debug->{Reloaded }}} = values
%{$Devel::Reloader::Debug->{Reloaded }};
## Copy entries for the items that changed into the non-local %INC
hash.
@INC{keys %{$Devel::Reloader::Debug->{GotLoaded}}} = values
%{$Devel::Reloader::Debug->{GotLoaded}};
}
return($ReturnVal);
}
# Utility routines ##
sub CompareHashKeys
{
my ($Hash1, $Hash2) = @_;
my $In1NotIn2 = {}; @$In1NotIn2{keys %$Hash1 } = undef; delete
@$In1NotIn2{keys %$Hash2 };
my $In2NotIn1 = {}; @$In2NotIn1{keys %$Hash2 } = undef; delete
@$In2NotIn1{keys %$Hash1 };
my $Subset= {}; @$Subset {keys %$Hash1, keys %$Hash2} = undef; delete
@$Subset {keys %$In1NotIn2, keys %$In2NotIn1};
return($In1NotIn2, $In2NotIn1, $Subset);
}
1;
Chris Thorman (413) 473-0853 e-fax
Re: May I put Devel::Reloader into Devel::?
Hi, I feel dumb for not having found that one in CPAN before writing mine :-). Yes, I think mine could maybe be a replacement, BUT it doesn't do the one feature that yours does: namely, reload based on file-changed-time. That's an optimization that's probably missing from mine, but I intentionally didn't add that because some modules have load-time side effects (such as BEGIN blocks) and so forcing an unconditional reload is slightly different from reloading only changed files. In light of that, maybe mine should be a different module, maybe called: Module::Reload::Force ? ... but one of the biggest aspects of mine is its ability to do nothing during end-user runtime, but kick in selectively at Development time -- i.e. it doesn't always force the Reload. That's why I thought Devel:: might be the best place for it. Anyone else have any opinions? I think naming is very important and I do want to come up with the best name. -c At 4:30 PM -0400 7/28/00, Joshua N Pritikin wrote: >On Fri, Jul 28, 2000 at 01:21:32PM -0700, [EMAIL PROTECTED] wrote: >> I'd like permission to submit a module called Devel::Reloader that's >> similar to the concept of Apache::StatInc but serves as a more >> general-purpose development tool. >> >> To describe it, I'm pasting the entire contents of the .pm file, which >> is more pod than code, below, since the pod docs are fairly complete. >> >> Thanks for your consideration, and also any advice or pointers you >> have time to offer before I release this module to the public. > >Looks like a more elaborate version of: > > http://search.cpan.org/search?dist=Module-Reload > >I wonder if your module can just replace this one...? > >-- >Never ascribe to malice that which can be explained by stupidity. > (via, but not speaking for Deutsche Bank) Chris Thorman (413) 473-0853 e-fax
Re: May I put Devel::Reloader into Devel::?
OK -- now who makes the final decision?
Seems like renaming an already-uploaded module could cause confusion.
-c
At 8:29 PM -0400 7/28/00, Joshua N Pritikin wrote:
>On Fri, Jul 28, 2000 at 02:01:13PM -0700, [EMAIL PROTECTED] wrote:
>> I feel dumb for not having found that one in CPAN before writing mine :-).
>
>Oops :-)
>
>> Yes, I think mine could maybe be a replacement, BUT it doesn't do the
>> one feature that yours does: namely, reload based on file-changed-time.
>
>Hm hm.
>
>> That's an optimization that's probably missing from mine, but I
>> intentionally didn't add that because some modules have load-time side
>> effects (such as BEGIN blocks) and so forcing an unconditional reload is
>> slightly different from reloading only changed files.
>
>Agreed.
>
>> In light of that, maybe mine should be a different module, maybe called:
>>
>> Module::Reload::Force
>
>Or maybe I should rename mine to Module::Autoreload?
>
>> but one of the biggest aspects of mine is its ability to do
>> nothing during end-user runtime, but kick in selectively at Development
>> time -- i.e. it doesn't always force the Reload. That's why I thought
>> Devel:: might be the best place for it.
>
>do_stuff() if $ENV{TESTING}; # pretty trival
>
>> I think naming is very important and I
>> do want to come up with the best name.
>
>Oh good. Me too.
>
>--
>Never ascribe to malice that which can be explained by stupidity.
> (via, but not speaking for Deutsche Bank)
Chris Thorman (413) 473-0853 e-fax
