|
🦋 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. |
|||
|
01:01
MasterDuke joined
08:01
sena_kun joined
|
|||
| lizmat | greppable6: duckmap | 12:10 | |
| greppable6 | lizmat, 16 lines, 2 modules: gist.github.com/f50041df2b80d094f2...f2750daae1 | ||
| lizmat | not very popular / understood it seems | ||
| Geth | rakudo/main: af6df81601 | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.rakumod Don't bother calling op in duckmap on sig failure If the signature of the op doesn't accept the value, then there's no point in trying to call it, as that will only create an exception. This will make sure that any LEAVE phaser in the op will *not* be run if the signature didn't match the given value. |
12:20 | |
| lizmat | m: dd (^10).lazy.map({ $_ == 5 ?? (last) !! $_ }) | 12:39 | |
| camelia | (0, 1, 2, 3, 4).lazy.Seq | ||
| lizmat | m: dd (^10).lazy.nnodemap({ $_ == 5 ?? (last) !! $_ }) | 12:40 | |
| camelia | No such method 'nnodemap' for invocant of type 'Seq'. Did you mean 'nodemap'? in block <unit> at <tmp> line 1 |
||
| lizmat | m: dd (^10).lazy.nodemap({ $_ == 5 ?? (last) !! $_ }) | 12:41 | |
| camelia | Failure.new(exception => X::Cannot::Lazy.new(action => "nodemap", what => Any)) | ||
| lizmat | so why does .map allow lazy iterators, and nodemap doesn't ? | ||
| greppable6: nodemap | |||
| greppable6 | lizmat, 12 lines, 1 module: gist.github.com/d8325c439ff1392ca8...b2fe640083 | ||
| Geth | rakudo/lizmat-deepmap: ecd656825c | (Elizabeth Mattijsen)++ | src/core.c/Any-iterable-methods.rakumod Rince, repeat for .nodemap |
13:08 | |
| rakudo/lizmat-deepmap: 4 commits pushed by (Elizabeth Mattijsen)++ | 13:10 | ||
|
13:20
finanalyst joined
|
|||
| lizmat | greppable6: flatmap | 14:10 | |
| greppable6 | lizmat, 77 lines, 28 modules: gist.github.com/cc98ccb28c09c744d7...17442f4450 | ||
| lizmat | wow, that's 28 modules that will stop working in 6.e :-( | 14:11 | |
|
14:27
MasterDuke left
|
|||
| [Coke] | I note zef is on that list, ugexe | 14:29 | |
| also, why is it "perl6/doc" and not "Raku/doc" ? | 14:30 | ||
| raku/doc shouldn't be a module; it was at one point, is that where it's coming from? | 14:31 | ||
| finanalyst | [Coke] lizmat: I just you both an email about relative priorities | 14:44 | |
| [Coke] | replied | 15:11 | |
| the raku/doc link is pointing at a six year old commit, I think (and is all docs regardless) | 15:13 | ||
| finanalyst: thanks for keeping us in the loop, appreciate it. | 15:14 | ||
| ugexe | [Coke]: nah, i just don't think using greppable6 is useful in this case. zef hasn't used flatmap in years, which implies greppable6 is searching all versions, including old ones no one would be using anymore | 15:20 | |
| [Coke] | Maybe if it also had a column for latest version of module there'd at least be context. | 15:37 | |
| ... or even the version it got the hit. | 15:38 | ||
| oh - it's doing git grep, not grep. | 15:40 | ||
| so there's only one ugexe/zef it's grepping, but since it's git grep... | 15:41 | ||
| does github.com/lizmat/raku-all-modules need to update submodules? | 15:42 | ||
| er, those are subrepos. | 15:43 | ||
| so, seeing hits on cpan/ugexe/zef, but also in github/ugexe/zef - I don't have subrepo support setup so can't see more | 15:48 | ||
| (wow is this slow) | 15:51 | ||
| This is the commit raku-all-modules is tied to: | 15:53 | ||
| github.com/ugexe/zef/commit/a1d6d5439 | |||
| from 2019. | |||
| and greppable link is to moritz's version of raku-all-modules, which is redirecting to lizmats? I think? | 15:55 | ||
| lizmat | re flatmap, after some research, it looks like the documentation is wrong | 16:33 | |
| in 095f7f02 (august 2015), jnthn changed flatmap into .map(&blodk).flat | 16:34 | ||
| basically providing the functionality that the documentation suggests | |||
| [Coke]: maybe something like: .flatmap(&block) is short for .map(&block).flat | 16:36 | ||
| apparently the behaviour changed with the GLR, and has been stable since Christmas, judging from the git blame innfo | 16:37 | ||
| [Coke] | so the deprecation is still in effect, though? | 16:39 | |
| lizmat | there's no deprecation message | 16:40 | |
| and the behaviour is already what is suggested, so I don't think we need to deprecate .flatmap | |||
| just document it as short for .map().flat | 16:41 | ||
| I mean, we still *could* deprecate it I guess | |||
| a deprecation message is added easily enough :-) | 16:42 | ||
| [Coke] | it's been listed as deprecated in the docs for ages. | ||
| So remove that from the docs and simplify the examples? I can do that | 16:43 | ||
| Done. | 16:49 | ||
|
17:17
finanalyst left
19:15
finanalyst joined
22:03
finanalyst left
22:54
sena_kun left
|
|||