>>>>> "TC" == Tal Cohen <tal-JzPWfi2g8PNWk0Htik3J/w@xxxxxxxxxxxxxxxx> writes:
TC> On my development system it works fine (SunOS XXX 5.8 Generic_117350-24
TC> sun4u sparc SUNW,Sun-Fire-880), however I copied it onto another system
TC> (SunOS XXX 5.8 Generic_117350-26 sun4u sparc SUNW,Sun-Fire) and all of a
TC> sudden, the script will only work if at some point in the function I print
TC> to STDERR one of the values of the internal hash (see below).
what about the perl versions? are there any xs based modules being used
(many times they will need rebuilding to work on other systems). even
with the same solaris if you have different perl versions you may need
to rebuild xs modules. just copying them over may work partially but i
wouldn't trust it.
TC> I have a hash that gets populated. The hash is then used with a
TC> proprietary function in a separate library. For example:
TC> use mylib qw(function1);
TC> my %hash;
TC> # populate values..
TC> %hash = function1(%hash);
i know that is generic code but do you really pass in the same hash and
then stuff it with the new hash? it would be cleaner and faster to pass
in a ref to the hash and to just work on that.
TC> package mylib;
TC> sub function1 {
TC> my %internalHash = @_;
TC> print STDERR "$internalHash{SOMEVALUE}\n";
TC> }
TC> If I don't include that print statement, the function does not
TC> work at all.
define does not work. i assume you mean stuffing of the hash doesn't work
but how are you checking that? IMO there is too much missing here to
give any deeper analysis.
uri
--
Uri Guttman ------ uri-X/06uaNR9nFmbZtjAW+qKA@xxxxxxxxxxxxxxxx --------
http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
|
