github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:20 leont left 00:21 raku-bridge left, raku-bridge joined 00:41 vrurg left 00:42 vrurg joined 02:36 lucasb left 04:15 notable6 left, nativecallable6 left, unicodable6 left, statisfiable6 left, benchable6 left, evalable6 left, releasable6 left, committable6 left, quotable6 left, bloatable6 left, linkable6 left, bisectable6 left, greppable6 left, shareable6 left, coverable6 left, tellable6 left, squashable6 left, sourceable6 left, bloatable6 joined, bisectable6 joined 04:16 nativecallable6 joined, tellable6 joined, statisfiable6 joined, quotable6 joined 04:17 unicodable6 joined, committable6 joined, coverable6 joined, evalable6 joined, linkable6 joined 04:18 notable6 joined, shareable6 joined, sourceable6 joined, squashable6 joined, benchable6 joined, greppable6 joined, releasable6 joined 05:28 squashable6 left, bisectable6 left, linkable6 left, statisfiable6 left, unicodable6 left, committable6 left, coverable6 left, evalable6 left, greppable6 left, bloatable6 left, nativecallable6 left, notable6 left, tellable6 left, benchable6 left, shareable6 left, releasable6 left, sourceable6 left, quotable6 left 05:29 bloatable6 joined, evalable6 joined, nativecallable6 joined, tellable6 joined, linkable6 joined, squashable6 joined, sourceable6 joined, coverable6 joined 05:30 shareable6 joined, unicodable6 joined, releasable6 joined, committable6 joined 05:31 benchable6 joined, quotable6 joined, statisfiable6 joined, greppable6 joined, notable6 joined, bisectable6 joined 08:06 domidumont joined
nwc10 good *, #moarvm 08:35
08:53 sena_kun joined 08:58 zakharyas joined 09:18 leont joined 10:25 raku-bridge left 10:26 raku-bridge joined, raku-bridge left, raku-bridge joined 11:39 jnthn joined
nwc10 good *, jnthn 11:45
(and just as I'm going AFK for lunch)
jnthn Hm, no sign of the commit bot 11:53
tellable6 2020-10-04T06:44:33Z #raku <Xliff> jnthn: ^^ Errors when attempting to run RakuAST code from branch
jnthn github.com/MoarVM/MoarVM/pull/1380 anyway
11:54 Geth joined 12:09 Altai-man joined 12:12 sena_kun left 12:31 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 12:36 zakharyas left
[Coke] waves. 13:00
13:28 ggoebel joined
ggoebel jnthn++ 13:28
13:28 ggoebel left 13:46 brrt joined
nwc10 good *, brrt 14:17
not #brrt (which I tried, and got very confused as to why tab completion didn't help me) 14:18
brrt good * nwc10 14:25
tellable6 2020-11-11T08:53:45Z #moarvm <nwc10> brrt Well, you have a bit more choice now: geizhals.eu/?cmp=2414598&cmp=2422055 (of course this doesn't work very well because the two products are in different categories)
brrt so attributes are sorted by category in geizhals, good to know :-P 14:37
15:00 lucasb joined
nine Looks like using an allow list managed by HLL code to filter dependencies of a comp unit is harder than expected. Assembling a useful allow list was actually easier and it's useful for catching unwanted references to unrelated SCs. It gets hard when I want to deal with those. 15:15
I figured when encountering one, I'll just add the object (or STable) to the current SC and serialize it as if it originated in the current compilation. That'd properly take care of things we get from the Int or parametrics caches. Copying them would be totally fine. 15:16
But objects reference a ton of things. Among them their STables which will contain e.g. method caches. And copying those doesn't work because code objects aren't mere objects but reference frames which are managed totally differently. 15:17
15:17 zakharyas joined
brrt hmm 15:17
nine The point where it currently breaks is actually not even Int or parametrics cache related. The allow list cought a reference from NativeCall::Compiler::MSVC to NativeCall::Compiler::GNU (which is compiled earlier in the same process) by way of the NativeCall::Compiler stash. This slipped through because nothing tried to load NativeCall::Compiler::MSVC on its own. 15:19
jnthn In theory, method caches are going away with the new-disp work, but I guess they're just one example 15:22
nine jnthn: almost the more important message to me is that you _didn't_ cry out about what craziness the idea of an allow list and copying stuff was ;) 15:38
Or maybe you did so in real life and will take me aside at the earliest opportunity and tell me privately that I ought to consider a different career like mowing lawns or so 15:40
jnthn nine: I've not been following enough to have the context, alas.
The problem here comes down to our separate compilation not being so separate when we do it in process, though? 15:41
nine Yes. This just exposes all the places where we do have global state like the Int and parametrics caches in the VM and also the Stash hierarchy in the Raku layer. I have already defused much of the latter by not actually serializing most of them and instead generating code to assemble them in the dependencies+deserialize frame. 15:44
jnthn Well, the int and parametrics one differ somewhat, in so far as the int one is an optimization, but the parametrics one is for correctness 15:48
nine In this case it's the stub package that's throwing in the wrench. We start compiling NativeCall which creates the NativeCall packages. Then we do the nested precompilation for NativeCall::Compiler::GNU which creates the NativeCall::Compiler stub to put GNU into. This stub has to be serialized and it will. Later we get the same stub when compiling NativeCall::Compiler::MSVC 15:49
jnthn Ah, yes
And later both get discarded
nine I think the allow list approach is a good solution for Int and parametrics caches. Ints are simple and builting anyway and the parametrics caches contain only type objects and STables - which won't have their own methods. So copying them should be OK. 15:50
jnthn What's being copied, the cache or the things in it? 15:51
nine The things we get from the cache
jnthn Hmm 15:52
Not quite sure I follow then, in that the goal of the "cache" is actually to intern them
nine I copy those things during serialization, so the copies will not be used at runtime and only written to the mbc. On loading we intern them anyway 15:53
It's really just a "pretend we created those parametrics during the current compilation" during serialization 15:54
jnthn ah, I see
nine Oh, I may have an idea for the stub package. I already implemented a cleanup after precompilation. Symbols added via Perl6::World::install_package_symbol_unchecked get removed again after compilation (to be added again when we actually load the module). But I don't do so yet for stub packages. 15:55
Oh, I do. They also go in via install_package_symbol_unchecked 15:56
Ok, I think I'll just have to debug this to find out how that package actually leaks in 15:57
jnthn wonders if this could be at all helped by, instead of .WHO being directly hung off STable, instead being a lookup keyed on it, and thus we can create a fresh view of it for nested compilations 16:01
16:10 sena_kun joined 16:12 Altai-man left
nine Less tight coupling could open up possibilities, yes 16:22
17:19 brrt left 18:15 domidumont left 18:33 brrt joined 19:24 MasterDuke joined 20:10 Altai-man joined 20:12 sena_kun left 20:48 Kaeipi joined, Kaiepi left 21:37 brrt left 22:10 Altai-man left, sena_kun joined 22:35 raku-bridge left, raku-bridge joined, raku-bridge left, raku-bridge joined 22:45 zakharyas left 22:48 zakharyas joined 23:09 zakharyas left 23:26 sena_kun left 23:39 vrurg_ joined 23:44 vrurg_ left