> Well, ... I've managed to crash python by using an "ostream" rather than
> "printf". The code is below. If I replace the std::cout with a printf
> the code works fine. The symptom is that the cout is flushed to the
> console as it should be, then the python shell hangs. A few seconds
> later a "send error report to microsoft" dialog comes up. Here's some
Hmm... I'm not sure why one would work and the other would fail. I
bet the cout << method would work with some python interpreters, but
not others.
I just put a cout << " luminance set to " << luminance; in my
extension (of a wxPython gui app.) and it worked fine. I'm running
mine from Visual Slickedit, so my stdout is getting redirected in a
passive way to an output window in slickedit.
The command line interpreter you get when you just type python at a
command prompt is pretty simple and forgiving about things like these,
but it does assume it has control of stdout. Other times, the gui
command lines like Pythonwin or wxWidgets PyCrust seem more
forgiving. PyCrust actually (if I remember right) redirects stdout so
your cout << "hi" might end up in a tab at the bottom of PyCrust (the
output window.)
I do usually keep my C++ extensions from doing anything but returning
values to python. Since I'm using wxWidgets in C++ and wxPython too,
I can do wx.LogTrace or wx.LogError at both the C++ and python levels
when I want to avoid trying to set up a debugger.
Another trick is to use C++ test projects (using cppunitlite) until I
get the C++ code working just right, and then create my swig .i files,
and then test a bit more interactively from Python, and I'm done. If
I have to debug something or print to stdout, then I'll do it from the
C++ unit tests.
It's not too strange to crash the python interpreter from an
extension. My most common problem is to create a C++ class (A) from
python, hand it to another C++ class (B), and then return from the
function. Python doesn't know that Class B has a pointer to class A,
so it thinks it should delete class A, and then I get a crash when
class B tries to dereference it. There are two solutions, if you want
python to handle class A's lifetime, then you just hold on to a
variable that points to it. If you want C++ to manage its lifetime,
then you can do a = A(); a.thisown=False. Thisown is a swig thing
that keeps python from deleting the C++ class.
But you aren't using swig (yet) so this is only relevent as far as
showing the one thing you have to be aware of. Without swig, it's
just being concious of when to Refrence and Unref() certain variables.
-Jim
On 6/16/06, Chris Botos <[EMAIL PROTECTED]> wrote:
> James Carroll wrote:
> >> Thanks for your responses. I went ahead and tried MinGW. I was able to
> >> build and use screengrabber and other examples. I also used it as an
> >> example and created successfully a very simple "hello python" extension.
> >
> > Fantastic! they must be more (binary) compatable than I thought.
>
> Well, ... I've managed to crash python by using an "ostream" rather than
> "printf". The code is below. If I replace the std::cout with a printf
> the code works fine. The symptom is that the cout is flushed to the
> console as it should be, then the python shell hangs. A few seconds
> later a "send error report to microsoft" dialog comes up. Here's some
> of the information it provided, in addition to saying it was an
> unhandled exception:
> Error Signature:
> AppName: python.exe AppVer: 0.0.0.0 ModName: ntdll.dll
> ModVer: 5.1.2600.2180 Offset: 00018fea
>
> I'm using
> Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310 32 bit (Intel)] on
> win32; MinGW Developer Studio 2.05.
> Does anyone know what I'm doing wrong?
> - Chris
>
>
> #include <Python.h>
> #include <iostream>
>
> static PyObject*
> spam_boo(PyObject* self, PyObject* args)
> {
> std::cout << "Boo!\n" << std::endl;
> // PYTHON CRASHES HERE <<<<<<<<<<<<<<<<<<<<<<<<<
> return Py_BuildValue("s", "boo: I'm done.\n");
> }
>
> static PyMethodDef SpamMethods[] = {
> {"boo", (PyCFunction)spam_boo, METH_VARARGS, ""},
> {NULL, NULL, 0, NULL}
> };
>
> PyMODINIT_FUNC
> initspam(void)
> {
> Py_InitModule("spam", SpamMethods);
> }
>
>
_______________________________________________
Python-win32 mailing list
Python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
