This channel is intended for people just starting with the Raku Programming Language (raku.org). Logs are available at irclogs.raku.org/raku-beginner/live.html Set by lizmat on 8 June 2022. |
|||
00:59
jgaz left
01:28
frost joined
01:29
frost left
01:30
frost joined
01:32
frost left,
frost joined
01:33
frost left
01:52
QhpAptyj9hj0RQwM left
02:33
frost joined
02:39
frost left
03:09
frost joined
03:10
frost left
03:11
frost joined
03:15
frost left
03:23
rf left
05:11
MasterDuke left
06:03
Heptite left
09:04
dakkar joined
09:39
ab5tract joined
10:55
ab5tract left
11:57
ab5tract joined
12:41
ab5tract left
13:30
Heptite joined
13:46
rf joined
14:16
jgaz joined
15:47
ab5tract joined
16:21
Nemokosch joined
16:23
Nemokosch left
16:33
QhpAptyj9hj0RQwM joined
16:41
deoac joined
|
|||
deoac | (%h{.key} = .value) for @s | 16:42 | |
will convert Seq \@s into Hash %h | |||
is there a more concise way of doing this? | |||
\@s is a Seq of Pairs | |||
lizmat | my %h = @s | 16:43 | |
m: my @a = a => 42, b => 666; my %h = @a; dd %h | |||
camelia | Hash %h = {:a(42), :b(666)} | ||
lizmat | if a key occurs more than once, the last one wins | 16:44 | |
if you don't like that, you could use .push | 16:45 | ||
m: my @a = a => 42, b => 666, a => 137; my %h; %h.push($_) for @a; dd %h | 16:46 | ||
camelia | Hash %h = {:a($[42, 137]), :b(666)} | ||
lizmat | deoac ^^ | 16:47 | |
Nemokosch | m: my @a = a => 42, b => 666, a => 137; @a.classify(*.key, as => *.value).&dd | ||
Raku eval | (my Any %{Any} = :a($[42, 137]), :b($[666])) | ||
Nemokosch | not quite the same but might be useful if you are counting on multiple keys | 16:48 | |
lizmat | that has the (dis)advantage of always creating arrays | 16:49 | |
16:58
ab5tract left
|
|||
deoac | discord-raku-bot How did you use .key and .value? My system requires .keys and .values? Rakudo v2022.12, v6.d | 17:02 | |
My apologies, @a actually looks like: | 17:03 | ||
[{a => 42} {b => 666} {c => 3.14}] | |||
m: my @a = [ {a => 42}, {b => 666}, {c => 3.14} ]; my %h = @a; dd %h | 17:04 | ||
camelia | Odd number of elements found where hash initializer expected: Found 3 (implicit) elements: Last element seen: ${:c(3.14)} in block <unit> at <tmp> line 1 |
||
lizmat | ah, doac, so you have a list of hashes | 17:05 | |
that's nor pairs | |||
deoac | right, my mistake | ||
lizmat | so, does each of these hashes only have 1 key? | ||
deoac | yes, guaranteed | ||
lizmat | m: my %h = [{a => 42},{b => 666},{c => 3.14}].map: |*.pairs; dd %h | 17:06 | |
camelia | Hash %h = {:a(42), :b(666), :c(3.14)} | ||
lizmat | m: my %h = [{a => 42},{b => 666},{c => 3.14}].map: |*; dd %h | 17:07 | |
camelia | Hash %h = {:a(42), :b(666), :c(3.14)} | ||
lizmat | slipping a hash means creating a slip of pairs | 17:08 | |
deoac | Interesting, I've never used Slips before. Thank you. | 17:14 | |
17:15
ab5tract joined
|
|||
lizmat | docs.raku.org/type/Slip | 17:17 | |
17:35
ab5tract left
17:37
dakkar left
17:43
ab5tract joined
18:06
ab5tract left
20:10
Guest2981 joined
20:23
QhpAptyj9hj0RQwM left
22:03
jgaz left
22:07
Guest2981 left
22:33
deoac left
23:14
habere-et-disper joined
|
|||
habere-et-disper | Is DateTime accurate? I tried a gigasecond: | 23:19 | |
m: DateTime.new( '2011-04-25' ).later: seconds => 10**9 | |||
camelia | ( no output ) | ||
habere-et-disper | But was expecting something three second later, see: | ||
2043-01-01T01:46:40 | |||
github.com/exercism/problem-specif...-data.json | 23:20 | ||
Which is correct? | |||
m: say DateTime.new( '2011-04-25' ).later: seconds => 10**9 | |||
camelia | 2043-01-01T01:46:37Z | ||
Nemokosch | the funny thing is that we can't actually say the (absolute) after that amount of (relative) time spent | 23:25 | |
of course it makes one think what created the difference but at the same time, talking about a set result is a bit nonsensical | 23:26 | ||
habere-et-disper | I thought it might be leap seconds. | 23:32 | |
Nemokosch | it might indeed be leap seconds - however, 1. there is no way to know for sure when and how many leap seconds will be added 2. it's cancelled from the year 2035 from what I heard, in favor of doing bigger corrections significantly less often | 23:59 |