I am trying to debug a script using spyder debugger. When entering debugger mode, python return the following error :
RecursionError: maximum recursion depth exceeded
My code does not use recursion. However, going up the traceback I see it is actually spyder's debugger pdb that triggers the recursion given that I see a bunch of the following repeated many times :
File "C:\Users\XXXX\Documents\PythonEnvs\Python36Main\lib\site-packages\pdb.py", line 169, in __init__
super(Pdb, self).__init__(*args, **kwargs)
File "C:\Users\XXXX\Documents\PythonEnvs\Python36Main\lib\site-packages\IPython\core\debugger.py", line 232, in __init__
OldPdb.__init__(self, completekey, stdin, stdout)
Any idea what is going on ? I tried on the machine of a colleague who is running 3.7 and he can debug without any issue.
EDIT : To the request, I tried a really simple script as shown herebelow :
def simpleFunction():
print("this is a simple function")
Entering the debug on this simple script triggers the same issue. Note that before, I could run the debugger without problem. I do not know what has changed since then.
Related
I am trying to run an executable called swat_edit.exe in R. It works perfectly when I run it directly in the command prompt, and also when I run it directly in the Terminal tab in R. However, when I try to write a function in R to run the executable, I get an error (I get a number of different errors...).
I have tried to use different methods of running the file:
1: I used system("swat_edit"), which returns the following error:
Unhandled Exception: System.IO.IOException: The handle is invalid.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.Console.set_CursorVisible(Boolean value)
at SWEdit.Program.Run(String[] args)
at SWEdit.Program.Main(String[] args)
[1] 17234
2: I used shell("swat_edit"), which returns the exact same error as (1).
3: I used shell.exec("swat_edit"). This works, but it opens the executable in a new window, which then runs for a few seconds and closes (as intended). I need the program to run in the R terminal window so it can run many iterations in the background without disrupting other things. This is not a viable option.
4: I tried using terminalSend(ID,"swat_edit") (from the rstudioapi package). This works in that it sends the command to the terminal window in R. When I move there and hit enter it executes perfectly, running in the terminal window like I want it to. However, I need to run many iterations so this is not viable either. I tried using KeyboardSimulator to go to the Terminal tab and hitting enter (which worked), but this also does not let me use the PC for other purposes while running my code.
5: I tried using terminalExecute("swat_edit"), which returns the following error code:
Error calling capture_console_output: 87
[Process completed]
[Exit code: -532462766]
6: I tried making a python file that runs swat_edit.exe, and then running that file in R. The python file works when I run it by itself, from the command prompt, or from the terminal in R. It does not, however, work when I try to run it in the R terminal using terminalExecute (same error as in (5)).
NOTE: I have another executable called swat.exe (entirely different program) that works with all of the above-mentioned methods.
So in summary: swat_edit.exe runs perfectly in command prompt and R terminal, but does not work when I try to run it using R code (either system(), shell(), or terminalExecute().
I can't figure out the difference between terminalExecute() and typing the string into terminal and hitting enter, but apparently there is something happening in between...
It will be tedious to reproduce this since it uses external programs, but if anyone has any idea about the error messages or how I can copy a string and run it in the terminal without any interference, that would be greatly appreciated.
EDIT: I found a method that solves my problem. I created a .bat file that runs swat_edit minimized. I was able to run this .bat file with the shell function (or any of the other commands I mentioned) in R. This doesn't answer why I was having the issues I described, and it doesn't let me run swat_edit in the R terminal, but it's good enough for me.
The .bat file was simply the following:
"START /MIN /WAIT C:\~\SWAT_Edit.exe"
This is a tricky problem because it deals with the Pythonwin.exe user interface itself, and not my code.
When I run a file with the following code in it, I would expect that if it errors, it would show the line that it failed on in the traceback output
I literally just create an untainted 32-bit python 3.5 environment, installed pywin32, and opened my testfile.py to run it and here were the results.
Screenshot
If you see the line saying
File "C:\testfile.py", line 2, in <module>
foo = 2 #this line works fine, but is identified as the traceback line
I would have expected this to point to line 5 and not line 2.
Inside a larger script, this is much more problematic as I need to guess which line caused the error based on the context.
To replicate my situation in an anaconda-based environment:
1. open the Anaconda Command Prompt
2. run the following lines to generate our environment
set CONDA_FORCE_32BIT=1
conda create -n test python=3.5
activate test
conda install -y pywin32
Save "testfile.py" file with text:
#comment
foo = 2 #this line works fine, but is identified as the traceback line
a=2
a=3
a=b #this line causes the error, but isn't identified
Open PythonWin.exe, open the "testfile.py" file and hit F5 or click Run
And it is not just an issue in anaconda installed environments.
If anyone has any insight into how to make it report the bad line of code, or why it is acting in this way, please let me know. Thanks!
The script is be able to run a software called PoiwerFctory externally by Python as follows:
#add powerfactory.pyd path to python path
import sys
sys.path.append("C:\\Program Files\\DIgSILENT\\PowerFactory 2017
SP2\\Python\\3.6")
#import powerfactory module
import powerfactory
#start powerfactory module in unattended mode (engine mode)
app=powerfactory.GetApplication()
#get the user
user=app.GetCurrentUser()
#active project
project=app.ActivateProject('Python Test') #active project "Python Test"
prj=app.GetActiveProject #returns the actived project
#run python code below
ldf=app.GetFromStudyCase('ComLdf') #caling loadflow command object
ldf.Execute() #executing the load flow command
#get the list of lines contained in the project
Lines=app.GetCalcRelevantObjects('*.ElmLne') #returns all relevant objects,
i.e. all lines
for line in Lines: #get each element out of list
name=line.loc_name #get name of the line
value=line.GetAttribute('c:loading') # return the value of elements
#Print the results
print('Loading of the line: %s = %.2f'%(name,value))
When the above code first time executed in Spyder, it will show proper resutls. However, if re-executing the script again, the following error is appeared:
Reloaded modules: powerfactory
Traceback (most recent call last):
File "<ipython-input-9-ae989570f05f>", line 1, in <module>
runfile('C:/Users/zd1n14/Desktop/Python Test/Call Digsilent in
Python.py', wdir='C:/Users/zd1n14/Desktop/Python Test')
File "C:\ProgramData\Anaconda3\lib\site-
packages\spyder\utils\site\sitecustomize.py", line 866, in runfile
execfile(filename, namespace)
File "C:\ProgramData\Anaconda3\lib\site-
packages\spyder\utils\site\sitecustomize.py", line 102, in execfile
exec(compile(f.read(), filename, 'exec'), namespace)
File "C:/Users/zd1n14/Desktop/Python Test/Call Digsilent in Python.py",
line 12, in <module>
user=app.GetCurrentUser()
RuntimeError: 'powerfactory.Application' already deleted
Referred to How can I exit powerfactory using Python in Unattended mode?, this may because of PowerFactory in still running. And the only way which has been found so far is to re-start the Spyder and execute the script again, this is so inefficiency that if I want to re-write the code and debugging it.
It would be so much appropriated that if anyone could give me some advice for such problem.
I ran into the same Problem. Python is still connected to powerfactory and gives the Error if you try to connect again. What basicly worked for me was to kill the instance on the end of your skript with
del app
another idea during debugging could be:
try:
# Do something in your skript
finally:
del app
So the killing of the instance happens in any case.
The way to solve this is to reload the powerfacotry module by adding:
if __name__ == "__main__":
before import powerfacory.
The reason behind may referred to: What does if __name__ == "__main__": do?.
I am trying to build XTK following this link on Linux running on Oracle VirtualBox to get non-minified xtk.js. I am getting following error when I tried to generate the xtk-deps.js on running deps.py file:
Generating dependency file for XTK...
Traceback (most recent call last):
File "/root/Downloads/X-master/lib/google-closure-library/closure/bin/build/depswriter.py", line 212, in <module>
main()
File "/root/Downloads/X-master/lib/google-closure-library/closure/bin/build/depswriter.py", line 196, in main
path_to_source[depspath] = source.Source(source.GetFileContents(srcpath))
File "/root/Downloads/X-master/lib/google-closure-library/closure/bin/build/source.py", line 126, in GetFileContents
return fileobj.read()
File "/usr/lib/python2.7/codecs.py", line 668, in read
return self.reader.read(size)
File "/usr/lib/python2.7/codecs.py", line 474, in read
newchars, decodedbytes = self.decode(data, self.errors)
File "/usr/lib/python2.7/encodings/utf_8_sig.py", line 104, in decode
return codecs.utf_8_decode(input, errors)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x9a in position 4584: invalid start byte
Could not generate dependency file.
Could anybody please explain why this error is coming.
There's probably some non-uft8 characters in your code (most likely in X.js).
Take my experience for example, in the X.js of XTK, I found there's a non-English word (maybe a German or French name) in line #210. What I did is to delete the character and run build.py again. The encode error didn't appear again.
What worked for me is that I used an earlier commit of google closure library for building XTK and it worked perfectly.
I had to search XTK's commit history extensively to know which version of closure library they were using to build it.
PS: Earlier I posted similar solution here. But the post was deleted by moderator so sharing it here again.
I've often been frustrated by R's cryptic error messages. I'm not talking about during an interactive session, I mean when you're running a script. Error messages don't print out line numbers, and it's often hard to trace the offending line, and the reason for the error (even if you can find the location).
Most recently my R script failed with the the incredibly insightful message: "Execution halted." The way I usually trace such errors is by putting a lot of print statements throughout the script -- but this is a pain. I sometimes have to go through the script line by line in an interactive session to find the error.
Does anyone have a better solution for how to make R error output more informative?
EDIT: Many R-debugging things work for interactive sessions. I'm looking for help on command-line scripts run through Rscript. I'm not in the middle of an R session when the error happens, I'm at the bash shell. I can't run "traceback()"
Try some of the suggestions in this post:
General suggestions for debugging in R
Specifically, findLineNum() and traceback()/setBreakpoint().
#Nathan Well add this line sink(stdout(), type="message") at the beginning of the script and you should get in console message both script content and output along with error message so you can see it as in interactive mode in the console. (you can then also redirect to a log file if you prefer keeping the console "clean")
Have a look at my package tryCatchLog (https://github.com/aryoda/tryCatchLog).
While it is impossible to improve the R error messages directly you can save a lot of time by identifying the exact code line of the error and have actual variables at the moment of the error stored in a dump for "post mortem" analysis!
The main advantages of the tryCatchLog function over tryCatch are
easy logging of errors, warnings and messages into a file or console
warnings do not stop the program execution (tryCatch stops the execution if you pass a warning handler function)
identifies the source of errors and warnings by logging a stack trace with a reference to the source file name and line number (since traceback does not contain the full stack trace)
allows post-mortem analysis after errors by creating a dump file with all variables of the global environment (workspace) and each function called (via dump.frames) - very helpful for batch jobs that you cannot debug on the server directly to reproduce the error!
This will show a more detailed traceback, but not the line number:
options(error = function() {traceback(2, max.lines=100); if(!interactive()) quit(save="no", status=1, runLast=T)})
One way inside a script to get more info on where the error occurred is to redirect R message to the same stream as errors :
sink(stdout(), type="message")
This way you get both messages and errors in the same output so you see which line raised the error...