whiteknight/io_cleanup1 branch ready for testing

Andrew Whitworth wknight8111 at gmail.com
Tue Jun 26 12:18:44 UTC 2012


Thanks for the report, Moritz! I haven't had time to run through the
rakudo spectest myself yet myself. These results are not entirely
unexpected and I have some ideas in mind about how to fix them (and,
more importantly, test them at the Parrot level so we don't regress
anymore).

The ultimate goal of this cleanup branch was to change around the IO
internals to be more sane without causing many changes at the user
level. Ideally, I would like to keep Rakudo and NQP working without
modification. Other disruptive changes (and I have several of those in
mind) can be saved for later branches. Unless Rakudo specifically
prefers the new semantics, I'll fix them to make sure Rakudo keeps
humming along without problems or changes. If we have to put in the
old read semantics, or put them back in and keep the newer semantics
as a separate method, I'll do that.

Thanks,

--Andrew Whitworth


On Mon, Jun 25, 2012 at 10:21 PM, Moritz Lenz <moritz at faui2k3.org> wrote:
> 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


More information about the parrot-dev mailing list