in reply to Re: Module development: concurrent versions (Updated)
in thread Module development: concurrent versions (Updated)

Yeah. I've done that before, but it means that you cannot use the two versions in the same program.

The problem I'm trying to track down only manifests itself when the size of the arrays being sized gets above about 500,000 elements which make comparing trace output by eye impossible. So then you want to automate the comparison--diff or a custom script--but doing this with trace lines that (have to) contain addresses, means that all lines are different. (Ie. as different modules are loaded, the memory allocator has been exercised in different ways, so the addresses of test arrays and it elements are all different.)

I needed to be able to load both modules concurrently so I can run them on the same array.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re^2: Module development: concurrent versions (Updated)

Replies are listed 'Best First'.
Re^3: Module development: concurrent versions (Updated)
by syphilis (Archbishop) on Dec 23, 2010 at 11:30 UTC
    I needed to be able to load both modules concurrently so I can run them on the same array

    I tried the following experiment with Math-GMPz (a perl extension):
    1) Place version 0.31 of GMPz.pm in ./temp31/Math;
    2) Place its GMPz.dll in ./temp31/auto/Math/GMPz;
    3) Place version 0.32 of GMPz.pm in ./temp32/Math;
    4) Place its GMPz.dll in ./temp32/auto/Math/GMPz;

    Then run the following script: 
    use warnings;
use strict;

unshift @INC, "temp31";
require "temp31/Math/GMPz.pm";

print $Math::GMPz::VERSION, "\n";

unshift @INC, "temp32";
require "temp32/Math/GMPz.pm";

print $Math::GMPz::VERSION, "\n";

    [download]
    which outputs (as desired): 
    0.31
0.32

    [download]
    and just goes to prove that one can easily (albeit a bit kludgily) load 2 different versions of the same perl extension into the same script.

    You should be able to apply the same technique with Devel::Size.

    Cheers,
    Rob

    UPDATE: However, I note it's not quite so simple if I try to load them in the reverse order (ie first load 0.32, then 0.31): 
    0.32
Math::GMPz object version 0.32 does not match bootstrap parameter 0.31
+ at C:/_32/ap1007/lib/DynaLoader.pm line 224.
Compilation failed in require at try.pl line 10.

    [download]
    Not sure why that happens - perhaps some %INC manipulation would counter it.
    And, I guess, if you have to keep switching between the 2, then things get even messier.
[reply]
[d/l]
[select]

      ...but after you've loaded the second version, the variables/subroutines/etc. of the first loaded version will have been overwritten.  IOW, how would you (and Perl) tell apart Devel::Size::total_size() (version 1) from Devel::Size::total_size() (version 2), unless you put them into a different namespace, or name the subs differently?  (At least, it was my impression that BUK wanted to run both routines concurrently, for debugging purposes.)

      Or am I missing something in your approach?

[reply]
[d/l]
[select]
        IOW, how would you (and Perl) tell apart Devel::Size::total_size() (version 1) from Devel::Size::total_size() (version 2)

        Dunno - my impression was that the version 1 output would be put into 1 file, and that the version 2 output into a different file ... and that something like 'diff' would then be a useful tool (because it's the same big array being looked at in both instances, and the problem of differing memory addresses won't arise) ... but I could well be missing something, too.

        Cheers,
        Rob
[reply]
Re^3: Module development: concurrent versions (Updated)
by Anonyrnous Monk (Hermit) on Dec 23, 2010 at 10:20 UTC
    ...you cannot use the two versions in the same program.

    In that case, the only option I see is to give them different names/namespaces (temporarily), because you generally can't load two versions of a shared lib (with same name and exported symbols) twice, or load two Perl packages into the same namespace...

[reply]

      Indeed. That's what I've done.

      But--unlike say a C dll--because there are so many internal self-references, and cross-references in makefiles, meta-files and other random pieces of build mechanism arcanery, it is a time consuming and laborious process to "rename" a module.

      I just thought, (hoped), someone might have come up with a better mechanism than doing it manually.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]

In Section Seekers of Perl Wisdom