Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mac OS X support #30

Closed
profwillie opened this issue Sep 19, 2019 · 3 comments
Closed

Mac OS X support #30

profwillie opened this issue Sep 19, 2019 · 3 comments

Comments

@profwillie
Copy link

Does /psi work well on Mac OS X? What are the limitations?

@AshleyF
Copy link
Contributor

AshleyF commented Sep 19, 2019

The core runtime, along with ROS bridge and (Python) interop is .NET Standard, and so is supported on MacOS X as well as Linux and Windows. The major areas of componentry (e.g. imaging, media, speech, ...) also have cross-plat assemblies at least for standard message types, but then each have platform-specific components (. Sadly, MacOS lags behind here. We've tried to be consistent in the naming of projects with .Windows or .Linux suffixes when things are platform-specific. Projects with no such suffix are cross-plat and should work on Mac.

For example, Microsoft.Psi.Imaging contains the base Image/EncodedImage, PixelFormat, ImagePool and other types, while Microsoft.Psi.Imaging.Linux/.Windows contains encoders for specific platforms. Notice, a MacOS-specific implementation is missing. That's the main limitation of \psi on Mac; gaps in component-level implementations. We welcome contributions here!

FWIW, my personal arrangement is VS Code on a MacBook for development. I run PsiStudio (which is Windows-only) in Parallels which works great. A lot of my work happens to be from recorded stores (gathered from deployed Linux/Windows systems) and so, not having source/sensor components for the Mac itself hasn't been much of an issue. Totally depends on your scenario.

Hope this helps!

@profwillie
Copy link
Author

This helped a lot. Similar to your setup, we are using a Windows system to record data from sensors to a data store. Then on Macs, we can replay the data just fine.

One thing that took me a little while to figure out was the right types of projects to have in my solution. Here is what I ended up with:

  • .Net Framework project that contains the Windows-specific code and can reference the .Net Standard projects
  • Many .Net Standard projects for the different components that are platform independent
  • 1 .Net Core Console project used to test the .Net Standard projects.

Is this a reasonable setup?

@AshleyF
Copy link
Contributor

AshleyF commented Jun 1, 2020

That sounds like a totally reasonable setup; very similar to what we do. Glad it’s working for you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants