github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:28 lucasb left 02:02 leont left
nwc10 good *, #moarvm 06:58
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
brrt good * #moarvm 09:32
nwc10 good *, brrt 09:33
brrt ohai nwc10 09:34
timotimo imgur.com/qC8qCMp 09:38
brrt that the debugger? 09:39
cool
timotimo magic 09:48
nwc10 or sufficiently advanced technology? 09:50
09:53 brrt left
patrickb 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.
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:19
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. 11:24
lizmat patrickb++ 12:09
12:12 sena_kun joined 12:13 Altai-man left 12:45 zakharyas left
Geth MoarVM: 998ea76a17 | (Nicholas Clark)++ | src/core/exceptions.c
Calling `MVM_exception_throw_adhoc` in the spesh worker should be an oops.

Similarly no exceptions should be thrown in the event loop thread.
Also report these two special threads in `MVM_oops`, and treat a NULL thread context pointer in oops as a bug worthy of a panic.
  (Previously it would have "panic"ed because it would have crash due to the
NULL pointer dereference. This way, we give slightly better diagnostics.)		 13:47
MoarVM: fa9b6659a1 | (Nicholas Clark)++ | src/core/exceptions.c
Use simpler stdio calls in exceptions.c where possible.

fputc('\n', stderr) is simpler than fprintf(...) or fwrite(...) Because `fputs` is not varargs, the caller has a simpler ABI than `fprintf` on some architectures (eg x86_64).
  (Well, that's the theory anyway. In practice, it seems that a new enough gcc
optimises simple cases of either into calls to `fwrite`.)
MoarVM: f3e9e356d2 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/core/exceptions.c
Merge pull request #1390 from MoarVM/exception-in-spesh-should-oops

Exceptions in spesh should oops
nwc10 I was a bit surprised how agressive gcc's optimisation was 14:02
"oh, I'll just turn it into fwrite for you", for both fputs and fprintf with a fixed string 14:03
nine That's decades of adding optimizations for you 14:26
14:31 squashable6 left 14:33 squashable6 joined 14:38 lucasb joined 15:20 travis-ci joined
travis-ci MoarVM build passed. Jonathan Worthington 'Merge pull request #1390 from MoarVM/exception-in-spesh-should-oops 15:20
travis-ci.org/MoarVM/MoarVM/builds/746263391 github.com/MoarVM/MoarVM/compare/b...e9e356d272
15:20 travis-ci left 15:53 zakharyas joined
nwc10 jnthn: you may appreciate that this is a bit of a loaded question, but I guess you can see where it's headed... 15:59
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) ?
jnthn 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:02
nwc10 OK 16:03
second sort of loaded question is "are backtraces supposed to be invariant whether spesh is running or not?"
jnthn Those should not be in spectest, but there may be some in Rakudo's make test
nwc10 basically
MVM_SPESH_DISABLE=1 ASAN_OPTIONS=detect_leaks=0 ./rakudo-m -Ilib t/spec/S32-exceptions/misc.rakudo.moar 16:04
fails 2 tests
and the quirky bit is that they are fudged for the JVM
and I think that actually the JVM is correct
(not that I have built a JVM Rakduo yet to confirm this)
jnthn I don't know we've ever committed one way or the other on that 16:05
nwc10 t/spec/S32-exceptions/misc.rakudo.moar fails these 2 tests *differently* with MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1
I'm fine with "not committed"
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
(and confirm what the JVM does)
and then also fudge it for MoarVM
jnthn It's nice if we can always produce the same backtrace 16:06
In theory "we can using the deopt info"
But will the deopt into always be enough?
*info
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?
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:08
nwc10 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
oh, and on "all the platforms"
jnthn Yes, that's indeed desirable 16:11
16:11 Altai-man joined
jnthn 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
nwc10 hence that rather stinky complicated PR for the floating point conversion
and this one github.com/MoarVM/MoarVM/pull/1369 16:12
16:14 sena_kun left 16:26 zakharyas left 16:27 zakharyas joined
timotimo patrickb: with the same script that packages moarperf, i can make an AppImage of the debugger 16:36
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
and a complete re-organization of the commands it currently has, they are silly and counter-intuitive
17:00 MasterDuke left
patrickb 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.
Geth MoarVM/faster-repeated-unshift: 5a21247e9f | (Jonathan Worthington)++ | src/6model/reprs/VMArray.c
Improve performance of repeated `unshift`ing

