views:

66

answers:

2

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.

+1  A: 

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?

Ned Batchelder
Aye, I did not build the Stackless Python 3.1 library my self. I'd read that the issue could very well be the use of FILE*s from different runtimes, thus why the workaround was to allow the Python library to create the FILE* and return it for use as an argument to the function. So then, have I no option but to acquire the source and build Stackless Python 3.1 myself?
Sion Sheevok
If you can build your C code, then you shouldn't have any difficulty with the Stackless code.
Ned Batchelder
+2  A: 

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.

Jack Kelly
Well, that's where I'm running into trouble. I know the C runtime is different. I'm using Visual Studio 2010 and I'm quite certain most Python binaries are built with Visual Studio 2008. I've been trying to build the Stackless Python 3.1 source, but I'm not entirely sure which libraries, DLLs, and headers are needed. Not to mention there are some issues regarding some of the extension modules not building due to missing files. The provided batch file to build them depends on several other missing files, like having SVN installed.
Sion Sheevok
@Sion: Unfortunately, there's nothing more I can really offer besides saying "check the docs" and "good luck". I don't have access to a Windows development machine, let alone VS2010. Is there any way to write a small wrapper for the relevant parts of stdio that's built with the correct visual studio version?
Jack Kelly
The help is appreciated none the less, though at this point even the same compiler and runtime have had no effect on solving the issue. I may very well have to try and contact the developers or other Python gurus directly.
Sion Sheevok
Good catch with the differing runtimes, a common problem on Windoze, with mix and match compilers.
Matt Joiner