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
|