Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
in [Python]
|
Prev: Python GUI for C program [was: ]
Next: Download Microsoft C/C++ compiler for use with Python 2.6/2.7ASAP
From: Thomas Jollans on 6 Jul 2010 19:07 On 07/07/2010 12:38 AM, Martin v. Loewis wrote: >>> - many things which are runtime independent on unix are not on >>> windows (file descriptor: AFAIK, a file descriptor as returned from >>> open can be dealt with in any C runtime on unix) >> >> Are you telling me that file descriptors (it's a flippin int!) can't be >> passed around universally on Windows?? > > There are really three things of concern here: > a) operating system file handles, of type HANDLE (which is an unsigned > 32-bit value); they are not contiguous, and stdin/stdout/stderr may > have arbitrary numbers > b) C runtime file handles, of type int. They are contiguous, and > stdin/stdout/stderr are 0/1/2. > c) C FILE*. > > OS handles can be passed around freely within a process; across > processes, they lose their meaning > > It's the data of types b) and c) that cause problems: the CRT handle 4 > means different things depending on what copy of the CRT is interpreting it. Ah, okay. On UNIX systems, of course, a) and b) are identical. > > It's worse with FILE*: passing a FILE* of one CRT to the fread() > implementation of a different CRT will cause a segfault. > >> And, as has already been said in this thread, this does not concern the >> .net developer, or any developer that sticks to managed code, be it >> .net, CPython, or something-else based. > > Since when is CPython managed code? It's not managed code in the "runs on .net" sense, but in principle, it is managed, in that garbage collection is managed for you.
From: sturlamolden on 6 Jul 2010 19:14 On 7 Jul, 01:07, Thomas Jollans <tho...(a)jollans.com> wrote: > It's not managed code in the "runs on .net" sense, but in principle, it > is managed, in that garbage collection is managed for you. I think you are confusing Python and C code.
From: Thomas Jollans on 6 Jul 2010 19:26 On 07/07/2010 01:14 AM, sturlamolden wrote: > On 7 Jul, 01:07, Thomas Jollans <tho...(a)jollans.com> wrote: > >> It's not managed code in the "runs on .net" sense, but in principle, it >> is managed, in that garbage collection is managed for you. > > I think you are confusing Python and C code. Or somebody's confusing something anyway I meant "CPython based", which, in hindsight, might have not have been clear from the grammatically obfuscated sentence I posted.
From: David Cournapeau on 6 Jul 2010 23:40 On Wed, Jul 7, 2010 at 12:26 AM, Thomas Jollans <thomas(a)jollans.com> wrote: > On 07/07/2010 12:08 AM, David Cournapeau wrote: >> On Tue, Jul 6, 2010 at 6:00 PM, Alf P. Steinbach /Usenet >> <alf.p.steinbach+usenet(a)gmail.com> wrote: >>> There is no *technical* problem creating a compiler-independent C/C++ >>> language binding. >> >> It is quite hard, though, or would require changes in the API to be >> entirely safe. When I asked the question a few months ago to see if we >> could fix those issues once and for all for numpy, the most common >> answer I got was to pass all the related functions in a structure: >> http://stackoverflow.com/questions/1052491/c-runtime-objects-dll-boundaries. >> >> The problem is not compiler, but really C runtimes. By itself, the >> issues are not windows specific (using malloc from one C library and >> one free from another one is trouble everywhere), but on windows: >> Â - multiple C runtimes are *very* common on windows > > I'm also rather sure that it's pretty much impossible to have multiple C > libraries in one process on UNIX, but it's obviously quite possible on > Windows. I am not sure why you think it is not possible. It is rare, though. > >> Â - many things which are runtime independent on unix are not on >> windows (file descriptor: AFAIK, a file descriptor as returned from >> open can be dealt with in any C runtime on unix) > > Are you telling me that file descriptors (it's a flippin int!) can't be > passed around universally on Windows?? Yes. The reason why it does not work on windows is because file descriptor are not "native": in every unix I have heard of, file descriptor are indexes in a table of the process "structure", hence can be shared freely (no dependency on the C runtime structures). On windows, I have heard they are emulated (the native one is the win32 file handle). David
From: Alf P. Steinbach /Usenet on 7 Jul 2010 00:54
* sturlamolden, on 06.07.2010 19:35: > On 6 Jul, 19:09, Thomas Jollans<tho...(a)jollans.com> wrote: > >> Okay, you need to be careful with FILE*s. But malloc and free? You'd >> normally only alloc& free something within the same module, using the >> same functions (ie not mixing PyMem_Malloc and malloc), would you not? > > You have to be sure PyMem_Malloc is not an preprocessor alias for > malloc (I haven't chaecked). Python 3.1.1, file [pymem.h]: PyAPI_FUNC(void *) PyMem_Malloc(size_t); #define PyMem_MALLOC(n) (((n) < 0 || (n) > PY_SSIZE_T_MAX) ? NULL \ : malloc((n) ? (n) : 1)) The problem with the latter that it seems that it's intended for safety but does the opposite... Perhaps (if it isn't intentional) this is a bug of the oversight type, that nobody remembered to update the macro? *** Except for the problems with file descriptors I think a practical interim solution for extensions implemented in C could be to just link the runtime lib statically. For a minimal extension this increased the size from 8 KiB to 49 KiB. And generally with MS tools the size is acceptably small. I think that this would be safe because since the C API has to access things in the interpreter I think it's a given that all the relevant functions delegate to shared library (DLL) implementations, but I have not checked the source code. As a more longterm solution, perhaps python.org could make available the redistributables for various MSVC versions, and then one could introduce some scheme for indicating the runtime lib dependencies of any given extension. Then when installing an extension the installer (distutils package functionality) could just check whether the required runtime is present, and if not give the user the choice of automatically downloading from python.org, or perhaps direct from Microsoft. This scheme would support dependencies on new runtime lib versions not yet conceived when the user's version of Python was installed. Cheers, - Alf -- blog at <url: http://alfps.wordpress.com> |