I encountered the following warning when it runs scipy.stats.stats.pearsonr() in my program
/usr/local/lib/python2.7/dist-packages/scipy/stats/stats.py:2471: RuntimeWarning: invalid value encountered in double_scalars
I wonder how to find out the reason of the warning, by using print out, or by using a debugger like pdb (I know something about pdb, but I don't know how to use pdb to find out the reason of the warning here).
Here is the line of my program that uses pearsonr():
...
corr = pearsonr(t1, t2)
...
According to the docs, you can change the default warning behavior to raise an exception, which would of course make it much easier to track down and debug.
import warnings
# Cause all warnings to raise exceptions:
warnings.simplefilter("error") # change the hook
# Trigger a warning:
corr = pearsonr(t1, t2) # this will now raise
Replace warnings.showwarning with a function that will print the stack trace.
Related
I am new to OCaml which I installed via opam. My compiler is dune. Each time I build my project and run it, it crashes but I get no information from where it crashes in the code.
A friend of mine who is doing the same thing get information about the line where it crashes.
If anyone have an idea it will be incredible !
Best regards,
You could add the following in you main, which turns on the recording of exception backtraces:
let main =
record_backtrace true;
...
Alternativelly, you can set the b flag through the OCAMLRUNPARAM variable.
you can try using try\catch, exceptions and printing to find where the problem is at.
in case the exception is something you have raised, you can try to replace it with a costume exception to get the various details.
exception Yourexception of string;;
raise (Yourexception "the problem is here") ;;
if the problem is an OS exception, such as stack overflow, you can try placing prints all over the place, and slowly pinpoint the exact location
print_string( "1\n");
and when all else fail, use try and catch to slowly pinpoint the location (you can google the exception to help pinpoint the cause. for example finding that list raise the exception or something)
try (-your code-)
with exception -> (- print or handle or whatever - );;
these steps help with most of the languages, so its nice to remember them
I'm trying to debug some code in a Jupyter notebook. I've tried 3 4 different methods, and they all suffer from the same problem:
--Return--
None
> <ipython-input-22-04c6f5c205d1>(3)<module>()
1 import IPython.core.debugger as dbg
2 dber = dbg.Tracer()
----> 3 dber()
4 tst = huh.plot(ret_params=True)
5 type(tst)
ipdb> n
> y:\miniconda\lib\site-packages\ipython\core\interactiveshell.py(2884)run_code()
2882 finally:
2883 # Reset our crash handler in place
-> 2884 sys.excepthook = old_excepthook
2885 except SystemExit as e:
2886 if result is not None:
as you can see, the n command, which from what I understood from the pdb documentation should execute the next line (I'm assuming ipdb is just pdb adapted to work on IPython, especially since I can't find any command documentation that refers specifically to ipdb and not pdb)
s also has the same problem. This is actually what I want to do - step into the plot call (from what I understand, this is what s is supposed to do), but what I get is exactly the same as what I get from n. I also just tried r and I get the same problem.
Every example I've seen just uses Tracer()() or IPython.core.debugger.PDB().set_trace() to set a breakpoint in the line that follows the command, but both cause the same problems (and, I assume, are actually the exact same thing).
I also tried %debug (MultipleInstanceError) and %%debug (Doesn't show the code in the line being executed - just says what line, using s doesn't step into the function, just runs the line).
Edit: turns out, according to a blog post from April of this year, plain pdb should also work. It does allow me to interactively debug the notebook, but it only prints the current line being debugged (probably not a bug), and it has the same problem as IPython's set_trace() and Tracer()()
on plain IPython console, IPython's set_trace (only one I've tested) works just fine.
I encountered the same problem when debugging in Jupyter Notebook. What is working for me however, is when I call set_trace() inside a function. Why is explained here (click), though I don't really understand why others don't encounter this problem. Anyway, if you need a pragmatic solution for your problem and you want to debug a self-written function, try this:
from IPython.core.debugger import set_trace
def thisfunction(x):
set_trace() # start debugging when calling the function
x += 2
return x
thisfunction(5) # ipdb console opens and I can use 'n'
Now I can use 'n' and the debugging process runs the next line without problems. If I use the following code, however, I run into your above mentioned problem.
from IPython.core.debugger import set_trace
def thisfunction(x):
x += 2
return x
set_trace() # start debugging before calling the function.
# Calling 's' in the ipdb console to step inside "thisfunction" produces an error
thisfunction(5)
Hope this helps until somebody could solve the problem completely.
In python IDLE it won't print the specified error message when using sys.exit('') but in cmd.exe it will. Why?
import sys
try:
print fail
except:
sys.exit("This is an example of an error message")
Your error message is printed to stderr which is not shown in IDLE because it's run in a subprocess (see this report of your observation and this related answer). So IDLE writes it on the terminal used to start IDLE.
The documentation states about the arguments of sys.exit:
Some systems have a convention for assigning specific meanings to
specific exit codes, but these are generally underdeveloped; Unix
programs generally use 2 for command line syntax errors and 1 for all
other kind of errors. If another type of object is passed, None is
equivalent to passing zero, and any other object is printed to stderr
and results in an exit code of 1. In particular, sys.exit("some error
message") is a quick way to exit a program when an error occurs.
So, the safest way is to only pass error codes and use an additional print (or calling a custom exit-function that gives the user an analysis of what happened).
Please help this is driving me stir crazy. I am using Ipython Shell, and desperately trying to receive less verbose error messages. For each tiny error I am getting 40+ lines. I think what I need to do is set xmode to plain. I tried at first to do this in the command prompt upon starting ipython, but I think xmode is a magic function so should be called in the Ipython shell, so I wont paste what I tried in the command prompt. In the shell I tried:
xmode('Plain')
xmode('plain')
xmode(plain)
xmode(Plain)
and all of the above with a % prefix. I also tried
xmode<('Plain')>
and about a billion other permutations.
Can someone please tell me what I'm doing wrong....?
Thanks so much
Magics are usually called without parentheses, and with a leading percent. You can call them without % in some cases I wont detail here.
xmode called without argument will cycle by itself through option.
Here is a session of mine :
In [1]: xmode
Exception reporting mode: Verbose
In [2]: %xmode
Exception reporting mode: Plain
In [3]: %xmode
Exception reporting mode: Context
In [4]: %xmode
Exception reporting mode: Verbose
In [5]: %xmode plain
Exception reporting mode: Plain
In [6]: %xmode plain
Exception reporting mode: Plain
Hope that helps. You can also execute a single question mark In[1]: ? to get an intro to ipython, or see %quickref.
I get this error while running a python script (called by ./waf --run):
TypeError: abspath() takes exactly 1 argument (2 given)
The problem is that it is indeed called with: obj.path.abspath(env).
This is not a python issue, because that code worked perfectly before, and it's part of a huge project (ns3) so I doubt this is broken.
However something must have changed in my settings, because this code worked before, and now it doesn't.
Can you help me to figure out why I get this error ?
Here is the python code: http://pastebin.com/EbJ50BBt. The error occurs line 61.
The documentation of the method Node.abspath() states it does not take an additional env parameter, and I confirmed that it never did by checking the git history. I suggest replacing
if not (obj.path.abspath().startswith(launch_dir)
or obj.path.abspath(env).startswith(launch_dir)):
continue
with
if not obj.path.abspath().startswith(launch_dir):
continue
If this code worked before, this is probably due to the fact that the first operator of the or expression happened to always be True, so the second operator was never executed. It seems to be a bug in your code anyway.
You should have a file name and line number in the traceback. Go to that file and line and find out was "obj" and "obj.path.abspath" are. A simple solution would be to put the offending line in a try/except block to print (or log) more informations, ie:
# your code here
try:
whatever = obj.path.abspath(env)
except Exception, e:
# if you have a logger
logger.exception("oops : obj is '%s' (%s)" % (obj, type(obj)))
# else
import sys
print >> sys.stderr, "oops, got %s on '%s' (%s)" % (e, obj, type(obj))
# if you can run this code directly from a shell,
# this will send you in the interactive debugger so you can
# inspect the offending objet and the whole call stack.
# else comment out this line
import pdb; pdb.set_trace()
# and re-raise the exception
raise
My bet is that "obj.path" is NOT the python 'os.path' module, and that "obj.path.abspath" is a an instance method that only takes "self" as argument.
The problem came from the fact that apparently waf doesn't like symlinks, the python code must not be prepared for such cases.
Problem solved, thanks for your help everybody