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?
En Fri, 23 Mar 2007 01:47:22 -0300, John Pye [EMAIL PROTECTED] escribió: 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 :-) I can think of two ways: - Define a Python function to do that, and test the platform just there. Something like that: def exportable_file(f): if we_are_working_on_windows: import msvcrt return msvcrt.get_osfhandle(f.fileno()) else: return f And replace all places where a Python file goes into a C extension, with exportable_file(f) - Define your own file class, inheriting from file, and store that handle as an attribute class my_file_class(file): def __init__(self, name, mode=r, buffering=-1): file.__init__(self, name, mode, buffering) self.handle = msvcrt.get_osfhandle(self.fileno()) But I've not checked this; I'm not sure if file creation always goes thru this __init__; I assume the file will never change its FILE struct (f_fp member) (uhm, is there any way to re-open a file?). Perhaps this approach has many assumptions to be usable at all - uh, forget it. -- Gabriel Genellina -- 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?
En Fri, 23 Mar 2007 10:07:30 -0300, John Pye [EMAIL PROTECTED] escribió: 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. 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. -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
On 22/03/2007 3.13, John Pye 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? Have a look here: http://www.mingw.org/MinGWiki/index.php/GccStatus 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!) 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. -- Giovanni Bajo -- 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 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! 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? There is also a need to be able to query the *current state* of the gccmrt option. Right, I'll add that. 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. -- Giovanni Bajo -- 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?
John Pye wrote: 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? std::iostream triggers this, IIRC the last time I ran into this problem. Are you saying that I can't make your GCC tools work until the MinGW runtime is patched? Not with that particular extension module. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
En Wed, 21 Mar 2007 03:35:09 -0300, John Pye [EMAIL PROTECTED] escribió:
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.
Try this. It's based on the example_nt extension module.
--- begin example.c ---
#include io.h
#include fcntl.h
#include stdio.h
#include windows.h
#include Python.h
static void externalfunction(FILE* f)
{
// This is a fake external function that receives a FILE*
printf(In externalfunction\n);
fprintf(f, Hello from externalfunction!\n);
}
static void wrapper(DWORD osfhandle)
{
// This is a wrapper around externalfunction; receives an OS handle
// for an open file, builds a FILE structure, and calls externalfunction
FILETIME lw;
SYSTEMTIME st;
FILE* f;
// This call is just to show that osfhandle is actually a Windows handle
// as if one had used CreateFile(...) by example
printf(Using osfhandle with GetFileTime\n);
GetFileTime((HANDLE)osfhandle, NULL, NULL, lw);
FileTimeToSystemTime(lw, st);
printf(LastWrite %d-%d-%d %02d:%02d:%02d.%03d\n, st.wYear, st.wMonth,
st.wDay, st.wHour, st.wMinute, st.wSecond, st.wMilliseconds);
// Now build a FILE struct from the received handle
f = fdopen(_open_osfhandle(osfhandle,_O_APPEND),a);
externalfunction(f);
fflush(f); // ensure all buffers are written
}
static PyObject *
filetest(PyObject *self, PyObject *args)
{
DWORD handle;
if (!PyArg_ParseTuple(args, I, handle))
return NULL;
printf(Received handle: %d\n, handle);
wrapper(handle);
printf(Done\n);
Py_INCREF(Py_None);
return Py_None;
}
static PyMethodDef example_methods[] = {
{filetest, filetest, 1, filetest doc string},
{NULL, NULL}
};
void
initexample(void)
{
Py_InitModule(example, example_methods);
}
--- end example.c ---
--- begin test.py ---
f = open(output.txt,w)
f.write(Hello from python!\n)
# ensure all buffers are written before calling the external function
f.flush()
import msvcrt
fh = msvcrt.get_osfhandle(f.fileno())
print handle=,fh
import example
# calling example.filetest using the OS handle
example.filetest(fh)
f.close()
f = open(output.txt,r)
print output.txt:
print f.read()
f.close()
--- test.py ---
Build example.dll and rename it example.pyd; copy test.py to the same
directory.
Running test.py gives:
C:\APPS\Python24\PYTHON~1.2\TEST_M~1\Releasepython24 test.py
handle= 1988
Received handle: 1988
Using osfhandle with GetFileTime
LastWrite 2007-3-23 04:25:08.000
In externalfunction
Done
output.txt:
Hello from python!
Hello from externalfunction!
--
Gabriel Genellina
--
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: 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: How to receive a FILE* from Python under MinGW?
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 -- 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?
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. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] [EMAIL PROTECTED] -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
En Wed, 21 Mar 2007 01:30:34 -0300, John Pye [EMAIL PROTECTED] escribió: 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 A FILE struct usually *contains* a file descriptor, among other things. But I think the FILE struct is opaque and not specified. Perhaps one should go even at a lower level, using open_osfhandle and get_osfhandle. (From python you can use the msvcrt module). See http://msdn2.microsoft.com/en-us/library/kdfaxaay(VS.71).aspx h=get_osfhandle(f.fileno()) returns a Windows file handle that you can pass around. On the Mingw side: fd=open_osfhandle(h); FILE *f=fdopen(fd) 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. Exactly; the idea is not to pass a foreign FILE struct, but to *contruct* another one based on an existing open file; this is what fdopen does. If there is more to your suggestion that I'm not seeing, please clarify. Have you tried this with MinGW actually? No, but I'm rather confident it should work... as always, it can fail miserably :) -- Gabriel Genellina -- 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?
En Wed, 21 Mar 2007 02:04:30 -0300, Ross Ridge [EMAIL PROTECTED] escribió: 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. Using get_osfhandle on that pseudo-descriptor gives a Windows file handle; that handle should be equivalent (that is, it has a similar role: identifies an open file uniquely inside a process, and is independent on the C runtime library) -- Gabriel Genellina -- http://mail.python.org/mailman/listinfo/python-list
Re: How to receive a FILE* from Python under MinGW?
En Wed, 21 Mar 2007 01:58:05 -0300, John Pye [EMAIL PROTECTED] escribió: 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. Just an integer. But as Ross Ridge has pointed out, it's not an OS thing on Windows, it's faked by the C runtime. 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? From Python, calling the fileno() method. From C, using fileno(PyFile_AsFile(your_file_object)) And then, using get_osfhandle(fd) 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 Just try it and let us know what happens! :) 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? It's too late (for me) now, but if you can't make it work I'll try an example tomorrow. -- Gabriel Genellina -- 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
Re: How to receive a FILE* from Python under MinGW?
On 20 Mar 2007 23:12:45 -0700, John Pye [EMAIL PROTECTED] wrote: 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...? You could try using dumpbin and dlltool to generate an import library for gcc from msvcrt71.dll. Perhaps this might work... I have never tried it. Search the web for mingw dumpbin dlltool. HTH JP -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
