Notes on actually calling Python from within Matlab, Matlab from within VSCode Jupyter notebooks, and version control of Matlab project folders with Git. These are hastily scribbled notes, not transformed into anything cohesive quite yet.
- The official Mathworks-authored project on the File Exchange
- See the discussion tab for an issue with the Open Weather API
- The official repository related to this project
- The GitHub issue I opened detailing how to fix it locally
- My fork of that repo, with the example partially worked out
- This is the core reference, the related topics show all the precise type relationships and how to convert types
- Start with this project...
- This Live Task will configure it...
- From a discussion with Kevin. Let's work together to figure it out?
- Here you can run Matlab in Jupyter notebooks, and then with VSCode's JupyterLab extension, you can write Matlab code in VSCode, AND run it.
- Call Matlab from within Python without having to have Matlab open. This is excellent, because you can work alongside Matlab using coworkers, and use their code.
- Access Python from Matlab. This is the other way around. Now you can sprinkle some Python into your Matlab scripts. For example, this could be a great way to try seaborn plotting in your Matlab process (if that works idk).
- Alternatively you can use the prior instructions to orchestrate things from Python and call the Matlab script to get data in.
- Finally, and this is an important but minor note, use your Python virtual environments from within Matlab. This is important because you can designate a set of Python packages to use for a certain projects, and not worry about polluting/breaking another one of your projects.
- Here is how to set up diff and merge of Matlab objects with visdiff
- Also, instead of designing apps visually, do it programmatically.
- For Simulink, you need VCS and very small files. One block per file almost. Lots of references
- Quote from someone discussing Git and version control with Matlab projects:
Do this all the time at scale, with many people in a team. Git is amazing, hands down, for distributed work flow.
Simulink's diff tool is... adequate. Mathworks, if you're listening, older versions were better when it color coded the differences.
You absolutely have to componentize. Library blocks everywhere, one block per library if you can (new subsystem references may be the same thing). It should be virtually impossible to find a subsystem that isn't a reference. Then merge often.
If you have small deltas, the built-in diff and merge tool works well. However, you also need lots of files to avoid the conflict in the first place.
This flow chart should be your new Bible:
https://www.mathworks.com/help/simulink/ug/types-of-model-components.html
Note that "subsystem" isn't an option.
- Create a Matlab package
- Consider packaging your network solver? Use propshop and Python to get properties
- Also, instead of package namespaces, you can create a toolbox
- See the most popular community toolboxes
- https://www.mathworks.com/matlabcentral/fileexchange/?category%5B%5D=matlab%2Findex&product_family%5B%5D=matlab&sort=downloads_desc&source%5B%5D=community&type%5B%5D=toolboxes_and_products>
- Settings can be backed up from
$Env:APPDATA\MathWorks\MATLAB. - See also Matlab Test, a toolbox for tests. Looks like the test toolbox is modeled after pytest, with fixtures and such. And it just came out, it seems that Matlab is taking software development best practices seriously. It also looks like there's a free set of test tools built in
- Reload modified user-defined module
- Importing Python stuff