At YAPC::NA 2012 last week, I decided I’d try to start summarizing the traffic on p5p. I’m sorry I didn’t get it done in time to include in Perl Weekly. I will attempt to do better in the future.
I don’t summarize every thread that is posted or written about. My goal is to highlight selected posts from the list traffic.
Also I’m just some guy; I’m not part of the perl5 core, so what I think is important may or may not reflect the consensus of the core contributors.
Adding Config::Perl::V to core
Ricardo Signes (our current pumpking) wrote:
It is very likely that Config::Perl::V, used by a number of smoking libraries to get information about the running perl, is going to go into core.
https://metacpan.org/module/Config::Perl::V
Cheers, comments, and objections would be appropriate at this time.
Nicholas Clark replied:
I *really* don't think that we should be adding a module that shells out to the current Perl. The entire output of perl -V is now generated *in Perl space* by Config::_V. Most of the values needed already exposed by public subroutines in Config, such as Config::compile_date(). I think that the correct approach is to expose whatever else is needed, and have Config::Perl::V avoid shelling out if it doesn't need to.
The reason I strenuously object to shelling out back to $^X is not theoretical. It can cause strange bugs. It certainly breaks things like profiling when they are invoked via environment variables.
Later in the week, Nicholas sent a proposed patch which H.Merijn Brand incorporated into his module:
http://repo.or.cz/w/Config-Perl-V.git/commit/e9843079de5351
Testing with 68 versions of perl (Module::Release++)
All passed
perlsecret.pod
In May, Phillipe Bruhat (aka BooK) proposed including documentation about some “secret” perl “operators”:
I have pushed (during the Perl QA Hackathon in Paris) a book/perlsecret branch that contains a new manual page (perlsecret.pod, not referenced in the main perl.pod) and a new test script (secret.t, under t/japh, so that it's only run during torturetest).
[...]
Now that 5.16 is out, I'd like to discuss the inclusion of this minor (and hidden) addition to the Perl documentation.
The comment thread rolled into June and last week Rik replied:
I really like perlsecret, and I want it to be somewhere, but I don't think it belongs in the core documentation right now. [...]
I hope we will be able to consider it again, once we've got a better idea how to deal with our overabundance of documentation. If you find a great home for it (even if just as a CPAN dist with "perlsecret.pod" in it) let us know. I, at least, will want to refer to it.
And BooK replied:
I've published a perlsecret distribution on CPAN yesterday, with the pod file (and without the SFW patch).
Highly illegal variable names now legal
Tom Christiansen started a thread via perlbug which included an example program showing how UTF-8 symbols, punctuation and combining characters(!) can be made into valid variable names. He writes:
I can handle punctuation. I can handle symbols.
I can even handle private use area.
I don't know what I think about hypers. Probably yes ok.
But I see no place for control characters or combining marks of any sort, and I am really unhappy about whitespace variable names. What's next, dollar tab? Beyond that, I am *exceedingly* displeased with surrogates.
That's just evil and wrong, and in so many ways.
Rik replied:
This definitely needs fixing.
What characters can be a literal punctuation var? Possibly:
(\pP | \pS) & \P{Space}
I think there's room to wiggle here, but it doesn't include surrogates or leading marks.
RFC on “pre-deprecation”
Karl Williamson published an RFC suggesting:
to have a release cycle where the to-be-removed construct would be "pre-deprecated", where no warning messages are raised unless explicitly requested by the user; and then a release cycle where a standard deprecated warning is raised.
In the 5.16 delta, we issued some pre-deprecation notices, but there is no mechanism to tell someone that the code they are running has or doesn't have the issues.
David Golden replied:
Without reviewing my earlier suggestions (so I might contradict myself now), I don't think I intended that "pre-deprecation" should have any code impact, including warnings.
I believe I was attempting to address the fact that a very small subset of Perl users actually follow p5p discussions and thus deprecation decisions get taken with input from a non-representative sample. And by the time deprecations are released in a stable version
when most people might notice, they are fait accompli.
[...]
I appreciate Karl's well-intentioned suggestion and what he's trying to do, but feel the extra work and warning-system complexity isn't worth it.
Karl wrote:
Then I think that we need 2 cycles of actual deprecated warnings. I don't think it is sufficient just to publish that a change is coming for one of those cycles.
Rik closed the thread, writing:
What David says [...] is what I had assumed we'd be doing: providing a public notice on a place that interested folks could see a heads-up about what might change in the future.
As for two deprecation cycles, Rik replied:
I think it's plausible, but I do worry about a chilling effect on changes that need deprecation cycles.
Dual life [GNO]DBM_File?
A few weeks ago, Steve Hay proposed removing some GCCisms from MSVC++ files. kmx replied that he had some concerns about [GNO]DBM_File.pm in Strawberry Perl.
Last week, Nicholas Clark wrote:
I can't see any reason why it would cause problems if these three were made dual life. Dual life, with upstream CPAN should work. IIRC it would also make the lives of various linux distributions simpler (or at least, more flexible)
Perl 5.17.1 released
Jesse Luehrs announced that Perl 5.17.1 is now available:
We are delighted to announce Perl 5.17.1, the second development release of Perl 5.17.
Perl 5.17.1 represents approximately 4 weeks of development since Perl 5.17.0 and contains approximately 37,000 lines of changes across 710 files from 35 authors.
We expect to release Perl 5.17.2 on July 20, 2012. The next major stable release of Perl 5, version 5.18.0, should appear in May 2013.
Re-opening scalar handles breaks on 5.16.0
Leon Timmermans opened a regression bug ticket on the newly minted 5.16.0. When a scalar file handle is duplicated using &= syntax, it causes a fatal error. (It works fine in 5.10, 5.12 and 5.14.) Father Chrysostomos fixed this problem in commit 7b3cf1c05, and it will be cherry picked into the forthcoming 5.16.1 release.
Parrot 4.5.0 released
Alvis Yardley announced that Parrot 4.5.0 was released.
Refactoring tests to use test.lib
Colin Kuskie offered to refactor tests as outlined in todo.pod, opening a ticket in RT.
Closing lots of old RT tickets
Jesse Luehrs has been updating/closing a ton of old tickets in RT, committing patches to blead when appropriate. Some of these open tickets go back six or seven years.
Using slab allocation for opcodes
In April 2012, an issue was reported where perl would coredump using perl -c. The underlying crash was diagnosed as being related to the way Perl attempts to stop leaking memory from opcode allocation. This long running thread seems to have made significant progress this past week when Father Chrysostomos wrote a patch implementing slab based allocator for opcodes. This would permit opcodes to be correctly free’d if something croak’d during subroutine compilation.
Requesting an override interface for given/when and smart matching
A request was made to implement an interface to override the built in given/when and smart matching functionality.
Rik replied:
Nothing is stopping anyone from doing what Jesse L. did to implement another engine, but the problem is knowing how to dynamically apply things.
For example, consider:
use Smartmatch::Engine::XYZ;
use Junction qw(any);
$x ~~ any(1,2,3);
...where 'any' is defined in the package Junction with ~~ distributing across the elements.
That means that in Junction.pm, there will effectively be something saying "$x ~~ 1" but without the Smartmatch::Engine::XYZ in use there, it will not necessarily do the right thing.
Until this problem is solved, pluggable ~~ behavior will become more, not less, confusing.
Later, Jesse wrote that he’d attempted to address some of this concern, but Rik wrote the attempt still didn’t address the issue of handling righthand values of ~~.