subject:"Re\: Download Microsoft C\/C\+\+ compiler for use with Python 2.6\/2.7 ASAP"

On 7 Jul, 11:32, Jonathan Hartley tart...@tartley.com wrote:
 Also,
 this would solve the pain of Python developers attempting to
 redistribute py2exe versions of their programs (i.e. they have to own
 a Visual Studio license to legally be able to redistribute the
 required C runtime)

http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bfdisplaylang=en

If this is not sufficient, ask Microsoft for permission or buy a copy
of Visual Studio (any will do, you can rebuild Python).

I don't understand enough to know why Visual
 Studio was chosen instead of MinGW. Can anyone shed any light on that
 decision?

It the standard C and C++ compiler on Windows.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

 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...

Why do you say that? It certainly *does* achieve safety, wrt. to certain
errors, specifically:
- passing sizes that are out-of-range
- supporting malloc(0) on all systems


 Perhaps (if it isn't intentional) this is a bug of the oversight type,
 that nobody remembered to update the macro?

Update in what way?

 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.

If you think that's fine for your extension module (which may well be
the case), go ahead. But then, you could also just link with a different
DLL version of the CRT instead.

 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.

There are certainly more cases than the ones mentioned so far, in
particular the time zone and the locale. The CRT carries global
variables for these, so if you set them in the copy of the CRT that
Python links with, you won't see the change in your extension module -
which may or may not be a problem.

 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.

My preferred long-term solution is to reduce the usage of the C library
in CPython as much as reasonable, atleast on Windows. Memory management
could directly use the heap functions (or even more directly
VirtualAlloc); filenos could be OS handles, and so on. There are
probably limitations to what you can achieve, but I think it's worth trying.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 7 Jul, 06:54, Alf P. Steinbach /Usenet alf.p.steinbach
+use...@gmail.com wrote:

 PyAPI_FUNC(void *) PyMem_Malloc(size_t);

 #define PyMem_MALLOC(n)         (((n)  0 || (n)  PY_SSIZE_T_MAX) ? NULL \
                                 : malloc((n) ? (n) : 1))

I was afraid of that :(



 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.

You still have two CRTs linked into the same process.



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

 I presume this problem would go away if future versions of Python
 itself were compiled on Windows with something like MinGW gcc. Also,
 this would solve the pain of Python developers attempting to
 redistribute py2exe versions of their programs (i.e. they have to own
 a Visual Studio license to legally be able to redistribute the
 required C runtime) I don't understand enough to know why Visual
 Studio was chosen instead of MinGW. Can anyone shed any light on that
 decision?

sturlamolden has already given the primary reason: Python,
traditionally, attempts to use and work with the system vendor's
compiler. On Windows, that's MSC. It's typically the one that best knows
about platform details that other compilers might be unaware of.

In addition, it's also the compiler and IDE that Windows developers (not
just Python core people, but also extension developers and embedders)
prefer to use, as it has quite good IDE support (in particular debugging
and code browsing).

Perhaps more importantly, none of the other compilers is really an
alternative. GCC in particular cannot build the Win32 extensions, since
it doesn't support the COM and ATL C++ features that they rely on (and
may not support other MSC extensions, either). So the Win32 extensions
must be built with VS, which means Python itself needs to use the same
compiler.

Likewise important: gcc/mingw is *not* a complete C compiler on Windows.
A complete C compiler would have to include a CRT (on Windows); mingw
doesn't (cygwin does, but I think you weren't proposing that Python be
built for cygwin - you can easily get cygwin Python anyway). Instead,
mingw relies on users having a CRT available to
them - and this will be a Microsoft one. So even if gcc was used, we
would have versioning issues with Microsoft CRTs, plus we would have to
rely on target systems including the right CRT, as we couldn't include
it in the distribution.

HTH,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 7 Jul, 21:12, sturlamolden sturlamol...@yahoo.no wrote:

  #define PyMem_MALLOC(n)         (((n)  0 || (n)  PY_SSIZE_T_MAX) ? NULL \
                                  : malloc((n) ? (n) : 1))

 I was afraid of that :(

Also observe that this macro is very badly written (even illegal) C.
Consider what this would do:

PyMem_MALLOC(n++)

According to Linus Thorvalds using macros like this is not even legal
C:

http://www.linuxfocus.org/common/src/January2004_linus.html

This would be ok, and safe as long as we use the GIL:

register Py_ssize_t __pymem_malloc_tmp;
#define PyMem_MALLOC(n)\
 (__pymem_malloc_tmp = n, (((__pymem_malloc_tmp)  0 ||
(__pymem_malloc_tmp)  PY_SSIZE_T_MAX) ? NULL \
                                 : malloc((__pymem_malloc_tmp) ?
(__pymem_malloc_tmp) : 1)))


An inline function is a better solution, but not ANSI C standard:

inline void *PyMem_MALLOC(Py_ssize_t n)
{
  return (((n)  0 || (n)  PY_SSIZE_T_MAX) ? NULL
   : malloc((n) ? (n) : 1));
}






-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP


* Martin v. Loewis, on 07.07.2010 21:10:

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...


Why do you say that? It certainly *does* achieve safety, wrt. to certain
errors, specifically:
- passing sizes that are out-of-range
- supporting malloc(0) on all systems


It uses malloc instead of PyMem_Malloc. malloc may well be different and use a 
different heap in an extension DLL than in the Python interpreter and other 
extensions. That's one thing that the docs (rightly) warn you about.




Perhaps (if it isn't intentional) this is a bug of the oversight type,
that nobody remembered to update the macro?


Update in what way?


I was guessing that at one time there was no PyMem_Malloc. And that it was 
introduced to fix Windows-specific problems, but inadvertently without updating 
the macro. It's just a guess as to reasons why the macro uses malloc directly.




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.


If you think that's fine for your extension module (which may well be
the case), go ahead.


I have no comment on that except pointing it out as a somewhat stupid, somewhat 
evil social inclusion/exclusion argument, talking to the audience. Argh. You're 
wasting my time. But anyway, 49 KiB is small by today's standards. For example, 
you get 20 of those in a single MiB, and about 20.000 in a single GiB.




But then, you could also just link with a different
DLL version of the CRT instead.


When I wrote link the runtime lib statically that was an alternative to the 
usual link-as-DLL.


It wouldn't make sense to link the runtime lib statically as an alternative to 
linking it statically.


As for linking to a different /version/ of the CRT, if you really mean that, I 
think that's difficult. It's not necessarily impossible, after all there's 
STLPort. But I think that it must at the very least be rather difficult to do 
with Microsoft's tools, for otherwise people would have employed that solution 
before, and so I wouldn't trust the result, and wouldn't waste the time trying.



Cheers,

- Alf

--
blog at url: http://alfps.wordpress.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP


* sturlamolden, on 07.07.2010 21:12:

On 7 Jul, 06:54, Alf P. Steinbach /Usenetalf.p.steinbach
+use...@gmail.com  wrote:


PyAPI_FUNC(void *) PyMem_Malloc(size_t);

#define PyMem_MALLOC(n) (((n)  0 || (n)  PY_SSIZE_T_MAX) ? NULL \
 : malloc((n) ? (n) : 1))


