[04:03] anyone know who runs colabti.org? the logger seems to have been downe for a while. [05:24] *** Xliff joined [06:20] *** frost-lab joined [06:21] *** Xliff left [07:22] *** evalable6 joined [07:23] *** linkable6 joined [07:29] *** jmerelo joined [08:16] *** sena_kun joined [09:05] *** JRaspass joined [09:37] ===> Fetching [FAIL]: WWW:ver<1.005004>:auth from https://github.com/perl6-community-modules/WWW.git [09:37] What's curious is that it works locally, likely due to a local cache. Can anyone try `zef install WWW`? [09:38] I assume https://github.com/raku-community-modules/WWW/blob/master/META6.json#L24 should be changed and then re-indexed by the ecosystem? [09:39] sena_kun: it probably should. I don't want to do it before solving issues, however [09:40] sena_kun: that shouldn't be a problem, however, unless redirections no longer work. [09:42] sena_kun: anyway, as I say, better solve outstanding issues before re-releasing it. [09:42] jmerelo, before solving what issues? Redirects should work, yes, but I am still seeing the error for the third time, so apparently they don't somewhere. [09:46] sena_kun: well, there are a few of them https://github.com/raku-community-modules/WWW/issues [09:46] jmerelo, https://github.com/raku-community-modules/WWW/issues/19 <- one of the issues is literally what I have right now. And it is probably caused by a redirect not working. [09:47] No? [09:48] sena_kun: the comment states that there's some issue with authentication. So we'll need to fix the tests (or the underlying code, or both). [09:48] My point is that it's not worth the while to change the link in META.list in the ecosystem and/or the META6.json link (which seems to have been fixed by lizmat, BTW), without looking at that other issues that might make it fail anyway [09:49] jmerelo, I think this is a fallback behavior due to issues with fetching. [09:50] jmerelo, no, it is worth. There was a module. People relied on that, other modules relied on that. Now fetching is broken due to a link being changed. And you are saying we should not fix fetching, because there are some other issues that might be irrelevant, wishlist ones, etc? [09:50] I am not getting it. [09:56] Not sure if a version bump is necessary. [10:08] sena_kun: let me work on that this morning. And yes, a version bump is necessary. [10:09] jmerelo, I already did https://github.com/raku-community-modules/WWW/commit/ddb678886168a4748c3ee7f2c80db4eb30edff47 [10:14] *** leont joined [10:26] sena_kun: thanks. I'm still trying to fix a few things... Also need to test if that effectively solves issue #19 [10:56] *** |Tux| joined [10:57] *** Tux__ joined [10:57] *** |Tux| left [10:58] *** Tux__ left [10:59] *** Tux__ joined [11:00] *** Tux__ left [11:00] *** Tux__ joined [11:03] *** Tux__ left [11:12] *** squashable6 joined [11:57] *** Altai-man joined [12:00] *** sena_kun left [12:38] *** frost-lab left [14:01] *** jmerelo left [14:45] *** zostay joined [14:47] *** rypervenche joined [14:47] *** epony joined [15:03] i have no reason for wanting this, but it randomly occurs to me that when you return something from .^parameterize that also has a .^parameterize you can have types be like MyType[foo][bar][baz] [15:25] *** maggotbrain left [15:26] *** vrurg_ joined [15:27] *** maggotbrain joined [15:29] *** vrurg left [15:37] *** kanopis joined [15:37] *** kanopis left [15:38] *** kanopis joined [15:46] ¦ rakudo: 8a3e983c99 | (Elizabeth Mattijsen)++ | 2 files [15:46] ¦ rakudo: Throw on non-Int result in Iterable index on native array [15:46] ¦ rakudo: [15:46] ¦ rakudo: Because slices on native arrays return the same type of array on which [15:46] ¦ rakudo: the slice is based, it cannot represent nested indexes like: [15:46] ¦ rakudo: [15:46] ¦ rakudo: @a[1,2,(3,4)] [15:46] ¦ rakudo: @a[1,2,*] [15:46] ¦ rakudo: <…commit message has 5 more lines…> [15:46] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/8a3e983c99 [15:59] *** sena_kun joined [15:59] *** Altai-man left [16:20] ¦ rakudo: 5eb5507640 | (Elizabeth Mattijsen)++ | 2 files [16:20] ¦ rakudo: Throw on non-Int result in Iterable index on native array assignment [16:20] ¦ rakudo: [16:20] ¦ rakudo: See previous commit for rationale [16:20] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/5eb5507640 [16:30] *** kanopis left [16:40] *** patrickb joined [16:46] *** patrickb left [17:03] ¦ rakudo: 4d40e23e0f | (Elizabeth Mattijsen)++ | 2 files [17:03] ¦ rakudo: Add candidate for native slice assignment from Iterable [17:03] ¦ rakudo: [17:03] ¦ rakudo: Makes slice assignment on a native array from an Iterable [17:03] ¦ rakudo: about 15x as fast. Also makes it more correct: [17:03] ¦ rakudo: [17:03] ¦ rakudo: If the values for a slice assignment to a native array are not of [17:03] ¦ rakudo: the same type, it would fall back to the generic slice assignment. [17:03] ¦ rakudo: This would a. return a List rather than a native array of the same [17:03] ¦ rakudo: type, and b. would not die on passing nested indices like with other [17:03] ¦ rakudo: slices on native arrays. [17:03] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/4d40e23e0f [17:05] lizmat: just curious, do you get a noticeably longer stage parse on the faster-slice-access branch? [17:06] MasterDuke: yes, because there is a lot more code to parse [17:07] yeah, i wondered if it was enough to make a difference [17:07] *** leont left [17:08] 79603 vs 73339 lines in gen/moar/CORE.c.setting [17:17] *** Kaiepi left [17:43] *** domidumont joined [18:13] *** Kaiepi joined [18:16] *** domidumont left [18:19] *** ggoebel joined [19:13] *** leont joined [19:57] *** Altai-man joined [20:00] *** sena_kun left [20:06] *** tobs joined [20:11] *** tobs left [20:14] *** tobs joined [20:18] *** tobs left [20:21] *** tobs joined [20:29] wow [20:29] that's a lot of code right there [20:52] yes [20:52] *** b2gills left [20:53] that's only to get around the performance issue of a role calling a private method in a consuming class [20:53] fwiw, this only creates more code [20:54] if it had been generated as roles and consuming classes, it would still codegen the same amount of code [20:54] would it not? [20:55] so the binary size would be the same whether they'd come from generated code like this, or codegenned code from roles and classes [20:56] the only disadvantage, as MasterDuke noted, is increased core setting compilation time [21:00] *** tobs left [21:06] *** tobs joined [21:09] *** ggoebel left [21:11] *** tobs left [21:15] *** ggoebel joined [21:20] *** tobs joined [21:22] *** rypervenche left [21:23] *** b2gills joined [21:24] *** sortiz joined [21:25] *** rypervenche joined [21:45] Trying to address an issue on Window 10, I find many failures at rakudo's test time. Details in https://gist.github.com/salortiz/7934a39b775a9bcc6d556b6fa8f23c71 [21:56] I've been out of the loop for many months. Are those glitches expected in Windows? [22:01] ¦ problem-solving/solution-250: 5637dc6f8d | Altai-man++ | solutions/documentation/search-categories.md [22:01] ¦ problem-solving/solution-250: Provide a solution document for https://github.com/Raku/problem-solving/issues/250 [22:01] ¦ problem-solving/solution-250: [22:01] ¦ problem-solving/solution-250: "Documentation search categories are not standartized" [22:01] ¦ problem-solving/solution-250: [22:01] ¦ problem-solving/solution-250: Fixes https://github.com/Raku/problem-solving/issues/250 [22:01] ¦ problem-solving/solution-250: review: https://github.com/Raku/problem-solving/commit/5637dc6f8d [22:02] ¦ problem-solving: Altai-man++ created pull request #256: Provide a solution document for #250 [22:02] ¦ problem-solving: review: https://github.com/Raku/problem-solving/pull/256 [22:07] sortiz: no? [22:07] 2021-01-04T18:40:06Z #moarvm nine it may be worth having a MVM_VECTOR_PARAM(x) macro that specifies the vector as a parameter, and maybe an equivalent MVM_VECTOR_ARG(x) that does the same for arguments [22:07] *** Altai-man left [22:38] *** finsternis joined