How to automatically change functions in a M-file that have been removed/changed between two releases of Matlab

Hello,

I’m seeking help with automation of a process. In short, I have a list of Matlab codes/applications (30 of them in total) written in the 2011a and 2018b. This means over 100 000 files with .m or .p extensions, many of them include functions that have changed/removed. I would like to automate the migration process as described in the picture below:

[Adam]

That sounds like a seriously major undertaking and not at all trivial. When you say you are 'seeking help' with it do you have code for most of it but with parts that doesn't work or do you just have this wishlist and need code from scratch? Any kind of file editing automation of this kind would seem to me to be extremely complex.

[Walter Roberson]

You cannot use just number of arguments to determine which syntax was being used, due to name / value pairs.

In some cases such as svmtrain it can be tricky to find the corresponding replacement for some of the former options, and a fair bit of the time the new functionality is better and forcing the old functionality would not be the best option.

Have you considered writing shim routines? You would give them other names, and they would analyze the input arguments and call the newer functions.

[Anthony Mukanya]

Hello gentlemen,

I forgot to mention that part I have donne part 1 & 2 already. I have a very efficient script for that. So it part 3 ie the propre migration itself that I'm still trying to figure out so any help will be greatly appreciated.

Answer 1

[Steven Lord]

As Adam said this is going to be a major undertaking, and quite possible an impossible one (as written.)

The Release Notes will help you achieve part of your step 1. However, we don't document all the changes, and MathWorks functions can change behavior without them being changed themselves if the functions they call change. Ideally those changes are beneficial (bug fixes, improvements in performance, new functionality) but they are still changes.

At step 3, opening P-coded files will not let you access the operations they perform when executed. That's the point behind P-coded files.

It sounds like you have legacy code (by both the modern interpretation and by Michael Feathers's definition.) One way to be more confident that the code is behaving correctly as you upgrade releases is to write tests for that code. While the MATLAB Unit Testing Framework was introduced in release R2013a (for class-based tests) and R2013b (for function-based tests) and so you wouldn't be able to run those in release R2011a, you could create script-based tests. You wouldn't be able to run those tests using runtests in R2011a like the current documentation shows, but you could run them like any normal script file in any release since the assert function was introduced in release R2007a. Then in release R2018b you could run them using runtests.

I'm not saying this would be an easy project. It would take a lot of work. But it would allow you to understand exactly what impact changes to your code or changes to MathWorks functions have on the code you own.