00:37 releasable6 left, bisectable6 left, nativecallable6 left, quotable6 left, evalable6 left, sourceable6 left, unicodable6 left, coverable6 left, linkable6 left, tellable6 left, reportable6 left, committable6 left, squashable6 left, notable6 left, benchable6 left, greppable6 left, bloatable6 left, shareable6 left, statisfiable6 left 00:48 finsternis joined 01:12 Xliff joined
Xliff \o 01:14
I know its late. Has there been any progress of getting Raku to pre-compile in parallel?
I still haven't gotten back to my work on removing the .precomp lock. So busy with other things. 01:15
I hope to get back to it before May ends.
01:33 pamplemousse left 01:35 Xliff left 03:56 commavir left 03:57 commavir joined 06:00 AlexDaniel joined 06:01 AlexDaniel left, AlexDaniel joined 06:19 jjmerelo joined
jjmerelo Morning 06:19
AlexDaniel o/ 06:47
Geth rakudo: 5644c709a7 | (Jeremy Studer)++ (committed by Aleks-Daniel Jakimenko-Aleksejev) | src/core.c/Kernel.pm6
Simplify Kernel signals method using Signal values

The Kernel signals method previously had a lot of logic for determining signal values on the host system and backends. Now that that logic is encapsulated into the getsignals ops, this method can be greatly simplified.
Closes #1901.
AlexDaniel I'd love to know why github doesn't know how to merge something even if locally there's no problem at all 06:54
is it using some different merge strategy or something?
[Tux] Rakudo version 2020.02.1-388-g3d2522eed - MoarVM version 2020.02.1-163-g8b109c68b
csv-ip5xs0.831 - 0.882
csv-ip5xs-207.818 - 9.508
csv-parser23.511 - 26.452
csv-test-xs-200.381 - 0.406
test7.746 - 7.786
test-t1.980 - 2.021
test-t --race0.851 - 0.969
test-t-2031.823 - 33.146
test-t-20 --race9.780 - 9.930
MasterDuke didn't git change its default merge strategy recently? maybe github just hasn't caught up yet 07:01
Geth rakudo: 89e570c2b0 | cygx++ (committed by Aleks-Daniel Jakimenko-Aleksejev) | lib/NativeCall.rakumod
Let NC map int to longlong

While `int` in nativecall declarations might be somewhat confusing, mapping it to the same thing as p6-land native `int` would be consistent - in normal situation, `int` would just be an alias for
  `int64` and `num` for `num64`.
On 'mainstream' architectures, this patch should be enough to do it, possibly there will be a better solution in the future.
Closes #572.
MasterDuke how do you view conflicts on github? 07:12
AlexDaniel MasterDuke: hahahahahahah 07:14
MasterDuke: most of the time you can't 07:15
MasterDuke huh
AlexDaniel but sometimes it even lets you fix conflicts on github via their web ui
jjmerelo MasterDuke only when the file name has not changed 07:16
MasterDuke oh, that's probably the only conflict with github.com/rakudo/rakudo/pull/1791 then 07:17
jjmerelo MasterDuke right. core -> core.c
Also, AppVeyor fails in many outstanding PRs. Should we pay any attention to it at all? 07:18
MasterDuke anyone mind if i do the merge manually then? and change the one test description, or is that bad form?
jjmerelo MasterDuke I don't mind... It's probably the best to save that PR. 07:19
AlexDaniel MasterDuke: lately I tend to do `wget github.com/rakudo/rakudo/pull/1791.patch` then git am -3 < 1791.patch 07:22
MasterDuke i just ran the command they showed 07:23
AlexDaniel honestly I don't care as long as you close these PRs 07:24
MasterDuke the only difference is you're keeping the patch around?
AlexDaniel MasterDuke: well, this way I can easily just change the patch if it doesn't apply cleanly, and I'm also not merging a branch from two years back (so git log should remain pretty) 07:25
but there are many ways to do it, as long as you feel comfortable it'll be ok 07:26
MasterDuke: also, whatever you do it'll likely not close the original PR, so include `Closes #…` in your commit message or close it manually 07:31
MasterDuke k
jjmerelo AlexDaniel++ with the issue closing. 07:37
I mean, some are so simple that I don't really understand why they remained there for so long...
Geth rakudo: b02a741398 | vendethiel++ (committed by Daniel Green) | 2 files
GH#1758: Only suggest a submethod if it's local

