timo that seems at least unusual to me, is that inspired by something already in the language? nothing springs to mind immediately? i mean moving the block from positional to named parameter? 00:04
ab5tract It’s reversible if found to be contentious 00:21
I just think &.map: :flat(&block) is nicer than 00:22
@.map: &block, :flat 00:23
ugexe to me that feels like it is a bit inconsistent 00:24
ab5tract It’s probably only in main by accident anyway, so if there’s any resistance we can nuke it
ugexe what if there is some other operation different but equally useful as flat that we would want to allow in the future? 00:25
:flat(:foo(&block))? :flat(&block), :foo(&block)? impossible?
ab5tract ?
Then it would be another named argument candidate? 00:26
ugexe but you're saying there will be :flat(&block)
what if i want :flat and :foo
ab5tract Then make a map candidate with both?
ugexe im arguing it cant be done in a consistent way 00:27
or rather im asking how can it be done in a consistent way
timo well, it's the day after the release, so there's a bunch of time for people who run blead to try it out. also it's on the eval bots now too so we can play around on channel 00:28
ab5tract It’s late and I don’t understand how it is inconsistent 00:29
ugexe let me try to rephrase in case i misunderstand
We now have `&.map: :flat(&block)`. Assume in the future we have some other `:foo` thing we want to apply to map. `&.map: &block, :flat, :foo` makes sense, but how does that work when wanting to use the block-as-named-argument format? `&.map: :flat(&block), :foo(&block)` seems not ideal because you either pass in the same block twice or you potentially pass in different blocks (and we have to 00:31
define that behavior)
ab5tract FWIW I didn’t merge this, but seeing it in main I updated it
Ok, so first off &.map was a typo, so apologies if that is contributing to confusion 00:32
timo i don't have a problem with experimental things in main, as long as the tests are clean
as you said, reverting is cheap and easy 00:33
ab5tract Re: the semantics of adding a second block to map feels orthogonal to me
timo i think that was less about a second block, but more about a second kind-of-behaviour
ab5tract Like, that’s up to the implementation of map(:&flat, :&foo!) 00:34
ugexe i might even argue the underlying issue is that :flat is an argument to main at all. going back to my argument of adding other useful adverbs you then have the question of what order do those get run in
timo compare to how adverbs combine with the postcircumfixes for example, :kv:exists
ugexe s/to main/to map/
timo also, sometimes we like passing False or True to a given adverb depending on dynamic context, then we'd have .map(:flat($maybe), &block) if the flat named argument is kept for just signalling flat vs "structured" 00:35
ab5tract I still fail to see how this impacts the current patch. For example, :&flat already has an optional named argument
timo and there it's a bit more obvious how map(:flat($want-flat), :duck($want-duck), &block) woul dbehave 00:36
ab5tract This is not an argument that is shared by other map candidates
timo right, we used to have to .duckmap or .flatmap by hand 00:37
.o( Duck What I Map ) 00:38
ab5tract The bool part makes some sense to me but I am not personally sure whether it is more clear, or worth the ergonomic impact 00:39
Anyway, good food for thought 00:40
timo i'm not fully awake any more, but another thing came to mind, which is how blocks as named arguments are used in other places of the language at the moment. i'm mostly thinking of :by, :as, :with in methods like grep or first and such
ab5tract But this is map.. it’s only job is to take a single block 00:41
timo from just a syntactic standpoint, it does seem more fluent to read `.map: flat => * + 1` over `.map: :flat, * + 1` but i think you can also write `.map: :flat * + 1` perhaps? 00:42
ab5tract Maybe I should just learn to love smashedcasemethods
timo m: say [1,[2,3]].map: :flat * + 1
camelia Cannot resolve caller Numeric(Pair:D: ); none of these signatures matches:
(Mu:U \v:: *%_)
in block <unit> at <tmp> line 1
timo i guess that needs to be deep or duck for that to work like this
m: dd [1,2,3].map: :flat { $_ xx $_ } 00:43
camelia ===SORRY!=== Error while compiling <tmp>
Unexpected block in infix position (missing statement control word before the expression?)
at <tmp>:1
------> dd [1,2,3].map: :flat<HERE> { $_ xx $_ }
expecting any of:
infix
inf…
timo m: dd [1,2,3].map: :flat, { $_ xx $_ }
camelia ((1,).Seq, (2, 2).Seq, (3, 3, 3).Seq).Seq
timo m: dd [1,2,3].map: :flat({ $_ xx $_ })
camelia (1, 2, 2, 3, 3, 3).Seq
timo right, i need the previous commit id for the first one
evalable6: 24b4001e63 dd [1,2,3].map: :flat { $_ xx $_ } 00:44
evalable6 (exit code 1) ===SORRY!=== Error while compiling /tmp/ishq2LRDqO
Confused
at /tmp/ishq2LRDqO:1
------> 24<HERE>b4001e63 dd [1,2,3].map: :flat { $_ xx $
expecting any of:
whitespace
timo evalable6: 24b4001e63 dd [1,2,3].map: :flat, { $_ xx $_ }
evalable6 (exit code 1) ===SORRY!=== Error while compiling /tmp/9VgdPwsPUB
Confused
at /tmp/9VgdPwsPUB:1
------> 24<HERE>b4001e63 dd [1,2,3].map: :flat, { $_ xx
expecting any of:
whitespace
timo not like that huh
evalable6: help
evalable6 timo, Like this: evalable6: say ‘hello’; say ‘world’ # See wiki for more examples: github.com/Raku/whateverable/wiki/Evalable
ab5tract timo: ah, throw those candidates into another commit and we can play around all the options?
timo i mean, i think they already are, right?
committable6: 24b4001e63 dd [1,2,3].map: :flat { $_ xx $_ } 00:45
committable6 timo, gist.github.com/9cd0247afa6655b1a8...51165d3a1e
timo committable6: 24b4001e63 dd [1,2,3].map: :flat, { $_ xx $_ }
committable6 timo, ¦24b4001: «(1, 2, 2, 3, 3, 3).Seq␤»
ab5tract Right, I forgot you could EVAL against whatever commits
timo so yeah, you do actually have to put the comma there
and if you put the :flat after * + 1 it will apply to the infix:<+> instead of the map call i guess? 00:46
ab5tract Indeed
timo committable6: 24b4001e63 dd [1,2,3].map: { $_ xx $_ } :flat
committable6 timo, ¦24b4001: «===SORRY!=== Error while compiling /tmp/h__4UWJwcE␤You can't adverb { $_ xx $_ }␤at /tmp/h__4UWJwcE:1␤------> dd [1,2,3].map: { $_ xx $_ } :flat<HERE><EOL>␤ expecting any of:␤ pair value␤ «exit code = 1»»
timo committable6: 24b4001e63 dd [1,2,3].map: * + 1 :flat
committable6 timo, ¦24b4001: «===SORRY!=== Error while compiling /tmp/fY9NXTiDCu␤You can't adverb +␤at /tmp/fY9NXTiDCu:1␤------> dd [1,2,3].map: * + 1 :flat<HERE><EOL>␤ expecting any of:␤ pair value␤ «exit code = 1»»
timo yep
committable6: 24b4001e63 dd [1,2,3].map(* + 1):flat
committable6 timo, ¦24b4001: «(2, 3, 4).Seq␤»
timo this one ain't so bad 00:47
ab5tract This is why u was asking if anyone else wished for @a.map:adverb *.&foo syntax some nights ago
timo right, i remember
and then i veered off into that little tangent with the map emoji 00:48
ab5tract Yeah, it’s the least bad imo but I don’t like finding the :flat at the end as much as seeing it at the beginning
Indeed:)
timo right, slightly related to the "end-weight problem", and why regex modifiers go in front of regexes now instead of at the end 00:49
and after :flat you can't just add more .foo method calls
can you do it with whitespace (or unwhitespace)?
ab5tract Alright, I have to try and sleep tonight. It’s been getting (even more) out of hand recently
timo committable6: 24b4001e63 [1,2,3].map(* + 1):flat .say 00:50
committable6 timo, ¦24b4001: «(2 3 4)␤»
timo ok, that's neat
committable6: 24b4001e63 [1,2,3].map(* + 1):flat.say
committable6 timo, ¦24b4001: «(2 3 4)␤»
timo that's a little unexpected
yeah i was also going to go to bed, good knight ab5tract 00:51
and good knight ugexe as well :)
ab5tract committable6: 24b4001e63 “okkookko”.comb.rotor(2).map(* + 1):flat.say
committable6 ab5tract, ¦24b4001: «(3 3 3 3)␤»
ab5tract committable6: 24b4001e63 “okkookko”.comb.rotor(2).map(*.reverse):flat.say 00:52
committable6 ab5tract, ¦24b4001: «(k o o k k o o k)␤»
ab5tract Wow :) 00:53
(Don’t forget to test :flat against something flattenable tho!)
timo now to write a slang where any `.foo(...):bar` gets replaced by `.barfoo(...)`
committable6: 24b4001e63 “okkookko”.comb.rotor(2).map(*.reverse):flat.&dd 00:54
committable6 timo, ¦24b4001: «===SORRY!=== Error while compiling /tmp/vRE2uz02Cd␤Malformed postfix call␤at /tmp/vRE2uz02Cd:1␤------> okko”.comb.rotor(2).map(*.reverse):flat.<HERE>&dd␤ «exit code = 1»»
timo d'oh :)
committable6: 24b4001e63 “okkookko”.comb.rotor(2).map(*.reverse):flat.&dd()
committable6 timo, ¦24b4001: «===SORRY!=== Error while compiling /tmp/1Wp6zJnng3␤Malformed postfix call␤at /tmp/1Wp6zJnng3:1␤------> okko”.comb.rotor(2).map(*.reverse):flat.<HERE>&dd()␤ «exit code = 1»»
timo committable6: 24b4001e63 “okkookko”.comb.rotor(2).map(*.reverse):flat .&dd()
committable6 timo, ¦24b4001: «===SORRY!=== Error while compiling /tmp/BidZbdLnub␤Malformed postfix call (only basic method calls that exclusively use a dot can be detached)␤at /tmp/BidZbdLnub:1␤------> kko”.comb.rotor(2).map(*.reverse):flat .<HERE>&dd()␤ «exit code = 1»»
timo committable6: 24b4001e63 “okkookko”.comb.rotor(2).map(*.reverse):flat\.&dd()
committable6 timo, gist.github.com/2d226af9e3bd12922c...71c6142362
timo committable6: 24b4001e63 “okkookko”.comb.rotor(2).map(*.reverse):flat\ .&dd()
committable6 timo, ¦24b4001: «===SORRY!=== Error while compiling /tmp/hkDoLFp9Qe␤Malformed postfix call (only basic method calls that exclusively use a dot can be detached)␤at /tmp/hkDoLFp9Qe:1␤------> ko”.comb.rotor(2).map(*.reverse):flat\ .<HERE>&dd()␤ «exit code = 1»»
timo it's not as universal as i thought, huh.
anyway 00:55
committable6: 24b4001e63 dd “okkookko”.comb.rotor(2).map(*.reverse):flat.self
committable6 timo, ¦24b4001: «("k", "o", "o", "k", "k", "o", "o", "k").Seq␤»
timo committable6: 24b4001e63 dd “okkookko”.comb.rotor(2).map(*.reverse).self
committable6 timo, ¦24b4001: «(("k", "o").Seq, ("o", "k").Seq, ("k", "o").Seq, ("o", "k").Seq).Seq␤»
timo committable6: 24b4001e63 “okkookko”.comb.rotor(2).map(*.reverse).say
committable6 timo, ¦24b4001: «((k o) (o k) (k o) (o k))␤»
timo sleep time!
ab5tract dd could very well be an odd duck here
m: “foo” ==> dd() 00:56
camelia "foo"
ab5tract Welp, that’s all my brain cans take for now
I’ll open a problem solving ticket tomorrow or soon 00:57
Thanks for the feedback ugexe and timo
Geth Blin: e7b00c0586 | (Will Coleda)++ | 2 files
Update module links to raku.land