I was afraid of that :(




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.


You still have two CRTs linked into the same process.


So?


Cheers,

- Alf

--
blog at url: http://alfps.wordpress.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 7 Jul, 21:41, Alf P. Steinbach /Usenet alf.p.steinbach
+use...@gmail.com wrote:

  You still have two CRTs linked into the same process.

 So?

CRT resources cannot be shared across CRT borders. That is the
problem. Multiple CRTs are not a problem if CRT resources are never
shared.




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP


 Also observe that this macro is very badly written (even illegal) C.
 Consider what this would do:
 
 PyMem_MALLOC(n++)
 
 According to Linus Thorvalds using macros like this is not even legal
 C:
 
 http://www.linuxfocus.org/common/src/January2004_linus.html

[Please don't use legal wrt. programs - it's not illegal to violate
the language's rules; you don't go to jail when doing so. Linus said
not allowed]

You are misinterpreting that statement. Linus said that the isdigit
macro was non-conforming, *and meant that specifically for isdigit()*.
That's because the C standard says that isdigit is a function. Under
the as-if rule, you may implement it as a macro as long as nobody can
tell the difference. However, in the presented implementation, there
is a notable difference.

However, the C standard is silent wrt. to PyMem_MALLOC, and it certainly
allows the definition of macros which use the macro arguments more than
once.

 This would be ok, and safe as long as we use the GIL:

The macro is ok as it stands (minus the issues with multiple heaps).
The Python convention is that you clearly recognize PyMem_MALLOC as
a macro, so you should know not to pass parameters with side effects.

 register Py_ssize_t __pymem_malloc_tmp;
 #define PyMem_MALLOC(n)\
  (__pymem_malloc_tmp = n, (((__pymem_malloc_tmp)  0 ||
 (__pymem_malloc_tmp)  PY_SSIZE_T_MAX) ? NULL \
  : malloc((__pymem_malloc_tmp) ?
 (__pymem_malloc_tmp) : 1)))

That would partially defeat the purpose, namely it would require the
compiler to put the size into a variable in memory, and possibly prevent
optimizations from taking place that rely on constant propagation
(depending on how smart the compiler is).

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 7 Jul, 21:47, Martin v. Loewis mar...@v.loewis.de wrote:

 That would partially defeat the purpose, namely it would require the
 compiler to put the size into a variable in memory, and possibly prevent
 optimizations from taking place that rely on constant propagation
 (depending on how smart the compiler is).

Also after reading carefully what Linus said, it would still be
incorrect if n is a complex expression. So, an inline function is the
correct one here.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

 Perhaps (if it isn't intentional) this is a bug of the oversight type,
 that nobody remembered to update the macro?

 Update in what way?
 
 I was guessing that at one time there was no PyMem_Malloc. And that it
 was introduced to fix Windows-specific problems, but inadvertently
 without updating the macro. It's just a guess as to reasons why the
 macro uses malloc directly.

It might indeed be that the function version was introduced specifically
for Windows. However, the macro was left intentionally: both for
backwards compatibility, and for use inside Python itself.

 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.
[...]
 
 When I wrote link the runtime lib statically that was an alternative
 to the usual link-as-DLL.

Ok, I lost the thread. When you said a practical interim solution
you were talking about what problem? I thought the discussion was
about the need to link with the same DLL version as Python.

 It wouldn't make sense to link the runtime lib statically as an
 alternative to linking it statically.

However, it would surely make sense to link with a different DLL than
the one that Python links with, assuming that would actually work.

 As for linking to a different /version/ of the CRT, if you really mean
 that, I think that's difficult. It's not necessarily impossible, after
 all there's STLPort. But I think that it must at the very least be
 rather difficult to do with Microsoft's tools, for otherwise people
 would have employed that solution before, and so I wouldn't trust the
 result, and wouldn't waste the time trying.

It's actually straight-forward (or used to be, until they came up with
the SxS madness). It was actually the case that people did so
unexpectingly, and it seemed to work fine, except that it crashed when
passing FILE*. Then we started explaining that mixing CRTs is risky.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP


* sturlamolden, on 07.07.2010 21:46:

On 7 Jul, 21:41, Alf P. Steinbach /Usenetalf.p.steinbach
+use...@gmail.com  wrote:


You still have two CRTs linked into the same process.


So?


CRT resources cannot be shared across CRT borders. That is the
problem. Multiple CRTs are not a problem if CRT resources are never
shared.


Yeah, but then we're down to file descriptors, C library locales and such as the 
remaining problems.


Cheers,

- Alf

--
blog at url: http://alfps.wordpress.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP


* Martin v. Loewis, on 07.07.2010 21:56:

Perhaps (if it isn't intentional) this is a bug of the oversight type,
that nobody remembered to update the macro?


Update in what way?


I was guessing that at one time there was no PyMem_Malloc. And that it
was introduced to fix Windows-specific problems, but inadvertently
without updating the macro. It's just a guess as to reasons why the
macro uses malloc directly.


It might indeed be that the function version was introduced specifically
for Windows. However, the macro was left intentionally: both for
backwards compatibility, and for use inside Python itself.


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.

[...]


When I wrote link the runtime lib statically that was an alternative
to the usual link-as-DLL.


Ok, I lost the thread. When you said a practical interim solution
you were talking about what problem? I thought the discussion was
about the need to link with the same DLL version as Python.


The main problem that the required MSVC redistributables are not necessarily 
present on the end user's system.




It wouldn't make sense to link the runtime lib statically as an
alternative to linking it statically.


However, it would surely make sense to link with a different DLL than
the one that Python links with, assuming that would actually work.


As for linking to a different /version/ of the CRT, if you really mean
that, I think that's difficult. It's not necessarily impossible, after
all there's STLPort. But I think that it must at the very least be
rather difficult to do with Microsoft's tools, for otherwise people
would have employed that solution before, and so I wouldn't trust the
result, and wouldn't waste the time trying.


It's actually straight-forward (or used to be, until they came up with
the SxS madness). It was actually the case that people did so
unexpectingly, and it seemed to work fine, except that it crashed when
passing FILE*. Then we started explaining that mixing CRTs is risky.


Oh.

Well then. :-)


