Nadeem Vawda added the comment:
Looking at Lib/test/test_zlib.py, it appears that this behaviour is intentional
(see issue8672). I agree that having flush() raise an exception is the Right
Thing, but breaking existing code (which we know depends on this behavior) is
clearly a bad idea. @pitrou
Nadeem Vawda added the comment:
Following d98b5e0f0862, I have been able to successfully build the curses
module with curses_unicode.patch applied.
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12
Nadeem Vawda added the comment:
Ack sorry, forgot to give context - my machine doesn't have libncursesw,
so the curses module failed to build before that commit (with or without
the patch applied).
--
___
Python tracker
<http://bugs.py
New submission from Nadeem Vawda :
When running regrtest with the -j and/or -w options, test_curses gets skipped,
complaining that stdout is not a tty. This means that the buildbots never run
this test, which is obviously a Bad Thing.
For the -w case (which applies to the buildbots), this is
Nadeem Vawda added the comment:
Correction: the offending options are -j and *-W* (display test output on
failure), not -w (re-run failed tests in verbose mode).
--
___
Python tracker
<http://bugs.python.org/issue12
Nadeem Vawda added the comment:
> I have attached a Python script which does what Antoine's patch does except
> which is expected to live in Tools/scripts. The perk of doing this in a
> Python script is that Windows users will be able to simply execute the script
> while th
Nadeem Vawda added the comment:
>> Some notes:
>> - By doing things this way, we lose the ability to specify custom arguments
>> to
>> the interpreter with $(TESTPYTHONOPTS). Might this be a problem?
>
> Yes, some buildbots use it. Can't you add support fo
Nadeem Vawda added the comment:
What changes do you suggest?
--
___
Python tracker
<http://bugs.python.org/issue11651>
___
___
Python-bugs-list mailing list
Unsub
Nadeem Vawda added the comment:
Updated patch attached.
>> Some notes:
>> - By doing things this way, we lose the ability to specify custom arguments
>> to
>> the interpreter with $(TESTPYTHONOPTS). Might this be a problem?
>
> Yes, some buildbots use it. Can&#
Changes by Nadeem Vawda :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
Relevant: http://mail.python.org/pipermail/python-dev/2011-July/112551.html
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12
Changes by Nadeem Vawda :
--
versions: +Python 3.2
___
Python tracker
<http://bugs.python.org/issue12692>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
> I have another proposition (as an alternative). The new _bz2.BZ2Decompressor
> objects have an attribute called eof which is False until the end of the
> stream is read. The same attribute could be added to zlib.Decompress objects.
+1, I like the idea
Nadeem Vawda added the comment:
Here's the patch.
--
Added file: http://bugs.python.org/file22846/zlib-eof
___
Python tracker
<http://bugs.python.org/is
Changes by Nadeem Vawda :
Added file: http://bugs.python.org/file22847/zlib-eof.patch
___
Python tracker
<http://bugs.python.org/issue12646>
___
___
Python-bugs-list m
Changes by Nadeem Vawda :
Removed file: http://bugs.python.org/file22846/zlib-eof
___
Python tracker
<http://bugs.python.org/issue12646>
___
___
Python-bugs-list mailin
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12707>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue12646>
___
___
Python-bugs-list mailing list
Unsubscri
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue10570>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
> Can't we create a dummy/temporary TTY for the curses tests using
> pty.openpty()?
I would have thought so, but it seems that savetty() and endwin() both fail when
running under '-j0':
test test_curses crashed -- Traceback (
Changes by Nadeem Vawda :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: behavior -> feature request
___
Python tracker
<http://bugs.python
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue11564>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
pickle64.patch applies cleanly to 3.2, but not 3.3. I've attached an
adapted version that applies cleanly to 3.3.
--
Added file: http://bugs.python.org/file22914/pickle64-3.3.patch
___
Python tracker
Nadeem Vawda added the comment:
I have tried running the tests on a machine with 12GB of RAM, but when I do so,
the new tests get skipped saying "not enough memory", even when I specify "-M
11G"
on the command-line. The problem seems to be the change to the
precisionbig
Nadeem Vawda added the comment:
> How much does it say is required?
> Did you remove the skips in BigmemPickleTests?
Yes, I did remove the skips. It says 2GB for some, and 4GB for others.
> Well, perhaps I got the logic wrong. Debugging welcome :)
I'd be glad to do so, but I&#
Nadeem Vawda added the comment:
D'oh. I just realized why the -M option wasn't being recognized - I had passed
it
after the actual test name, so it was being treated as another test instead of
an
option. Sorry for the confusion :/
As for the actual test results, test_huge_bytes_(32
Nadeem Vawda added the comment:
> Can you replace "_2G" with "_4G" in the decorator for that test?
I'm not at work any more, but I'll try that out on Monday.
--
___
Python tracker
&
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12795>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12797>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Are the failures because the machine you're running the test on doesn't
have internet access? Or are there problems with some of the tests?
The attached patch should solve the problem.
--
keywords: +patch
Added file: http://bugs.python.org
Changes by Nadeem Vawda :
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
> Looks like the patch is not enough:
> http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%203.2/builds/477/steps/test/logs/stdio/text
That's a 3.2 builder. You only committed Jeremy's fix to default. I've tested
the fix on 3.2 on
Nadeem Vawda added the comment:
With the patch applied, I still get failures in test_old_record_extensions
and test_record_basic, so it doesn't seem to work.
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/is
Nadeem Vawda added the comment:
The sdist failure is now fixed on the 3.2 XP builders.
test_record_extensions still needs attention, though.
I also tried backporting Jeremy's fix to 2.7, but that doesn't seem to
have worked; the sdist tests is still failing there. Someone who
actu
Nadeem Vawda added the comment:
> Can you replace "_2G" with "_4G" in the decorator for that test?
When I do that, it pushes the memory usage for the test up to 16GB, which is
beyond what the machine can handle. When I tried with 2.5G (_2G * 5 // 4),
that was enough
Nadeem Vawda added the comment:
> Uh, does it? With 4G it should raise OverflowError, and not try to do
> anything else.
> Could I ask you to try to take a look? :S
Sure; I'll see what I can figure out tomorrow.
> Running bigmem tests in parallel doesn't make much sense
Nadeem Vawda added the comment:
> These are unrelated, I’m only interested in test_database for this patch.
I see. I'll re-run the tests this evening, and see whether that failure
crops up.
--
___
Python tracker
<http://bugs.python.org
Nadeem Vawda added the comment:
> I’ll commit the tmp-debug patch so that we can get info from the buildbot,
> unless Jeremy or someone can investigate.
If you can wait until this evening (CEST), I'll run the tests with that
patch applied locally. It might be easier to get to th
Nadeem Vawda added the comment:
I was playing around with pickling large Unicode strings in an interactive
interpreter, and it seems that you have to have at least 4G chars (not bytes)
to trigger the OverflowError. Consider the following snippet of code:
out = dumps(data)
del data
Nadeem Vawda added the comment:
Some more info: the first few bytes of the output for the _2G case are this:
b'\x80\x03X\x00\x00\x00\x80aa'
--
___
Python tracker
<http://bugs.python.o
Nadeem Vawda added the comment:
> With data as (b"a" * _4G) the result is as expected:
>
> Traceback (most recent call last):
> File "pickle-bigmem-test.py", line 5, in
> out = dumps(data)
> OverflowError: cannot serialize a string la
Nadeem Vawda added the comment:
Testing on 3.2, the latest patch doesn't fix the test_record_extensions failure
:/
It does change the traceback for the exception, though.
Before:
==
ERROR: test_record_exten
Nadeem Vawda added the comment:
Testing on 3.2, the latest patch doesn't fix the test_record_extensions failure
:/
It does change the traceback for the exception, though.
Before:
==
ERROR: test_record_exten
Changes by Nadeem Vawda :
--
Removed message: http://bugs.python.org/msg142863
___
Python tracker
<http://bugs.python.org/issue12678>
___
___
Python-bugs-list m
Nadeem Vawda added the comment:
Thanks for the bug report and patch. I'll take a look at it over the weekend.
--
assignee: -> nadeem.vawda
components: +Extension Modules -None
nosy: +nadeem.vawda
___
Python tracker
<http://bugs
Nadeem Vawda added the comment:
Reproduced on 3.3 head. Looking at the documentation of the C readline
library, it needs to know the length of the prompt in order to display
properly, so this seems to be an acknowledged limitation of the underlying
library rather than a bug on our side.
Still
Nadeem Vawda added the comment:
Done. Once again, thanks for the report and the patch!
--
resolution: -> fixed
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Nadeem Vawda :
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12850>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Tested the latest patch with -M11G. All tests pass.
--
___
Python tracker
<http://bugs.python.org/issue11564>
___
___
Python-bug
Changes by Nadeem Vawda :
--
hgrepos: +64
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
Added file: http://bugs.python.org/file23063/f3cf187208ea.diff
___
Python tracker
<http://bugs.python.org/issue6715>
___
___
Python-bugs-list m
Nadeem Vawda added the comment:
Attached is a patch (f3cf187208ea.diff) containing my work so far on
reimplementing the lzma module. So far I've just done the LZMACompressor
and LZMADecompressor classes, but I'm hoping to implement LZMAFile th
Nadeem Vawda added the comment:
I've tested the attached patch against 3.3 on Windows XP, and it seems to
fix the test_database failures. There were some merge conflicts when I
applied the patch (because some of the docstring and comment changes had
already been committed in fixes fro
Nadeem Vawda added the comment:
I haven't been able to reproduce this on Linux (2.6.38; Ubuntu 11.04).
Some searching around seems to suggest that OpenBSD doesn't provide
those functions (or didn't until recently). Modules/posixmodule.c and
configure.in seem to assume that thes
Nadeem Vawda added the comment:
This is expected behaviour - you cannot seek on a pipe.
--
nosy: +nadeem.vawda
___
Python tracker
<http://bugs.python.org/issue12
Changes by Nadeem Vawda :
--
resolution: -> invalid
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
New submission from Nadeem Vawda :
The C functions for converting a Python 'int' object to a C integer are
inconsistent about what exception gets raised when the object passed to
them is not an integer. Most of these functions raise a TypeError, but
PyLong_AsUnsignedLong
Nadeem Vawda added the comment:
> Do you have a patch handy?
See attached.
--
keywords: +patch
Added file: http://bugs.python.org/file23106/pylong-exceptions.diff
___
Python tracker
<http://bugs.python.org/issu
Nadeem Vawda added the comment:
This probably shouldn't be backported to 3.2; it could break 3rd-party
extension modules (though I would hope that nothing depends on this
behaviour...).
Also, it's worth noting that the error handling between conversion
functions still isn&#x
Nadeem Vawda added the comment:
Attached is an updated patch with tests.
There don't seem to be any tests for PyLong_AsS[s]ize_t() and
PyLong_AsDouble(), so I added new ones for this issue. They should still
be expanded on at some point in the future, but for the meanwhile this
shou
Nadeem Vawda added the comment:
> The 'Py_None' reference counting in test_long_as_size and
> test_long_as_double looked a little odd at first glance
Indeed, it is rather roundabout, so I added a comment to avoid confusion.
> Anyway, those are just nitpicks; I leave it
Changes by Nadeem Vawda :
--
resolution: -> fixed
stage: patch review -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.or
Nadeem Vawda added the comment:
> In uint32_converter, I'm not sure the if statement comparing val and
> UINT32_MAX makes sense. val was defined to be unsigned long, which is
> 32bit on 32-bit compiler.
Yes, on a 32-bit system, this comparison will always be false. However,
on a
New submission from Nadeem Vawda :
zlib.crc32() and zlib.adler32() in Modules/zlibmodule.c don't handle buffers of
>=4GB correctly. The length of a Py_buffer is of type Py_ssize_t, while the C
zlib functions take length as an unsigned integer. This means that on a 64-bit
build, th
Nadeem Vawda added the comment:
test_source_address_passive_connection() raises a ResourceWarning. Fix attached.
--
nosy: +nvawda
Added file: http://bugs.python.org/file21019/test_ftplib-leak.diff
___
Python tracker
<http://bugs.python.
Nadeem Vawda added the comment:
I'm not seeing the commit anywhere. Did you perhaps forget to "hg push" after
committing?
--
___
Python tracker
<http://bugs.py
Nadeem Vawda added the comment:
I don't seem to be able to reproduce the failure in test_platform.
Nevertheless, the behaviour is broken. Here's a patch that should fix it
without allocating too much extra space.
--
keywords: +patch
nosy: +nvawda
Added file: http://bugs.
Nadeem Vawda added the comment:
Ah, now I see - the code that fails isn't test_platform, it's the regrtest code
that prints out the version info at the beginning of the test results. This
doesn't get displayed when you explicitly tell regrtest what tests to run
("./
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue11457>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue11454>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue11244>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Thanks for the review. I'll try and have an updated patch ready by next weekend.
Regarding your comments:
> Is there any reason it doesn't inherit io.BufferedIOBase?
No, there isn't; I'll fix that in my revised patch.
> Since this
Nadeem Vawda added the comment:
> Would it be possible to add an open() function to the bz2 module?
Yes, it would be quite trivial, though I don't think it would be worthwhile -
all it would do is provide a direct alias for the BZ2File constructor. But as
Antoine said, that is a top
Nadeem Vawda added the comment:
> Well, I would personally advocate not re-adding a license boilerplate,
> since it doesn't serve a purpose (nearly all of Python is freely usable
> under the PSF License, and the authors are documented by version control).
That sounds sensible t
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue11550>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
issue10883 is related; test_urllib2net also leaves sockets open in several
places.
--
nosy: +haypo, nvawda
___
Python tracker
<http://bugs.python.org/issue11
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue11549>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue10050>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
urlopen_HttpTests.test_willclose() fails to call unfakehttp(), which breaks
subsequent runs of test_urllib2_localnet, test_urllib2net and test_urllibnet.
Fix attached.
--
Added file: http://bugs.python.org/file21292/unfakehttp.diff
Nadeem Vawda added the comment:
Would it be possible to commit this partial fix now? It gets rid of 4 of the 8
warnings that I am currently seeing in test_urllib2net.
(As an aside, for anyone reading this who hasn't seen issue11563,
test_urllibnet is now warning
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue11608>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
The first ResourceWarning looks like the test_cgi leak from issue10512, which
was fixed in changeset ae186b3b2c55.
--
nosy: +nvawda
status: pending -> open
___
Python tracker
<http://bugs.python.org/issu
Nadeem Vawda added the comment:
Sorry about accidentally changing the issue status to "open". It seems that I
don't have the requisite privileges to change it back to "pending"...
--
___
Python tracker
<http:
Nadeem Vawda added the comment:
Here is an updated patch, incorporating the feedback from your review.
The new patch no longer checks for errors in bz2CompressEnd()/bz2DecompressEnd()
in the dealloc functions for BZ2Compressor/BZ2Decompressor. I found that calling
PyErr_WriteUnraisable
Nadeem Vawda added the comment:
Corresponding patch for the module docs.
--
Added file: http://bugs.python.org/file21315/bz2-v4-doc.diff
___
Python tracker
<http://bugs.python.org/issue5
Nadeem Vawda added the comment:
> I saw the partial fix suggested by the patch, but for some reason I
> did not see ResourceWarning being shutup.
Do you mean that you aren't getting ResourceWarnings in the first place?
Or that you are getting warnings, and the partial fix isn'
Nadeem Vawda added the comment:
>From the discussion on python-dev, it seems that I will need to submit a
Contributor Agreement to the PSF. Can I ask that you not commit this
patch until the CA has been submitted? I will need to clear it with my
employer, and it might complicate things if
Nadeem Vawda added the comment:
>- when "-j0" is passed to regrtest, use the cpu count detected by
>multiprocessing
>- remove the duplicate test in "make test"
>- add "-j0" to the test options in make test
+1. The duplicate test seems quite wasteful
Nadeem Vawda added the comment:
Looking at the actual times with -j0, I don't think there is any need to
keep quicktest - with the removal of the duplicate test, I can do a full
run in 3m16s (on a debug build; non-debug takes 1m54s), which seems plenty
fast enough.
One thing I noticed
Nadeem Vawda added the comment:
Looks good to me.
> [...] but I couldn't find any patches that fix this specific issue.
Well, test_select_unbuffered() was only introduced a few days ago (changeset
cb148da52c47), so I'm not surprised :)
--
Nadeem Vawda added the comment:
> For what its worth, an strace of Java's Process class appears to "cheat" by
> opening /proc/self/fd inbetween fork & exec.
Looking at the OpenJDK source confirms this:
http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/tip/src
New submission from Nadeem Vawda :
When running regrtest on a non-Windows platform, I get a warning that
test_msilib was skipped unexpectedly. The attached patch modifies regrtest to
indicate that this is expected.
--
components: Tests
files: test_msilib-expected.diff
keywords: patch
Nadeem Vawda added the comment:
> Apparently the PSF has received your contributor agreement.
Great; I was just about to send them an email to check.
> Does it mean the situation is cleared? I plan to do a review of your latest
> patch.
Yes, everything's sorted
Changes by Nadeem Vawda :
--
nosy: +nvawda
___
Python tracker
<http://bugs.python.org/issue10791>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nadeem Vawda added the comment:
Here is an updated patch that adds read1() to BZ2File. This should fix things
for issue10791 from the bz2 side. I also took the opportunity to clean up
_read_block() to be more readable. As per Martin's suggestion on python-dev, I
put the copyright notice i
Nadeem Vawda added the comment:
Updated documentation.
--
Added file: http://bugs.python.org/file21503/bz2-v5-doc.diff
___
Python tracker
<http://bugs.python.org/issue5
Nadeem Vawda added the comment:
Thanks for the review. I've made most of the changes you suggested, but there's
one thing I wanted to check about:
> - instead of "int(size)", use "size = size.__index__()" so as to forbid floats
The tests for readline() and
Nadeem Vawda added the comment:
Here's the updated patch.
--
Added file: http://bugs.python.org/file21507/bz2-v6.diff
___
Python tracker
<http://bugs.python.org/i
Nadeem Vawda added the comment:
... and the corresponding updated documentation patch.
--
Added file: http://bugs.python.org/file21508/bz2-v6-doc.diff
___
Python tracker
<http://bugs.python.org/issue5
Nadeem Vawda added the comment:
> Is following change in GzipFile class enough:
>
> def read1(self, n):
> return self.read(n)
>
> ? This satisfies TextIOWrapper to run readline correctly.
Looks good to me.
By the way, BZ2File now works correctly - the fix
101 - 200 of 535 matches
Mail list logo