This avoids us suggesting a submethod from a parent class, which would always result into an error.
rakudo: cc10570da5 | (Daniel Green)++ | 2 files
Merge branch 'vendethiel-bugfix/gh-1758'

Fixes #1873 and closes #1791
07:58 Altai-man_ joined
Geth rakudo/sumanstats-master: 9a0aa98871 | (JJ Merelo)++ | README.md
Fixes conflict
rakudo: JJ++ created pull request #3662:
Changes to README.md
lizmat Files=1305, Tests=111241, 213 wallclock secs (28.94 usr 8.29 sys + 3002.44 cusr 276.02 csys = 3315.69 CPU) 08:10
Geth rakudo: 9a0aa98871 | (JJ Merelo)++ | README.md
Fixes conflict
rakudo: 0a3f4f95f6 | (JJ Merelo)++ | README.md
Small changes to README.md, fixes conflict

Closes #3125
rakudo: 2c9168b9ad | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | README.md
Merge pull request #3662 from JJ/master

Changes to README.md
AlexDaniel lizmat: take a look at github.com/rakudo/rakudo/pulls?q=i...dated-desc :) 08:12
lizmat: maybe there's something that is a LHF for you
lizmat are we ok to commit wrt the release ?
AlexDaniel lizmat: too late, we're already committing like crazy 08:13
lizmat *sigh*
AlexDaniel so releasing from a branch is the way
lizmat: come on, it's a rare occurance that people get motivated to work on old PRs 08:14
lizmat & 08:15
lizmat starts working on the RWN first and hopes to be able to mention a new release in it 08:50
08:58 sena_kun joined 08:59 Altai-man_ left
lizmat m: my @a = ^5; @a[2]:delete; my @b is default(42) = @a.reverse; dd @b[2] # should this be Any or 42 09:08
camelia Any @b = Any
lizmat m: my @a = ^5; @a[2]:delete; dd @a.reverse 09:09
camelia (4, 3, Any, 1, 0).Seq
lizmat m: my @a = ^5; @a[2]:delete; $_ = 42 for @a.reverse; dd @a
camelia Array @a = [42, 42, 42, 42, 42]
lizmat seeing this, I'm starting to lean towards .reverse always deconting and returning Nil for holes 09:10
09:12 jjmerelo left
jnthn Why would reverse decont? 09:21
A deleted slot is ordinarily assignable
Not sure about the wisdom of 89e570c2b0 09:25
AlexDaniel m: use NativeCall; say nativesizeof(int) 09:31
camelia 8
AlexDaniel jnthn: see github.com/rakudo/rakudo/pull/572
IMO it's wrong either way
lizmat 89e570c2b0 09:32
AlexDaniel but now it's right for more people, I guess
lizmat: the bots are down, I'm working on it
lizmat ok
jnthn Well, the point of the original choice was that `int` was likely to get you what `int` means in C, for those just naively translitting signatures. 09:34
lizmat jnthn: in the example, @a contains an nqp::null. normally, AT-POS would return a container for it so you can assign into the array. Because .reverse does that now as well, the nqp::null does not get bound to @b, so its observed value becomes Any, rather than 42
jnthn e.g. a "pit of success" thing
lizmat if you think the current behaviour is ok, then we're fine
jnthn lizmat: ah, hm, it's kinda more complicated 09:35
AlexDaniel jnthn: if you feel strongly about it we can revert it, but IIRC you should never use `int` in signatures anyway
which also kinda means that you can never get your signatures right if you're dev-ing for multiple platforms…
that's something I stumbled upon years ago, maybe there were improvements for that meanwhile, I don't know
jnthn The "can never use `int` in signatures" was also never something I was that thrilled about, for the very reason you mention. The original idea was that int mapped to the current platform's notion of int. 09:36
AlexDaniel jnthn: what about nativesizeof(int) returning 8? 09:39
jnthn That's inconsistent, and probably what should be fixed.
09:39 jjmerelo joined
AlexDaniel jnthn: okay, so what about `my int @a`, should that give you an array of 32-bit ints? 09:41
09:44 reportable6 joined, releasable6 joined, shareable6 joined, sourceable6 joined, committable6 joined, coverable6 joined, statisfiable6 joined 09:45 bloatable6 joined, squashable6 joined, evalable6 joined, quotable6 joined, benchable6 joined, bisectable6 joined, nativecallable6 joined 09:46 linkable6 joined, unicodable6 joined, tellable6 joined 09:47 notable6 joined
AlexDaniel 89e570c2b0 09:47
linkable6 (2015-11-04) github.com/rakudo/rakudo/commit/89e570c2b0 Let NC map int to longlong
AlexDaniel lizmat: fixed, thanks!
09:48 greppable6 joined
lizmat yw :-) 09:48
jnthn AlexDaniel: No, because that's nothing to do with nativecall 09:52
CArray[int], on the other hand, probably should. 09:53
AlexDaniel jnthn: in the PR people were making a point that maybe we should have a “cint” which can deconfuse things a little bit 09:55
jnthn: anyway, can you revert it then?
jnthn Um, well, my expectation is that people who merge PRs take responsibility for that action. 10:06
Thus why I only merge those I've had time to carefully look through.
And feel comfortable about.
AlexDaniel no problem, I can revert too 10:07
jnthn Thanks
I finally have a week with a load of time to work on implementing the MoarVM dispatcher stuff, and waking up to a flood of emails about PRs that I maybe should pay attention to was like...urgh. :) 10:08
I mean, I kinda appreciate the enthusiasm, but I worry it'll lead to hasty/bad decisions.
Geth rakudo: c362bd8295 | (Aleks-Daniel Jakimenko-Aleksejev)++ | lib/NativeCall.rakumod
Revert "Let NC map int to longlong"