Cheers,

- Alf

--
blog at url: http://alfps.wordpress.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 7 Jul, 21:47, Martin v. Loewis mar...@v.loewis.de wrote:

 However, the C standard is silent wrt. to PyMem_MALLOC, and it certainly
 allows the definition of macros which use the macro arguments more than
 once.

Ok, I knew there was something odd here. PyMem_Malloc is indeed a
function, whilst PyMem_MALLOC is a deprecated macro.

:)






-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-07 Thread Grant Edwards

On 2010-07-07, Martin v. Loewis mar...@v.loewis.de wrote:

 Also observe that this macro is very badly written (even illegal) C.
 Consider what this would do:
 
 PyMem_MALLOC(n++)
 
 According to Linus Thorvalds using macros like this is not even legal
 C:
 
 http://www.linuxfocus.org/common/src/January2004_linus.html

 [Please don't use legal wrt. programs - it's not illegal to violate
 the language's rules; you don't go to jail when doing so. Linus said
 not allowed]

Nonsense.

The world illegal doesn't mean you'll go to jail.

Legal and illegal are used to indicate conformance or
nonconformace with respect to some set of rules -- be they a
programming language standard, FIFA footbal rules, or Forumula 1
technical regulations.

It's perfectly standard usage to refer to an illegal forward pass in
American football, to illegal tires used during a race, or to an
illegal operation in a program.

-- 
Grant Edwards   grant.b.edwardsYow! I feel like I'm
  at   in a Toilet Bowl with a
  gmail.comthumbtack in my forehead!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-07 Thread Christian Heimes

 Yeah, but then we're down to file descriptors, C library locales and such as 
 the 
 remaining problems.

Don't forget errno! Every CRT might have its own errno thread local. I
don't know how its handled on Windows but I suspect it suffers from the
same problem.

Christia

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 7 Jul, 22:26, Christian Heimes li...@cheimes.de wrote:

 Don't forget errno! Every CRT might have its own errno thread local. I
 don't know how its handled on Windows but I suspect it suffers from the
 same problem.

The Windows API errno is GetLastError. But a delinquent CRT might
map GetLastError() to other integers.



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-07 Thread Christian Heimes

 The main problem that the required MSVC redistributables are not necessarily 
 present on the end user's system.

It's not a problem for Python anymore. It took a while to sort all
problems out. Martin and other developers have successfully figured out
how to install the CRT for system wide and local user installations. A
system wide installation installs the CRT in the side by side cache
(WinSxS). A local installation keeps the msvcrt90.dll and the
Microsoft.VC90.CRT.manifest next to the python.exe. Python extensions no
longer embed a manifest so they share the CRT from the python.exe process.

In order to ship a standalone exe you have to keep the CRT next to your
exe. This should work for py2exe binaries as well. At our company we
install our application stack entirely from subversion including Python
2.6.5, Sun JRE and lots of other stuff. This works perfectly fine for us
even for servers without the MSVCRT redistributable.

Christian

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP


* Christian Heimes, on 07.07.2010 22:47:

The main problem that the required MSVC redistributables are not necessarily
present on the end user's system.


It's not a problem for Python anymore. It took a while to sort all
problems out. Martin and other developers have successfully figured out
how to install the CRT for system wide and local user installations. A
system wide installation installs the CRT in the side by side cache
(WinSxS). A local installation keeps the msvcrt90.dll and the
Microsoft.VC90.CRT.manifest next to the python.exe. Python extensions no
longer embed a manifest so they share the CRT from the python.exe process.

In order to ship a standalone exe you have to keep the CRT next to your
exe. This should work for py2exe binaries as well. At our company we
install our application stack entirely from subversion including Python
2.6.5, Sun JRE and lots of other stuff. This works perfectly fine for us
even for servers without the MSVCRT redistributable.


I think you're talking about a different problem. The CRT installed along with 
CPython works for extensions using the MSVC 9.0 CRT.


However developing an extension with MSVC 10 the extension will use the 10.0 
CRT, which is not necessarily present on the end user's system.


As I see it there are five solutions with different trade-offs:

  A Already having Visual Studio 2008 (MSVC 9.0), or coughing up the
money for an MSDN subscription, or visiting trade shows, so as to
obtain that compiler version.
- Not an option for everybody.

  B Linking the CRT statically.
- Increased size, problems with CRT state such as file descriptors.

  C Linking the CRT dynamically and bundling the MSVC redistributables
with the extension.
- Even more increased size for the download, but smaller total
   footprint for extensions in sum; same CRT state problems.

  D Linking the CRT dynamically and providing an optional download and
install of the redistributables if they're not present. This would
best be done with some support from the Python installation machinery.
- Small nice size for extensions, still same CRT state problems.

  E As D + a new compiler-independent native code interface that
does not carry dependencies on CRT state such as file descriptors, like JNI.
- Really huge effort, and cannot be applied until some new Python version.

And I think the clue here is that the CRT state problems can be avoided by 
careful coding.


Hence, for those who cannot do A I think B is a realistic practical option, and 
D would be nice...



Cheers,

- Alf

--
blog at url: http://alfps.wordpress.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

Am 07.07.2010 22:35, schrieb sturlamolden:
 On 7 Jul, 22:26, Christian Heimes li...@cheimes.de wrote:
 
 Don't forget errno! Every CRT might have its own errno thread local. I
 don't know how its handled on Windows but I suspect it suffers from the
 same problem.
 
 The Windows API errno is GetLastError. But a delinquent CRT might
 map GetLastError() to other integers.

Please check the source before posting. msvcrt defines errno as

