|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:02
sena_kun joined
00:04
Altai-man_ left
00:41
vrurg left
00:48
vrurg joined
00:52
vrurg left
01:11
vrurg joined
01:29
MasterDuke left
01:55
lucasb left
02:01
Altai-man_ joined
02:02
vrurg left
02:03
sena_kun left
02:18
vrurg joined
02:38
AlexDaniel left
02:40
AlexDaniel joined,
AlexDaniel left,
AlexDaniel joined
04:02
sena_kun joined
04:03
Altai-man_ left
06:01
Altai-man_ joined
06:03
sena_kun left
|
|||
| nwc10 | good *, #moarvm | 06:19 | |
|
07:45
zakharyas joined
08:02
sena_kun joined
08:04
Altai-man_ left
08:13
MasterDuke joined
08:25
MasterDuke left
09:01
MasterDuke joined
|
|||
| jnthn | morning o/ | 09:29 | |
| tellable6 | 2020-06-28T10:45:40Z #raku-dev <Kaiepi> jnthn, is github.com/Raku/nqp/pull/597 ok on the condition that nqp::listen always be called directly after nqp::bind_sk when binding streaming sockets? | ||
| nwc10 | \o | ||
| lizmat | /o | 09:30 | |
| sena_kun | o/ | 09:31 | |
| MasterDuke | morning. i would ask if now is a good time to merge github.com/MoarVM/MoarVM/pull/1320, but it seems github is down | 09:32 | |
|
10:01
Altai-man_ joined
|
|||
| jnthn | Yes, I'm now onto my third task of the day that I'm attemting to do, but finding I can't quite do 'cus github is down :/ | 10:02 | |
| *attempting | |||
|
10:04
sena_kun left
|
|||
| nwc10 | So ahead of its time :-) -- www.youtube.com/watch?v=-Kobdb37Cwc | 10:07 | |
| (not a Rickroll.) | |||
| MasterDuke | ah, back now | 10:08 | |
|
10:44
gmoshkin joined
10:47
gmoshkin left
11:46
zakharyas left
12:02
sena_kun joined
12:03
Altai-man_ left
|
|||
| jnthn | Hm, this is odd. Somehow we end up in a situation where there's something on the stack top (a frame) that doesn't match up with tc->cur_frame (it's one frame deeper than that), and I can't figure out how it gets left behind there | 12:40 | |
| It's got bogus content, and we end up tripping over it during GC | |||
| moritz | sounds like something that deopt could do? (just spitballing, have no real knowledge about it) | 12:41 | |
| does it happen with spesh disabled? | 12:42 | ||
| jnthn | Not that I can see; I did already consider deopt as a possible cause | ||
| Oh...the thread that is being marked is not the one that triggers GC | |||
| timotimo | whew | 12:43 | |
| jnthn | ahh...I see it | 12:44 | |
|
12:46
zakharyas joined
|
|||
| timotimo | a bad mark_thread_blocked? | 12:51 | |
| Geth | MoarVM/new-disp: 008d4afae0 | (Jonathan Worthington)++ | src/core/frame.c Reorder frame invoke logic for safety The call stack entry needs to be sufficiently set up before we try to GC mark it. Sending spesh log entries can cause us to enter GC. Make sure we have set code_ref and outer before that can ever happen, so that we don't mark leftover junk pointers. |
12:53 | |
| jnthn | hah, and get got rid of one more `make test` Rakudo failure too, it seems | 12:56 | |
| I think all the current ones are known NYI of things | |||
|
13:01
dogbert17 left
|
|||
| jnthn | Guess I'd better do some kind of wiring up of multi dispatch to the new dispatch mechanism, since there's so many failures relating to that, that I can't actually see if there's any other interesting ones. :) | 13:04 | |
| Geth | MoarVM/new-disp: 3be0031c4b | (Jonathan Worthington)++ | 3 files Make captureposelems work on MVMCapture |
13:45 | |
|
13:46
AlexDaniel` left,
dogbert17 joined
13:50
Geth left,
Geth joined
13:53
Kaiepi left
14:01
Altai-man_ joined
14:04
sena_kun left
14:07
AlexDaniel` joined
|
|||
| timotimo | gist.github.com/timo/19da667195e0d...d274991518 - here's my patch for logging the resolution of a dispatch program based on the correlation id that was there at the beginning | 14:20 | |
| ooh, wasn't there a thing where i was supposed to implement the correlation id lookup based on what's on the stack, i.e. if multiple run frames are on top of it? | 14:21 | ||
|
14:26
MasterDuke left
|
|||
| jnthn | timotimo: Will have a look at it when I'm not trying to re-work multi dispatch... :) | 15:02 | |
| timotimo | aye | 15:03 | |
| jnthn | (Which is quite tricky, given I'm giving the algorithm a bit of an overhaul too, so we can, for example, avoid some of the repeated nominal type checking we do today when there's candidates that need bind checks) | ||
| nwc10 | but surely you can mutli-task when you're doing mulit-dispatch? | ||
| jnthn | Yes, but only if the other task is undemanding, like "drink tea" | 15:04 | |
| nwc10 | and by some coincidence, that's also what I'm doing | ||
| lizmat | as am I :-) | 15:10 | |
| darn, out of it again :-) | |||
| Geth | MoarVM/new-disp: 08c34ce157 | (Jonathan Worthington)++ | 3 files Implement captureposprimspec for MVMCapture |
15:30 | |
|
15:43
rypervenche left
15:46
rypervenche joined
16:02
sena_kun joined
16:03
Altai-man_ left
|
|||
| jnthn | Hm, turns out a fairly incomplete multi dispatch impl gets a lot of the tests back | 16:17 | |
| (To be clear, I'm not actually using it for all multi-dispatch yet, only those cases where a coercion on a return type bottoms out in doing a multi dispatch) | 16:18 | ||
|
16:59
Kaiepi joined
|
|||
| jnthn | Uff, probably at the point where I should rebase all the new-disp things onto Rakudo HEAD 'cus I suspect many of my remaining spectest failures are due to missing HEAD fixes | 17:15 | |
| Well, onto everything HEAD really | 17:17 | ||
|
17:23
japhb left,
japhb joined
|
|||
| jnthn | Wow, after rebasing, only 8 spectests showing issues on new-disp. (Noting that we're only using it in place of spesh plugins so far, for the most part) | 17:34 | |
| And it seems 5 of them are for the same bit of NYI multi dispatch stuff | 17:35 | ||
| Geth | MoarVM/new-disp: 141 commits pushed by (Jonathan Worthington)++, (Timo Paulssen)++ review: github.com/MoarVM/MoarVM/compare/0...7097168e76 |
17:37 | |
| jnthn | All rebased, so will need some twiddling for anyone testing it | 17:38 | |
| (There were assorted conflicts on MoarVM, and I find those easier to deal with - not to mention getting cleaner history - with a rebase workflow.) | |||
| nine | Are you planning on merging it as soon as it can fully replace spesh plugins or only when it replaces all dispatch? | 17:39 | |
| jnthn | Undecided. | 17:41 | |
| There's a horrible hack or two that would probably need to be turned into something more robust if we want to merge it sooner | |||
| While if we wait until it replaces all dispatch then the hacks in question become dead code and so I just delete them :) | 17:42 | ||
| Home time o/ | 17:46 | ||
|
17:48
zakharyas left
18:01
Altai-man_ joined
18:03
sena_kun left
18:07
MasterDuke joined
|
|||
| Geth | MoarVM: 193748846b | (Daniel Green)++ | src/jit/core_templates.expr Add JIT templates for return_(i|n|s) Based off of the pre-existing one for return_o. |
18:09 | |
| MoarVM: 5832b26289 | MasterDuke17++ (committed using GitHub Web editor) | src/jit/core_templates.expr Merge pull request #1320 from MasterDuke17/jit_templates_for_return_ins Add JIT templates for return_(i|n|s) |
|||
|
18:50
dogbert17 left
18:53
dogbert17 joined
18:57
zakharyas joined
|
|||
| timotimo | trying to run update_ops has callstack.c's mark stumble over a MVM_CALLSTACK_RECORD_FLATTENING | 19:03 | |
| so i'll implement that | |||
| nwc10 | jnthn: ASAN excited by new-disp -- paste.scsys.co.uk/591952 | 19:06 | |
| there were other failures in the test summary, but when I picked a different one and re-ran it, it seemed fine | |||
| so not sure how many bugs there are | 19:07 | ||
| but nonzero, which makes ASAN's day | |||
| it's a use-after free. The free is in remove_one_frame | |||
| might need FSA_DEBUG to expose it | 19:08 | ||
| timotimo | thanks to a MVM_callsite_mark, it was trivial | 19:09 | |
| Geth | MoarVM/new-disp: 6885813817 | (Timo Paulssen)++ | src/core/callstack.c implement marking of MVM_CALLSTACK_RECORD_FLATTENING using MVM_callsite_mark on the &record.produced_cs. |
19:17 | |
|
20:02
sena_kun joined
20:03
Altai-man_ left
|
|||
| jnthn | timotimo: That's incomplete; the MVMRegister * or args also must be marked per the flags in the callsite | 20:18 | |
| *of args | 20:19 | ||
| nwc10: ooh, interesting... | |||
| nwc10 | I had been just about to go to bed. But if you think you want any more info, I can delay for a bit | ||
| timotimo | ah, so i do have to iterate through the flags, then | 20:21 | |
|
20:31
zakharyas left
|
|||
| timotimo | can i just keep one index for the callsite entries and one for the register "addresses" and when i see one with MVM_CALLSITE_ARG_NAMED (perhaps also NAMED_AND_FLATTENED) i skip the entry but not the register? | 20:33 | |
| jnthn | nwc10: No, was doing homework. Will probably look on Wednesday | 21:07 | |
| timotimo: No, the data in a flattened record is *already* flattened | |||
| timotimo: You don't have to care about nameds even, just just check if it's an object or string arg in the callsite | 21:08 | ||
| (Because the whole "named is two args" thing is totally gone in the new calling conventions | |||
| Now the names live only in the callsite object | |||
| (The point of a flattening record is that we can allocate the space for the result of the flattening right there on the callstack) | 21:09 | ||
| lizmat | and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2020/06/29/2020-...loud-gone/ | 21:21 | |
| timotimo | whee | 21:43 | |
| [Coke] | lizmat++ | 21:45 | |
|
22:01
Altai-man_ joined
22:04
sena_kun left
22:43
Kaiepi left
22:44
Kaiepi joined
23:06
AlexDaniel left,
AlexDani` joined
23:20
vrurg left
|
|||