[Martin]
> Well, it was atleast motivating enough to try it out on my Whistler
> installation. Purify would probably find this rather quickly; the code
> writes into the 257th element of a 256-elements array.
Ah! You shouldn't do that <wink>.
> I've committed a fix.
But you should do that. Thank you!
Here's where I am now:
=========================================================================
All test_sax failures have gone away (yay!).
=========================================================================
Running
rt -x test_sax
on Windows still blows up in test_extcall on the 2nd pass. It does not blow
up:
using the debug build; or
if test_sax is *not* excluded; or
in the 1st pass; or
when running text_extcall in isolation; or
if the steps rt performs are done by hand
=========================================================================
Running
rt -r
on Windows still sees test_cpickle fail in the first pass (with truncated
output), but succeed in the second pass. First-pass failure is always like
so (modulo line breaks I'm inserting by hand):
test test_cpickle failed -- Tail of expected stdout unseen:
'dumps()\012
loads()\012
ok\012
loads() DATA\012
ok\012
dumps() binary\012
loads() binary\012
ok\012
loads() BINDATA\012
ok\012
dumps() RECURSIVE\012
ok\012'
I've also seen it fail at least once when doing the same thing by hand:
del ..\lib\*.pyc
del ..\lib\test\*.pyc
python ../lib/test/regrtest.py -r
else-i-would-have-asked-martin-to-look-for-a digit-to-change-in-
command.com<wink>-ly y'rs - tim
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4