|
🦋 Welcome to the IRC channel of the core developers of the Raku Programming Language (raku.org #rakulang). This channel is logged for the purpose of history keeping about its development | evalbot usage: 'm: say 3;' or /msg camelia m: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm Set by lizmat on 8 June 2022. |
|||
| jdv | nine: nice | 00:33 | |
|
04:20
sivoais joined
|
|||
| patrickb | For those that didn't notice / forgot: That's the Raku ecosystem grant application news.perlfoundation.org/post/raku-...stem-tonyo | 07:29 | |
|
08:12
sena_kun joined
08:46
sena_kun left
08:52
finanalyst joined
|
|||
| lizmat | TIL that deepmap doesn't actuall support FIRST / NEXT / LAST phasers | 09:41 | |
| nor blocks with multiple args | |||
| ab5tract | :( | 10:28 | |
| lizmat | actually, no multiple args makes sense when you start thinking about it | 10:31 | |
| and not supporting phasers, by consequence, also, as you'd need to decide whether or not to fire them when recursinng | 10:32 | ||
| ab5tract | Well, I still think multiple args is the wrong approach in regular maps and a relatively serious problem when used in greps | 10:37 | |
| lizmat | fwiw, .kv.map( -> $key, $value { ... } ) feels valid to me | 10:38 | |
| ab5tract | But I still shed a tear or two for consistency’s sake | ||
| I think that is a really small reason to implement such a significant departure from the expected semantics of map: processing a single element from a list at a time | 10:40 | ||
| lizmat | m: my %h = a => 42, b => 666; %h .= map: -> $key, $value { $key.uc => $value }; dd %h | ||
| ab5tract | The original approach of having each k/v be in its own list makes more sense to me | ||
| camelia | No such method 'uc' for invocant of type 'Pair' in block <unit> at <tmp> line 1 |
||
| lizmat | m: my %h = a => 42, b => 666; %h = %h.kv.map: -> $key, $value { $key.uc => $value }; dd %h | ||
| camelia | {:A(42), :B(666)} | ||
| ab5tract | m: my %h = :42a, :666b; dd (%h.keys Z %h.values).map: -> [$k,$v] { $k.succ => $v.pred } | 10:45 | |
| camelia | (:b(41), :c(665)).Seq | ||
| lizmat | ab5tract: if falls out of for -> $a, $b { } semantics | 10:46 | |
| as "for foo { ... }" is really just foo.map({...}).iterator.sink-all under the hood | 10:47 | ||
| ab5tract | Maybe there are performance implications I am not aware of… | ||
| lizmat | performance implications of what ? | 10:48 | |
| ab5tract | Making .kv return a flat list instead of a list of tuples | 10:49 | |
| See my invocation above | |||
| s/tuples/lists/ | 10:50 | ||
| lizmat | that would be about 3x as slow, is my guess | ||
| ab5tract | You mean that implementation of .kv or using lists of lists in general? | 10:51 | |
| lizmat | as .kv is just about producing values, and Z creates new values and thus allocationns | ||
| list of lists I'd say | |||
| ab5tract | Seems a bit shocking, but I believe you | 10:52 | |
| lizmat | eh, I could be wrong :-) | 10:53 | |
| ab5tract | R#1661 — here’s some discussion about how this feature interacts with Greg | 10:55 | |
| linkable6 | R#1661 [open]: github.com/rakudo/rakudo/issues/1661 Remove .grep with .count > 1 Callables | ||
| ab5tract | Erm, grep, not Greg :) | ||
| lizmat | fwiw, depracating would be an option | 10:59 | |
| ab5tract | My impulse for proposing to do so would be for consistency, both internally and wrt external expectations about how these functional thingies usually behave | 11:04 | |
| lizmat: do those phasers in deepmap result in errors/warnings or are they silently ignored? | 11:05 | ||
| lizmat | silently ignored | 11:06 | |
| ab5tract | Ouch :/ | 11:20 | |
| That should be adjusted I think | |||
| lizmat | yeah, I'll add some checks for that | 11:22 | |
| Geth | rakudo/lizmat-deepmap: 65f39a512a | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.rakumod Check expectations of .deepmap - Add warning if the Callable has a FIRST, NEXT or LAST phaser, as these are not supported by .deepmap - Die if the number of arguments of the Callable is not 1: only Callables that accept 1 are currently supported |
13:58 | |
| rakudo: lizmat++ created pull request #5592: Check expectations of .deepmap |
|||
| rakudo/main: e2fa55b9b1 | (Elizabeth Mattijsen)++ | src/Raku/Grammar.nqp RakuAST: allow for =for formula |
17:28 | ||
|
17:51
sena_kun joined
|
|||
| Geth | rakudo/lizmat-deepmap: 71550aaa79 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.rakumod Rince and repeat for duckmap |
18:23 | |
|
18:26
finanalyst left
|
|||
| lizmat | in he WTF department of today: | 18:52 | |
| m: dd (^6).duckmap(-> $_ where * %% 5 { ENTER say "e$_"; LEAVE say "l$_"; $_ + 42 }) | |||
| camelia | e0 (42, proto method defined (Mu $:: |) {*}, 2, 3, 4, 47) l0 l1 l2 l3 l4 e5 l5 |
||
| lizmat | 1. even though 4/5 iterations do not ENTER, they *do* fire the LEAVE phaser | 18:53 | |
| 2. where on earth does the: proto method defined (Mu $:: |) {*} value come from | 18:54 | ||
| I guess 1 is another expression of: | 19:05 | ||
| m: sub a(Str:D $) { LEAVE say "goodbye" }; a 42 | |||
| camelia | goodbye Type check failed in binding to parameter '<anon>'; expected Str but got Int (42) in sub a at <tmp> line 1 in block <unit> at <tmp> line 1 |
||
| lizmat | aka: LEAVE is called even if we didn't make it into the body of sub yet | 19:06 | |
| which leaves 2. | 19:07 | ||
| afk& | |||
|
19:20
finanalyst joined
21:38
finanalyst left
22:33
sena_kun left
|
|||
| Geth | nqp/main: 7d01903329 | (Elizabeth Mattijsen)++ | tools/templates/MOAR_REVISION Bump MoarVM for fix in return / LEAVE interaction patrickb++ |
23:25 | |
| rakudo/main: f85de735d6 | (Elizabeth Mattijsen)++ | tools/templates/NQP_REVISION Bump NQP for fix in return / LEAVE interaction patrickb++ |
23:37 | ||