Jean-Michel Pichavant wrote:
Robert Kern wrote:
On 7/23/10 7:08 PM, Lawrence D'Oliveiro wrote:
In message,
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
Robert Kern wrote:
On 7/23/10 7:08 PM, Lawrence D'Oliveiro wrote:
In message,
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 Windows, Yes.
You need the
On 26/07/2010 16:47, Burton Samograd wrote:
Grant Edwards writes:
On 2010-07-24, Lawrence D'Oliveiro wrote:
In message, 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??
Not if the OS
Grant Edwards writes:
> On 2010-07-24, Lawrence D'Oliveiro wrote:
>> In message , 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??
>
> Not if the OS and VFS are competently
On Mon, Jul 26, 2010 at 3:07 AM, Zooko O'Whielacronx 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 are.
To b
On Wed, Jul 7, 2010 at 3:32 AM, Jonathan Hartley 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 compilable with mi
On 2010-07-24, Lawrence D'Oliveiro wrote:
> In message , 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??
Not if the OS and VFS are competently designed. In Linux all you need
to
On 7/23/10 7:08 PM, Lawrence D'Oliveiro wrote:
In message, 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 Windows, Yes.
--
Robert Kern
"I have come to beli
In message , 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 9 Jul, 02:02, Neil Hodgson 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 issue applies to COM as well. C
Dave Angel 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 conclusion
Tim Roberts wrote:
Christian Heimes 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
Christian Heimes 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 problem.
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
> co
> 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, i
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
> 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 o
On Wed, Jul 7, 2010 at 9:10 PM, Martin v. Loewis 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 cou
On 8 Jul, 00:35, Jonathan Hartley 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
On Jul 7, 8:22 pm, "Martin v. Loewis" 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 pro
On 7 Jul, 23:19, "Alf P. Steinbach /Usenet" 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
Am 07.07.2010 23:49, schrieb sturlamolden:
> On 7 Jul, 23:33, "Martin v. Loewis" 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 s
On 7 Jul, 23:33, "Martin v. Loewis" 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.
--
* 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 (MSV
Am 07.07.2010 22:35, schrieb sturlamolden:
> On 7 Jul, 22:26, Christian Heimes 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 GetLastErro
* 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
> 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
On 7 Jul, 22:26, Christian Heimes 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 ot
> 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.pytho
On 2010-07-07, Martin v. Loewis 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/s
On 7 Jul, 21:47, "Martin v. Loewis" 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
* 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 problem
* sturlamolden, on 07.07.2010 21:46:
On 7 Jul, 21:41, "Alf P. Steinbach /Usenet" 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.
Yea
>>> 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
> wit
On 7 Jul, 21:47, "Martin v. Loewis" 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 i
> 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 "lega
On 7 Jul, 21:41, "Alf P. Steinbach /Usenet" 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/l
* sturlamolden, on 07.07.2010 21:12:
On 7 Jul, 06:54, "Alf P. Steinbach /Usenet" 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 :(
* 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
On 7 Jul, 21:12, sturlamolden 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 wo
> 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
On 7 Jul, 06:54, "Alf P. Steinbach /Usenet" 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
> 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 opposi
On 7 Jul, 11:32, Jonathan Hartley 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/d
On Jul 6, 4:50 pm, sturlamolden 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 and 2.7 binary i
On 7/6/10 11:21 PM, Tim Roberts wrote:
> sturlamolden 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 nonsense;
sturlamolden 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. >:((
Also nons
* sturlamolden, on 06.07.2010 19:35:
On 6 Jul, 19:09, Thomas Jollans 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 h
On Wed, Jul 7, 2010 at 12:26 AM, Thomas Jollans wrote:
> On 07/07/2010 12:08 AM, David Cournapeau wrote:
>> On Tue, Jul 6, 2010 at 6:00 PM, Alf P. Steinbach /Usenet
>> wrote:
>>> There is no *technical* problem creating a compiler-independent C/C++
>>> language binding.
>>
>> It is quite hard, th
On 07/07/2010 01:14 AM, sturlamolden wrote:
> On 7 Jul, 01:07, Thomas Jollans 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 confusin
On 7 Jul, 01:07, Thomas Jollans 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 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 fli
On 7 Jul, 00:41, sturlamolden 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 proje
On 07/06/10 21:19, sturlamolden wrote:
On 6 Jul, 21:49, Christian Heimes 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 V
On 6 Jul, 21:52, casevh 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
>> - 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 W
On 07/07/2010 12:08 AM, David Cournapeau wrote:
> On Tue, Jul 6, 2010 at 6:00 PM, Alf P. Steinbach /Usenet
> 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
On Tue, Jul 6, 2010 at 6:00 PM, Alf P. Steinbach /Usenet
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 req
On 6 Jul, 21:52, casevh wrote:
> On Jul 6, 9:21 am, Thomas Jollans 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-edit
On 6 Jul, 21:49, Christian Heimes 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 $12
On Jul 6, 9:21 am, Thomas Jollans 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
> 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 extensi
On Tue, Jul 6, 2010 at 1:46 PM, Martin P. Hellwig
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 dev
On 6 Jul, 19:46, "Martin P. Hellwig"
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 to
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
p
On 6 Jul, 19:52, Ed Keith 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 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
Descrip
ft 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. >:((
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.>:((
Public download that is, people like me who have a MSDN subscription can
still download old versions like Visual Studio
>> 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
On 6 Jul, 19:11, Thomas Jollans 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 ), malloc
and new, etc. With g++ you have a C++ standard library compiled
against msvcrt.dll, whereas Python is using msvcr90.dll.
We can u
On 6 Jul, 19:09, Thomas Jollans 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
On 07/06/2010 06:49 PM, sturlamolden wrote:
> On 6 Jul, 18:21, Thomas Jollans 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.
Pyth
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 su
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 ve
On 6 Jul, 18:21, Thomas Jollans 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 releas
On 6 Jul, 18:00, "Alf P. Steinbach /Usenet" 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
> shou
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 shoul
* 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 her
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):
h
80 matches
Mail list logo
