Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Summarize Oct-29-2012

  • Loading branch information...
commit 3fe4fd19d9dafc6abd3d6fe8653336da510ab89a 1 parent 8c2d168
@mrallen1 authored
Showing with 121 additions and 0 deletions.
  1. +121 −0 2012/10/29.md
View
121 2012/10/29.md
@@ -0,0 +1,121 @@
+Perl 5 Porters Weekly: October 29-November 4, 2012
+==================================================
+
+Welcome to Perl 5 Porters Weekly, a summary of the email traffic of the
+perl5-porters email list.
+
+This week's topics are:
+
+* perl-5.16.2 is now available
+* perl-5.12.5 RC1 is now available
+* What happened to the whole "small core" idea?
+* Eliminating the "rehash" mechanism for 5.18
+* benchmarking Murmurhash3 vs One-At-A-Time as perl's hash function
+
+**perl-5.16.2 is now available**
+
+Ricardo Signes announced that perl 5.16.2 is now available on a CPAN mirror
+near you.
+
+[Read the announcement][1]
+
+[Read what's new][2]
+
+[Download the tarball][3]
+
+**perl-5.12.5 RC1 is now available**
+
+Dominic Hargreaves announced that perl 5.12.5-RC1 is now available on a CPAN
+mirror near you.
+
+[Read the announcement][4]
+
+**What happened to the whole "small core" idea**
+
+[Last time][5], Peter Rabbitson asked what had happened to the idea of making
+Perl's core smaller. Ricardo Signes, the project's arbiter of taste,
+finally replied this week. I encourage you to "read the whole thing" as all
+the cool kids say these days, but here are some good excerpts:
+
+ Later on in this thread, you say something like, "people are talking about
+ getting [subroutine signatures] into 5.18." I never thought this was
+ seriously considered. That is, I thought maybe some were hoping to see
+ it become an experimental feature, but not anything we'd be stuck with
+ once we proved it stank.
+
+ ...but really, I didn't think it was even going to get that far. But did
+ it have to become a discussion about that? I didn't think so. There were two
+ important things to figure out: (a) how can we get perl equipped with hooks
+ for signature systems that share a common underpining so we can figure out what
+ a good "core" one might be and (b) what might that core one be?
+
+ (a) would be nice to see, at least experimentally in 5.18
+
+ (b) seems like it will be an ongoing discussion; why not have some of it on
+ p5p? and if there's an implementation that is built in a branch, without the
+ benefit of the hooks suggested by 'a' that lets us play with the things as
+ discussed... awesome!
+
+ [...]
+
+ As you noted, the bikeshedding is largely about design decisions that have
+ *not* been proved on CPAN or become a standard. This is a warning sign that
+ it's maybe not baked enough. I don't think that means that we should stop
+ talking about it, or stop building on the code that implements it. That
+ currently-in-a-branch-of-perl code seems pretty good, and may very well be the
+ code that does evolve into something proven enough to become the beloved
+ reference implementation of signatures. After all, it's from that code that
+ the signature-adding APIs will probably be born, right?
+
+[Read the whole thing][6]
+
+**Eliminating the "rehash" mechanism for 5.18**
+
+Yves Orton proposed eliminating perl's defensive mechanism against
+pathological hash insertion attacks and replacing it with a per-run random
+hash seed. He explains:
+
+ Choose a random hash seed at process start up as it effectively prevents
+ the attacker from constructing their colliding keys remotely. However
+ it also means that the order in which a set of keys are stored in a hash
+ becomes random.
+
+ [...]
+
+ Besides the advantages of avoiding the costs of the rehash mechanism
+ this change will smoke out any hash order dependency bugs in the
+ modules on CPAN, and in our own code. (I found at least two unrelated
+ bugs in code in core due to hash randomization.) It will also prepare
+ the ground for people to choose alternative hash algorithms for Perl
+ to use, or to make it possible to use specialized hash algorithms in
+ certain contexts such as 64 bit builds.
+
+ The downside however will be that it almost certainly will make lots
+ of lazily written code to fail. But IMO the cost is worth it.
+
+Most people thought this was a good idea, but some thought there were
+additional security precautions which should be considered.
+
+[Read the thread][7]
+
+**benchmarking Murmurhash3 vs One-At-A-Time as perl's hash function**
+
+Yves Orton had another interesting hash related email this week. He'd
+written earlier in the summer that he was looking at replacing perl's hash
+algorithm with one that could offer some signficant performance benefits
+especially with longer keys. This week he reported the results:
+
+ Conclusion: on my laptop Murmurhash3 is more than 3 times faster at
+ hashing longer strings than one-at-a-time, and roughly the same for
+ shorter strings.
+
+[Read the post][8]
+
+[1]: http://www.nntp.perl.org/group/perl.perl5.porters/2012/11/msg194915.html
+[2]: https://metacpan.org/module/perldelta
+[3]: http://cpan.metacpan.org/authors/id/R/RJ/RJBS/perl-5.16.2.tar.bz2
+[4]: http://www.nntp.perl.org/group/perl.perl5.porters/2012/11/msg194981.html
+[5]: http://byte-me.org/perl-5-porters-weekly-october-22-october-28-2012/
+[6]: http://www.nntp.perl.org/group/perl.perl5.porters/2012/10/msg194832.html
+[7]: http://www.nntp.perl.org/group/perl.perl5.porters/2012/10/msg194813.html
+[8]: http://www.nntp.perl.org/group/perl.perl5.porters/2012/10/msg194877.html
Please sign in to comment.
Something went wrong with that request. Please try again.