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 on
Perl #126403,
that addresses speeding up read
on Windows, which seems very promising.
A grant report by Tony Cook, the summary of which is:
Approximately 16 tickets were reviewed or worked on, and 6 patches were applied.
Tony's September grant report is also available. Tony worked or or reviewed approximately 42 tickets.
H.Merijn (Tux) Brand updates that Getopt::Long is now available on Github.
Tony Cook opened a meta ticket, Perl #126546, to keep track of any issues detected by fuzzing.
Jarkko Hietaniemi provides an update on his Coverity work.
Tony Cook is trying to resolve (unrelated tickets)
Perl #126042
(fuzzer-found segfault)
and
Perl #57512
(implicit close
silently unchecked for error),
providing patches for both.
Bulk88 is continuing his quest to remove bootstrap files and proposed two patches to handle this.
Bulk88 also provided two patches (that were already applied by
Tony Cook) to re-parallelize Win32 builds (after
Unicode::Normalize was
reimplemented in XS, and to remove useless build product file
/win32/config.w32
.
A problem raised and solved in Perl #126582 by Jarkko Hietaniemi on accidental bit-shifting, following a discussion (mentioned under Discussion below).
Bulk88 updates 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 stat
behaves when
receiving an array breaks
perl5i.
Perl #126544,
reported by Jim Avera, asks to document variables used in the
synopsis of the fcntl
function.
Perl #126556,
reported by Atoomic, raises the question on destruction when using
an INIT
block. More on that under Discussion below.
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 resolving
Perl #121085
(warning on filenames with newlines), there is still a warning
even after a newline is stripped by a two-arg open
call.
Perl #126586, reported by Jarkko Hietaniemi, relates to Perl #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.so
/PPPort.dll
. - Perl #125830: Building perl reproducibly.
- Perl #126368: Bleadperl breaks Filesys::DfPortable.
- Make
-O
behaviour the default. (Commit 41d73075f0801c26794dadb1ff690f305d7e53a7, no ticket.) - Perl #126502: Storable alters floating point number.
- Perl #126469:
sv_reftype
second argument is not described. - Perl #122251: Bleadperl breaks Module::Info and B::Utils.
Discussion
Michael Felt (from AIXTools) sent an email to p5p asking for help digging into a segmentation fault he's exploring.
Yaroslav Kuzmin emailed about a hanging test in z/OS. Karl Williamson is already on it, providing branches to test out a fix.
Zsbán Ambrus asks 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.
In
Perl #126556
question on expected behavior (and the documentation of such)
with regard to destruction when using an INIT
block. 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 Prindeville
asks
about a possible feature for
IO::Pipe allowing you to
have access to the child PID. Chas Owens suggested using open
instead.
Bulk88 suggests 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 in Perl #126474 Leon Timmermans suggests checking out his Signal::Pipe module and Tony Cook has additional comments on possible improvements in the noted case.
Continued discussion in
Perl #126437
about the documentation of hex
and now its behavior as well.
Ricardo Signes adds in Perl #121766 he's not sure how to address the regression problem without reintroducing old problems.
A discussion 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:
Eirik:
... that's just emergent behaviour? Cool! :)
Jarkko:
"Emergent behaviour" describes the whole of Perl rather beautifully, don't you think?
Sawyer X, thank you so much for doing this!