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 :
--
nosy: -Jeffrey.Armstrong
___
Python tracker
<http://bugs.python.org/issue29936>
___
___
Python-bugs-list mailing list
Unsub
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
<http://bugs.python.org/is
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
<http://bugs.pyt
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&qu
Changes by Jeffrey Armstrong :
Removed file: http://bugs.python.org/file39407/mmapmodule.py3.5.0a3.diff
___
Python tracker
<http://bugs.python.org/issue24217>
___
___
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
<http://bugs.python.org/is
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?"
--
Changes by Jeffrey Armstrong :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20596>
___
___
Python-bugs-
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 fc
Jeffrey Armstrong added the comment:
Oops, I meant WITH_THREAD. Thanks for the quick fix!
--
___
Python tracker
<http://bugs.python.org/issue23877>
___
___
Pytho
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
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(p
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.
Changes by Jeffrey Armstrong :
--
resolution: -> wont fix
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue20597>
___
___
Python-bugs-
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.
--
___
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
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
<http://bugs.python.org/is
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 compi
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, b
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:
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
The
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 file
Jeffrey Armstrong added the comment:
Was this ever accepted?
--
___
Python tracker
<http://bugs.python.org/issue20597>
___
___
Python-bugs-list mailing list
Unsub
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
<http://bugs.python.org/issue21
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
<http://bugs.python.org/is
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
<http://b
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
<http://bugs.python.org/issue21
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
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
<http://bugs.python.org/is
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 Min
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:
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
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 ex
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
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
___
P
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
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"
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:
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:
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
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
<http://bugs.python.org/is
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."
---
Changes by Jeffrey Armstrong :
--
type: -> compile error
___
Python tracker
<http://bugs.python.org/issue19356>
___
___
Python-bugs-list mailing list
Un
Changes by Jeffrey Armstrong :
--
type: -> compile error
___
Python tracker
<http://bugs.python.org/issue19355>
___
___
Python-bugs-list mailing list
Un
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 compatib
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
Changes by Jeffrey Armstrong :
--
nosy: +Jeffrey.Armstrong
___
Python tracker
<http://bugs.python.org/issue11723>
___
___
Python-bugs-list mailing list
Unsub
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
Changes by Jeffrey Armstrong :
--
nosy: +Jeffrey.Armstrong
___
Python tracker
<http://bugs.python.org/issue12641>
___
___
Python-bugs-list mailing list
Unsub
Changes by Jeffrey Armstrong :
--
components: +Extension Modules -Build
___
Python tracker
<http://bugs.python.org/issue17391>
___
___
Python-bugs-list mailin
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
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:
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:
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
Jeffrey Armstrong added the comment:
Is Christian's patch going to be sufficient for the time being? Just curious.
--
___
Python tracker
<http://bugs.python.org/is
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
Changes by Jeffrey Armstrong :
--
type: -> compile error
___
Python tracker
<http://bugs.python.org/issue16953>
___
___
Python-bugs-list mailing list
Unsubscri
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/selectmod
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 stati
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_dynam
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 unt
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.
66 matches
Mail list logo
