Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
Nicholas good *able6, #moarvm 06:52
lizmat good *, Nicholas 09:12
m: dd :(UInt:D $a) # I guess that still needs to be fixed ?
camelia :(Int:D $a where { ... })
jnthnwrthngtn moarning o/ 10:49
Nicholas \p
oops, off by one
\o
lizmat is unclear on the state of nine's unsigned int work 10:50
is it correct to say that it all got merged ?
Nicholas I don't know. I thought yes. But I don't know. And I don't know what other "fallout" there is, and what needs doing 10:52
lizmat ok, but the bulk of the work got merged... I know there's some fallout, which is why there won't be a 2022.01 release 10:53
m: sub a(uint $a) { dd $a }; a -42 # that feels unexpected to me 11:11
camelia -42
lizmat a. that it dispatches without bind failure
b. even if it did dispatch, that inside the sub the unsigned int has a negative value
nine It's all merged, yes 11:57
MoarVM is still somewhat lenient. I figured lets take it one explosion at a time 11:58
In my defence its not just uint regressions that defied having a 2022.01 release 11:59
lizmat And yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2022/01/24/2022-...ned-merge/ 12:20
ok, this gets a bit weird: 12:36
m: sub a(uint $a) { dd $a.Str }; a -42 # feels correct 12:37
camelia "18446744073709551574"
lizmat m: sub a(uint $a) { say $a.gist }; a -42
camelia 18446744073709551574
lizmat also feels correct
m: sub a(uint $a) { say $a.raku }; a -42 # ok! 12:38
camelia 18446744073709551574
lizmat m: sub a(uint $a) { say $a }; a -42 # huh ?
camelia -42
lizmat fwiw, I think the binding is correct: natives specifically don't need to check for overflow or underflow, right ? 12:39
m: sub a(uint $a) { $a.say }; a -42 # the problematic case I think 12:40
camelia -42
nine Could be that for so.e methods we have int candidates but no uint candidates and we coerce the uint to int to make it fit 12:45
And yes natives are a performance tool foremost, so overflow/underflow is explicitely allowed 12:46
[Coke] nine++ again, btw. 14:27
moon-child m: m: sub a(uint $a) { say +$a }; a -42 17:46
camelia -42
[Coke] in an ideal world, would that accept the arg, get the correspond int you'd expect from a shift in C and return that? Or would it error out? 19:17
moon-child I would expect an error, as -42 can not be converted to uint. However I would expect wrapping from, say, my uint $x = 14; $x = -$x 19:25
lizmat mL sub a(uint $a) { say $a.Str }; a -42 19:33
m: sub a(uint $a) { say $a.Str }; a -42
camelia 18446744073709551574
lizmat the problem is in uint.say really
going afk to record a presentation
well, offline actually :-)
lizmat mission accomplished and uploaded :-) 20:38