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.
MasterDuke m: say &infix:<eq>.prec<iffy> # ok, now how do i know this in the rakudo optimizer? 00:18
camelia 1
MasterDuke m: my $a = 3; say 4 eq $a ?? 1 !! 2; 00:32
camelia 2
MasterDuke m: my $a = 3; say 4 + $a ?? 1 !! 2;
camelia 1
MasterDuke timo: i currently have ^^^ reporting `WARNINGS for -e: Potential dead code, the '?? !!' is gobbling up the result of the '&infix:<~>' (line 1)` 00:33
Nicholas good *, #moarvm 07:43
nine Good.....aged tweet? twitter.com/TheASF/status/1400875147163279374 07:51
Nicholas nine: here's a testcase for NQP that hits the assertion: paste.scsys.co.uk/596330 09:02
as in, I have a test. I just need to fix the C 09:03
timo MasterDuke: there's no ~ in that code :D 09:47
nine Nicholas: how on earth has this managed to stay hidden till now? 10:13
Nicholas "needs assertions enabled, which isn't the default" ? 10:15
timo it's not enabled when you compile with --debug=3 like i always do? 10:31
.o( but i haven't run spec tests in a whole while ) 10:32
[Coke] fff 18:03
timo ^fff^ 18:04
Nicholas fortississimo
(I did have to look that up because I could only remember f and ff) 18:05
nine Well I'd say fff is kinda rare, so that's understandable :) 18:08
Geth MoarVM/deserialize-empty-hashes-robustly: 0a674c8c3e | (Nicholas Clark)++ | src/core/str_hash_table_funcs.h
For an empty hash, report that at most 0 buckets are in use

  `MVM_str_hash_kompromat` is a private function that abstracts the logic for
determining the number of buckets in use, which is often slightly smaller than the number of buckets allocated. This value is needed to know where hash iterators should start.
... (14 more lines)		 19:13
MoarVM/deserialize-empty-hashes-robustly: 2fa51c611f | (Nicholas Clark)++ | src/6model/reprs/MVMHash.c
No need to call `MVM_str_hash_build` when deserializing an empty hash

MVMHash and MVMStrHashTable have an optimisation that avoids allocating any memory for a hash with 0 elements, by treating an (internal) NULL pointer as an empty hash, and only allocating memory on demand. Hence don't call
  `MVM_str_hash_build` if `elems` is 0 to take advantage of this.
MoarVM/deserialize-empty-hashes-robustly: c1e8775f78 | (Nicholas Clark)++ | src/6model/serialization.c
Skip sorting the keys when serializing empty hashes

To ensure that bytecode generation is repeatable even with hashes randomised we need to sort the hash keys so that we always serialize in a consistent order. In turn, this means we need to allocate temporary storage for an array of keys, so that we can sort this. All this code is generic and correctly handles the case of 0 keys (and 1 key), but all of it can be ... (5 more lines)
MoarVM: nwc10++ created pull request #1620:
Deserialize empty hashes robustly		 19:19
lizmat Nicholas++ 19:20
Nicholas nine: I haven't actually checked the final build "against" LibXML
the first commit fixes it
the second commit would "fix" it by not hitting the duff code path

Powered by Cro and the Raku® Programming Language.

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

Thank you!