I want to profile python code on Widnows 7. I would like to use something a little more user friendly than the raw dump of cProfile. In that search I found the GUI RunSnakeRun, but I cannot find a way to download RunSnakeRun on Windows. Is it possible to use RunSnakeRun on windows or what other tools could I use?
Edit: I have installed RunSnakeRun now. That's progress, thanks guys. How do you run it without a linux command line?
Edit 2: I am using this tutorial http://sullivanmatas.wordpress.com/2013/02/03/profiling-python-scripts-with-runsnakerun/ but I hang up at the last line with "python: can't open file 'runsnake.py': [Errno 2] No such file or directory "
The standard solution is to use cProfile (which is in the standard library) and then open the profiles in RunSnakeRun:
http://www.vrplumber.com/programming/runsnakerun/
cProfile, however only profiles at the per-functions level. If you want line by line profiling try line profiler:
https://github.com/rkern/line_profiler
I installed runsnake following these installation instructions.
The step python runsnake.py profile.pfl failed because the installation step (easy_install SquareMap RunSnakeRun) did not create a file runsnake.py.
For me (on Ubuntu), the installation step created an executable at /usr/local/bin/runsnake. I figured this out by reading the console output from the installation step. It may be in a different place on Windows, but it should be printed in the output of easy_install. To read a profile file, I can execute /usr/local/bin/runsnake profile.pfl.
There's also py-spy, written in Rust, safe to use even in production, without modifying any code.
Works on Windows, to install run pip install py-spy.
From there you can run py-spy record -o profile.svg -- python myprogram.py which produces nice flame graphs.
Related
I am trying to compile a .tex file in a Python script using pdflatex. The command pdflatex filename.tex works when I run it from the command line on Windows. However, attempting to run os.system("pdflatex filename.tex") just spits out 1 into the Python console and does not compile a pdf. I've also tried putting in the full file path similar to this person solved their problem but the same thing happens. Similarly, subprocess.call(['pdflatex', 'filename.tex']) just outputs a 1 and does not do anything.
It seems someone else has encountered the same problem in this thread, but on Mac instead of Windows. (But regardless of the operating system, they didn't find an answer.)
Why might this be happening?
EDIT: I've just discovered a solution. The script runs successfully (using the os.system approach) when I run the .py file using the command line. Previously I was attempting to run the script from RStudio, both using reticulate::source_python(filename) and also line-by-line via the reticulate REPL. Seems like the problem may actually be coming from R's reticulate package rather than anything to do with Python.
Fortunately RStudio has a terminal window so this doesn't end up being too inconvenient!
I've written a script to rename my photos according to the date they were recorded. It runs on mac and uses the CLI exiftool by phil harvey.
The command that create problem is the following:
os.popen("exiftool " + file path)
I wrote the script using Pycharm CE. I used the exiftool because it yielded the best results and was the easiest to use at the time. With the command mentioned above, I got all the metadata nicely formatted by the exiftool and it only needed to be separated and put in a list. I tried everything in the console of Pycharm CE before I wrote the script.
The script and the console of Pycharm both worked fine. However, I tried recently to run the script with the IDLE from python. The script failed because the return from the console was always an empty string. Upon further research I used the subprocess.run()method. The error was
CompletedProcess(args='exiftool PATH', returncode=127, stdout=b'', stderr=b'/bin/sh: exiftool: command not found\n')
The output was also empty.
My questions are now:
Why does the Console and the interpreter of Pycharm CE find the exiftool but the console and the IDLE of python don't?
Is there a way to include the installation location of the exiftool so it is found by the os.popen() / subprocess.run() methods in the IDLE and the console?
Many thanks for your help
AliSot2000
At your command prompt, type which exiftool to find the full path to the executable. Then, instead of just calling exiftool in your Python script, use the full path.
Turns out, using which exiftool was indeed the solution.
I deinstalled python, reinstalled the newer version and tried the fix, proposed in the comment. (Using said command in Terminal and calling the command with the full path) It worked in the IDLE once I installed Python 3.7. I ran previously Python 2.7 on my MacBook.
I still don't understand why 2.7 wouldn't work.
Anyway thanks for the tip.
I am very new to R, and should only have two plugins that get loaded specifically for *.R scripts: jalvesaq/Nvim-R and vim-pandoc/vim-rmarkdown. However, I shall see the following error message every time I open an *.R file:
The problem when I open an R-script
On a MacBook Air (through MacVim):
On a Windows machine (Gvim):
I would need to click on the Reopen button for once; and the Close program button for twice. Afterwards, the Nvim-R plugin runs with no problem.
Possible solution?
Can I possibly get ride of these warnings? And/or, should this be a Vim-Python support problem? When starting the python-mode plugin, I get a Windows R6034 runtime error.
I have no trouble using other plug-ins that also calls Python, including: VOom, vim-tex and
Partial solution on Windows platforms
To delete all existing Python and Vim distribution;
To install a 64-bit Python (my version that worked is Python 2.7.14)
To install a 64-bit built Gvim (I found it from Cream, build Vim 8.0-1123)
Sanity check
Open a Vim with the following plug-ins loaded: Nvim-R, klen/python-mode.
To open a *.R file
To open a *.py file
Pending solution on Mac OS X
Also asked a question through the Mac-superuser forum: https://apple.stackexchange.com/questions/302213/how-to-properly-use-macvim-on-os-x-and-to-delete-the-duplicative-app-via-fi
I'm trying to install IDLE2HTML from the following link in order to print from IDLE in color. I use Python 2.7 on a Mac.
I follow the instructions from the readme.txt, but when I reload IDLE nothing has changed. I don't have the Save As HTML option.
In the past I've installed and reinstalled Python a few times.
When trying to find my idlelib folder (as written in the readme instructions), I eventually found it under the path /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/
Is my problem that my python is in /System/Library/?
Any ideas please?
I have not tried this extension, but the following may help. When you start Idle, select File / Path browser on the menu. You should see
_ sys.path
|
+ some_path/pythonxy/Lib/idlelib
|
+ some_path/python27.zip # or MAC equivalent
The first path tells you where the new files should be. If you click the +, you will see what file are there. What about IDLE2HTML.py? The next issue is whether you properly edited config-extensions.def. If you wait a few days for 2.7.9 and install it, you can try the new Options / Config-extensions dialog on the menu. That will show whether Idle can read the new information in the .def file. Or you can edit your question, paste in the new material you added, and comment on this answer, and I will take a look. However, given that the extension has been around for years, I presume that the addition in config-extensions.txt is correct.
I suspect that whenever you upgrade Python, config-extension.def will be overwritten and you will have to re-edit it.
If the problem is not a configuration problem with the IDLE2HTML Python IDLE extension like this answer (for the same question) explains about, it may be a problem with the code itself (this has happened with Python 3 IDLE). This can be checked by running IDLE using the Python file that starts it (<PYTHON LIBRARY DIR>\idlelib\idle.py where <PYTHON LIBRARY DIR> is the location of the standard library for the Python installation), in a command line interpreter (use <PYTHON EXECUTABLE DIR>\python.exe where <PYTHON EXECUTABLE DIR is the location of the executable files that start Python). It will launch IDLE and show any errors in the C.L.I..
Quote from Python idlelib module docstring:
Idle includes an interactive shell and editor. Use the files named idle.* to start Idle.
IDLE2HTML real error example:
A common problem is that IDLE2HTML version 2.0 (latest at time of writing) needs a simple code tweak to work with Python 3.x (a fixed version that works as part of the IDLEX Python module had this tweak). File comparison image (left is original file, right is IDLEX version in image); if the Python version is Python 3.x, import Tkinter needs to be changed to import tkinter as Tkinter and import tkFileDialog needs to be changed to import tkinter.filedialog as tkFileDialog:
Edwards suggestion of using the CLI for diagnosis was very useful. It exposed that the cgi.escape attribute does not exist for Python 3.
I changed the IDLE2HTML.py line 74 from "out.append(cgi.escape(content))" to
"out.append(content)" and after a re-boot it all worked!
Later: well almost... better to replace "import cgi" with "import html and then cgi.escape() with html.escape()
If using Win10 you will need super-admin rights to change IDLE2HTML.
I have several python scripts which work just fine but one script has (as of this morning) started giving me this error if I try to run it from the bash:
: No such file or directory
I am able to run the 'broken' script by doing python script_name.py and after looking around a bit the general idea that I picked up was that maybe my line ending of the hashbang got changed (silently) so I looked at the line ending of a working script and a broken script via the :set list option in VI as indicated in this question -> View line-endings in a text file
Both files appear to end using the same character (a $) so I am kind of at a loss on how to proceed from here. Specifically, how to actually 'see' the line ending in case the set list was not the right method.
PS: The script is executable and the shebang is in there, I stated that it's just this 1 script that was working fine before the weekend but it started giving me this error as of this morning.
-- edit: --
Running the script through dos2unix does get it working again but I would like to know of any way to visualize the line ending somehow in VI(M) or why Geany somehow converted the line endings in the first place (as I never work on a dos/windows system anyhow).
From the comments above it looks like you have dos line endings, and so the hashbang line is not properly processed.
Line ending style are not shown with :set list in Vim because that option is only used when reading/writing the file. In memory line endings are always that, line-endings. The line ending style used for a file is kept in a Vim per-file option, weirdly called fileformat.
To see/change the line ending style from Vim, you can use the following commands:
:set fileformat
:set ff
It will show dos or unix. You want unix, of course ;-).
To change it quickly you can save the file with:
:w ++ff=unix
Or if you prefer:
:set ff=unix
And then save the file normally.
So see all the gory details just do :help fileformat, :help file-formats and :help fileformats
You can also use the dos2unix command to convert the file format
dos2unix
This helped me to run the python scripts
This normally happens when we open files in windows do changes and save it.
if you open the file locate the ^M characters at the end of every line
Thanks
Personally, I find it kinda wrong using direct path to python interpreter. As you dont use windows platform, you should have program env, usually in /usr/bin (/usr/bin/env). Try using following shebang:
#!/usr/bin/env python
Different distros store python binary in /bin or /usr/bin (or some weird locations), and this one makes your script config-independent (as far as possible, here we have possibility that env is stored elsewhere; still - it is less possible that env is not in /usr/bin than that python is mislocated).
I had similiar problem (if not exactly the same) and that worked for me.
Also, I have both python interpreters (2.7.x and 3.x) installed, so I need to use "python3" argument for env. AFAIR usually distros link different names to different binaries, so "env python" will run python2.7 on my system, "env python3" (also python33, or smth like that) will run p3k, and "env python2" (also python27, etc) will run python 2.7.x. Declaring which version of interpreter should be used seems like a good idea too.
I came across this problem editing my code on Windows, checking it in with git, and checking out and running it on Linux.
My solution was: tell git to Do The Right Thing. I issued this command on the Windows box:
git config --global core.autocrlf true
Modified the files and checked them in; voila, no such problem any more.
As discussed on the Git documentation.