This reverts commit 89e570c2b0bdec925aa758cca35bbebe6b0811f1.
See the discussion on
Basically, we'll probably need a problem-solving ticket to figure out what `int` should mean in different contexts and whether we need something like `cint` to express what `int` means in C.
AlexDaniel jnthn: ↑ I hope this makes sense
jnthn Yes, that summarizes it well. Thanks.
MasterDuke jnthn: btw, did you mean to comment on github.com/rakudo/rakudo/pull/2737 ? 10:10
jjmerelo ... and we're down to 90 PRs :-) github.com/rakudo/rakudo/pulls Thanks everyone!
jnthn MasterDuke: haha, what happened there? I was just looking for a commit to link to... 10:11
MasterDuke heh
jjmerelo jnthn MasterDuke ran the benchmarks, it was no longer needed, it was closed 10:12
jnthn Yes, but since it was almost certainly changes I did a month or so back that led to the improvement, I thought I'd link them. :) Done now. 10:13
Geth ¦ problem-solving: AlexDaniel assigned to jnthn Issue What should be the size of `int`? (and other NativeCall type issues) github.com/Raku/problem-solving/issues/182 10:14
AlexDaniel jnthn: ↑ also this 10:15
jnthn Thanks.
AlexDaniel jnthn: thanks for the help, btw 10:16
Geth ¦ problem-solving: AlexDaniel assigned to jnthn Issue What should unicode subscripts do? (and should they do anything at all?) github.com/Raku/problem-solving/issues/183 10:24
AlexDaniel here's an interesting aspect regarding permissions: github.com/Raku/problem-solving/is...-623387149 10:35
jnthn: ↑ take a look perhaps
feel free to slap me if what I'm doing is wrong 10:36
it looks like this: github.com/rakudo/rakudo/settings/access
nine Oh, speaking of, AlexDaniel could you please give me admin permissions to rakudo/rakudo? Can't remember any specifics right now but from time to time I stumble over not having them 10:40
AlexDaniel nine: done 10:43
nine thanks :)
AlexDaniel github is now adding more levels so maybe eventually it'll be more fine-grained
Geth rakudo/master: 5 commits pushed by ribbon-otter++, (Juan Julián Merelo Guervós)++
AlexDaniel but webhooks and stuff is not available for the `Maintain` level and there's nothing in between
10:45 robertle joined 10:49 robertle left 10:56 Altai-man_ joined 10:59 sena_kun left
Geth ¦ problem-solving: AlexDaniel assigned to jnthn Issue Should ¿? and ¡! be an alternative to "" ? github.com/Raku/problem-solving/issues/184 11:23
AlexDaniel m: CATCH { when X::Y {} } 11:35
camelia 5===SORRY!5===
Function 'X::Y' needs parens to avoid gobbling block (or perhaps it's a class that's not declared or available in this scope?)
at <tmp>:1
------> 3CATCH { when X::Y {}7⏏5 }
Missing block (apparently claimed by 'X::Y')…
Geth rakudo: dac68b27b3 | ribbon-otter++ | CONTRIBUTING.md
Replace `RT #12345` with `#12345`. Explain `RT`