Prior to this, we always created a fixed amount of extra space (8 elements) at the start of the array, regardless of array size. With this change we start accounting for the number of elements in the array. This will make no difference for steady state unshift/pop, but for situations where we repeatedly unshift will bring the performance in line with that of push. Fixes #1382.		 17:55
MoarVM: jnthn++ created pull request #1392:
Improve performance of repeated `unshift`ing		 17:56
18:03 Kaeipi left 18:10 domidumont left 18:23 domidumont joined
Geth MoarVM/faster-repeated-unshift: d0d6088afc | (Jonathan Worthington)++ | src/6model/reprs/VMArray.c
Remove duplicated word in comment
 18:25
19:20 brrt joined
nine (v)room (v)room 19:22
brrt zooom zooom 19:23
nwc10 but I hope not oom oom 19:24
lizmat OM 19:26
brrt I hope not, either
19:27 domidumont left
timotimo 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
patrickb yes that was me...
19:40 MasterDuke joined
MasterDuke timotimo: cool 19:41
20:12 sena_kun joined 20:13 Altai-man left 20:24 brrt left 20:36 brrt joined
Geth MoarVM/hash-bits-in-metadata: 39690f50ae | (Nicholas Clark)++ | src/core/str_hash_table.h
Two words missing from comments spotted by jnthn++
 21:04
MoarVM/hash-bits-in-metadata: 0641ce8402 | (Nicholas Clark)++ | 2 files
Add `MVM_index_hash_allocated_size` for MVMStaticFrame's `unmanaged_size`

It's easy to calculate this accurately, so we should.
nwc10 that's doomed to fail against nqp and rakudo master...
jnthn Oh? 21:05
Ah, version bumps maybe
nwc10 yes, and probably real test failures that are fixed
I actually tested it with a merge of master 21:06
21:08 zakharyas left
MasterDuke i usually rebase my PRs against master if there's been a bunch of changes and force push 21:09
21:09 brrt left
nwc10 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
but not for me tonight
jnthn 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
I didn't look at the second one at all yet 21:11
nwc10 OK. I'm still not going to do anything tonight
jnthn 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 :)
As in, a few weeks of testing...
nwc10 I was about to go to bed. I don't think I even want to suggest a plan right now. 21:12
and thanks for giving it a careful review 21:13
MasterDuke 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
21:21 leont_ joined 21:24 leont left 21:25 MasterDuke left 22:09 sena_kun left
jnthn .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
tellable6 jnthn, I'll pass your message to MasterDuke
jnthn .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
tellable6 jnthn, I'll pass your message to MasterDuke
22:22 patrickb left
timotimo welp, i just threw an exception into a thread with the debugserver and the P6EX hash via the hll value access mechanism 22:32
gist.github.com/timo/08705f1fe617c...3febd28c66 22:35
moon-child jnthn: alignment is not an issue. E.G. sizeof(struct { char a; double t[]; }) is 8 22:36
jnthn 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.
moon-child oic 22:40
timotimo 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:44
but when you run some utility code that ends up throwing, you may want it to abort?! 22:45
jnthn 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?
And then just unwind the frames introduced by the call?
"just" :) 22:47
Also, do we get a handle to the object returned by some code run on the debug server?
timotimo yes, we will. not just yet, but soon enough 22:56
jnthn cool 22:59
Now I can start thinking of terrifying things to do with this new power :)
timotimo aye
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:01
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
jnthn Yeah, I'd prefer to punt the problem there than complicate the VM layer 23:04
timotimo so if you invoke something directly and it throws an exception, Don't Do That Then 23:06
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" } }`
jnthn Needs to be CATCH { default { say "oh bugger" } }, but yes :P 23:08
timotimo ok, "default {" fits my definition of "not terribly much" 23:09
and balancing out the braces

Powered by Cro and the Raku® Programming Language.

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

Thank you!