_CRTIMP extern int * __cdecl _errno(void);
#define errno   (*_errno())

where _errno is (see dosmap.c)

int * __cdecl _errno(void)
{
_ptiddata ptd = _getptd_noexit();
if (!ptd) {
return ErrnoNoMem;
} else {
return ( ptd-_terrno );
}

}

where _getptd_noexit returns the CRT's per-thread data (see tidtable.c).

So it *is* a mapping to other integers, and, even though it's called
dosmap.c, it is maintained because of the (limited) POSIX support in the
CRT. In particular, there is a mapping between GetLastError values and
errno values that can't be implemented through simple defines
(e.g. both ERROR_FILE_NOT_FOUND and ERROR_PATH_NOT_FOUND map to ENOENT).
In addition, a standard C implementation can rely on only certain APIs
changing errno, which MS perhaps might not be able to guarantee for
GetLastError values in exactly the same manner.

So with the way the Windows API is defined, a C implementation has no
alternative but to be delinquent.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP


* Alf P. Steinbach /Usenet, on 07.07.2010 23:19:


However developing an extension with MSVC 10 the extension will use the
10.0 CRT, which is not necessarily present on the end user's system.

As I see it there are five solutions with different trade-offs:

A Already having Visual Studio 2008 (MSVC 9.0), or coughing up the
money for an MSDN subscription, or visiting trade shows, so as to
obtain that compiler version.
- Not an option for everybody.

B Linking the CRT statically.
- Increased size, problems with CRT state such as file descriptors.

C Linking the CRT dynamically and bundling the MSVC redistributables
with the extension.
- Even more increased size for the download, but smaller total
footprint for extensions in sum; same CRT state problems.

D Linking the CRT dynamically and providing an optional download and
install of the redistributables if they're not present. This would
best be done with some support from the Python installation machinery.
- Small nice size for extensions, still same CRT state problems.

E As D + a new compiler-independent native code interface that
does not carry dependencies on CRT state such as file descriptors, like
JNI.
- Really huge effort, and cannot be applied until some new Python version.

And I think the clue here is that the CRT state problems can be avoided
by careful coding.

Hence, for those who cannot do A I think B is a realistic practical
option, and D would be nice...


Wait...

  F Possibly, as the docs say,

Developer Studio will throw in a lot of import libraries that you do not really 
need, adding about 100K to your executable. To get rid of them, use the Project 
Settings dialog, Link tab, to specify ignore default libraries. Add the correct 
msvcrtxx.lib to the list of libraries.


Can anyone confirm whether this works in practice with MSVC 10?


Cheers,

- Alf

--
blog at url: http://alfps.wordpress.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 7 Jul, 23:33, Martin v. Loewis mar...@v.loewis.de wrote:

  The Windows API errno is GetLastError. But a delinquent CRT might
  map GetLastError() to other integers.

 Please check the source before posting. msvcrt defines errno as

I don't have the source to msvcrt, at least not to my knowledge.




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

Am 07.07.2010 23:49, schrieb sturlamolden:
 On 7 Jul, 23:33, Martin v. Loewis mar...@v.loewis.de wrote:
 
 The Windows API errno is GetLastError. But a delinquent CRT might
 map GetLastError() to other integers.

 Please check the source before posting. msvcrt defines errno as
 
 I don't have the source to msvcrt, at least not to my knowledge.

If you have Visual Studio, and opted to install the CRT sources,
you'll find them in VC/crt/src (or VC7/crt/src, depending on VS
version). I'm not 100% sure whether they are included in VS Express as well.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 7 Jul, 23:19, Alf P. Steinbach /Usenet alf.p.steinbach
+use...@gmail.com wrote:

    D Linking the CRT dynamically and providing an optional download and
      install of the redistributables if they're not present. This would
      best be done with some support from the Python installation machinery.
      - Small nice size for extensions, still same CRT state problems.

This was a problem for py2exe'd apps before Python 2.6 (i.e. no public
download for Visual C++ 2003 runtime files.) But for Visual C++ 2008
and 2010, the CRTs can be downloaded from Microsoft and need not be
shipped with the application.

http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BFdisplaylang=en
http://www.microsoft.com/downloads/details.aspx?familyid=BA9257CA-337F-4B40-8C14-157CFDFFEE4Edisplaylang=en

http://www.microsoft.com/downloads/details.aspx?FamilyID=a7b7a05e-6de6-4d3a-a423-37bf0912db84displaylang=en
http://www.microsoft.com/downloads/details.aspx?familyid=BD512D9E-43C8-4655-81BF-9350143D5867displaylang=en







-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-07 Thread Jonathan Hartley

On Jul 7, 8:22 pm, Martin v. Loewis mar...@v.loewis.de wrote:
  I presume this problem would go away if future versions of Python
  itself were compiled on Windows with something like MinGW gcc. Also,
  this would solve the pain of Python developers attempting to
  redistribute py2exe versions of their programs (i.e. they have to own
  a Visual Studio license to legally be able to redistribute the
  required C runtime) I don't understand enough to know why Visual
  Studio was chosen instead of MinGW. Can anyone shed any light on that
  decision?

 sturlamolden has already given the primary reason: Python,
 traditionally, attempts to use and work with the system vendor's
 compiler. On Windows, that's MSC. It's typically the one that best knows
 about platform details that other compilers might be unaware of.

 In addition, it's also the compiler and IDE that Windows developers (not
 just Python core people, but also extension developers and embedders)
 prefer to use, as it has quite good IDE support (in particular debugging
 and code browsing).

 Perhaps more importantly, none of the other compilers is really an
 alternative. GCC in particular cannot build the Win32 extensions, since
 it doesn't support the COM and ATL C++ features that they rely on (and
 may not support other MSC extensions, either). So the Win32 extensions
 must be built with VS, which means Python itself needs to use the same
 compiler.

 Likewise important: gcc/mingw is *not* a complete C compiler on Windows.
 A complete C compiler would have to include a CRT (on Windows); mingw
 doesn't (cygwin does, but I think you weren't proposing that Python be
 built for cygwin - you can easily get cygwin Python anyway). Instead,
 mingw relies on users having a CRT available to
 them - and this will be a Microsoft one. So even if gcc was used, we
 would have versioning issues with Microsoft CRTs, plus we would have to
 rely on target systems including the right CRT, as we couldn't include
 it in the distribution.

 HTH,
 Martin


