whiteknight/io_cleanup1 branch ready for testing

Andrew Whitworth wknight8111 at gmail.com
Mon Jun 25 16:30:53 UTC 2012


I'm not sure yet what benchmarks are needed. That's why I haven't set
any up yet. I suspect timed builds of NQP, Winxed and Rakudo might be
good places to start. If anybody else has any ideas of relevant
IO-heavy benchmarks to try I'd love to hear about them.

--Andrew Whitworth


On Mon, Jun 25, 2012 at 12:24 PM, Jonathan "Duke" Leto
<jonathan at leto.net> wrote:
> Howdy,
>
> Smolder report for "make smolder_fulltest" on Ubuntu 10.10 here:
>
> http://smolder.parrot.org/app/projects/report_details/29862
>
> 7 failing codingstd tests.
>
> What kind of benchmarks do you want to see?
>
> Duke
>
> On Sun, Jun 24, 2012 at 9:29 AM, Andrew Whitworth <wknight8111 at gmail.com> wrote:
>> The whiteknight/io_cleanup1 branch is ready for testing and
>> benchmarking. Help is appreciated.
>>
>> As of this morning I put in one last fix and was able to get the
>> following things to build on the branch without issue: Winxed and
>> tests, Rosella and tests, NQP (did not run tests) and Rakudo (have not
>> yet run tests). I will be working on the other tests later this
>> afternoon but don't expect regressions.
>>
>> In addition to testing, benchmarking is very important. Buffering is a
>> performance optimization, and there's a real chance that the change in
>> buffering algorithm or changes in when buffers are filled/flushed
>> buffers may cause different performance characteristics. I don't
>> expect regressions.
>>
>> There are some semantic changes in this branch, which I think are more
>> correct but which can be opened to debate:
>>
>> 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.
>> 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.
>> 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).
>>
>> Thanks,
>>
>> --Andrew Whitworth
>> _______________________________________________
>> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
>
>
> --
> Jonathan "Duke" Leto <jonathan at leto.net>
> Leto Labs LLC http://labs.leto.net
> 209.691.DUKE http://dukeleto.pl


More information about the parrot-dev mailing list