Perl 5 programmers are used to being casual about closing file handles. Obviously, 6 requires a change of habits. A cultural shift, if that's not too pretentious a term. Perhaps it needs to be mentioned in large, friendly letters somewhere in the documentation?
On 9/5/17, jn...@jnthn.net via RT <perl6-bugs-follo...@perl.org> wrote: > On Tue, 05 Sep 2017 00:54:27 -0700, alex.jakime...@gmail.com wrote: >> <[Tux]> CSV tests started to fail >> <[Tux]> # at t/90_csv.t line 260 >> <[Tux]> # expected: $[["1", "2", "3"], ["2", "a b", ""]] >> <[Tux]> # got: $[["1", "2", "3"],] >> <[Tux]> # Failed test 'AOH parse out' >> >> >> Bisectable points to >> https://github.com/rakudo/rakudo/commit/4b02b8aadcb47072bc87fb8be8069177b74cd59d >> >> bisect log: https://gist.github.com/62a876b09bfecc9aa305061e384f43ce >> double-check with committable: >> https://gist.github.com/50bd16934e6bc93ad49a1659cf31bf06 >> >> >> I'm suspecting that Whateverable issues that I'm seeing right now are >> also associated with this. > > Text::CSV is failing to close an output handle on all codepaths in one of > its methods, and can be fixed by a patch to do that: > > https://gist.github.com/jnthn/a999df1f89d24cdc6ffac42ca55be806 > > Failing to close output handles has been clearly documented (and yes, > documented well before the recent buffering change) as something that can > cause data loss. Default output buffering just makes it quite a lot more > likely to show up. > > While there will be some ecosystem fallout like this, unfortunately I don't > think it's avoidable. If we whip out the patch that turns output buffering > on by default for non-TTYs for this release, then when will we include it? > The longer we leave it, the more painful it will be, because more code will > be written that is careless with handles. > > I don't think "leave it off by default" is a good option either, otherwise > we get to spend the next decade hearing "Perl 6 I/O is slow" because it'd be > one of the only languages that doesn't buffer its output without an explicit > flag being passed to enable that (which nearly nobody doing quick benchmarks > will know to use). > > In summary, if we had a time machine, going back and implementing this when > the ecosystem was smaller would be a good use of it. But we don't, and we > won't in the future, so I suspect the best thing to do is take the hit now. > > Will leave this ticket open a little longer for further comments/discussion, > but my intention is to reject it. > > /jnthn >
