|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
03:27
AlexDani` joined
03:31
AlexDaniel left
03:48
AlexDani` is now known as AlexDaniel,
AlexDaniel left,
AlexDaniel joined
07:03
domidumont joined
07:31
robertle_ joined
07:37
AlexDaniel left
08:10
sena_kun joined
08:27
Kaiepi left
08:40
chloekek joined
08:41
zakharyas joined
08:53
chloekek left
09:09
zakharyas left
09:11
chloekek joined
10:24
Kaiepi joined
11:08
AlexDaniel` left
11:16
AlexDaniel` joined
11:19
chloekek left
11:32
domidumont left
11:34
domidumont joined
11:48
brrt joined
|
|||
| brrt | \o | 11:48 | |
| nwc10 | o/ | 11:53 | |
| jnthn | o/ | 11:56 | |
| tellable6 | 2019-08-31T23:39:38Z #perl6-dev <vrurg> jnthn I was thinking about 'NULL.<rev>' used to distinguish currently compilng language revision. Perhaps we just need a command line switch(es) --lang-ver / --lang-rev? | ||
| brrt | no good deed goes unpunished | 12:01 | |
| Q: I can get rid of the bit that says 'does this template yield a value or does it only have a side effect' because I know on one hand, what the 'root' operator is, and on the other, I know of all operators whether they yield a value or not. Should I get rid of that bit? | 12:24 | ||
| the context of the question is: I want a sort-of open interface for the REPR specialization / devirtualization, and in the suggested interface, that bit doesn't really fit | 12:25 | ||
| so I was thinking of doing a negative-number-is-no-value scheme, but I think that's messy | |||
| interestingly, in the linear IR scheme, because all operators get a fixed size, we no longer strictly *need* to return the 'template root', because we can just say that's always the last operator by convention. | 12:26 | ||
| timotimo | i'm beginning to think that "forget snapshot" works so unreliably could be our heuristic for "when should we do a full collection" | 12:52 | |
| because in later snapshots it does look like a lot of the big objects are only reachable via gen2 roots? | 12:53 | ||
| wait, don't inter-generational roots point from gen2 to nursery? | |||
| jnthn | Well, they exist when a gen2 object comes to point to a nursery object | 12:56 | |
|
12:58
lucasb joined
|
|||
| timotimo | i put in some code to make gen2 root links only show up if there's no other way to reach something at all | 12:58 | |
| so those would be objects that are being kept alive inside the nursery even if the gen2 object that at some point pointed at them has already become garbage? | |||
| oh, the number of gen2 roots would probably be interesting for the GCEvent? | 13:06 | ||
| oh damn | 13:11 | ||
| is the profiler only recording the number of gen2 roots of one TC? | |||
| ah, no, wrong | 13:12 | ||
| it's actually recorded for every tc | |||
| (every tc that is involved in GC) | |||
| so, hm, it should also go through the non-involved TCs perhaps | |||
|
13:17
brrt left
|
|||
| timotimo | i *think* i can "just" revert github.com/MoarVM/MoarVM/commit/7d...6f8222da26 completely on top of master | 13:38 | |
| Geth | MoarVM/master: 6 commits pushed by (Timo Paulssen)++
|
14:01 | |
|
14:03
robertle_ left
|
|||
| timotimo | rejoice | 14:03 | |
|
14:05
robertle_ joined
|
|||
| timotimo | jnthn: i assume we'll also want to make VMEvents available through the debugserver, eh? | 14:16 | |
| jnthn | Hm, could be interesting | 14:21 | |
| timotimo puts it on the long list | |||
| this could also be the same mechanism that passes spesh log results to the debug client | 14:22 | ||
| Geth | MoarVM: aa934648ed | (Timo Paulssen)++ | src/gc/orchestrate.c Fix call of profiler_log_gen2_roots |
14:31 | |
| MoarVM: fdc5eacf57 | (Timo Paulssen)++ | src/gc/orchestrate.c VMEvent: put gc_promoted_bytes_since_last_full in GCEvent |
|||
|
14:32
Kaiepi left
14:35
chloekek joined
14:36
Kaiepi joined
14:46
Kaiepi left
14:47
Kaiepi joined
|
|||
| timotimo | i'm all out of zoom juice :( | 14:48 | |
|
14:49
brrt joined
15:02
chloekek left
|
|||
| Geth | MoarVM: 1b67a94cc9 | (Timo Paulssen)++ | src/gc/orchestrate.c oops don't overwrite fields; add a new one instead |
15:07 | |
| Kaiepi | can someone review github.com/MoarVM/MoarVM/pull/1166 ? | 15:08 | |
| timotimo | is the dyncall submodule update important to the pull request? | 15:10 | |
| i need a monkeypatch to Concurrent::Progress so i can find out why there's unmatched target increments and value increments m) | 15:21 | ||
|
15:22
brrt left
15:28
robertle_ left
|
|||
| Kaiepi | oh wtf how did dyncall get changed | 15:28 | |
| timotimo | :) | 15:31 | |
| possibly when "git checkout"int across branches | |||
| Kaiepi | ok it doesn't update dyncall anymore | 15:34 | |
|
15:49
domidumont left
16:35
domidumont joined
|
|||
| nine | r/win 10 | 16:54 | |
|
16:55
domidumont left
|
|||
| tadzik | that subreddit is private :( | 16:58 | |
|
17:23
AlexDaniel joined,
AlexDaniel left,
AlexDaniel joined
17:26
brrt joined
17:38
brrt left
18:15
chloekek joined
19:11
MasterDuke joined
19:22
brrt joined
19:46
moritz joined
20:06
sena_kun left
20:13
Guest71418 joined
20:21
Guest71418 left
21:31
krunen left,
krunen joined
|
|||
| brrt | .seen pamplemousse | 21:48 | |
| tellable6 | brrt, I saw pamplemousse 2019-08-26T20:51:12Z in #moarvm: <pamplemousse_> lizmat++ | ||
| brrt | hmmm | 21:49 | |
|
21:53
brrt left
22:43
MasterDuke left
23:25
chloekek left
23:57
lucasb left
|
|||