[00:01] *** hungrydonkey joined [00:10] *** pmurias left [00:56] *** Kaiepi left [01:01] *** Kaiepi joined [01:34] *** sena_kun joined [01:36] *** Altai-man_ left [02:09] *** Kaeipi joined [02:09] *** Kaiepi left [02:12] *** Kaeipi left [02:14] *** Kaeipi joined [02:14] *** ufobat_ joined [02:18] *** ufobat__ left [02:24] Turns out, multi-dispatch doesn't pay respect to inheritance... [03:00] Next release in ≈1 day and ≈15 hours. There are no known blockers. Please log your changes in the ChangeLog: https://github.com/rakudo/rakudo/wiki/ChangeLog-Draft [03:33] *** Altai-man_ joined [03:36] *** sena_kun left [03:56] ¦ rakudo: vrurg++ created pull request #3500: Make multi method dispatcher handle MRO [03:56] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/3500 [04:36] *** hungrydonkey left [04:37] *** hungrydonkey joined [05:20] *** vrurg left [05:21] *** vrurg joined [05:34] *** sena_kun joined [05:36] *** Altai-man_ left [06:39] *** domidumont joined [06:42] *** domidumont left [06:52] *** domidumont joined [07:33] *** Altai-man_ joined [07:36] *** sena_kun left [07:50] *** Kaeipi left [07:53] *** Kaiepi joined [07:53] *** domidumont left [08:02] *** cognomin_ joined [08:05] *** cognominal left [08:16] *** domidumont joined [08:31] ¦ Blin: jsoref++ created pull request #21: Spelling [08:31] ¦ Blin: review: https://github.com/Raku/Blin/pull/21 [08:47] ¦ Blin: d88b3fd1aa | (Josh Soref)++ | bin/blin.p6 [08:47] ¦ Blin: spelling: algorithmically [08:47] ¦ Blin: review: https://github.com/Raku/Blin/commit/d88b3fd1aa [08:47] ¦ Blin: dbc48e43d2 | (Josh Soref)++ | docker/README.md [08:47] ¦ Blin: spelling: takes [08:47] ¦ Blin: review: https://github.com/Raku/Blin/commit/dbc48e43d2 [08:47] ¦ Blin: b495ad0342 | Altai-man++ (committed using GitHub Web editor) | 2 files [08:47] ¦ Blin: Merge pull request #21 from jsoref/spelling [08:47] ¦ Blin: [08:47] ¦ Blin: Spelling [08:47] ¦ Blin: review: https://github.com/Raku/Blin/commit/b495ad0342 [08:53] >no issues with Blin check [08:53] 2020-02-21T08:41:57Z #raku Altai-man great job! [08:54] releasable6, status [08:54] Altai-man_, Next release in ≈1 day and ≈10 hours. There are no known blockers. 163 out of 247 commits logged [08:54] Altai-man_, Details: https://gist.github.com/86e4b460f6ffb15543860701803cb8f9 [09:09] ¦ rakudo: 388846cf5a | Altai-man++ | tools/create-release-announcement.raku [09:09] ¦ rakudo: Fix executable name and off-by-one [09:09] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/388846cf5a [09:34] *** sena_kun joined [09:36] *** Altai-man_ left [09:47] bisectable6, my $a = (^2).Seq; my $b = $a; say $a eqv $b; [09:47] sena_kun, Bisecting by exit code (old=2015.12 new=388846c). Old exit code: 1 [09:47] sena_kun, bisect log: https://gist.github.com/f7179ec92670a1951d3fd83741b2713e [09:47] sena_kun, (2020-01-27) https://github.com/rakudo/rakudo/commit/76187b57c5ea8a34d16510878539bbb05ce4c9fb [10:11] *** cognominal joined [10:15] *** cognomin_ left [10:29] sena_kun: ^^ is that a problem ? [10:29] lizmat, nope, just checked if that's a "fix" or "change" [10:30] <|Tux|> Rakudo version 2020.01-248-g388846cf5 - MoarVM version 2020.01.1-43-ga71eee4c2 [10:30] <|Tux|> csv-test-xs-20 0.368 - 0.370 [10:30] <|Tux|> csv-ip5xs 0.699 - 0.708 [10:30] <|Tux|> test-t --race 0.778 - 0.822 [10:30] <|Tux|> test-t 1.743 - 1.841 [10:30] I'll scream here loudly if see any issues. ;) [10:30] <|Tux|> csv-ip5xs-20 5.753 - 5.853 [10:30] <|Tux|> test 7.261 - 7.546 [10:30] <|Tux|> test-t-20 --race 8.530 - 8.821 [10:30] <|Tux|> csv-parser 22.782 - 22.799 [10:30] <|Tux|> test-t-20 29.170 - 29.216 [10:30] sena_kun++ [11:01] ¦ rakudo/release-2020.02: 11997c8e26 | Altai-man++ | 2 files [11:01] ¦ rakudo/release-2020.02: Update changelog + announcement [11:01] ¦ rakudo/release-2020.02: [11:01] ¦ rakudo/release-2020.02: Deliberately not logged: [11:01] ¦ rakudo/release-2020.02: [11:01] ¦ rakudo/release-2020.02: 8099d64 4ffd8df 4437723 6c5615e 2b04eea 1cc43c8 2e69d7a 4829711 [11:01] ¦ rakudo/release-2020.02: 4e12365 5629cdf 58e8fb1 b582c7e 1299e32 5d65764 0d53009 547c7b9 [11:02] ¦ rakudo/release-2020.02: bae5fc7 c9a6b02 749ab90 14abd58 fb13c31 e27811a 68ff8cf 589ba38 [11:02] ¦ rakudo/release-2020.02: f8b9d02 37b1be7 5cffce1 9a83b61 e2a66ff 94b30b6 ca912be a152997 [11:02] ¦ rakudo/release-2020.02: 5a4a3be f2b3091 cdc907b ab9c1ff 774a839 8390016 f95bf76 5685648 [11:02] ¦ rakudo/release-2020.02: fbeb3e3 585cc6b 17f7c5a 0bebe4e b74e5d7 348fa84 4035239 [11:02] ¦ rakudo/release-2020.02: review: https://github.com/rakudo/rakudo/commit/11997c8e26 [11:03] ¦ rakudo: Altai-man++ created pull request #3501: Release 2020.02 [11:03] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/3501 [11:19] *** hankache joined [11:27] *** hungryd59 joined [11:29] *** hungrydonkey left [11:33] *** Altai-man_ joined [11:36] *** sena_kun left [11:42] *** hungrydonkey joined [11:44] *** hungryd59 left [11:45] *** hungrydonkey left [11:45] *** hungrydonkey joined [11:47] ¦ rakudo: 539e96c262 | (Elizabeth Mattijsen)++ | 2 files [11:47] ¦ rakudo: Make error on Buf stringification more awesome [11:47] ¦ rakudo: [11:47] ¦ rakudo: - tell the type it was attempted on [11:47] ¦ rakudo: - mention the use of .decode instead [11:47] ¦ rakudo: - also add prefix:<~> to the actual cases tested [11:47] ¦ rakudo: [11:47] ¦ rakudo: Inspired by Ralph Mellor's comment on: [11:47] ¦ rakudo: https://stackoverflow.com/questions/60334347/raku-is-there-a-super-fast-way-to-turn-an-array-into-a-string-without-the-spac [11:47] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/539e96c262 [11:47] ¦ rakudo: dumarchie++ created pull request #3502: Make listing and coercion of sequences more efficient [11:47] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/3502 [11:57] ¦ rakudo: 992f1b83f8 | (Jonathan Worthington)++ | 2 files [11:57] ¦ rakudo: Fix mixing in Raku-level code to the grammar [11:57] ¦ rakudo: [11:57] ¦ rakudo: The grammar is written in NQP, and so wants its match objects to have [11:57] ¦ rakudo: an nqp::list for quantified captures. An internals change resulted in us [11:57] ¦ rakudo: always creating a Raku Array instead; this is fine for everything except [11:57] ¦ rakudo: when we want to mix into the Raku grammar itself. In that case, we could [11:57] ¦ rakudo: end up with quantified things only collecting the last captured value, [11:57] ¦ rakudo: <…commit message has 5 more lines…> [11:57] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/992f1b83f8 [11:57] releasable6: status [11:57] jnthn, Next release in ≈1 day and ≈7 hours. There are no known blockers. 163 out of 249 commits logged [11:57] jnthn, Details: https://gist.github.com/dc2b49ca4ec275868ee10e16afe552a9 [11:57] \o/ [11:58] jnthn, given moarvm will be released today or early tomorrow, I'll wrap one tomorrow, things look (hopefully) smoothly here. [12:04] :) [12:04] Altai-man_++ [12:04] Then next week I can break st^W^Wmerge my latest MoarVM work :) [12:05] jnthn, please do by all means! [12:05] jnthn, it would be great to also merge everything available related to unix sockets grant [12:05] And I will join with some of my breaking opts :-) [12:05] but first some afk& [12:05] lizmat, good luck! [12:20] I am not sure about including https://github.com/rakudo/rakudo/commit/992f1b83f8f4ba68ea5229a877636f971ca0877e into the release, but tending not to do so: this failure is not a last release regression, has flapping nature and we release montly anyway. Any objections? [12:37] Altai-man_: It was a regression in the release before the last one, I guess... [12:37] Altai-man_: imo it's low-risk [12:37] (to include it) [12:37] jnthn, yes, it doesn't contradict with what I wrote. [12:39] Up to you really. It means that the module will only have been broken for one release, rather than for two if we don't include it. [12:46] *** lucasb joined [12:46] *** Kaiepi left [12:47] *** domidumont left [12:49] *** Kaiepi joined [12:51] t/spec/S32-container/buf.t ........................................ Dubious, test returned 1 (wstat 256, 0x100) [12:51] Failed 1/21 subtests [12:52] lizmat: ^^^ [13:23] *** hankache left [13:34] *** sena_kun joined [13:36] *** Altai-man_ left [14:36] jnthn: any thoughts on https://github.com/MasterDuke17/rakudo/commit/a24ed84ae33cc1440ee7f7a9dbd6a5b27aeaff5a ? [14:47] *** pmurias joined [14:52] m: say 1 ~~ 1.5 | 1.0 [14:52] jnthn, rakudo-moar 992f1b83f: OUTPUT: «True␤» [14:52] Does it get this right? [14:55] (It may be over-committing on type, if I'm reading it right) [14:56] I really want just desugar it into a chain of calls to .ACCEPTS and then let the right thing happen [14:56] m: sub a($a where 1.0|1.5) { $a }; my $a; my $b := 1; say a($b) [14:56] MasterDuke, rakudo-moar 992f1b83f: OUTPUT: «1␤» [14:56] i get '1' also [14:57] but should i change it to a bunch of .ACCEPTS? [14:58] Oh, you don't optimize for Rat, but... [14:58] m: say 1 ~~ 1.5e0 | 1e0 [14:58] jnthn, rakudo-moar 992f1b83f: OUTPUT: «True␤» [14:58] What about a case like that? [14:58] m: say '1' ~~ 1.5e0 | 1e0 [14:58] jnthn, rakudo-moar 992f1b83f: OUTPUT: «True␤» [14:58] Or that? [15:00] m: sub a($a where 1e0|1.5e0) { $a }; my $a; my $b = 1; say a($b); my $c = '1'; say a($c) [15:00] MasterDuke, rakudo-moar 992f1b83f: OUTPUT: «1␤1␤» [15:00] heh. i get 'Internal error: inconsistent bind result' [15:01] Yeah, I feared that one might not go well [15:02] guess we should also add tests for those cases, because my branch does pass a spectest [15:03] +1 [15:04] My gut feeling is that calling .ACCEPTS is going to be the best way, because doing otherwise will mean the code size is liable to explode [15:04] i'll give that a try [15:33] *** Altai-man_ joined [15:34] *** cognomin_ joined [15:36] *** sena_kun left [15:37] *** pmurias left [15:37] *** cognominal left [16:18] nine: grrr.... adding a period I didn't think would make that much of a difference [16:23] ¦ rakudo: 3f637af9e1 | (Elizabeth Mattijsen)++ | src/core.c/Buf.pm6 [16:23] ¦ rakudo: Remove period to fix test [16:23] ¦ rakudo: [16:23] ¦ rakudo: Really didn't think it would make a difference :-( [16:23] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/3f637af9e1 [16:54] *** domidumont joined [16:58] t/spec/S16-io/watch.t ............................................. Dubious, test returned 1 (wstat 256, 0x100) [16:59] Failed test: 1 [17:00] nine: that's potentially a flapper: some OS's sometimes take a little longer to deliver file system events [17:01] or does it repeatedly fail for you ? [17:02] Yeah, I've noted that here multiple times already. But no one feels responsible for fixing it. [17:04] well, it depends on the OS... I've fixed it for MacOS [17:07] The test is obviously still broken. In a quite obvious way even. [17:08] <[Coke]> is there a ticket to track it? [17:10] Now: https://github.com/perl6/roast/issues/621 [17:11] Maybe I should mark it a release blocker. After all it did cause my test run of the new release script for MoarVM to abort. [17:12] Apparently there is no blocker label in roast. So maybe I should assume that the test is correct after all and create a rakudo release blocker issue? [17:12] nine, if the test itself is broken, how release blocker? [17:13] nine, is it reliable? if yes, can we bisect it? if it's a flapper since forever, how blocker? [17:14] The test being broken is just my interpretation after all. It's not like I have mathematical proof of it. [17:14] nine: then. from my experience trying to test this, we should make it a stress test, maybe [17:14] It's pretty easy to make it fail by running on a heavily loaded system [17:15] the thing is that on such systems, in my experience, some events just don't get delivered [17:15] so increasing the timeout, would result in a hanging test, rather than a failing test [17:16] What timeout? [17:16] Promise.in(5); [17:16] The test file goes straight from triggering the last even to checking the 5 second time out without giving the system any time at all to deliver the event. [17:19] ¦ roast: b3274b105b | (Jonathan Worthington)++ | S16-io/watch.t [17:19] ¦ roast: Try to make file watching test more reliable [17:19] ¦ roast: [17:19] ¦ roast: Don't rely on time, just keep the thing making events and thing that [17:19] ¦ roast: expects them in lock step with each other. [17:19] ¦ roast: review: https://github.com/perl6/roast/commit/b3274b105b [17:20] nine: works for me... :-) [17:21] Still the same :/ [17:21] Still fails? [17:21] After my fix, or the timeout bump? [17:22] jnthn: still same error mode even with your fix [17:23] nine: I was mistaken that test file with S17-supply/watch-path.t [17:24] jnthn: I think the test actually still has exactly the same issue. Your fix suffers from an off-by-one in a way [17:24] ah, shit, I see... [17:24] No, I don't think it does [17:24] It's a race [17:24] Do we need $done-writing at all? [17:24] no, that's precisely what I'm removing at the moment [17:24] We could just end if $count arrives at 10 [17:25] *** domidumont left [17:25] ¦ roast: 440672c984 | (Jonathan Worthington)++ | S16-io/watch.t [17:25] ¦ roast: Remove another source of race in file watch test [17:25] ¦ roast: review: https://github.com/perl6/roast/commit/440672c984 [17:26] Btw sorry for being so grumpy about this. I'm overly stressed by $daytime-job and just finished my workout which left me unusually exhausted and not feeling good at all :/ [17:26] I was pissed off you were being grumpy so decided to fix it while you were grumping :P [17:26] So I guess it worked out :P [17:27] Well, if it's fixed now anyway... [17:27] *** domidumont joined [17:28] ¦ roast: 72ab057be3 | (Jonathan Worthington)++ | S16-io/watch.t [17:28] ¦ roast: Factor out a magic number to a constant [17:28] ¦ roast: review: https://github.com/perl6/roast/commit/72ab057be3 [17:28] Plus that gets rid of the 10 everywhere [17:28] Yeah, looks better now. I do get an occasional timeout though. [17:28] Hmm [17:28] But I'm running spectest with TEST_JOBS=40 to generate load [17:29] Can it really take more than 5 seconds for 10 write/fs event cycles? [17:29] The first fix I did was 'cus I figured it was batching them and getting the count wrong. [17:30] Bumped the timeout to 50s and still got one [17:30] as I said: OS's are not guaranteed to deliver all events at all times [17:30] at least in my experience [17:32] *** domidumont left [17:32] so maybe we should test for a percentage of events arriving? [17:33] *** domidumont joined [17:34] I wonder if there's a race between the file watcher setup request being sent and the first write [17:34] *** sena_kun joined [17:35] Since I don't think the `whenever` giving back control means the setup was completed, and the first write might beat it... [17:36] ¦ roast: c1f86a12b7 | (Jonathan Worthington)++ | S16-io/watch.t [17:36] ¦ roast: Allow time for file watcher setup [17:36] ¦ roast: review: https://github.com/perl6/roast/commit/c1f86a12b7 [17:36] *** Altai-man_ left [17:36] Don't like having a time in there...grmbl :) [17:36] But if it helps, then it explains what is going on [17:45] I've run it during a loop for an entire spectest run without failure. [17:47] *** hungryd5 joined [17:50] *** hungrydonkey left [17:50] OK, home time o/ [18:00] jnthn: double promise approach for watch.t would do better: first the start block signals that it's ready (promise1), then it would await for the command to start (promise2). [18:03] *** hungryd5 left [18:04] ¦ rakudo: 1d946e15fe | (Elizabeth Mattijsen)++ | src/core.c/IO/Path.pm6 [18:04] ¦ rakudo: IO::Path!new-from-absolute-path is a private method [18:04] ¦ rakudo: [18:04] ¦ rakudo: - so it doesn't need any named parameters, it can use positionals [18:04] ¦ rakudo: - it doesn't need any defaults or coercing [18:04] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/1d946e15fe [18:07] *** domidumont left [18:08] *** patrickb joined [18:11] *** rba[m] left [18:11] *** unclechu left [18:12] *** CIAvash left [18:12] *** AlexDaniel` left [18:29] *** rba[m] joined [18:30] *** rba[m] left [18:50] *** cognominal joined [18:52] .ask vrurg could you put the RUN_CLEAN_TARGET_FILES logic into a script to be run with -ll-exception ? [18:52] lizmat, I'll pass your message to vrurg [18:54] *** cognomin_ left [18:59] *** Xliff joined [19:00] lizmat: it was patrickb addition and I rather avoid this part of the build. [19:00] .ask patrickb could you put the RUN_CLEAN_TARGET_FILES logic into a script to be run with -ll-exception ? [19:00] lizmat, I'll pass your message to patrickb [19:00] vrurg++ [19:01] lizmat: But if he's too busy, I'll do it. [19:01] m: role A { submethod BUILD (:$a) { say "A" } }; role B { submethod BUILD (:$b) { say "B" } }; class C does A does B { } [19:01] Xliff, rakudo-moar 1d946e15f: OUTPUT: «(exit code 1) 04===SORRY!04=== Error while compiling /tmp/cvjQfyHrsM␤Method 'BUILD' must be resolved by class C because it exists in multiple roles (B, A)␤at /tmp/cvjQfyHrsM:1␤» [19:01] 2020-02-05T07:21:31Z #raku Xliff thanks for updating the raku/perl6 compiler :-) [19:01] I'm working on some IO::Path streamlining [19:01] and it breaks during that process... but can't really see why :-( [19:01] m: role A { submethod BUILD (:$a) { say "A" } }; role B { submethod BUILD (:$b) { say "B" } }; class C does A does B { submethod BUILD (:$c) { say "C" } }; C.new} [19:01] Xliff, rakudo-moar 1d946e15f: OUTPUT: «(exit code 1) 04===SORRY!04=== Error while compiling /tmp/8IrYlVRWET␤Unexpected closing bracket␤at /tmp/8IrYlVRWET:1␤------> 03bmethod BUILD (:$c) { say "C" } }; C.new08⏏04}␤» [19:01] m: role A { submethod BUILD (:$a) { say "A" } }; role B { submethod BUILD (:$b) { say "B" } }; class C does A does B { submethod BUILD (:$c) { say "C" } }; C.new [19:01] Xliff, rakudo-moar 1d946e15f: OUTPUT: «C␤» [19:02] *** CIAvash joined [19:03] lizmat: Actually, --ll-exception could be added to the command line without extracting into a script. [19:04] lizmat: Do you just need the full backtrace or there is something else? [19:04] true, but that wouldn't give me an easy way to find out what exactly is going on [19:04] a full backtrace will do for now :-) [19:04] which I have now, thanks! :-) [19:11] lizmat: np :) [19:25] *** unclechu joined [19:25] *** rba[m] joined [19:25] *** AlexDaniel` joined [19:27] I wonder if someone can explain to me why this doesn't select the :basename! candidate: https://gist.github.com/lizmat/1c4480ee3099037bc52c37c8e3177b60 [19:33] *** Altai-man_ joined [19:36] lizmat, vrurg: Not sure what the RUN_CLEAN_TARGET_FILES / --ll-exception thing is about. [19:36] 2020-02-21T07:15:27Z #raku patrickb, no, no way that I know of. And yes, the organization has been deleted for me too; it returned a 403. [19:36] 2020-02-21T19:00:43Z #raku-dev patrickb could you put the RUN_CLEAN_TARGET_FILES logic into a script to be run with -ll-exception ? [19:36] *** sena_kun left [19:36] in the Makefile there is a piece of code run with -e [19:37] I would like to see it being run from a script so that I can easily add debugging code if necessary [19:37] rather than to fiddle with the Makefile [19:43] re https://gist.github.com/lizmat/1c4480ee3099037bc52c37c8e3177b60 I figured it out [19:43] *** domidumont joined [19:43] m: dd $*SPEC, $*SPEC.defined [19:43] lizmat, rakudo-moar 1d946e15f: OUTPUT: «Unix element = IO::Spec::Unix␤Bool::False␤» [19:43] constraining to IO::Spec:D is suicide :) [19:45] jmerelo: I wrote to GSoC support and asked about our rejection, they answered really fast. Our application wasn't bad in any way. It's just that they have a maximum of 200 orgs they accept, and want to get 30 new ones in every time, so some have to pause from time to time. This year we were paused. [19:45] patrickb, I'll pass your message to jmerelo [19:47] *** domidumont left [19:48] so, if we would have applied as The Raku Foundation, we would have had a good chance of being accepted :-( [19:51] <[Coke]> Given that would be the same org with a d.b.a., we might have, but only on a technicality. [19:52] <[Coke]> It wouldn't hurt to have a third name for the foundation, for sure. [19:52] <[Coke]> (from the standpoint of someone who wouldn't be dealing with any of the legalities.) [19:58] I've been told it would be relatively easy and painless [19:59] as TPF is also a d.b.a of Yet Another Society [20:07] m: class Foo { multi method foo(Str:D $a) { say "Foo" } }; class Bar is Foo { multi method foo(Any:D $v) { say "Bar" } }; Bar.new.foo("ok") [20:07] vrurg, rakudo-moar 1d946e15f: OUTPUT: «(exit code 1) Ambiguous call to 'foo(Bar: Str)'; these signatures all match:␤:(Foo: Str:D $a, *%_)␤:(Bar: Any:D $v, *%_)␤ in block at /tmp/thVw2Ey6s5 line 1␤␤» [20:07] ^ Am I right that this is not how it should behave? [20:08] m: class Foo { multi method foo(Str:D $a) { say "Foo"; nextsame } }; class Bar is Foo { multi method foo(Foo: Any:D $v) { say "Bar" } }; Bar.new.foo("ok") [20:08] vrurg, rakudo-moar 1d946e15f: OUTPUT: «Foo␤» [20:19] vrurg: That is correct behavior. [20:19] jnthn: The second one too? [20:20] vrurg: The invocant is just another parameter so far as the multi-dispatch is concerned [20:20] Didn't look at the second one yet, just the one you asked about :) [20:20] I know the invokant is considered, but it feels to me that Str:D should have preference in this case. [20:21] It's correct in the second csae tht it picks Foo, but it's not clear to me why it'd not then nextsame into bar [20:22] Um, to be clear, the one that says Foo [20:22] Since I think both should be valid candidates [20:23] jnthn: I know what you mean, that's the point. [20:24] It's a bit of a funny nextsame in so far as you go down the class hierarchy, but that should be totally irrelevant given we're walking a multi candidate list [20:24] (multi method dispatch is actually two dispatches, one to find the controlling proto, and then a standard multi dispatch once it's found) [20:26] jnthn: I wanna try rewriting MethodDispatch to have it handle multis too. Gonna see if it would impact the issue. [20:26] m: class Foo { multi method foo(Str:D $a) { say "Foo"; nextsame } }; class Bar is Foo { multi method foo(Foo: Any:D $v) { say "Bar" } }; Bar.^lookup("foo").cando(Bar.new, "str") [20:26] jnthn, rakudo-moar 1d946e15f: OUTPUT: «(exit code 1) Too many positionals passed; expected 2 arguments but got 3␤ in block at /tmp/1pgbEZhLvz line 1␤␤» [20:26] d'oh [20:26] m: class Foo { multi method foo(Str:D $a) { say "Foo"; nextsame } }; class Bar is Foo { multi method foo(Foo: Any:D $v) { say "Bar" } }; Bar.^lookup("foo").cando(\(Bar.new, "str")) [20:26] jnthn, rakudo-moar 1d946e15f: OUTPUT: «» [20:27] m: class Foo { multi method foo(Str:D $a) { say "Foo"; nextsame } }; class Bar is Foo { multi method foo(Foo: Any:D $v) { say "Bar" } }; say Bar.^lookup("foo").cando(\(Bar.new, "str")) [20:27] jnthn, rakudo-moar 1d946e15f: OUTPUT: «(foo foo)␤» [20:27] That thinks they are both candidates [20:27] And I thought nextsame would use the same plumbing [20:28] So I'm a bit surprised it doesn't reach the `say "Bar"` [20:28] Looks like candidates are taken before foo from Bar is added to the cloned proto. [20:28] Huh? [20:28] So, runtime sees both, but only one is compiled into. [20:28] But the dispatcher is formed at runtime? [20:29] It was a only guess for now. [20:30] I suspect whatever it is will be fairly localized to the deferral handling [20:30] I'll try to see what I can done about it. [20:30] *can do [20:30] One thing I worry about is that we don't end up revisiting the same multi method multiple times 'cus it exists in many protos [20:31] Which a naive fix for this issue would end up doing [20:32] So maybe MethodDispatcher trying to rule over the whole process is a rightish way to go [20:32] *MethodDispatch [20:32] jnthn: I took care of this in #3500, but as I thought about that implementation afterwards, it's prone to the revisiting if child classes would override with non-multi. [20:33] Aha, that was exactly my enlightenment before I went to bed. :) Gonna try it this way today. [20:33] Is it possible to have a catch-the-rest argument in sub MAIN? like 'sub MAIN(Str $folder, Str @files)'? [20:34] *@files [20:34] And you can't type slurpies [20:34] ¦ problem-solving: lizmat assigned to jnthn Issue $*CWD is an IO::Path, IO::Path.CWD is a Str https://github.com/Raku/problem-solving/issues/164 [20:34] And it would still have to remember what packages protos were defined in to get around corresponding parents. [20:35] Yes, and I'm not sure we retain that information [20:35] The other thing it could potentially do is keep a seen list [20:36] Though that's not really efficient [20:36] jnthn: We do retain it. That's how I solved it with MultiDispatcher. It walks MRO but throws away the first entry and records the proto's package. Did work in a way. [20:37] jnthn: Nevermind, don't get yourself distracted on this. I have a plan, will see how it works. [20:37] * vrurg needs it or the whole architecture of my event dispatching in Vikna is broken. :( [20:38] vrurg: Hm, how is it retained out of curiosity? :) [20:38] Is that something you added, or is there a bit of information retained that I forgot about? [20:40] In terms of Dispatcher.nqp vivify_for: $sub.dispatcher.package. For Bar it gives Foo. [20:40] Aha! [20:42] m: class Foo { multi method foo(Str:D $a) { say "Foo"; nextsame } }; class Bar is Foo { multi method foo(Any $v) { say "Bar" } }; say Bar.^method_table.is_dispatcher; say Bar.^method_table.package.^name [20:42] vrurg, rakudo-moar 1d946e15f: OUTPUT: «True␤Dummy␤» [20:42] But this ^ is confusing me though. [20:43] Dummy is the class in which protos are generated ? [20:43] Dummy.HOW.set_autogen_proto(&Dummy::AUTOGEN); [20:44] m: class Foo { proto method foo(|) {*}; multi method foo(Str:D $a) { say "Foo"; nextsame } }; class Bar is Foo { multi method foo(Any $v) { say "Bar" } }; say Bar.^method_table.is_dispatcher; say Bar.^method_table.package.^name; [20:44] vrurg, rakudo-moar 1d946e15f: OUTPUT: «True␤Foo␤» [20:44] lizmat: thanks! [20:45] But it means a lot of problems then... I have what to think about... [20:51] What if I "rebind" the proto to the package it's being instantiated for? I.e. enforce it's package attribute to the correct value? [21:01] jnthn: with your latest commit I haven't been able anymore to reproduce a failure in watch.t :) [21:25] ¦ rakudo: patrickbkr++ created pull request #3504: Move RUN_CLEAN_TARGET_FILES to separate script [21:25] ¦ rakudo: review: https://github.com/rakudo/rakudo/pull/3504 [21:25] vrurg, lizmat: https://github.com/rakudo/rakudo/pull/3504 [21:26] nine: Hurrah :) [21:27] vrurg: That'd probably work given it's cloned [21:28] jnthn: should/could https://github.com/rakudo/rakudo/blob/master/src/Perl6/Actions.nqp#L9676-L9706 just be made smarter? [21:34] MasterDuke: I'd prefer optimizations stay in the optimizer, I think [21:34] *** sena_kun joined [21:36] *** Altai-man_ left [21:36] k [23:00] Next release in ≈19 hours. There are no known blockers. Please log your changes in the ChangeLog: https://github.com/rakudo/rakudo/wiki/ChangeLog-Draft [23:31] ¦ rakudo: 21aa02ba0d | (Elizabeth Mattijsen)++ | src/core.c/Match.pm6 [23:31] ¦ rakudo: Revert "Make Match.STR faster if there are no captures" [23:31] ¦ rakudo: [23:31] ¦ rakudo: This reverts commit 495ddcc1ffcb9d652e555608cb60b2cc166a916e. [23:31] ¦ rakudo: [23:31] ¦ rakudo: This was only an optimization in an area that could use a lot of [23:31] ¦ rakudo: thinking and reorganization. Since it apparently causes issues: [23:31] ¦ rakudo: [23:31] ¦ rakudo: https://colabti.org/irclogger/irclogger_log/moarvm?date=2020-02-21#l112 [23:31] ¦ rakudo: [23:31] ¦ rakudo: revert it. [23:31] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/21aa02ba0d [23:31] .tell sena_kun suggest you cherry pick https://github.com/rakudo/rakudo/commit/21aa02ba0d into the release [23:31] lizmat, I'll pass your message to sena_kun [23:31] sleep& [23:33] *** Altai-man_ joined [23:36] *** sena_kun left [23:42] greppable6: Dummy [23:42] vrurg, 26 lines, 10 modules: https://gist.github.com/0c1657a081b6cb7d51e55fde7e69b7ac [23:46] *** lucasb left