[issue4709] Mingw-w64 and python on windows x64
John Pye added the comment: This bug is still present in Python 2.7.5 on Windows 64-bit . I am currently providing the following instructions for MinGW-w64 users wanting to link to Python27.dll: http://ascend4.org/Setting_up_a_MinGW-w64_build_environment#Setup_Python_for_compilation_of_extensions -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4709 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
John Pye j...@curioussymbols.com added the comment: Martin, Ralf is right and my as previously linked is about building a python extension. I should have been more explicit about that. FWIW I found that the configure scripts on MinGW-w64 generally work fine if you add a --build=x86_64-w64-mingw32 argument on the ./configure command line. Then you should only add /mingw/bin to your path (and edit /etc/fstab to map c:/mingw64 to /mingw). Adding those subdirectories to the PATH doesn't seem to be successful; I suspect that those binaries are off the standard path for some reason, eg internal use by GCC only, or something (GCC seems to do some clever tricks with relative paths, so I'm sure it's important that you use the correct starting executable). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4709 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4709] Mingw-w64 and python on windows x64
John Pye j...@curioussymbols.com added the comment: Hi Martin I have documented a build process for a Python package on MinGW-w64, including a requirement that this patch be applied. You might want to revisit it, given that your attempt to reproduce this bug earlier was unsuccessful. http://ascend4.org/Building_ASCEND_for_64-bit_Windows Please let me know if you're looking at it and if there's anything that needs to be clarified. Cheers JP -- nosy: +jdpipe ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4709 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: What was that web interaction library called again?
Harald Korneliussen wrote:
Hi,
I remember I came across a python library that made it radically
simple to interact with web sites, connecting to gmail and logging in
with four or five lines, for example. I thought, that's interesting,
I must look into it sometime.
I was looking for something like this recently too. I don't believe
there is anything in the Python world quite as staggeringly
well-designed as the SimpleBrowser component nested within the
SimpleTest framework for PHP. If there is, I would like to know.
http://simpletest.sourceforge.net/en/web_tester_documentation.html
Here is a code snippet:
class TestOfLastcraft extends WebTestCase {
...
function testContact() {
$this-get('http://www.lastcraft.com/');
$this-clickLink('About');
$this-assertTitle(new PatternExpectation('/About Last Craft/'));
}
}
--
http://mail.python.org/mailman/listinfo/python-list
subprocess.Popen output to file?
Hi all I am trying to set up a python script to manage backups of a mysql database the 'right way' using pipes. I want to send the output of the 'mysqldump' command to a file. Using a normal shell script this would be easy using a operator. What is the efficient and best way to do this using pure python, bearing in mind that it will be too much data to keep in memory? I presume using the subprocess module, but how to get the output to a file? It's not really documented, AFAICS. Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
On Mar 24, 5:37 am, Gabriel Genellina [EMAIL PROTECTED] wrote: En Fri, 23 Mar 2007 16:34:22 -0300, Gabriel Genellina [EMAIL PROTECTED] escribió: What about calling mscvrt_get_osfhandle from inside the SWIG wrapper? I tried this but it seemed that the function was not exported to the DLL. The idea is to separate both worlds - _get_osfhandle must be called from the C runtime used by Python, not the one linked to your extension. Ah, but you could import the msvcrt module and get it from there. *ONLY* get_osfhandle. The other function, open_osfhandle, must be from the runtime used by your extension. -- Gabriel Genellina Yes, that was what I was hoping might be possible. Have not had any luck with that yet though. Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
On Mar 23, 7:48 pm, Gabriel Genellina [EMAIL PROTECTED] wrote: And replace all places where a Python file goes into a C extension, with exportable_file(f) What about calling mscvrt_get_osfhandle from inside the SWIG wrapper? I tried this but it seemed that the function was not exported to the DLL. Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
On Mar 22, 7:23 pm, Giovanni Bajo [EMAIL PROTECTED] wrote: I personally don't use MSYS so I don't know exactly. I use SCons too, and I simply run it from the normal command prompt. I *believe* it's sufficient to unpack MSYS somewhere (you can either unpack it *over* the directory where you installed my GCC package, or somewhere else, I believe it works either way); since the GCC binaries are added to the system PATH by the installer, you should able to run it anyway. You can try by simply invoking gcc -v at the MSYS prompt and see if it's picking up the right version of GCC. I would appreciate if you give some feedback about this. I would like to incorporate your findings on the webpage. Hi Giovanni I downloaded your package and installed it in c:/mingw1. It complained that it could not detect Python, although I have Python 2.4 installed on my system (did you check HKCU as well as HKLM, perhaps?) I note that the gccmrt utility does not work from MSYS. You will need to provide a shell-script equivalent version, in order for that to be useful for MSYS users. So I opened a cmd prompt and ran the command, then restarted my MSYS session. There is also a need to be able to query the *current state* of the gccmrt option. Next I built my code. It all compiled OK, all the way through to my NSIS bundle. So that was nice. It includes gfortran, flex, bison, SWIG/ Python and Tcl/Tk linkage: a bit of a coup. BUT when I try to run my program, I get a windows error msgbox, python.exe - Entry Point Not Found: The procedure entry point _ctype could not be located in the dynamic link library msvcr71.dll. I don't know what the cause of that missing symbol could be, unless it has something to do with the fact that I am linking with -lgfortran. As well as the python module that fails to load (above) I also have a Tcl/Tk based executable which crashes on launch. Also seems to be something with msvcr71, but I can't tell for sure. Have you got any ideas? -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
On Mar 23, 10:59 am, Giovanni Bajo [EMAIL PROTECTED] wrote: On 22/03/2007 15.34, John Pye wrote: I downloaded your package and installed it in c:/mingw1. It complained that it could not detect Python, although I have Python 2.4 installed on my system (did you check HKCU as well as HKLM, perhaps?) E you're totally right! I'll have that fixed! Great. I'll be looking out for a bugfix release very shortly then ;-) I note that the gccmrt utility does not work from MSYS. You will need to provide a shell-script equivalent version, in order for that to be useful for MSYS users. So I opened a cmd prompt and ran the command, then restarted my MSYS session. Yes, I don't use MSYS. I'll attempt something... any idea how to ship both versions and still having the right one picked up depending on which shell you're using? Maybe it's just a matter of extensions? Yes, just add a file 'gccmrt' with no extension, and put '#!/bin/sh' in the first line, I'd say. And then whatever the script actually needs to do -- hopefully it's pretty simple. If you need to be tweaking the registry perhaps it would be better to just write a little binary .exe that can be used both my cmd and sh users. There is also a need to be able to query the *current state* of the gccmrt option. Right, I'll add that. Great, that would be a help. Next I built my code. It all compiled OK, all the way through to my NSIS bundle. So that was nice. It includes gfortran, flex, bison, SWIG/ Python and Tcl/Tk linkage: a bit of a coup. BUT when I try to run my program, I get a windows error msgbox, python.exe - Entry Point Not Found: The procedure entry point _ctype could not be located in the dynamic link library msvcr71.dll. In msvcrt71.dll, there is no _ctype (see declaration at line 111 of include\ctype.h). There is only _pctype. What if you comment the declaration at line 111? I wonder what it's bringing in _ctype. Anyway, it looks like mingw-runtime does not support this _ctype change between mscvrt.dll and msvcr71.dll. These changes should probably be represented in the forms of #ifs checking __MSVCRT_VERSION__. I'm not even sure that __MSVCRT_VERSION__ is being set correctly.. that is something gccmrt should eventually take care of, but for this specific _ctype problem you probably need to submit a patch to mingw-runtime. I can guide you through it though... I don't have much time in these days though. Sorry, I'm not clear on this and will need a bit more help. I'm not even sure where this _ctype dependency could be coming from -- do you have any ideas? Are you saying that I can't make your GCC tools work until the MinGW runtime is patched? Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
On Mar 23, 3:33 pm, Gabriel Genellina [EMAIL PROTECTED] wrote: import msvcrt fh = msvcrt.get_osfhandle(f.fileno()) .. example.filetest(fh) f.close() Cool, that looks great, Gabriel. But is there any way I can hide the get_osfhandle call inside my Python module? That way I wouldn't need to request end users to make contorted 'if platform.system()==Windows' calls everywhere. Maybe this *is* workable, after all :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: splitting perl-style find/replace regexp using python
Thanks all for your suggestions on this. The 'splitter' idea was particularly good, not something I'd thought of. Sorry for my late reply. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
On Mar 22, 10:55 am, Giovanni Bajo [EMAIL PROTECTED] wrote: I suggest people to try my GCC 4.1.2 binary installer for Windows which fully integrates with Python and has scripts in place to solve the MSVCR71.DLL problem. It was announced on this very list a few days ago: http://www.develer.com/oss/GccWinBinaries Hi Giovanni, Thanks very much for that suggestion. It looks like you have done some good work on addressing this problem. I wonder if you might be able to expand on what those 'serious problems' with GCC 4.x on the Windows platform are? Also, can you comment on how one might use your compiler bundle with MSYS? In particular, I like to run SCons from an MSYS prompt. Assuming I don't want to kill my old MinGW and Cygwin installations, how do you recommend that one proceeds to set up a working GCC 4 environment on Windows? (I haven't downloaded it just yet; I'm on Linux today!) Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
Re: [Swig-user] How to receive a FILE* from Python under MinGW?
Hi Carl
I'm not sure that your snippet really solves my problem. As far as I can
see from, you're just passing a filename instead of a file pointer,
right? And then you're using the Python fopen-equivalent
(PyFile_FromString) This is not an option for me, as I want to pass the
FILE* from Python and all the way into into a existing shared-library
code. I can't change the latter; it must work ok with standard fprintf
(etc) functions.
If I've missed something, perhaps you could clarify a little bit more on
how it is that you're overcoming the FILE* problem?
Cheers
JP
See also
http://groups.google.com/group/comp.lang.python/browse_frm/thread/7b69b34240169f7e/ac8fae1b61832f51?lnk=stq=file+mingw+pythonrnum=30#ac8fae1b61832f51
And
http://mail.python.org/pipermail/python-list/2007-March/430695.html
http://groups.google.com/group/comp.lang.python/browse_frm/thread/6d7569e7fd996daf/
http://groups.google.com/group/comp.lang.python/browse_frm/thread/17558adbc053f26d/
Carl Douglas wrote:
Hi John,
I had exactly this problem... use the PyFile_AsFile function. Below
is a code snippet from my project:
// Thank you: http://www.ragestorm.net/tutorial?id=21#8
PyObject* PyFileObject = PyFile_FromString(ofn.lpstrFile, r);
if (PyFileObject == NULL)
{
PyErr_Print();
PyErr_Clear();
return false;
}
// Because microsoft C runtimes are not binary compatible, we
can't
// just call fopen to get a FILE * and pass that FILE * to
another application
// or library (Python25.dll in this case) that uses a
different version
// of the C runtime that this DLL uses. Using PyFile_AsFile is a
work-around...
if (PyRun_SimpleFile(PyFile_AsFile(PyFileObject),
ofn.lpstrFile) == -1)
{
PyErr_Print();
PyErr_Clear();
}
Py_DECREF(PyFileObject);
For the full source of my SWIG/Python project, poke around here:
http://l3dtpython.googlecode.com/svn/trunk/cdPython/
Hope that helps.
On 3/21/07, John Pye [EMAIL PROTECTED] wrote:
Hi all
There is fairly well-known problem on MinGW with passing FILE pointers
to Python. The problem seems to be that Python depends on a different
version of msvcrt*.dll to that which MinGW depends on, and these
different C runtimes provide different FILE implementations.
The upshot of that seems to be that file objects created in Python via
the 'file(...)' command can't safely be used in a SWIG module. It can be
done perfectly (using SWIG typemap and PyFile_AsFile) on Linux but it
fails with a segfault on Windows.
What is the best possible workaround for this? Surely someone must have
found a satisfactory solution to this problem?
Cheeers
JP
--
John Pye
Department of Mechanical and Manufacturing Engineering
University of New South Wales, Sydney, Australia
http://pye.dyndns.org/
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
On Mar 21, 3:15 pm, Gabriel Genellina [EMAIL PROTECTED] wrote: En Wed, 21 Mar 2007 00:46:03 -0300, John Pye [EMAIL PROTECTED] escribió: This is not an option for me, as I want to pass the FILE* from Python and all the way into into a existing shared-library code. I can't change the latter; it must work ok with standard fprintf (etc) functions. You can get the file descriptor from the Python file object using its fileno() method. The file descriptor lives at the OS level, so it's safe to pass around. You can regenerate a new FILE struct (using the other runtime library) with fdopen. -- Gabriel Genellina Hi Gabriel Are you sure about this? My understanding is that 'fileno' is just a FILE* cast to an integer. So it's a pointer to something (check out stdio.h to see what it points to). Problem is (AFAICT) that Python 2.4 uses a different version of the C runtime DLL (MSVCRT*.DLL) to that which MinGW links against. And it turns out that the different C runtime libraries have incompatible implementations of the FILE struct. And therefore if you try to pass a FILE* (fileno?) from Python to MinGW you will get a segfault. If there is more to your suggestion that I'm not seeing, please clarify. Have you tried this with MinGW actually? Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
On Mar 21, 3:15 pm, Gabriel Genellina [EMAIL PROTECTED] wrote: En Wed, 21 Mar 2007 00:46:03 -0300, John Pye [EMAIL PROTECTED] escribió: This is not an option for me, as I want to pass the FILE* from Python and all the way into into a existing shared-library code. I can't change the latter; it must work ok with standard fprintf (etc) functions. You can get the file descriptor from the Python file object using its fileno() method. The file descriptor lives at the OS level, so it's safe to pass around. You can regenerate a new FILE struct (using the other runtime library) with fdopen. -- Gabriel Genellina Hmm. Reading this again I think I understand properly now. The 'fileno' is really *not* the same thing as the FILE* pointer cast to an integer. It is a lower-level structure. The question is now, if I don't want to modify my *python* code, how do I get at the 'fileno' property of my PyFileObject? Also, are there consequences for using this approach of regenerating the FILE struct? For example if I have the following: F = os.tmpfile() F.write(some data) F.seek(0) myswigmodule.dosomething(F) F.seek(0) S = F.read() print S I don't know enough about this low-level file handling to really understand the implications of what you are proposing -- perhaps you could explain a little? Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
On Mar 21, 4:04 pm, Ross Ridge [EMAIL PROTECTED]
wrote:
Gabriel Genellina [EMAIL PROTECTED] wrote:
You can get the file descriptor from the Python file object using its
fileno() method. The file descriptor lives at the OS level, so it's safe
to pass around.
Not under Windows. Windows doesn't have Unix-like descriptors, so the
C runtime emulates them.
I am trying the following... any thoughts?
%typemap(in) FILE * {
if (!PyFile_Check($input)) {
PyErr_SetString(PyExc_TypeError, Need a file!);
return NULL;
}
%#ifdef __MINGW32__
PyFileObject *fo = (PyFileObject *)$input;
$1 = fdopen(_fileno(fo-f_fp),PyString_AsString(fo-f_mode));
fprintf(stderr,FDOPEN(%d,\%s\)\n,fo-f_fp,PyString_AsString(fo-
f_mode));
%#else
$1 = PyFile_AsFile($input);
%#endif
}
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
On Mar 21, 4:48 pm, John Pye [EMAIL PROTECTED] wrote:
I am trying the following... any thoughts?
%typemap(in) FILE * {
if (!PyFile_Check($input)) {
PyErr_SetString(PyExc_TypeError, Need a file!);
return NULL;
}
%#ifdef __MINGW32__
PyFileObject *fo = (PyFileObject *)$input;
$1 = fdopen(_fileno(fo-f_fp),PyString_AsString(fo-f_mode));
fprintf(stderr,FDOPEN(%d,\%s\)\n,fo-f_fp,PyString_AsString(fo-f_mode));
%#else
$1 = PyFile_AsFile($input);
%#endif
}
Ok, so this didn't work. 'fdopen' returned NULL. I guess that nails
the coffin for the fileno() approach?
Cheers
JP
--
http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
On Mar 21, 4:49 pm, Carl Douglas [EMAIL PROTECTED] wrote: 1) Rebuild Python with a different compiler/linker kit so it links to the same CRT as my project, in your case find a mingw built Python.dll 2) Rebuild [with MSVC] OK, so let's say that I must support EXISTING installations of Python 2.4 on computers I have no control over. And let's say that I detest MSVC and want to push on with MinGW at all costs. What then? I read something about being using '-lmsvcrt71' or '-lmsvcrt' with GCC...? JP -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
Gabriel, if you think you can make an example that works, that would be great. I'm afraid I feel a bit out of my depth and don't have much confidence in this idea. JP -- http://mail.python.org/mailman/listinfo/python-list
Passing a FILE* from Python into a MinGW/SWIG module
Hi all I understand that I can't hope to pass a FILE* from the Windows version of Python into a SWIG module that I've built using MinGW gcc/g+ +, because apparently the FILE* structure are different and incompatible. Is there an official workaround for this? Presumably I need to implement a mingw-compatible version of all the 'file' class in Python, eg import mingw import myswigmodule F1 = mingw.file(newfile.txt,rw) F1.write(somestuff) F1.seek(0) F2 = mingw.tmpfile() myswigmodule.dosomething(F1,F2) F2.seek(0) print F2.read() Has anyone done this? Is there a better way that doesn't require users of my module to adapt? Do I have to use the dreaded MSVS to compile my SWIG module? Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
Re: python/C++ wrapper
Check out this example from NumPy. This would be the way sanctioned by the scipy community, as you benefit from a large library of matrix routines that you can use to prepare/postprocess the data. http://www.scipy.org/Cookbook/SWIG_and_NumPy -- http://mail.python.org/mailman/listinfo/python-list
splitting perl-style find/replace regexp using python
Hi all
I have a file with a bunch of perl regular expressions like so:
/(^|[\s\(])\*([^ ].*?[^ ])\*([\s\)\.\,\:\;\!\?]|$)/$1'''$2'''$3/ #
bold
/(^|[\s\(])\_\_([^ ].*?[^ ])\_\_([\s\)\.\,\:\;\!\?]|$)/$1''b$2\/
b''$3/ # italic bold
/(^|[\s\(])\_([^ ].*?[^ ])\_([\s\)\.\,\:\;\!\?]|$)/$1''$2''$3/ #
italic
These are all find/replace expressions delimited as '/search/replace/
# comment' where 'search' is the regular expression we're searching
for and 'replace' is the replacement expression.
Is there an easy and general way that I can split these perl-style
find-and-replace expressions into something I can use with Python, eg
re.sub('search','replace',str) ?
I though generally it would be good enough to split on '/' but as you
see the \/b messes that up. I really don't want to learn perl
here :-)
Cheers
JP
--
http://mail.python.org/mailman/listinfo/python-list
Re: 'import dl' on AMD64 platform
On Feb 19, 6:30 am, Nick Craig-Wood [EMAIL PROTECTED] wrote: John Pye [EMAIL PROTECTED] wrote: application from running on the Debian Etch AMD64 platform. It seems that the 'dl' module is not available on that platform. The only reason I need the 'dl' module, however, is for the values of RTLD_LAZY etc, which I use with sys.setdlopenflags() in order to make my imported SWIG module share its symbols correctly with more deeply- nested plugin modiles in my C-code layer. I wonder if there is a workaround for this -- perhaps another way to access the values of those RTLD flags? Read stuff out of /usr/include/bits/dlfcn.h ? It seems to be a constant 1 anyway #define RTLD_LAZY 0x1 You could try compiling the dl module by hand. Well yes, and that's the workaround I came up with: for systems that don't provide the 'dl' module, I just default to the values I found on my linux (ubuntu) system. This is a nasty hack however. I wonder if anyone could say why the Debian people left out this important module from their AMD64 platform? Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
'import dl' on AMD64 platform
Hi all I have a tricky situation that's preventing my Python/SWIG/C application from running on the Debian Etch AMD64 platform. It seems that the 'dl' module is not available on that platform. The only reason I need the 'dl' module, however, is for the values of RTLD_LAZY etc, which I use with sys.setdlopenflags() in order to make my imported SWIG module share its symbols correctly with more deeply- nested plugin modiles in my C-code layer. I wonder if there is a workaround for this -- perhaps another way to access the values of those RTLD flags? Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
Re: Catching floating point errors from linked C code
Hi John I think you're right, and I need to place FPE 'brackets' around my code. The thing that was confusing me was that python has division by zero exceptions (for which I assumed fenv.h was being used), but when from python I reach down into my SWIG code and do a 1/0, no SIGFPE is thrown. I will experiment with the _controlfp stuff (and linux equivs) and see how it goes. Thanks for your help. Cheers JP On Jan 25, 5:12 pm, John Nagle [EMAIL PROTECTED] wrote: John Pye wrote: Hi John, On Jan 25, 3:43 pm, John Nagle [EMAIL PROTECTED] wrote: Python is probably running with floating point exceptions disabled, but you can enable them in your C code, and restoring the floating point mode when you leave, if you want. This is probably only worth doing under a debugger, because otherwise you just end up with an aborted instance of Python. So as far as you know, Python doesn't switch stuff like feenableexcept(FE_EXCEPT_ALL)? Does Python use the signal.h internally, or are all its FPEs detected by explicit checks beforehand? I have no idea what state Python leaves the FPU in, but whatever the state is, you can read it, set your own state, and restore the previous state before returning to Python. The last time I had to do this, I used unsigned int oldstate = // make almost all FPU errors fatal _controlfp ((~_EM_INVALID) _CW_DEFAULT, _MCW_EM); ... _controlfp(oldstate); // restore old state on Windows 2000. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Overloading assignment operator
Hi thre, On Jan 24, 5:24 am, Achim Domma [EMAIL PROTECTED] wrote: I want to use Python to script some formulas in my application. Depending on what you're trying to do, you might possibly find it useful to lake a look at the approach used by PyGINAC, which is a symbolic algebra system (in C++) wrapped with some clever python bindings: http://pyginac.sourceforge.net/ Hope that helps, JP -- http://mail.python.org/mailman/listinfo/python-list
Catching floating point errors from linked C code
Hi all I have some C code that is giving me some 'nan' values in some calculations. The C code is wrapped using SWIG to give me a Python module that I am then exercising through a unittest suite. It seems that I should expect the C code to throw floating point exceptions (SIGFPE) and either the whole thing to abort, or for Python to catch the errors and report them. Instead I'm getting neither. I want to be able to track down the exact location of problems in my C code. Is there something that Python does to turn on/off the catching of divide-by-zero errors, eg by manipulating signal.h signal handlers and/or fenv.h settings? Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
Re: Catching floating point errors from linked C code
Hi John, On Jan 25, 3:43 pm, John Nagle [EMAIL PROTECTED] wrote: Python is probably running with floating point exceptions disabled, but you can enable them in your C code, and restoring the floating point mode when you leave, if you want. This is probably only worth doing under a debugger, because otherwise you just end up with an aborted instance of Python. So as far as you know, Python doesn't switch stuff like feenableexcept(FE_EXCEPT_ALL)? Does Python use the signal.h internally, or are all its FPEs detected by explicit checks beforehand? If writing a python module with SWIG, and the module uses Python callbacks, do I need to restore the signal handlers before running the callback, or python do that itself? (These might be questions better asked on the SWIG list I guess) Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
error with import md5
Hi all, I'm doing some convoluted stuff with running a python script from inside a shared library that's running inside a Tcl/Tk interpreter. It's all been going surprisingly well, up until the point where my Python script attempts to import matplotlib, which includes a reference to import md5: I get this error bubbling through: Traceback (most recent call last): File /home/john/ascend/models/johnpye/extpy/extpytest.py, line 5, in ? import matplotlib; File /usr/lib/python2.4/site-packages/matplotlib/__init__.py, line 150, in ? import md5, os, re, shutil, sys, warnings ImportError: /usr/lib/python2.4/lib-dynload/md5.so: undefined symbol: _Py_NoneStruct Is it possible that this could be a bug in the md5 library (Python 2.4.4c1), or does it look like a problem perhaps with RTDL_NOW | RTDL_LAZY stuff? Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
Crash on
Hi all I have a unittest test suite that's testing a fairly large SWIG-wrapped application via Python. All my tests are passing at the moment, but when Python exits, I get the following (shown below). Could anyone please help me to understand what precisely this message means (other than that obviously I have made a mistake with object ownership or INCREF or DECREF somewhere), and what the best way of tracking down the source of the problem might be? Cheers JP -- Ran 63 tests in 3.269s OK python: Modules/gcmodule.c:275: visit_decref: Assertion `gc-gc.gc_refs != 0' failed. process killed by signal 6 program finished with exit code -1 -- http://mail.python.org/mailman/listinfo/python-list
Getting exceptions back from calls to embedded python
Hi all,
I have an application that is using embedded python to offer some
scripting ability. An API is exposed via SWIG, and I am accessing that
API from my embedded python interpreter.
Scripts are present as separate files, and I'm invoking them at present
using the following:
iserr = PyRun_AnyFileEx(f,name,1);
if(iserr){
/* tell the user */
return 1;
}else{
/* all good */
return 0;
}
My question is, if I want to be able to get information about
exceptions that have occurred here (perhaps a syntax error, or an
import error, or perhaps a runtime error), what would be the easiest
way to do this now?
I understand that I'm currently using the 'very high level interface'
for python embedding. What's the easiest next step down that will allow
me to catch exceptions and report them?
Would appreciate any thoughts.
Cheers
JP
--
http://mail.python.org/mailman/listinfo/python-list
embedding python -- windows specify problems
Hi all I have been working on some new code that embeds python in an C application. The embedding is working fine under Linux but crashing under Windows (XP) when I reach the following step. PyRun_AnyFile(f,name); If there's some python exception being thrown by the PyRun_AnyFile call, how can I retrieve it from C? Even when the file (f) being run by Python contains only a 'print' statement, the application still crashes on WinXP. The linking to Python seems to be working OK, and the following C code that precedes the above PyRun_AnyFile statement seems to be working fine: PyRun_SimpleString(import ascpy); PyRun_SimpleString(L = ascpy.Library()); PyRun_SimpleString(print L); Can anyone suggest what some good diagnostic steps would be? My embedding code is at the following link. I'm happy to explain the architecture in more detail if that helps. https://pse.cheme.cmu.edu/svn-view/ascend/code/branches/extfn/models/johnpye/extpy/ Any suggestions very much appreciated! Cheers JP -- http://mail.python.org/mailman/listinfo/python-list
Re: embedding python -- windows specify problems
Hi Fredrik,
Thanks very much for that reply. Your suggestion sounds feasible, I
guess. Taking what you said, and thinking about how I could avoid adding
an additional intepreter step, I thought that I could try the following:
pyfile = PyFile_FromString(name,r);
if(pyfile==NULL){
return 1;
}
f = PyFile_AsFile(pyfile);
PyRun_AnyFileEx(f,name,1);
This seems to work on Linux at least (I'll test it tomorrow on my
Windows machine), and presumably it will work around the problem you
mentioned?
Cheers
JP
Fredrik Lundh wrote:
John Pye wrote:
I have been working on some new code that embeds python in an C
application. The embedding is working fine under Linux but crashing
under Windows (XP) when I reach the following step.
PyRun_AnyFile(f,name);
If there's some python exception being thrown by the PyRun_AnyFile call,
how can I retrieve it from C?
Even when the file (f) being run by Python contains only a 'print'
statement, the application still crashes on WinXP.
the contents and the layout of the FILE structure isn't defined, so
PyRun_AnyFile()
only works if you make sure to open the file using *exactly* the same run
time library
as Python itself uses.
it's usually easier to hand the problem over to the interpreter:
PyRun_SimpleString(execfile('myscript.py')\n);
the same approach can be used to implement custom error handling,
stdout/stderr
redirects, etc.
/F
--
http://mail.python.org/mailman/listinfo/python-list
