github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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 Configure.pl 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 | |
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 |
15:18 | |
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 github.com/rakudo/rakudo/wiki/Mont...Squash-Day | ||
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: github.com/MoarVM/MoarVM/blob/mast...lker.c#L45 | 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
|