我的一个脚本在没有经过我的手修改的情况下停止了工作，并出现了一个非常奇特的错误信息。
Type check failed in binding to parameter '$s'; expected Str but got Int (42)
in sub jpost at /home/bisect/.perl6/sources/674E3526955FCB738B7B736D9DBBD3BD5B162E5C (WWW) line 9
in block <unit> at wrong-line-or-identifier.p6 line 3
其中第9行是这样的。
@stations = | jpost "https://www.perl6.org", :limit(42);
Rakudo 缺少了 $s 这个参数，我也一样。因为我的脚本和 WWW 中的任何例程都不包含这个参数。很明显，这是对一个相当简单的代码和一个流行的模块的回归。因为我有一段时间没有检查那个脚本了，所以我不知道是哪个Rakudo提交造成的。
在 #perl6 中，我们得到了 bisectable6，一个不断增长的有用机器人大军的成员。然而它却无法帮助我，因为它没有安装社区模块。用手对几十个 Rakudo 版本进行测试是不可能的。于是我拿出我仅有的一点 bash-foo，写了几个脚本来构建 Rakudos 过去。这就有了 #2779。
如果你也想去寻找时空旅行者的 bug，请克隆这些脚本，安装你的脚本所需的模块，并确保它失败时退出代码大于0。然后运行 ./build-head-to-tail.sh <nr-of-commits> 来构建你喜欢的 Rakudos。用 ./run-head-to-tail <nr-of-commits> <your-script-name-here>。最多可并行运行主机测试的核数。一段时间后，你会得到一个 OK、FAILed 和 SKIPed 提交的列表。任何未能构建的 Rakudo 提交都会被 SKIPed。
以 root 身份运行可能会失败，因为模块会被 zef 放到错误的位置。一次提交会占用大约 70MB 的磁盘空间，重复数据删除的希望不大。
勇敢的人们将 Perl 5 不断向前推进，他们有一整个 CPAN 价值的测试来检查是否有什么东西在他们改变编译器时被破坏。相比之下，我们的地盘还是相当小的，但我希望能对测试有更好的帮助。
by gfldex.