🦋 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: ... | log inspection situation still under development | For MoarVM see #moarvm
Set by lizmat on 22 May 2021.
Geth roast: vrurg++ created pull request #780:
Add smartmatch tests for Map
00:07 reportable6 left 00:16 evalable6 joined
Geth rakudo: 87621e1ae5 | (Vadim Belman)++ | src/core.c/Map.pm6
Fix Map ACCEPTS by collapsing explicit junctions

Where topics are explicitly junctionaized with `.any` we need explicit
  `.Bool` or otherwise the code always throws with return type mismatch.
rakudo: 5608686950 | (Vadim Belman)++ (committed using GitHub Web editor) | src/core.c/Map.pm6
Merge pull request #4688 from vrurg/rakudo_2560

Fix Map ACCEPTS by collapsing explicit junctions
roast: 983933642b | (Vadim Belman)++ | 2 files
Add smartmatch tests for Map

In support of rakudo/rakudo#4688
roast: 9df6e7a7d9 | (Vadim Belman)++ | S03-smartmatch/array-hash.t
Unfudge smartmatch tests for Hash

They're passing on Rakudo now.
roast: 7fa1a4555d | (Vadim Belman)++ (committed using GitHub Web editor) | 3 files
Merge pull request #780 from vrurg/rakudo_2560

