🦋 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: ... | Logs available at irclogs.raku.org/raku-dev/live.html | For MoarVM see #moarvm
Set by lizmat on 8 June 2022.
Geth nqp: 7059106468 | (Daniel Green)++ | tools/templates/MOAR_REVISION
Bump MoarVM to get unsigned comparison ops
01:19
nqp: 9dcf422c29 | (Daniel Green)++ | 5 files
Make unsigned comparison ops available

The MoarVM and JVM implementations work, but the JS ones are completely untested.
nqp: d397598a16 | MasterDuke17++ (committed using GitHub Web editor) | 6 files
Merge pull request #780 from MasterDuke17/add_unsigned_comparison_ops

Add unsigned comparison ops
rakudo: 4a51b15214 | (Daniel Green)++ | tools/templates/NQP_REVISION
Bump NQP for unsigned comparison ops
01:36
sena_kun rba, ping? 11:40
Geth roast: 4af6095bd1 | (Elizabeth Mattijsen)++ | S02-types/native.t
Add some uint tests

And sanify int tests, as the "isnt" cases were only passing because they were working off of incorrect values.
11:48
rakudo: 25c76aed00 | (Elizabeth Mattijsen)++ | src/core.c/Int.pm6
Add proper support for uint comparisons

For == != < <= > >= using the new _u nqp::ops, MasterDuke++
Note these also have candidates for mixes of uint / int and vice-versa which would otherwise be handled by relatively expensive Int:D Int:D candidates.
11:51
Geth roast: 2a78098fdc | (Elizabeth Mattijsen)++ | S02-types/signed-unsigned-native.t
Add test file for (un)signed int comparisons

Specifically when the bitmaps are the same
18:05
Geth rakudo: 32af3dbeaf | (Elizabeth Mattijsen)++ | 2 files
Apply unsigned int comparisons on native arrays

Where applicable, of course
19:28
rakudo: b75545d3b8 | (Elizabeth Mattijsen)++ | 2 files
Use uint comparisons in native infix:<cmp>
bartolin_ lizmat: To me it looks a bit strange to assign -1 to uint all over the place. Does this bring a performance improvement? 19:34
lizmat m: my uint $a = -1; say ++$a 19:35
camelia 0
lizmat I think that makes more sense than:
m: my uint $a = 18446744073709551615; say ++$a 19:36
camelia 0
bartolin_ yes, sure. but what was wrong with int in the first place?
lizmat also: -1 will work on both 32bit and 64bit systems
well, with uint we have 2x the range 19:37
bartolin_ ah, ok.
lizmat but other than that, there are no performance reasons
bartolin_ I see. I just wondered why you did this. And I didn't think that the range could become a limiting factor. Thanks for explaining :) 19:38
lizmat well, it would be extreme in the 64 bit case 19:39
I mean, more than 9223372036854775807 19:40
but yeah...
in a way it's also dogfooding, making sure we got all native uint cases right
lizmat there would be no problem reverting the last 2 commits should it become clear they break the ecosystem 19:41
lizmat there's plenty of iterator logic that would also need be looked at wrt uint... but am too tired for that now 19:42
bartolin_ ++lizmat ;) 19:43
Geth rakudo: usev6++ created pull request #5072:
Reuse $v-how instead of calling HOW again
19:48
roast: 51b19bcb1c | (Christian Bartolomäus)++ | 10 files
[JVM] Unfudge some tests for unicode numbers

Fixed with github.com/Raku/nqp/pull/779
20:00
Geth ¦ problem-solving: 2colours assigned to codesections Issue The Path to Raku, revisited github.com/Raku/problem-solving/issues/347 22:20
japhb lizmat: I think 02a28de5bd may have broken the BSON module's tests (AKA BSON::Document). I suspect that's a bug in the tests (being too precise about expected result type), but I haven't gone in depth. 23:00
japhb turns off testing on that module locally in order to continue testing 23:03
japhb Might have affected HTTP::UserAgent's tests as well 23:33