I see. Thanks very much to both of you for the info, much appreciated.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 8 Jul, 00:35, Jonathan Hartley tart...@tartley.com wrote:

 I see. Thanks very much to both of you for the info, much appreciated.

The problem you referred to for py2exe despaired with Python 2.6. For
Python 2.5, there was no public download option for msvcr71.dll and
msvcp71.dll. There was also the unsolved SxS issue. Thus a license for
Visual Studio 2003 was required to distribute py2exe apps for Python
2.5. That is now history. For py2exe apps using Python 2.6, 2.7 or
3.1, you can just ask your clients to install this:

http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BFdisplaylang=en
http://www.microsoft.com/downloads/details.aspx?familyid=BA9257CA-337F-4B40-8C14-157CFDFFEE4Edisplaylang=en

There are similar downloads for Visual C++ 2010 run-time files as
well. Python 3.2 will probably be built with Visual Studio 2010.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-07 Thread David Cournapeau

On Wed, Jul 7, 2010 at 9:10 PM, Martin v. Loewis mar...@v.loewis.de wrote:


 My preferred long-term solution is to reduce the usage of the C library
 in CPython as much as reasonable, atleast on Windows. Memory management
 could directly use the heap functions (or even more directly
 VirtualAlloc); filenos could be OS handles, and so on. There are
 probably limitations to what you can achieve, but I think it's worth trying.

I saw you already mentioned work toward this a few months (years ?)
ago. Is there some kind of roadmap, or could you use some help ? I
would really like to solve this issue as much as we possibly can,

David
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-07 Thread Martin v. Löwis

 I saw you already mentioned work toward this a few months (years ?)
 ago. Is there some kind of roadmap, or could you use some help ? I
 would really like to solve this issue as much as we possibly can,

Well, Python 3 has already dropped stdio for its own io library, and
I do want to get rid of the remaining FILE* usage for 3.2. Any other
change needs to be discussed on python-dev first; contributions are welcome.

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-07 Thread Stephen Hansen

On 7/7/10 9:46 PM, Martin v. Löwis wrote:
 I saw you already mentioned work toward this a few months (years ?)
 ago. Is there some kind of roadmap, or could you use some help ? I
 would really like to solve this issue as much as we possibly can,
 
 Well, Python 3 has already dropped stdio for its own io library, and
 I do want to get rid of the remaining FILE* usage for 3.2. Any other
 change needs to be discussed on python-dev first; contributions are welcome.

Really? I wasn't entirely aware of this effect of the io module.
Somehow, without at all paying attention (because certain third party
modules blocking me for awhile, I never looked close enough), I just
sort of thought the io module was mostly thin wrappers around stdio
primitives, into a more Pythonic API.

This actually makes me long for Python 3 more. And adjust agendas to
push my day-job work to 2.7 as soon as possible, and start a preemptive
reconfiguration to support a future Py3k migration.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-06 Thread Alf P. Steinbach /Usenet

* sturlamolden, on 06.07.2010 17:50:

Just a little reminder:

Microsoft has withdrawn VS2008 in favor of VS2010. The express version
is also unavailable for download.:((

We can still get a VC++ 2008 compiler required to build extensions for
the official Python 2.6 and 2.7 binary installers here (Windows 7 SDK
for .NET 3.5 SP1):

http://www.microsoft.com/downloads/details.aspx?familyid=71DEB800-C591-4F97-A900-BEA146E4FAE1displaylang=en

Download today, before it goes away!

Microsoft has now published a download for Windows 7 SDK for .NET 4.
It has the VC++ 2010 compiler. It can be a matter of days before the VC
++ 2008 compiler is totally unavailable.

It is possible to build C and Fortran extensions for official Python
2.6/2.7 binaries on x86 using mingw. AFAIK, Microsoft's compiler is
required for C++ or amd64 though. (Intel's compiler requires VS2008,
which has now perished.)

Remember Python on Windows will still require VS2008 for a long time.
Just take a look at the recent Python 3 loath threads.

Perhaps this all for the good.

There is no *technical* problem creating a compiler-independent C/C++ language
binding. I believe that Java's JNI works fine no matter what compiler you use,
although it's many many years since I've done JNI things. Similarly, Python
should IMHO just have a well defined compiler independent native code interface,
e.g. PNI, or pynacoin, the PYthon NAtive COde INterface :-)

Cheers,

- Alf

--
blog at url: http://alfps.wordpress.com
--
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 07/06/2010 05:50 PM, sturlamolden wrote:
 It is possible to build C and Fortran extensions for official Python
 2.6/2.7 binaries on x86 using mingw. AFAIK, Microsoft's compiler is
 required for C++ or amd64 though. (Intel's compiler requires VS2008,
 which has now perished.)

mingw gcc should work for building C++ extensions if it also works for C
extensions. There's no difference on the binding side - you simply have
to include everything as extern C, which I am sure the header does for
you.

As for amd64 - I do not know if there is a mingw64 release for windows
already. If there isn't, there should be ;-) But that doesn't really
change anything: the express edition of Microsoft's VC++ doesn't include
an amd64 compiler anyway, AFAIK.

Also, VS2010 should work as well - doesn't it?

 
 Remember Python on Windows will still require VS2008 for a long time.
 Just take a look at the recent Python 3 loath threads.
 

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 6 Jul, 18:00, Alf P. Steinbach /Usenet alf.p.steinbach
+use...@gmail.com wrote:

 There is no *technical* problem creating a compiler-independent C/C++ language
 binding. I believe that Java's JNI works fine no matter what compiler you use,
 although it's many many years since I've done JNI things. Similarly, Python
 should IMHO just have a well defined compiler independent native code 
 interface,
 e.g. PNI, or pynacoin, the PYthon NAtive COde INterface :-)

Yes but Python currently does not, due to dependency on VS2003 (2.5)
or VS2008 (2.6, 2.7, 3.1) C and C++ runtime DLLs.

It's not the binary interface that is the trouble, but CRT
versioning.

C++ is extra troublesome due to name mangling, standard runtime and
exceptions.

Here are the issues:

C++:
VS2010 - does not link with msvcp90.dll but msvcp100.dll.
mingw - linkes statically with its own C++ library.

