Meador Inge mead...@gmail.com added the comment:
Most definitely not. It is very deliberate that asdl_c.py is only
invoked when the ASDL sources change. Otherwise, having Python installed
would be a build requirement for Python, which it must be not.
OK, thanks for the background
New submission from Meador Inge mead...@gmail.com:
While implementing a patch for issue13096 I found a reference leak in 'ctypes'.
I couldn't find the cause immediately, but it can be
reproduced by applying the attached patch and running:
[meadori@motherbrain cpython]$ ./python -m test -R
Meador Inge mead...@gmail.com added the comment:
Ah, I see now. Thanks Benjamin.
So it's not a bug at all, right?
A bug in regrtest.py maybe. 'dash_R_cleanup' clears various other caches in
between test runs to avoid false positives like this. Perhaps
'ctypes._pointer_type_cache'
should
Meador Inge mead...@gmail.com added the comment:
Nick, the revised definition of 'getclosurevars' seems reasonable to me.
I will cut a new patch this week.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
Meador Inge mead...@gmail.com added the comment:
Good catch. I see what happened. 7109f31300fb updated
Python/Python-ast.c but not Parser/asdl_c.py. I will apply your patch
shortly. Thanks.
--
assignee: - meador.inge
nosy: +meador.inge
stage: - patch review
Meador Inge mead...@gmail.com added the comment:
Oh, and just to be clear I reproduced the build break by doing:
./Parser/asdl_c.py -c ./Python ./Parser/Python.asdl
make
in a built tree. The reason that this wasn't caught is that the make
rules have the ASDL files as dependencies on the AST C
Meador Inge mead...@gmail.com added the comment:
Committed. Thanks!
--
nosy: -python-dev
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13243
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12675
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13217
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
stage: - test needed
type: - resource usage
versions: +Python 2.7, Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13199
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13183
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13187
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
perhaps 'getclosurevars' would do as the name?
I like vars. Updated patch attached.
--
Added file: http://bugs.python.org/file23368/issue13062-3.patch
___
Python tracker rep...@bugs.python.org
http
Meador Inge mead...@gmail.com added the comment:
Yup, it is the 'alloca' call. This issue and issue13097 are both
'alloca' related as mentioned in issue12881.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13096
Meador Inge mead...@gmail.com added the comment:
As mentioned in issue12881, this issue is a result of an unbounded 'alloca'
call that trashes the stack.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13097
Meador Inge mead...@gmail.com added the comment:
Here is an updated patch with error handling. One other thought is that
'getclosure' should be called something like 'getclosureenv' since
technically a closure is a function plus its environment and our
implementation only returns
Meador Inge mead...@gmail.com added the comment:
I can't reproduce this problem in either 2.7.2 or 3.3.0a0.
For example if executed with pypy.
Do you mean that this problem is only reproducible when the attached
script is run with pypy?
--
nosy: +meador.inge
Meador Inge mead...@gmail.com added the comment:
On Sat, Oct 8, 2011 at 5:34 PM, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou pit...@free.fr added the comment:
Before going further with this, I'd suggest you have a look at your
compiler settings.
They are set
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10399
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
Éric, thanks. I fixed most of your points. And thanks to everyone that
reviewed this. Much appreciated.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12943
Changes by Meador Inge mead...@gmail.com:
--
assignee: docs@python - meador.inge
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12943
Meador Inge mead...@gmail.com added the comment:
No problem. This last version LGTM.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3163
Meador Inge mead...@gmail.com added the comment:
Mostly LGTM. I have a few comments in rietveld.
--
nosy: +meador.inge
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3163
Meador Inge mead...@gmail.com added the comment:
On Tue, Oct 4, 2011 at 10:21 AM, Vlad Riscutia rep...@bugs.python.org wrote:
First, I'm saying toying with the underlying buffer because none of the
bugs are actual issues of the form I created this bitfield
structure with Python, passed
Meador Inge mead...@gmail.com added the comment:
Look in 'cfield.c' where all of the native alignments
Well, not *all* the native alignments, but many of them.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12880
New submission from Meador Inge mead...@gmail.com:
Reproducible in 2.7 and tip:
[meadori@motherbrain cpython]$ ./python
Python 3.3.0a0 (default:61de28fa5537+d05350c14e77+, Oct 3 2011, 21:47:04)
[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:
There is similar crasher to this one that can be reproduced like:
[meadori@motherbrain cpython]$ ./python
Python 3.3.0a0 (default:61de28fa5537+d05350c14e77+, Oct 3 2011, 21:47:04)
[GCC 4.6.0 20110603 (Red Hat 4.6.0-10)] on linux
Type help
New submission from Meador Inge mead...@gmail.com:
Reproducible in 2.7 and tip:
[meadori@motherbrain cpython]$ ./python
Python 3.3.0a0 (default:61de28fa5537+d05350c14e77+, Oct 3 2011, 21:47:04)
[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:
Fixed. Opened issue13096 and issue13097 for the other crashers.
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http
Meador Inge mead...@gmail.com added the comment:
On Fri, Sep 30, 2011 at 12:19 PM, Vlad Riscutia rep...@bugs.python.org wrote:
I believe this is the better thing to do rather than detailing how GCC and
MSVC allocated their bitfields because that would just
encourage people to use
Meador Inge mead...@gmail.com added the comment:
Added some comments in rietveld. P.S. watch out for trailing whitespace
when writing patches. Use 'make patchcheck' to help find bad whitespace
formatting.
--
___
Python tracker rep
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13089
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
components: +ctypes
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13091
Meador Inge mead...@gmail.com added the comment:
I can reproduce this with:
valgrind --tool=memcheck --log-file=leaks.txt --leak-check=full
--suppressions=Misc/valgrind-python.supp ./python -m test test_ctypes
Where as:
valgrind --tool=memcheck --log-file=leaks.txt --leak-check=full
Meador Inge mead...@gmail.com added the comment:
this pointer is tied to a CDataObject; its tp_alloc should free the
memory
The free in 'PyCData_clear' is conditional:
if ((self-b_needsfree)
((size_t)dict-size sizeof(self-b_value)))
PyMem_Free(self-b_ptr);
As written
Meador Inge mead...@gmail.com added the comment:
Here is a first cut at a patch. There is one slight deviation from the
original spec:
some nice error checking for when the generator's frame is already gone (or
the supplied object isn't a generator iterator).
The attached patch returns
Meador Inge mead...@gmail.com added the comment:
Fixed a few more nits pointed out in review.
--
Added file: http://bugs.python.org/file23304/issue12943-6.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12943
Changes by Meador Inge mead...@gmail.com:
--
components: +Library (Lib)
stage: - needs patch
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13062
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
I'll take a shot and writing a patch for this one. Nick, are the
elements in 'co_freevars' and '__closures__' always expected to match
up? In other words, is the 'closure' function below always expected to
work (simplified; no error checking
Changes by Meador Inge mead...@gmail.com:
--
resolution: - fixed
stage: test needed - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13013
Changes by Meador Inge mead...@gmail.com:
--
assignee: - meador.inge
versions: +Python 2.7, Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12881
Meador Inge mead...@gmail.com added the comment:
If the function is public I guess that some external module
might use it
Agreed; That is the only case I could deduce as well, which I hinted at
in msg144397. So, I will leave the error check and keep the function
public for now.
I
Meador Inge mead...@gmail.com added the comment:
OK, I will just fix the ref leak in 2.7, 3.2, and 3.3. This is a pretty
low-risk fix (as I mentioned before, I can't see how the error condition is
even executed).
--
___
Python tracker rep
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13044
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
Doing two separate commits is probably better.
Out of curiosity, what is typically the convention on that? The
devguide seems to suggest one changeset per issue:
Just please make sure that you generate a single, condensed patch rather than
Meador Inge mead...@gmail.com added the comment:
I agree that 'bytecode_instructions' is a long-winded. FWIW, I
have worked on or with a fair amount instruction level things and
instruction or instr seem to be the established domain terminology.
Here are a few examples:
* Java ASM - http
Meador Inge mead...@gmail.com added the comment:
I don't think the help option needs to be documented, it will document
itself.
Normally I would document it anyway, but in this case there is only the
one option. So, I dropped it.
An additional suggestion is to catch errors on tokenizing
Meador Inge mead...@gmail.com added the comment:
This patch seems reasonable. Upon looking at the code in more
detail, however, I can't see how the error condition that leaks the
reference can ever by triggered. In particular, the following code
from the 'PyCArrayType_from_ctype' function
Meador Inge mead...@gmail.com added the comment:
In general I agree that a test case is needed, but in this particular
case its looks to be non-trivial to come up with one. The only way
the reference leak is triggered is when memory is exhausted during an
attempt to new up a 'PyStructSequence
Meador Inge mead...@gmail.com added the comment:
I am going to open separate issues for the other crashers.
Also, PyUnicode_FromFormat could be used instead of sprintf.
Amaury, how so? 'sprintf' and 'stgdict-format' work with 'char *'s
where as 'PyUnicode_FromFormat' builds a unicode string
Meador Inge mead...@gmail.com added the comment:
I took a quick look over the final patch (I will do a more thorough
review later). I like the general idea a lot. The first thing that
popped out at me are the names 'OpInfo' and 'get_opinfo'.
'OpInfo' makes it sound like information concerning
Meador Inge mead...@gmail.com added the comment:
+1; the keyword arg version is much more readable.
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13012
Changes by Meador Inge mead...@gmail.com:
--
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11816
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13008
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1172711
Meador Inge mead...@gmail.com added the comment:
Patch looks good. I noticed a change in the conventional type for
'keepends' from 'int' to 'bool'. Several unit tests were updated to
match this change. Perhaps other call sites should be updated too? A
little greping shows:
$ grep -Rl
Meador Inge mead...@gmail.com added the comment:
I'll take this one.
Suman, thanks for finding this. It will help in the future if you don't
open a ton of bugs with the *exact* same title. They are harder to
filter and keep track of that way.
--
assignee: - meador.inge
nosy
Meador Inge mead...@gmail.com added the comment:
Updated patch fixing some issues pointed out by Ezio on Rietveld.
--
Added file: http://bugs.python.org/file23193/issue12943-3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Meador Inge mead...@gmail.com added the comment:
Updated patch which adds and documents a '-h,--help' option. This option
was suggested during code review.
--
Added file: http://bugs.python.org/file23196/issue12943-4.patch
___
Python tracker rep
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
stage: test needed - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1294232
Meador Inge mead...@gmail.com added the comment:
Looks like it was checked in that way
(http://hg.python.org/cpython/rev/14205d0fee45). Patch looks good to me.
--
nosy: +meadori
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Meador Inge mead...@gmail.com added the comment:
v2 patch which addresses comments made by merwok via rietveld.
--
Added file: http://bugs.python.org/file23184/issue12943-2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Meador Inge mead...@gmail.com added the comment:
Did you get commit rights already?
I have not. I still need to submit a contributor agreement as well. I
plan to fax that today.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Meador Inge mead...@gmail.com added the comment:
I specifically meant the 'P' format. As far as I can see, PyLong_AsVoidPtr()
never allowed __int__(), but now index objects can be packed as pointers.
It isn't a big deal, I just have to know for features/pep-3118.
To illustrate
Meador Inge mead...@gmail.com added the comment:
I think Mark's original pointer to issue1762561 was right on. The last
two cases are failing due to the mixed-endian format (mentioned
in that issue) used in OABI.
You can see this in the output of 'test_endian_double':
'182D4454FB210940
Meador Inge mead...@gmail.com added the comment:
OK, I got an OABI system setup. I am seeing the 'test_struct_return_2H'
failure, which actually segfaults in my setup. The difference does,
indeed, seem like an ABI mismatch.
The test code that is failing has a Python side like:
def
Meador Inge mead...@gmail.com added the comment:
The 'test_endian_double' test fails because the 'double' floating-point
type for an interpreter built for OABI is unknown:
float.__getformat__(float)
'IEEE, little-endian'
float.__getformat__(double)
'unknown'
According to [1], the double
Meador Inge mead...@gmail.com added the comment:
Yes, please let's not add any new __int__-based duck typing here;
Mark, just to clarify a bit, the behavior is already there in the array module
(by way of 'PyLong_AsLong'). The fact that it is there was picked up on a code
review
New submission from Meador Inge mead...@gmail.com:
When reviewing the fix for issue1172711 it was discovered that the 'array'
module allows for '__int__' conversions:
import array, struct
a = array.array('L', [1,2,3])
class T(object):
... def __init__(self, value
Meador Inge mead...@gmail.com added the comment:
Okay, understood. But the new 'long long' support provided by this patch
still allows for __int__-based duck typing, right?
Yes, but ...
That's the new duck typing I meant. I see this acceptance of things with an
__int__ method
Meador Inge mead...@gmail.com added the comment:
Updated patch with the 'Py_ssize_t' fixes.
--
Added file: http://bugs.python.org/file23148/issue-1172711.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1172711
Meador Inge mead...@gmail.com added the comment:
Note that there is at least one other place where alloca() is
used with potentially large values:
Ouch! I found three more crashers (including the one you found)
by grepping for 'alloca' in ctypes:
from ctypes import *
T = type('x' * 2
Meador Inge mead...@gmail.com added the comment:
On Mon, Sep 12, 2011 at 7:10 AM, Mark Dickinson rep...@bugs.python.org wrote:
Mark Dickinson dicki...@gmail.com added the comment:
I believe the problem is specific to machines still using the old ABI
('OABI'). Which ABI was being used
Meador Inge mead...@gmail.com added the comment:
Heh, I was just about to upload another patch with your test case. Thanks for
committing this Amaury.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python
Meador Inge mead...@gmail.com added the comment:
import array, struct
a = array.array('L', [1,2,3])
class T(object):
... def __init__(self, value):
... self.value = value
... def __int__(self):
... return self.value
...
a = array.array('L', [1,2,3
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meadori
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12936
___
___
Python-bugs-list mailing
Meador Inge mead...@gmail.com added the comment:
Would you mind explaining your use case and why ctypes won't fit it? Maybe
there is something that can be fixed.
FWIW, I agree that the overloading of 'size' is unnecessary.
--
___
Python tracker
Meador Inge mead...@gmail.com added the comment:
I ran the ctypes tests on Debian GNU/Linux 5.0.8 (lenny) on an ARMv5tejl
Versatile kernel and everything passed. Is anyone else still seeing
errors?
--
assignee: theller -
nosy: +meadori -theller
Meador Inge mead...@gmail.com added the comment:
I see what is going on. I don't think the 'libffi' code can be executed
correctly when built by 'suncc'. The code currently requires
'__attribute__((regparm(1)))', which AFAICT is not implemented by 'suncc';
only 'gcc'.
Take a look
Meador Inge mead...@gmail.com added the comment:
According to the latest release notes
(https://github.com/atgreen/libffi/blob/master/README) the Solaris compiler
should be supported for building:
3.0.10 Aug-23-11
Add support for Apple's iOS.
Add support for ARM VFP ABI
Meador Inge mead...@gmail.com added the comment:
Another example of desperately needed documentation: issue12945.
--
components: +ctypes
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12880
Meador Inge mead...@gmail.com added the comment:
Pavel, I looked into to this a little more and have some ideas. First off,
'_swappedbytes_' is an undocumented implementation detail that is used to
implement the LittleEndianStructure and BigEndianStructure types. So using it
directly like
Meador Inge mead...@gmail.com added the comment:
I am not sure, but it does seem that way considering the most recent libffi
says that 3.0.10 was released on Aug-23-11. What is the process for updating
libffi anyway?
Also, I posted a question concerning the Solaris Studio support on
libffi
Meador Inge mead...@gmail.com added the comment:
Yes I can. This seems strange, but it is correct. The little endian case look
like:
Little endian
---
| unsigned short | unsigned short |
---
|
Meador Inge mead...@gmail.com added the comment:
Ping. Any thoughts on this one?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12881
Meador Inge mead...@gmail.com added the comment:
This patch seems reasonable, is consistent with the GC docs, and passed all
regression tests. Can someone apply?
--
nosy: +amaury.forgeotdarc, belopolsky, meadori
stage: - patch review
type: - behavior
Meador Inge mead...@gmail.com added the comment:
Patch against tip.
--
assignee: - docs@python
components: +Documentation
keywords: +needs review, patch
nosy: +docs@python
stage: needs patch - patch review
Added file: http://bugs.python.org/file23127/issue12943.patch
Meador Inge mead...@gmail.com added the comment:
I can reproduce this on Fedora 15 with the Python tip revision. I am
investigating the behavior now.
--
nosy: +meadori
stage: - needs patch
type: - behavior
versions: +Python 3.2, Python 3.3
Changes by Meador Inge mead...@gmail.com:
Added file: http://bugs.python.org/file23121/issue-1172711.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1172711
Meador Inge mead...@gmail.com added the comment:
Victor, I like the decorator approach much better. Thanks. Attached is a new
patch with that update.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1172711
New submission from Meador Inge mead...@gmail.com:
In 2.x, 'python -m tokenize' worked great:
[meadori@motherbrain cpython]$ python2.7 -m tokenize test.py
1,0-1,5:NAME'print'
1,6-1,21: STRING 'Hello, World!'
1,21-1,22: NEWLINE '\n'
2,0-2,0:ENDMARKER
Changes by Meador Inge mead...@gmail.com:
--
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12927
___
___
Python-bugs-list
Meador Inge mead...@gmail.com added the comment:
That syntax error is coming from the CPython parser and *not* the tokenizer.
Both CPython and the 'tokenizer' modules produce the same tokenization:
[meadori@motherbrain cpython]$ cat repro.py
if 1:
\
pass
[meadori@motherbrain cpython
Meador Inge mead...@gmail.com added the comment:
It would be nice if this same C API was used to implement the 'tokenize'
module. Issues like issue2180 will potentially require bug fixes in two places
:-/
--
nosy: +meadori
___
Python tracker rep
Meador Inge mead...@gmail.com added the comment:
Vlad, I agree that having both 'c_char_p' and 'POINTER(c_char)' will just be
more work for two seemingly identical constructs. I don't fully understand why
both would be needed either (or the implications of removing one of them or
making them
Meador Inge mead...@gmail.com added the comment:
Is this work something that might be suitable for the features/pep-3118 repo
(http://hg.python.org/features/pep-3118/) ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3132
Meador Inge mead...@gmail.com added the comment:
Attached is a first cut at a patch.
--
keywords: +patch
stage: needs patch - patch review
Added file: http://bugs.python.org/file23099/issue9969.patch
___
Python tracker rep...@bugs.python.org
http
Meador Inge mead...@gmail.com added the comment:
Here is a refresh of this patch for 3.3. Please review.
--
Added file: http://bugs.python.org/file23100/issue-1172711.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Meador Inge mead...@gmail.com added the comment:
Here is a patch that replaces the 'alloca' call with 'PyMem_Malloc'.
--
keywords: +patch
stage: needs patch - patch review
Added file: http://bugs.python.org/file23094/issue12881.patch
___
Python
401 - 500 of 625 matches
Mail list logo
