Meador Inge mead...@gmail.com added the comment:
On Fri, Sep 2, 2011 at 4:26 PM, Amaury Forgeot d'Arc
rep...@bugs.python.org wrote:
Amaury Forgeot d'Arc amaur...@gmail.com added the comment:
Certainly the effect of some alloca call with a large value, then the stack
overflows.
Yeah, I
Meador Inge mead...@gmail.com added the comment:
This has been fixed. I verified tip and 2.7.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Meador Inge mead...@gmail.com added the comment:
This is busted for plain old assignment too:
Python 3.3.0a0 (default:6374b4ffe00c, Sep 2 2011, 23:50:39)
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux
Type help, copyright, credits or license for more information.
from ctypes import *
buff
Meador Inge mead...@gmail.com added the comment:
On Thu, Sep 1, 2011 at 9:45 AM, Vlad Riscutia rep...@bugs.python.org wrote:
Vlad Riscutia riscutiav...@gmail.com added the comment:
Meador, I believe this was the first issue on the tracker that got me looking
into bitfield allocation.
I
Meador Inge mead...@gmail.com added the comment:
As stated, how a particular compiler allocates bitfields is *extremely*
implementation specific. There can be differences in implementations between
different compilers, different *versions* of the same compiler, and different
invocations
Meador Inge mead...@gmail.com added the comment:
Hi Vlad,
On Thu, Sep 1, 2011 at 1:30 PM, Vlad Riscutia rep...@bugs.python.org wrote:
Vlad Riscutia riscutiav...@gmail.com added the comment:
Well currently we pack bitfields with an algorithm that uses #ifdefs for GCC
and MSVC builds
New submission from Meador Inge mead...@gmail.com:
As issues like issue6069 and issue11920 allude to, figuring out how 'ctypes'
allocates bit-fields is not very clear. The documentation should be enhanced
to flesh this out in more detail. As an example, Microsoft documents the VC
Changes by Meador Inge mead...@gmail.com:
--
stage: test needed - committed/rejected
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6069
Meador Inge mead...@gmail.com added the comment:
I opened issue12880 for the doc bug. Closing this one out ...
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6069
Meador Inge mead...@gmail.com added the comment:
Hi Steve,
There is currently no way to deal with this situation. Vlad has opened
issue12528 with a proposal to make the allocation strategy configurable from
the 'ctypes' API. Please follow that issue if you are still interested. I am
Changes by Meador Inge mead...@gmail.com:
--
nosy: -theller
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9030
Changes by Meador Inge mead...@gmail.com:
--
assignee: theller -
nosy: -theller
priority: normal - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9175
Meador Inge mead...@gmail.com added the comment:
This was, in fact, committed already.
--
assignee: theller -
nosy: +meadori -theller
resolution: - fixed
stage: - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
Meador Inge mead...@gmail.com added the comment:
Whoops. I meant to post a link to the commit before. It is here:
http://hg.python.org/cpython/rev/584db03e5248.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6980
Changes by Meador Inge mead...@gmail.com:
--
assignee: theller -
nosy: -theller
priority: normal - low
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5718
Changes by Meador Inge mead...@gmail.com:
--
assignee: theller -
nosy: -theller
priority: normal - low
stage: - patch review
type: - compile error
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6006
Meador Inge mead...@gmail.com added the comment:
Vlad,
Thanks for the patch. A few nits:
1. The test case is in 'test_bitfields.py'.
I think it should go in 'test_structures.py'.
2. The test case would probably be cleaner using a 'with' context
manager
New submission from Meador Inge mead...@gmail.com:
Reproduced on Fedora 15 with tip Python:
[meadori@motherbrain cpython]$ ./python
Python 3.3.0a0 (default:3102951cc1ce+, Sep 1 2011, 22:19:06)
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux
Type help, copyright, credits or license for more
Meador Inge mead...@gmail.com added the comment:
Hmmm ... Assuming a native VC++ compiler on an x86 machine running Windows,
then it doesn't make sense to validate these test cases in such an environment.
All the tests are all big-endian.
'ctypes' can't be expected to behave the same
Meador Inge mead...@gmail.com added the comment:
That is a good question. While it is true that errors other than
'PyExc_OverflowError', will be mapped onto a 'TypeError' I don't think that is
a bad thing. Any errors that come out of 'PyFloat_AsDouble' should be handled
on a case-by-case
Meador Inge mead...@gmail.com added the comment:
Thanks a lot for committing this for me Amaury.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11241
Meador Inge mead...@gmail.com added the comment:
This patch was marked as accepted, but it doesn't seem to be committed. Will
someone commit it?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11241
Changes by Meador Inge mead...@gmail.com:
--
resolution: accepted -
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8743
Changes by Meador Inge mead...@gmail.com:
--
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2651
___
___
Python
Changes by Meador Inge mead...@gmail.com:
--
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7433
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
I agree that this violates C99, but is this actually causing any real world
problems with the platforms Python supports? If so, then we need a test case.
This seems low priority
--
assignee: theller -
nosy: +amaury.forgeotdarc
Meador Inge mead...@gmail.com added the comment:
Ping. I think this one is OK to commit.
--
nosy: +belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9651
Meador Inge mead...@gmail.com added the comment:
Stefan, it is a constructed failure (I hacked the unit test to break it).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12740
Meador Inge mead...@gmail.com added the comment:
On Sun, Aug 14, 2011 at 1:03 PM, Stefan Krah rep...@bugs.python.org wrote:
Stefan Krah stefan-use...@bytereef.org added the comment:
I like random tests in the stdlib, otherwise the same thing gets tested
over and over again. `make
Meador Inge mead...@gmail.com added the comment:
The functionality part of the patch looks reasonable. However, the
pseudo-randomization in the unit tests seems like a bad idea. Say someone is
adding a new feature X. Runs the unit tests to find one of them failing. Then
runs them again
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12744
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12744
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
Michael,
It is hard to tell from your description alone where the bug is. Could you
provide more detailed reproduction steps with a test case that exhibits the
issue?
--
nosy: +jnoller, meador.inge
stage: - test needed
Meador Inge mead...@gmail.com added the comment:
Amaury, how about this patch? I got rid of querying the type dictionary and
hoisted the creation of the type instance earlier. Then
'PyObject_GetAttrString' can be used to lookup '_length_' and '_type_' by the
regular Python attribute lookup
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11105
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
I have verified that the code checked in for issue12575 keep the test case from
this issue from crashing the interpreter:
[meadori@motherbrain cpython]$ ./python test.py
Traceback (most recent call last):
File test.py, line 14, in module
Meador Inge mead...@gmail.com added the comment:
OK, I am marking this as fixed then. If someone decides to fix this in 3.2 or
3.7, then they can reopen the issue.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
Changes by Meador Inge mead...@gmail.com:
--
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4841
___
___
Python
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12613
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
I see two problems that cause the posted test cases to fail:
1. The 'next' fixer runs before the 'itertools' fixer and strips
out a 'power' node. This keeps the 'itertools' fixer from
matching.
2. The 'itertools' fixer does
Meador Inge mead...@gmail.com added the comment:
Thanks for the test case Albert. The attached patch adds a unit test based off
of the given repro case and fixes the bug in the FunctionDef compiler. The
compiler was hitting a NULL pointer deref on FunctionDefs with empty list
bodies
Meador Inge mead...@gmail.com added the comment:
But what happens with a third level?
That doesn't work. I have a test case for that, but the test case has
a typo that caused it to pass. I will fix the test case and the code.
Thanks
Meador Inge mead...@gmail.com added the comment:
Verified that this is still broken in the main development branch.
The base type should be checked for '_type_' or '_length_' before throwing
an error. Attached is a patch that fixes the problem and adds covering
tests. The full test suite
Meador Inge mead...@gmail.com added the comment:
This doesn't look like it has anything to to with the 'ctypes' library
component (http://docs.python.org/library/ctypes). So I am removing
'ctypes' from the 'Components' selection. Please correct me if I am
wrong ...
--
components
Changes by Meador Inge mead...@gmail.com:
--
components: +Macintosh
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10910
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
This problem still occurs in the main development branch. I think the
'PyErr_ExceptionMatches' check that Pauli suggested will work. The same
problem exist for 'c_float', 'c_double', and 'c_longdouble'.
Attached is a patch that fixes
Meador Inge mead...@gmail.com added the comment:
This crash still occurs in the main development branch and Amaury's patch
still fixes the problem. I verified that all tests pass on OS X 10.6.5.
It should be OK to commit.
--
assignee: theller -
nosy: +meador.inge -theller
versions
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11477
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
Is there still any interest in this work?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3132
Meador Inge mead...@gmail.com added the comment:
Attached is the latest version of the struct string patch. I tested on OS X
10.6.5 (64-bit) and Ubuntu 10.04 (32-bit). I also scanned for memory problems
with Valgrind. There is one test failing on 32-bit systems ('test_crasher
Meador Inge mead...@gmail.com added the comment:
How is the compiler supposed to know whether a and b belong to the same
array when compiling ptr_compare?
I agree with Mark, it doesn't need to know. However, many compilers [1,2]
support whole program optimization and could in theory figure
New submission from Meador Inge mead...@gmail.com:
Currently with 'py3k' only 'bytes' objects are accepted for tokenization:
import io
import tokenize
tokenize.tokenize(io.StringIO(1+1).readline)
Traceback (most recent call last):
File stdin, line 1, in module
File /Users/minge/Code
Changes by Meador Inge mead...@gmail.com:
--
components: +Library (Lib)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9969
___
___
Python-bugs
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2180
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
I agree with Antoine's LIFO comment. Also, FWIW, the C standard library
behaves in a LIFO manner as well (C99 spec - 7.20.4.3 clause 3):
First, all functions registered by the atexit function are called, in the
reverse order
Meador Inge mead...@gmail.com added the comment:
To fix the segfault, I suppose that we use a more strict validation on
the input type. Eg. Use PyUnicode_Check() instead of
PyObject_IsInstance()?
Where would the more strict validation take place? This problem is not unique
to Unicode
Meador Inge mead...@gmail.com added the comment:
Overall, this patch look reasonable. I tested on py3k and the the tests pass.
I also did a few micro-benchmarks to verify the speedup.
One question I do have, though, is whether the 'len' calculation modifications
are necessary? This looks
Meador Inge mead...@gmail.com added the comment:
I believe this is slightly tricky because 'bdb.format_stack_entry' makes
references to '.f_locals' and 'bdb.format_stack_entry' is invoked in several
places in 'pdb'. One option would be to add a extra parameter to
'bdb.format_stack_entry
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9633
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
Overall the patch looks good. I don't think it is an extremely important
feature, but similar support is already available in other places (e.g.
'struct', 'ctypes').
Here is a patch updated for py3k with some minor additions:
(1) Fixed
Changes by Meador Inge mead...@gmail.com:
--
assignee: teoliphant - meador.inge
priority: critical - high
stage: unit test needed - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3132
Changes by Meador Inge mead...@gmail.com:
--
nosy: +minge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4188
___
___
Python-bugs-list mailing list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +minge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5248
___
___
Python-bugs-list mailing list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +minge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1172711
___
___
Python-bugs-list mailing
Meador Inge mead...@gmail.com added the comment:
Sure. I take it you meant http://svn.python.org/projects/sandbox/trunk/2to3,
though. Is this the location that all patches for 2to3 should be produced
against?
I dropped the documentation changes b/c I did not see any docs in the 2to3
trunk
Changes by Meador Inge mead...@gmail.com:
--
nosy: +minge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9249
___
___
Python-bugs-list mailing list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +minge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9011
___
___
Python-bugs-list mailing list
Meador Inge mead...@gmail.com added the comment:
[Mark]
Can you think of any reason that we shouldn't just copy the py3k
implementation ...
Not that I can think of. Like you pointed out, we should have removed the
coercion from the rich comparison when fixing issue 5211.
Thanks for all
Meador Inge mead...@gmail.com added the comment:
I'm not sure that's a good idea: mightn't this change behaviour for
user-defined classes with a __coerce__ method? Maybe it would be
better to just special-case ints and longs at the start of
complex_richcompare, and then leave everything
Changes by Meador Inge mead...@gmail.com:
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8748
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
stage: - needs patch
type: - feature request
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2470
Meador Inge mead...@gmail.com added the comment:
Hmm. The current Python 2.7 behaviour really is a mess.
No doubt!
Your patch removes the coercion entirely;
Yeah, I know. The funny thing about this is that according to the
documentation [1]:
Arguments to rich comparison methods
Meador Inge mead...@gmail.com added the comment:
is that correct, or should the production list be something like:
Yup, you are right. I will change the grammar.
Whether these cases are valid or not (personally, I think they should
be), we should add some tests for them
Meador Inge mead...@gmail.com added the comment:
Thanks for the review. I incorporated the check re-orderings.
I am also writing more tests. Which already exposed a subtly that I was not
expecting:
Python 3.2a0 (py3k:81284M, May 20 2010, 09:08:20)
[GCC 4.2.1 (Apple Inc. build 5646
Meador Inge mead...@gmail.com added the comment:
As a separate issue, I notice that the new 'T{}' code doesn't respect
multiplicities, e.g., as in 'H3T{HHL}'. Is that
intentional/desirable?
That could have been an oversight on my part. I don't see any immediate reason
why we wouldn't
Meador Inge mead...@gmail.com added the comment:
Thanks for the updated patch; I'll take a closer look tonight, and
apply it if all looks good.
I incorporated the changes locally and have not updated the patch yet. I will
update it later today
Meador Inge mead...@gmail.com added the comment:
Granted, yes. But I wouldn't expect the same padding for 'BT{BI}' and
'BBI'. 'BT{BI}' should match a C struct which itself has an embedded
struct. For C, I get the following results on my machine:
I wasn't sure. The C99 standard does
Meador Inge mead...@gmail.com added the comment:
No problem! I have attached the updated patch.
I am starting on the 2.7 patch now.
--
Added file: http://bugs.python.org/file17424/issue-8748.2.patch
___
Python tracker rep...@bugs.python.org
http
Meador Inge mead...@gmail.com added the comment:
2.7 patch attached. The implementation is mostly the same as the 3.2 one, but
there is one quirk. Namely, 2.7 (and other 2.x's) has the following odd
behavior:
1j None
False
1j 1
Traceback (most recent call last):
File
Meador Inge mead...@gmail.com added the comment:
For a complex number z and an integer i, 'z == i' should be exactly
equivalent to 'z.real == i and z.imag == 0.0'.
Like you mentioned before a lot of care is taken in 'floatobject.c' to ensure
that the comparison is robust. Would
Meador Inge mead...@gmail.com added the comment:
Does this patch seem reasonable?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7902
Meador Inge mead...@gmail.com added the comment:
Sure - http://codereview.appspot.com/1258041
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3132
Meador Inge mead...@gmail.com added the comment:
Attached is a patch that implements part of the additions. More specifically,
the 'T{}' syntax and the ability to place byte-order specifiers ('', '', '@',
'^', '!, '=') anywhere in the struct string.
The changes dictated by the PEP are so
Meador Inge mead...@gmail.com added the comment:
wonder whether they should be converted to little-endian
I thought about that as well. It sure would make creating new examples easier
:) I had to construct the new examples by hand.
I can regenerate the examples for little-endian if you
Meador Inge mead...@gmail.com added the comment:
Sure, if you want to. [Then I won't be able to reproduce what's in the
docs on either of my machines. :) One's 32-bit big-endian; the other's
64-bit little-endian.]
I guess it's painful either way. I think the only fair thing to do
Meador Inge mead...@gmail.com added the comment:
Those last two sentences where meant to be in response to your Merged your
changes and subsequent tweaks to py3k in r80016. comment. I tried to reply to
the tracker from my mail client and things got reformatted
Changes by Meador Inge mead...@gmail.com:
--
nosy: +minge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7433
___
___
Python-bugs-list mailing list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +minge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7355
___
___
Python-bugs-list mailing list
Meador Inge mead...@gmail.com added the comment:
I'm half-convinced that struct.pack *should* ideally add trailing
padding in the same situation that C does, for consistency with C.
Then calcsize would match C's sizeof.
Maybe... AFAIK, the C language does not mandate structure padding
Meador Inge mead...@gmail.com added the comment:
would be to add enough padding so that the alignment of the struct
matches the largest alignment of any member of the struct.
That might work. I will have to think about it a bit.
On the subject of documentation
Attached a doc patch which
Meador Inge mead...@gmail.com added the comment:
Looks good to me.
--
status: pending - open
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8300
Meador Inge mead...@gmail.com added the comment:
I may be missing something subtle, but how can 'PyNumber_Index(v) != NULL'
*and* '!PyInt_Check(v) !PyLong_Check(v)' both be satisfied in the
'get_pylong' mods? It seems to me that 'PyNumber_Index' only returns non-NULL
when the object being
Meador Inge mead...@gmail.com added the comment:
Hi Eric,
(-2) and (-3) are different. The changes that I made, however, are pretty
minor. Also, they are all in 'test_builtin.py'.
--
___
Python tracker rep...@bugs.python.org
http
Meador Inge mead...@gmail.com added the comment:
(2) For 2.x, I'm a bit uncomfortable with introducing the extra Python layer
on top of the C layer. Partly I'm worried about accidentally breaking
something (it's not 100% clear to me whether there might be hidden
side-effects
Meador Inge mead...@gmail.com added the comment:
If anyone's interested in submitting a patch, it would be welcome.
Sure. I saw where this was partly addressed in r78690. The attached patch
adds support for the '__index__' conversion that Mark
suggested.
At first glance, the patch may
Meador Inge mead...@gmail.com added the comment:
It seems to me from the grammar
(http://docs.python.org/reference/expressions.html#grammar-token-conditional_expression)
that the precedence for conditional expressions fall in between that of
'lambda' and 'or' expressions.
--
keywords
Meador Inge mead...@gmail.com added the comment:
This is common practice in the standard library.
This doesn't necessarily mean it is a correct practice :-). All
kidding aside, I think the assumption that the standard documentation
on '__enter__' and '__exit__' is sufficient is a bad one
Meador Inge mead...@gmail.com added the comment:
What about changing the exception test to something like what I did in
issue7232.4.diff?
That is definitely more succinct, but Lars' solution provides more information
about _why_ the test fails. IMHO, the descriptiveness is
more important
Meador Inge mead...@gmail.com added the comment:
The patch looks reasonable. I built on it with the following changes:
1. Added some extra test cases to cover Unicode format strings,
since the code was changed to handle these as well.
2. Changed test_builtin.py by
s/m[0
Meador Inge mead...@gmail.com added the comment:
Built on Brian's patch by adding the following items:
* Added a unit test case to cover exceptional conditions.
* Added doc strings on __enter__ and __exit__ (more consistent
with the surrounding code).
* Spelling error in doc
501 - 600 of 625 matches
Mail list logo
