github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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
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
timotimo rejoice 14:03
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
timotimo i'm all out of zoom juice :( 14:48
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
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
nine r/win 10 16:54
tadzik that subreddit is private :( 16:58
brrt .seen pamplemousse 21:48
tellable6 brrt, I saw pamplemousse 2019-08-26T20:51:12Z in #moarvm: <pamplemousse_> lizmat++
brrt hmmm 21:49

Powered by Cro and the Raku® Programming Language.

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

Thank you!