Win32, ANSI C:
VS2010 - does not link with msvcr90.dll but msvcr100.dll.
mingw - ok for C if passed -lmsvcr90 on linking step

Win64, ANSI C:
VS2010 - does not link with msvcr90.dll but msvcr100.dll.
mingw - missing import libraries (libmsvcr90.a and libpython26.a)

Visual Studio 2008's C/C++ compiler is the only sane solution. It is
still there so go get it if you don't already have a copy (I guess Alf
does).












-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 6 Jul, 18:21, Thomas Jollans tho...@jollans.com wrote:

 mingw gcc should work for building C++ extensions if it also works for C
 extensions.

No, it uses an incompatible statically linked C++ runtime. We need to
use msvcp90.dll with Python 2.6/2.7.


 As for amd64 - I do not know if there is a mingw64 release for windows
 already. If there isn't, there should be ;-)

There is. But it does not have an import library for msvcr90.dll. It's
omitted from mingw-w64. Also libpython26.a is missing from Python on
Windows 64.


 Also, VS2010 should work as well - doesn't it?

The problem with Microsoft's compilers is that they just let you pick
between two CRTs (single- or multi-threaded). We need to specify the
version number as well.

So no, VS2010 will not work. (At least not without some ugly hacks.)










-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-06 Thread Christian Heimes

Am 06.07.2010 18:21, schrieb Thomas Jollans:
 mingw gcc should work for building C++ extensions if it also works for C
 extensions. There's no difference on the binding side - you simply have
 to include everything as extern C, which I am sure the header does for
 you.

You need unofficial version of MinGW with gcc 4.x for several C++
extension like PyLucene's JCC. Some project like pywin32 don't work with
MinGW, too.

 Also, VS2010 should work as well - doesn't it?

It may work, it may segfault.

The official Python binaries are build with VS 2008. Although you are
able to build and use extensions build with other versions of VS it can
lead to segfaults. So far every version of VS has introduced its own C
runtime library (MSVCRT). If you try to close a FILE* from one MSVCRT
with fclose() from another MSVCRT your program SEGFAULT. malloc() and
free() suffer from the same problem.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 07/06/2010 06:58 PM, Christian Heimes wrote:
 Am 06.07.2010 18:21, schrieb Thomas Jollans:
 mingw gcc should work for building C++ extensions if it also works for C
 extensions. There's no difference on the binding side - you simply have
 to include everything as extern C, which I am sure the header does for
 you.
 
 You need unofficial version of MinGW with gcc 4.x for several C++
 extension like PyLucene's JCC. Some project like pywin32 don't work with
 MinGW, too.

aha - why is that?

But - if you write code that builds with [whatever gcc version you
have], the compiler Python is built with shouldn't matter, should it?

 
 Also, VS2010 should work as well - doesn't it?
 
 It may work, it may segfault.
 
 The official Python binaries are build with VS 2008. Although you are
 able to build and use extensions build with other versions of VS it can
 lead to segfaults. So far every version of VS has introduced its own C
 runtime library (MSVCRT). If you try to close a FILE* from one MSVCRT
 with fclose() from another MSVCRT your program SEGFAULT. malloc() and
 free() suffer from the same problem.

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 code quite defensively, true. But, IF you keep all
non-Python data structures local to your module, you should be fine?

Coming from a system where I can generally rely on the system gcc to
work for everything, I may be a bit naïve wrt certain questions ;-)

Cheers,
Thomas

PS: Windows CPython programming scares me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 07/06/2010 06:49 PM, sturlamolden wrote:
 On 6 Jul, 18:21, Thomas Jollans tho...@jollans.com wrote:
 
 mingw gcc should work for building C++ extensions if it also works for C
 extensions.
 
 No, it uses an incompatible statically linked C++ runtime. We need to
 use msvcp90.dll with Python 2.6/2.7.

Python is written in C. How does the C++ runtime enter into it?


 
 As for amd64 - I do not know if there is a mingw64 release for windows
 already. If there isn't, there should be ;-)
 
 There is. But it does not have an import library for msvcr90.dll. It's
 omitted from mingw-w64. Also libpython26.a is missing from Python on
 Windows 64.
 
 
 Also, VS2010 should work as well - doesn't it?
 
 The problem with Microsoft's compilers is that they just let you pick
 between two CRTs (single- or multi-threaded). We need to specify the
 version number as well.
 
 So no, VS2010 will not work. (At least not without some ugly hacks.)

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 6 Jul, 19:09, Thomas Jollans tho...@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).

In general, CRT objects cannot be shared across CRT boundaries.

Also remember the C and C++ standard libraries interact. g++ from
links statically with an incompatible C++ standard library (read: it
will segfault, it's just a question of when).


 Coming from a system where I can generally rely on the system gcc to
 work for everything, I may be a bit naïve wrt certain questions ;-)

On sane operating systems you generally have one version of libc
installed.

Windows did this too (msvcrt.dll) up to the VS2003 release, which came
with msvcr71.dll in addition. Since then, M$ (pronounced Megadollar
Corp.) have published msvcr80.dll, msvcr90.dll, and msvcr100.dll (and
corresponding C++ versions) to annoy C and C++ developers into
converting to C# .NET. (And yes, programs using third-party DLL and
OCX components become unstable from this. You have to check each DLL/
OCX you use, and each DLL used by each DLL, etc. How fun...)


















-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 6 Jul, 19:11, Thomas Jollans tho...@jollans.com wrote:

 Python is written in C. How does the C++ runtime enter into it?

The C and C++ runtimes interact (e.g. stdlib.h and iostream), malloc
and new, etc. With g++ you have a C++ standard library compiled
against msvcrt.dll, whereas Python is using msvcr90.dll.

We can use the C++ runtime msvcp90.dll used by VC++ 2008, but this DLL
is binary incompatible with g++ (GNU uses a different ABI for C++).


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-06 Thread Christian Heimes

 You need unofficial version of MinGW with gcc 4.x for several C++
 extension like PyLucene's JCC. Some project like pywin32 don't work with
 MinGW, too.
 
 aha - why is that?
 
 But - if you write code that builds with [whatever gcc version you
 have], the compiler Python is built with shouldn't matter, should it?

Unless I'm mistaken, official MinGW32 packages still have GCC 3.x. Some
projects like JCC need recent C++ compilers. MinGW doesn't provide some
features that pywin32 requires.

