Geth rakudo: vrurg++ created pull request #3415:
Pass relaxed flag further up to parent lookup		 00:07
00:11 patrickz joined 00:15 patrickb left
Geth roast: vrurg++ created pull request #612:
Test relaxed FQN method calls on a role from parent		 00:32
00:33 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Replace RT ticket references to GitHub 00:33
travis-ci.org/rakudo/rakudo/builds/635497213 github.com/rakudo/rakudo/compare/3...292bc826de
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
Geth rakudo: 27b3db274d | (Vadim Belman)++ | src/Perl6/Metamodel/Concretization.nqp
Pass relaxed flag further up to parent lookup

Fix for parameterized roles not found for FQN lookup if applied to a parent class.		 02:42
rakudo: 72fadd1b24 | (Vadim Belman)++ (committed using GitHub Web editor) | src/Perl6/Metamodel/Concretization.nqp
Merge pull request #3415 from vrurg/fix-relaxed-FQN

Pass relaxed flag further up to parent lookup
roast: 802a448298 | (Vadim Belman)++ | S12-methods/qualified.t
Test relaxed FQN method calls on a role from parent

Also made test classes lexicals of their respective subtest block.
roast: 2438626ff4 | (Vadim Belman)++ (committed using GitHub Web editor) | S12-methods/qualified.t
Merge pull request #612 from vrurg/fix-relaxed-FQN

Test relaxed FQN method calls on a role from parent
04:07 quotable6 left, committable6 left, bloatable6 left, reportable6 left, releasable6 left, greppable6 left, squashable6 left, bisectable6 left, shareable6 left, statisfiable6 left, nativecallable6 left, coverable6 left, notable6 left, sourceable6 left, unicodable6 left, benchable6 left, bisectable6 joined, quotable6 joined, unicodable6 joined, bloatable6 joined 04:08 coverable6 joined, benchable6 joined, sourceable6 joined 04:09 greppable6 joined, squashable6 joined, nativecallable6 joined, reportable6 joined, notable6 joined, statisfiable6 joined, releasable6 joined 04:10 committable6 joined, shareable6 joined 05:21 MasterDuke left
Xliff Is there a high resolution timer or clock in nqp? 05:40
06:27 klapperl left, klapperl joined
nine Xliff: nqp::time_n 08:01
Xliff nine++ 08:04
Did find that about 3 hours ago. ;)
Geth nqp/precomp: 351f3e48e5 | (Clifton Wood)++ | src/HLL/Compiler.nqp
- Change HLL::Compiler to accept a --temp-output parameter, which will

output bytecode using a temporary filename. This allows higher level compilers to generate bytecode in parallel WITHOUT the need for a directory lock		 08:05
Xliff The FUCK?!
Geth tracks forks?! 08:06
nine: That's on a precomp branch. Why is Geth reporting it? 08:07
It's on my precomp branch.
nine: Well, I wanted to show you my thoughts. Not the way I wanted to do it, but there you go...
nine Xliff: looks like you accidentally pushed the branch to the upstream repo? 08:26
Xliff nine: Yeah. I fixed that. 08:27
nine: Take a look at this diff -- github.com/Xliff/nqp/commit/351f3e...01c1c1d09b 08:28
With some upstream changes, I think I can remove the need for the directory lock in the precomp store. 08:29
nine You mean remove the lock completely? Not just replace it with a finer grained one? 08:53
09:21 sena_kun joined
Geth rakudo: d8c7d87984 | (Rod Taylor)++ | src/Perl6/Actions.nqp
Pull add_phasers_handling_code up from methodize_block