Add smartmatch tests for Map
01:01 linkable6 left, linkable6 joined 01:08 reportable6 joined 01:22 frost joined 01:32 frost left 01:46 frost joined 02:46 benchable6 left, releasable6 left, nativecallable6 left, greppable6 left, evalable6 left, committable6 left, notable6 left, bloatable6 left, coverable6 left, tellable6 left, reportable6 left, shareable6 left, bisectable6 left, unicodable6 left, statisfiable6 left, sourceable6 left, squashable6 left, quotable6 left, linkable6 left 02:47 linkable6 joined, sourceable6 joined, bisectable6 joined, shareable6 joined 02:49 squashable6 joined, bloatable6 joined, evalable6 joined, tellable6 joined, releasable6 joined 03:47 greppable6 joined, benchable6 joined 03:48 notable6 joined, statisfiable6 joined 03:49 quotable6 joined, reportable6 joined 04:47 committable6 joined 05:30 [Coke] left 05:33 [Coke] joined 05:47 unicodable6 joined 06:07 reportable6 left 06:08 reportable6 joined 06:47 nativecallable6 joined 09:07 committable6 left, reportable6 left, unicodable6 left, notable6 left, sourceable6 left, bisectable6 left, statisfiable6 left, greppable6 left, squashable6 left, linkable6 left, nativecallable6 left, quotable6 left, bloatable6 left, evalable6 left, tellable6 left, releasable6 left, benchable6 left, shareable6 left 09:09 linkable6 joined, quotable6 joined, reportable6 joined, sourceable6 joined, statisfiable6 joined, bloatable6 joined, nativecallable6 joined 09:10 bisectable6 joined, notable6 joined, committable6 joined 09:11 releasable6 joined 10:09 unicodable6 joined, evalable6 joined 11:09 shareable6 joined, squashable6 joined 11:11 sena_kun joined 12:08 reportable6 left 12:09 benchable6 joined 12:10 tellable6 joined 12:11 reportable6 joined 12:35 frost left 14:04 linkable6 left, evalable6 left
Geth roast: 10621b95e1 | (Vadim Belman)++ | MSG
Remove accidentally added file
15:05 linkable6 joined 15:48 coverable6 joined 16:07 evalable6 joined 16:10 greppable6 joined 17:38 discord-raku-bot left 17:39 discord-raku-bot joined 17:43 discord-raku-bot left, discord-raku-bot joined 18:08 reportable6 left, reportable6 joined 19:07 sena_kun left 19:36 squashable6 left, squashable6 joined 20:13 [Coke] left 20:16 [Coke] joined
japhb lizmat: Around? 21:49
lizmat somewhere, yes
japhb So ... I'm not sure the original code in TinyFloats was wrong. I'm thinking the warning may be spurious (at least in the case of +&). 21:50
I'm instrumenting the heck out of my tests, and I can't see the new and old code produce a different answer.
Heck, I even have a version that prints every stage of both calculations, and they're the same as far as I can tell. 21:51
What commit added this warning? 21:52
lizmat vrurg added a few days ago 21:53
maybe longer ago
no, it was Masterduke 21:54
21:55 linkable6 left
MasterDuke japhb: you're hitting a new warning? 21:55
japhb github.com/japhb/TinyFloats/pull/2 21:56
lizmat++ sent me a PR to silence the warning, but neither of us managed to create a test where the old (unparenthesized) code produces a different answer. 21:57
21:57 linkable6 joined
japhb Which could just be me being blind, but I suspect maybe the warning is overzealous. 21:57
lizmat I guess a test could be devised with 2 Proxies to the left of the ?? ? 22:00
japhb Oh hmmm, I was missing the (potential) bug before because I wasn't using Proxy objects? Interesting. 22:07
lizmat well, having the FETCH in the Proxy setting a flag, and thus testing the order in which they were fetched ? 22:08
japhb I'm saying that my original code could never trip over the bug, because only the first line of bin16-from-num() touches the user input, and that in a way that would work properly with a Proxy object. All the other code in that routine works with scalars of my own production -- thus there could never be proxies in the warned line of code. 22:11
MasterDuke well, i think that's a case where i didn't intend the warning to fire. i.e., the +& produces a truthy result to it should get exluded
*so it should get excluded
that was the intent of this part github.com/rakudo/rakudo/commit/92...96f32R1523 22:12
japhb Ah, and my code had the opposite case from the one in the comment there -- instead of wanting parens around the ternary, it's pushing for parens around the test 22:14
moon-child +& is a case where you could conceivably want it either way 22:15
so I think it is reasonable to warn there
japhb moon-child: Yeah, I can see that. 22:16
MasterDuke `src/Perl6/Grammar.nqp:4090:    token infix:sym<?&>   { <sym>  <O(|%multiplicative, :iffy(1))> }` 22:17
`src/core.c/precedence.pm6:66:    trait_mod:<is>(&infix:<?&>,  :prec($multiplicative));`
interestingly `?&` is iffy in the token, but not the trait_mod
`src/Perl6/Grammar.nqp:4088:    token infix:sym<+&>   { <sym>  <O(|%multiplicative)> }` 22:18
`src/core.c/precedence.pm6:64:    trait_mod:<is>(&infix:<+&>,  :prec($multiplicative));`
lizmat m: dd DateTime.now.Str
camelia "2021-12-28T23:18:36.305661+01:00"
MasterDuke `+&` isn't in either
lizmat turns out that is NOT a ISO 8601 compatible string anymore 22:19
japhb lizmat: Too many decimal places?
lizmat yeah, for second indeed 22:20
moon-child what's the cap? 3?
lizmat ISO 8601:1-2019 is the standard, but it appears that some services don't understand that
0 I'd say :-)
moon-child :/
japhb Well, I suppose that's only two years old as a standard, so ... 22:21
lizmat m: dd DateTime.now.truncated-to('second').Str
camelia "2021-12-28T23:21:46+01:00"
lizmat meh
m: dd DateTime.new(now.Int) 22:22
camelia DateTime.new(2021,12,28,22,22,51)
lizmat m: dd DateTime.new(now.Int).Str
camelia "2021-12-28T22:22:57Z"
lizmat m: dd DateTime.new(time).Str
camelia "2021-12-28T22:22:51Z"
lizmat guess I'll use that
japhb Oof, lots of pointer size and signedness warnings building MoarVM on RPi4 + Raspbian (32-bit) 22:27
Geth rakudo: MasterDuke17++ created pull request #4689:
Make infix:<(~+?)&> iffy
MasterDuke japhb, lizmat: ^^^, though i would be curious if there's any ecosystem fallout 23:47
lizmat I doubt it... approved the PR already :-) 23:48
MasterDuke heh, that was fast
well, i'm off to sleep 23:49
lizmat well, it was about the last thing I'll be doing today as well
sleep well all!