[00:00] *** JRaspass left [02:09] *** JRaspass joined [02:10] *** JRaspass left [02:29] *** kvw_5 joined [02:32] *** kvw_5_ left [07:55] *** epony left [08:15] *** epony joined [09:05] *** domidumont joined [09:14] MasterDuke++ # a review [10:05] ¦ problem-solving/solution-250: f172f51654 | Altai-man++ | solutions/documentation/search-categories.md [10:05] ¦ problem-solving/solution-250: Provide a solution document for https://github.com/Raku/problem-solving/issues/250 [10:05] ¦ problem-solving/solution-250: [10:05] ¦ problem-solving/solution-250: "Documentation search categories are not standartized" [10:05] ¦ problem-solving/solution-250: [10:05] ¦ problem-solving/solution-250: Fixes https://github.com/Raku/problem-solving/issues/250 [10:05] ¦ problem-solving/solution-250: review: https://github.com/Raku/problem-solving/commit/f172f51654 [10:16] <[Tux]> Rakudo v2021.02.1-40-gb21bb5ab6 (v6.d) on MoarVM 2021.02-9-g564f5819b [10:16] <[Tux]> csv-test-xs-20 0.387 - 0.395 [10:16] <[Tux]> csv-ip5xs 0.804 - 0.815 [10:16] <[Tux]> test-t --race 1.361 - 1.386 [10:16] <[Tux]> test-t 2.031 - 2.263 [10:16] <[Tux]> test 7.937 - 7.993 [10:16] <[Tux]> csv-ip5xs-20 8.469 - 8.477 [10:16] <[Tux]> test-t-20 --race 9.107 - 9.145 [10:16] <[Tux]> csv-parser 26.285 - 26.498 [10:16] <[Tux]> test-t-20 33.190 - 33.234 [10:18] ¦ problem-solving/conf.raku.org: 1c8662211c | (Elizabeth Mattijsen)++ | solutions/meta/conf.raku.org [10:18] ¦ problem-solving/conf.raku.org: Set DNS record for conf.raku.org [10:18] ¦ problem-solving/conf.raku.org: review: https://github.com/Raku/problem-solving/commit/1c8662211c [10:18] ¦ problem-solving: lizmat++ created pull request #273: Set DNS record for conf.raku.org [10:18] ¦ problem-solving: review: https://github.com/Raku/problem-solving/pull/273 [10:25] ¦ problem-solving/dns-for-conf.raku.org: 28f50c6889 | (Elizabeth Mattijsen)++ | solutions/meta/conf.raku.org [10:25] ¦ problem-solving/dns-for-conf.raku.org: Set DNS for conf.raku.org [10:25] ¦ problem-solving/dns-for-conf.raku.org: review: https://github.com/Raku/problem-solving/commit/28f50c6889 [10:25] ¦ problem-solving: lizmat++ created pull request #274: Set DNS for conf.raku.org [10:25] ¦ problem-solving: review: https://github.com/Raku/problem-solving/pull/274 [10:27] ¦ problem-solving: 28f50c6889 | (Elizabeth Mattijsen)++ | solutions/meta/conf.raku.org [10:27] ¦ problem-solving: Set DNS for conf.raku.org [10:27] ¦ problem-solving: review: https://github.com/Raku/problem-solving/commit/28f50c6889 [10:27] ¦ problem-solving: 7f4a72233d | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | solutions/meta/conf.raku.org [10:27] ¦ problem-solving: Merge pull request #274 from Raku/dns-for-conf.raku.org [10:27] ¦ problem-solving: [10:27] ¦ problem-solving: Set DNS for conf.raku.org [10:27] ¦ problem-solving: review: https://github.com/Raku/problem-solving/commit/7f4a72233d [12:07] ¦ rakudo: 7f0ababc0b | (Elizabeth Mattijsen)++ | README.md [12:07] ¦ rakudo: Initial README.md updates [12:07] ¦ rakudo: [12:07] ¦ rakudo: - Remove some more Perl 6 references [12:07] ¦ rakudo: - Fix some URLs [12:07] ¦ rakudo: - Emphasize the number of developers involved [12:07] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/7f0ababc0b [12:11] ¦ rakudo: 6c1b02ecaf | (Elizabeth Mattijsen)++ | 2 files [12:11] ¦ rakudo: Linkify CREDITS and mention IN-MEMORIAM.md [12:11] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/6c1b02ecaf [12:12] ¦ rakudo: 9b07164243 | (Elizabeth Mattijsen)++ | IN-MEMORIAM.md [12:12] ¦ rakudo: Give the in memoriam a proper header [12:12] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/9b07164243 [12:18] ¦ rakudo: 0e957a662e | (Elizabeth Mattijsen)++ | README.md [12:18] ¦ rakudo: s/Raku and Rakudo/... [12:18] ¦ rakudo: [12:18] ¦ rakudo: Although it alliterates nicely, it looks confusing, so throw in another [12:18] ¦ rakudo: Programming Language for better SEO [12:18] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/0e957a662e [12:22] ¦ rakudo: 9b22e51bf2 | (Elizabeth Mattijsen)++ | README.md [12:22] ¦ rakudo: Add reference to Code of Conduct [12:22] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/9b22e51bf2 [13:50] *** domidumont left [13:55] *** gfldex left [14:06] *** gfldex joined [14:10] ¦ rakudo: 09d27c3216 | (Elizabeth Mattijsen)++ | docs/architecture.html [14:10] ¦ rakudo: Mark document as containing obsolete information [14:10] ¦ rakudo: review: https://github.com/rakudo/rakudo/commit/09d27c3216 [16:29] *** domidumont joined [16:53] *** finsternis joined [17:17] *** evalable6 left [17:17] *** greppable6 left [17:17] *** summerisle left [17:19] *** evalable6 joined [17:19] *** greppable6 joined [17:21] *** AlexDaniel` left [17:21] *** uzl[m] left [17:21] *** unclechu left [17:22] *** summerisle joined [17:25] *** JJAtria[m] left [17:25] *** patrickbkr[m] left [17:39] *** AlexDaniel` joined [17:45] *** unclechu joined [17:45] *** uzl[m] joined [18:28] *** JJAtria[m] joined [18:29] *** patrickbkr[m] joined [18:54] *** [Coke] joined [18:54] *** [Coke] left [18:54] *** [Coke] joined [18:58] *** domidumont left [19:29] `elems requires a concrete object (got a VMNull type object instead)` why couldn't this just be 0 instead of an exception? [19:42] *** lichtkind joined [19:48] well, changing it to do so passes a `make m-test m-spectest` [20:49] *** Kaiepi left [20:52] *** Kaeipi joined [20:52] *** Kaiepi joined [20:56] *** Kaiepi left [21:16] I'm may open a Problem Solving issue on this, but thought I'd ask for thoughts on here in case I'm missing something obvious. Raku seems to equivocate between Nil being "soft failure" (the docs call it "a cheaper and less explosive alternative to a Failure") and Nil indicating an _intentional_ absence of a value/successfully returning nothing (e.g., in &BagHash.add(to-add --> Nil), Nil indicates successfully adding an item) [21:18] Given that, it seems to me that it'd be worth having a separate "successful Nil" type, so that we could distinguish these two cases. The type could be as simple as `class Ok is Nil { method Bool(--> True) {} method gist() { self.^name } }` [21:20] That way, something could return Ok (successful nothing), Failure (unsuccessful nothing), or Nil (unspecified nothing). Anyway, no need to get into the full details here – I just wanted to see if I'm missing something so obvious that this isn't worth discussing in Problem Solving [22:05] Use Empty? [22:06] I'm not sure if thats the intended purpose of Empty... but i don't know the actually know the reasoning behind Empty [22:08] i guess that isn't very type-ish though [22:32] *** lichtkind left [22:41] Anyone know what the plan is for the next Rakudo Star? Is there a schedule for it now, or is it just "when there's a relatively clean and solid base rakudo release"? [22:42] japhb: tyil is the person to ask [22:43] japhb: april [22:43] the schedule is every 3 months, but there was no Rakudo release in January [23:25] *** Kaeipi left [23:26] *** Kaiepi joined [23:32] *** dogbert17 joined [23:36] *** dogbert11 left [23:40] codesections [23:40] codesections the reason BagHash.add returns Nil, is that it cannot fail gracefully [23:41] I'd say it cannot fail at all, but that would be hubris [23:42] therefore it returns Nil: returning True to indicate success wouldn't make sense, as it would either always return True, or throw an exception [23:42] *** dogbert17 left [23:43] *** dogbert17 joined [23:43] hmm, yeah, that all makes sense. And the same logic would also apply to something like &sleep (which also returns Nil) [23:44] tyil: OK, thanks for the info. [23:44] to my mind, Nil is about indicating the absence of a value [23:44] in the case of BagHash.add, there's just nothing to return [23:44] And, given the types we have, I agree that they both _should_ return Nil -- it's the best way to say "I'm successfully returning nothing." As opposed to Failure, which is about _un_sucessfully returning nothing. [23:44] also: Nil indicates to the compiler it should not have to evaluate the return value [23:45] Yeah, agreed on all points [23:45] I wasn't saying to change away from Nil for those fns [23:46] just to add an `Ok is Nil` type that is _still_ an absence of a value (that's why it's still a Nil) [23:47] but it's more explicit about being a successful absence of a value [23:47] well, if you see Nil in a return constraint, it *is* an OK :-) [23:48] from a self-documenting point of view, I can see your argument for OK [23:48] but otoh, it feels to me that it would steepen the Raku learning curve unnecessarily [23:51] Yeah, I could see that. Or I could see it flattening it/preventing new user confusion. Anyway, it sounds like I'm not missing anything so obvious that this isn't worth discussing, so I'll probably open an issue and link this discussion so people can see the good points you brought up here. [23:58] sleep&