Closes #36
01:07
[Coke] Should make the next blin run slightly easier to process. 01:11
jdv patrickb: thanks 06:28
[Coke]: you see those from patrickb?
10:16 sena_kun joined
lizmat re merging the adverbial maps: it wasn't marked as draft, had no negative comments and felt like a nice addition 10:38
and it can still be reverted
ab5tract lizmat ++ 11:06
lizmat ugexe: "why ownup instead of own-up?" because I mistakenly thought that was a word as well 11:07
Geth Algorithm-Soundex/main: c31df80148 | (Elizabeth Mattijsen)++ | 14 files
CI test in preparation for a Raku Community release
11:08
Algorithm-Soundex/main: d5439a05e9 | (Elizabeth Mattijsen)++ | 4 files
0.2
11:09
rakudo/main: 70d66b983a | (Elizabeth Mattijsen)++ | 4 files
Change "ownup" to "own-up"

  ugexe++ for the nudge
11:17
rakudo/lower-bound-for-revision-gating: 92607f18f2 | ab5tract++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Don't forget a key thing to ignore
13:10
ab5tract A *huge* amount of gratitude going out to everyone who plugged away at getting the rakudo.git CI/CD into it's current shape! 13:11
I am not sure if it is new, or I was just too stupid previously, but I was just able to quickly drill down into some failures via the Azure UI and get the precise failure mode. I feel like this used to take a whole lot of scrolling and searching 13:12
lizmat nice! 13:13
not sure either: I had basically given up on rakudo's CI reliability
Geth WebService-Slack-Webhook/main: 22 commits pushed by Nic++, (Nic Q)++
review: github.com/raku-community-modules/...68e2ec1719
13:18
WebService-Slack-Webhook/main: 5c42e94410 | (Elizabeth Mattijsen)++ | 16 files
CI test in preparation for a Raku Community release
13:34
WebService-Slack-Webhook/main: 05c0a6c053 | (Elizabeth Mattijsen)++ | 2 files
0.1.3
13:38
ab5tract lizmat: I'm feeling like CI trust is back on the menu :D 13:50
lizmat hehe 13:51
Geth rakudo/main: 7c7ad5bd62 | ab5tract++ | 3 files
Add lower-bounding for the revision-gated trait

