to guess /which/ line the spawned thread is in at the time
sys._current_frames() is called: we know it finished
enter_g.set(), but can't know whether the instruction
counter has advanced to the following leave_g.wait().
The latter is overwhelming most likely, but not guaranteed,
and I see that the "x86 Ubuntu dapper (icc) trunk" buildbot
found it on the other line once. Changed the test so it
passes in either case.
that a 2.93 sec audio file will always take 3.1 sec (as it did on the
hardware I had when I first wrote the test), expect that it will take
2.93 sec +/- 10%, and only fail if it's outside of that range.
Compute the expected
points out there are really two types of continued headers defined in this
RFC (i.e. "encoded" parameters with the form "name*0*=" and unencoded
parameters with the form "name*0="), but we were were handling them both the
same way and that isn't correct.
This patch should be much more RFC compliant in that only encoded params are
%-decoded and the charset/language information is only extract if there are
any encoded params in the segments. If there are no encoded params then the
RFC says that there will be no charset/language parts.
Note however that this will change the return value for Message.get_param() in
some cases. For example, whereas before if you had all unencoded param
continuations you would have still gotten a 3-tuple back from this method
(with charset and language == None), you will now get just a string. I don't
believe this is a backward incompatible change though because the
documentation for this method already indicates that either return value is
possible and that you must do an isinstance(val, tuple) check to discriminate
between the two. (Yeah that API kind of sucks but we can't change /that/
without breaking code.)
Test cases, some documentation updates, and a NEWS item accompany this patch.
Moved the code for _PyThread_CurrentFrames() up, so it's no longer
in a huge "#ifdef WITH_THREAD" block (I didn't realize it /was/ in
one).
Changed test_sys's test_current_frames() so it passes with or without
thread supported compiled in.
Note that test_sys fails when Python is compiled without threads,
but for an unrelated reason (the old test_exit() fails with an
indirect ImportError on the `thread` module). There are also
other unrelated compilation failures without threads, in extension
modules (like ctypes); at least the core compiles again.
Do we really support --without-threads? If so, there are several
problems remaining.
of values in the time tuple passed in. Unfortunately people came to rely on
undocumented behaviour of setting unneeded values to 0, regardless of if it was
within the valid range. Now those values force the value internally to the
minimum value when 0 is passed in.
Specifically, instead of raising a ValueError when there is a single tick in
the parameter, simply return that the entire string unquoted, with None for
both the charset and the language. Also, if there are more than 2 ticks in
the parameter, interpret the first three parts as the standard RFC 2231 parts,
then the rest of the parts as the encoded string.
Test cases added.
Original fewer-than-3-parts fix by Tokio Kikuchi.
Resolves SF bug # 1218081. I will back port the fix and tests to Python 2.4
(email 3.0) and Python 2.3 (email 2.5).
Also, bump the version number to email 4.0.1, removing the 'alpha' moniker.
1. 'as' highlighted as builtin in comment string on import line
2. Comments such as "#False identity" which start with a keyword immediately
after the '#' character aren't colored as comments.
3. u or U beginning unicode string not correctly highlighted
Closes bug 1325071
already verified in .frombuf() on the lines above. If there was
a problem an exception is raised, so there was no way this condition
could have been true.
The hppa ubuntu box sometimes hangs forever in these tests. My guess
is that the wait is failing for some reason. Use WNOHANG, so we won't
wait until the buildbot kills the test suite.
I haven't been able to reproduce the failure, so I'm not sure if
this will help or not. Hopefully, this change will cause the test
to fail, rather than hang. That will be better since we will get
the rest of the test results. It may also help us debug the real problem.
*** The reason this originally failed was because there were many
zombie children outstanding before rev 47158 cleaned them up.
There are still hangs in test_subprocess that need to be addressed,
but that will take more work. This should close some holes.
Add a new function uses_seh() to the _ctypes extension module. This
will return True if Windows Structured Exception handling (SEH) is
used when calling functions, False otherwise.
str() or repr()) would work, just not multi-value tuples. Probably not a
backport candidate, since it changes the behaviour of passing a
single-element tuple:
>>> string.Template("$foo").substitute(dict(foo=(1,)))
'(1,)'
versus
'1'
will return True if Windows Structured Exception handling (SEH) is
used when calling functions, False otherwise.
Currently, only MSVC supports SEH.
Fix the test so that it doesn't crash when run with MingW compiled
_ctypes. Note that two tests are still failing when mingw is used, I
suspect structure layout differences and function calling conventions
between MSVC and MingW.
handler would cause a segfault. This merges in Expat's lib/xmlparse.c
revisions 1.154 and 1.155, which fix this and a closely related problem
(the later does not affect Python).
Moved the crasher test to the tests for xml.parsers.expat.
be called at the end of each test that spawns children (perhaps it
should be called from regrtest instead?). This will hopefully prevent
some of the unexplained failures in the buildbots (hppa and alpha)
during tests that spawn children. The problems were not reproducible.
There were many zombies that remained at the end of several tests.
In the worst case, this shouldn't cause any more problems,
though it may not help either. Time will tell.
(modified patch by Sam Ruby; changed to use separate REs for start and end
tags to reduce matching cost for end tags; extended tests; updated to avoid
breaking previous changes to support IPv6 addresses in unquoted attribute
values)
consistent with os.wait() returning immediately because some other
subprocess had previously exited; the test suite then immediately
tries to lock the mailbox and gets an error saying it's already
locked.
To fix this, do a waitpid() so the test suite only continues once
the intended child process has exited.
remove the flock() calls.
On FreeBSD, the two methods lockf() and flock() end up using the same
mechanism and the second one fails. A Linux man page claims that the
two methods are orthogonal (so locks acquired one way don't interact
with locks acquired the other way) but that clearly must be false.
Without this patch IDLE will get unresponsive when you open the debugger
window on OSX. This is both using the system Tcl/Tk on Tiger as the latest
universal download from tk-components.sf.net.
('[' and ']' were not accepted in unquoted attribute values)
- cleaned up tests of character and entity reference decoding so the
tests cover the documented relationships among handle_charref,
handle_entityref, convert_charref, convert_codepoint, and
convert_entityref, without bringing up Unicode issues that sgmllib
cannot be involved in
both a subclass of Warning and a subclass of types.ClassType. The latter is no
longer true thanks to new-style exceptions.
Closes bug #1510580. Thanks to AMK for the test.
The problem of checking too eagerly for recursive calls is the
following: if a RuntimeError is caused by recursion, and if code needs
to normalize it immediately (as in the 2nd test), then
PyErr_NormalizeException() needs a call to the RuntimeError class to
instantiate it, and this hits the recursion limit again... causing
PyErr_NormalizeException() to never finish.
Moved this particular recursion check to slot_tp_call(), which is not
involved in instantiating built-in exceptions.
Backport candidate.
constructor, meaning it is treated as *args, not as a single argument. This
means using the 'message' attribute won't work (until Py3K comes around),
and so one must grab from 'arg' to get the error number.
os.environ (setting envar COLUMNS), which at least caused
test_float_default() to fail if the tests were run more than once.
This repairs the test_optparse -R failures Neal reported on
python-dev. It also explains some seemingly bizarre test_optparse
failures we saw a couple weeks ago on the buildbots, when
test_optparse failed due to test_file failing to clean up after
itself, and then test_optparse failed in an entirely different
way when regrtest's -w option ran test_optparse a second time.
It's now obvious that make_parser() permanently changing os.environ
was responsible for the second half of that.
is that the wait is failing for some reason. Use WNOHANG, so we won't
wait until the buildbot kills the test suite.
I haven't been able to reproduce the failure, so I'm not sure if
this will help or not. Hopefully, this change will cause the test
to fail, rather than hang. That will be better since we will get
the rest of the test results. It may also help us debug the real problem.
issues that crop up from time to time, but this change seems to have been
pretty stable (no spurious warnings) for about a week.
Other modules which use threads may require similar use of
threading_setup/threading_cleanup from test_support.
of this test. It probably still requires more disk space
than most buildbots have, and in any case is still so
intrusive that if we don't find another way to test this I'm
taking my buildbot offline permanently ;-)
This will hopefully get the buildbots to pass. Not sure this
test will be feasible or even work. But everything is red now,
so it can't get much worse.
now works reliably. It has been updated to use automatic BerkeleyDB
deadlock detection and the bsddb.dbutils.DeadlockWrap wrapper to retry
database calls that would previously deadlock. [SF python bug #775414]
until Gerhard has time to fully debug the issue. This affects versions
before 3.2.1 (possibly only versions earlier than 3.1.3).
Based on discussion on python-checkins.
This backs out the test changes in 46962 which prevented crashes
by not running the tests via a version check. All the version checks
added in that rev were removed from the tests.
Code was added to the error handler in connection.c that seems
to work with older versions of sqlite including 3.1.3.
SQLite versions.
- Added version checks in test suite so that we don't execute tests that we
know will fail with older (buggy) SQLite versions.
Now, all tests should run against all SQLite versions from 3.0.8 until 3.3.6
(latest one now). The sqlite3 module can be built against all these SQLite
versions and the sqlite3 module does its best to not trigger bugs in SQLite,
but using SQLite 3.3.3 or later is recommended.
adjacent triples in the result list describe non-adjacent matching
blocks. That's _nice_ to have, and Guido said he wanted it.
Not a bugfix candidate: Guido or not ;-), this changes visible
endcase semantics (note that some tests had to change), and
nothing about this was documented before. Since it was working
as designed, and behavior was consistent with the docs, it wasn't
"a bug".
arguments in reverse, the interpreter would infinitely recourse trying to get a
coercion that worked. So put in a recursion check after a coercion is made and
the next call to attempt to use the coerced values.
Fixes bug #992017 and closes crashers/coerce.py .
Heavily revised, comprising revisions:
46640 - original trunk revision (backed out in r46655)
46647 - markup fix (backed out in r46655)
46692:46918 merged from branch aimacintyre-sf1454481
branch tested on buildbots (Windows buildbots had problems
not related to these changes).
more comments about why it's this way at all; and removed what looked
like needless expense (sorting (i, j, k) triples directly should give
exactly the same order as sorting (i, (i, j, k)) pairs).
when running with -O.
test_simple_validation_error still fails under -O. That appears to be because
wsgiref's validate.py uses `assert` statements all over the place to check
arguments for sanity. That should all be changed (it's not a logical error
in the software if a user passes bogus arguments, so this isn't a reasonable
use for `assert` -- checking external preconditions should generally raise
ValueError or TypeError instead, as appropriate).
a search path setup, some of these hosts resolve to the wrong address.
By appending a period to the hostname, the hostname should only resolve
to what we want it to resolve to. Hopefully this doesn't break different bots.
Also add more info to failure message to aid debugging test failure.
a search path setup, some of these hosts resolve to the wrong address.
By appending a period to the hostname, the hostname should only resolve
to what we want it to resolve to. Hopefully this doesn't break different bots.
Tim Peters
Greg Ward
Georg Brandl
Kurt B. Kaiser
Martin v. Löwis
Andrew MacIntyre
Ronald Oussoren
Neal Norwitz
Barry Warsaw
Vinay Sajip
Phillip J. Eby
Facundo Batista
Brett Cannon
Bob Ippolito
Thomas Heller
Peter Astrand
Anthony Baxter
Neil Schemenauer
Hye-Shik Chang
Nick Coghlan
Fredrik Lundh
Armin Rigo
Thomas Wouters
Gerhard Häring
Fred Drake
Andrew M. Kuchling
Ka-Ping Yee
Walter Dörwald
Gregory P. Smith