whiteknight/io_cleanup1 branch ready for testing

Moritz Lenz moritz at faui2k3.org
Tue Jun 26 02:21:49 UTC 2012


Rakudo spectest on this branch has failures in two test files:

Test Summary Report
-------------------
t/spec/S16-filehandles/io.rakudo                        (Wstat: 0 Tests:
84 Failed: 2)
  Failed tests:  80-81
t/spec/S32-io/IO-Socket-INET.t                          (Wstat: 0 Tests:
17 Failed: 13)
  Failed tests:  3-10, 13-17
Files=682, Tests=24684, 649 wallclock secs ( 5.86 usr  3.23 sys +
1999.22 cusr 213.08 csys = 2221.39 CPU)
Result: FAIL


$ ./perl6 -Ilib t/spec/S16-filehandles/io.rakudo
...
ok 79 - The object is-a 'IO'
not ok 80 - three bytes were read
#      got: '4'
# expected: '3'
not ok 81 - the bytes decode into the right Str
#      got: 'fööÄ'
# expected: 'föö'
ok 82 - can read lines without explicitly opening IO


$ ./perl6 -Ilib t/spec/S32-io/IO-Socket-INET.t
1..17
# Testing on port 1024
ok 1 - echo server and client
ok 2 - discard server and client
not ok 3 - received first 7 characters
#      got: 'Invalid character in ASCII string'
# expected: '0123456'
not ok 4 - received next 3 characters
#      got: '  in method recv at src/gen/CORE.setting:7452'
# expected: '789'
not ok 5 - remaining 26 were buffered
#      got: '  in block <anon> at t/spec/S32-io/IO-Socket-INET.pl:99'
# expected: 'abcdefghijklmnopqrstuvwxyz'
not ok 6 - received 뻯
#      got: '  in block <anon> at t/spec/S32-io/IO-Socket-INET.pl:82'
# expected: '뻯'
not ok 7 - ... which is 3 bytes
#      got: ''
# expected: '3'
not ok 8 - received 2 bytes of a 3 byte unicode character
#      got: ''
# expected: '2'
not ok 9 - combined the bytes form 몾
#      got: ''
# expected: '몾'
not ok 10 - ... which is 3 bytes
#      got: ''
# expected: '3'
ok 11 - get() with default separator
ok 12 - default separator
not ok 13 - \r\n separator
# '    got: 'All mimsy were the borogoves,
# expected: 'All mimsy were the borogoves,'
not ok 14 - . as a separator
#      got: ''
# expected: 'And the mome raths outgrabe'
not ok 15 - ! separator not at end of string
#      got: 'And the mome raths outgrabe'
# expected: 'O frabjous day'
not ok 16 - Multiple separators not at end of string
#      got: 'O frabjous day'
# expected: ' Callooh'
not ok 17 - ! separator at end of string
#      got: ' Callooh'
# expected: ' Callay'
# Looks like you failed 13 tests of 17


On 06/24/2012 06:29 PM, Andrew Whitworth wrote:
> 1) Calling FileHandle.read(x) will read up to x characters in the
> current encoding. In the old behavior, FileHandle.read(x) will read x
> bytes, attempting to round up to the nearest complete multibyte
> codepoint. This semantic is changed for all handle types (Socket,
> StringHandle) as well. To read a specific number of bytes, reading
> into a ByteBuffer still does the correct thing.

That makes a lot of sense, and seems to cause the failures in the first
test file.


> 2) StringHandle.read(0) used to be an odd synonym for
> StringHandle.readall(). Now this does what other handle types do: Read
> 0 characters.
> 3) You can now use both read and write buffers with Sockets. Buffers
> are not attached to Sockets by default.  Sockets now work correctly
> with non-ascii encodings for all operations.

But it could it be that some default in the socket code is now ASCII
which used to be something else?

> 4) StringHandle keeps better track of encodings. If you set a
> StringHandle to use a particular encoding, strings read from that
> StringHandle will now be in that encoding (previously, the string you
> read out might be the encoding it was written as, not the encoding set
> on the StringHandle).


In general I'm rather happy with these changes, I'll just have to
investigate the Socket-related spectest errors a bit, and think a bit
about whether to fix Rakudo's code or the tests in the case of
FileHandle.read(x).

Moritz





More information about the parrot-dev mailing list