Can I overwrite a function in a compiled program with a custom version?

I have a set of MATLAB functions with a main function that will be compiled. This program calls a function that requires the user to design part of it.

For example, I have a compiled program runFit.exe. The source code calls a wrapper.m that gets some parameters which the user defines how the parameters are actually used. I would need to include wrapper.m when I compile runFit.exe, but can the user write a new wrapper.m that gets used instead of the one compiled in the code? Or is the only way is to not compile the program?

Thanks!

Jesse

Answer 1

[Jan]

This will not work. And if it works, it would conflict with the license conditions.

Do not provide parameters as M-functions, but as data files, e.g. in text format, as binary or MAT file. Then it is easy to let the user change the parameters without the need to parse and run an M-function.

[Zhangxi Feng]

Thank you for the response. However, providing the parameters directly to the user won't be feasible since I am running the genetic algorithm for many generations, many populations, and for many parameters.

This parameter writing function will write input files with these parameters that are used in an another program that calculates some results that gets used in the error evaluation.

I am thinking now I must have the user provide the function call in a text file and eval() it in the code. I know this is bad practice. Do you have any suggestions?

Thanks,

Jesse

[Steven Lord]

Not only is using eval bad practice, it won't work in a deployed application. From the documentation:

"The compiler secures your code against unauthorized changes. Deployable MATLAB® files are suspended or frozen at the time of compilation. This does not mean that you cannot deploy a flexible application—it means that you must design your application with flexibility in mind. If you want the end user to be able to choose between two different methods, for example, both methods must be available in the deployable archive.

The MATLAB Runtime only works on MATLAB code that was encrypted when the deployable archive was built. Any function or process that dynamically generates new MATLAB code will not work against the MATLAB Runtime."

You wrote "This parameter writing function will write input files with these parameters that are used in an another program that calculates some results that gets used in the error evaluation." Can you say more about this "another program" and how it interacts with those "input files"? Describe your workflow in a little more detail and we may be able to offer an alternate design that avoids trying to run dynamically generated MATLAB code.

[Zhangxi Feng]

This other program is a completely developed program written in Fortran. The wrapper function will write the parameters from the genetic algorithm's generations into a text file at specific locations. Like this:

function WriteWrapper(fname,inputs,cases)
par=inputs(:,1).*inputs(:,5);
...
fileID=fopen(fname,'w');
...
fprintf(fileID,'0.175 0 %5.1f %5.1f 0.1 0.1 \n',par(36),par(37));
...
fclose(fileID);
end

The Fortran program will read this file for these values and produce stress strain and other material mechanical response results.

The error function called by genetic algorithm will take the results and calculate an error that is returned back to the genetic algorithm.

I think for now, we will just leave the code uncompiled.

[Steven Lord]

Is the list of parameters that you want to write into the file that the Fortran executable will consume fixed at compile-time for the MATLAB code? You can generate text files from a compiled application; what you can't generate is MATLAB code files that you expect to be executed from within the compiled application.

[Zhangxi Feng]

I understand. If the parameter file is fixed, then I wouldn't need to allow the user to define this function. However, the parameter file may not be the same all the time. For example, some times it may need to write more parameters, sometimes less, and sometimes may need to write more than one file.

I now think the only way to incorporate that flexibility is to not compile the code so the user may simply modify the functions as they need. I am not talking about end-customer users (at least not yet) so this is not a pressing issue since it would just be used within my research group for now. And even if not, it can always be like MTEX.

[Jan]

@Zhangxi Fend: It is a good programming practice to keep code for computations and input data separated. It is a standard for scientific software, that inputs can be provided by text or binary files. The ini files under Windows and the configuration files of Linux systems are famous examples. As soon, as the data are not included in a specific code, e.g. as Matlab code, it is possible in theory, to process them with different tools and to compare the results.

You can create your own file format and a Matlab function to import it. You can implement all kind of special cases, e.g. the number of parameters or of the needed files to be imported. There is no need to implement this as Matlab code, because these cases are such simple, that some simple tables are sufficient. This is even a good idea, if you do not compile the code. A strictly defined import functions is more reliable that creating a set of different codes to create the input data, because code must be tested exhaustively in every case. Even trivial code offers an infinite number of possible bugs. So prefer to write one code and test it exhaustively and provide the data as dull and static text/binary files.

[Guillaume]

For example, some times it may need to write more parameters, sometimes less, and sometimes may need to write more than one file.

While allowing user to specify all this as matlab code may be the easiest for now, it's also the most fragile. The user have to be careful not to stomp over your own variables with their m code (maybe they're not even aware of your own variables, and one day a user overwrites one of your variable which slightly changes the behaviour of the code and results in slightly incorrect outputs. That goes unnoticed until the probe crashes into Mars because it's off by a few 100 meters).

The correct way to deal with this is to provide an input method completely independent of m code that allows for all these variations. It could be via configuration, a GUI, whatever. Yes, it'll be more work to start with, but ultimately a better usage experience.

[Zhangxi Feng]

Thank you for your suggestions. I can definitely see a way to design an input file reader that dynamically recognizes the user's desired parameters and writes them according to the user's given conditions to achieve the level of flexibility for this.