From bduggan at matatu.org Tue Dec 6 07:51:05 2016 From: bduggan at matatu.org (Brian Duggan) Date: Tue, 6 Dec 2016 10:51:05 -0500 Subject: [Philadelphia-pm] Monday Meeting Message-ID: <20161206155105.GB25720@haraka> Hi Everyone, Hope you can make it on Monday for our usual meeting. The logistics: Date: Monday, December 12 Time: 6 pm Location: PromptWorks, 1211 Chestnut Street, Suite 400 Dinner to follow This month Jim Keenan is coming down from NYC to talk about applications of "multisection" to the Perl 5 source code. Here's a description of the topic from Jim: Code bisection is a developer's tool customarily used to identify the single point in a series of commits when the code's behavior changed. * A test started to fail. * A test started to pass. * Code that was previously working started to crash. In each case, you traverse the commit tree and pose a question which can be answered in a Boolean manner: true/false, yes/no, pass/fail. But what happens when you discover that your code has failed in multiple, different ways over the course of many commits? In that case, *how* something failed becomes more important than simply *that* something failed. You may need to capture the complete output of the testing process for human examination. You need a tool for "multiple bisection" -- or, for short, "multisection." In this presentation, Jim Keenan will present a use case for multisection and a Perl-based solution, Devel-Git-MultiBisect, for that purpose. Brian From jkeen at verizon.net Thu Dec 15 07:32:52 2016 From: jkeen at verizon.net (James E Keenan) Date: Thu, 15 Dec 2016 10:32:52 -0500 Subject: [Philadelphia-pm] Devel-Git-MultiBisect: follow-up to Dec 12 2016 meeting Message-ID: This is a follow-up to the discussion of CPAN distribution Devel-Git-MultiBisect from the Philadelphia Perlmongers meeting on Monday, December 12 2016. I would once again like to thank phiadelphia.pm for offering me that opportunity to present my work. At approximately this point in the slides -- http://thenceforward.net/perl/talks/phlpm20161212/slide034.html -- Walt Mankowski asked why I felt it necessary, after testing commit 110 out of 220 -- i.e., the first bisection point -- I then proceeded to test commit 109 out of 220 rather than proceeding directly to the next bisection point which would, in this case, be commit 55 out of 220. The inference was that some of my test runs might have been unnecessary. I believe Geoff Avery and others -- speak up here, so you all get credit! -- concurred. Another way of putting this: Suppose that we populated a list of the index numbers of commits visited in the course of multisection. Suppose that that list was 0-based rather than 1-based. Then that list would start like this: [ 0, 219, 109, 108, 54, 81, 80, 67, 66, 60, 59, 57, 56, 55 ... ] Walt -- correct me if I'm misstating this -- was wondering why visits to steps 108, 80, 66, etc., were needed. I didn't have a good response then, and I still don't now. I can state that, in terms of getting to my desired final result (see http://thenceforward.net/perl/talks/phlpm20161212/slide050.html), my multiple bisection code is correct, even if it is somewhat inefficient. Thinking about this over the past few days, I realized that it would be helpful to create, for my benefit and yours, a simplified framework for approaching the problem. In my github repo for this distribution (though not yet on CPAN), I have added this file: https://github.com/jkeenan/devel-git-multibisect/blob/master/examples/generalized-multisection.t. This program abstracts away the presenting problem and git in order to just focus on the procedure for multisection of a list of strings in the same format as produced by Devel::Git::MultiBisect::Transitions::multisect_all_targets(). The bisection procedure I am currently using in that method can be found in multisect_list(), which starts at line 265, and more specifically in the if block starting at line 317. Now, I suspect that some of the bisection steps could probably be eliminated -- but different steps from those people were pointing out during the meeting. If we took a look at the complete list of indexes visited, it would be: [ 0, 219, 109, 108, 54, 81, 80, 67, 66, 60, 59, 57, 56, 55, 137, 136, 96, 95, 75, 74, 65, 64, 58 ] That holds the full 23 steps taken to identify all 3 transition points in the 220-item commit range discussed at the meeting. But if we know that the value at the first real bisection point (index 109) is identical to that at the end-of-range point (index 219), then we should be able to avoid ever visiting any index between 109 and 219. Hence, indexes 137 and 136 could be eliminated. But that's a different set of potentially eliminatable steps from what was raised at the meeting. So, if any of you would like to stare at the code and offer a suggestion, feel free to clone that repo, poke around and offer a patch. Thank you very much. Jim Keenan