🦋 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:03
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.		 01:00
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
Geth roast: 10621b95e1 | (Vadim Belman)++ | MSG
Remove accidentally added file
 14:25
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
71c62e7c1121c19e7c4
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
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		 23:46
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
afk&
sleep well all!

Powered by Cro and the Raku® Programming Language.

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

Thank you!