🦋 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 | |
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 | ||
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 | |
nothing? | |||
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. | |||
</channeling> | |||
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… |