This adds a finishing touch to revision gating: the ability to use revision gating to evolve methods that otherwise have the exact same signature.
The is done by adding the trait to the candidate that is to be replaced: ... (23 more lines)
15:33
rakudo/main: 0e9a2d73e3 | ab5tract++ | src/Perl6/bootstrap.c/BOOTSTRAP.nqp
Don't forget a key thing to ignore
ab5tract Ah, forgot to squash, luckily it wasn’t a big list of commits 15:34
Btw, I think Windows checks are failing due to the repl reconfiguration. I will adjust the test and see if that fixes it 15:35
Geth rakudo/adjust-failing-repl-test: 6cc7a88701 | ab5tract++ | t/02-rakudo/15-gh_1202.t
Fix failing test on Windows
15:38
rakudo: ab5tract++ created pull request #5735:
Draft: Fix failing test on Windows
15:41
Brazilian-FederalDocuments/main: a8c1976959 | (Elizabeth Mattijsen)++ | 19 files
CI test in preparation for a Raku Community release
17:59
Brazilian-FederalDocuments/main: d36f415d81 | (Elizabeth Mattijsen)++ | 2 files
0.1.1
18:01
vCard-Parser/main: 160ac59c69 | (Elizabeth Mattijsen)++ | 23 files
CI test in preparation for a Raku Community release
18:22
vCard-Parser/main: c86a4264fa | (Elizabeth Mattijsen)++ | 2 files
0.0.2
18:25
Data-StaticTable/main: 52c0178f5b | (Elizabeth Mattijsen)++ | 28 files
CI test in preparation for a Raku Community release
19:44
Data-StaticTable/main: 050ba28b0a | (Elizabeth Mattijsen)++ | 5 files
Try to fix strange failure on Windows only
19:59
Data-StaticTable/main: 1cc7ec337b | (Elizabeth Mattijsen)++ | 3 files
0.1.1
20:02
22:51 sena_kun left
lizmat ok, there's still 400+ modules that need probably need to be moved to raku community moduels 23:58
maybe I should set up a separate channel #raku-community-modules
and have Geth report there ?