Re: Problem embedding Python.
Dave Angel wrote: Brandon Keown wrote: On Oct 27, 7:48 pm, "Gabriel Genellina" wrote: Now that you've solved your problem, revise your conclusion. A file without a path *is* searched in the current working directory - but that directory may not be the one you think it is. -- Gabriel Genellina I'm not sure what you mean. I executed the program from the directory the file was in, they were in the same directory. And when a program executes from a path in CMD in windows, that is supposed to be the CWD. I'm not sure what it would be set to if not that... Gabriel is right. But if you care to get our diagnosis, you need to state your working conditions more clearly. Or perhaps do a bit of debugging on it. For a start, you might do aprint os.curdir right before the open() function to see what the current directory is. Or you could remove the several ambiguities in your paragraph above that starts "I'm not sure..." Maybe show a transcript of your CMD session. And if the python.* that's on your PATH is a batch file, show us the contents of that as well. And if you're running from CMD, or from an interpreter, or from IDLE, or from an IDE, or from Explorer, each one may have its own idea of what to give you for current directory. If you're running the script from a CMD prompt, by just entering the script name and letting Windows find the executable (which is not the script), then you're correct, CWD should be the same as it was in the CMD shell. DaveA OK, I blew it. Instead of re-reading the thread, I relied on memory. So please cancel my last paragraph, and let me try again. The big differences between your working code and the non-working code are three: The non-working code uses relative file name, while the working code uses absolute path. The non-working code uses C's open() call, while the working code changed that to PyFile_FromString(filename, "r") The non-working code uses "w" mode on the open, trashing the file, while the working code uses "r" I'd claim that #3 is your real problem. I doubt that a file open in "w" mode is acceptable to the interpreter, since the first thing that does is truncate the file. Anyway, Gabriel's point (which I poorly elaborated on) about the current directory is still valid. But you should use C calls to see what it is, rather than Python calls. And I'd still like to know how you're launching this executable, this compiled C program. If you're running it from a CMD window, a DOS box, then the current directory is obvious from the prompt. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem embedding Python.
O...K... -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem embedding Python.
Brandon Keown wrote: On Oct 27, 7:48 pm, "Gabriel Genellina" wrote: Now that you've solved your problem, revise your conclusion. A file without a path *is* searched in the current working directory - but that directory may not be the one you think it is. -- Gabriel Genellina I'm not sure what you mean. I executed the program from the directory the file was in, they were in the same directory. And when a program executes from a path in CMD in windows, that is supposed to be the CWD. I'm not sure what it would be set to if not that... Gabriel is right. But if you care to get our diagnosis, you need to state your working conditions more clearly. Or perhaps do a bit of debugging on it. For a start, you might do aprint os.curdir right before the open() function to see what the current directory is. Or you could remove the several ambiguities in your paragraph above that starts "I'm not sure..." Maybe show a transcript of your CMD session. And if the python.* that's on your PATH is a batch file, show us the contents of that as well. And if you're running from CMD, or from an interpreter, or from IDLE, or from an IDE, or from Explorer, each one may have its own idea of what to give you for current directory. If you're running the script from a CMD prompt, by just entering the script name and letting Windows find the executable (which is not the script), then you're correct, CWD should be the same as it was in the CMD shell. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem embedding Python.
On Oct 27, 7:48 pm, "Gabriel Genellina" wrote: > En Tue, 27 Oct 2009 06:36:18 -0300, Brandon Keown > escribió: > > > On Oct 27, 2:47 am, "Gabriel Genellina" > > wrote: > > >> You didn't test for the fopen result; are you sure "test.py" exists in > >> the current directory at the time you run it? > > > Ok, so I assumed that the file, if supplied without a path, would use > > current working directory, which was evidently a false assumption. > > Now that you've solved your problem, revise your conclusion. A file > without a path *is* searched in the current working directory - but that > directory may not be the one you think it is. > > -- > Gabriel Genellina I'm not sure what you mean. I executed the program from the directory the file was in, they were in the same directory. And when a program executes from a path in CMD in windows, that is supposed to be the CWD. I'm not sure what it would be set to if not that... -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem embedding Python.
En Tue, 27 Oct 2009 06:36:18 -0300, Brandon Keown escribió: On Oct 27, 2:47 am, "Gabriel Genellina" wrote: You didn't test for the fopen result; are you sure "test.py" exists in the current directory at the time you run it? Ok, so I assumed that the file, if supplied without a path, would use current working directory, which was evidently a false assumption. Now that you've solved your problem, revise your conclusion. A file without a path *is* searched in the current working directory - but that directory may not be the one you think it is. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem embedding Python.
I found the problem. Evidently as posted on a few other areas of the
internet, this is a common problem when trying to use compilers that
may have different type definitions for (FILE*). Here is workable
solution:
#include
int main(int argc, char* argv[])
{
PyObject* PyFileObject;
char* filename;
Py_Initialize();
filename = "c:\\Patches\\Test\\Debug\\test.py";
PyFileObject = PyFile_FromString(filename, "r");
PyRun_SimpleFile(PyFile_AsFile(PyFileObject), filename);
Py_Finalize();
return 0;
}
--
http://mail.python.org/mailman/listinfo/python-list
Re: Problem embedding Python.
On Oct 27, 2:47 am, "Gabriel Genellina"
wrote:
>
> Crashes, how? Try running inside a debugger to see where it crashes, or at
> least put a few printf.
> You didn't test for the fopen result; are you sure "test.py" exists in the
> current directory at the time you run it?
>
> --
> Gabriel Genellina
Ok, so I assumed that the file, if supplied without a path, would use
current working directory, which was evidently a false assumption. I
put in an if statement to check to see if the pointer was null which
it was. So I fully qualified the path in the test file. Now it
throws an unhandled exception when it goes to execute the line with
PyRun_SimpleFile. The following code yields the errors after it.
#include
int main(int argc, char* argv[])
{
FILE* fp = fopen("c:\\Patches\\Test\\Debug\\test.py","w");
if(fp == NULL)
printf("error");
Py_Initialize();
PyRun_SimpleFile(fp,"test.py");
Py_Finalize();
return 0;
}
"First-chance exception at 0x77d2dbba in Test.exe: 0xC005: Access
violation writing location 0x0014.
Unhandled exception at 0x77d2dbba in Test.exe: 0xC005: Access
violation writing location 0x0014.
First-chance exception at 0x77d2dbba in Test.exe: 0xC005: Access
violation writing location 0x0014.
Unhandled exception at 0x77d2dbba in Test.exe: 0xC005: Access
violation writing location 0x0014."
In the debug output.
This is the call stack (the first line is where execution halted).
Test.exe!main(int argc=1, char** argv=0x006d1b88) Line 9 + 0x15 bytes
Test.exe!__tmainCRTStartup() Line 586 + 0x19 bytes
Test.exe!mainCRTStartup() Line 403
(There is more after this, but it goes back to system calls and
execution is halted here so I thought this was relevant).
--
http://mail.python.org/mailman/listinfo/python-list
Re: Problem embedding Python.
En Tue, 27 Oct 2009 03:25:54 -0300, Brandon Keown
escribió:
I am going to try to embed python in an application, but in simple
testing, I could not get it to work. The following code seems like it
should work, but it crashes, and I have tried several things. What
could I be doing wrong?
#include
int main(int argc, char* argv[])
{
FILE* fp = fopen("test.py","r");
Py_Initialize();
PyRun_SimpleFile(fp,"test.py");
Py_Finalize();
return 0;
}
Crashes, how? Try running inside a debugger to see where it crashes, or at
least put a few printf.
You didn't test for the fopen result; are you sure "test.py" exists in the
current directory at the time you run it?
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
Re: Problem embedding Python...
> C:\DOCUME~1\ANDY~1.MCC\LOCALS~1\Temp/cckhbaaa.o(.text+0x2b):main.cpp: > undefined reference to `_imp__Py_Initialize' These errors indicate that the linker can't find the Python library (python24.lib). > -L"C:\Python24\Lib" I think you want to say -L"C:\Python24\Libs" instead. 'libs' contains the binary lib files, while 'lib' contains the .py library files. -- Want to play tabletop RPGs online? Check out RPZen:http://koboldsoft.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Problem: embedding Python
mmf wrote:
> Hallo!
>
> I tried to use Python from C like it is described in the Python
> Docmentation. So I wrote the following C source file:
>
> #include
> int
> main(int argc, char *argv[])
> {
> Py_Initialize();
> PyRun_SimpleString("print 'Hallo World!'\n");
> Py_Finalize();
> return 0;
> }
>
> I saved it as run.c and tried to compile it using the following
> command:
> gcc run.c
>
> But that always results in a list of errors:
>
> /tmp/cc1tmrPU.o(.text+0x1d): In function `main':
> : undefined reference to `Py_Initialize'
> /tmp/cc1tmrPU.o(.text+0x2a): In function `main':
> : undefined reference to `PyRun_SimpleString'
> /tmp/cc1tmrPU.o(.text+0x32): In function `main':
> : undefined reference to `Py_Finalize'
>
> What am I doing wrong? Can you help me?
>
> Tanks.
>
> Best regards,
> Markus
>
You should link with Python's shared object (replace with your version
of Python):
gcc -o run run.c -I/usr/include/python2.4 -lpython2.4
--
Are you a riddle lover?
Try http://www.pythonchallenge.com
--
http://mail.python.org/mailman/listinfo/python-list
