| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:36 sena_kun left
AlexDaniel MasterDuke: yeah, if we don't have any custom changes 01:39
however, I'm not sure what is going to happen with existing checkouts 01:40
that is, if you have the submodule locally, will it be able to switch to a different branch instead of trying to fast-forward? 01:41
01:46 Kaiepi left 01:48 Kaiepi joined 06:03 sena_kun joined 06:39 sena_kun left 07:37 domidumont joined
nine Got it! It's deserialization, which can actually cause a NativeCall site to lose its lib_name and then lib_handle 07:41
09:16 zakharyas joined 09:42 discord6 left, timotimo left 09:56 timotimo joined 10:04 domidumont left 10:06 domidumont joined
nine Damn it, even with a fix the problem is still there. 11:40
It's again repossession which NULLs the existing object before deserializing it
11:47 Guest38485 joined
Guest38485 nine: But didn't it only happen on 32 bit or was 64 bit affected as well 11:50
nine Its easily reproducible on 64 bit, too with MVM_SPESH_NODELAY and MVM_SPESH_BLOCKING 11:52
Guest38485 and the fix is a nightmare ? 11:53
nine Indeed it is. My current approach seems doomed to fail. But I came up with a different one. One that will give us all the benefits with no drawbacks. It's just...architecturally terrible 11:55
nwc10 does it involve thread local storage and insecure temporary files? 11:56
nine No, not that terrible.
nwc10 :-) 11:57
nine It's just that the NativeCall repr gains an attribute in which we can store an object that NativeCall can ask for the current location of the library on deserialization.
So we go all the way back up from MoarVM to Distribution::Resource to get the proper path. This way we don't need to store absolute (thus outdated) paths in precomp files. 11:58
I'm not sure we have any place in MoarVM that expects a certain method to exist on a user supplied object 12:00
Maybe a closure would be better. There's at least precedence for calling those 12:01
12:09 lucasb joined, sena_kun joined 12:16 zakharyas left 12:17 zakharyas joined 12:46 zakharyas left 13:02 sena_kun left 13:16 sena_kun joined 13:52 zakharyas joined 14:14 MasterDuke left 14:17 MasterDuke joined
vrurg MasterDuke: did you resolve it with submodule? 14:34
MasterDuke not really. did you see the chat with samcv and AlexDaniel from last night?
vrurg MasterDuke: partially. 14:40
MasterDuke: as far as I understand, the submodule is from a forked repo with local patches. Right? 14:41
MasterDuke yep. but we don't need the patches anymore if we upgrade to the latest upstream release 14:42
and i/we don't know to make the switch to just using the upstream release without messing things up 14:43
vrurg Perhaps it is better to keep in mind that we still might need some more patches in the future?
MasterDuke sure, we can use our fork. but how do we get it back to just tracking upstream without adding anything? 14:44
vrurg Best is what nine reommended: add upstream remote and merge. Except that I'd merge with --rebase and if they use tags then with --tags. Any conflicts to be resolved 'using theirs' 14:46
This would require manual update of the submodule sometimes to pull from upstream, but otherwise seems to be the best way.
MasterDuke what would the impact be for people who currently have moarvm cloned? if they did a simple `git pull` would it work cleanly for them? 14:47
vrurg BTW, when I develop in my fork of rakudo, I use 'git pull --rebase --tags upstream master` – this skips 'get fetch' step. 14:48
People would need to do `git submodule update --recursive` 14:49
That's why I set submodule.recurse in git config on the first run of in NQP and Rakudo. Then git pull just updates modules. 14:50
Ah, and surely, you'd have to do `git add 3rdparty/libtomath && git commit && git push` in MoarVM. 14:51
Geth MoarVM: MasterDuke17++ created pull request #1220:
Upgrade libtommath to v1.2.0
15:02 sena_kun left
MasterDuke would appreciate if someone could test that out for me ^^^ 15:02
huh, well appveyor doesn't like checking out that commit 15:08
oh. we were on develop. maybe that makes things easier, because we can just switch to master/the tag 15:09
uh. i just pushed a fetched upstream master to our fork's master 15:14
(so damn complicated) 15:15
vrurg MasterDuke: you'll get used to it. For the first time it confuses a lot, that's true. 15:16
15:17 sena_kun joined
Geth MoarVM: MasterDuke17++ created pull request #1221:
Switch our libtommath to upstream's 1.2.0 tag
vrurg To me the purpose of submodules is to have independent pieces of code nailed down at certain commits. This guarantees that the main code compiles/runs as expected and doesn't depend on unexpected changed.
AlexDaniel yeah 15:20
MasterDuke oh, looks like i didn't try building after our build options changed. ugh 15:21
16:42 zakharyas left 16:48 domidumont left 16:49 robertle joined 17:02 sena_kun left 17:17 sena_kun joined 17:23 domidumont joined
AlexDaniel squashable6: status 17:41
squashable6 AlexDaniel, ⚠🍕 Next SQUASHathon in 2 days and ≈10 hours (2019-12-07 UTC-12⌁UTC+20). See
17:52 brrt joined
brrt \o 17:54
18:16 tellable6 left 18:18 tellable6 joined
nwc10 o/ 18:18
brrt ohai nwc10 18:20
brrt is waiting for a slooooow compile 18:22
MasterDuke ugh again, we almost never check the return value of the libtommath functions. so many warnings, so much code to add
brrt: upgrade to a ryzen (if you haven't already), they compile so quickly 18:23
brrt I have a ryzen, but it's a mobile one 18:25
and this isn't moarvm
or rakudo
dogbert17 I just got a SEGV when running t/spec/S17-supply/syntax.t in a loop with MVM_JIT_DISABLE=1 18:27
it SEGV's here: 18:28
nwc10 brrt: that's silly. Clearly you should fix that failing of SEP - Someone Else's Program 18:30
brrt nwc10: I'm staying as far as possible away from this one (it's gradle) 18:46
18:50 Kaiepi left, Kaiepi joined 18:51 Kaiepi left 19:03 sena_kun left 19:18 sena_kun joined 19:26 brrt left 19:46 MasterDuke left 19:55 squashable6 left 19:57 squashable6 joined 20:02 squashable6 left, MasterDuke joined 20:04 squashable6 joined 20:14 brrt joined 20:28 lucasb left 20:49 vesper11 left 20:51 vesper11 joined 21:02 sena_kun left 21:17 sena_kun joined, brrt left 21:19 brrt joined 21:29 domidumont left 21:50 brrt left 21:57 Kaiepi joined 22:42 lucasb joined 23:02 sena_kun left 23:03 sena_kun joined, sena_kun left