The previous version caused me to think that `RT` was just the prefix that goes before issue numbers. I only learned the true meaning from when zoffixznet kindly informed me of it. Hopefully, changing the examples and adding an explanation will prevent future misunderstandings of this sort.
rakudo: 10a8f6a20f | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | CONTRIBUTING.md
Fix links

And update some text in the process.
rakudo: d6576888a1 | (Juan Julián Merelo Guervós)++ (committed using GitHub Web editor) | CONTRIBUTING.md
Merge pull request #2226 from ribbon-otter/contributing-fix

Update CONTRIBUTING.md with regards to prefix `RT`
jjmerelo Open PRs in rakudo/rakudo is down roughly 20% since yesterday. Can we clear the backlog? Yes we can! (y) <3 12:00
(at least a tiny bit)
lizmat notable6: weekly 12:07
notable6 lizmat, 3 notes: gist.github.com/ce722ac87f7bee6854...a50c6824eb
lizmat notable6: weekly reset 12:10
notable6 lizmat, Moved existing notes to “weekly_2020-05-04T12:10:10Z”
[Coke] I have received JJ Merelo's CLA. 12:40
AlexDaniel [Coke]: thank you 12:47
jnthn: can you add jmerelo then? ↑
jnthn: github handle is @JJ 12:48
jjmerelo (y) <3
12:48 pamplemousse joined 12:54 jjmerelo left
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/05/04/2020-...community/ 12:56
12:57 sena_kun joined 13:00 Altai-man_ left
[Tux] nothing on the slowdown in this weekly? 13:03
lizmat first item in core developments 13:10
AlexDaniel nine: so regarding your comment wrt symlinks, did you delete it? It left me and lizmat a bit confused. Do I understand it right that there's no issue with symlinks because .f will actually be True anyway?
nine: I have to admit that for a moment it made me go “oh shit” too :) 13:11
[Tux] Ah, I didn't make the link 13:13
nine Oh, sorry about that. That comment was plain wrong
lizmat *phew*
nine I did test it, but of course the symlink I tested with was pointing at a directory :) 13:14
AlexDaniel nine: ok! Good attention to detail anyway, thanks! 13:15
Geth rakudo: 4278e4c28f | (Ray Perry)++ | 2 files
Issue #2092 | Clarify detached method error messaging.

