Meador Inge added the comment:
Nick, the revised definition of 'getclosurevars' seems reasonable to me.
I will cut a new patch this week.
--
___
Python tracker
<http://bugs.python.o
Meador Inge 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&#
New submission from Meador Inge :
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 : t
Meador Inge 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. To be clea
Meador Inge added the comment:
> Actually, I think sysconfig does the right thing when it comes to all
> the configure-generated HAVE_XXX variables
I agree. The 'configure' script could be improved, though. If we truly
want to enable this by default, then the defaulting sh
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue12675>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
Committed. Thanks!
--
nosy: -python-dev
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Meador Inge 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 files. So
Meador Inge 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
Changes by Meador Inge :
--
nosy: +meador.inge
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue13217>
___
___
Python-bugs-list mai
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13183>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
stage: -> test needed
type: -> resource usage
versions: +Python 2.7, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/i
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13187>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge 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
<http://bugs.pytho
Meador Inge 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 the en
Meador Inge added the comment:
As mentioned in issue12881, this issue is a result of an unbounded 'alloca'
call that trashes the stack.
--
___
Python tracker
<http://bugs.python.o
Meador Inge added the comment:
Yup, it is the 'alloca' call. This issue and issue13097 are both
'alloca' related as mentioned in issue12881.
--
___
Python tracker
<http://bug
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue10399>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
On Sat, Oct 8, 2011 at 5:34 PM, Antoine Pitrou wrote:
> Antoine Pitrou added the comment:
>
>> Before going further with this, I'd suggest you have a look at your
>> compiler settings.
>
> They are set by the configure script:
&g
Meador Inge 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: +mea
Changes by Meador Inge :
--
assignee: docs@python -> meador.inge
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python
Meador Inge added the comment:
Éric, thanks. I fixed most of your points. And thanks to everyone that
reviewed this. Much appreciated.
--
___
Python tracker
<http://bugs.python.org/issue12
Meador Inge added the comment:
No problem. This last version LGTM.
--
___
Python tracker
<http://bugs.python.org/issue3163>
___
___
Python-bugs-list mailin
Meador Inge added the comment:
Found a few test case nits. Comments in rietveld.
--
___
Python tracker
<http://bugs.python.org/issue3163>
___
___
Python-bug
Meador Inge 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
<http://bugs.pytho
Meador Inge added the comment:
On Tue, Oct 4, 2011 at 10:21 AM, Vlad Riscutia 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 it to C
Meador Inge added the comment:
Mostly LGTM. I have a few comments in rietveld.
--
nosy: +meador.inge
stage: needs patch -> patch review
___
Python tracker
<http://bugs.python.org/iss
Meador Inge 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
<http://bugs.python.o
Meador Inge added the comment:
On Fri, Sep 30, 2011 at 12:19 PM, Vlad Riscutia 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 this feature incorrectly.
S
Meador Inge added the comment:
Fixed. Opened issue13096 and issue13097 for the other crashers.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Meador Inge :
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", "credi
Meador Inge 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 :
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", "credi
Meador Inge added the comment:
Fixed a few more nits pointed out in review.
--
Added file: http://bugs.python.org/file23304/issue12943-6.patch
___
Python tracker
<http://bugs.python.org/issue12
Meador Inge 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 ret
Meador Inge 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)))
Meador Inge 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
--suppressions=Misc
Changes by Meador Inge :
--
components: +ctypes
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
___
Python tracker
<http://bugs.python.org/issue13091>
___
___
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13089>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge 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 (simpl
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13062>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
components: +Library (Lib)
stage: -> needs patch
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue13062>
___
_
Changes by Meador Inge :
--
assignee: -> meador.inge
versions: +Python 2.7, Python 3.2
___
Python tracker
<http://bugs.python.org/issue12881>
___
___
Python-
Changes by Meador Inge :
--
resolution: -> fixed
stage: test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Meador Inge 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 will commit the re
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13044>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge 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
<http://bugs.py
Meador Inge 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
Meador Inge 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 tokenizi
Meador Inge 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:
*
Meador Inge 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 informat
Meador Inge 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_F
Meador Inge 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&#x
Meador Inge 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' fu
Meador Inge 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: +mead
Meador Inge 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 sh
Changes by Meador Inge :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13008>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bugs-list mailing list
Unsubscri
Meador Inge added the comment:
+1; the keyword arg version is much more readable.
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13
Meador Inge 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
<http://bu
Meador Inge 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
<http://bugs.python.org/issue12
Changes by Meador Inge :
--
nosy: +meador.inge
stage: test needed -> patch review
___
Python tracker
<http://bugs.python.org/issue1294232>
___
___
Python-
Meador Inge 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
<http://bugs.python.org/issu
Meador Inge 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
<http://bugs.python.org/issue12
Meador Inge 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
<http://bugs.python.org/issue13
Meador Inge 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 illust
Meador Inge 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':
&#
Meador Inge 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_
Meador Inge 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 test_struct
Meador Inge 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 *
&
Meador Inge added the comment:
Updated patch with the 'Py_ssize_t' fixes.
--
Added file: http://bugs.python.org/file23148/issue-1172711.patch
___
Python tracker
<http://bugs.python.org
Meador Inge 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__
New submission from Meador Inge :
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):
Meador Inge 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 for this
Meador Inge 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):
> ...
Meador Inge 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
___
Pytho
Meador Inge added the comment:
On Mon, Sep 12, 2011 at 7:10 AM, Mark Dickinson wrote:
> Mark Dickinson added the comment:
>
> I believe the problem is specific to machines still using the old ABI
> ('OABI'). Which ABI was being used on your test machine?
I tested t
Meador Inge 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
___
Pyt
Meador Inge 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
Changes by Meador Inge :
--
nosy: +meadori
___
Python tracker
<http://bugs.python.org/issue12936>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge 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
Meador Inge 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 added the comment:
Ping. Any thoughts on this one?
--
___
Python tracker
<http://bugs.python.org/issue12881>
___
___
Python-bugs-list mailin
Meador Inge 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 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-discuss: http
Meador Inge 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 t
Meador Inge added the comment:
Another example of desperately needed documentation: issue12945.
--
components: +ctypes
___
Python tracker
<http://bugs.python.org/issue12
Meador Inge 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.
Add
Meador Inge 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 &#x
Meador Inge 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
___
Python t
New submission from Meador Inge :
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
Meador Inge added the comment:
Victor, I like the decorator approach much better. Thanks. Attached is a new
patch with that update.
--
___
Python tracker
<http://bugs.python.org/issue1172
Changes by Meador Inge :
Added file: http://bugs.python.org/file23121/issue-1172711.patch
___
Python tracker
<http://bugs.python.org/issue1172711>
___
___
Python-bug
Meador Inge 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 trac
Meador Inge 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]
Changes by Meador Inge :
--
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issue12927>
___
___
Python-bugs-list mailing list
Unsubscri
Meador Inge 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
Meador Inge 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
<http://bugs.python.org/issue1172
Meador Inge 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
<http://bugs.python.org/iss
401 - 500 of 629 matches
Mail list logo
