[00:00] *** sena_kun left [00:00] *** TempIRCLogger left [00:00] *** vrurg left [00:00] *** ugexe left [00:00] *** tbrowder left [00:00] *** japhb left [00:00] *** gfldex left [00:00] *** squashable6 left [00:00] *** greppable6 left [00:00] *** shareable6 left [00:00] *** committable6 left [00:00] *** Kaiepi left [00:00] *** rypervenche left [00:00] *** tbrowder joined [00:00] *** squashable6 joined [00:00] *** committable6 joined [00:00] *** greppable6 joined [00:00] *** shareable6 joined [00:00] *** sena_kun joined [00:00] *** vrurg joined [00:00] *** TempIRCLogger joined [00:00] *** gfldex joined [00:00] *** rypervenche joined [00:01] *** Colt left [00:01] *** rypervenche left [00:01] *** rypervenche joined [00:02] *** ugexe joined [00:02] *** reportable6 left [00:03] *** Colt joined [00:05] *** MasterDuke left [00:05] *** japhb joined [00:17] *** MasterDuke joined [00:18] m: say &infix:.prec # ok, now how do i know this in the rakudo optimizer? [00:18] rakudo-moar ca4f003bc: OUTPUT: «1␤» [00:32] m: my $a = 3; say 4 eq $a ?? 1 !! 2; [00:32] rakudo-moar ca4f003bc: OUTPUT: «2␤» [00:32] m: my $a = 3; say 4 + $a ?? 1 !! 2; [00:32] rakudo-moar ca4f003bc: OUTPUT: «1␤» [00:33] timo: i currently have ^^^ reporting `WARNINGS for -e: Potential dead code, the '?? !!' is gobbling up the result of the '&infix:<~>' (line 1)` [01:05] *** reportable6 joined [01:34] *** frost joined [02:40] *** MasterDuke left [04:07] *** squashable6 left [05:11] *** squashable6 joined [06:02] *** reportable6 left [07:03] *** reportable6 joined [07:43] good *, #moarvm [07:51] Good.....aged tweet? https://twitter.com/TheASF/status/1400875147163279374 [09:02] nine: here's a testcase for NQP that hits the assertion: http://paste.scsys.co.uk/596330 [09:03] as in, I have a test. I just need to fix the C [09:06] *** MasterDuke joined [09:47] MasterDuke: there's no ~ in that code :D [10:13] Nicholas: how on earth has this managed to stay hidden till now? [10:15] "needs assertions enabled, which isn't the default" ? [10:31] it's not enabled when you compile with --debug=3 like i always do? [10:32] .o( but i haven't run spec tests in a whole while ) [11:30] *** frost left [11:30] *** MasterDuke left [11:39] *** TempIRCLogger left [11:39] *** TempIRCLogger joined [11:57] *** squashable6 left [12:02] *** reportable6 left [12:05] *** reportable6 joined [12:06] *** TempIRCLogger left [12:06] *** TempIRCLogger joined [12:11] *** TempIRCLogger left [12:11] *** TempIRCLogger joined [12:12] *** TempIRCLogger left [12:13] *** TempIRCLogger joined [12:14] *** frost joined [12:43] *** discord-raku-bot left [12:43] *** discord-raku-bot joined [13:06] *** squashable6 joined [14:36] *** frost left [15:58] *** MasterDuke joined [17:57] *** squashable6 left [18:03] <[Coke]> fff [18:04] ^fff^ [18:04] fortississimo [18:05] (I did have to look that up because I could only remember f and ff) [18:07] *** reportable6 left [18:08] Well I'd say fff is kinda rare, so that's understandable :) [19:08] *** reportable6 joined [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: 0a674c8c3e | (Nicholas Clark)++ | src/core/str_hash_table_funcs.h [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: For an empty hash, report that at most 0 buckets are in use [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: `MVM_str_hash_kompromat` is a private function that abstracts the logic for [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: determining the number of buckets in use, which is often slightly smaller [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: than the number of buckets allocated. This value is needed to know where [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: hash iterators should start. [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: <…commit message has 14 more lines…> [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: review: https://github.com/MoarVM/MoarVM/commit/0a674c8c3e [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: 2fa51c611f | (Nicholas Clark)++ | src/6model/reprs/MVMHash.c [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: No need to call `MVM_str_hash_build` when deserializing an empty hash [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: MVMHash and MVMStrHashTable have an optimisation that avoids allocating any [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: memory for a hash with 0 elements, by treating an (internal) NULL pointer [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: as an empty hash, and only allocating memory on demand. Hence don't call [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: `MVM_str_hash_build` if `elems` is 0 to take advantage of this. [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: review: https://github.com/MoarVM/MoarVM/commit/2fa51c611f [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: c1e8775f78 | (Nicholas Clark)++ | src/6model/serialization.c [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: Skip sorting the keys when serializing empty hashes [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: To ensure that bytecode generation is repeatable even with hashes randomised [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: we need to sort the hash keys so that we always serialize in a consistent [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: order. In turn, this means we need to allocate temporary storage for an [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: array of keys, so that we can sort this. All this code is generic and [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: correctly handles the case of 0 keys (and 1 key), but all of it can be [19:13] ¦ MoarVM/deserialize-empty-hashes-robustly: <…commit message has 5 more lines…> [19:14] ¦ MoarVM/deserialize-empty-hashes-robustly: review: https://github.com/MoarVM/MoarVM/commit/c1e8775f78 [19:19] ¦ MoarVM: nwc10++ created pull request #1620: Deserialize empty hashes robustly [19:19] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1620 [19:20] Nicholas++ [19:20] nine: I haven't actually checked the final build "against" LibXML [19:20] the first commit fixes it [19:20] the second commit would "fix" it by not hitting the duff code path [21:01] *** squashable6 joined