github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *able6, #moarvm 08:30
nine Yeah, *able6 is what we have most of here... 09:51
MasterDuke who need people when we have useful bots? 09:53
shouldn't github.com/MoarVM/MoarVM/pull/1344...3230cbR354 come after github.com/MoarVM/MoarVM/pull/1344...bR365-R366 ? it's in the same order as before converting to a REPR, but especially now 10:01
that we're going to be removing things, isn't that unsafe?
MasterDuke interesting. at local HEAD (so adding in the removing of spesh candidates) now get a segv in deopt_frame, from `f->static_info->body.bytecode` where is f->static_info is 0x0 10:35
oh 10:39
in MVM_spesh_deopt_one it's in the `if (f->spesh_cand) {` branch calling deopt_frame. but then in deopt_frame it's in the else of `if (f->spesh_cand && f->spesh_cand->body.inlines) {` and when the segv happens, not only is f->static_info 0x0, but so is f->spesh_cand 10:41
ah, well the entire *f is 0xo 10:43
but one level back in the backtrace (MVM_spesh_deopt_one) `*tc->cur_frame` (which is the f passed to deopt_frame) is not 0x0 10:46
nine MasterDuke: in what way would it be usafe? There shouldn't be anything different for adding candidates should there? 11:49
MasterDuke well, jnthn recommended doing roughly the same thing in MVM_spesh_candidate_discard_one. move `spesh->body.spesh_cands_and_arg_guards     = new_cands_and_arg_guards;` to after `MVM_spesh_arg_guard_regenerate(tc, &(new_cands_and_arg_guards->spesh_arg_guard), new_cands_and_arg_guards->spesh_candidates, new_num);` 11:53
which i believe fixed a segv (and left me with the invalid GC-owner panic) 11:54
though now i'm getting a segv, maybe because of fixing the missing MVMROOT (one of the recent commits to the PR)? 11:56
btw, merging that PR would make things a bit more convenient for me. i could create a new branch and PR instead of having some commits on the existing branch i'm being careful not to push. hopefully would make it easier for the rest of you to see the diff and help debug 11:57
do you have any objection to merging it now? 11:58
MasterDuke huh. there's `MVMFrame *f = tc->cur_frame;` at the very beginning of MVM_spesh_deopt_one, but then a bit of a mix of using both `f` and `tc->cur_frame` throughout github.com/MoarVM/MoarVM/blob/mast...#L280-L309 12:43
ha. here github.com/MoarVM/MoarVM/blob/mast...opt.c#L300 `*f ` is 0x0, but `*tc->cur_frame` is just fine 12:52
lizmat any SN9 watchers here with news ? 12:53
lizmat yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2021/02/01/2021-...proposing/ 16:19
looks like the earliest SN9 launch will be on Tue
nine MasterDuke: merge is ok with me 16:21
MasterDuke nine: cool, thanks 16:26
jnthn fwiw, new-disp isn't just about multiple dispatch, it's about All The Dispatch :) 16:29
nine And even things we didn't actually use to consider to be dispatch 16:30
lizmat so how would you phrase it ?
nwc10 All dispatch | Such unified | Better 16:32
there, someone on the Internet is wrong. This will need correcting :-) 16:33
lizmat changed it to "all dispatching" 16:35
El_Che I don't see nine in the fosdem schedule 16:36
jnthn "all dispatching" is fine 16:41
I plan to make a blog post when I get a bit further along
lizmat that's probably nine is too busy atm to do presentations 16:56
MasterDuke hm. if i "squash and merge" through the github ui, is it going to pull in all the commit messages? or do i manually need to that (or write a comprehensive one in the "extended description" section)?
nine would never trust a web UI with that... 16:58
jnthn I'm pertty sure it doesn't take all the commit messages 16:59
MasterDuke oh! then maybe i'd better manually squash them and massage the commit message(s) and then just do a regular merge 17:00
jnthn To me the retention of commit messages is usually a bit more important than "every commit builds", in that git bissect --first-parent means that we can avoid looking inside of branches and bissect only their merges 17:01
brrt` huh, no idea it worked that way 17:02
MasterDuke hm, wonder if that would be a good thing to implement for bisectable6 17:03
MasterDuke like i mentioned in a comment on the PR, i wish there was a way to attach messages to individual parts of a larger diff that don't really make sense as a comment. i.e., they're about the change in the code, not the final state 17:06
MasterDuke oh, no geth. i just merged github.com/MoarVM/MoarVM/pull/1344 19:58
nine MasterDuke: feels good, doesn't it? :) 20:02
MasterDuke well yeah, but the real goal (remove opts) is still segfaulting... 20:05
jnthn MasterDuke++ # yay 20:14
lizmat MasterDuke: time to bump MoarVM? 20:22
MasterDuke lizmat: sure. the changes shouldn't be visible to nqp/rakudo (yet), but it'd be good to get them more testing 20:23
lizmat ok, bumping 20:23
MasterDuke let me get the removing commits in a new PR so they can be looked at more easily
MasterDuke github.com/MoarVM/MoarVM/pull/1426 created 20:28
lizmat bumped 20:50

Powered by Cro and the Raku® Programming Language.

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

Thank you!