This prevents it from being called twice for method_def and solves the below trouble code:
class A {
   method f() {
   ENTER say "foo";
... (7 more lines)		 09:33
rakudo: ff7e17f1eb | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | src/Perl6/Actions.nqp
Merge pull request #3413 from rbt/f.enter_twice

Run add_phasers_handling_code once for methods
09:52 thundergnat left, Altai-man_ joined 09:55 sena_kun left
Xliff nine: Yeah. I think this will remove it completely. 09:55
Actually, no. It will remove the need for the directory lock, but that atomic rename will still need to be guaranteed atomic. 09:57
I haven't looked at that bit of code yet, so I don't now what's involved. 09:58
nine How will you prevent multiple processes from precompiling the same dependency at the same time? 10:00
Xliff Well, the call to compile doesn't worry about that. It's the rename that matters. 10:01
The resulting bytecode will then belong to the latest compunit compiled. which is the desired one, correct? 10:02
nine 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.
Xliff nine: Ah. I have not thought of a good way to avoid that, no.
Other than polling, and polling is tricky.
nine 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)
Xliff Yeah, with me its 20 10:03
nine I figured instead of the .lock file in the repo we can just lock the target precomp file itself
Xliff That's my hope, really. Again, I haven't gotten to that piece of code.
nine Unless that doesn't exist yet...
Xliff 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?
nine Same as we currently do with the .lock file: wait and when we gain the lock check if we still have something to do
Xliff These are the questions I was hoping to run around... not through.
OK. So polling is the best way to go? 10:05
nine 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
Xliff I'll see about doing that at compunit store time, then.
Actually, no... thinking more of if precompilation failed. 10:06
nine It's not really polling. The kernel will wake up the process once it acquired the lock. Until then the process will sleep.
Xliff I might need to learn how to do that, then. 10:07
nine 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.
Xliff "sleep 100 unless $file.IO.e" is about the best way I know how to do something like that.
nine: Ah! True!
Will have to make sure that logic is still in place after my changes. Thanks! 10:08
nine It's as simple as this: github.com/rakudo/rakudo/blob/mast...e.pm6#L146
$!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
Xliff IO::Handle.lock on the file itself, then?
nine yes
Xliff OK, that's what I was planning.
nine Btw. this code is the reason why I implemented file locking in rakudo in the first place :) 10:10
Xliff heh
10:26 travis-ci joined
travis-ci Rakudo build errored. Elizabeth Mattijsen 'Merge pull request #3413 from rbt/f.enter_twice 10:26
travis-ci.org/rakudo/rakudo/builds/635623946 github.com/rakudo/rakudo/compare/7...7e17f1eb07
10:26 travis-ci left 10:28 patrickb joined
lizmat Files=1294, Tests=109642, 209 wallclock secs (28.29 usr 8.04 sys + 2934.13 cusr 273.35 csys = 3243.81 CPU) 10:50
10:55 travis-ci joined
travis-ci Rakudo build failed. Elizabeth Mattijsen 'Merge pull request #3413 from rbt/f.enter_twice 10:55
travis-ci.org/rakudo/rakudo/builds/635623946 github.com/rakudo/rakudo/compare/7...7e17f1eb07
10:55 travis-ci left
lizmat t/02-rakudo/repl.t test 41 in one build 10:57
Altai-man_ ok, one more ticket I want to check before releasing... 11:02
lizmat, o/
lizmat Altai-man_ o/
Altai-man_ lizmat, did you patch .gist recently (since last release) ?
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
lizmat hmmm... I've changed a lot since the last release
Altai-man_ :S
lizmat and .gist falls back to .raku, and I did change a lot there
(well, first to .Str, and then to .raku) 11:04
Altai-man_ the odd thing is that Blin doesn't show up regression commit
lizmat which module are we talking about ? 11:09
Altai-man_ ADT
github.com/timo/ADT
lizmat that's an oldie 11:14
Altai-man_ yesh. :S 11:15
lizmat looking at it now 11:16
Altai-man_ lizmat, thanks! 11:17
lizmat ok, it doesn't have its own .gist
nor .perl
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
Altai-man_ lizmat, ok, then we can just send a patch, I think
lizmat not sure yet
Altai-man_ 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
lizmat I'm with you, so if I changed something in the .gist output, it was not meant to be
Altai-man_ releasable6, status 11:24
releasable6 Altai-man_, Next release will happen when it's ready. There are no known blockers. 0 out of 427 commits logged
Altai-man_, Details: gist.github.com/2f1388fa9429e791b3...71c66b92da
lizmat Altai-man_: I don't think its .gist that's to blame 11:26
gist.github.com/lizmat/ed63ff17eec...0a495cf3c1
shows that the structures are *very* different, and by the looks of the Any's , really wrong
11:26 Guest78373 left
Altai-man_ then internal changes... 11:26
lizmat .gist is just the messenger :-( 11:27
Altai-man_ yeah
11:27 Guest78373 joined
Altai-man_ I do wonder wtf Blin doesn't show up a regression, only says it is a flapper 11:27
lizmat # create a pretty-printer 11:28
for <perl gist> -> $methname {
ah, it *does* have a .gist and a .perl
Altai-man_: could you run a bisect on the first test in t/01-basic.t ? 11:29
Altai-man_ I can run bisect for the whole module or for a script 11:30
bisectable6, help
bisectable6 Altai-man_, Like this: bisectable6: old=2015.12 new=HEAD exit 1 if (^∞).grep({ last })[5] // 0 == 4 # See wiki for more examples: github.com/perl6/whateverable/wiki/Bisectable
lizmat then for t/01-basic.t
the other test scripts are fine 11:31
Altai-man_ is there a decision wrt is-identifier? was it moved out from Str? 11:34
lizmat yes, it is no more 11:35
Altai-man_ runs the first test 11:38
maybe that'll show up a comit
Geth roast: d44517c284 | (Elizabeth Mattijsen)++ | 9 files
First batch of roast RT -> GH ticket migration
 11:39
lizmat only 685 files to go
Altai-man_ >No regressions found, dot file not saved 11:40
sigh
Geth roast: e76230bab2 | (Elizabeth Mattijsen)++ | S04-phasers/enter-leave.t
Add test for GH #3411
 11:43
rakudo/release-2020.01: 7be1e1bdad | Altai-man++ | docs/announce/2020.01.md
Update changelog

Deliberately not logged:
c63d8a8 5786026 9832958 9b1cb33 b12ba42 5d57011 960b0a1 2f94362d		 11:47
11:48 thundergnat joined
Altai-man_ 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:51
11:53 sena_kun joined 11:56 Altai-man_ left 12:13 Guest78373 left 12:16 Guest78373 joined
AlexDaniel sena_kun: as for the flapper status, it means that something also failed on --old too 12:16
so it tested --new, it failed, then it tested --old, it succeeded 12:17
so… should be bisected, right?
then it did a few more runs on --old and it turned out that it fails sometimes too
so even if you were to bisect it, it'd give you some bogus result
lizmat: very often you can give the whole file to bisectable 12:18
ah… if it's for a module… then yeah it's a bit easier to do it with blin 12:20
Geth roast: 4568c2a1bd | (Elizabeth Mattijsen)++ | 9 files
Second batch of roast RT -> GH ticket migration
 12:27
12:29 AlexDani` joined 12:30 Guest78373 left, AlexDaniel left 12:31 Guest78373 joined 12:44 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined
Geth ¦ rakudo: AlexDaniel assigned to jnthn Issue Should the GitHub organization's name and logo be changed from "Rakudo Perl"? github.com/rakudo/rakudo/issues/3416 12:46
lizmat afk for some hours& 13:06
13:25 Guest78373 left
sena_kun releasable6, status 13:28
releasable6 sena_kun, Next release will happen when it's ready. There are no known blockers. 0 out of 427 commits logged
sena_kun, Details: gist.github.com/eae73ec679f04f73f8...bf2e31afe1
13:37 Guest78373 joined
AlexDaniel sena_kun: ooooooooooooooooooooooooooooooooh… 13:38
I think I found a problem…
github.com/Raku/Blin/commit/debe67...a871059269
sena_kun AlexDaniel, hmm?
AlexDaniel it should be “if not alright”
sena_kun oh 13:39
AlexDaniel so it wasn't really working since Oct 16 ?
hmm…
that's why we were not seeing any regressions from blin, ha 13:40
sena_kun AlexDaniel, so every Flapper is a potential regression then?
AlexDaniel 🥞🥞🥞 Bisecting ADT
sena_kun: yeah
sena_kun oh noes
this is not cool. :S
AlexDaniel sena_kun: just rerun it on flappers after the fix 13:41
that's my fuckup :(
sena_kun AlexDaniel, yes, going to do exactly that
sena_kun waits for the fix commit
AlexDaniel yeah… I'm in the process
ADT – Fail, Bisected: add2ec0d491218e59e6c7a517e37458e1a6c3daf 13:47
hmm :) 13:48
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:49
sena_kun 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
AlexDaniel sena_kun: oh yeah that sounds about right!
finally 13:51
sena_kun I'll re-run the flappers and create tickets...
13:52 Altai-man_ joined
AlexDaniel geez that was very stupid on my part 13:53
Altai-man_ AlexDaniel, hmm, did you push the fix?
AlexDaniel Altai-man_: not yet, hold on
Altai-man_ ah, ok
AlexDaniel testing Foo:: modules to make sure it really didn't work
13:56 sena_kun left
AlexDaniel 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
who knows*
Altai-man_ AlexDaniel, ok, I'll do another Blin run tonight, but for now can investigate ones starting from 2019.11. 13:59
AlexDaniel yeah, a quick run on just the flappers will speed things up quite a bit
Altai-man_ AlexDaniel, also you've lied to me, writing the changelog was the easiest part! :P
AlexDaniel really?
Altai-man_ yaeh
AlexDaniel I dunno… I've spent hours doing that : 14:00
:)
Altai-man_ I am much more stressed over regressions | ecosystem testing thing, really.
AlexDaniel I had a lot of fun bisecting stuff and investigating into failures
Altai-man_ maybe your changelogs are just better and made more carefully than mine. :>
I suspect it will be easier for me too with the fixed tooling 14:01
Geth Blin: 8a30528edd | (Aleks-Daniel Jakimenko-Aleksejev)++ | lib/Blin/Processing.pm6
Unbreak Blin (big oops)

This bug made all regressions appear as flappers. Oh no. It was introduced in debe6760fdafb1be4963be8f8de596a871059269.		 14:03
AlexDaniel and yeah, confirmed that it didn't work before the fix and now it does
14:20 thundergnat left
Altai-man_ >Enabled fetching backends [git path curl] don't understand www.cpan.org/authors/id/J/JN/JNTHN/...0.3.tar.gz 14:24
Xliff Um. Is there to be releasing?!
Altai-man_ dafuq is this...
Xliff, sadly, nope 14:25
our counter of potential regressions suddenly increased from 0 to 35
which is ugh
Xliff :(
Hmm... tar.gz should be curl...
14:28 lucasb joined
Altai-man_ >Enabled fetching backends [git path curl] don't understand www.cpan.org/authors/id/J/JN/JNTHN/...1.1.tar.gz 14:30
eeh
AlexDaniel “http” 14:45
freaking hell…
Altai-man_ 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 14:46
nine Shouldn't that be https anyway? 15:08
AlexDaniel of course, yes 15:09
15:13 Kaiepi joined
Xliff nine: Still see no way of getting around polling. 15:23
nine: Consider another process tree hitting the .bc.lock file
AlexDaniel Altai-man_: how is it? :) 15:41
Altai-man_ 65 out of 107 modules processed
I'll create a ticket afterwards, so no worries
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, tyilanmenyn is now known as tyil 17:52 Altai-man_ joined 17:56 sena_kun left
AlexDaniel Altai-man_: what about now? :D 17:59
yeah I'm impatient :)
Altai-man_ AlexDaniel, ⏳ 103 out of 107 modules processed (left: PDF::Lite PDF::API6 PDF::Class PDF::Font::Loader)
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
AlexDaniel no, probably dependencies waiting for PDF::Class 18:01
Altai-man_ dunno 18:02
AlexDaniel $ zef rdepends PDF::Class 18:03
PDF::API6:ver<0.1.2>:auth<github:p6-pdf>
Altai-man_ overview for the impatient ones: clbin.com/gZ200
AlexDaniel at least one
moritz m: say $*IN.lines.^name
camelia Seq
Altai-man_ ⏳ 104 out of 107 modules processed (left: PDF::API6 PDF::Class PDF::Font::Loader)
AlexDaniel PDF::Font::Loader was waiting for PDF::Lite 18:04
Altai-man_ 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...
Geth ¦ rakudo: AlexDaniel assigned to Altai-man Issue [WIP] Blin 2020.01 github.com/rakudo/rakudo/issues/3417 18:07
AlexDaniel Altai-man_: there you go :)
Altai-man_: hey I made module names clickable! 18:09
lizmat: some were bisected to your commits github.com/rakudo/rakudo/issues/3417 18:10
Altai-man_ hmm, this is really weird... 18:31
nine Xliff: I don't see where you'd have to do any polling?
Altai-man_ github.com/rakudo/rakudo/commit/aa...9388ab1890 shouldn't have sch a fallout
nine If another process hits the .bc.lock file, it will just wait for the lock 18:32
Altai-man_ 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:45
AlexDaniel Altai-man_: in the installed/ dir take a look at the output on new and old revisions 18:46
Altai-man_ ok, I'm taking my words back. :S 18:47
phew
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!
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, TreyHarris left 19:23 TreyHarris joined 19:30 patrickb left
lizmat is back 19:41
AlexDaniel: so is there something I should look at or not? 19:42
AlexDaniel I guess 19:43
lizmat github.com/rakudo/rakudo/commit/aa...9388ab1890 ?
modules.raku.org/dist/P6W looks like it doesn't even have any code ? or tests ?? yet it bisected to that commit ? 19:47
19:48 domidumont left
nine Also P6W installs just fine with zef 19:53
19:53 sena_kun joined 19:55 Altai-man_ left
lizmat .ask Altai-man_ does the release branch contain all of the .perl -> .raku changes that I did ? 20:34
tellable6 lizmat, I'll pass your message to Altai-man_
20:37 Kaiepi joined
sena_kun lizmat, yes, up to the commit where you return .perlseen method back 20:57
you can check it at github.com/rakudo/rakudo/tree/release-2020.01
lizmat 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
sena_kun no 20:59
I am not cherry-picking, but doing a rebase
Geth roast: fbf511a36c | (Elizabeth Mattijsen)++ | 16 files
Batch #3 of roast RT -> GH ticket migration
 21:02
AlexDaniel m: my $a := $::a; say $a 21:29
camelia (Mu)
AlexDaniel bisect: my $a := $::a; say $a
bisectable6 AlexDaniel, On both starting points (old=2015.12 new=ff7e17f) the exit code is 0 and the output is identical as well
AlexDaniel, Output on both points: «(Mu)␤»
AlexDaniel interesting
6c: my $a := $::a; say $a 21:30
committable6 AlexDaniel, ¦6c (40 commits): «(Mu)␤»
Geth roast: d5caf89871 | (Elizabeth Mattijsen)++ | 11 files
Batch #4 of roast RT -> GH ticket migration
 21:44
21:51 ufobat__ left 21:52 Altai-man_ joined 21:55 sena_kun left
Geth roast: bd14bc3add | (Elizabeth Mattijsen)++ | 7 files
Batch #5 of roast RT -> GH ticket migration
 22:10
lizmat that concludes my migration work of today 22:11
only 642 files to go
jnthn lizmat++ 22:17
AlexDaniel lizmat++ indeed 22:21
btw I'll mention this again: 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

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!