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
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:
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:
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:
>>>> 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:
> 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
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:
> 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__
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:
> 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:
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:
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:
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:
> 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:
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:
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:
> 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
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:
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
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:
+1; the keyword arg version is much more readable.
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13
Changes by Meador Inge :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue11816>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13008>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.org/
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
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:
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:
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:
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:
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 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 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:
> 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:
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
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:
> 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 :
--
resolution: -> fixed
stage: test needed -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
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 :
--
components: +Library (Lib)
stage: -> needs patch
versions: +Python 3.3
___
Python tracker
<http://bugs.python.org/issue13062>
___
_
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13062>
___
___
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/issue13089>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
components: +ctypes
nosy: +amaury.forgeotdarc, belopolsky, meador.inge
___
Python tracker
<http://bugs.python.org/issue13091>
___
___
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
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:
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:
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
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. Opened issue13096 and issue13097 for the other crashers.
--
resolution: -> fixed
stage: commit review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
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:
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:
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:
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:
> 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:
Found a few test case nits. Comments in rietveld.
--
___
Python tracker
<http://bugs.python.org/issue3163>
___
___
Python-bug
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:
Éric, thanks. I fixed most of your points. And thanks to everyone that
reviewed this. Much appreciated.
--
___
Python tracker
<http://bugs.python.org/issue12
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:
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
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
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:
Yup, it is the 'alloca' call. This issue and issue13097 are both
'alloca' related as mentioned in issue12881.
--
___
Python tracker
<http://bug
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:
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:
> 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
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13187>
___
___
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/issue13183>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue13217>
___
___
Python-bugs-list mai
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
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:
Committed. Thanks!
--
nosy: -python-dev
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
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:
> 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
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
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:
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&#
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:
>> P.S. We could probably get rid of the HAVE macro all together by doing
>> all the work in the 'configure' script.
> Would that be a breach of backward compatibility for sysconfig?
Yeah, I think so. Be
Meador Inge added the comment:
I think it might be easier to just always use the absolute path rather than
looking at the directory length. Maybe something like the attached. I added
unit tests as well.
--
nosy: +meador.inge
stage: test needed -> patch review
Added file: h
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13272>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13266>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13253>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13298>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue10977>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13328>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
I agree this is a regression. I am looking more into it now.
--
stage: -> needs patch
___
Python tracker
<http://bugs.python.org/issu
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13370>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
Hmmm... I take back what I said before (not sure what I was thinking), I
don't think this is a regression. If this ever did work, it must have
been a bug. For one reason, Python byte strings are now immutable.
Allowing their memory to be indirectly mu
New submission from Meador Inge :
Currently it is possible to somewhat easily get false positives for reference
leaks when running the ctypes regression tests with -R. See issue13250 for an
example where I got tripped up. The reason is that the ctypes caches are not
cleared in between test
Meador Inge added the comment:
I opened issue13380 for fixing the ctypes regrtest caching problem.
--
___
Python tracker
<http://bugs.python.org/issue13
Meador Inge added the comment:
> - you duplicated the part with "CFUNCTYPE(c_int)(lambda: None)" without
> removing the original chunk of code
> - some platforms can't compile ctypes, you must handle that case in
> regrtest
Both fixed. Thanks for the rev
Changes by Meador Inge :
--
nosy: +meador.inge
___
Python tracker
<http://bugs.python.org/issue13411>
___
___
Python-bugs-list mailing list
Unsubscribe:
Meador Inge added the comment:
Éric, sure, I will commit the tests sometime today. Then I will respond to the
'os.path.abspath' question as well.
--
___
Python tracker
<http://bugs.python.o
Meador Inge added the comment:
Committed. Thanks for the review Antoine.
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Meador Inge added the comment:
On Sat, Nov 26, 2011 at 7:17 AM, Antoine Pitrou wrote:
> The tests break on the Windows buildbots:
I am investigating now.
--
___
Python tracker
<http://bugs.python.org/issu
Meador Inge added the comment:
The tests are fixed now. A relative path was being computed, but on Windows
the current working directory drive and the drive of the relative path we were
computing was different (and so this test bug would *not* be seen if running on
a Windows box with a
Meador Inge added the comment:
> we don’t know what people do with symlinks and relative paths out
> there, so I’d prefer adding a safe special case* rather than always
> calling abspath. What do you think?
Éric, I agree. I didn't know about the strange symlink + relative
1 - 100 of 629 matches
Mail list logo
