whiteknight/io_cleanup1 branch ready for testing

Jonathan "Duke" Leto jonathan at leto.net
Mon Jun 25 16:24:36 UTC 2012


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