03:20 bisectable6 left, nativecallable6 left, shareable6 left, coverable6 left, greppable6 left, tellable6 left, benchable6 left, unicodable6 left, squashable6 left, evalable6 left, sourceable6 left 03:21 benchable6 joined, bisectable6 joined 03:22 squashable6 joined, sourceable6 joined, evalable6 joined, tellable6 joined, coverable6 joined 03:23 greppable6 joined, nativecallable6 joined, unicodable6 joined, shareable6 joined 04:24 benchable6 left, bisectable6 left, sourceable6 left, releasable6 left, coverable6 left, evalable6 left, shareable6 left, greppable6 left, nativecallable6 left, tellable6 left, unicodable6 left, squashable6 left, quotable6 left, notable6 left, linkable6 left, bloatable6 left, committable6 left, statisfiable6 left, squashable6 joined, shareable6 joined 04:25 tellable6 joined, committable6 joined, sourceable6 joined, coverable6 joined, greppable6 joined 04:26 quotable6 joined, bloatable6 joined, linkable6 joined, evalable6 joined, bisectable6 joined 04:27 benchable6 joined, nativecallable6 joined, statisfiable6 joined, unicodable6 joined, notable6 joined, releasable6 joined 07:25 domidumont joined
nwc10 good *able6, #moarvm 08:30
08:31 Altai-man_ left 08:56 vrurg_ joined 08:58 vrurg left 09:07 sena_kun joined 09:31 MasterDuke joined 09:44 avar joined
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?
10:10 MasterDuke left 10:20 MasterDuke joined
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
11:09 avar left, avar joined
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
12:37 ggoebel_ left, ggoebel_ joined
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
13:33 ggoebel_ left 13:35 MasterDuke left, MasterDuke joined 13:38 ggoebel_ joined 14:24 zakharyas joined 14:45 brrt joined 15:41 brrt left
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
16:27 brrt joined
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 ?
16:32 brrt` joined, brrt left
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
17:05 brrt` is now known as brrt
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
17:28 domidumont left 17:33 brrt left 17:44 [Coke] joined, MasterDuke left 17:49 domidumont joined 18:05 domidumont left 19:23 vrurg_ is now known as vrurg 19:24 vrurg left 19:25 zakharyas left 19:31 MasterDuke joined 19:38 MasterDuke left 19:41 MasterDuke joined 19:57 brrt joined
MasterDuke oh, no geth. i just merged github.com/MoarVM/MoarVM/pull/1344 19:58
20:00 vrurg joined, vrurg left
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
20:23 vrurg joined
lizmat ok, bumping 20:23
MasterDuke let me get the removing commits in a new PR so they can be looked at more easily
20:26 releasable6 left, notable6 left, statisfiable6 left, nativecallable6 left, bisectable6 left, linkable6 left, quotable6 left, greppable6 left, shareable6 left, squashable6 left
MasterDuke github.com/MoarVM/MoarVM/pull/1426 created 20:28
20:38 zakharyas joined
lizmat bumped 20:50
21:15 shareable6 joined 21:16 greppable6 joined, bisectable6 joined, squashable6 joined, releasable6 joined, nativecallable6 joined 21:17 linkable6 joined, quotable6 joined, notable6 joined, statisfiable6 joined 21:26 zakharyas left 21:48 MasterDuke left 23:39 brrt left