00:53 lucasb left 05:39 guifa2 left 05:48 pamplemousse left
nine releasable6: status 07:29
releasable6 nine, Next release will happen when it's ready. 3 blockers. 166 out of 355 commits logged (⚠ 3 warnings) 07:30
nine, Details: gist.github.com/1a61932ffc62240520...7221babcb9
nine Funny how a week ago I said that none of the release blockers look like something I'd work on, yet I fixed one anyway and have a proposed fix for another. Guess that shows that: 07:34
* you should never exclude a goal from the outset. Whatever the circumstances (like a bug only affecting Windows which I'm not interested in at all), nothing is really impossible. 07:35
moritz * you're pretty versatile :D 07:36
nine * it's very dangerous to fall into the "jnthn will fix it" trap. Yes he can and will fix everything - on an infinite time scale.
There are very few issues that really absolutely require jnthn to fix them. We should really try hard to keep him on those and fix the rest by ourselves. Most bugs will go away if only you bang your head against them long enough. 07:41
moritz * you're pretty versatile :D 07:48
sorry, double-posting by accident
nine++ # banging his head against bugs
08:17 patrickb joined
moritz hoelzro: github.com/Raku/docker/pull/28 for your pleasure :-) It seems I can now build star 2020.01, and would like to take you up on the offer to walk me through the steps of releasing 08:27
08:42 Altai-man_ joined
[Tux] WHAT HAS HAPPENED? 09:10
Rakudo version 2020.02.1-355-g6721794e4 - MoarVM version 2020.02.1-153-g9bb7a1850
csv-ip5xs0.893 - 0.911
csv-ip5xs-209.825 - 9.948
csv-parser25.651 - 25.789
csv-test-xs-200.381 - 0.384
test8.055 - 8.302
test-t2.768 - 2.778
test-t --race0.981 - 1.138
test-t-2047.695 - 48.348
test-t-20 --race13.382 - 13.500
[Tux] runs again
MasterDuke [Tux]: might be github.com/MoarVM/MoarVM/commit/6f...bccabe614c 09:18
09:20 sena_kun joined 09:22 Altai-man_ left
sena_kun [Tux], yesterday's commit has disabled inlining of particular op, alas it is a known issue, I think. 09:33
lizmat I thought nine re-inlined the dispatcher inlining / JITting ? 09:42
*restored
sena_kun lizmat, not yet? 09:44
github.com/MoarVM/MoarVM/blob/mast...plist#L887 <- it is still noinline 09:45
lizmat I though b77aa1622390b2f09473d8b846 was it
linkable6 (2020-04-25) github.com/MoarVM/MoarVM/commit/b77aa16223 Bring back a fixed JIT building block for nextdispatcherfor
lizmat ah, JITting vs inlining 09:46
sena_kun yes
lizmat, anyway, we have, I suspect, plenty of work other than this for a release. :)
lizmat severely regrets ever having merged the dispatcher code
sena_kun lizmat, people do mistakes, so don't let it let you down. 09:48
lizmat yeah, I've learned from that one 09:49
but sometimes I wonder how things would have been had I decided in 2012 to just retire, rather then getting involved again 09:50
only sometimes, though :-)
sena_kun Complexity, complexity... 09:52
How do I search if the module is on cpan? 09:56
.tell AlexDaniel gist.github.com/Altai-man/3eee8d3c...778575c623 <- this is the yesterday's blin. There are still odd false positives, new log starts with "The following candidates are already installed:" and then it contains failure which was long time fixed on module master. 09:59
tellable6 sena_kun, I'll pass your message to AlexDaniel
patrickb o/ 10:02
tellable6 hey patrickb, you have a message: gist.github.com/f62dc72d0e924ea9d2...c88df1dfdb
Geth ¦ rakudo: Altai-man assigned to lizmat Issue Blin 2020.04, round 1 github.com/rakudo/rakudo/issues/3645 10:03
patrickb .tell pamplemousse It's nice reading from you again! Welcome back! I've now read through all your module related blog posts. I've now got a clearer picture of the state of things. 10:04
tellable6 patrickb, I'll pass your message to pamplemousse
lizmat hmmm... looks like we lost Geth 10:06
sena_kun Not so many regressions, nice. Now torturing stresstest...
10:06 Geth joined
lizmat 5610764374b975516394f5 10:06
linkable6 (2020-04-26) github.com/rakudo/rakudo/commit/5610764374 Revert "Simplify iterator of Cool values"
patrickb .tell pamplemousse I'd like to have running precompiled scripts work exactly like running non-precompiled scripts. I think that's a nice intermediate step for the work on packaged executables. 10:07
tellable6 patrickb, I'll pass your message to pamplemousse
patrickb .tell pamplemousse Please keep us updated what you are working on, so we don't do duplicate work.
tellable6 patrickb, I'll pass your message to pamplemousse
nine Yeah, the performance regression is regrettable :/ But I don't think we've ever opted for "buggier but faster", have we? 10:17
lizmat nine: but going from 2.0 to 2.8 is.... a *lot* 10:20
I know it's only a single benchmark...
nine Oh I'm pretty sure it hurts us across the board
lizmat but this doesn't bode well for a lot of production cases either ?
so, before this work, arguably it was less correct (for some definition), but it had been a long standing issue 10:21
like there are quite a number of long-standing issues
and I'm not convinced that now being more correct *this way* warrants the performance loss 10:22
so, what did the dispatcher work fix that needed to be fixed so badly that we lose so much performance? 10:23
especially in the light of jnthn looking at fixing this a completely other way?
nine I'm pretty sure we don't want the regression caused by the initial fix. So it's either defering the release until jnthn's dispatcher work is ready and stable (could be months), or taking the performance hit, or backing out all the next-dispatcher work (which is non-trivial) 10:24
sena_kun lizmat, I don't think this can be simply reverted to "buggy but usual speed".
I've asked yesterday if the penalty still (was) a thing and apparently it is, so I would not release this way. To keep master ready - that's cool. 10:25
lizmat well, I don't like the prospect of 1 (no releases for months) or 2 (taking the performance hit)
so it feels to me that 3. is the only option we should be looking at 10:26
unfortunately :-(
sena_kun lizmat, can you please check stresstest on 6.c-errata?
nine Personally, I'm totally open to reverting the next-dispatcher stuff. My initial look at it just showed that reverting is quite a bit of work in itself, as this was a largish branch spread out over quite some time. And IIRC vrurg has some code requiring this fix 10:27
lizmat sena_kun: running it now 10:28
sena_kun lizmat, thanks! Want to confirm if t/spec/S32-str/encode behaves funny only for me or not.
[Tux] Rakudo version 2020.02.1-355-g6721794e4 - MoarVM version 2020.02.1-153-g9bb7a1850
csv-ip5xs0.909 - 0.927
csv-ip5xs-209.912 - 10.524
csv-parser25.716 - 25.846
csv-test-xs-200.388 - 0.414
test7.931 - 8.037
test-t2.732 - 2.770
test-t --race1.122 - 1.127
test-t-2048.085 - 49.121
test-t-20 --race13.272 - 13.825
 10:35
just as bad
lizmat [Tux]: noted :-( 10:39
sena_kun: ===SORRY!=== 10:43
chr codepoint 16777215 (0xFFFFFF) is out of bounds
other than that: a massive amount of TODO's that passed :-)
sena_kun lizmat, I wonder why I can't trigger it with `z t S32-str/encode.t`. 10:44
github.com/Raku/roast/blob/master/...r/encode.t latest commit is November.
lizmat 80dde85a665e1b9979bfe
linkable6 (2020-03-26) github.com/rakudo/rakudo/commit/80dde85a66 Tweak chr out of range error output
sena_kun So I am really confused why it isn't broken on roast master, but broken on same file, but on different branch. 10:45
lizmat well, if I remove the two lines with the "\x[FFFFFF]" codepoint, the test passes 10:48
m: "\x[FFFFFF]"
camelia ===SORRY!===
chr codepoint 16777215 (0xFFFFFF) is out of bounds
sena_kun oooh 10:49
github.com/Raku/roast/commit/1e1b9...36ef11c692
lizmat bisectable6: say "\x[FFFFFF]"
bisectable6 lizmat, Bisecting by exit signal (old=2015.12 new=5610764). Old exit signal: 11 (SIGSEGV)
lizmat, bisect log: gist.github.com/1fc47cf2e952ba1bce...4f0a5fde3b 10:50
lizmat, (2016-03-09) github.com/rakudo/rakudo/commit/e1...8dbc8531e9
sena_kun lizmat, I think jnthn's commit just uncovered this problem. I guess I'm cherry-picking 1e1b9c0db02a142526ae75318131fbf21a1d410e to 6.c-errata.
lizmat bisectable6: old=2020.01 say "\x[FFFFFF]"
bisectable6 lizmat, Bisecting by output (old=2020.01 new=5610764) because on both starting points the exit code is 1
lizmat, bisect log: gist.github.com/8bb2ba3571bf5db774...6be3fe3672
lizmat, (2020-03-26) github.com/rakudo/rakudo/commit/aa...86c95183a9
lizmat sena_kun: yeah, think that's the right approach :-) 10:51
sena_kun lizmat++, thanks!
11:01 Amabella joined 11:03 Amabella left 11:19 Altai-man_ joined
Geth z: 553ec32b16 | Altai-man++ (committed using GitHub Web editor) | lib/RDev.pm6
s/perl6/Raku/ in github urls
 11:22
11:22 sena_kun left
lizmat looking at a --profile of test-t, it's all very green and very OSR 11:22
so whatever it is slowing down, is at a lower level, which we already knew, but good to see confirmed 11:23
I'm wondering what kind of code construct would cause this slower behaviour ?
vrurg: could you enlighten us in that respect ? 11:24
Altai-man_ >error: GH006: Protected branch update failed for refs/heads/6.c-errata. You're not authorized to push to this branch 11:39
Really?
Geth roast/2020.04-patch-1: 7368901b26 | pmurias++ (committed by Altai-man) | S32-str/encode.t
Stop using invalid unicode in a string literal
 11:40
roast: Altai-man++ created pull request #637:
Cherry-pick a commit		 11:44
roast/6.c-errata: 7368901b26 | pmurias++ (committed by Altai-man) | S32-str/encode.t
Stop using invalid unicode in a string literal
 11:46
roast/6.c-errata: 2bf3c317da | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | S32-str/encode.t
Merge pull request #637 from Raku/2020.04-patch-1

Cherry-pick a commit
lizmat Altai-man_: no idea why :-(
Altai-man_ .tell AlexDaniel maybe you have ideas about github.com/Raku/roast/pull/637 ? 11:48
tellable6 Altai-man_, I'll pass your message to AlexDaniel
lizmat Altai-man_: you are in group Raku no? 11:49
Altai-man_ lizmat, sure.
Anyway, enough for this time of a day. Hope everyone can rest this Sunday. I'd anticipate a release after dispatchers overhaul. 11:51
12:28 guifa2 joined
lizmat Altai-man_: enjoy your day 12:42
Altai-man_ lizmat, you too!
nine Getting there: `{ use v5-inline; sub foo { "foo!" } }; say ::('&foo')()` will now correctly say foo! 12:50
lizmat wow!
nine It still claims Undeclared routine when just calling it by say foo() though 12:51
lizmat trivialities :-)
nine Yeah, just need to find out where else I've got to plug those subs into 12:52
guifa2 Is there ever a time that Match.to and Match.pos aren't the same? AFAICT testing they're the same 13:11
lizmat moritz might know
I've wondered that myself every now and then :-)
guifa2 I also realized that the most important feature of binex is also probably the most complex of the regex feature set: && 13:13
13:14 Catalynna joined
guifa2 Backtracking on steroids to make sure that each matches the same length 13:14
13:16 Catalynna left 13:21 sena_kun joined 13:22 Altai-man_ left
moritz have you checked inside look-behind assertions? 13:22
guifa2 moritz: aaaah that makes sense 13:23
guifa2 hasn't gotten to lookahead/behinds yet in Binex :-)
moritz TBH I haven't thought this through, it's just a shot in the dark
also, )> maybe
m: say 'abc' ~~ / a )> b { say $/.pos; say $/.to } / 13:24
camelia 2
1
｢a｣
moritz hah, found it :D
guifa2 moritz: I may be bugging you more later as polish things up so I can make sure I'm doing everything as close to regex as possible. You've been warned ;-) 13:26
moritz guifa2: then let me warn you that I've never written a regex engine .D 13:29
guifa2 moritz: you've not written one but you uh, kinda wrote the book on using them :-) 13:35
moritz so they say. 13:55
lizmat afk for a few hours& 14:14
14:17 guifa2 left 14:58 pamplemousse joined
nine And now I've got this working as well :) { use v5-inline; sub foo { "foo!" } }; say foo; 14:59
patrickb o/ pamplemousse 15:10
pamplemousse o/ patrickb
tellable6 2020-04-26T10:04:44Z #raku-dev <patrickb> pamplemousse It's nice reading from you again! Welcome back! I've now read through all your module related blog posts. I've now got a clearer picture of the state of things.
2020-04-26T10:07:16Z #raku-dev <patrickb> pamplemousse I'd like to have running precompiled scripts work exactly like running non-precompiled scripts. I think that's a nice intermediate step for the work on packaged executables. 15:11
2020-04-26T10:07:58Z #raku-dev <patrickb> pamplemousse Please keep us updated what you are working on, so we don't do duplicate work.
timotimo impressive, nine
nine So...after just 5 years Inline::Perl5 can actually do inlined code :D 15:15
pamplemousse It’s nice to be back! It's been a bit; I've been settling into work and post-school life and got a bit bogged down with things. 15:16
I just moved and am having a bit of trouble locating my computer, but I’ll hopefully find that while unpacking today and be able to get the executable branch I was working on up to date with the current Rakudo and NQP master branches.
nine++, that's really cool 15:18
15:19 Altai-man_ joined 15:22 sena_kun left
AlexDaniel . 15:34
tellable6 2020-04-26T11:48:09Z #raku-dev <Altai-man_> AlexDaniel maybe you have ideas about github.com/Raku/roast/pull/637 ? 15:35
hey AlexDaniel, you have a message: gist.github.com/68f36398b027cbcd10...09de2491e4
AlexDaniel Altai-man_: your role in the Raku org was “Member” 15:36
Altai-man_: now I changed it to “Owner” 15:37
Altai-man_: I have a feeling that you never had access to do that, surprisingly. The branch was protected for more than a year 15:39
but yeah, obviously not right, should be fixed now, let me know if you have any other access issues
Altai-man_: btw you can use `--new=HEAD` 15:43
Altai-man_: that unicode issue is R#3636 15:45
linkable6 R#3636 [open]: github.com/rakudo/rakudo/issues/3636 [BLOCKER][Unicode] uniname on numerics vs on strs (.chr is now a bit too sensitive?)
nine lizmat: now that I've got inline blocks merged, I've released Inline::Perl5 0.48 with your renaming commit :) 16:04
Altai-man_ AlexDaniel, odd, I certainly pushed commits there, maybe it was perl6 org, not Raku one. But glad to have it fixes, thanks! 16:10
AlexDaniel Altai-man_: I checked, you had the same role in both
I changed it to Owner in both too, just in case
Geth ¦ problem-solving: JJ assigned to AlexDaniel Issue Give Travis.com permission to access raku-community-modules repositories github.com/Raku/problem-solving/issues/179 16:58
17:20 patrickb left, sena_kun joined 17:22 Altai-man_ left
lizmat nine++ 17:53
m: dd 1,2,3 ... { IterationEnd } # should we allow this? Or is this a case of DIHWIDT ? 17:56
camelia (1,).Seq
vrurg lizmat: I just came and saw your question. But can't get the context. 18:07
lizmat we'er currently not inlining the dispatch stuff anymore, as it apparently borks on WIndows 18:08
this caused test-t to drop from ~2 to ~2.8 seconds
and I was wondering what would make test-t so vulnerable to this drop as I don't see that much of a drop in e.g. "make spectest" 18:09
vrurg I never dealt with test-t, can't guess what could be the cause. 18:10
lizmat it does a lot of postcircumfix:<[ ]> 18:11
in any case, the options now are: 1. release with this performance loss, 2. wait for jnthn to re-design and re-implement dispatch (several months delay) or 3. rip out the new dispatcher stuff you made 18:13
option 1 possibly hurts people using it in production, but 3 may also, right vrurg ? 18:14
vrurg I can only think of two possible causes: a lot of calls to tiny functions. Especially, first calls onlystars where it redelegates upstream nextdisaptcher to the first invoked candidate.
lizmat things like "nextsame" and so? 18:15
vrurg My code depending on this is not in production. But I'm preparing it for the TPCiC.
lizmat: nextsame doesn't use it directly, it's metamodel dispatching code which needs it to build correct chain of calls. 18:17
AlexDaniel are there any significant improvements since the last release? 18:18
lizmat changelog draft mentions a few ?
vrurg lizmat: Basically, without proper dispatching I would have to pull out my talk and basically shutdown my Vikna project for indefinite period of time or re-write it for using plain inheritance and no roles whatsoever. 18:20
AlexDaniel there's always a lot of small stuff that adds up, but I don't see anything big that stands on its own
lizmat vrurg: understood 18:21
so I guess it's going to be 2 and not have a release for several months :-(
MasterDuke was there some reason we couldn't release from a known-good commit right before the dispatch merge? 18:22
vrurg Either option is terrible to me. I wouldn't be able to choose. 18:23
AlexDaniel if that's the decision I'll be able to fix whateverable/blin in 1-2 days so that it's possible to test branches
hmmm why isn't it already doing that btw 18:33
lizmat afk& 18:34
AlexDaniel let's see… 18:35
cc44b48b443
cc44b48b443066
hmm
committable6: cc44b48b443066 say 42
committable6 AlexDaniel, ¦cc44b48: «Cannot find this revision (did you mean “fcfd51b”?)»
AlexDaniel there is a build for that 18:36
shareable6: cc44b48b443066
shareable6 AlexDaniel, whateverable.6lang.org/cc44b48b443066
AlexDaniel yeah except it ignores it altogether
jnthn vrurg: Ultimately, Raku performance is hugely dependent on inlining, and anything that blocks that is going to cause significant preformance issues. 18:51
vrurg: What's not quite clear to me is why we can't inline takenextdispatcher; does it depend on anything other than the immediate caller setting it? 18:52
vrurg jnthn: I tried making the optimizer support takenextdispatcher same way as takedispatcher. But, apparently, with no success. 18:54
Basically, set/takenextdispatcher do the same what setfor/takedispatcher do, just with different data. 18:55
jnthn What was the failure mode? New behavior didn't work as expected, or existing behavior didn't work as expected? 18:56
vrurg R#3569 is a related one. 18:57
linkable6 R#3569 [open]: github.com/rakudo/rakudo/issues/3569 [BLOCKER][MoarVM][regression] &nextcallee can misbehave with wrapped routines in threaded code
19:19 Altai-man_ joined 19:22 sena_kun left
Altai-man_ lizmat, when you referring to a "several months delay", do you mean re-designing/re-implementing dispatchers would take a couple of months or that last release was February? 19:22
vrurg Altai-man_: the former. 19:23
Altai-man_ Ouch. I was thinking about a couple of weeks, not months. 19:24
vrurg Altai-man_: as far as I understand, the work isn't even started yet unless jnthn has other new.
*news
Altai-man_ vrurg, what's the TPCiC date?
vrurg Altai-man_: Jun 24. 19:25
24-26
vrurg is afk 19:26
Altai-man_ AFAIK, dispatcher patches were merged quite early after 2020.02 (we don't count 2020.02.1, it's the same). The release was Feb 23 and github.com/rakudo/rakudo/pull/3500 was already on Feb 26 and then there are subsequent PRs which are not so far away. 19:30
Altai-man_ backlogs
nine The takenextdispatcher issue is not what broke Windows. That was just a sublte error in the JITing of nextdispatcherfor (a related op) which is fixed with no down sides. 19:47
Altai-man_ writes up a proposal
nine I marked takenextdispatcher :noinline because of #3569
That the redesign of dispatching jnthn is working on may take months is just my guess based on it already being a while in the works, it's intrusiveness into some of the most central and important areas and that we want it to be as stable a the previous stuff when we release. 19:48
Of course I wouldn't put a miracle past jnthn :) It may also be done in 2 weeks, but I wouldn't want to put that kind of pressure on him 19:49
From what I've seen making takenextdispatcher :noinline hurts so much because it's practically everywhere. I've seen it even in a spesh log of method sink. So if not even that can be inlined, few things can. 19:50
MasterDuke i think jnthn said the design was nearly done, and he hoped to have a bunch of next week to work on it 19:51
nine Personally I'm leaning towards taking that performance hit and releasing what we have. Yes, it looks bad, but there are so many cases where even 25 % don't cause much of an issue. For us at work, reliability is currently much more important. 19:53
If jnthn's work goes much faster than I fear, we can always do another release quickly
Don't forget that people usually have a choice. If the slowdown is inacceptible, they may just chose to stay on 2020.02.1 19:54
Altai-man_ gist.github.com/Altai-man/433f3314...e255533eb3 19:55
.tell vrurg gist.github.com/Altai-man/433f3314...e255533eb3
tellable6 Altai-man_, I'll pass your message to vrurg
Altai-man_ ^ is my proposal of what to do, comments are welcomed.
20:00 lucasb joined
jnthn The design might be nearly done, or it might be "I did the first 80% and the second 80% is to come"... :-) And of course, then we'll have to see how well it copes with reality once implementation gets underway. This is the kind of area where the academic folks are still writing research papers, and none of those that exist (that I'm aware of) cover all of the problems we have. 20:00
I should be able to give a better estimate of "just how much work is it" by the end of next week, and hopefully have a bunch of implementation progress to base that on. 20:01
Altai-man_ jnthn, what are your thoughts on ^?
nine got a laugh out of discovering the subtle typo he made in "sublte" 20:02
jnthn I'm curious: I thought there was a part-way state on the dispatcher stuff vrurg++ did that didn't involve the new MoarVM ops, but used dynamic variables. What were the performance measurements on that? I'm kind of guessing those didn't prevent inlining. 20:07
In which case there's a partial revert option too that might give better dispatcher behavior and tolerable slowdown 20:08
AlexDaniel committable6: cc44b48b443066 say 42 20:16
committable6 AlexDaniel, ¦cc44b48: «Cannot test this commit (Commit exists, but an executable could not be built for it)»
AlexDaniel hmmm
that's probably right
committable6: rakuast say 42
committable6 AlexDaniel, ¦rakuast: «Cannot find this revision (did you mean “Prague”?)»
AlexDaniel hmm 20:17
committable6: a757328bdd2 loop (my $x = 0, $x < 10, $x++) {} 20:18
committable6 AlexDaniel, gist.github.com/899ae2268897fb1e48...6625c4352d
AlexDaniel committable6: a757328bdd2 loop (my $x = 0; $x < 10; $x++;) {}
committable6 AlexDaniel, gist.github.com/87a4ae9ff5b6f06532...abc877f239
AlexDaniel okay, so that's easy 20:19
now a little bit of hackety-hacking and it'll work
it's kinda funny, all this time whateverable was building all branches 20:20
but bots were simply not seeing the commits so it wasn't possible to use these builds
heh
jnthn That "did you mean" is amazing :D 20:37
Altai-man_ >2015-07-24 Rakudo #90 "Prague" (masak) 20:40
AlexDaniel c: Prague say 42 20:43
committable6 AlexDaniel, ¦Prague: «42␤»
AlexDaniel not only it's amazing, it's actually correct :) it's very likely that Prague is indeed the closest match to rakuast 20:45
it's kinda weird for it to base its guess on three letters but hey, better than nothing I guess :) 20:46
though my favorite is this one:
c: cycle say 42
committable6 AlexDaniel, ¦cycle: «Cannot find this revision (did you mean “v6.c”?)»
AlexDaniel hmmm
I wonder if it's smart enough to ignore Bicycle 20:47
c: Bicycle say 42
hello?
committable6: help
committable6 AlexDaniel, Like this: committable6: f583f22,HEAD say ‘hello’; say ‘world’ # See wiki for more examples: github.com/Raku/whateverable/wiki/Committable
AlexDaniel c: Bicycle say 42
:S
committable6: Bicycle say 42
fail 20:48
MasterDuke sift4 gives a distance of 4 for rakuast and prague, levenstein give 5 20:49
committable6 AlexDaniel, ¦Bicycle: «No build for this commit» 20:52
timotimo needs .pm?
committable6 AlexDaniel, ¦Bicycle: «No build for this commit»
timotimo ah, probably not 20:53
21:20 sena_kun joined 21:22 Altai-man_ left
AlexDaniel weeeird. 21:25
well, at least it works…
vrurg jnthn: Unfortunately, the work based on dynamic variables was a dead end because then next dispatcher was propagated into unrelated code. So, set/takenextdispatcher ops was the only solution, 21:43
tellable6 2020-04-26T19:55:30Z #raku-dev <Altai-man_> vrurg gist.github.com/Altai-man/433f3314...e255533eb3
vrurg is afk again, was just passing by...
jnthn vrurg: Thanks for explaining. 22:08
22:09 dogbert11 joined 22:38 Kaiepi left, Kaeipi joined 22:53 MasterDuke left
AlexDaniel committable6: master say 42 23:04
committable6 AlexDaniel, ¦master: «42␤»
AlexDaniel huh
23:11 Kaeipi left 23:14 Kaiepi joined 23:19 Altai-man_ joined 23:22 sena_kun left
hoelzro moritz: excellent! I'll have a look at that PR, but I'm afraid I don't have time for the walkthrough atm (and it's probably a little late for you!); what day/time would work for you? 23:23
23:49 lucasb 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!