[01:28] *** lucasb left [02:02] *** leont left [06:58] good *, #moarvm [07:43] *** domidumont joined [07:49] *** patrickb joined [08:09] *** sena_kun joined [08:11] *** Altai-man joined [08:14] *** sena_kun left [08:48] *** leont joined [09:01] *** zakharyas joined [09:27] *** brrt joined [09:32] good * #moarvm [09:33] good *, brrt [09:34] ohai nwc10 [09:38] https://imgur.com/qC8qCMp [09:39] that the debugger? [09:39] cool [09:48] magic [09:50] or sufficiently advanced technology? [09:53] *** brrt left [11:18] timotimo: I think the command line debugger is a tool that has a really big potential to change how people use Raku. [11:18] A debugger allows inspecting a program so not only aids in debugging, but also inspecting how a program works. So it's also a learning tool. [11:19] Given Raku is also a scripting language having that available on the command line and not only in an IDE makes it a lot more suitable for quickly having a look at that small to medium sized ish script one writes. [11:24] But to serve that purpose it needs to be a bit more polished. Simple installation and a shortish getting started document are the most pressing necessities. [12:09] patrickb++ [12:12] *** sena_kun joined [12:13] *** Altai-man left [12:45] *** zakharyas left [13:47] ¦ MoarVM: 998ea76a17 | (Nicholas Clark)++ | src/core/exceptions.c [13:47] ¦ MoarVM: Calling `MVM_exception_throw_adhoc` in the spesh worker should be an oops. [13:47] ¦ MoarVM: [13:47] ¦ MoarVM: Similarly no exceptions should be thrown in the event loop thread. [13:47] ¦ MoarVM: [13:47] ¦ MoarVM: Also report these two special threads in `MVM_oops`, and treat a NULL [13:47] ¦ MoarVM: thread context pointer in oops as a bug worthy of a panic. [13:47] ¦ MoarVM: [13:47] ¦ MoarVM: (Previously it would have "panic"ed because it would have crash due to the [13:47] ¦ MoarVM: NULL pointer dereference. This way, we give slightly better diagnostics.) [13:47] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/998ea76a17 [13:47] ¦ MoarVM: fa9b6659a1 | (Nicholas Clark)++ | src/core/exceptions.c [13:47] ¦ MoarVM: Use simpler stdio calls in exceptions.c where possible. [13:48] ¦ MoarVM: [13:48] ¦ MoarVM: fputc('\n', stderr) is simpler than fprintf(...) or fwrite(...) [13:48] ¦ MoarVM: Because `fputs` is not varargs, the caller has a simpler ABI than `fprintf` [13:48] ¦ MoarVM: on some architectures (eg x86_64). [13:48] ¦ MoarVM: [13:48] ¦ MoarVM: (Well, that's the theory anyway. In practice, it seems that a new enough gcc [13:48] ¦ MoarVM: optimises simple cases of either into calls to `fwrite`.) [13:48] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/fa9b6659a1 [13:48] ¦ MoarVM: f3e9e356d2 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/core/exceptions.c [13:48] ¦ MoarVM: Merge pull request #1390 from MoarVM/exception-in-spesh-should-oops [13:48] ¦ MoarVM: [13:48] ¦ MoarVM: Exceptions in spesh should oops [13:48] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f3e9e356d2 [14:02] I was a bit surprised how agressive gcc's optimisation was [14:03] "oh, I'll just turn it into fwrite for you", for both fputs and fprintf with a fixed string [14:26] That's decades of adding optimizations for you [14:31] *** squashable6 left [14:33] *** squashable6 joined [14:38] *** lucasb joined [15:20] *** travis-ci joined [15:20] MoarVM build passed. Jonathan Worthington 'Merge pull request #1390 from MoarVM/exception-in-spesh-should-oops [15:20] https://travis-ci.org/MoarVM/MoarVM/builds/746263391 https://github.com/MoarVM/MoarVM/compare/bfce05394d8a...f3e9e356d272 [15:20] *** travis-ci left [15:53] *** zakharyas joined [15:59] jnthn: you may appreciate that this is a bit of a loaded question, but I guess you can see where it's headed... [16:00] 1) the "canonical" "correct" output of MoarVM and Rakudo is when running without spesh? [16:00] (ie with MVM_SPESH_DISABLE=1 all tests should pass) ? [16:02] Yes, with the caveat that sometimes there are performance tests written that aim to check timings of certain things, and they may well be vulnerable. [16:03] OK [16:03] second sort of loaded question is "are backtraces supposed to be invariant whether spesh is running or not?" [16:03] Those should not be in spectest, but there may be some in Rakudo's make test [16:03] basically [16:04] MVM_SPESH_DISABLE=1 ASAN_OPTIONS=detect_leaks=0 ./rakudo-m -Ilib t/spec/S32-exceptions/misc.rakudo.moar [16:04] fails 2 tests [16:04] and the quirky bit is that they are fudged for the JVM [16:04] and I think that actually the JVM is correct [16:04] (not that I have built a JVM Rakduo yet to confirm this) [16:05] I don't know we've ever committed one way or the other on that [16:05] t/spec/S32-exceptions/misc.rakudo.moar fails these 2 tests *differently* with MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 [16:05] I'm fine with "not committed" [16:05] I think that the right thing (for now) is for me to send a PR to have the test work properly under MVM_SPESH_DISABLE=1 [16:05] (and confirm what the JVM does) [16:05] and then also fudge it for MoarVM [16:06] It's nice if we can always produce the same backtrace [16:06] In theory "we can using the deopt info" [16:06] But will the deopt into always be enough? [16:06] *info [16:07] And are we tying our hands in the future when we understand more and can toss more deopt points (PEA for example can reveal such things) [16:07] Or should we tie our hands anyway because reliable backtraces are important? [16:08] Given all the questions, it's one of those "don't decide until somebody makes me, and at least then it'll be done with more info" :) [16:09] yes, I'm fine with "don't decide yet" [16:09] but I wanted all the sepctests to pass under MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 [16:09] oh, and on "all the platforms" [16:11] Yes, that's indeed desirable [16:11] *** Altai-man joined [16:11] I worry that we have things that depend on backtraces (like `is DEPRECATED`) and those will be what force us to reliably provide the backtraces [16:11] hence that rather stinky complicated PR for the floating point conversion [16:12] and this one https://github.com/MoarVM/MoarVM/pull/1369 [16:14] *** sena_kun left [16:26] *** zakharyas left [16:27] *** zakharyas joined [16:36] patrickb: with the same script that packages moarperf, i can make an AppImage of the debugger [16:37] something important to have would be discovery of source code so that line numbers can be shown with code and a bit of context ideally [16:37] also, a better readline-like thing, hopefully with tab completion as well [16:37] and a complete re-organization of the commands it currently has, they are silly and counter-intuitive [17:00] *** MasterDuke left [17:13] timotimo: I'm reading through the docs of how to install again. The debugger is installable via zef. That's fine for most use cases. I think a simple update of the "Beta use instructions" updating the bits about modifying the raku startup scripts (they aren't scripts anymore!) is a good first thing to do. [17:13] timotimo: I pretty much agree to all of your points. [17:55] ¦ MoarVM/faster-repeated-unshift: 5a21247e9f | (Jonathan Worthington)++ | src/6model/reprs/VMArray.c [17:55] ¦ MoarVM/faster-repeated-unshift: Improve performance of repeated `unshift`ing [17:55] ¦ MoarVM/faster-repeated-unshift: [17:55] ¦ MoarVM/faster-repeated-unshift: Prior to this, we always created a fixed amount of extra space (8 [17:55] ¦ MoarVM/faster-repeated-unshift: elements) at the start of the array, regardless of array size. With [17:55] ¦ MoarVM/faster-repeated-unshift: this change we start accounting for the number of elements in the [17:55] ¦ MoarVM/faster-repeated-unshift: array. This will make no difference for steady state unshift/pop, [17:55] ¦ MoarVM/faster-repeated-unshift: but for situations where we repeatedly unshift will bring the [17:55] ¦ MoarVM/faster-repeated-unshift: performance in line with that of push. Fixes #1382. [17:55] ¦ MoarVM/faster-repeated-unshift: review: https://github.com/MoarVM/MoarVM/commit/5a21247e9f [17:56] ¦ MoarVM: jnthn++ created pull request #1392: Improve performance of repeated `unshift`ing [17:56] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1392 [18:03] *** Kaeipi left [18:10] *** domidumont left [18:23] *** domidumont joined [18:25] ¦ MoarVM/faster-repeated-unshift: d0d6088afc | (Jonathan Worthington)++ | src/6model/reprs/VMArray.c [18:25] ¦ MoarVM/faster-repeated-unshift: Remove duplicated word in comment [18:25] ¦ MoarVM/faster-repeated-unshift: review: https://github.com/MoarVM/MoarVM/commit/d0d6088afc [19:20] *** brrt joined [19:22] (v)room (v)room [19:23] zooom zooom [19:24] but I hope not oom oom [19:26] OM [19:26] I hope not, either [19:27] *** domidumont left [19:28] patrickb: you don't even have to change the startpu scripts any more, since someone (you?) made them pass them on by themselves [19:28] yes that was me... [19:40] *** MasterDuke joined [19:41] timotimo: cool [20:12] *** sena_kun joined [20:13] *** Altai-man left [20:24] *** brrt left [20:36] *** brrt joined [21:04] ¦ MoarVM/hash-bits-in-metadata: 39690f50ae | (Nicholas Clark)++ | src/core/str_hash_table.h [21:04] ¦ MoarVM/hash-bits-in-metadata: Two words missing from comments spotted by jnthn++ [21:04] ¦ MoarVM/hash-bits-in-metadata: review: https://github.com/MoarVM/MoarVM/commit/39690f50ae [21:04] ¦ MoarVM/hash-bits-in-metadata: 0641ce8402 | (Nicholas Clark)++ | 2 files [21:04] ¦ MoarVM/hash-bits-in-metadata: Add `MVM_index_hash_allocated_size` for MVMStaticFrame's `unmanaged_size` [21:04] ¦ MoarVM/hash-bits-in-metadata: [21:04] ¦ MoarVM/hash-bits-in-metadata: It's easy to calculate this accurately, so we should. [21:04] ¦ MoarVM/hash-bits-in-metadata: review: https://github.com/MoarVM/MoarVM/commit/0641ce8402 [21:04] that's doomed to fail against nqp and rakudo master... [21:05] Oh? [21:05] Ah, version bumps maybe [21:05] yes, and probably real test failures that are fixed [21:06] I actually tested it with a merge of master [21:08] *** zakharyas left [21:09] i usually rebase my PRs against master if there's been a bunch of changes and force push [21:09] *** brrt left [21:10] I wasn't sure if jnthn was trying to review them as-is [21:10] it might make sense to rebase both branches to master [21:10] but not for me tonight [21:10] nwc10: I've looked through the single memory block one and didn't see anything that concerned me; I'm happy for it to go in [21:11] I didn't look at the second one at all yet [21:11] OK. I'm still not going to do anything tonight [21:11] Sure, just so you aren't blocking on me if you want to get the first one merged. Good for it to get some testing ahead of the release also :) [21:11] As in, a few weeks of testing... [21:12] I was about to go to bed. I don't think I even want to suggest a plan right now. [21:13] and thanks for giving it a careful review [21:21] i not-infrequently wish i'd ever taken a c class. i'm not sure how to alloc an MVMArrayBody with a known size for slots as one chunk. `MVMArrayBody *body = fsa_alloc(3 * sizeof(MVMuint64) + n * repr_data->elem_size)`? `MVMArrayBody *body = fsa_alloc(sizeof(struct MVMArrayBody) + n * repr_data->elem_size)`? [21:21] *** leont_ joined [21:24] *** leont left [21:25] *** MasterDuke left [22:09] *** sena_kun left [22:13] .tell MasterDuke probably best is to have a `struct` that contains the metadata, and then sizeof(that_struct) + n * repr_data->elem_size, however you may need to worry about alignment on some platforms (32-bit ones that want an array of 64-bit integers or doubles aligned to 8 byte boundaries) [22:13] jnthn, I'll pass your message to MasterDuke [22:14] .tell MasterDuke But you can defer the alignment and just make it work at all first; it won't be a big change [22:14] jnthn, I'll pass your message to MasterDuke [22:22] *** patrickb left [22:32] welp, i just threw an exception into a thread with the debugserver and the P6EX hash via the hll value access mechanism [22:35] https://gist.github.com/timo/08705f1fe617cdbab3f8f83febd28c66 [22:36] jnthn: alignment is not an issue. E.G. sizeof(struct { char a; double t[]; }) is 8 [22:38] moon-child: That's not quite the situation though; we're allocating a single piece of memory to hold a metadata struct *and* elements that follow it; the elements vary in size depending on the type of array. [22:38] It's the padding between the struct and the elements (not part of the struct) that is in question. [22:40] oic [22:44] throwing an exception now makes me wonder how exactly special unwind should be handled. clearly when you use the p6ex hash to throw an exception you don't want a "oh no, an unhandled exception happened in code run by the debugserver! we'll crash now, thanks" [22:45] but when you run some utility code that ends up throwing, you may want it to abort?! [22:46] I'd probably write a support library that installs itself into hllsym and have it catch, probably, but yeah, we need fallback semantics [22:46] Can we convey the exception that went unhandled back over the debug protocol? [22:46] And then just unwind the frames introduced by the call? [22:47] "just" :) [22:47] Also, do we get a handle to the object returned by some code run on the debug server? [22:56] yes, we will. not just yet, but soon enough [22:59] cool [22:59] Now I can start thinking of terrifying things to do with this new power :) [22:59] aye [23:01] anyway, at the point where the special unwind is hit, which is what i'm currently hooking into to make this work, it'll already be, well, unwinding [23:03] i suppose the other way to do it is to put an exception handler on the stack [23:03] which in theory could be the task of the helper library [23:04] Yeah, I'd prefer to punt the problem there than complicate the VM layer [23:06] so if you invoke something directly and it throws an exception, Don't Do That Then [23:07] i imagine the helper library will then have a signature like `\code-obj, |arguments` [23:07] and it'll be not terribly much more than `try { code-obj(|arguments); CATCH { say "oh bugger" } }` [23:08] Needs to be CATCH { default { say "oh bugger" } }, but yes :P [23:09] ok, "default {" fits my definition of "not terribly much" [23:09] and balancing out the braces