Paul Moore wrote:
On 10 October 2014 17:28, Mark Lawrence wrote:
There are 55 open issues on the bug tracker with mingw in the title.
It's not easy to tell, but on a spot check a fair proportion of them
seem to be about distutils/extension builds. And a lot of the rest are
related to http://b
from linux of cygwin then could use this set:
18654 - modernize mingw&cygwin compiler classes
I could step in as maintainer for Cygwin and builds based on GCC using
mingw* APIs.
Regards,
Roumen Petrov
___
Python-Dev mailing list
Python-Dev@py
Matthias Klose wrote:
[No, I'm not interested in the port myself]
patches for a mingw32 port are floating around on the web and the python bug
tracker, although most of them as a set of patches in one issue addressing
several things, and which maybe outdated for the trunk. at least for me
re-rea
Trent Nelson wrote:
[SNIP]
diff -r 51ce9830d85a configure.ac
--- a/configure.ac Sat Oct 13 11:58:23 2012 -0400
+++ b/configure.ac Tue Oct 16 09:12:56 2012 +
@@ -9,6 +9,9 @@
AC_INIT(python, PYTHON_VERSION, http://bugs.python.org/)
+BUILDDIR="`pwd`"
^
http://www.gnu.
Brett Cannon wrote:
On Sat, Jun 26, 2010 at 16:37, M.-A. Lemburg wrote:
Brett Cannon wrote:
On Wed, Jun 23, 2010 at 14:53, Brett Cannon wrote:
[SKIP]
Since no one objected I swapped the order in r82259. In case anyone
else uses clang to compile Python, this means that -Wno-unused-value
will
Brett Cannon wrote:
I finally realized why clang has not been silencing its warnings about
unused return values: I have -Wno-unused-value set in CFLAGS which
comes before OPT (which defines -Wall) as set in PY_CFLAGS in
Makefile.pre.in.
I could obviously set OPT in my environment, but that would
Antoine Pitrou wrote:
Antoine Pitrou pitrou.net> writes:
Roumen Petrov roumenpetrov.info> writes:
Antoine Pitrou wrote:
In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!).
And alignment is ?
16 bytes as well.
This is probably why, by the way, a PyGC_Head
Antoine Pitrou wrote:
Christian Tismer stackless.com> writes:
Well, I doubt that a 12 byte long double causes any other
alignment but 4.
In 32-bit mode, no. But under x86-64 Linux, a long double is 16 bytes (!!).
And alignment is ?
___
Python-De
Christian Tismer wrote:
Hi all,
I was hacking to get mingw32 builds of psyco to work
and found a pretty weird thing:
I used mingw32 (stable distro) to build the psyco extension
on top of standard python2.6, built with Visual Studio,
and got weird crashes.
The reason is in objimpl.h:
typedef u
Christian Tismer wrote:
On 7/22/09 4:56 PM, Roumen Petrov wrote:
Martin v. Löwis wrote:
[SNIP]
No. tim_one changed it to be long double in r25454 to support some
system that Dave Abrahams uses, so it needs to stay that way :-)
However, we can certainly acknowledge that this is a bug in MingW
Martin v. Löwis wrote:
[SNIP]
No. tim_one changed it to be long double in r25454 to support some
system that Dave Abrahams uses, so it needs to stay that way :-)
However, we can certainly acknowledge that this is a bug in MingW,
and special case it. Either introduce a symbolic type gchead_align_
Christian Tismer wrote:
Hi all,
I was hacking to get mingw32 builds of psyco to work
and found a pretty weird thing:
I used mingw32 (stable distro) to build the psyco extension
on top of standard python2.6, built with Visual Studio,
and got weird crashes.
The reason is in objimpl.h:
typedef u
Roumen Petrov wrote:
Cesare Di Mauro wrote:
Have you made some benchmarks like pystone?
Its seems to me version 2.6.1 is not optimized build so I
remove(uninstall) it.
I repeat the pystone tests with an optimized GCC(mingw32) build.
- python-trunk-GCC(mingw32, local, native, optimized
Luke Kenneth Casson Leighton wrote:
[SNIP]
Yes it is enough to encapsulate memory allocation and file functions into
python shared library. The python provide memory allocation functions, but
not all modules use them. File functions are hiden by posixmodule and python
modules can't use them.
ex
Luke Kenneth Casson Leighton wrote:
On Fri, Jan 23, 2009 at 10:48 PM, Roumen Petrov
[SNIP]
but it would certainly mean that there would be both a future-proof
path for binary modules from either msvc-compiled _or_ mingw-compiled
2.5, 2.6, 2.7 etc. to work with 2.5, 2.6, 2.7, 2.8 etc. _without_
[SNIP]
No, Python 2.5 is linked with msvcr71.dll.
ehn? i don't see that anywhere in any PC/* files - i do see that
there's a dependency on .NET SDK 1.1 which uses msvcr71.dll
Take a look at PCbuild/pythoncore.vcproj. It says
Version="7.10"
This is how you know VS 2003 was used to bu
Luke Kenneth Casson Leighton wrote:
[SNIP]
python.exe (say, the official one) loads
python25.dll. Then, an import is made of a ming-wine extension, say
foo.pyd, which is linked with libpython2.5.dll, which then gets loaded.
Voila, you have two interpreters in memory, with different type objects,
anatoly techtonik wrote:
On Thu, Jan 22, 2009 at 12:51 AM, Roumen Petrov
wrote:
Against 2.3, rejected due to dependence on SCons.
Also appears to have been incomplete, needing more work.
No it was complete but use SCons. Most of changes changes in code you will
see again in 3871.
I would
rdmur...@bitdance.com wrote:
On Fri, 23 Jan 2009 at 21:23, "Martin v. L�wis" wrote:
Given that a Unix OS can't know what encoding a filename is in (*),
I can't see that one could practically implement a Unix FTP server
in any other way.
However, an ftp server is different. It might start up wi
Luke Kenneth Casson Leighton wrote:
version. I hope that users will understand that it is disjoint from
the python.org version (as they seem to understand fine for the
Cygwin build, which already picks up its extension modules also from
a disjoint location, which helps to keep the two separate).
Luke Kenneth Casson Leighton wrote:
On Wed, Jan 21, 2009 at 9:13 PM, "Martin v. Löwis" wrote:
ok, so - different from what's being generated by ./configure under
msys under wine or native win32 - what's being generated (libpython 2
. 5 . a and libpython 2 . 5 . dll . a) is more akin to the cyg
Cesare Di Mauro wrote:
Have you made some benchmarks like pystone?
There is result from pystone test test run an old PC (NT 5.1):
- 2.6(official build):
42194,6; 42302,4; 41990,8; 42658,0; 42660,6; 42770,1
average=42429,4
deviation=311,6
- 2.6.1(official build):
35612,1; 35778,8; 35666,
://bugs.python.org/issue841454
Against 2.3, rejected due to dependence on SCons.
Also appears to have been incomplete, needing more work.
No it was complete but use SCons. Most of changes changes in code you
will see again in 3871.
http://bugs.python.org/issue3754
Open by Roumen Petrov, no review, see below
Luke Kenneth Casson Leighton wrote:
[SNIP]
i'm going to _try_ to merge in #3871 but it's... the prospect of
sitting waiting for configure to take THREE hours to complete, due to
/bin/sh.exe instances taking TWO SECONDS _each_ to start up does not
really fill me with deep joy.
As from version 1.
Hi All,
May I ask for a vote how issue to be resolved.
The problem is command "... setup.py install ... --root=/$(DESTDIR)" if
DESTDIR is specified:
error: could not create '//...': No such host or network path
Currently issue http://bugs.python.org/issue2233 propose three solutions:
1) replace
25 matches
Mail list logo
