[02:14] *** evalable6 left [02:14] *** linkable6 left [02:14] *** squashable6 left [02:15] *** squashable6 joined [02:15] *** bloatable6 joined [02:15] *** committable6 joined [02:15] *** statisfiable6 joined [02:16] *** releasable6 joined [02:16] *** sourceable6 joined [02:16] *** nativecallable6 joined [02:16] *** benchable6 joined [02:16] *** tellable6 joined [02:16] *** quotable6 joined [02:16] *** coverable6 joined [02:16] *** evalable6 joined [02:16] *** shareable6 joined [02:17] *** greppable6 joined [02:17] *** bisectable6 joined [02:17] *** linkable6 joined [02:17] *** unicodable6 joined [02:17] *** notable6 joined [03:17] *** linkable6 left [03:17] *** committable6 left [03:17] *** evalable6 left [03:17] *** sourceable6 left [03:17] *** tellable6 left [03:17] *** benchable6 left [03:17] *** releasable6 left [03:17] *** quotable6 left [03:18] *** evalable6 joined [03:19] *** sourceable6 joined [03:19] *** releasable6 joined [03:19] *** benchable6 joined [03:20] *** tellable6 joined [03:20] *** quotable6 joined [03:20] *** linkable6 joined [03:20] *** committable6 joined [05:53] *** japhb left [05:55] *** japhb joined [07:26] good *, #moarvm [07:33] Oh, is it * again? [07:34] you know how timezone works, it's always * somewhere [07:34] it keeps happening. [07:34] 3 days without hot beverage mishaps. I wonder how long I can keep this up. I have no tea... [07:40] No mishaps, but did you have hot beverages at all? [08:02] yes. There was tea. There was coffee. [08:23] *** Kaeipi joined [08:26] https://github.com/MoarVM/MoarVM/pull/1470 and https://github.com/rakudo/rakudo/pull/4320 now have several different versions, many of them relatively independent (i.e., you kind of want to look at each commit and its diff from master, not necessarily to the previous commit) [08:27] is there any other good way to propose multiple different options, besides just creating multiple PRs? [08:28] maybe i just need to extract the various diffs and put them in a gist [08:32] and now a completely different question. jnthn mentioned logging pow_I, which involved adding `:logged` to its entry in the oplist, and then possibly some additions to src/spesh/facts.c., and maybe some tweaks in src/core/interp.c, etc. [08:33] i assume there's some cost to logging, or, what's the reason not to log everything? [08:34] Yes, there is a cost [08:37] very few ops are logged, does it only make sense to do so for ops that have different kinds of return values? e.g., pow_I could return an Int or a Num, contrasted with mul_I which only returns an Int (both can throw in some error conditions) [08:39] my new pow2_I (to maybe replace the existing pow_I) instead returns an Int type object instead of a Num, but that's still different enough to make logging potentially worthwhile? [08:42] also, add_bb_facts has cases for lots of ops (not just :logged ones), so e.g., (add|sub|mul|div|mod|neg|abs)_I all have a case that that just does a copy_facts between two registers [08:43] would it make sense to add a bunch more cases? pow_I, b(and|or|xor|not)_(i|I) [08:57] *** domidumont joined [09:01] no noes. Was within 1cm of finishing the coffee when I got a minor explosion. I think that the coffee slug "failed" on the edge, and that releases all the pressure (like a damn burst) and the flow rapidly erodes more of the coffee slug. [09:01] Have to reset the counter. [09:53] MasterDuke, ping? [09:56] https://gist.github.com/Altai-man/32a9fb9c9f0a3c7c36935c14603ab658 <- this looks to me like a moarvm regression, not a false positive. [10:11] sena_kun: i still can't repro locally [10:13] MasterDuke, you have clonned the https://github.com/coke/raku-uni repo? [10:13] yep. its test passes when run from the cloned repo, also `zef install App::Uni` succeeds for me [10:14] MasterDuke, and your raku --version is v2021.03-176-g6fdc2b690? [10:14] v2021.03-178-g10c3dbb94 [10:14] Built on MoarVM version 2021.03-50-g948128995. [10:16] * sena_kun re-installs moar-blead [10:18] sena_kun: https://github.com/coke/raku-uni also tests clean for me on MacOS [10:19] I wonder how on earth I can reproduce it so reliably. [10:19] Welcome to Rakudo(tm) v2021.03-178-g10c3dbb94. [10:19] [App::Uni] # You failed 1 test of 8 [10:20] hmmm... my raku says: Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.03. [10:20] wtf ? [10:22] lizmat, didn't you make it optional? When fonts are present or something. [10:22] made what optional? [10:23] the "𝐑𝐚𝐤𝐮𝐝𝐨" you mean? [10:23] lizmat, the message font. [10:23] yeah [10:23] yeah, it's only shown when starting the REPL [10:24] I was more pointing towards the version shown? [10:24] lizmat, when I start REPL there is indeed Welcome to 𝐑𝐚𝐤𝐮𝐝𝐨™ v2021.03. [10:24] ah, *phew* [10:24] raku --version shows me Welcome to Rakudo(tm) v2021.03-178-g10c3dbb94. [10:25] right.... ok, that was the other difference, I remember now :-) [10:25] *phew* [10:26] Ok, so Blin can spot the regression and I can spot the regression manually. [10:26] But two people cannot. [10:26] what os are you on? [10:26] gnu/linux box [10:27] i'm using arch linux [10:27] void linux if it gives something [10:27] OTOH I don't think it does. I'm using an intel CPU. [10:29] amd [10:30] I suspect it's something else. Can you do `which zef`? As in, what raku binary runs zef, is it the correct one? [10:31] i only have one raku binary, and was using the zef binary in the zef repo [10:32] Hmmm. Apparently, I am not qualified enough to find a solution. I'll gladly run commands if anything that can clarify the case comes to mind. [10:33] maybe vrurg can try to repro on the machine where blin runs [10:33] *** dogbert17 joined [10:35] I kinda don't want to manually revert moarvm commits in a binary search manner, bump and rebuild to find out which one causes that on this machine, but maybe that's the way. [10:37] sena_kun: I'm not 100% convinced it's in MoarVM [10:37] what happens if you run this golf (cough cough) a few times, does it always work? https://gist.github.com/dogbert17/cf91cd2b2f324164b4895b60857958d9 [10:37] 2021-04-15T12:45:17Z #moarvm dogbert17: ping, you're good at testing the 3rdparty bumps, looks like libatomicops is a bit out of date of upstream [10:38] lizmat, the commit between bump works for me, the commit with the bump does not. [10:39] Oh, interesting. [10:39] So I ran it 3 times so far [10:39] Strings = cat eyes 2 [10:39] Type check failed in binding to parameter ''; expected Cool but got Method (proto method fc (Coo...) [10:39] in sub uni-search at golf.raku line 35 [10:39] second two runs are fine [10:40] could you check to see what happens if you change in lines 35 and 36 [10:40] uniname($_) to .uniname ? [10:40] I get the same error as sena_kun but not always [10:41] lizmat, I can't break it so far, alas I did just 10 iterations, cannot do 100 or something here. [10:41] ok, well: looks to me that code hyper code is a bit suspect [10:42] lizmat: it works for you then? [10:43] ah, no.. it fails [10:43] ok, so we have it reproed now [10:43] yay [10:43] yay++ [10:43] do you folks need something from me or I can go grab some food? :) [10:44] get some food :) [10:44] grab food! [10:45] yay [10:45] thanks for being patient with me. :) [10:45] sena_kun: thanks for being persistent! [10:49] ok, I think the MoarVM change uncovered a DIHWIDT bug [10:49] * dogbert17 speculates (woldly) that there might possibly be some bizarre connection with https://github.com/rakudo/rakudo/commit/e2ec1607f9c949a72f0a81d3bf61c1f46459ea66 [10:49] if you remove the hypers from that code, it all works [10:50] dogbert17: that could be, but only because they made it more likely that the hyper would be bashing the same $sieve at the same time [10:51] the code is wrong: multiple threads should *not* be writing to $sieve at the same time [10:51] ah [10:54] running with MVM_CROSS_THREAD_WRITE_LOG=1 seems to confirm your theory [10:55] so I would mark it as a false positive, and maybe make a PR removing the hypers [10:56] that piece of logic needs to be re-thought [10:56] I suspect [Coke] put them there for speed related reasons [10:59] wow, that's a lot of output [11:01] hmmm... now it also fails without the hypers? [11:02] doesn't fail if I put a dd $sieve in it [11:02] hmmm [11:06] the number of strings isn't big enough for the hyper to actually hyper, as it default batch size is 64 and there are only 2 strings [11:07] so *that* is only a potential issue [11:17] interesting, and if we backtrack to the bizarre theory ? [11:22] that it *is* something in moar that broke [11:23] can't get it to fail with MVM_SPESH_BLOCKING=1 [11:24] the wild theory is that your Rakudo commit uncovered a spesh bug which MasterDuke's decont fix managed to hid/fix. How's that for a wild theory? [11:24] *hide [11:24] could be [11:25] what other MVM_SPESH options do we have again? [11:25] chances are quite high that it will be smashed to bits :) [11:25] the interesting ones are MVM_SPESH_INLINE_DISABLE and MVM_SPESH_OSR_DISABLE [11:25] can't replicate with MVM_SPESH_DISABLE [11:25] neither can I [11:26] can't replicate with MVM_SPESH_INLINE_DISABLE [11:26] +1 [11:27] can't get it to fail with --profile either [11:27] correction: --profile also fails [11:29] profile shows that of the 1.1M calls to Str.contains, the majority is red, only the last 10% is green [11:29] which feels... odd ? [11:30] the inline log shows uniname, fc and contains all inlined [11:32] MVM_SPESH_NODELAY=1 *always* fails [11:32] also fails with MVM_JIT_DISABLE [11:33] so my guess is indeed some spesh related issue, possibly already existing, now uncovered by this code [11:33] where are the speshialists :) [11:34] the problem occurs in the *proto* of Cool.contains [11:36] anything on top of that in the stacktrace is just producing the error [11:36] I'm afraid I'm out of ideas at this point [11:36] MasterDuke nine sena_kun ^^ [11:37] I am surely not a speshialist, but nice to see the investigation progressing, great work! [12:20] i likely won't have any decent chunk of time to work on this today, but 08525be54bab1e7e9130568eda06d7c8295ac5cb is a spesh-related commit in between the two bumps [12:58] *** frost-lab joined [13:02] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: e1d546ab54 | (Stefan Seifert)++ | src/spesh/optimize.c [13:02] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: Propagate spesh facts after optimizing away a guard [13:02] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: [13:02] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: When we optimize a guard into a set (for in the hopes of it getting eliminated [13:02] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: later on), we missed the opportunity to copy the facts from the source [13:02] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: register. This lead to missed optimization opportunities like not inlining [13:02] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: a function, because we didn't know that we actually knew the callee. [13:02] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: review: https://github.com/MoarVM/MoarVM/commit/e1d546ab54 [13:02] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: dc1f710bd5 | (Stefan Seifert)++ | src/spesh/optimize.c [13:02] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: Propagate spesh facts after optimizing box/unbox into a set [13:02] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: [13:02] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: When we optimize a box/unbox pair into a plain set, we do so knowing that the [13:02] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: required output is exactly the input. So all facts known for the input must [13:03] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: apply for the output as well. Copy those facts to allow for further [13:03] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: optimizations based on them. [13:03] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: review: https://github.com/MoarVM/MoarVM/commit/dc1f710bd5 [13:03] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: 543258ab10 | (Stefan Seifert)++ | src/spesh/optimize.c [13:03] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: Propagate spesh facts after eliminating unuseed log guards [13:03] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: [13:03] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: When turning unused log guards into plain sets (with the goal of getting rid of [13:03] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: them completely via set elimination) copy the input facts to the output to [13:03] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: unlock further optimization between log guard and set elimination. [13:03] ¦ MoarVM/propagate_spesh_facts_after_guard_elimination: review: https://github.com/MoarVM/MoarVM/commit/543258ab10 [13:04] ¦ MoarVM: niner++ created pull request #1471: Propagate spesh facts after guard elimination [13:04] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1471 [14:10] *** frost-lab left [15:47] nine++ [15:47] 2021-04-17T09:57:04Z #raku-dev jnthn https://github.com/rakudo/rakudo/pull/4331 will probably amuse you :) [15:48] nine: Fixing bugs my deleting code is always a nice thing :D [15:53] Taking the discussion about the clear moarvm bug back to the channel, my propagate_spesh_facts_after_guard_elimination branch actually makes the uni-search bug go away [15:53] It's quite possible though that it just hides it again. [15:54] On the topic "Type check failed in binding to parameter '$bytes'; expected Blob but got Supplier::Preserving (Supplier::Preserving...)" I've found that MVM_SPESH_OSR_DISABLE makes that go away. And spesh log shows a difference in facts that seems to be significant. [15:56] on moarvm master, after removing the hypers in the App::Uni test, i can consistently repro with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1. it still fails if i add MVM_SPESH_OSR_DISABLE=1 [15:59] seems to pass with PEA or INLINE disabled though [16:03] nine: i don't remember, did you ever figure out/fix that SSA problem? [16:03] yes [16:04] That was https://github.com/MoarVM/MoarVM/commit/298298aaac65e71e610f6007a8bc957fe83daea1 [16:04] ah, right [16:19] Fun time over, "ab attack" training starts... [16:33] i'm also about to attack my abs, but with indian food [16:47] *** brrt joined [17:09] *** brrt left [17:15] *** lucasb joined [17:30] *** patrickb joined [17:36] *** patrickb left [17:39] *** domidumont left [18:51] *** zakharyas joined [19:53] ¦ MoarVM/ryu: 5 commits pushed by (Nicholas Clark)++ [19:53] ¦ MoarVM/ryu: 5c449e6c5e | Add Ryū as a submodule. [19:53] ¦ MoarVM/ryu: ca0f50eb91 | Switch MVM_coerce_n_s to Ryū from Grisu3 with a sprintf fallback. [19:53] ¦ MoarVM/ryu: c3e4b8c68b | Remove the Grisu3 code. [19:53] ¦ MoarVM/ryu: fff5572d81 | Convert MVM_num_isnanorinf and MVM_num_{posinf,neginf,nan} to static inline. [19:53] ¦ MoarVM/ryu: e6d5976448 | In `MVM_coerce_n_s`, move the NaN and Inf handling inside an UNLIKELY test. [19:53] ¦ MoarVM/ryu: review: https://github.com/MoarVM/MoarVM/compare/5c449e6c5e54^...e6d5976448c0 [19:56] ¦ MoarVM: nwc10++ created pull request #1472: Switch MVM_coerce_n_s to Ryū from Grisu3 with a sprintf fallback [19:56] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1472 [20:07] and now I find *two* errors in one of the commit messages [20:08] anyway, put *that* in your CI system and smoke it. [20:08] (tomorrow I'll have a go on big endian systems, which I think feature nowhere in any CI system anyone offers online) [20:39] <[Coke]> japhb: [u] sure. [20:40] [u]? [20:41] <[Coke]> https://gist.github.com/japhb/7b8a68da1b4b6c201e5334c1269b951a [20:41] Oh, the [] meant re:, got it [20:41] <[Coke]> I assume you were referring to updates to app::uni, sure, patches welcome [20:42] * japhb throws that into his queue [20:45] nwc10: doesn't the OBS, which i believe nine has access to, have some big endian systems? [20:45] OBS? Something SuSE? [20:46] I have an account on the gcc compile farm. There's lots of fun stuff, but it has to be me logging in manually [20:46] sadly the ia64 machine is no more. [20:47] opensuse build system i think [20:49] s/system/service/ I think, but otherwise yeah [21:07] nwc10: OBS is the Open Build Service which is as the name says quite open :) Yes, it comes from the SUSE people. [21:08] I'm building every rakudo commit on among the usual candidates PowerPC, aarch64 and s390: https://build.opensuse.org/project/show/home:niner9:rakudo-git [21:08] *** zakharyas left [21:08] And not just rakudo but a whole bunch of modules I care about. What I don't yet do is run a spectest. I figured patrickb will get to that [21:10] Oh, RISCV is also available nowadays. Wonder how'd we do there... [21:30] *** Kaeipi left [21:31] *** Kaeipi joined [22:50] *** Kaeipi left [23:40] *** japhb left [23:52] *** japhb joined [23:53] *** japhb_ joined [23:55] *** japhb_ left [23:55] *** japhb left [23:55] *** japhb joined