[00:07] ¦ rakudo: vrurg++ created pull request #3415: Pass relaxed flag further up to parent lookup [00:07] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/3415 [00:11] *** patrickz joined [00:15] *** patrickb left [00:32] ¦ roast: vrurg++ created pull request #612: Test relaxed FQN method calls on a role from parent [00:32] ¦ roast: review: https://github.com/perl6/roast/pull/612 [00:33] *** travis-ci joined [00:33] Rakudo build failed. Elizabeth Mattijsen 'Replace RT ticket references to GitHub [00:33] https://travis-ci.org/rakudo/rakudo/builds/635497213 https://github.com/rakudo/rakudo/compare/3e332a1adf84...06292bc826de [00:33] *** travis-ci left [01:07] *** awwaiid left [01:08] *** awwaiid joined [01:53] *** patrickz left [02:08] *** ufobat__ joined [02:12] *** ufobat_ left [02:42] ¦ rakudo: 27b3db274d | (Vadim Belman)++ | src/Perl6/Metamodel/Concretization.nqp [02:42] ¦ rakudo: Pass relaxed flag further up to parent lookup [02:42] ¦ rakudo: [02:42] ¦ rakudo: Fix for parameterized roles not found for FQN lookup if applied to a [02:42] ¦ rakudo: parent class. [02:42] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/27b3db274d [02:42] ¦ rakudo: 72fadd1b24 | (Vadim Belman)++ (committed using GitHub Web editor) | src/Perl6/Metamodel/Concretization.nqp [02:42] ¦ rakudo: Merge pull request #3415 from vrurg/fix-relaxed-FQN [02:42] ¦ rakudo: [02:42] ¦ rakudo: Pass relaxed flag further up to parent lookup [02:42] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/72fadd1b24 [02:42] ¦ roast: 802a448298 | (Vadim Belman)++ | S12-methods/qualified.t [02:42] ¦ roast: Test relaxed FQN method calls on a role from parent [02:42] ¦ roast: [02:42] ¦ roast: Also made test classes lexicals of their respective subtest block. [02:42] ¦ roast: review: https://github.com/perl6/roast/commit/802a448298 [02:42] ¦ roast: 2438626ff4 | (Vadim Belman)++ (committed using GitHub Web editor) | S12-methods/qualified.t [02:42] ¦ roast: Merge pull request #612 from vrurg/fix-relaxed-FQN [02:42] ¦ roast: [02:42] ¦ roast: Test relaxed FQN method calls on a role from parent [02:42] ¦ roast: review: https://github.com/perl6/roast/commit/2438626ff4 [04:07] *** quotable6 left [04:07] *** committable6 left [04:07] *** bloatable6 left [04:07] *** reportable6 left [04:07] *** releasable6 left [04:07] *** greppable6 left [04:07] *** squashable6 left [04:07] *** bisectable6 left [04:07] *** shareable6 left [04:07] *** statisfiable6 left [04:07] *** nativecallable6 left [04:07] *** coverable6 left [04:07] *** notable6 left [04:07] *** sourceable6 left [04:07] *** unicodable6 left [04:07] *** benchable6 left [04:07] *** bisectable6 joined [04:07] *** quotable6 joined [04:07] *** unicodable6 joined [04:07] *** bloatable6 joined [04:08] *** coverable6 joined [04:08] *** benchable6 joined [04:08] *** sourceable6 joined [04:09] *** greppable6 joined [04:09] *** squashable6 joined [04:09] *** nativecallable6 joined [04:09] *** reportable6 joined [04:09] *** notable6 joined [04:09] *** statisfiable6 joined [04:09] *** releasable6 joined [04:10] *** committable6 joined [04:10] *** shareable6 joined [05:21] *** MasterDuke left [05:40] Is there a high resolution timer or clock in nqp? [06:27] *** klapperl left [06:27] *** klapperl joined [08:01] Xliff: nqp::time_n [08:04] nine++ [08:04] Did find that about 3 hours ago. ;) [08:05] ¦ nqp/precomp: 351f3e48e5 | (Clifton Wood)++ | src/HLL/Compiler.nqp [08:05] ¦ nqp/precomp: - Change HLL::Compiler to accept a --temp-output parameter, which will [08:05] ¦ nqp/precomp: [08:05] ¦ nqp/precomp: output bytecode using a temporary filename. This allows higher level [08:05] ¦ nqp/precomp: compilers to generate bytecode in parallel WITHOUT the need for a [08:05] ¦ nqp/precomp: directory lock [08:05] ¦ nqp/precomp: review: https://github.com/perl6/nqp/commit/351f3e48e5 [08:05] The FUCK?! [08:06] Geth tracks forks?! [08:07] nine: That's on a precomp branch. Why is Geth reporting it? [08:07] It's on my precomp branch. [08:07] nine: Well, I wanted to show you my thoughts. Not the way I wanted to do it, but there you go... [08:26] Xliff: looks like you accidentally pushed the branch to the upstream repo? [08:27] nine: Yeah. I fixed that. [08:28] nine: Take a look at this diff -- https://github.com/Xliff/nqp/commit/351f3e48e55647c0481a9673e7694701c1c1d09b [08:29] With some upstream changes, I think I can remove the need for the directory lock in the precomp store. [08:53] You mean remove the lock completely? Not just replace it with a finer grained one? [09:21] *** sena_kun joined [09:33] ¦ rakudo: d8c7d87984 | (Rod Taylor)++ | src/Perl6/Actions.nqp [09:33] ¦ rakudo: Pull add_phasers_handling_code up from methodize_block [09:33] ¦ rakudo: [09:33] ¦ rakudo: This prevents it from being called twice for method_def and solves the below trouble code: [09:33] ¦ rakudo: [09:33] ¦ rakudo: class A { [09:33] ¦ rakudo: method f() { [09:33] ¦ rakudo: ENTER say "foo"; [09:33] ¦ rakudo: <…commit message has 7 more lines…> [09:33] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/d8c7d87984 [09:33] ¦ rakudo: ff7e17f1eb | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Perl6/Actions.nqp [09:33] ¦ rakudo: Merge pull request #3413 from rbt/f.enter_twice [09:33] ¦ rakudo: [09:33] ¦ rakudo: Run add_phasers_handling_code once for methods [09:33] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/ff7e17f1eb [09:52] *** thundergnat left [09:52] *** Altai-man_ joined [09:55] *** sena_kun left [09:55] nine: Yeah. I think this will remove it completely. [09:57] Actually, no. It will remove the need for the directory lock, but that atomic rename will still need to be guaranteed atomic. [09:58] I haven't looked at that bit of code yet, so I don't now what's involved. [10:00] How will you prevent multiple processes from precompiling the same dependency at the same time? [10:01] Well, the call to compile doesn't worry about that. It's the rename that matters. [10:02] The resulting bytecode will then belong to the latest compunit compiled. which is the desired one, correct? [10:02] The rename is important for keeping the read path lock free. But we'll also not want to waste countless cycles on compiling the same modules 8 times. [10:02] nine: Ah. I have not thought of a good way to avoid that, no. [10:02] Other than polling, and polling is tricky. [10:02] And the 8 times is a completely realistic scenario. It's what would happen when I work on Inline::Perl5 and run the test suite (with 8 parallel jobs, cause I have 8 cores) [10:03] Yeah, with me its 20 [10:03] I figured instead of the .lock file in the repo we can just lock the target precomp file itself [10:03] That's my hope, really. Again, I haven't gotten to that piece of code. [10:03] Unless that doesn't exist yet... [10:04] Right...and if you encounter the lock, what do you do? Wait? [10:04] If something happened to that precomp file so that it didn't exist after the lock was created, what then? [10:04] Same as we currently do with the .lock file: wait and when we gain the lock check if we still have something to do [10:04] These are the questions I was hoping to run around... not through. [10:05] OK. So polling is the best way to go? [10:05] You mean someone deleted the precomp file after we took the lock to update it? The precomp file would just reappear at the end of precompilation. On Windows this situation cannot happen at all, as deleting the open file will fail [10:05] I'll see about doing that at compunit store time, then. [10:06] Actually, no... thinking more of if precompilation failed. [10:06] It's not really polling. The kernel will wake up the process once it acquired the lock. Until then the process will sleep. [10:07] I might need to learn how to do that, then. [10:07] If we failed to precompile, the other process waiting for that lock will do its checks and notice that its job hasn't been done yet and precompile. That's exactly what happens now. [10:07] "sleep 100 unless $file.IO.e" is about the best way I know how to do something like that. [10:07] nine: Ah! True! [10:08] Will have to make sure that logic is still in place after my changes. Thanks! [10:08] It's as simple as this: https://github.com/rakudo/rakudo/blob/master/src/core.c/CompUnit/PrecompilationStore/File.pm6#L146 [10:09] $!update-lock is a Lock object protecting the PrecompilationStore in memory (against other threads) and $!lock is the .lock file in the repository. [10:09] IO::Handle.lock on the file itself, then? [10:09] yes [10:09] OK, that's what I was planning. [10:10] Btw. this code is the reason why I implemented file locking in rakudo in the first place :) [10:10] heh [10:26] *** travis-ci joined [10:26] Rakudo build errored. Elizabeth Mattijsen 'Merge pull request #3413 from rbt/f.enter_twice [10:26] https://travis-ci.org/rakudo/rakudo/builds/635623946 https://github.com/rakudo/rakudo/compare/72fadd1b243d...ff7e17f1eb07 [10:26] *** travis-ci left [10:28] *** patrickb joined [10:50] Files=1294, Tests=109642, 209 wallclock secs (28.29 usr 8.04 sys + 2934.13 cusr 273.35 csys = 3243.81 CPU) [10:55] *** travis-ci joined [10:55] Rakudo build failed. Elizabeth Mattijsen 'Merge pull request #3413 from rbt/f.enter_twice [10:55] https://travis-ci.org/rakudo/rakudo/builds/635623946 https://github.com/rakudo/rakudo/compare/72fadd1b243d...ff7e17f1eb07 [10:55] *** travis-ci left [10:57] t/02-rakudo/repl.t test 41 in one build [11:02] ok, one more ticket I want to check before releasing... [11:02] lizmat, o/ [11:02] Altai-man_ o/ [11:02] lizmat, did you patch .gist recently (since last release) ? [11:03] I see a module that fails because .gist is different, but not sure if that's due to changed format or because it does Raku grammar patching black magic and something was changed there. [11:03] hmmm... I've changed a lot since the last release [11:03] :S [11:03] and .gist falls back to .raku, and I did change a lot there [11:04] (well, first to .Str, and then to .raku) [11:04] the odd thing is that Blin doesn't show up regression commit [11:09] which module are we talking about ? [11:09] ADT [11:09] https://github.com/timo/ADT [11:14] that's an oldie [11:15] yesh. :S [11:16] looking at it now [11:17] lizmat, thanks! [11:17] ok, it doesn't have its own .gist [11:17] nor .perl [11:18] so it'd depending on the default .raku, it would seem [11:18] which makes my changes a candidate for the reason it fails now [11:18] lizmat, ok, then we can just send a patch, I think [11:18] not sure yet [11:20] lizmat, I am between 1)we need to change things to FIX them, IMPROVE them; 2)we mustn't change things because it breaks someones workflow we can't check [11:20] I'm with you, so if I changed something in the .gist output, it was not meant to be [11:24] releasable6, status [11:24] Altai-man_, Next release will happen when it's ready. There are no known blockers. 0 out of 427 commits logged [11:24] Altai-man_, Details: https://gist.github.com/2f1388fa9429e791b3489871c66b92da [11:26] Altai-man_: I don't think its .gist that's to blame [11:26] https://gist.github.com/lizmat/ed63ff17eec693510fcb840a495cf3c1 [11:26] shows that the structures are *very* different, and by the looks of the Any's , really wrong [11:26] *** Guest78373 left [11:26] then internal changes... [11:27] .gist is just the messenger :-( [11:27] yeah [11:27] *** Guest78373 joined [11:27] I do wonder wtf Blin doesn't show up a regression, only says it is a flapper [11:28] # create a pretty-printer [11:28] for -> $methname { [11:28] ah, it *does* have a .gist and a .perl [11:29] Altai-man_: could you run a bisect on the first test in t/01-basic.t ? [11:30] I can run bisect for the whole module or for a script [11:30] bisectable6, help [11:30] Altai-man_, Like this: bisectable6: old=2015.12 new=HEAD exit 1 if (^∞).grep({ last })[5] // 0 == 4 # See wiki for more examples: https://github.com/perl6/whateverable/wiki/Bisectable [11:30] then for t/01-basic.t [11:31] the other test scripts are fine [11:34] is there a decision wrt is-identifier? was it moved out from Str? [11:35] yes, it is no more [11:38] * Altai-man_ runs the first test [11:38] maybe that'll show up a comit [11:39] ¦ roast: d44517c284 | (Elizabeth Mattijsen)++ | 9 files [11:39] ¦ roast: First batch of roast RT -> GH ticket migration [11:39] ¦ roast: review: https://github.com/perl6/roast/commit/d44517c284 [11:39] only 685 files to go [11:40] >No regressions found, dot file not saved [11:40] sigh [11:43] ¦ roast: e76230bab2 | (Elizabeth Mattijsen)++ | S04-phasers/enter-leave.t [11:43] ¦ roast: Add test for GH #3411 [11:43] ¦ roast: review: https://github.com/perl6/roast/commit/e76230bab2 [11:47] ¦ rakudo/release-2020.01: 7be1e1bdad | Altai-man++ | docs/announce/2020.01.md [11:47] ¦ rakudo/release-2020.01: Update changelog [11:47] ¦ rakudo/release-2020.01: [11:47] ¦ rakudo/release-2020.01: Deliberately not logged: [11:47] ¦ rakudo/release-2020.01: [11:47] ¦ rakudo/release-2020.01: c63d8a8 5786026 9832958 9b1cb33 b12ba42 [11:47] ¦ rakudo/release-2020.01: 5d57011 960b0a1 2f94362d [11:47] ¦ rakudo/release-2020.01: review: https://github.com/rakudo/rakudo/commit/7be1e1bdad [11:48] *** thundergnat joined [11:51] ok, so I guess a release will be (hopefully) made today using release branch. any objections can be raised while I'm going for a walk and will be addressed on return. :) [11:53] *** sena_kun joined [11:56] *** Altai-man_ left [12:13] *** Guest78373 left [12:16] *** Guest78373 joined [12:16] sena_kun: as for the flapper status, it means that something also failed on --old too [12:17] so it tested --new, it failed, then it tested --old, it succeeded [12:17] so… should be bisected, right? [12:17] then it did a few more runs on --old and it turned out that it fails sometimes too [12:17] so even if you were to bisect it, it'd give you some bogus result [12:18] lizmat: very often you can give the whole file to bisectable [12:20] ah… if it's for a module… then yeah it's a bit easier to do it with blin [12:27] ¦ roast: 4568c2a1bd | (Elizabeth Mattijsen)++ | 9 files [12:27] ¦ roast: Second batch of roast RT -> GH ticket migration [12:27] ¦ roast: review: https://github.com/perl6/roast/commit/4568c2a1bd [12:29] *** AlexDani` joined [12:30] *** Guest78373 left [12:30] *** AlexDaniel left [12:31] *** Guest78373 joined [12:44] *** AlexDani` is now known as AlexDaniel [12:44] *** AlexDaniel left [12:44] *** AlexDaniel joined [12:46] ¦ rakudo: AlexDaniel assigned to jnthn Issue Should the GitHub organization's name and logo be changed from "Rakudo Perl"? https://github.com/rakudo/rakudo/issues/3416 [13:06] afk for some hours& [13:25] *** Guest78373 left [13:28] releasable6, status [13:28] sena_kun, Next release will happen when it's ready. There are no known blockers. 0 out of 427 commits logged [13:28] sena_kun, Details: https://gist.github.com/eae73ec679f04f73f8882cbf2e31afe1 [13:37] *** Guest78373 joined [13:38] sena_kun: ooooooooooooooooooooooooooooooooh… [13:38] I think I found a problem… [13:38] https://github.com/Raku/Blin/commit/debe6760fdafb1be4963be8f8de596a871059269 [13:38] AlexDaniel, hmm? [13:38] it should be “if not alright” [13:39] oh [13:39] so it wasn't really working since Oct 16 ? [13:39] hmm… [13:40] that's why we were not seeing any regressions from blin, ha [13:40] AlexDaniel, so every Flapper is a potential regression then? [13:40] 🥞🥞🥞 Bisecting ADT [13:40] [13:40] sena_kun: yeah [13:40] oh noes [13:40] this is not cool. :S [13:41] sena_kun: just rerun it on flappers after the fix [13:41] that's my fuckup :( [13:41] AlexDaniel, yes, going to do exactly that [13:41] * sena_kun waits for the fix commit [13:41] yeah… I'm in the process [13:47] ADT – Fail, Bisected: add2ec0d491218e59e6c7a517e37458e1a6c3daf [13:48] hmm :) [13:49] sena_kun: there's this example that can be used to test blin: bin/blin.p6 --old=2018.06 --new=2018.09 Foo::Regressed Foo::Regressed::Very Foo::Dependencies::B-on-A [13:50] AlexDaniel, that's a progress... Though I am not happy that now we are having, erm, 35 (!) potential regressions. anyway, thanks for the fix! [13:50] sena_kun: oh yeah that sounds about right! [13:51] finally [13:51] I'll re-run the flappers and create tickets... [13:52] *** Altai-man_ joined [13:53] geez that was very stupid on my part [13:53] AlexDaniel, hmm, did you push the fix? [13:53] Altai-man_: not yet, hold on [13:53] ah, ok [13:53] testing Foo:: modules to make sure it really didn't work [13:56] *** sena_kun left [13:58] Altai-man_: maybe we should have another run with --old=2019.07 then [13:58] because who know what wasn't caught in prep for 2019.11 [13:58] who knows* [13:59] AlexDaniel, ok, I'll do another Blin run tonight, but for now can investigate ones starting from 2019.11. [13:59] yeah, a quick run on just the flappers will speed things up quite a bit [13:59] AlexDaniel, also you've lied to me, writing the changelog was the easiest part! :P [13:59] really? [13:59] yaeh [14:00] I dunno… I've spent hours doing that : [14:00] :) [14:00] I am much more stressed over regressions | ecosystem testing thing, really. [14:00] I had a lot of fun bisecting stuff and investigating into failures [14:00] maybe your changelogs are just better and made more carefully than mine. :> [14:01] I suspect it will be easier for me too with the fixed tooling [14:03] ¦ Blin: 8a30528edd | (Aleks-Daniel Jakimenko-Aleksejev)++ | lib/Blin/Processing.pm6 [14:03] ¦ Blin: Unbreak Blin (big oops) [14:03] ¦ Blin: [14:03] ¦ Blin: This bug made all regressions appear as flappers. Oh no. It was [14:03] ¦ Blin: introduced in debe6760fdafb1be4963be8f8de596a871059269. [14:03] ¦ Blin: review: https://github.com/Raku/Blin/commit/8a30528edd [14:03] and yeah, confirmed that it didn't work before the fix and now it does [14:20] *** thundergnat left [14:24] >Enabled fetching backends [git path curl] don't understand http://www.cpan.org/authors/id/J/JN/JNTHN/Perl6/Log-Timeline-0.3.tar.gz [14:24] Um. Is there to be releasing?! [14:24] dafuq is this... [14:25] Xliff, sadly, nope [14:25] our counter of potential regressions suddenly increased from 0 to 35 [14:25] which is ugh [14:25] :( [14:25] Hmm... tar.gz should be curl... [14:28] *** lucasb joined [14:30] >Enabled fetching backends [git path curl] don't understand http://www.cpan.org/authors/id/J/JN/JNTHN/Perl6/OO-Monitors-1.1.1.tar.gz [14:30] eeh [14:45] “http” [14:45] freaking hell… [14:46] the more confusing thing is that it is a flapper, apparently, because on third try I no longer see any of these errors and it builds fine. :S [15:08] Shouldn't that be https anyway? [15:09] of course, yes [15:13] *** Kaiepi joined [15:23] nine: Still see no way of getting around polling. [15:23] nine: Consider another process tree hitting the .bc.lock file [15:41] Altai-man_: how is it? :) [15:41] 65 out of 107 modules processed [15:41] I'll create a ticket afterwards, so no worries [15:41] I see some are indeed bisected, but don't want to rush with incomplete results to not confuse myself [15:53] *** sena_kun joined [15:55] *** Altai-man_ left [16:07] *** masak left [16:55] *** Kaiepi left [17:24] *** domidumont joined [17:47] *** tyil left [17:48] *** tyilanmenyn joined [17:48] *** tyilanmenyn is now known as tyil [17:52] *** Altai-man_ joined [17:56] *** sena_kun left [17:59] Altai-man_: what about now? :D [17:59] yeah I'm impatient :) [17:59] AlexDaniel, ⏳ 103 out of 107 modules processed (left: PDF::Lite PDF::API6 PDF::Class PDF::Font::Loader) [18:00] and it was ⏳ 102 out of 107 modules processed (left: PDF::Content PDF::Lite PDF::API6 PDF::Class PDF::Font::Loader) like a half of hour ago... [18:00] I wonder if there is a fight over resources [18:01] no, probably dependencies waiting for PDF::Class [18:02] dunno [18:03] $ zef rdepends PDF::Class [18:03] PDF::API6:ver<0.1.2>:auth [18:03] overview for the impatient ones: https://clbin.com/gZ200 [18:03] at least one [18:03] m: say $*IN.lines.^name [18:03] rakudo-moar ff7e17f1e: OUTPUT: «Seq␤» [18:03] ⏳ 104 out of 107 modules processed (left: PDF::API6 PDF::Class PDF::Font::Loader) [18:04] PDF::Font::Loader was waiting for PDF::Lite [18:04] AlexDaniel, you can create a ticket out out of the overview, if you really want, though I'll make it myself in 20-30 minutes after exercising... [18:07] ¦ rakudo: AlexDaniel assigned to Altai-man Issue [WIP] Blin 2020.01 https://github.com/rakudo/rakudo/issues/3417 [18:07] Altai-man_: there you go :) [18:09] Altai-man_: hey I made module names clickable! [18:10] lizmat: some were bisected to your commits https://github.com/rakudo/rakudo/issues/3417 [18:31] hmm, this is really weird... [18:31] Xliff: I don't see where you'd have to do any polling? [18:31] https://github.com/rakudo/rakudo/commit/aa9c824d06c9f65645b35173b360c09388ab1890 shouldn't have sch a fallout [18:32] If another process hits the .bc.lock file, it will just wait for the lock [18:45] AlexDaniel, is that just my fantasy or some of them are false positives and bisected to latest commit bisected (lizmat one) as a false positive? For example, check logs for Verge::RPC::Client, it clearly has nothing to do with the commit, it's the file missing [18:46] Altai-man_: in the installed/ dir take a look at the output on new and old revisions [18:47] ok, I'm taking my words back. :S [18:47] phew [18:48] anyway, I'll run a full blin tonight, maybe we'll be able to squeeze some more juice now, but other than that just waiting for our great core devs to look into the issues. \o/ [18:48] AlexDaniel, thanks for your help! [18:49] I've updated the ticket with the rest of the modules checked also, notifying just in case [18:49] * Altai-man_ afk& [19:18] *** pochi_ joined [19:21] *** pochi left [19:21] *** TreyHarris left [19:23] *** TreyHarris joined [19:30] *** patrickb left [19:41] * lizmat is back [19:42] AlexDaniel: so is there something I should look at or not? [19:43] I guess [19:43] https://github.com/rakudo/rakudo/commit/aa9c824d06c9f65645b35173b360c09388ab1890 ? [19:47] https://modules.raku.org/dist/P6W looks like it doesn't even have any code ? or tests ?? yet it bisected to that commit ? [19:48] *** domidumont left [19:53] Also P6W installs just fine with zef [19:53] *** sena_kun joined [19:55] *** Altai-man_ left [20:34] .ask Altai-man_ does the release branch contain all of the .perl -> .raku changes that I did ? [20:34] lizmat, I'll pass your message to Altai-man_ [20:37] *** Kaiepi joined [20:57] lizmat, yes, up to the commit where you return .perlseen method back [20:57] you can check it at https://github.com/rakudo/rakudo/tree/release-2020.01 [20:57] I believe you :-) I was just thinking that the .perlseen addition *without* all of the other ones, could be an explanation for the Blin breakage we saw [20:59] no [20:59] I am not cherry-picking, but doing a rebase [21:02] ¦ roast: fbf511a36c | (Elizabeth Mattijsen)++ | 16 files [21:02] ¦ roast: Batch #3 of roast RT -> GH ticket migration [21:02] ¦ roast: review: https://github.com/perl6/roast/commit/fbf511a36c [21:29] m: my $a := $::a; say $a [21:29] rakudo-moar ff7e17f1e: OUTPUT: «(Mu)␤» [21:29] bisect: my $a := $::a; say $a [21:29] AlexDaniel, On both starting points (old=2015.12 new=ff7e17f) the exit code is 0 and the output is identical as well [21:29] AlexDaniel, Output on both points: «(Mu)␤» [21:29] interesting [21:30] 6c: my $a := $::a; say $a [21:30] AlexDaniel, ¦6c (40 commits): «(Mu)␤» [21:44] ¦ roast: d5caf89871 | (Elizabeth Mattijsen)++ | 11 files [21:44] ¦ roast: Batch #4 of roast RT -> GH ticket migration [21:44] ¦ roast: review: https://github.com/perl6/roast/commit/d5caf89871 [21:51] *** ufobat__ left [21:52] *** Altai-man_ joined [21:55] *** sena_kun left [22:10] ¦ roast: bd14bc3add | (Elizabeth Mattijsen)++ | 7 files [22:10] ¦ roast: Batch #5 of roast RT -> GH ticket migration [22:10] ¦ roast: review: https://github.com/perl6/roast/commit/bd14bc3add [22:11] that concludes my migration work of today [22:11] only 642 files to go [22:17] lizmat++ [22:21] lizmat++ indeed [22:23] btw I'll mention this again: https://github.com/sindresorhus/refined-github [22:23] makes links clickable and other stuff :) [23:27] *** lucasb left [23:54] *** sena_kun joined [23:56] *** Altai-man_ left