If you invoke the cpython interpreter with the -i option, it will enter the interactive mode upon completing any commands or scripts it has been given to run. Is there a way, within a program to get the interpreter to do this even when it has not been given -i? The obvious use case is in debugging by interactively inspecting the state when an exceptional condition has occurred.
You want the code module.
#!/usr/bin/env python
import code
code.interact("Enter Here")
Set the PYTHONINSPECT environment variable. This can also be done in the script itself:
import os
os.environ["PYTHONINSPECT"] = "1"
For debugging unexpected exceptions, you could also use this nice recipe http://code.activestate.com/recipes/65287/
The recipe metioned in the other answer using sys.excepthook, sounds like what you want. Otherwise, you could run code.interact on program exit:
import code
import sys
sys.exitfunc = code.interact
The best way to do this that I know of is:
from IPython import embed
embed()
which allows access to variables in the current scope and brings you the full power of IPython.
Related
In the PyInstaller docs they demonstrate the use of eval_statement() and exec_statement() which call eval() or exec() in a new instance of Python. But they don't say why you would want to run your code in a separate instance.
For example, why couldn't their example of:
from PyInstaller.utils.hooks import exec_statement
mpl_data_dir = exec_statement(
"import matplotlib; print(matplotlib._get_data_path())"
)
datas = [ (mpl_data_dir, "") ]
not just be:
import matplotlib
datas = [(matplotlib._get_data_path(), "")]
I've tried doing this with my own library and it doesn't seem to do it any harm. So why the extra complexity? Why do all the other hooks included in PyInstaller use the 1st method?
All the hooks use the first method in case of path and environment manipulations. What happens if matplotlib changes sys.path or some other environmental manipulation that could mess with the build process? Using a separate python instance means this won't happen.
Let's say we have a symbol array of packages packages::Vector{Symbol} = [...] and we want to create a sys image using PackageCompiler.jl. We could simply use
using PackageCompiler
create_sysimage(packages; incremental = false, sysimage_path = "custom_sys.dll"
but without a precompile_execution_file, this isn't going to be worth it.
Note: sysimage_path = "custom_sys.so" on Linux and "custom_sys.dylib" on macOS...
For the precompile_execution_file, I thought running the test for each package might do it so I did something like this:
precompilation.jl
packages = [...]
#assert typeof(packages) == Vector{Symbol}
import Pkg
m = Module()
try Pkg.test.(Base.require.(m, packages)) catch ; end
The try catch is for when some tests give an error and we don't want it to fail.
Then, executing the following in a shell,
using PackageCompiler
packages = [...]
Pkg.add.(String.(packages))
Pkg.update()
Pkg.build.(String.(packages))
create_sysimage(packages; incremental = false,
sysimage_path = "custom_sys.dll",
precompile_execution_file = "precompilation.jl")
produced a sys image dynamic library which loaded without a problem. When I did using Makie, there was no delay so that part's fine but when I did some plotting with Makie, there still was the first time plot delay so I am guessing the precompilation script didn't do what I thought it would do.
Also when using tab to get suggestions in the repl, it would freeze the first time but I am guessing this is an expected side effect.
There are a few problems with your precompilation.jl script, that make tests throw errors which you don't see because of the try...catch.
But, although running the tests for each package might be a good idea to exercise precompilation, there are deeper reasons why I don't think it can work so simply:
Pkg.test spawns a new process in which tests actually run. I don't think that PackageCompiler can see what happens in this separate process.
To circumvent that, you might want to simply include() every package's test/runtests.jl file. But this is likely to fail too, because of missing test-specific dependencies.
So I would say that, for this to work reliably and systematically for all packages, you'd have to re-implement (or re-use, if you can) some of the internal logic of Pkg.test in order to add all test-specific dependencies to the current environment.
That being said, some packages have ready-to-use precompilation scripts helping to do just this. This is the case for Makie, which suggests in its documentation to use the following file to build system images:
joinpath(pkgdir(Makie), "test", "test_for_precompile.jl")
Is it possible to run something similar to a Linux R console (which uses GNU Readline) from within a C++ program using RInside? The best option would be, if such a console would have all the nice features like the autocomplete.
The background:
I have a big solver, which has a RInside-based plugin for running small chunks of R code during a simulation. It would be nice if the user would be able to switch it to "interactive" mode and check things out as they go.
Notice:
1. I cannot just run R as a separate program, as I need it to see my objects and pointers from the main code. 2. I know about callbacks in RInside, but they do not provide any console-like capabilities.
Code: I doubt it will help, but here is my code now: https://github.com/llaniewski/TCLB/blob/RInside/src/Handlers/cbRunR.cpp.Rt
I have .py script that run from the cmd.
I want to execute it in quality center automatically (I understood that is done using the test type VAPI-XP-TEST) and to get indication of '"Pass"/"Fail".
How exactly I can do it?
Thanks.
Check this link: http://alm-help.saas.hpe.com/en/12.50/online_help/Content/UG/t_create_vapixp_scripts.htm
Also, VAPI-XP allows Python script. I have not used Python for VAPI-XP yet, but HP documentation in the above link I believe can help you get up to speed.
Does R provide a similar command for debugging like Matlab's keyboard?
This command provides an interactive shell and can be used in any function.
This gives access to all variables allowing one to verify that the input data is really what it should be (or test why it's not working as expected).
Makes debugging a lot easier (at least in Matlab...).
It sounds like you're looking for browser().
From the description:
A call to ‘browser’ can be included in the body of a function.
When reached, this causes a pause in the execution of the current
expression and allows access to the R interpreter.
It sounds like you're new to debugging in R so you might want to read Hadley's wiki page on debugging.
Have a look at ?recover, this function provides great debugging functionality.