Originally, this error said "only alphabetic methods may be detached" but those aren't the only methods that can be detached. The new messaging is a bit clearer on valid detachment candidates.
rakudo: ee22c2ef48 | (Aleks-Daniel Jakimenko-Aleksejev)++ (committed using GitHub Web editor) | 2 files
Merge pull request #3204 from RayMPerry/enhancement/2092-detached-method-error-messaging
linkable6 RAKUDO#2092 [open]: github.com/rakudo/rakudo/issues/2092 [Hacktoberfest][LTA][easy to resolve][good first issue] "only alpha methods may be detached" message could be a bit clearer/accurater
lizmat afk for a few hours& 13:28
AlexDaniel > I can't imagine contemplating such an invasive refactoring inside MoarVM as proposed here unless you had stellar certainty the finished product would be rock solid. 13:38
interesting comment
MasterDuke it's true though. and it makes experimenting a lot more fun (especially since my new cpu runs a spectest so much faster), since i'm assured of getting good feedback on my changes 13:41
jnthn Between all the tests + being able to run them with spesh stressing + blin, we're in a fairly decent place to detect regressions. 13:42
sena_kun AlexDaniel, link?
AlexDaniel sena_kun: www.reddit.com/r/rakulang/comments...rthington/
jnthn vrurg: Hmm, I'd not noticed until now but when I make a change in NQP, it only seems to recompile stage 2 from the point of the change I made onward. It used to recompile the whole of stage 2 unconditionally, so you could spot if you broke the code-gen... 13:43
nine Well the comment is in the context of having a fantastic test suite 13:44
AlexDaniel btw if anybody feels like helping me with getting bisectable to dive into nqp and moarvm bumps, please don't hesitate :) It'd make hacking on moarvm maybe even more fun
vrurg jnthn: It was intentional implementation but seemingly wrong. Ok, noted. 13:51
jnthn: Just to make sure: its ok to rebuild stage 1 partially but always full rebuild of stage 2. 13:53
nine vrurg: yes
vrurg Heh... nine – thanks!
nine vrurg: the point of the stages is to end up with a compiler that is compiled by itself. Stage 0 is the old compiler, stage 1 is the new compiler compiled with the old compiler, stage 2 is the new compiler compiled by the new compiler.
jnthn Indeed, it's a kind of "I didn't screw up compiling the compiler" validation :) 13:54
tbrowder nine: i have a short test case that fails when using Inline::Perl5. it is using the perl Excel::Writer::XLSX module which a pretty big one.
[Tux] so in fact it is not really a small test case :) 13:55
vrurg It just never crossed my mind that stage 2 is a tests itself.
nine tbrowder: that reminds me.... I think there is a known issue related to AUTOLOAD on that module.
tbrowder well, the script is small, but the perl is deep ;-) 13:56
but i have been able so far to use much of the module. the current problem is in setting format for font name and size. either one causes a core dump. i have tried using the Scalar as first arg but no help. 13:59
nine That does sound like the AUTOLOAD issue 14:01
vrurg jnthn: BTW, does anybody test Comma on macOS? When I'm trying to debug with a breakpoint the thing I get reproducibly is it hits the bp for the first time, then I resume and get 'marking thread 6 unblocked, but its status is already NONE.'
tbrowder i don't see an issue posted about that.
i need to check closed though..l 14:02
nada 14:06
nine I think I've so far gotten two emails and now an IRC message about this ;) 14:09
jnthn vrurg: Hm, that messages comes from the debug server in MoarVM (plus it'd surprised me if it were macOS-specific, though stranger things have happened...) 14:10
vrurg jnthn: I just cannot try it anywhere else yet. 14:11
tbrowder nine: yep, i see autoload being used in the format modue. is there any way to handle that with inline::perl5? 14:13
nine tbrowder: how about a deal? You write a reduced test case that doesn't rely on any installed module and I write a fix? 14:14
vrurg jnthn: And another thing. comma fails to access the marketplace. Don't know if its on purpose, but I think the cause is in the request url it is using: plugins.jetbrains.com/api/search?o...&max=9 – the server replies with empty list and I think this is due to it not knowning about such build 'CT-2020.4'. 14:16
sena_kun vrurg, that's a sad known bug. :S 14:19
tbrowder hm, it sounds like a good deal if i knew how to start. so the perl code has to originate in the test script itself... i'll try to give it a shot. thanks!
vrurg sena_kun: a tolerable one. Wish I have the debugging work as this is the only thing holding me back from buying comma. 14:22
Geth nqp/new-disp: 29f2695491 | (Jonathan Worthington)++ | src/vm/moar/QAST/QASTOperationsMAST.nqp
Basic compilation of new dispatch operation
vrurg jnthn++ Yes! :D 14:36
jnthn vrurg: Is the debugging issue reproducible with something publicly available (or that can be privately shared)? 14:40
vrurg jnthn: yes, but I'd have to commit latest changes eventhough they're incomplete. Will submit later today. 14:42
jnthn vrurg: Thanks.
Geth rakudo/awesome-malformed-loops: d3c3e5346e | (Aleks-Daniel Jakimenko-Aleksejev)++ | src/Perl6/Grammar.nqp
Awesomify “malformed loop spec” errors

This is a questionable fix for RT #127857.
Makes each parse of a loop construct 0.04 ms slower. So if you have one hundred 「loop」-s in your code, that's already about four milliseconds slower.
Also breaks one 6.c-errata test that checks for “loop spec” text.
14:56 Altai-man_ joined
tbrowder nine: i just noticed if i use the alternative format setting syntax i don't get a core dump. does that still mean an autoload problem? 14:57
i'll show the working syntax in the issue description. 14:58
14:59 sena_kun left 15:10 jjmerelo joined
tbrowder nine: is it ok to put a very stripped down version of Excel::Writer::XLSX in your test dir where the other perl modules are? 15:46
Altai-man_ By the way, can anyone check github.com/rakudo/rakudo/wiki/ChangeLog-Draft for sanity? I am not really sure if changes to e.g. Rakudo::Iterator should be internal or public or if VM.request-garbage-collection is public or not. 15:47
Any suggestions are welcome.
nine tbrowder: if it's stripped down to only the parts really needed to reproduce the issue, then it's certainly welcome to t/lib 15:48
tbrowder okey dokey, thnx 15:49
jjmerelo Altai-man_ it looks fine.
Geth rakudo: d3c3e5346e | (Aleks-Daniel Jakimenko-Aleksejev)++ | src/Perl6/Grammar.nqp
Awesomify “malformed loop spec” errors

This is a questionable fix for RT #127857.
Makes each parse of a loop construct 0.04 ms slower. So if you have one hundred 「loop」-s in your code, that's already about four milliseconds slower.
Also breaks one 6.c-errata test that checks for “loop spec” text.
rakudo: 1a536ca9db | (Aleks-Daniel Jakimenko-Aleksejev)++ (committed using GitHub Web editor) | src/Perl6/Grammar.nqp
Merge pull request #1188 from rakudo/awesome-malformed-loops
roast/6.d-errata: 1b0b309937 | (Aleks-Daniel Jakimenko-Aleksejev)++ | S32-exceptions/misc.t
More tests for malformed `loop`s

See rakudo/rakudo#1188.
linkable6 RAKUDO#1188 [closed]: github.com/rakudo/rakudo/pull/1188 [has conflicts] Awesomify “malformed loop spec” errors
Geth roast/6.c-errata: 2a74a21955 | (Aleks-Daniel Jakimenko-Aleksejev)++ | S32-exceptions/misc.t
Make malformed loop tests less specific

Recent rakudo versions print some extra info on what went wrong.
AlexDaniel` whoops, I did it, folks! 16:01
I pushed into 6.d-errata what I meant to push into master
nevermind will fix soon… 16:02
Geth roast: 212042d578 | (Aleks-Daniel Jakimenko-Aleksejev)++ | S32-exceptions/misc.t
More tests for malformed `loop`s

See rakudo/rakudo#1188.
linkable6 RAKUDO#1188 [closed]: github.com/rakudo/rakudo/pull/1188 [has conflicts] Awesomify “malformed loop spec” errors
nine Nothing a force push can't fix... 16:03
Geth roast/6.d-errata: 71ed05cec3 | (Aleks-Daniel Jakimenko-Aleksejev)++ | S32-exceptions/misc.t
Revert "More tests for malformed `loop`s"

This reverts commit 1b0b3099371bbc46ac5fe94e58d974b4129f86e7.
roast/6.d-errata: bc25d4b50f | (Aleks-Daniel Jakimenko-Aleksejev)++ | S32-exceptions/misc.t
Make malformed loop tests less specific

Recent rakudo versions print some extra info on what went wrong.
AlexDaniel` nine: xD
16:10 Kaiepi left 16:12 Kaiepi joined 16:14 AlexDaniel left 16:15 AlexDaniel joined, AlexDaniel left, AlexDaniel joined
AlexDaniel Altai-man_: btw how do you keep track of the roast version that is supposed to be used for the release? 16:15
I used to like… rely on my bash history… :S /o\ 16:16
Altai-man_ AlexDaniel, I am not sure I'm getting your question. Do you like if there is some cool mechanism for that I should invent and encourage people to use? Nope. I know the commit I tested many times against and that's all. 16:17
Engrish is da stronkest today.
AlexDaniel Altai-man_: ah okay
Altai-man_ In the meanwhile, we still have no changelog for moar. 16:18
Also, one who will do it, it will be really helpful to add changes in a branch deriving from github.com/MoarVM/MoarVM/commit/3d...54433d5fb2 16:20
As we don't want to take the last commit in the release.
AlexDaniel who will be doing it, by the way? 16:22
Altai-man_ No idea yet, asked in #moarvm this morning and nobody was particularly enthusiastic. OTOH, I'm wrong for doing it on MONDAY, so no surprise people are busy. 16:23
I also suspect I can do it myself with some reviewing.
AlexDaniel jnthn: among all the notification spam, I think PS#184 is a relatively easy opportunity to say “no” :)
linkable6 PS#184 [open]: github.com/Raku/problem-solving/issues/184 [language] Should ¿? and ¡! be an alternative to "" ?
jnthn Indeed :) 16:39
AlexDaniel thanks :) 16:51
16:57 sena_kun joined 16:59 Altai-man_ left
Geth nqp/new-disp: e19e513763 | (Jonathan Worthington)++ | t/moar/53-dispatch.t
An initial test for the new dispatchers