The compiler must create ABI compatible object files and the linker
needs to support the latest CRT. Three years ago it took several months
until MinGW supported the 9.0 CRT.

 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 code quite defensively, true. But, IF you keep all
 non-Python data structures local to your module, you should be fine?

You must be carefully with functions like PyFile_FromFile(), too. If you
expose the FILE* from the alien CRT to Python somehow you can get into
trouble. Lukely PyFile_FromFile() works around most issues but it's
still problematic. These kind of SEGFAULTs are hard to debug, too.

 Coming from a system where I can generally rely on the system gcc to
 work for everything, I may be a bit naïve wrt certain questions ;-)

 PS: Windows CPython programming scares me.

Yeah, it's a pain.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-06 Thread Martin P. Hellwig


On 07/06/10 16:50, sturlamolden wrote:


Just a little reminder:

Microsoft has withdrawn VS2008 in favor of VS2010. The express version
is also unavailable for download.:((

cut
Public download that is, people like me who have a MSDN subscription can 
still download old versions like Visual Studio 2005.


So I would say that there is no particular hurry.
I would think that everyone really serious about MS development with MS 
tools should get an MSDN subscription anyway, it saves you a lot of 
money in the long run.


--
mph
--
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-06 Thread Ed Keith

I downloaded the ISO, but it seems to be just a bit too big to fit on a CD!

This seems odd to me, has anyone else had this problem?

  -EdK

Ed Keith
e_...@yahoo.com

Blog: edkeith.blogspot.com


--- On Tue, 7/6/10, sturlamolden sturlamol...@yahoo.no wrote:

 From: sturlamolden sturlamol...@yahoo.no
 Subject: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
 To: python-list@python.org
 Date: Tuesday, July 6, 2010, 11:50 AM
 
 Just a little reminder:
 
 Microsoft has withdrawn VS2008 in favor of VS2010. The
 express version
 is also unavailable for download. :((
 
 We can still get a VC++ 2008 compiler required to build
 extensions for
 the official Python 2.6 and 2.7 binary installers here
 (Windows 7 SDK
 for .NET 3.5 SP1):
 
 http://www.microsoft.com/downloads/details.aspx?familyid=71DEB800-C591-4F97-A900-BEA146E4FAE1displaylang=en
 
 Download today, before it goes away!
 
 Microsoft has now published a download for Windows 7 SDK
 for .NET 4.
 It has the VC++ 2010 compiler. It can be a matter of days
 before the VC
 ++ 2008 compiler is totally unavailable.
 
 It is possible to build C and Fortran extensions for
 official Python
 2.6/2.7 binaries on x86 using mingw. AFAIK, Microsoft's
 compiler is
 required for C++ or amd64 though. (Intel's compiler
 requires VS2008,
 which has now perished.)
 
 Remember Python on Windows will still require VS2008 for a
 long time.
 Just take a look at the recent Python 3 loath threads.
 
 -- 
 http://mail.python.org/mailman/listinfo/python-list
 


  
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-06 Thread Stephen Hansen

On 7/6/10 10:52 AM, Ed Keith wrote:
 I downloaded the ISO, but it seems to be just a bit too big to fit on a CD!

The website says its a DVD iso.

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/



signature.asc
Description: OpenPGP digital signature
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 6 Jul, 19:52, Ed Keith e_...@yahoo.com wrote:

 This seems odd to me, has anyone else had this problem?

DVD?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-06 Thread Robert Kern


On 7/6/10 1:52 PM, Ed Keith wrote:

I downloaded the ISO, but it seems to be just a bit too big to fit on a CD!

This seems odd to me, has anyone else had this problem?


These days, ISOs are destined for DVD-Rs. :-)

There are also utilities for mounting ISOs directly without burning them to a 
physical disk. Here is a decent list:


  http://www.techsupportalert.com/best-free-cd-emulator.htm

--
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: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 6 Jul, 19:46, Martin P. Hellwig martin.hell...@dcuktec.org
wrote:

 Public download that is, people like me who have a MSDN subscription can
 still download old versions like Visual Studio 2005.

That's nice to know, but I personally don't have an MSDN subscription.
Many scientists don't have access to development tools like VS2008.
Many hobby developers don't have access expensive MSDN subscriptions.
Many don't develop C personally, but just needs a compiler to build
an extension with distutils. And for all of us not subscribing to
MSDN, this is the only remaining source.




-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-06 Thread David Robinow

On Tue, Jul 6, 2010 at 1:46 PM, Martin P. Hellwig
martin.hell...@dcuktec.org wrote:
 Public download that is, people like me who have a MSDN subscription can
 still download old versions like Visual Studio 2005.

 So I would say that there is no particular hurry.
 I would think that everyone really serious about MS development with MS
 tools should get an MSDN subscription anyway, it saves you a lot of money in
 the long run.
Amazing!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-06 Thread Christian Heimes

 That's nice to know, but I personally don't have an MSDN subscription.
 Many scientists don't have access to development tools like VS2008.
 Many hobby developers don't have access expensive MSDN subscriptions.
 Many don't develop C personally, but just needs a compiler to build
 an extension with distutils. And for all of us not subscribing to
 MSDN, this is the only remaining source.

I agree, the situation isn't ideal. I see if I can get in contact with
Microsoft's open source team. Perhaps they can keep the download link to
VS 2008 EE working.

By the way lot's of universities participate in the MSDN Academy
Alliance program. Students, scientists and employees of the university
can get most MSDN packages.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-06 Thread casevh

On Jul 6, 9:21 am, Thomas Jollans tho...@jollans.com wrote:
 On 07/06/2010 05:50 PM, sturlamolden wrote:

  It is possible to build C and Fortran extensions for official Python
  2.6/2.7 binaries on x86 using mingw. AFAIK, Microsoft's compiler is
  required for C++ or amd64 though. (Intel's compiler requires VS2008,
  which has now perished.)

 mingw gcc should work for building C++ extensions if it also works for C
 extensions. There's no difference on the binding side - you simply have
 to include everything as extern C, which I am sure the header does for
 you.

 As for amd64 - I do not know if there is a mingw64 release for windows
 already. If there isn't, there should be ;-) But that doesn't really
 change anything: the express edition of Microsoft's VC++ doesn't include
 an amd64 compiler anyway, AFAIK.

The original version of the Windows 7 SDK includes the command line
version of the VS 2008 amd64 compiler. I've used it compile MPIR and
GMPY successfully. The GMPY source includes a text file describing the
build process using the SDK tools.

casevh

 Also, VS2010 should work as well - doesn't it?





  Remember Python on Windows will still require VS2008 for a long time.
  Just take a look at the recent Python 3 loath threads.- Hide quoted text -

 - Show quoted text -

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 6 Jul, 21:49, Christian Heimes li...@cheimes.de wrote:

 I agree, the situation isn't ideal. I see if I can get in contact with
 Microsoft's open source team. Perhaps they can keep the download link to
 VS 2008 EE working.

It seems the MSDN subscription required to get VS 2008 costs one
dollar less than $1200. So it does not fit within everyone's budget.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 6 Jul, 21:52, casevh cas...@gmail.com wrote:

 On Jul 6, 9:21 am, Thomas Jollans tho...@jollans.com wrote:
  But that doesn't really
  change anything: the express edition of Microsoft's VC++ doesn't include
  an amd64 compiler anyway, AFAIK.

See here:
http://jenshuebel.wordpress.com/2009/02/12/visual-c-2008-express-edition-and-64-bit-targets/

The express edition can be used as is for x86 though (it might not
have an optimizing compiler). It can also be used for C++, unlike g++
(at least VC++ is safer).


 The original version of the Windows 7 SDK includes the command line
 version of the VS 2008 amd64 compiler.


C:\Program Files\Microsoft SDKs\Windows\v7.0cl
Microsoft (R) C/C++ Optimizing Compiler Version 15.00.30729.01 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

usage: cl [ option... ] filename... [ /link linkoption... ]

C:\Program Files\Microsoft SDKs\Windows\v7.0


Need any more proof? :D


Also note that the Windows 7 SDK can still be used with IDEs, like Qt
Creator, KDEvelop (yes there is a Windows version), Eclipse, Visual
Studio, and even Visual C++ Express (a little PITA for amd64, but
possible too).

I'm still fan of a tiny text editor for typing (Kate from KDE tends to
be my favorite) and a Python script for building, though.



-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-06 Thread David Cournapeau

On Tue, Jul 6, 2010 at 6:00 PM, Alf P. Steinbach /Usenet
alf.p.steinbach+use...@gmail.com wrote:
* sturlamolden, on 06.07.2010 17:50:

Just a little reminder:

Microsoft has withdrawn VS2008 in favor of VS2010. The express version
is also unavailable for download.:((

We can still get a VC++ 2008 compiler required to build extensions for
the official Python 2.6 and 2.7 binary installers here (Windows 7 SDK
for .NET 3.5 SP1):

http://www.microsoft.com/downloads/details.aspx?familyid=71DEB800-C591-4F97-A900-BEA146E4FAE1displaylang=en

Download today, before it goes away!

Microsoft has now published a download for Windows 7 SDK for .NET 4.
It has the VC++ 2010 compiler. It can be a matter of days before the VC
++ 2008 compiler is totally unavailable.

Remember Python on Windows will still require VS2008 for a long time.
Just take a look at the recent Python 3 loath threads.

Perhaps this all for the good.

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
- 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)
- the MS standard C library is clearly not a priority: win32 specific
objects can be shared across runtimes, but standard C rarely can.
- the recent manifest concept (which can improve or worsen the
issues) is incredibly convoluted, and poorly documented (they expect
you to use MS tool and not to try to understand how it works).

David
--
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

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+use...@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.

  - 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??

Now Windows programming *really* scares me.

  - the MS standard C library is clearly not a priority: win32 specific
 objects can be shared across runtimes, but standard C rarely can.

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.

  - the recent manifest concept (which can improve or worsen the
 issues)  is incredibly convoluted, and poorly documented (they expect
 you to use MS tool and not to try to understand how it works).


Cheers,

Thomas
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-06 Thread Martin v. Loewis

  - 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.

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?

Regards,
Martin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 6 Jul, 21:52, casevh cas...@gmail.com wrote:

 The original version of the Windows 7 SDK includes the command line
 version of the VS 2008 amd64 compiler. I've used it compile MPIR and
 GMPY successfully. The GMPY source includes a text file describing the
 build process using the SDK tools.

It should also be mentioned that the Windows 7 SDK includes
vcbuild.exe, so it can be used to compile Visual Studio 2008 projects
(I'm going to try Python).

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

2010-07-06 Thread Martin P. Hellwig


On 07/06/10 21:19, sturlamolden wrote:

On 6 Jul, 21:49, Christian Heimesli...@cheimes.de  wrote:


I agree, the situation isn't ideal. I see if I can get in contact with
Microsoft's open source team. Perhaps they can keep the download link to
VS 2008 EE working.


It seems the MSDN subscription required to get VS 2008 costs one
dollar less than $1200. So it does not fit within everyone's budget.


Take in the cost of your operating system, and the ones you want to test 
against, perhaps you also like to use office.
Although I am not a windows developer per se, I do use windows XP, 2000 
2003, 2008, Vista and 7 for testing. I also use office for all those 
clients who think that this is the only format.


1200 USD is actually quite cheap, but then again I didn't pay that 
because I am either always been in an academic license (about 70 EUR a 
year) or like now in a program for businesses who just start up (free 
with my bank as supporting agent). When this 3 year subscription is over 
I fall anyway in the cheaper renewals and if not I am sure that there is 
some other brand new scheme like they did for the last decade.


Anyway, if you want to provide tools for platforms that are closed 
source that means that there are costs for the developer and the client.
Although the cost for MS platforms are reasonable (as a developer and 
you know you way around, that means go a couple of times to those free 
MS events and it is quite likely you get an MSDN subscription for being 
such a good loyal puppy), there are always costs.


If you don't like that better convince your target audience about an 
open source operating system, whichever that may be.


--
mph


--
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 7 Jul, 00:41, sturlamolden sturlamol...@yahoo.no wrote:

 It should also be mentioned that the Windows 7 SDK includes
 vcbuild.exe, so it can be used to compile Visual Studio 2008 projects
 (I'm going to try Python).

Not sure why I forgot to mention, but we can (or even should?) use
CMake to generate these project files. We don't need Visual Studio for
that.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

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.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP

On 7 Jul, 01:07, Thomas Jollans tho...@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.


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP