Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl: the Markov chain saw
 
PerlMonks  

Re: package variables turning suddenly to undef and back again depending on subfunction call

by flexvault (Monsignor)
on Feb 25, 2013 at 18:55 UTC ( #1020552=note: print w/replies, xml ) Need Help??


in reply to package variables turning suddenly to undef and back again depending on subfunction call

tobias_hofer,

Put an extra set of brackets in the script. '{' after the package name, and a '}' the end of the script. Now, everything is in scope, so nothing should be 'undef' unless you didn't define them.

Hope this helps...Ed

"Well done is better than well said." - Benjamin Franklin

  • Comment on Re: package variables turning suddenly to undef and back again depending on subfunction call

Replies are listed 'Best First'.
Re^2: package variables turning suddenly to undef and back again depending on subfunction call
by tobias_hofer (Friar) on Feb 26, 2013 at 07:56 UTC

    I gave a try but there is no change in the debugger-view. Guess its up to the eclipse-plugin or debugger as using print statements is working fine.

    Thanks a lot!
    Tobias

      tobias_hofer,

      Just a little trick on using 'print' statements and debugging. (Note: I'm using *nix boxes) At the beginning of all of my packages, I define (actually copy the code) the following:

      ###################################################################### +# # DEBUG ==0 {no debugging}, ==1 {debugging}, >=2 {greater debugg +ing} ###################################################################### +## # our $Debug = 0; our $DLOG; ## Production our $Debug = 4; our $DLOG; ## Testing if ( $Debug ) { my $logFile = "MyLog_$$"; ## Good for multi-user testing open($DLOG,">",$logFile) || die "Cannot open $logFile:$!"; print $DLOG "############################# ".scalar localtime() +."\nStart. . . \n"; } else { open $DLOG, ">>", "/dev/null" ); }

      At different places in the code, if I have something going wrong, I insert statements like:

      for my $key { sort keys %Hash ) { ... do something ... if ( $Debug >= 4 ) { print $DLOG "Hash:\t$key\t|$Hash{$key}|\n +"; } }
      Once you get it working, all you have to do to stop printing to the log, is change the '4' to a '5' and the print won't be executed. When computers were much slower than today, I used to take them out for production, but now I leave them in and change the global '$Debug' to '0'.

      The advantage to doing this is if you have a production problem, you can turn the debugging on and get some help finding the problem. :-)

      There have been times when I've had a debug statement after every line of code to figure out what was going wrong. It's usually a typo or some other simple mistake, but without the debug info, you just don't see it. ( I always use strict and warnings, but sometimes things get through. )

      Always name the output so you can use your editor to search on the print statement. Notice that I put '|' around the variables to help see if it's undefined or "". You can also print to STDERR when your getting warnings. One time I was getting a couple 100K warnings for a script and by printing to STDERR, I was able to see the start and end of the problem in the loop. If your not testing a multi-user or multi-tasking package you don't need the '$$'. That's just so you don't have to lock/unlock the log file.

      Good Luck...Ed

      "Well done is better than well said." - Benjamin Franklin

        Hello Ed,

        I am doing almost the same, I wrote a class for error logging and use it extensively. For my module now I will give a try with your '$Debug' variable to drive the error-logging mechanism as its a fast way for exploring the data ;-)

        Thanks a lot!
        Tobias

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1020552]
help
Chatterbox?
[ambrus]: I'm currently in the process of rewriting my proof of concept programs. They sort of developped organically as I was experimenting, so now I've got an ugly mess of multiple programs and one-liners held together by nothing. I'll have to rewrite them to som
[ambrus]: ething that's both cleanly organized and mostly automated.
LanX in train, bad connection
[Corion]: ambrus: Yeah - we're in that situation too, except that there is no time to do the reorganizing :-/
[LanX]: ... so my boss started a project with the newest sun servers and invited the traders to come on weekend to test it... and they were so pleased, that they forced him to keep it in production...
[ambrus]: Corion: sure, this is the long-term plan. The short term is that I have to run this ungodly mess to get results from the new input data today.
[Corion]: ambrus: Most of our "automation" is tied to process exit codes and a shell pipeline :-\
[LanX]: ... a week later they realized that one of the databases - which recorded how much the other banks due to this bank - was not correctly plugged
[ambrus]: Corion: I have no problem with exit codes and shell pipeline. My problem is that the current process requires a lot of manual intervention from me, including editing the source codes.
[ambrus]: (Also a lot of manual intervention by two or three other co-workers, who do other parts of the process.)

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (16)
As of 2017-03-29 11:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Should Pluto Get Its Planethood Back?



    Results (350 votes). Check out past polls.