Post

Replies

Boosts

Views

Activity

Reply to XPC so universal app can interact with ARM or Intel dylib?
Hi, Quinn - First, thanks for the response. If R has both Apple silicon and Intel builds, the most obvious path forward is to link the Apple silicon ‘slice’ of your app to R’s Apple silicon build and the Intel slice of your app to R’s Intel build. I wasn't aware you could compile one universal app and link to two different libraries with different architectures like that. Is there any documentation on how to approach that? The only discussion I've found has been that WWDC session from last year. Right now when we build now we point to the /Library/Frameworks/R.Framework/Current symlink which resolves to whichever single version of R is listed as "Current" (EX: /3.1). When the user runs the app we then pull in "Current" and reference whichever version of R the user has installed - could be Intel and, as of last week, could be ARM. We don't know. We simply hit "Current" and pull in whichever version of R the user has designated as appropriate. If I understand this we'd have something like... R 3.1 (Intel) R 4.1 (ARM) both living in /Library/Frameworks/R.Framework. I'm struggling to grasp how we build against R as you describe. Right now we have a single reference to a single library in the build dependencies. BTW - not doubting you at all - I simply haven't heard of this approach before. I'd love to have more information on this. We're doing this for an open source app sponsored through an NIH research grant. There's an audience out there in our space who would benefit from having a way to interact with R like this from a Mac app and it's something we could at least share with other collaborators and colleagues. Thank you, Eric
Topic: App & System Services SubTopic: Core OS Tags:
Jun ’21
Reply to XPC so universal app can interact with ARM or Intel dylib?
@eskimo - You rule. Honestly, we're struggling with wrapping our heads around how to think about this, so I really sincerely appreciate you taking the time to respond to us and doubly appreciate you being willing to investigate. The R framework(s) are available via https://mac.r-project.org/ . There are separate Intel and ARM versions Intel 4.1 - https://mac.r-project.org/high-sierra/R-4.1-branch/R-4.1-branch.pkg ARM 4.1 - https://mac.r-project.org/big-sur/R-4.1-branch/R-4.1-branch.pkg Our audience (medical/biomedical informatics researchers, primarily) tend do want to use their own versions of R with their own packages, etc. installed, so as a result we do not distribute R directly with our app (https://sites.northwestern.edu/stattag/). Instead, we link on build to "Current" and our app links to the R distribution on the user's machine at runtime. Our focus is on reproducible research, so the rationale here is that we want to allow users to govern the specific application (R, Stata, etc.) versions for their project. There are some other challenges with that, but our big question right now is how to approach ARM vs. Intel. I think that means we have three scenarios: Universal app runs on Intel machine with Intel R Universal app runs on ARM machine with Intel R (I had previously tested this on the DTK before there was an ARM R and it worked fine) Universal app runs on ARM machine with ARM R Now that there's the possibility a user could have an ARM machine with either an Intel or an ARM build of R set as "Current," I'm not even sure how to think about this problem. We're in the process of getting an ARM Mac Mini (we two developers both have Intel machines right now) and we hope to be able to do more extensive testing soon. Any insights / ideas / critiques are very, very welcome. Again, thank you Eric (and Luke, Leah, and Abi)
Topic: App & System Services SubTopic: Core OS Tags:
Jun ’21
Reply to XPC so universal app can interact with ARM or Intel dylib?
@eskimo - I've opened up access to a demo app on GitHub that takes our R wrapper (RCocoa) and drops it into simple app that lets you enter basic R code to return a single R value. It defaults the R code for convenience https://github.com/StatTag/RCocoaExampleLinkAtRuntime (dummy app - exposes some of the R bits we use in our app) https://github.com/StatTag/RCocoa (R wrapper framework) RCocoa is the R wrapper framework that references R. The dummy app links to the RCocoa project. RCocoa was written by my collaborator Luke and presented at useR! in 2019 (https://www.r-project.org/conferences/useR-2019/posters). Exposing R for incorporation into statistical applications has been super super helpful to our users. Thank you, Eric
Topic: App & System Services SubTopic: Core OS Tags:
Jun ’21
Reply to XPC so universal app can interact with ARM or Intel dylib?
Hi, @eskimo - Thank you again for the fantastic response here. My apologies for just now responding (out last week). Luke, Leah I’m sure that generates some office teasing (-: LOL. I got that reference. (insert Steve Rogers meme) I'm also shocked none of us ever realized that... I can't thank you enough for you detailed and extraordinarily considerate response. This is some amazing guidance I'll bring to our team meeting this morning. If you’d like to dig into this in more detail, I’m going to recommend that you open a DTS tech support incident so that I can allocate more time to it. It might even involve gasp a phone call (-: Oh, I'm in! I'll submit it after our team meeting this morning. I'd love to see us do this in a way that benefits our users and also helps others understand how to approach similar needs. Thank you again, Eric (and Team Skywalker)
Topic: App & System Services SubTopic: Core OS Tags:
Jun ’21
Reply to XPC so universal app can interact with ARM or Intel dylib?
Hi, Quinn - First, thanks for the response. If R has both Apple silicon and Intel builds, the most obvious path forward is to link the Apple silicon ‘slice’ of your app to R’s Apple silicon build and the Intel slice of your app to R’s Intel build. I wasn't aware you could compile one universal app and link to two different libraries with different architectures like that. Is there any documentation on how to approach that? The only discussion I've found has been that WWDC session from last year. Right now when we build now we point to the /Library/Frameworks/R.Framework/Current symlink which resolves to whichever single version of R is listed as "Current" (EX: /3.1). When the user runs the app we then pull in "Current" and reference whichever version of R the user has installed - could be Intel and, as of last week, could be ARM. We don't know. We simply hit "Current" and pull in whichever version of R the user has designated as appropriate. If I understand this we'd have something like... R 3.1 (Intel) R 4.1 (ARM) both living in /Library/Frameworks/R.Framework. I'm struggling to grasp how we build against R as you describe. Right now we have a single reference to a single library in the build dependencies. BTW - not doubting you at all - I simply haven't heard of this approach before. I'd love to have more information on this. We're doing this for an open source app sponsored through an NIH research grant. There's an audience out there in our space who would benefit from having a way to interact with R like this from a Mac app and it's something we could at least share with other collaborators and colleagues. Thank you, Eric
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Jun ’21
Reply to XPC so universal app can interact with ARM or Intel dylib?
@eskimo - You rule. Honestly, we're struggling with wrapping our heads around how to think about this, so I really sincerely appreciate you taking the time to respond to us and doubly appreciate you being willing to investigate. The R framework(s) are available via https://mac.r-project.org/ . There are separate Intel and ARM versions Intel 4.1 - https://mac.r-project.org/high-sierra/R-4.1-branch/R-4.1-branch.pkg ARM 4.1 - https://mac.r-project.org/big-sur/R-4.1-branch/R-4.1-branch.pkg Our audience (medical/biomedical informatics researchers, primarily) tend do want to use their own versions of R with their own packages, etc. installed, so as a result we do not distribute R directly with our app (https://sites.northwestern.edu/stattag/). Instead, we link on build to "Current" and our app links to the R distribution on the user's machine at runtime. Our focus is on reproducible research, so the rationale here is that we want to allow users to govern the specific application (R, Stata, etc.) versions for their project. There are some other challenges with that, but our big question right now is how to approach ARM vs. Intel. I think that means we have three scenarios: Universal app runs on Intel machine with Intel R Universal app runs on ARM machine with Intel R (I had previously tested this on the DTK before there was an ARM R and it worked fine) Universal app runs on ARM machine with ARM R Now that there's the possibility a user could have an ARM machine with either an Intel or an ARM build of R set as "Current," I'm not even sure how to think about this problem. We're in the process of getting an ARM Mac Mini (we two developers both have Intel machines right now) and we hope to be able to do more extensive testing soon. Any insights / ideas / critiques are very, very welcome. Again, thank you Eric (and Luke, Leah, and Abi)
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Jun ’21
Reply to XPC so universal app can interact with ARM or Intel dylib?
@eskimo - I've opened up access to a demo app on GitHub that takes our R wrapper (RCocoa) and drops it into simple app that lets you enter basic R code to return a single R value. It defaults the R code for convenience https://github.com/StatTag/RCocoaExampleLinkAtRuntime (dummy app - exposes some of the R bits we use in our app) https://github.com/StatTag/RCocoa (R wrapper framework) RCocoa is the R wrapper framework that references R. The dummy app links to the RCocoa project. RCocoa was written by my collaborator Luke and presented at useR! in 2019 (https://www.r-project.org/conferences/useR-2019/posters). Exposing R for incorporation into statistical applications has been super super helpful to our users. Thank you, Eric
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Jun ’21
Reply to XPC so universal app can interact with ARM or Intel dylib?
Hi, @eskimo - Thank you again for the fantastic response here. My apologies for just now responding (out last week). Luke, Leah I’m sure that generates some office teasing (-: LOL. I got that reference. (insert Steve Rogers meme) I'm also shocked none of us ever realized that... I can't thank you enough for you detailed and extraordinarily considerate response. This is some amazing guidance I'll bring to our team meeting this morning. If you’d like to dig into this in more detail, I’m going to recommend that you open a DTS tech support incident so that I can allocate more time to it. It might even involve gasp a phone call (-: Oh, I'm in! I'll submit it after our team meeting this morning. I'd love to see us do this in a way that benefits our users and also helps others understand how to approach similar needs. Thank you again, Eric (and Team Skywalker)
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Jun ’21
Reply to XPC so universal app can interact with ARM or Intel dylib?
@eskimo - Finally got our M1 through academic purchasing! DTS request opened! Follow-up: 781056948
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Sep ’21