Change by Jeffrey Armstrong :
--
nosy: -Jeffrey.Armstrong
___
Python tracker
<https://bugs.python.org/issue17226>
___
___
Python-bugs-list mailing list
Unsub
Change by Jeffrey Armstrong :
--
nosy: -Jeffrey.Armstrong
___
Python tracker
<https://bugs.python.org/issue11723>
___
___
Python-bugs-list mailing list
Unsub
Change by Jeffrey Armstrong :
--
nosy: -Jeffrey.Armstrong
___
Python tracker
<https://bugs.python.org/issue20596>
___
___
Python-bugs-list mailing list
Unsub
Change by Jeffrey Armstrong :
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Changes by Jeffrey Armstrong <jeffrey.armstr...@approximatrix.com>:
--
nosy: -Jeffrey.Armstrong
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Jeffrey Armstrong added the comment:
I pulled the 3.5 branch a few minutes ago, and the patch isn't present. Has it
not been pushed to hg.python.org?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24769
Jeffrey Armstrong added the comment:
There is a patch attached to this report for greater than 2 months. Should I
mark this as won't fix?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24217
New submission from Jeffrey Armstrong:
When attempting to build Python without dynamic loading (HAVE_DYNAMIC_LOADING
is not defined), the module _imp will not have the function exec_dynamic.
However, Lib/bootstrap.py seems to assume that _imp.exec_dynamic exists,
causing the error
New submission from Jeffrey Armstrong:
While compiling on Linux/x86 with Open Watcom, I've run into the following at
link time in Modules/mmapmodule.c:
./Modules/mmapmodule.c(1223): Error! E1011: Symbol 'O_RDWR' has not been
declared
The constant isn't defined because fcntl.h isn't included
Changes by Jeffrey Armstrong jeffrey.armstr...@approximatrix.com:
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20596
Jeffrey Armstrong added the comment:
Indeed, I agree. Let's try this new patch.
--
Added file:
http://bugs.python.org/file39408/mmapmodule.py3.5.0a3.HAVE_FCNTL_H.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24217
Jeffrey Armstrong added the comment:
I thought, while I'm here reporting another bug, I'd bump this once more.
There is a patch here, and it corrects clearly broken code. Should I mark this
as won't fix?
--
___
Python tracker rep
Changes by Jeffrey Armstrong jeffrey.armstr...@approximatrix.com:
Removed file: http://bugs.python.org/file39407/mmapmodule.py3.5.0a3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24217
Jeffrey Armstrong added the comment:
Oops, I meant WITH_THREAD. Thanks for the quick fix!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23877
New submission from Jeffrey Armstrong:
If threads are disabled, either via --disable-threads or using a
compiler/standard library that doesn't support threads, the build will fail
when linking the Python interpreter because the following is undefined:
PyGILState_GetThisThreadState
The error
New submission from Jeffrey Armstrong:
Within Modules/posixmodule.c:4914 (in 3.5.0a3), the preprocessor checks for
compiler macros as such:
#if ( defined(__WATCOMC__) || defined(PYCC_VACPP) ) !defined(__QNX__)
result = mkdir(path-narrow);
#else
result = mkdir(path-narrow, mode
Jeffrey Armstrong added the comment:
What's to understand? Some compilers, particularly MinGW and Open Watcom,
already define a PATH_MAX macro on Windows, and it's not necessarily the same
as Python's redefinition of it, possibly causing a compiler error. That's all.
Given the time frame
Jeffrey Armstrong added the comment:
There's not much to look into. If the Python function encounters an argument
error, it returns an uninitialized integer as an error code. This patch
fixes incorrect C code, nothing more.
--
___
Python tracker
Changes by Jeffrey Armstrong jeffrey.armstr...@approximatrix.com:
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20597
Jeffrey Armstrong added the comment:
My patch merely fixes broken code that wasn't being used by Python's
supported compilers under most common configurations. It's really
independent of compiler. I realize nobody here cares about Open Watcom as a
supported compiler; the Python community
Jeffrey Armstrong added the comment:
Georg: Sorry, that wasn't directed at you. Your comment snuck in before mine.
It was more general frustration.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22568
Jeffrey Armstrong added the comment:
The last official Open Watcom release (1.9) is indeed quite dated. The
codebase was forked for a variety of reasons where development continues:
https://github.com/open-watcom/open-watcom-v2
The current development release does indeed build on x86_64
New submission from Jeffrey Armstrong:
The determination of the name of the posix module's initialization function (at
Modules/posixmodule.c:12055) is currently dependent on the compiler being
used. For MSVC, Watcom, or Borland, the name is defined as PyInit_nt.
However, both Open Watcom
New submission from Jeffrey Armstrong:
Under certain circumstances, Modules/posixmodule.c will fail to compile due to
a number of utime-related functions using a variable named utime when a
function named utime already exists in the compiler's C header files.
Specifically, if the following
Jeffrey Armstrong added the comment:
Under the conditions I described in Modules/posixmodules.c on line 4815, the
utime() function is called. With the current code, the following correct
compiler error is emitted:
./Modules/posixmodule.c(4815): Error! E1012: Expression is not a function
Jeffrey Armstrong added the comment:
So in my original report, I actually got things backwards. The failure is
because utime is a local variable, but a call to utime() is then attempted.
Regardless, the code is still completely broken in Modules/posixmodule.c under
the conditions I described
Jeffrey Armstrong added the comment:
Is this patch going to be accepted? It fixes actual incorrect code in msilib,
and it seems to have stagnated
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21931
Jeffrey Armstrong added the comment:
Was this ever accepted?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20597
___
___
Python-bugs-list
Jeffrey Armstrong added the comment:
Next time I see a bug I'll be sure to wait rather than actually submit a
patch...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17391
Jeffrey Armstrong added the comment:
This patch is so old at this point, it doesn't apply. Obviously its contents
are of no interest to anyone.
--
resolution: - wont fix
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Jeffrey Armstrong added the comment:
Attached a patch. The dangers of using goto...
--
keywords: +patch
Added file: http://bugs.python.org/file35935/_msi.3.4.0.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21931
New submission from Jeffrey Armstrong:
The function fcicreate in PC/_msi.c can return nonsense if the list of files
passed to msilib.FCICreate does not contains tuples as expected. To replicate,
import msilib
msilib.FCICreate(test.cab, [entry.txt])
The above code will return a ValueError
Jeffrey Armstrong added the comment:
I didn't receive any feedback on the last patch from 2014-02-12. Is this issue
effectively dead?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20596
Jeffrey Armstrong added the comment:
I know that Borland/Embarcadero also uses the two-argument version like
Microsoft. As I said earlier, MinGW uses the two-argument version, although it
is currently marked as deprecated. Just from searching, it appears that Pelles
C/LCC uses the POSIX
Jeffrey Armstrong added the comment:
I've included a revised patch that is far simpler than the others I've
proposed. In this example, the preprocess checks for MSVC or
Borland/Embarcadero and, if found, uses three-argument wcstok_s(). If neither
is detected, it checks for MinGW
New submission from Jeffrey Armstrong:
The file Python/getargs.c currently uses an array initializer with a runtime
variable, causing compile errors on strict C89 compilers. The variables named
freelist in vgetargs1() and vgetargskeywords() both use non-constant
initializers. The attached
New submission from Jeffrey Armstrong:
In two locations, the current interpreter code makes some assumptions
concerning the syntax of the wcstok() function based solely on the operating
system (Windows, in this case). Compilers other than MSVC may (and do) provide
alternative wcstok
New submission from Jeffrey Armstrong:
On some Windows compilers, the constant PATH_MAX may already be defined, which
will cause compile errors on non-MSVC compilers (notably Open Watcom and
MinGW). Rather than assume it is not available and define it in all #ifdef
MS_WINDOWS cases
Jeffrey Armstrong added the comment:
Depending on your compiler, yes, it is more than a theoretical problem. I am
building using the Open Watcom compiler, and it chokes on these initializers
due to their non-conformance. I would assume some other obscure,
non-GNU/non-MSVC/non-Clang
Jeffrey Armstrong added the comment:
Here's an additional patch removing PATH_MAX from Modules/main.c and
Python/pythonrun.c. This solution works fine for me.
--
Added file: http://bugs.python.org/file34044/remove_path_max.default.patch
___
Python
Jeffrey Armstrong added the comment:
I've replaced the patch with a newer version that defines Py_WCSTOK in
Include/pyport.h as Victor suggested.
--
Added file: http://bugs.python.org/file34045/wcstok.default.patch
___
Python tracker rep
Jeffrey Armstrong added the comment:
PATH_MAX is defined in both Open Watcom and MinGW's GCC toolchain. Neither is
a supported compiler, I suppose. I hadn't meant to suggest that it be
included in 3.4's release candidate, only that the problem exists on current
versions
Jeffrey Armstrong added the comment:
Based on the comments thus far, I've gone ahead with another version of this
patch. Py_WCSTOK is now defined regardless of OS. For Windows, it chooses
between MSVC's wcstok_s, Open Watcom's wcstok, and MinGW's/misc's two-argument
wcstok. If the platform
New submission from Jeffrey Armstrong:
The code within Python/Python-ast.c does not currently conform to C89 standard.
Within the function PyAST_obj2mod(), the array 'req_type' is initialized using
runtime values, which is not allowed by the standard, causing building to fail
on a C89
Jeffrey Armstrong added the comment:
That was sloppy of me to not check other modules. I hadn't encountered them in
my build yet. Here's a patch for Modules/_ctypes/_ctypes.c and
Modules/_ctypes/callbacks.c. The arguments were changed similarly to myself.
--
Added file: http
Jeffrey Armstrong added the comment:
And finally here's the necessary changes to Modules/_elementree.c as well.
--
Added file: http://bugs.python.org/file32312/_elementree._self.3.3.2.patch
___
Python tracker rep...@bugs.python.org
http
New submission from Jeffrey Armstrong:
In an attempt to overhaul the existing Open-Watcom-specific portions of
CPython, I encountered a number of issues related mostly to preprocessor
directives surrounding support for the Open Watcom toolchain on Windows.
Specifically, there were a number
New submission from Jeffrey Armstrong:
At Modules/_io/textio.c:285, one argument to
_PyIncrementalNewlineDecoder_decode is named _self. The name _self,
however is a keyword on older Microsoft C compilers and certain other compilers
attempting to maintain compatibility with Microsoft
Changes by Jeffrey Armstrong jeffrey.armstr...@approximatrix.com:
--
type: - compile error
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19356
Changes by Jeffrey Armstrong jeffrey.armstr...@approximatrix.com:
--
type: - compile error
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19355
Jeffrey Armstrong added the comment:
...the fact that this issue has been open for almost 2 years is quite
ridiculous.
I thought that I'd add a little statistic for everyone that might put this bug
into perspective. Since this bug was opened, the MinGW installer has been
downloaded about
Changes by Jeffrey Armstrong jeffrey.armstr...@approximatrix.com:
--
nosy: +Jeffrey.Armstrong
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11723
Changes by Jeffrey Armstrong jeffrey.armstr...@approximatrix.com:
--
nosy: +Jeffrey.Armstrong
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12641
New submission from Jeffrey Armstrong:
When compiling Modules/_cursesmodule.c as a static module with GCC 2.95.3, an
error is encountered on line 2260 in PyCurses_GetWin. The error occurs because
the PyCursesInitialised macro appears prior _Py_IDENTIFIER(read), which is
actually a variable
Changes by Jeffrey Armstrong jeffrey.armstr...@approximatrix.com:
--
components: +Extension Modules -Build
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17391
Jeffrey Armstrong added the comment:
Alan, I was about to file a bug as well because I'm not even getting a libintl
dependency to be acknowledged under these build conditions. What versions of
gettext and GCC are you using?
Ned, not sure if it matters, but the libintl page does specify
Jeffrey Armstrong added the comment:
I would suggest a more straightforward patch. My understanding is that the
standard library on the m68k-atari-mint platform does not include the necessary
gettext functionality. This functionality is present in glibc, however. A
more direct test might
Jeffrey Armstrong added the comment:
Is Christian's patch going to be sufficient for the time being? Just curious.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16880
Jeffrey Armstrong added the comment:
Sorry, I think my question was a bit vague. Christian's patch does, in fact,
work fine for fixing the problem as reported. I was wondering if the patch was
sufficient to close the bug with a commit. I didn't know if other work was
ongoing to close
Jeffrey Armstrong added the comment:
I've attached the patch, and I probably should have done so in the first place.
It applies to Python 3.3.0. The resulting code compiles fine on
m68k-atari-mint. It shouldn't affect any of the major platforms.
--
Added file: http
New submission from Jeffrey Armstrong:
On a platform with a broken poll() function (as detected during configure),
Modules/selectmodule.c fails to compile. The error occurs at two points:
./Modules/selectmodule.c:2100: `select_poll' undeclared here (not in a function)
./Modules/selectmodule.c
Changes by Jeffrey Armstrong jeffrey.armstr...@approximatrix.com:
--
type: - compile error
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16953
Jeffrey Armstrong added the comment:
Terry: If I'm understanding this correctly, C_EXTENSION implies a dynamically
loaded module authored in C. The issue on FreeMiNT, the operating system in
question, is that there is no support for true shared objects. Any C modules
must be statically
New submission from Jeffrey Armstrong:
On a platform where dynamic loading is unsupported, the function
imp_load_dynamic is not compiled (Python/import.c:1775), and the Python
function load_dynamic (Python/import.c:1845) will not be included in the _imp
module. However, Lib/imp.py attempts
New submission from Jeffrey Armstrong:
The Py_ARRAY_LENGTH macro (Include/pymacro.h:36) checks to see if using GCC by
simply looking for __GCC__ being defined. If so, it uses the GCC extension
function __builtin_types_compatible_p. However, this function was not
introduced until GCC 3.1
Jeffrey Armstrong added the comment:
The patch works with respect to allowing the interpreter to start, and
importing modules from the interpreter seems to be working fine. I can't speak
to Brett's concerns about possible side effects of setting load_dynamic to None
66 matches
Mail list logo
