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
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 mu
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 in
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 t
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 ther
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 nee
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 mod
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 too
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
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!
>
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
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/GccWinBin
On 22/03/2007 3.46, Carl Douglas wrote:
> Hi Giovanni,
>
> I was wondering if gccmrt can be used with older 3.x versions of GCC?
>
> Thanks
I think so, but I have not tried it. You just need to copy gccmrt to the bin
directory, and then copy "libmsvcrt.a" into "libmsvcr60.a", and "libmsvcrtd.a
On 3/22/07, Giovanni Bajo <[EMAIL PROTECTED]> wrote:
> On 21/03/2007 6.49, Carl Douglas wrote:
>
> > Hi John,
> >
> > In my case, all I needed was a PyFile_AsFile to get the File *.
> > However I found that Python errors going to stdout/stderr were not
> > being redirected properly when my code was
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.devel
On 21/03/2007 6.49, Carl Douglas wrote:
> Hi John,
>
> In my case, all I needed was a PyFile_AsFile to get the File *.
> However I found that Python errors going to stdout/stderr were not
> being redirected properly when my code was linking to a different
> version of the CRT than the build of Py
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
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
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 P
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__
> PyFileObje
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 poi
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.
>
>
Hi John,
In my case, all I needed was a PyFile_AsFile to get the File *.
However I found that Python errors going to stdout/stderr were not
being redirected properly when my code was linking to a different
version of the CRT than the build of Python I was using.
In the end, I came up with one of
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. Wi
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*
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 emulat
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 cha
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 cha
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.
Yo
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 an
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 (PyFileObje
31 matches
Mail list logo
