🦋 Welcome to the former MAIN() IRC channel of the Raku Programming Language (raku.org). This channel has moved to Libera (irc.libera.chat #raku)
Set by lizmat on 23 May 2021.
00:02 reportable6 left 00:04 reportable6 joined
ugexe SmokeMachine: seems liek a rakudo regression 00:06
raydiak I can reproduce, latest zef does indeed seem to be broken on current rakudo HEAD 00:08
as far as I can tell, the commonality seems to be that modules with dependencies fail, while modules with an empty depends array install successfully 00:09
I'm trying to hunt it down to something easily bisected, but here is a stack trace: gist.github.com/raydiak/df9f588424...2a1d74d963 00:13
00:23 perlbot left, simcop2387 left
raydiak bisectable6: old=2021.06 new=HEAD ((),()).sort 00:31
bisectable6 raydiak, Bisecting by output (old=2021.06 new=50bd171) because on both starting points the exit code is 1
raydiak, bisect log: gist.github.com/9110e2118d981d434c...3500eb5852
raydiak, (2021-07-20) github.com/rakudo/rakudo/commit/50...1a28933fb4
00:32 perlbot joined
raydiak bisectable6: ((),()).sort 00:32
bisectable6 raydiak, Will bisect the whole range automagically because no endpoints were provided, hang tight
raydiak, Output on all releases: gist.github.com/100c8775889895cb0e...1827afd07b
raydiak, Bisecting by output (old=2021.06 new=50bd171) because on both starting points the exit code is 1
raydiak, bisect log: gist.github.com/141e25e53223bdf91c...4dbd10c6be
raydiak, (2021-07-20) github.com/rakudo/rakudo/commit/50...1a28933fb4
raydiak, Bisecting by output (old=2019.03.1 new=2019.07.1) because on both starting points the exit code is 1
raydiak, bisect log: gist.github.com/57f73dd81ecc40ac7a...be4cee655d 00:33
raydiak, (2019-04-09) github.com/rakudo/rakudo/commit/a2...07b4a6ba04
raydiak, Bisecting by exit code (old=2018.03 new=2018.04.1). Old exit code: 0
raydiak, bisect log: gist.github.com/3349cf72360c6bfba9...16855354a3
raydiak, (2018-03-31) github.com/rakudo/rakudo/commit/12...21aef23419
00:33 simcop2387 joined
bisectable6 raydiak, ⚠ New output detected, please review the results manually 00:33
raydiak, Output on all releases and bisected commits: gist.github.com/bf447db122fd449d8f...123754dc4d
raydiak um, hm...that construct has thrown one weird error or another since 2018.04? 00:35
ugexe its definitely that commit though 00:36
raydiak right...I guess the question then is why .dist.api is now always `()` at github.com/ugexe/zef/blob/master/l...kumod#L149 00:37
that's the line triggering the error. yes the message changed with that recent cmp optimization, but that doesn't explain why it wasn't manifesting the other errors before, does it? 00:39
bisectable6: say () cmp () 00:54
bisectable6 raydiak, Will bisect the whole range automagically because no endpoints were provided, hang tight
raydiak, Output on all releases: gist.github.com/1c14ed74b5f258d224...5825be8405
raydiak, Bisecting by exit code (old=2021.06 new=50bd171). Old exit code: 1
raydiak, bisect log: gist.github.com/4e51187c6ce56e9fce...41da51ef21
raydiak, (2021-07-20) github.com/rakudo/rakudo/commit/50...1a28933fb4
raydiak, Bisecting by output (old=2019.03.1 new=2019.07.1) because on both starting points the exit code is 1
raydiak, bisect log: gist.github.com/e8f3f0630348c7de19...f3d27b8f94 00:55
raydiak, (2019-04-09) github.com/rakudo/rakudo/commit/a2...07b4a6ba04
raydiak, Bisecting by exit code (old=2018.03 new=2018.04.1). Old exit code: 0
raydiak, bisect log: gist.github.com/99d89588d9b038e5fc...e85690ea70
raydiak, (2018-03-31) github.com/rakudo/rakudo/commit/12...21aef23419
raydiak, ⚠ New output detected, please review the results manually
raydiak, Output on all releases and bisected commits: gist.github.com/73132247186e3d78ab...da5c9c6a4c
raydiak apparently all the () in zef aren't anything new. still don't get why it wasn't triggering the old errors before, but here's what I reported: github.com/rakudo/rakudo/issues/4471 01:12
01:12 Doc_Holliwood left 01:30 discord-raku-bot left 01:31 discord-raku-bot joined
justsomeguy Hi #raku. I just read through a few dozen examples of different programming tasks on rosettacode and noticed that raku is consistently the most expressive language among all of the examples listed. That's pretty impressive. 01:34
raydiak hello, justsomeguy. wide dynamic range of expression was a core concept of the design from the very start, and an enormous amount of work has gone into making it a useful reality 01:41
so thanks for noticing :)
justsomeguy :D 01:49
02:31 linkable6 left, evalable6 left 02:32 linkable6 joined, evalable6 joined 03:11 justsomeguy left 04:11 unicodable6 left, greppable6 left, committable6 left, reportable6 left, sourceable6 left, squashable6 left, benchable6 left, linkable6 left, bloatable6 left, statisfiable6 left, evalable6 left, tellable6 left, shareable6 left, quotable6 left, coverable6 left, notable6 left, releasable6 left, nativecallable6 left, bisectable6 left, benchable6 joined, unicodable6 joined, coverable6 joined, quotable6 joined 04:12 committable6 joined, tellable6 joined, greppable6 joined 04:13 bisectable6 joined, statisfiable6 joined, reportable6 joined, squashable6 joined, shareable6 joined, sourceable6 joined, bloatable6 joined, linkable6 joined 04:14 evalable6 joined, nativecallable6 joined, notable6 joined, releasable6 joined 05:05 Doc_Holliwood joined 05:13 Eddward_ left 05:14 Eddward_ joined 05:24 Eddward_ left 05:27 Doc_Holliwould joined 05:31 Doc_Holliwood left 05:47 frost joined 06:02 reportable6 left 06:05 reportable6 joined 06:25 Sgeo left 06:38 MasterDuke left 06:41 ufobat_ joined 06:58 patrickb joined 07:03 ufobat__ joined 07:06 ufobat_ left 07:15 frost left 07:16 frost joined 07:25 tejr left
mykhal is there some .comb etymology story? i always think of combinations ... 07:40
07:47 Oshawott joined
moon-child when you pull a comb through your hair, it separates it into distinct strands 07:47
and 'strands' are the name of moarvm's indirect string representation
mykhal moon-child: ok, that was another common item missing in my en dictionary 07:48
.. vocabulary
tadzik .comb predates moarvm quite a lot, but the strands still fit :) 07:49
07:49 dakkar joined
moon-child yeah 07:49
07:50 archenoth left
moon-child cf 'rope', another 'fat' string type 07:50
hmm, what's the difference between string and thread?
mykhal does not need combs almost at all, already 07:52
08:03 MasterDuke joined 08:06 MasterDuke left 08:26 Doc_Holliwould left 08:50 tejr joined 08:58 linkable6 left, linkable6 joined 09:04 MasterDuke joined
mykhal moon-child: seem to have similar origin, cord that has to be strong, vs cord madde by twisting (probably to be strong, also) 09:27
(just reading at etymonline)
perlmaros hi, how do i stack promises in raku? chaining via .then does not quite work as expected. I've compiled three examples - one in p5, one in javascript and one in raku - to illustrate my point. 09:33
p5 (ugly, very verbose and requires cpan modules) and javascript behave as expected. raku immediately passes the new promise to the second chained then, instead of waiting for the resolution of the promise and passing only the result to the next then. 09:35
09:47 Doc_Holliwould joined
perlmaros (also see promisesaplus.com/#point-41 and promisesaplus.com/#point-49 also shows the excpected behaviour) 09:57
raydiak I don't claim to have a ton of experience with promises, but I don't think 'return' does what you're expecting there. the second then receives a promise which is kept after the first then block has finished executing, not the promise you're returning from the first block. as far I can tell, any return in the then block causes its resulting promise to be broken instead of kept, and otherwise does...seemingly 10:05
docs.rakulang.site/type/Promise#method_then is rather short on details
moon-child perlmaros: sprunge.us/W7C1XK 10:06
10:08 ufobat__ left
raydiak docs.rakulang.site/language/concur...y#Promises has some more details. everywhere I see it used, the resulting value of then's promise is the last value in the block, but not actually returned by `return` 10:10
rba raydiak: please always refer to docs.raku.org. rakulang.site is only for backup. 10:12
lizmat note that `return` returns from the surrounding *sub*, **NOT** from the block it is in 10:14
`leave` has been specced for that, but nobody has implemented that yet 10:15
m: leave
camelia leave not yet implemented. Sorry.
in block <unit> at <tmp> line 1
lizmat perlmaros: remove the `return` from your example, and it seems to do what you want? 10:17
raydiak rba: sorry, my mistake. I usually fix that before pasting, just forgot to this time. I always have to use rakulang.site because of comcast screwery. they have been completely unresponsive to my request on that, btw 10:19
perlmaros raydiak/lizmat: removing the return clause gets rid of the exception, but i still only get the Promise object in the second then 10:24
raydiak .then() creates its own entirely separate promise, so the second .then is getting the promise you're explicitly returning from the first one as the .result of the first .then's promise 10:26
perlmaros raydiak: yes, the example from your paste works, but imho then blocks should be agnostic to the way they are invoked. so at least according to the promise a+ spec a new promise returned by the then block should NOT be passed directly to the next then, but only once it kept/broken 10:27
mykhal what's a+ ? 10:30
10:31 dogbert17 joined
raydiak the second block doesn't run until after the first one finishes running, which is what keeps its promise. its promise is kept with a .result value of the .in(2) promise you are explicitly creating. that could have just as well been "foobar" or any other value, you just happen to be handing it a promise. if you're looking for a 2 seond delay between the two, you could add a .then({sleep 2}) to the middle of the 10:31
cain, for example
10:32 dogbert11 left
rba raydiak: got it. Strange thing thats it‘s still not working. 10:32
raydiak or moon-child++'s solution in that paste was to await on the promise you're passing along, then call .result.result to get the result from the promise you created in the second block, which itself was the result of the first .then block's promise
rba: it turns out that it's a bizarre symptom of comcast doing a really weird way of blocking a site. in my research there were tons of legitimate sites complaining about being impacted by this. comcast is just doing their usual craptastic job of...pretty much everything 10:35
perlmaros mykhal: the promise a+ spec is followed by many languages/modules promisesaplus.com 10:37
and afaict the second block is invoked imediately - so in my case it does not wait 2 seconds. only if i run await on the promise i got there 10:39
i know that this can be solved using sleep/await/... but it feels kind of akward and adds this extra complexity to the code 10:41
raydiak that's what I'm saying. it runs directly after the first block, and receives the promise implicitly created and kept by .then(), not the promise you're explicitly creating...that one ends up as the value in the first block's promise's .result 10:42
perlmaros in the javascript and perl examples the then block is always called with the result value - regardless if if came from an previous promise, or if it came from the original keep/resolve. in raku it behaves differently - raku' behaviour leads to more complex code because my then code needs to know how it was invoked, which makes chaining promise harder 10:47
and personally i don't see an advantage to returning the raw value here. 10:48
raydiak yes, raku gives you the promise itself, not the result of the promise. you have to call .result yourself. I'd imagine the advantage is that you can also check the .status/.cause kind of stuff. but like I said, I'm definitely no expert in this area 10:51
e.g. if the first promise throws an exception, the second one is still called and can check for that and respond appropriately 10:52
lizmat channeling jnthn: Raku doesn't do the "unwrapping"/"flattening" thing that JavaScript Promises do by design. I consider the JavaScript way a mistake. 11:05
While we borrowed the name Promise because it's more Raku-ish than the .Net Task<T>, semantically we're far closer to the latter.
11:07 dogbert11 joined 11:08 dogbert17 left
raydiak I recall it being a thoroughly-considered design, but any specifics as to why our way is better? perlmaros is saying it means he now has to write `.then({do-stuff(.result)})` instead of `.then(&do-stuff)` if do-stuff() is just a normal routine expecting a normal value instead of a promise 11:09
the only one I could think of was exception handling, but I don't really use promises myself
11:13 dogbert17 joined 11:16 dogbert11 left 11:25 ufobat__ joined 12:02 reportable6 left 12:05 reportable6 joined
mykhal m: say 1.:<->; say (2, 3)>>.&(-*); say (2, 3)>>.:<-> 12:28
camelia -1
Type check failed in binding to parameter '&code'; expected Callable but got Int (2)
in block <unit> at <tmp> line 1

(-2 -3)
mykhal .. 2nd a 3rd outs are switched !? 12:31
.. (not related to (2, 3) lists) 12:32
m: say (1..5)>>.:<-> 12:33
camelia Type check failed in binding to parameter '&code'; expected Callable but got Int (1)
in block <unit> at <tmp> line 1
mykhal docs.raku.org/language/operators#m...perator%3E 12:34
12:38 ecocode_ joined
mykhal m: say (2, 3)>>.: *.:<-> # i thught it wants me to do it like this, but not 12:40
camelia 5===SORRY!5=== Error while compiling <tmp>
Malformed postfix
at <tmp>:1
------> 3say (2, 3)>>.:7⏏5 *.:<-> # i thught it wants me to do i
expecting any of:
colon pair
ugexe promise flattening or whatever breaks parametric polymorphism 12:51
i dunno if that justifies anything, just a point
13:28 frost left
Altreus multi sub do-stuff(Promise \p) { do-stuff(p.result) } # This is why I dislike the multi keyword 13:32
You shouldn't have to change the signature of the original do-stuff just to provide an alternative. In fact, there's no guarantee that you CAN 13:33
for a language that can infer what * means it's surprising we couldn't infer whether a sub is multi or not
mykhal m: say ( "uniname" (elem) $_ for ("a".^method_names, "a".^methods>>.gist) ) 13:42
camelia (True False)
mykhal m: say "a".^method_names (-) "a".^methods>>.gist 13:47
camelia Set(BUILDALL WORDS_AUTODEREF naive-word-wrapper ord ords unimatch uniname uninames uniparse uniprop uniprops unival univals)
mykhal hm, github.com/rakudo/rakudo/issues/4207 13:54
13:54 Eddward_ joined 14:19 sono left 14:20 Sgeo joined 15:20 linkable6 left, evalable6 left 15:21 linkable6 joined 15:23 evalable6 joined 15:26 patrickb left
Altreus I wonder why method_names uses an underscore and not a dash 15:41
MasterDuke the meta-methods all use underscore. i think it's just convention to show they're slightly different than regular methods 15:42
Altreus oh. I expected something like, they're implemented in C and it's easier to stick to C's syntax requirements 15:43
or maybe, they were written before we decided to allow - in identifiers!
that would be cool etymology 15:44
mykhal dunno too, just found plenty new methods "accidentally" in Comma 15:48
Altreus a handy tool! 15:53
15:54 Doc_Holliwould left 15:56 Doc_Holliwood joined 16:04 ufobat__ left
ugexe so having looked into this promise thing more... my impression is some people in javascript are regretting their decision with the rise in popularity of typescript 16:14
Altreus This sounds divisive 16:15
ugexe the non flattening implementation was deemed too language and type theoryist, hence why typescript rising popularity is exposing this change in sentiment 16:16
at the time it was deemed^
Altreus My understanding is that JS will automatically unpack a promise for a .then function? 16:17
ugexe yeah
Altreus I can see the appeal
I can also see how perl-family language theorycrafters would prefer to honour the edge cases than make the common cases more convenient 16:18
16:38 ecocode_ left
ugexe damned if you do and damned if you don't 16:43
16:43 dakkar left
Altreus programming is hard and then they added async 16:44
tonyo typescript handles promises just fine 16:54
unpacking can happen without the .then syntax 16:55
the promise thing is why i was ostracized from node 17:00
Altreus I'm blessed that the fact I don't understand has no bearing on my professional or personal programming journey 17:07
tonyo there are more useful things to know 17:11
than how promises work
Altreus I was referring specifically to the issues, or lack thereof, around JS promises as seen through Typescript 17:23
17:43 evalable6 left, linkable6 left 18:02 reportable6 left 18:18 Doc_Holliwood left 18:19 Doc_Holliwood joined 19:01 ecocode_ joined 19:25 Doc_Holliwood left 19:26 Doc_Holliwood joined 19:28 dogbert17 left 19:31 dogbert17 joined 19:36 Xliff joined 19:50 Manifest0 left 20:05 evalable6 joined 20:21 squashable6 left 20:39 sono joined 21:13 dogbert17 left 21:18 ecocode_ left 21:35 squashable6 joined 22:23 Doc_Holliwould joined 22:26 Doc_Holliwood left 22:27 Doc_Holliwood joined 22:29 Doc_Holliwould left
tbrowder Altreus: i'm pretty sure the late adding of kebab-casing is the major reason. i remember after the Christmas release seeing @jnthn saying something like, "oh, yes, we can use kebab case now to change this core thing." 23:07
23:14 Juerd left 23:15 Juerd joined 23:22 dogbert17 joined
[Coke] are the methods you're referring to with underscore also ALL_CAPS? 23:36
if so, it's the caps that's the difference.
23:40 japhb left 23:43 simcop2387 left, perlbot left 23:44 japhb joined 23:52 simcop2387 joined 23:53 perlbot joined
raydiak I think it was more about metamethods 23:57
m: say "".HOW.^methods».name.grep(/_/) 23:58
camelia (new_type add_fallback role_typecheck_list is_composed setup_junction_fallback find_method_fallback has_fallbacks set_pun_source is_pun pun_source set_name set_shortname set_why set_language_version set_language_revision set_ver set_auth set_api add_s…