Perl 5 Porters Mailing List Summary: November 2nd-9th


Hey everyone,

Following is the p5p (Perl 5 Porters) mailing list summary for the past week, including Monday the 9th. Enjoy!

November 2nd-9th Updates

Ricardo Signes is updating that the #onionsketch is back! Wednesday, November 18th is the next sketch meeting, at 14:00 NYC time.

Craig A. Berry shared his latest patch onPerl #126403, that addresses speeding up readon Windows, which seems very promising.

A grantreport by Tony Cook, the summary of which is:

Approximately 16 tickets were reviewed or worked on, and 6 patches were applied.

Tony's September grantreport is also available. Tony worked or or reviewed approximately 42 tickets.

H.Merijn (Tux) Brand updates that Getopt::Longis now available on Github.

Tony Cook opened a meta ticket,Perl #126546, to keep track of any issues detected by fuzzing.

Jarkko Hietaniemi providesan update on his Coverity work.

Tony Cook is trying to resolve (unrelated tickets)Perl #126042 (fuzzer-found segfault) andPerl #57512 (implicit closesilently unchecked for error), providing patches for both.

Bulk88 iscontinuing his quest to remove bootstrap files and proposedtwo patches to handle this.

Bulk88 also provided two patches (that were already applied by Tony Cook) to re-parallelize Win32 builds (after Unicode::Normalizewas reimplemented in XS, and to remove useless build product file /win32/config.w32.

A problem raised and solved inPerl #126582 by Jarkko Hietaniemi on accidental bit-shifting, following a discussion (mentioned under Discussionbelow).

Bulk88updates everyone that perl was forked by Michael Schwern under the name piledriver.

Bugs Reported bugs

Perl #126162, reported by Andreas J. Koening (in turn from a report by Slaven Rezić). A commit in perl which changes how statbehaves when receiving an array breaks perl5i.

Perl #126544, reported by Jim Avera, asks to document variables used in the synopsis of the fcntlfunction.

Perl #126556, reported by Atoomic, raises the question on destruction when using an INITblock. More on that under Discussionbelow.

Perl #126552, reported by Shlomi Fish, raises a possible bug in the Perl Debugger, which turns out to be a case of confusing closures.

Perl #126579, reported by Ricardo Signes, notes that after resolvingPerl #121085 (warning on filenames with newlines), there is still a warning even after a newline is stripped by a two-arg opencall.

Perl #126586, reported by Jarkko Hietaniemi, relates toPerl #126582 and the parsing of hexadecimal floats.

Perl #126593, reported by Andreas J. Koening (discovered by Slaven Rezić), Bleadperl breaks App::test::travis.

Resolved bugs Perl #126533: Trim Dynaloader. Perl #126534: Don't install PPPort.dll. Perl #125830: Building perl reproducibly. Perl #126368: Bleadperl breaks Filesys::DfPortable. Make -Obehaviour the default. (Commit 41d73075f0801c26794dadb1ff690f305d7e53a7, no ticket.) Perl #126502: Storablealters floating point number. Perl #126469: sv_reftypesecond argument is not described. Perl #122251: Bleadperl breaks Module::Infoand B::Utils. Discussion

Michael Felt (from AIXTools) sent anemail to p5p asking for help digging into a segmentation fault he's exploring.

Yaroslav Kuzminemailed about a hanging test in z/OS. Karl Williamson is already on it, providing branches to test out a fix.

Zsbán Ambrusasks about comparisons of integers and floating point numbers. Zefram responded that a comparison of mixed types was never planned to behave well and would be more complex and expensive. Ambrus disagrees but notes that difficult to implement correct and to test properly.

InPerl #126556 question on expected behavior (and the documentation of such) with regard to destruction when using an INITblock. It does not seem to be a bug but could possibly a problematic limitation. Todd Rinaldo tries to carefully describe it as:

So to rephrase what we're saying here: We're saying that any variable used in an INIT block like this either needs to be weakened or will never be destroyed until global destruction? I'm inclined to say that's a problem. At the least it should be documented right?

Philip Prindevilleasks about a possible feature for IO::Pipeallowing you to have access to the child PID. Chas Owens suggested using openinstead.

Bulk88suggests that distributions (such as Carp) which keep their development history in the perl core repository be separated into their own repository with their own history.

In the discussion around unsafe signal handlers inPerl #126474 Leon Timmermans suggests checking out his Signal::Pipemodule and Tony Cook has additional comments on possible improvements in the noted case.

Continued discussion inPerl #126437 about the documentation of hexand now its behavior as well.

Ricardo Signes adds inPerl #121766 he's not sure how to address the regression problem without reintroducing old problems.

Adiscussion started on support of hexadecimal floats yielded the following interesting observation, described by Jarkko:

So it really does look like the hexfp parsing code implementation is leaking over to supporting unintentionally also binary and octal...

Additionally, I will begin quoting the following emergent description of Perl, a result of a conversation on the ticket between Eirik Berg Hanssen and Jarkko:


... that's just emergent behaviour? Cool! :)


"Emergent behaviour" describes the whole of Perl rather beautifully, don't you think?