Robert Kern wrote:
On 7/23/10 7:08 PM, Lawrence D'Oliveiro wrote:
In messagemailman.323.1278440923.1673.python-l...@python.org,
Robert Kern
wrote:
There are also utilities for mounting ISOs directly without burning
them
to a physical disk.
You need special utilities to do this??
On at
Jean-Michel Pichavant wrote:
Robert Kern wrote:
On 7/23/10 7:08 PM, Lawrence D'Oliveiro wrote:
In messagemailman.323.1278440923.1673.python-l...@python.org,
Robert Kern
wrote:
There are also utilities for mounting ISOs directly without burning
them
to a physical disk.
You need special
Grant Edwards inva...@invalid.invalid writes:
On 2010-07-24, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote:
In message mailman.323.1278440923.1673.python-l...@python.org, Robert Kern
wrote:
There are also utilities for mounting ISOs directly without burning
them to a physical
On 26/07/2010 16:47, Burton Samograd wrote:
Grant Edwardsinva...@invalid.invalid writes:
On 2010-07-24, Lawrence D'Oliveirol...@geek-central.gen.new_zealand wrote:
In messagemailman.323.1278440923.1673.python-l...@python.org, Robert Kern
wrote:
There are also utilities for mounting ISOs
On Wed, Jul 7, 2010 at 3:32 AM, Jonathan Hartley tart...@tartley.com wrote:
I presume this problem would go away if future versions of Python
itself were compiled on Windows with something like MinGW gcc.
You might want to track issue3871. Roumen Petrov has done a lot of
work to make CPython
On Mon, Jul 26, 2010 at 3:07 AM, Zooko O'Whielacronx zo...@zooko.com wrote:
I would suggest that people try to build their native extension
modules with mingw, and if it doesn't work report a bug (to mingw
project and to the Python project) so that we can track more precisely
what the issues
In message mailman.323.1278440923.1673.python-l...@python.org, Robert Kern
wrote:
There are also utilities for mounting ISOs directly without burning them
to a physical disk.
You need special utilities to do this??
--
http://mail.python.org/mailman/listinfo/python-list
On 7/23/10 7:08 PM, Lawrence D'Oliveiro wrote:
In messagemailman.323.1278440923.1673.python-l...@python.org, Robert Kern
wrote:
There are also utilities for mounting ISOs directly without burning them
to a physical disk.
You need special utilities to do this??
On at least some versions of
On 2010-07-24, Lawrence D'Oliveiro l...@geek-central.gen.new_zealand wrote:
In message mailman.323.1278440923.1673.python-l...@python.org, Robert Kern
wrote:
There are also utilities for mounting ISOs directly without burning
them to a physical disk.
You need special utilities to do this??
Dave Angel da...@ieee.org wrote:
Tim Roberts wrote:
No. The multi-thread-aware CRT in Visual C++ (which is the only option
since VS2008) puts errno in thread-local storage, so it's shared by all
CRTs.
I didn't know specifically that errno is in TLS, but I will disagree
with the
On 9 Jul, 02:02, Neil Hodgson nyamatongwe+thun...@gmail.com wrote:
If you break the rules by using malloc rather than IMalloc for memory
that is deallocated by a different component to that which allocated it
or try to pass around FILE* objects then you will see failures.
Yes, the CRT
Tim Roberts wrote:
Christian Heimes li...@cheimes.de wrote:
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
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
sturlamolden:
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
Christian Heimes li...@cheimes.de wrote:
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
sturlamolden sturlamol...@yahoo.no wrote:
Just a little reminder:
Microsoft has withdrawn VS2008 in favor of VS2010.
Nonsense. They have released VS2010, but they certainly have not
withdrawn VS2008, and I have heard of no plans to do so.
The express version is also unavailable for download.
On 7/6/10 11:21 PM, Tim Roberts wrote:
sturlamolden sturlamol...@yahoo.no wrote:
Just a little reminder:
Microsoft has withdrawn VS2008 in favor of VS2010.
Nonsense. They have released VS2010, but they certainly have not
withdrawn VS2008, and I have heard of no plans to do so.
Its not
On Jul 6, 4:50 pm, sturlamolden sturlamol...@yahoo.no wrote:
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
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)
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
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
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
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.
* 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
* 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))
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.
--
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.
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
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
* 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
* 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
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
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:
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
--
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
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
* 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
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
* 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
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
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
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
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
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
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
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
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
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):
* 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
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
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
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
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
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
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
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
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
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
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
...@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
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
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
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
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
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
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
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
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
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:
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++
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
- 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??
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.
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
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
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!)
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
On 07/07/2010 01:14 AM, sturlamolden wrote:
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.
Or somebody's
On Wed, Jul 7, 2010 at 12:26 AM, Thomas Jollans tho...@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+use...@gmail.com wrote:
There is no *technical* problem creating a compiler-independent C/C++
* sturlamolden, on 06.07.2010 19:35:
On 6 Jul, 19:09, Thomas Jollanstho...@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),
80 matches
Mail list logo
