|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
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
|
|||