Failing at time of commit.
nine tbrowder: looks like I've got a fix. If you've got a test, I can commit and push :) 17:40
tbrowder sounds good, but i’m still trimming module. down to .5mb 17:49
it will be a while, dr appt soon 18:19
18:56 Altai-man_ joined 18:59 sena_kun left 19:10 jjmerelo left 19:29 pamplemousse left 19:35 Altai-man_ left 19:36 sena_kun joined, sena_kun left 19:37 sena_kun joined 19:38 sena_kun left 19:39 sena_kun joined, sena_kun left 19:52 cognomin_ joined 19:55 sena_kun joined, cognominal left
sena_kun How horrible are perl: warning: Setting locale failed. Falling back to a fallback locale ("en_US.utf8").? 20:04
20:15 pamplemousse joined 20:32 Kaiepi left, Kaeipi joined 20:56 Altai-man_ joined 20:59 sena_kun left 21:01 Altai-man_ left 21:06 sena_kun joined
Geth rakudo/2020.05-release: 2a17339306 | Altai-man++ | 3 files
2020.05 release
21:24 cognominal joined 21:27 cognomin_ left
vrurg .tell jnthn here is detailed description of the problem with debugging in Comma: gist.github.com/vrurg/47a7ea373eb7...5a96c215cd 21:39
tellable6 vrurg, I'll pass your message to jnthn
vrurg sena_kun++! 21:41
tbrowder nine: it's still about 428 mb but it uses no Perl modules outside the core Perl dist. i commented out the one critical one it uses Archive::Zip so it can't produce an Excel file BUT I have a perl script that works with it while the raku script core dumps. 21:45
i can work up a PR from that unless you want me to keep trimming... 21:46
21:52 pamplemousse left
Geth rakudo/2020.05-release: b7f2f46dbc | Altai-man++ | 3 files
Update changelog + announcement

