New submission from Vitaly Murashev:
[Affects Windows only]
Brief description (after analysis in debugger):
Py_InitializeEx fails inside internal call:
1.
if (initstdio() < 0)
Py_FatalError(
"Py_Initialize: can't initialize sys standard streams");
2
Vitaly Murashev added the comment:
More details:
previously Python3.4.3 was compiled in my environment using compiler from
VisualStudio-2005 and everything worked well. The crash has come right after
changing compiler to the one from VisualStudio-2013
So something definitely changed inside
Vitaly Murashev added the comment:
patch suggested
--
keywords: +patch
Added file: http://bugs.python.org/file39854/pythonrun.c.diff
___
Python tracker
<http://bugs.python.org/issue24
Changes by Vitaly Murashev :
--
title: [VS2013] Py_InitializeEx causes fatal error being from winnt-service ->
[VS2013] Py_InitializeEx causes fatal error being called from winnt-service
___
Python tracker
<http://bugs.python.org/issu
New submission from Vitaly Murashev:
Current time on my machine with Windows7x64 is set to year 2045 for test
purposes.
Since Python3.5(amd64) I have an OverflowError when I am trying to call
datetime.datetime.now()
It looks like a regress since there was no such error on Python3.4.3
Could
Vitaly Belman added the comment:
Note: Using pip library enum34
--
___
Python tracker
<http://bugs.python.org/issue25281>
___
___
Python-bugs-list mailin
New submission from Vitaly Belman:
Possibly related to: http://bugs.python.org/issue18264
The following code:
>>> import IntEnum from enum
>>> from enum import IntEnum
>>> class a(IntEnum): a=0
>>> json.loads(json.dumps({"x": a.a}))
Produces
New submission from Vitaly Murashev:
Hi,here the issue:
We (crystax.net) use custom builds of cpython,
which for windows are compiled by MinGW with pyconfig.h taken from PC/pyconfig.h
And for 32-bit Windows everything works well, but for 64-bit Windows - doesn't.
The root cause of this iss
Changes by Vitaly Murashev :
Added file: http://bugs.python.org/file44806/pyconfig.h.2.7.mingw.patch
___
Python tracker
<http://bugs.python.org/issue28267>
___
___
Pytho
New submission from Vitaly Murashev:
Attempt to complile Python/dynload_win.c by MinGW fails
due to static reimplementation of strcasecmp function in this file:
---
/* Case insensitive string compare, to avoid any dependencies on particular
C RTL implementations */
static int strcasecmp
Changes by Vitaly Murashev :
Added file: http://bugs.python.org/file44809/dynload_win.c.2.7.mingw.patch
___
Python tracker
<http://bugs.python.org/issue28269>
___
___
Vitaly Murashev added the comment:
Patch suggested here is actually the most trivial as it could be.
And at the same time we (crystax.net) can prove that after this patch Python
being compiled by MInGW for 64-bit Windows actually works well. There are other
minor fixes but this one is the
Changes by Vitaly Murashev :
--
type: -> crash
___
Python tracker
<http://bugs.python.org/issue28267>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Vitaly Murashev :
--
type: -> compile error
___
Python tracker
<http://bugs.python.org/issue28269>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Vitaly Murashev :
Added file: http://bugs.python.org/file44812/posixmodule.c.2.7.mingw.patch
___
Python tracker
<http://bugs.python.org/issue28270>
___
___
New submission from Vitaly Murashev:
'posixmodule.c' is written pretty well, but some important MinGW realated macro
are missed.
And as a result an attempt to complile Modules/posixmodule.c by MinGW fails.
So suggested patch (for 3.5.2 and 2.7.12)
just turns on missed MinGW rel
New submission from Vitaly Murashev:
Structured exception handling not supported by MinGW,
and as a result file 'Modules/_ctypes/callproc.c' is not compilable by MinGW
without patching
As I know the patch was initially introduced in Google's repo,
and fixed file 'callproc
Changes by Vitaly Murashev :
Added file: http://bugs.python.org/file44814/callproc.c.2.7.mingw.patch
___
Python tracker
<http://bugs.python.org/issue28271>
___
___
Pytho
Vitaly Murashev added the comment:
We (crystax.net) are building Python for Windows completely by cmake and MinGW
using PC/pyconfig.h without any configure scripts
--
___
Python tracker
<http://bugs.python.org/issue28
Vitaly Murashev added the comment:
> And why not open MS_WIN64 to any Windows compiler
It would be very good idea
Patches suggested here are just the drafts which just work.
Actually I don't believe they will be accepted, so just dropped here for
101 - 120 of 120 matches
Mail list logo
