I've been experimenting with embedding different scripting languages in a C++ application, currently I'm trying Stackless Python 3.1. I've tried several tutorials and examples, what few I can find, to try and run a simple script from an application.
Py_Initialize();
FILE* PythonScriptFile = fopen("Python Scripts/Test.py", "r");
if(PythonScriptFile)
{
PyRun_SimpleFile(PythonScriptFile, "Python Scripts/Test.py");
fclose(PythonScriptFile);
}
Py_Finalize();
For some odd reason, running this piece of code results in an access violation at:
PyRun_SimpleFile(PythonScriptFile, "Python Scripts/Test.py");
I've searched online for others with a similar problem and found only one. Their only solution was a workaround that only seems possible in an older version of Python: Creating a python file object and returning the FILE* from that python file object into PyRun_SimpleFile. Such function calls are not available however, the Python 3.1 API creates file objects from a file descriptor and returns file descriptors, but the PyRun_SimpleFile function still requires a FILE*.
I'm at a loss as to how to run any scripts from file, short of loading the entire file into memory manually and running it as a giant string, certainly not a practical solution.
What gives? How can I accomplish this task if the API has an internal error?
Update:
I've managed to build Stackless Python 3.1 from the source and yet the crash remains completely unchanged, despite using the same C runtime library. Both my project and the Stackless Python 3.1 source are built with Visual Studio 2010's C++ compiler and C runtime. I no longer have any inkling as to what might solve this problem, short of modifying Python to use a file name and not a FILE*. Another terrible workaround.
This works for me on Python 3:
PyObject *obj = Py_BuildValue("s", "test.py");
FILE *file = _Py_fopen_obj(obj, "r+");
if(file != NULL) {
PyRun_SimpleFile(file, "test.py");
}
I hope It would be useful.
I was getting a similar crash & did the below:
PyObject* PyFileObject = PyFile_FromString("test.py", "r");
PyRun_SimpleFileEx(PyFile_AsFile(PyFileObject), "test.py", 1);
Note that this was in python 2.7 though. I don't know if the API has changed in 3.x.
Your code works correctly on my installed version of Python 2.6. I also built stackless 3.1.2 from source and it worked correctly. This was with g++ 4.4.3 on Ubuntu 10.04. If you're on windows, you might want to check that both stackless and your code are built against the same C runtime.
This sounds like a problem of mismatched APIs. If your code and the Python runtime were compiled with different compilers, or even different compiler options, then accessing the FILE* could result in an access violation. Can you double-check that you've build your C code properly?
You mention that you're embedding Python into your C++ application. Keep in mind that Python is C code, compiled as C code. Perhaps that is the source of the problem?
If you built your test with VC 2010, you will definitely have problems - VC9 (VS 2008) and VC10 (VS 2010) have mutually incompatible support DLLs that are usually required (implement printf, file i/o and that sort of thing). You cannot mix them if they include the standard libraries, which the python build does.
You always have the option of using gcc (e.g. Cygwin or mingw) or downloading Visual Studio 2008 express, which should work fine for experimentation into python embedding. I have used both with the standard Python 2.7.6 build.
And what about this solution:
Py_SetProgramName(argv[0]);
Py_Initialize();
PyRun_SimpleString("execfile(\"ex30.py\")");
Py_Finalize();
Where ex30.py it the name of the python script I am running.
The below code will execute the test.py module. Python will search the module in the path set. So the path should be handled first.
Py_Initialize();
string path = "Python Scripts/";
//Set the path
PyRun_SimpleString("import sys");
string str = "sys.path.append('" + path + "')";
PyRun_SimpleString(str.c_str());
//Dont use test.py as it actually searches sub module test>>py
PyObject * moduleName = PyUnicode_FromString("test");
PyObject * pluginModule = PyImport_Import(moduleName);
if (pluginModule == nullptr)
{
PyErr_Print();
return "";
}
//Do the executions here
//clean up
Py_DECREF(moduleName);
Py_DECREF(pluginModule);
Py_DECREF(transformFunc);
Py_DECREF(result);
Py_Finalize();
Related
I have some MagickWand code where the MagickReadImage() fails (returns MagickFalse) on one system where it works on the other.
Now there is no exception occuring, MagickGetException() returns an empty string which means no exception if I understood the documentation correctly.
The file I want to open is there, I can open it with other tools under the same user, and the magick_wand I use is not NULL.
The code around the call is essentially this:
// read image
MagickBooleanType status = MagickReadImage(magick_wand, fn_selector);
// make sure it worked
if (status == MagickFalse)
{
char *description;
ExceptionType severity;
description=MagickGetException(magick_wand,&severity);
fprintf(stderr,"%s %s %lu :%s: %u\n",GetMagickModule(),description,severity);
description=(char *) MagickRelinquishMemory(description);
fprintf(stderr, "magickwand couldn't read file %s\n", fn_selector);
exit(1);
}
Is there any way to find out why the function call fails? MagickReadImage() seems to call an internal function which is not easily debuggable, and I don't want to build the MagickWand library myself with added debug stuff if not absolutely necessary.
Using MagickWand version 6.8.9.9 (debian jessie)
Turns out (after going through an strace) the PDF reading part of ImageMagick requires the ghostscript executable (/usr/bin/gs) to be installed on the system. Now when installing ImageMagick via the Debian apt package manager, ghostscript is not a dependency, only a recommend of the Magick library. Unfortunately Magick does not think it's necessary to inform you in any way that a library component is missing when the read call fails.
After installing the ghostscript package, everything works as expected.
My goal is to create a package in R with C++ code: So my questions is how?
I am following the tutorial http://www.stat.columbia.edu/~gelman/stuff_for_blog/AlanRPackageTutorial.pdf on creating an R package containing C++ code. The specific code Im trying to compile and package is exactly as described in the tutorial.
R CMD SHLIB seems to be working creating .dll file.
I can load in R using dyn.load() and test it on simulated data (as described in tutorial)
R CMD INSTALL is where the problem begins. I have done two things encountering two different errors supposedly related:
1) The tutorial says the NAMESPACE file is supposed to contain the code:
useDynLib(XDemo)
export(XDemoAutoC)
When it does R CMD INSTALL fail resulting in error:
Error in inDL(x,as.logical(local), as.logical(now),...): unable to
load shared object 'C:/.../libs/i386/XDemo.dll': Loadlibrary failure:
1% is not a valid Win32-program
2) Removing the above mentioned lines in NAMESPACE file will result in installation of package. I can succesfully load it in R but when I try to use the R function that makes a .C() call to the C++ written function I another error:
library(newpackage)
ls(package:newpackage)
[[1]] "XDemoAutoC"
Warning message:
In ls(package:newpackage) :
‘package:newpackage’ converted to character string
XDemoAutoC(c(1,2,3,4))
Error in .C("DemoAutoCor", OutVec = as.double(vector("numeric", OutLength)), :
C symbol name "DemoAutoCor" not in load table
Im running version R2.15.2 on windows 64-bit and using R64 bit.
I read the following post with a similar problem:
http://r.789695.n4.nabble.com/Include-C-DLL-error-in-C-symbol-name-not-in-load-table-td3464021.html
Except they mention nothing about the NAMESPACE-matter.
Also I read this post:
Problem with loading compiled c code in R x64 using dyn.load
So I am thinking: that based on the fact that I am able to use dyn.load() in Rx64 means that I have succesfully created x64 .dll. Assuming that the NAMESPACE file is supposed to be left as in the tutorial - hopefully fixing the >>not in load table<< error - this would mean I should focus on fixing problem one. This problem seems to be caused by something related to 32-bit. I have used Dependency Walker on the .dll file but I am not sure how to interpret the results
I really don't have any ideas on how to fix this problem so any suggestion on what to do would be welcome?
I think you are doing it wrong. Two quick suggestions:
Read the Writing R Extensions manual written to explain just this: writing R extensions including those with compiled code
Have a look at Rcpp which makes R and C++ extensions, including package building so much easier. Or so we think. Writing a package is as easy as calling Rcpp.package.skeleton(). The documentation in 1) still help.
That said, if R CMD INSTALL fails you may have some mixup in your $PATH. Never ever mix MinGW and Cygwin. Make sure no Cygwin DLLs are found when you build or call R. Path order matters greatly. See the manual for details.
Currently I'm trying to start programming on my new Mac. I installed TextWrangler, and chose C++ as my language of choice; since I have some prior knowledge of it, from when I used Windows.
So, I wrote the ever so common "Hello World" program. Although, when I tried to run it, I got an error:
"This file doesn’t appear to contain a valid ‘shebang’ line (application error code: 13304)"
I tried searching the error code to find out how to fix this, but I couldn't find anything.. I have no idea what a 'shebang' line is... Can someone help me out?
You need to compile it with a compiler first. I assume you tried to run the source file like ./source but C++ doesn't work this way.
With some compilers however, you can provide a shebang-line as the first line of the source file (the #! is known as shebang or crunchbang, hence the name), like so:
#!/path/to/compiler
So that the shell knows what application is used to run that sort of file, and when you attempt to run the source file by itself, the compiler will compile and run it for you. That's a compiler-dependent feature though, so I recommend just plain compiling with G++ or whatever Macs use to get an executable, then run that.
While I wouldn't recommend it for regular C++ development, I'm using a simple shell script wrapper for small C++ utilities. Here is a Hello World example:
#if 0 // -- build and run wrapper script for C++ ------------------------------
TMP=$(mktemp -d)
c++ -o ${TMP}/a.out ${0} && ${TMP}/a.out ${#:1} ; RV=${?}
rm -rf ${TMP}
exit ${RV}
#endif // ----------------------------------------------------------------------
#include <iostream>
int main(int argc, char *argv[])
{
std::cout << "Hello world" << std::endl;
return 0;
}
It does appear that you are trying to run the source file directly, however you will need to compile using a C++ compiler, such as that included in the gcc (GNU Compiler Collection) which contains the C++ compiler g++ for the Mac. It is not included with the Mac, you have to download it first:
from http://www.tech-recipes.com/rx/726/mac-os-x-install-gcc-compiler/ : "To install the gcc compiler, download the xcode package from http://connect.apple.com/. You’ll need to register for an Apple Developer Connection account. Once you’ve registered, login and click Download Software and then Developer Tools. Find the Download link next to Xcode Tools (version) – CD Image and click it!"
Once it's installed, if you are going for a quick Hello World, then, from a terminal window in the directory of your source file, you can execute the command g++ HelloWorld.cpp -o HelloWorld. Then you should be able to run it as ./HelloWorld.
Also, if you're coming from a Visual Studio world, you might want to give Mono and MonoDevelop a try. Mono is a free implementation of C# (and other languages), and MonoDevelop is an IDE which is very similar to Visual Studio. MonoDevelop supports C# and other .NET languages, including Visual Basic .NET, as well as C/C++ development. I have not used it extensively, but it does seem to be very similar to VS, so you won't have to learn new everything all in a day. I also have used KDevelop, which I liked a lot while I was using it, although that's been a while now. It has a lot of support for GNU-style development in C/C++, and was very powerful as I recall.
Good luck with your endeavors!
Links:
Mono: http://mono-project.com/Main_Page
MonoDevelop: http://monodevelop.com/
KDevelop: http://kdevelop.org/
shebang is http://en.wikipedia.org/wiki/Shebang_%28Unix%29.
not sure why your program is not running. you will need to compile and link to make an executable.
What I find confusing (/interesting) is C++ program giving "Shebang line" error. Shebang line is a way for the Unix like operating system to specify which program should be used to interpret the rest of the file. The shebang line usually points to the path of the interpreter. C++ is a compiled language and does not have interpreter for it.
To get the real technical details of how shebang lines work, do a man execve and get that man page online here - man execve.
If you're on a mac then doing something like this on the commandline:
g++ -o program program.cpp
Will compile and link your program into an executable called program. Then you can run it like:
./program
The reason you got the 'shebang' error is probably because you tried to run the cpp file like:
./program.cpp
And the shell tries to find an interpreter to run the code in the file. Because this is C++ there is no relevant interpreter but if your file contains Python or Bash then having a line like this
#!/usr/bin/python
at the 1st line in your source file will tell the shell to use the python interpreter
The lines that start with a pattern like this: #!/.../.../.. is called a shebang line. In other words, a shebang is the character sequence consisting of the characters number sign and exclamation mark (#!).In Unix-like operating systems, when a text file with a shebang is used as if it is an executable, the program loader mechanism parses the rest of the file's initial line as an interpreter directive. The loader executes the specified interpreter program, passing to it as an argument the path that was initially used when attempting to run the script, so that the program may use the file as input data.
I have a C++ application dynamically linked to the Python interpreter. I want to be able to import python modules from a particular directory. I want to modify the PYTHONPATH for my process so that sys.path will include the paths that I added to the PYTHONPATH. That seems to be the way it works according to this documentation:
http://docs.python.org/c-api/intro.html#embedding-python
However, when I print sys.path from Python-land it has the original contents of PYTHONPATH and not the one I set. Here's an example of what I'm doing (using Boost.Python):
int main(int argc, char* argv[])
{
_putenv_s("PYTHONPATH", "C:\\source\\\\modules");
Py_Initialize();
object main = import("__main__");
object global = (main.attr("__dict__"));
exec("import sys\nprint sys.path"), global, global);
}
PS - I know there are other ways to accomplish my goal, but that's not what I'm asking about. I am wondering why Py_Initialize() doesn't use the current value of PYTHONPATH when setting up sys.path. Or perhaps I've misunderstood how it is supposed to work?
I found cross-platform solution. Before invoke any other python code just execute following python lines:
import sys
sys.path.append("C:\\source\\\\modules")
This happens if you're using more than one C runtime library at a time. In this case, your application and the Python DLL are probably linked against different CRTs. Each CRT has its own set of environment variables; changes to the environment made with putenv from one CRT are not visible from getenv calls made with a different CRT.
See the "readEnv" example at http://msdn.microsoft.com/en-us/library/ms235460%28v=vs.80%29.aspx.
You can fix this by making sure to use only a single CRT, but that's tricky in practice. Debug builds of programs typically use debug CRTs (which enable things like heap checks and API assertions); production DLLs, even when used in debugging, typically use MSVCRT, the production, threadsafe version. I've worked around this by disabling the debug CRTs entirely, setting all builds to "multithreaded dynamic", since maintaining separate debug DLLs is too much of a hassle. You lose some debugging capabilities by doing that.
Check out:
void PySys_SetPath(char *path) Set sys.path to a list object of paths found in path which should be a list of paths separated with the platform’s search path delimiter (: on Unix, ; on Windows).
or
Py_SetProgramName(argv[0]); That adds dirname(argv[0]) to your PYTHONPATH for you.
As other people have said, you may be running into a CRT mismatch. I was able to get this to work with Python 2.6 and Visual C++ 2008:
#include "stdafx.h"
#include "Python.h"
int _tmain(int argc, _TCHAR* argv[])
{
_putenv_s("PYTHONPATH", "C:\\source\\\\modules");
Py_Initialize();
PyRun_SimpleString("import sys\nprint sys.path");
PyRun_SimpleString("raw_input()");
return 0;
}
This output:
['C:\\Python26\\lib\\site-packages\\distribute-0.6.13-py2.6.egg', 'C:\\Python26\
\lib\\site-packages\\virtualenv-1.4.9-py2.6.egg', 'C:\\source\\modules', ...
Another option may be to change to that directory, since the current directory typically ends up on the path, e.g.:
_chdir("c:\\");
Py_Initialize();
[...]
which gives me:
['C:\\Python26\\lib\\site-packages\\distribute-0.6.13-py2.6.egg', 'C:\\Python26\
\lib\\site-packages\\virtualenv-1.4.9-py2.6.egg', 'C:\\Windows\\system32\\python
26.zip', 'C:\\Python26\\Lib', 'C:\\Python26\\DLLs', 'C:\\Python26\\Lib\\lib-tk',
'c:\\', ...
You could just do python3 -c "import sys; sys.path.append('C:\Path\To\Modules')"
It is possible that the Python DLL gets its own copy of the environment when it is loaded. Try loading it with LoadLibrary and GetProcAddress after you've changed the environment and see if that changes anything.
#include "Python.h"
int main()
{
Py_Initialize();
PyRun_SimpleString("import sys");
PyRun_SimpleString("sys.path.append(\"<some_path>\")");
return 0;
}
This worked for all python version (2.6, 2.7, 3.1, 3.2, 3.3 and 3.4).
Several notes regarding <some_path>:
It should contain only a single directory. List of directories with valid separators (d:/path1;d:/path2 etc.) is not working
Windows paths like: d:\\path1 will work only for python versions prior to Python 3, for later versions d:\\\\path1 should be used. I'd advice replacing windows path delimiters with unix delimiters. Following code chunk does this.
std::string my_path = "<some_path>";
std::replace(my_path.begin(), my_path.end(), '\\', '/');
A gentle advise:
Don't waste your time trying to modify PYTHONPATH with either of the following API methods if you want to support different python versions:
Py_SetPythonHome() - for python 2 requires an ascii string, for python 3 - a unicode string, but doesn't work reliably for versions greater than 3.1
Py_SetPath() - introduced in python 3, but is buggy (see http://bugs.python.org/issue11320)
In general API methods listed above do not affect after Py_Initialize() call.
I'm trying to embed python within a C++ based programming language (CCL: The compuatational control language, not that any of you have heard of it). Thus, I don't really have a "main" function to make calls from.
I have made a test .cc program with a main, and when I compile it and run it, I am able to import my own python modules and system modules for use.
When I embed my code in my CCL-based program and compile it (with g++), it seems I have most functionality, but I get a RUNTIME error:
ImportError: /usr/lib/python2.6/lib-dynload/_ctypes.so: undefined symbol: PyType_GenericNew
This is the code that is executed at Runtime error.
void FFSim::initCKBot (){
Py_Initialize();
PyRun_SimpleString("execfile('logical.py')");
}
logical.py imports modules, one of which attempts to execute 'from cytpes import *', which throws the runtime error.
Can someone explain this to me and how to go about solving it? It seems like I've linked the objects correctly when compiling the c++ aspect of the code.
Thanks.
The Python runtime is effectively a collection of libraries that your program uses. Those libraries take strings, convert them to Python bytecode and then interpret the bytecode. The error you're getting is that as part of interpreting the program, the Python runtime needs to call a function (PyType_GenericNew), but that function does not exist in the compiled Python runtime on your system. Going off the name of the function, this isn't something you can ignore or workaround. It's a fundamental part of the runtime.
Assuming your PATH is correct, your best solution is to reinstall or rebuild Python. Your installation is missing something important.