Deliberately not logged:
1d11885 bf2a542 26f4a36 3134ec7 358c5a8 80dde85 a10140f b9105f1 9b66980 feb0367 fa0da6f 65f18a9 18d083e 48d3a7f 4f63764 979d384 a47372a 35ac7c4 8f015aa a4680db a501754 9ebbad3 e8e2d3c 82b3249 ... (6 more lines)
rakudo/2020.05-release: 2d13f4ff5d | Altai-man++ | tools/templates/NQP_REVISION
[release] Bump NQP revision to 2020.05
rakudo/2020.05-release: 40a82d8723 | Altai-man++ | VERSION
[release] Bump VERSION to 2020.05
22:05 Kaeipi left 22:09 Kaiepi joined
Kaiepi sena_kun++ 22:30
lizmat, is github.com/rakudo/rakudo/pull/3589 good to go now with the release made? 22:34
23:07 Altai-man_ joined 23:09 sena_kun left 23:21 pamplemousse joined 23:31 MasterDuke left
Geth nqp: 2f5d5b7540 | Altai-man++ | tools/templates/MOAR_REVISION
[release] Bump MoarVM revision to 2020.05
nqp: a04f4985fb | Altai-man++ | VERSION
[release] Bump VERSION to 2020.05
nqp: vrurg++ created pull request #625:
Make stage 2 always fully rebuild upon changes in sources
rakudo: Altai-man++ created pull request #3663:
2020.05 release
rakudo/master: 4 commits pushed by Altai-man++
23:56 Altai-man_ left