🦋 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 | |
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. |
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 |
|||
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 |
14:25 | |
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 | ||
71c62e7c1121c19e7c4 | |||
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 |
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! |