Mixing arm64/Intel

[lrasmus]

StatTag should gracefully handle (meaning, not crash) if a user is running a build that is not compatible with their architecture of R. e.g., if someone has downloaded arm64 R, and is running Intel StatTag, we know that R can't run. When the user tries to run anything in R, they should get an informative error message.

[lrasmus]

Currently we crash - not surprising since we're not doing anything to detect/handle this:

0   StatTag.RCocoa                	0x000000010ac0ae8a -[RCEngine disableRSignalHandlers:] + 26 (RCEngine.m:380)
1   StatTag.RCocoa                	0x000000010ac0a189 __24+[RCEngine GetInstance:]_block_invoke + 89 (RCEngine.m:110)
2   libdispatch.dylib             	0x00007fff201c8806 _dispatch_client_callout + 8
3   libdispatch.dylib             	0x00007fff201c998c _dispatch_once_callout + 20
4   StatTag.RCocoa                	0x000000010ac0a109 _dispatch_once + 27 (once.h:84) [inlined]
5   StatTag.RCocoa                	0x000000010ac0a109 +[RCEngine GetInstance:] + 121 (RCEngine.m:107)
6   edu.northwestern.nucats.StatTagFramework	0x000000010a8b6639 -[STRAutomation Initialize:withLogManager:] + 153 (STRAutomation.m:46)
7   edu.northwestern.nucats.StatTagFramework	0x000000010a87c4a9 -[STStatsManager ExecuteStatPackage:filterMode:tagsToRun:] + 473 (STStatsManager.m:117)
8   edu.northwestern.nucats.StatTag	0x0000000100af3cf0 __54-[UpdateOutputProgressViewController refreshTagsAsync]_block_invoke + 1712 (UpdateOutputProgressViewController.m:126)
9   libdispatch.dylib             	0x00007fff201c7623 _dispatch_call_block_and_release + 12
10  libdispatch.dylib             	0x00007fff201c8806 _dispatch_client_callout + 8
11  libdispatch.dylib             	0x00007fff201cae37 _dispatch_queue_override_invoke + 775
12  libdispatch.dylib             	0x00007fff201d7818 _dispatch_root_queue_drain + 326
13  libdispatch.dylib             	0x00007fff201d7f70 _dispatch_worker_thread2 + 92
14  libsystem_pthread.dylib       	0x00007fff2036f417 _pthread_wqthread + 244
15  libsystem_pthread.dylib       	0x00007fff2036e42f start_wqthread + 15```

[ewhitley]

I can't find the larger issue I created in github to track this, but I got some feedback from Apple on this and they agreed we need to look at a different way to invoke the R process at runtime. We can no longer just link like we have been. We can, but it's going to create a lot of issues for users if we do. They'll have to delete and reinstall stattag to match the R architecture, which is something I don't think they should have to do.

https://developer.apple.com/forums/thread/682381?login=true&page=1#680127022

[ewhitley]

https://developer.apple.com/documentation/apple-silicon/porting-your-macos-apps-to-apple-silicon

"Plug-ins that run out-of-process using an XPC service may run using a different architecture than the app itself. To give your developers time to update their plug-ins, provide two non-universal XPC services—one to run arm64 plug-ins and one to run x86_64 plug-ins. A single XPC service can manage either native or translated plug-ins, but not both at the same time. When creating the services, give each one a unique bundle identifier so they may run simultaneously."

[ewhitley]

More fun reading

https://www.wwdcnotes.com/notes/wwdc20/10214/