[00:02] *** reportable6 left [00:05] *** reportable6 joined [00:07] *** linkable6 left [00:08] *** linkable6 joined [00:22] *** jgaz left [01:22] *** linkable6 left [01:22] *** evalable6 left [01:24] *** linkable6 joined [01:24] *** evalable6 joined [01:52] | * 00372e46f - (origin/disp-prog-spesh-codegen) disp prog spesh codegen for LoadAttribute* ops (1 year ago) [01:52] oof, haha [01:52] one year already [01:53] heh. i have some old PRs still open(ish) [01:54] looks like oldest are 4 years old. should probably close them [02:20] feed them, clothe them, do whatever it takes to give them a good life [02:21] *** frost joined [02:23] closed the oldest, next oldest i've actually done some recent work with on the desktop (guess i haven't pushed it though) [02:24] but ugh, not making any progress with this current exploration. adding `.node($/)`s and `QAST::Stmts.new(<...>)`s all over the place, but no change so far [02:32] *** frost left [03:07] *** Kaiepi joined [03:08] *** Kaipi left [05:57] *** evalable6 left [05:57] *** bisectable6 left [05:57] *** nativecallable6 left [05:57] *** releasable6 left [05:57] *** quotable6 left [05:57] *** linkable6 left [05:57] *** squashable6 left [05:57] *** coverable6 left [05:57] *** greppable6 left [05:57] *** benchable6 left [05:57] *** statisfiable6 left [05:57] *** unicodable6 left [05:57] *** committable6 left [05:57] *** tellable6 left [05:57] *** sourceable6 left [05:57] *** shareable6 left [05:57] *** notable6 left [05:57] *** reportable6 left [05:57] *** bloatable6 left [05:57] *** reportable6 joined [05:57] *** evalable6 joined [05:58] *** releasable6 joined [05:58] *** notable6 joined [05:58] *** bisectable6 joined [05:58] *** tellable6 joined [05:58] *** sourceable6 joined [05:58] *** nativecallable6 joined [05:58] *** greppable6 joined [05:58] *** coverable6 joined [05:58] *** squashable6 joined [05:59] *** bloatable6 joined [05:59] *** committable6 joined [05:59] *** statisfiable6 joined [05:59] *** unicodable6 joined [06:00] *** linkable6 joined [06:00] *** shareable6 joined [06:00] *** quotable6 joined [06:00] *** benchable6 joined [06:02] *** reportable6 left [06:04] *** reportable6 joined [07:08] *** patrickb joined [07:22] *** Kaiepi left [07:23] *** Kaiepi joined [07:54] *** brrt joined [07:55] \o [07:55] 2021-07-14T08:56:16Z #moarvm brrt Good *, brrt. https://colabti.org/irclogger/irclogger_log/moarvm?date=2021-07-14#l8 [07:55] o/ [07:55] and it's pure chance that I'm here when you arrived [07:56] and I'd forgotten that question from $other [07:56] you missed - a lot of new-disp progress [07:56] jnthn was on a roll [07:56] jnthn++ :-) [07:57] actually, that's not the nickname here [07:57] ehm, I think there might've been a silly thing for that actually [08:26] *** Kaiepi left [08:31] *** Kaiepi joined [08:32] *** brrt left [09:20] *** Kaiepi left [09:22] perhaps also interesting for the people here: https://github.com/rakudo/rakudo/issues/4456 [09:22] Label lost with spesh enabled [09:22] *** frost joined [09:23] *** Kaiepi joined [10:23] *** evalable6 left [10:23] *** linkable6 left [10:25] *** evalable6 joined [10:25] *** linkable6 joined [10:27] *** Kaiepi left [10:27] *** Kaiepi joined [10:32] *** sena_kun joined [10:38] re blin for new-disp: spec tests aside, it's a must for the `make install` to work (AFAIK it doesn't work yet now?) to test the branch. [10:41] sena_kun: make install already works [10:42] nine, oh, great! I'll do a run today in a couple of hours (just started the release one) [10:53] ¦ MoarVM/hash-fsck-fixes: 8b36d1230b | (Nicholas Clark)++ | src/core/str_hash_table.c [10:53] ¦ MoarVM/hash-fsck-fixes: Fix another bug in MVM_str_hash_fsck(). [10:53] ¦ MoarVM/hash-fsck-fixes: [10:53] ¦ MoarVM/hash-fsck-fixes: Calling `MVM_str_hash_entries` when just the control structure was allocated [10:53] ¦ MoarVM/hash-fsck-fixes: (the empty hash optimisation) would trigger an assertion failure. [10:53] ¦ MoarVM/hash-fsck-fixes: [10:53] ¦ MoarVM/hash-fsck-fixes: We need to check `control->cur_items` and `control->max_items` explicitly. [10:53] ¦ MoarVM/hash-fsck-fixes: It also makes sense to check for `control` being NULL and handling that case [10:53] ¦ MoarVM/hash-fsck-fixes: (instead of segfaulting). [10:53] ¦ MoarVM/hash-fsck-fixes: review: https://github.com/MoarVM/MoarVM/commit/8b36d1230b [10:53] ¦ MoarVM: nwc10++ created pull request #1514: Fix another bug in MVM_str_hash_fsck(). [10:53] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1514 [11:05] *** Kaiepi left [11:07] *** Kaiepi joined [12:02] *** reportable6 left [12:05] *** reportable6 joined [12:16] *** patrickb left [12:21] *** patrickb joined [12:33] ¦ MoarVM: 1180c98820 | (Stefan Seifert)++ | src/core/bytecodedump.c [12:33] ¦ MoarVM: Fix read buffer overflow in bytecode dumper [12:33] ¦ MoarVM: [12:33] ¦ MoarVM: The append_string function relied on the target buffer being calloced, so any [12:33] ¦ MoarVM: strings we copied into it would automatically get a trailing \0. However, when [12:33] ¦ MoarVM: the buffer became too small, we realloced it without zeroing the extension. [12:33] ¦ MoarVM: This resulted in reading past the buffer when actually printing the result [12:33] ¦ MoarVM: string. [12:33] ¦ MoarVM: [12:33] ¦ MoarVM: Fix by just appending that \0 manually whenever we append a string. This also [12:33] ¦ MoarVM: fixes the unsafe use of vsnprintf which caused us to read past the line [12:33] ¦ MoarVM: buffer when a line exceeded the maximum allowed length. [12:33] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1180c98820 [13:06] *** frost left [13:12] *** Util_ joined [13:13] *** jdv_ joined [13:15] *** [Coke]_ joined [13:18] *** [Coke] left [13:18] *** Util left [13:18] *** jdv left [13:48] Commit exists, but an executable could not be built for it [13:49] that's info for https://github.com/rakudo/rakudo/commit/43c8b3a4bc381cf05e39dc453002bd86a1b564a4 [13:50] ? [13:50] nine, that's what blin says [13:51] I'll look at it later, $dayjob time [13:54] jnthnwrthngtn: Turns out you did break reproducible build. But that was 2 years agon in https://github.com/Raku/nqp/commit/d97f3084addf86a5a187d404294deda82b173b70 :D [14:04] nine: Ahread of my time, I guess. :P But hm, is that the same issue that causes it to fail now? [14:05] Unfortunately no. Looks like NQP is OK now with my fix though. So it must be something in Rakudo itself [14:06] I think at some point you did some fixes so that anything that is compiled while compiling gets incorporated into the enclsoing compunit to fix EVAL at BEGIN time, and I wonder if the stuff I'm compiling is accidentally getting lumped in with that? [14:11] The most notable differences are strings that look like "104733760" [14:16] In case you missed me mentioning this: it was passing, and I broke it with ded9a561417e [14:16] Though that implies there was a problem anyway, just a hidden one [14:17] *** linkable6 left [14:17] *** linkable6 joined [14:17] I'm not sure how the logic in !produce-reader could lead to that; those numbers are too big to be cuids of the generated blocks... [14:29] ok, I know why new-disp branch cannot be built: one needs to bump the thing so that the correct versions were taken (right now it tries to build with moarvm from master and so fails). [14:30] I am not sure how to properly make it work from branches, though, I suspect putting just the branch name into the revision is not the way. [14:35] *** vrurg_ joined [14:36] *** vrurg left [14:38] jnthnwrthngtn: fun fact: the ProxyReaderFactory is not even used during reproducible-builds.t [14:38] o.O [14:39] By code in the test maybe not, but I think during startup (CORE.setting init) it is used... [14:40] as I thought, revision templates have no idea about branches [14:41] jnthnwrthngtn: well, this patch makes the problem go away (note line 10) https://gist.github.com/niner/2c0700ac42d5ae8c5d8bea03de1e69f7 [14:44] Oh, wait, that should be nqp::die. How does it even survive this?! [14:50] *** vrurg_ is now known as vrurg [14:52] nine: That's just a revert of the PR I pointed at? [14:52] Plus some error code that won't be reached [14:53] (because if we pre-fill the readers then we never need to produce them for any cases that you're likely hitting) [14:53] We can't just pre-define them because then they're not marked as thunks and that causes other failures [14:56] jnthnwrthngtn: no, I also added a die; in method new. Which in NQP can't work and seems to have been ignored. [14:57] I don't think it does listops, so it'll have interpreted it as a term [14:58] And it doesn't seem to bail over those [14:58] die() likely woulda whined [15:03] It seems to be this entry that does the trick: '1%0,', -> $a1, *%n { nqp::dispatch('boot-resume', 6, nqp::decont($a1), |%n) } [15:03] The other's don't make a difference [15:11] Because 1%0 is the only key that's in use [15:38] Possibly, yes; a bunch of them I added to cover unary/binary ops [15:38] If the code in question never passed a Proxy to such an op then they'd not be used [15:39] The original idea was to prime the hash with a few such cases so we'd not need to go and eval a QAST tree for them [15:39] But that doesn't work out, because there's no way to get them marked as a thunk [15:39] Thus why I dropped everything in the hash and relied on always going through the generation pass [15:40] Thus why I dropped everything in the hash and relied on always going through the generation pass [15:40] And it's going through that which seems to trip things up [15:45] Yeah, the Proxy in question is CompUnit::RepositoryRegistry's short-id2class [15:52] Yes, I was a little surprised to find myself having to handle multi dispatch over Proxy so relatively early on [15:52] Had to do it at some point though :) [15:54] ¦ MoarVM/new-disp: 375b818094 | (Jonathan Worthington)++ | src/core/callstack.c [15:54] ¦ MoarVM/new-disp: Fix exception handling situation with dispatchers [15:54] ¦ MoarVM/new-disp: [15:54] ¦ MoarVM/new-disp: If we have: [15:54] ¦ MoarVM/new-disp: * A dispatch with a catch handler around the dispatch instruction [15:54] ¦ MoarVM/new-disp: * A dispatcher written in bytecode that calls... [15:54] ¦ MoarVM/new-disp: * A dispatcher written in C that throws [15:54] ¦ MoarVM/new-disp: Then we need to make sure that the interpreter's current address is [15:54] ¦ MoarVM/new-disp: sync'd up before we run the dispatcher written in C, otherwise the [15:54] ¦ MoarVM/new-disp: catch handler will be missed. This kind of sandwich hasn't come up much [15:54] ¦ MoarVM/new-disp: before, thus this case was missed. [15:54] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/375b818094 [15:54] ¦ MoarVM/new-disp: e1df16065a | (Jonathan Worthington)++ | 5 files [15:54] ¦ MoarVM/new-disp: Reinstate per-language method not found handling [15:54] ¦ MoarVM/new-disp: [15:54] ¦ MoarVM/new-disp: Add a dispatcher that language dispatchers can defer to in order that [15:54] ¦ MoarVM/new-disp: the *calling* language's method not found handler is used. This is not [15:54] ¦ MoarVM/new-disp: quite backward compatible with the current solution, since now the [15:54] ¦ MoarVM/new-disp: method not found handler also receives the arguments. We'll call it a [15:54] ¦ MoarVM/new-disp: new feature. [15:54] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/e1df16065a [15:56] With those MoarVM commits and the NQP ones I just did, we should now enjoy clean `make test` in NQP. [15:57] jnthnwrthngtn++, seems you got a few minutes for new-disp today as well :) [15:58] jnthnwrthngtn++ [15:59] Head wasn't in the right place for figuring out new stuff on $other-project post-vaccination, so figured I'd work on some easy-ish things that needed stuff I've been looking at recently :) [16:00] have been subjected to dose 2 then? [16:00] *have you been ... [16:03] Yes [16:03] I don't see how just compiling that one block can lead to such massive differences. And it is compilation that throws in the wrench here. Even if we return the hard coded block, it still fails. [16:04] Yeah, that's how it looked to me (although I didn't do the analysis you have to rule out other possibilities) [16:04] Small discrepancies I could understand, but the diff is massive [16:04] * sena_kun confirms nqp tests are fixes, 2 files left for rakudo ones [16:04] Where did the EVAL-at-BEGIN-time fix get integrated with the compilation pipeline? [16:05] Though I'm starting it from the QAST step so hmm [16:08] Yay, fixing that method not found thing up didn't just get us NQP tests clean, but also gained one more spectest [16:08] Presumably one of the "wrong kind of exception" ones dogbert11++ mentioned yesterday [16:09] jnthnwrthngtn: that'd be https://github.com/Raku/nqp/commit/be58f8095c3adfd4fa8e3fa98f3bc76cd1322cd4 https://github.com/Raku/nqp/commit/f18e017903f89804e9429cc2c5da05094391089a and https://github.com/rakudo/rakudo/commit/537f8877034fa4c3697d3a8b093039b18c331b79 [16:09] *** patrickb left [16:10] Another bit: it's this call: nqp::getcomp('Raku').compile($block, :from); So just creating test QAST::Block object is harmless [16:12] I suspect integration/advent2011-day07.t [16:12] is the one I have the best chance of solving with my remaining energy today [16:12] It needs nqp::can to compile into some kind of dispatcher [16:14] I was sort of inclined to kill off findmethod and tryfindmethod entirely, but it's probably better to just have them delegate to the dispatcher stuff. [16:16] heh, it looks like a non-trivial amount of nqp::findmethod usage in Rakudo is working around the fact that NQP doesn't have $obj.Qualified::meth() [16:17] If we implemented that we could probably be rid of > 50% of it [16:17] greppable6: findmethod [16:17] jnthnwrthngtn, 16 lines, 13 modules: https://gist.github.com/4ce10c9f8556210e74554b3d7046c535 [16:18] 13 modules that I won't break also [16:18] Though looking at what a few of them are doing, this is only a stay of execution until RakuAST takes them out [16:21] nine: The description of https://github.com/Raku/nqp/commit/f18e017903f89804e9429cc2c5da05094391089a makes we wonder a bit [16:22] If we treat the compilation of the QAST as a nested compile, then is https://github.com/Raku/nqp/commit/f18e017903f89804e9429cc2c5da05094391089a#diff-0e15e16535afce8b8dcb349510cbe334820eb0af9771594e2534288b8e2bb027R387 happening? [16:25] *** dogbert17 joined [16:27] *** dogbert11 left [16:32] *** dogbert11 joined [16:34] *** dogbert17 left [16:39] *** patrickb joined [16:49] jnthnwrthngtn: yes, we're certainly on the right track there. This successfully works around the issue: https://gist.github.com/niner/1d0bb550f9fb26647d3fd88c4747a867 [16:49] I.e. turning it into a non-nested compilation [16:55] Ah, nice [16:55] I wonder if just declaring an empty `my %*COMPILING` would also [16:55] Already compiling just that :) [16:56] :) [16:56] And of course it does [16:56] Urgh, I suddenly feel very tired. Will continue the can/findmethod/tryfindmethod transition later [16:57] nine++ # figuring out the penultimate `make test` failure [16:57] bbia [16:57] *bbiab [16:57] Still this doesn't explain the differences between compilation runs though. Even if the compiled frame makes it into the bytecode file, so what? It should always be exactly the same one. [16:58] * nine likes his computers to be mostly deterministic [16:58] nine: I don't know, but I didn't give the block a cuid, maybe it synthesizes a filename or compunit name, or something? [16:58] Or those sneak in somehow [16:59] Further research is needed :D [16:59] :) [16:59] * jnthnwrthngtn really wanders afk [17:05] jnthnwrthngtn, et al.: https://gist.github.com/MasterDuke17/93d06244ec25556324544581c13cba1b does cause a minor change in the output of `raku --ll-exception -e 'grammar G { token TOP { $=() } }; G.parse("x")'` [17:05] from :1 (:) [17:05] from -e:1 (:TOP) [17:05] becomes [17:06] from -e:1 (:) [17:06] from -e:1 (:TOP) [17:06] so it looks like it picks up the '-e', but still not the 'xxx' [17:11] timo: what was your example to try? [17:12] *** sena_kun left [17:13] *** patrickb left [17:14] for getting the lack of names? i think it was just a random piece of nqp code from either nqp build or rakudo build [17:15] *** patrickb joined [17:27] *** Kaiepi left [17:32] *** Kaiepi joined [17:32] *** Kaiepi left [17:33] *** [Coke]_ is now known as [Coke] [17:36] *** Kaiepi joined [17:38] *** Kaipi joined [17:39] *** Kaiepi left [18:00] ah [18:02] *** reportable6 left [18:04] nine: interested in fixing a spesh related problem in new-disp? [18:05] *** reportable6 joined [18:17] *** dogbert11 left [18:17] *** dogbert17 joined [18:33] *** dogbert11 joined [18:36] *** dogbert17 left [18:41] *** dogbert11 left [18:48] Interested sure, but I'm still busy with the reproducibility issue :) [18:50] *** dogbert11 joined [18:56] *** dogbert11 left [18:57] *** dogbert11 left [18:59] *** dogbert11 joined [19:01] So, on the two compilation runs in the test we actually write back exactly the same frames to the outer compilation in the same order. Still we end up with those vast discrepancies [19:03] *** jdv_ is now known as jdv [19:03] huh [19:06] Well the answer to that is that it's not the actual writing back that creates the issue [19:08] *** squashable6 left [19:08] reading then? [19:09] *** squashable6 joined [19:17] No, more that it's about other shared data [19:21] somewhat a change of topic, but that patch i linked earlier gives one (i think new) passing TODO in t/spec/S32-exceptions/misc2.rakudo.moar and one fail in t/spec/S02-lexical-conventions/comments.t [19:23] the fail is getting an X::Syntax::Comment::Embedded instead of an X::Syntax::Confused [19:23] for `Subtest: no spaces allowed between '#`' and '<'` [19:24] m: dd EVAL "3 * #`\n 2" [19:24] rakudo-moar 5ecc8308f: OUTPUT: «5===SORRY!5=== Error while compiling /home/camelia/EVAL_0␤Two terms in a row␤at /home/camelia/EVAL_0:2␤------> 37⏏5 2␤ expecting any of:␤ infix␤ infix stopper␤ statement end␤ st…» [19:25] the passing TODO is also about X::Syntax::Comment::Embedded [19:27] MasterDuke: I wouldn't expect the `xxx` in the backtrace; the file and (probably accurate rather than always "1") line number is already good [19:28] yeah, if i put it in a file spread over a couple lines it give the right line number [19:28] yay [19:28] dogbert11: A spesh-related problem in new-disp? I didn't think it managed to spesh much of anything at the moment :) [19:29] m: EVAL "#`"; CATCH { default { dd } } # this is the new fail [19:29] rakudo-moar 5ecc8308f: ( no output ) [19:29] m: EVAL "3 * #`\n 2"; CATCH { default { dd $_ } } # this is the new passing TODO [19:29] rakudo-moar 5ecc8308f: OUTPUT: «X::Syntax::Confused.new(reason => "Two terms in a row", filename => "/home/camelia/EVAL_0", pos => 25, line => 2, column => Any, modules => [], is-compile-time => 1, pre => "", post => " 2", highexpect => ["infix", "infix stopper", "s…» [19:29] m: EVAL "#`"; CATCH { default { dd $_ } } # this is the new fail [19:29] rakudo-moar 5ecc8308f: ( no output ) [19:30] i have no idea if the failing test is correct or not [19:31] i have no idea if the failing test is correct or not [19:32] https://github.com/Raku/roast/blob/master/S32-exceptions/misc2.t#L187-L191 [19:34] https://github.com/Raku/roast/blob/master/S02-lexical-conventions/comments.t#L74-L76 [19:36] oh, i had them backwards above. EVAL "#`" now correctly throws. EVAL "3 * #`\n 2" now throws X::Syntax::Comment::Embedded instead of X::Syntax::Confused [19:39] So! It is just about %*COMPILING. Everything else can stay shared. [19:39] This is...quite weird as mast_frames is just a lookup hash to get a MAST::Frame by cuid. [19:39] jnthnwrthngtn: MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 ./rakudo-m -Ilib -MTest -e 'is do { [+] grep * %% 2, (1, 2, *+* ...^ * > 4_000_000) }, 4613732, "fibonacci"' [19:40] dogbert11: This is distinct to new-disp, not on master also? [19:41] on master I don't see it [19:43] don't see it here either [19:44] Curious. I can repro it [19:44] I'd just not expect very much to be being specialized at all at the moment [19:45] it still fails for me with inlining, osr and pea disabled but the problem vanishes with MVM_SPESH_DISABLE=1 [20:06] I've added debug output in every places that accesses the moar_frames hash and the usage pattern is exactly the same between runs and regardless of whether it's shared or not. [20:08] Err... mast_frames hash [20:09] *** evalable6 left [20:09] *** linkable6 left [20:10] *** evalable6 joined [20:12] *** linkable6 joined [22:24] *** dogbert17 joined [22:28] *** dogbert11 left [22:34] *** dogbert11 joined [22:36] *** squashable6 left [22:36] *** dogbert17 left [22:39] *** squashable6 joined [22:44] ¦ MoarVM/new-disp: 07f6ddd73b | (Jonathan Worthington)++ | 5 files [22:44] ¦ MoarVM/new-disp: Introduce lang-find-meth [22:44] ¦ MoarVM/new-disp: [22:44] ¦ MoarVM/new-disp: This dispatcher will be used to implement `can`, `findmethod`, and [22:44] ¦ MoarVM/new-disp: `tryfindmethod`. As with the other lang-* dispatchers, languages can [22:44] ¦ MoarVM/new-disp: plug in their own versions of them. [22:44] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/07f6ddd73b [22:46] *** patrickb left [22:48] *** linkable6 left [22:49] *** linkable6 joined [23:27] *** sortiz joined [23:30] *** sortiz left [23:34] * [Coke] tries a sour monkey sour tripel and ... meh [23:54] *** Merfont joined [23:54] *** Kaipi left