github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:45 MasterDuke left 01:45 leont left 08:59 sena_kun joined
nine So...maybe patch gmp after all and try to upstream that patch? That would probably the best solution in the long term 08:59
09:19 MasterDuke joined
MasterDuke nine: not actually going to be around for a while to chat about it, but what sort of patch do you have in mind? 09:19
nine One where instead of calling a hard coded abort() it would call a user supplied function instead. This could then throw an appropriate exception 09:21
timotimo plus have something for cleanup 09:27
nine I guess we can recover tc from the TLS, so it wouldn't even needs some way to keep custom data for us 09:28
timotimo so when we patch, don't we want to go right for the other library that was forked off of gmp? 09:35
nine Oh, yes, there is already one. I forgot about that 09:36
timotimo i pointed this mess out to a friend; he said grepping for "abort" in that other library was not pretty 09:37
09:41 Altai-man joined
nine I now have some understanding of why nqp::scdisclaim after a precompilation leads to JustPrecompiledModule::return-defined-int-hash() ~~ Hash[Int:D] giving False. 09:41
Ordinarily a type gets parameterized during compilation and serialized at the end. When using it at runtime, we deserialize it again. This serialization/deserialization cycle will generate a copy of the object.
When parameterizing the same type for the main program, the VM finds it in the parameterization cache and returns the same object as previously. When serializing this we discover that it has already been serialized (it got an sc and sc_idx) and instead of doing so again just return the same copy we previously got.
With the nqp::scdisclaim however, we clear the sc and sc_idx so we actually go through serialization/deserialization and thus get an independent copy. Since we compare types by comparing pointers to type objects, they no longer match.
lizmat so it should not look at the parameterization cache ? 09:43
nine That would just make it an entirely new type that wouldn't match either 09:44
09:44 sena_kun left
timotimo nqp::sclink, replaces an object from one serialization context with one from another, and sets up a dependency 09:48
not a terrible idea and fragile approach at all
nine We wouldn't want a dependency in this case
timotimo hm, so we have a "resolve repossessions" step already, does repossession somehow seem like a good hook point to do a cache unification kind of thing? 09:49
nine IIRC repossession still implies dependency 09:51
timotimo hm, right 09:53
nine LOL 10:02
timotimo here comes a/the thought that blows this case wide open
nine I've wondered how this works on master when two independent modules create the same parameterization and why they would match if we need them to result in the same object. Turns out: it doesn't at all 10:03
timotimo totally not 10:04
nine And I wouldn't be surprised if this was what "#?rakudo todo 'no 6model parametrics interning yet'" would test 10:05
I think "interning" would be the fancy word for reconciling those different type objects
timotimo recoils 10:08
nine Now I wonder how this fits into this picture: github.com/MoarVM/MoarVM/blob/mast...on.c#L3127 10:20
timotimo good question. does stuff in there ever run? 10:22
nine Yes: matching 0x7ff2136d3a40 Associative[Int:D] 0 -1, matching 0x7ff2136abae8 Hash::TypedHash[Int:D] 0 -1 10:23
timotimo perhaps we're setting the indices but never reading them?!
nine I may have an answer. The thing is that Hash[Int:D] is not actually a parameterized type as such. It's really Hash+{Hash::TypedHash[Int:D]}, i.e. a mixin 10:26
timotimo uh oh 10:27
does that mean when you grab the .^roles of that type, you'll get a Hash::TypedHash[Int:D] that doesn't match what you get from the literal Hash::TypedHash[Int:D] because that got patched? or something? 10:28
nine m: say Hash[Int] ~~ Associative[Int] 10:31
camelia True
nine m: say Hash[Int:D] ~~ Associative[Int:D]
camelia True
nine m: say Hash[Int:D].^roles[0] ~~ Associative[Int:D]
camelia True
nine Intriguing...the latter 2 were False on rakudo 2019.11 10:32
Cant' test Hash::TypedHash as that's a my scoped role 10:38
lizmat so, do we have a way in Actions to determine whether we'e compiling something for 6.c / 6.d / 6.e.PREVIEW 10:51
?
nine $*W.setting_revision sounds like the closest 10:56
Or $*W.lang-ver-before($want) or nqp::getcomp('Raku').language_version 10:57
lizmat $*W.setting_revision gives an ampty string 11:07
.language_version gives what I was looking for
nine Mixins actually also go through type parameterization. So the real question is: why don't they appear in the param type interns? 11:42
lizmat actually used $*W.lang-ver-before($want) 11:44
now in a PR: 11:45
$ r 'use v6.e.PREVIEW; my %h; %h{ || <a b c> } = 42; dd %h'
Hash %h = {:a(${:b(${:c(42)})})}
timotimo nice 11:48
nine Of course.... interability is 1 while num_params + 1 is 2...
Otherwise, there is no way the parameterized type in question could have been produced by another compilation unit. We keep a counter of things, which should add up to parameters + 1 if we need the intern entry. */ 11:50
Comment starts with :/* To deserve an entry in the intern table, we need that both the type being parameterized and all of the arguments are from an SC other than the one we're currently serializing.
Now I wonder if that's an optimization or rather something that's essential for this house of cards to stand...
12:02 leont joined
MasterDuke we are using a fork of gmp, but i believe it only adds visual studio compilation support and pulls upstream pretty frequently 12:29
nine multi level parameterization! 12:31
Hash[Int:D] is actually Hash+{Hash::TypedHash[Int:D]} which is really 3 parameterizations. Now when we read the parameterization intern table, we try to find an existing parameterization for each one. But if we try Hash[Int:D] before Hash::TypedHash[Int:D] the latter won't be available yet, so we won't find an existing parameterization, won't we? 12:33
timotimo that could be it, yeah 12:47
so we may have to go through again and again until we hit a fix point
nine That's exactly what I'm currently trying :) And indeed it leads to more hits. But also to an Invalid dependencies table index encountered (index 768) which I'm trying to debug now 12:48
Bingo! 12:54
*hyperventilates* this fixed the issue 12:55
13:01 vrurg joined 13:02 vrurg_ left
MasterDuke nice 13:06
13:16 vrurg_ joined 13:18 vrurg left 13:42 sena_kun joined 13:44 Altai-man left 15:21 domidumont joined 15:27 domidumont left
[Coke] nine++ 16:38
17:41 Altai-man joined 17:44 sena_kun left
timotimo what, the whole issue?! 17:50
nine Well the TODOed "precompile load of both and identity check passed" in S10/precompilation.t now passes, as does my golfed version of the in-process-precomp issues I was tracking 17:55
timotimo fantastic 17:56
nine With the internability == num_params + 1 check disabled at least
timotimo greppable6: has ::
greppable6 timotimo, 1 line, 1 module: gist.github.com/0121ea6f1d45b06782...bbdbb5f0b8
timotimo hmm 17:57
nine Still a bit of an issue, but I'm getting there 17:58
18:03 zakharyas joined 18:16 domidumont joined 18:19 domidumont left 18:40 vrurg_ is now known as vrurg
nine There actually was yet another bug in resolve_param_interns that was just not triggered because it found so few parameterizations... 19:00
20:13 zakharyas left
nine Yeah, if we need to deserialize an object when processing the interns, we change the serialization reader's state. Need to restore that to continue where we left off. 20:20
20:51 Kaiepi left
timotimo good catch 21:02
21:14 Altai-man left
lizmat nine++ 21:32
22:52 Kaiepi joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!