As part of our discussion as to whether the threads branch is ready to
be merged into master, we have had to focus considerable attention on
t/pmc/filehandle.t.
Two tests in this file are TODO-ed. The reason for the first is
self-documented:
# GH #535 pir_output_is( <<'CODE', <<'OUT', 'print, read, and readline -
asynchronous', todo => 'not yet implemented' );
However, the second test, #28, is in TODO-ed status because we cannot
get it to PASS on all the platforms on which we habitually test.
pir_output_is( <<"CODE", <<'OUT', 'write after buffered read', todo =>
'GH #811 Write error: No space left on device on swap fs' );
I think we should note, however, that it is not simply the case that
this test fails on older or more obscure operating systems. It fails in
very elementary cases on our lead developers' favorite OS/platform:
Linux/i386.
If I build Parrot on this platform -- as I have been doing for six years
-- with an "all-gcc" build -- using gcc for 'cc', 'link' and 'ld' --
t/pmc/filehandle.t #28 fails, meaning that the file as a whole PASSes
only because of the TODO.
not ok 28 - write after buffered read # TODO GH #811 Write error: No
space left on device on swap fs
# Failed (TODO) test 'write after buffered read'
# at t/pmc/filehandle.t line 929.
# got: '10
# abcdefghij
# '
# expected: '10
# abcde#####klmno
# '
ok 29 - small reads and seeks
ok 30 - partial multibyte char in buffer
ok 31 - .write_bytes
ok 32 - .read_bytes
ok
All tests successful.
Files=1, Tests=32, 2 wallclock secs ( 0.03 usr 0.01 sys + 0.82 cusr
0.32 csys = 1.18 CPU)
Result: PASS
But when I test with "all-g++ build -- using g++ for 'cc', 'link' and
'ld' -- t/pmc/filehandle.t #28 passes, meaning that the test harness
reports an unexpected PASS.
ok 28 - write after buffered read # TODO GH #811 Write error: No space
left on device on swap fs
...
t/pmc/filehandle.t (Wstat: 0 Tests: 32 Failed: 0)
TODO passed: 28
(These results were run at commit 5709835825; Sept 02 2012. But I've
submitted dozens of smolders with the same results in recent months.)
In my experience, it's really rare that we get consistently different
test results between all-gcc and all-g++ builds on our most heavily
tested platform.
Any thoughts as to the cause of this discrepancy?
Thank you very much.
Jim Keenan
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
