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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
