in reply to Re^10: Techniques On Saving Memory
in thread Techniques On Saving Memory

Ok, I'm game. So, should I work on this as Devel::RecoverRef (or some other, more appropriate name), or should I contact the authors of the Devel::Pointer* modules?
_____________________________________________________
Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

Replies are listed 'Best First'.
Re^12: Techniques On Saving Memory
by BrowserUk (Patriarch) on Mar 10, 2005 at 18:40 UTC

    I would antisipate some resistance to the idea from some quarters, although most, if not all of the functionality is already exposed through a collection of other modules, and is obviously available to XS programmers anyway.

    I'd do it as your own module. As for a name, maybe Devel::Reference?


    Examine what is said, not who speaks.
    Silence betokens consent.
    Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco.
Re^12: Techniques On Saving Memory
by Limbic~Region (Chancellor) on Mar 10, 2005 at 19:14 UTC
    japhy,
    I think we should keep code reuse in mind here. Writing code that solves a specific task often involves intermediate steps. Divorcing the intermediate steps from the specific task allows others to reuse the intermediate steps for their specific task.

    In other words, BrowserUk and I would both like to see a canned solution that would allow someone to stringify a reference, keep the memory around until needed, allow us to convert the string back into a reference, and release the memory when finished. This is unlikely going to be very useful to the general public, but some of the intermediate steps might be. I say 2 modules, 1 that provides all the XS basics and the second that ties them together for the specific task outlined above.

    As BrowserUk mentioned elsewhere in this thread. Even the implementation I proposed doesn't mean you can't get into trouble easily.

    Cheers - L~R

      Ok, then I offer this: here is XS code for two functions, conceal() and reveal(). (I'm not attached to the names, I just wanted a pair of names that vaguely explained their purpose.)
      int conceal(int var) CODE: SvREFCNT_inc((SV *) var); RETVAL = var; OUTPUT: RETVAL SV * reveal(char *str_or_addr) CODE: char *hex; int addr = (hex = rindex(str_or_addr, 'x')) ? strtol(++hex, NULL, 16) : atoi(str_or_addr); RETVAL = newRV((SV *) addr); SvREFCNT_dec((SV *) addr); OUTPUT: RETVAL
      How's that? Here's a sample use of the code:
      use Devel::Reference; my $x = [1,2,3]; my $addr = Devel::Reference::conceal($x); # the refcount of [1,2,3] is now 2 undef $x; # the refcount of [1,2,3] is now 1 my $y = Devel::Reference::reveal($addr); # the refcount of [1,2,3] REMAINS at 1 print "@$y\n"; # "1 2 3"
      As for all that other satellite data, that could be provided, but this is the crux of the functionality. All it's really lacking right now is sanity checking, to make sure the address is recoverable when in reveal().
      _____________________________________________________
      Jeff japhy Pinyan, P.L., P.M., P.O.D, X.S.: Perl, regex, and perl hacker
      How can we ever be the sold short or the cheated, we who for every service have long ago been overpaid? ~~ Meister Eckhart

      I don't see any reason to make two modules at all. This is not "general public" functionality.

      As I've said, almost all of this functionality is already available in a mix'm'match of various existing modules. The only reason I can see for a new module would be to put all the required functionality into one place--but that's just my opinion which has just as much worth as you choose to give it:)


      Examine what is said, not who speaks.
      Silence betokens consent.
      Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco.