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
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
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
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
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
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.
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
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
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
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
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
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:
),
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
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
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
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
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
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
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
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
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
--
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/ #
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
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
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
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++)
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
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,
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:
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
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 =
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
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
33 matches
Mail list logo
