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
sena_kun MasterDuke++ # a review 09:14
Geth problem-solving/solution-250: f172f51654 | Altai-man++ | solutions/documentation/search-categories.md
Provide a solution document for github.com/Raku/problem-solving/issues/250

  "Documentation search categories are not standartized"
Fixes github.com/Raku/problem-solving/issues/250		 10:05
[Tux] Rakudo v2021.02.1-40-gb21bb5ab6 (v6.d) on MoarVM 2021.02-9-g564f5819b
csv-ip5xs0.804 - 0.815
csv-ip5xs-208.469 - 8.477
csv-parser26.285 - 26.498
csv-test-xs-200.387 - 0.395
test7.937 - 7.993
test-t2.031 - 2.263
test-t --race1.361 - 1.386
test-t-2033.190 - 33.234
test-t-20 --race9.107 - 9.145
 10:16
Geth problem-solving/conf.raku.org: 1c8662211c | (Elizabeth Mattijsen)++ | solutions/meta/conf.raku.org
Set DNS record for conf.raku.org
 10:18
problem-solving: lizmat++ created pull request #273:
Set DNS record for conf.raku.org
problem-solving/dns-for-conf.raku.org: 28f50c6889 | (Elizabeth Mattijsen)++ | solutions/meta/conf.raku.org
Set DNS for conf.raku.org
 10:25
problem-solving: lizmat++ created pull request #274:
Set DNS for conf.raku.org
problem-solving: 28f50c6889 | (Elizabeth Mattijsen)++ | solutions/meta/conf.raku.org
Set DNS for conf.raku.org
 10:27
problem-solving: 7f4a72233d | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | solutions/meta/conf.raku.org
Merge pull request #274 from Raku/dns-for-conf.raku.org

Set DNS for conf.raku.org
rakudo: 7f0ababc0b | (Elizabeth Mattijsen)++ | README.md
Initial README.md updates

  - Remove some more Perl 6 references
  - Fix some URLs
  - Emphasize the number of developers involved		 12:07
rakudo: 6c1b02ecaf | (Elizabeth Mattijsen)++ | 2 files
Linkify CREDITS and mention IN-MEMORIAM.md
 12:11
rakudo: 9b07164243 | (Elizabeth Mattijsen)++ | IN-MEMORIAM.md
Give the in memoriam a proper header
 12:12
rakudo: 0e957a662e | (Elizabeth Mattijsen)++ | README.md
s/Raku and Rakudo/...

Although it alliterates nicely, it looks confusing, so throw in another Programming Language for better SEO		 12:18
rakudo: 9b22e51bf2 | (Elizabeth Mattijsen)++ | README.md
Add reference to Code of Conduct
 12:22
13:50 domidumont left 13:55 gfldex left 14:06 gfldex joined
Geth rakudo: 09d27c3216 | (Elizabeth Mattijsen)++ | docs/architecture.html
Mark document as containing obsolete information
 14:10
16:29 domidumont joined 16:53 finsternis joined 17:17 evalable6 left, greppable6 left, summerisle left 17:19 evalable6 joined, greppable6 joined 17:21 AlexDaniel` left, uzl[m] left, unclechu left 17:22 summerisle joined 17:25 JJAtria[m] left, patrickbkr[m] left 17:39 AlexDaniel` joined 17:45 unclechu joined, uzl[m] joined 18:28 JJAtria[m] joined 18:29 patrickbkr[m] joined 18:54 [Coke] joined, [Coke] left, [Coke] joined 18:58 domidumont left
MasterDuke `elems requires a concrete object (got a VMNull type object instead)` why couldn't this just be 0 instead of an exception? 19:29
19:42 lichtkind joined
MasterDuke well, changing it to do so passes a `make m-test m-spectest` 19:48
20:49 Kaiepi left 20:52 Kaeipi joined, Kaiepi joined 20:56 Kaiepi left
codesections 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:16
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:18
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 21:20
ugexe Use Empty? 22:05
I'm not sure if thats the intended purpose of Empty... but i don't know the actually know the reasoning behind Empty 22:06
i guess that isn't very type-ish though 22:08
22:32 lichtkind left
japhb 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:41
MasterDuke japhb: tyil is the person to ask 22:42
tyil 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
lizmat codesections 23:40
codesections the reason BagHash.add returns Nil, is that it cannot fail gracefully
I'd say it cannot fail at all, but that would be hubris 23:41
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
23:42 dogbert17 left 23:43 dogbert17 joined
codesections hmm, yeah, that all makes sense. And the same logic would also apply to something like &sleep (which also returns Nil) 23:43
japhb tyil: OK, thanks for the info. 23:44
lizmat to my mind, Nil is about indicating the absence of a value
in the case of BagHash.add, there's just nothing to return
codesections 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.
lizmat also: Nil indicates to the compiler it should not have to evaluate the return value
codesections Yeah, agreed on all points 23:45
I wasn't saying to change away from Nil for those fns
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:46
but it's more explicit about being a successful absence of a value 23:47
lizmat well, if you see Nil in a return constraint, it *is* an OK :-)
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
codesections 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:51
lizmat sleep& 23:58

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!