🦋 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.
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
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
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
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
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
mykhal is there some .comb etymology story? i always think of combinations ... 07:40
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
moon-child yeah 07:49
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
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
gist.github.com/maros/d9f5a8d1cc6d...5e22e7ab0a
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
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
nothing?
docs.rakulang.site/type/Promise#method_then is rather short on details
moon-child perlmaros: sprunge.us/W7C1XK 10:06
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
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
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.
</channeling>
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
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
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
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
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
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
ugexe damned if you do and damned if you don't 16:43
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
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
[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.
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…

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!