MATLAB Runtime Server

Testing While Emulating the Runtime Server (GUI)

Once you have compiled all of the M-files of a MATLAB runtime GUI application, you can test the application with the Runtime Server. However, since the Runtime Server does not provide a command window, for the purpose of debugging it is much easier to have your development version of MATLAB emulate the Runtime Server as a first step in the testing process. You should still test the application with the actual Runtime Server variant later. This section discusses both kinds of testing and includes a troubleshooting section.

Moving P-Files to Final Locations

If you store your source M-files outside of the toolbox directory, then at some point during your testing you should move the corresponding P-files to their final destinations under toolbox. Then use rehash toolboxreset to register the changes.

Each time you change the source M-files, remember to delete, regenerate, and move the P-files to their toolbox destination. Again, use rehash toolboxreset as necessary to register the changes to toolbox subdirectories.

Emulating the Runtime Server

Commercial MATLAB can emulate the Runtime Server environment by disabling the MATLAB ability to read M-files and standard P-files. The command window remains active, however. This section describes the procedure and some tips for testing while MATLAB emulates the Runtime Server.

To test and debug while MATLAB emulates the Runtime Server, follow this procedure:

1. At the MATLAB prompt, type

1. runtime on

   to start emulating the Runtime Server.

   To find out whether MATLAB is emulating the Runtime Server at a given time, type

   • runtime status
     

   at the command line.

2. Run your application from the command line. For the most accurate simulation of the Runtime Server environment, launch the application through matlabrt.p, as the Runtime Server does. At the command line type

• matlabrt
  

3. If there are errors, the usual error report in the MATLAB command window shows you where they occurred. To execute M-files and debug your functions, first turn off Runtime Server emulation by typing

• runtime off
  

1. and then debug the problematic M-files as you normally would.

4. Whenever you change an M-file, be sure that runtime MATLAB registers those changes: If the M-file is under the toolbox directory, then use rehash toolboxreset. Then, use buildp to recompile the M-file into a runtime P-file. Finally, test the application again with MATLAB emulating the Runtime Server.
5. To exit the application without quitting MATLAB, close the application's GUI from the command line by typing

1. close force

Runtime Server Emulation Considerations

There are a few things you should keep in mind when using MATLAB to emulate the Runtime Server:

• Even when emulating the Runtime Server, commercial MATLAB displays untrapped errors in the command window. To see the effects of the global error behavior that you specified in matlabrt.m, you must run the application with the Runtime Server variant, as described in Testing with the Runtime Server Variant (GUI).
• It might help to clear memory-resident functions by typing rehash toolboxreset before starting to emulate the Runtime Server. This ensures that MATLAB does not use a P-file already in memory from an earlier run.
• You might want to save your development path before running the application, since matlabrt replaces it with the runtime path. Type

• devpath = path;
  save devpath devpath
  

• After ending Runtime Server emulation, you can restore your development path by typing

  • load devpath
    path(devpath)
    

  If the path.m function is not on the runtime path, then you can use matlabpath(devpath) instead. Restarting MATLAB also restores your original path.

Troubleshooting

If the application runs normally with commercial MATLAB but does not run as expected with MATLAB emulating the Runtime Server, then the problem might be one of the following:

• Some M-files did not compile. If necessary M-files were not specified in the compile list for any reason, then the corresponding P-files will be missing and the application might not run properly.
• If you did not use cleanp before compiling, then the application might be using a P-file that was not generated from the current version of the M-file. When this happens, you might need to delete all P-files and recompile them.
• If your application uses toolbar or menu items from the MATLAB default figure window, then you need to include 'FigureMenuBar.fig' and 'FigureToolBar.fig' in your input to buildp or depfun. If your application uses GUI elements and creates .fig files, then you should include those .fig files in your input to buildp or depfun as well.
• Some directories are missing from the path. If the path specified in pathdefrt is lacking directories that contain application files, then the application might not run properly.

You might be able to determine the source of the problem by running the application using the runtime path with commercial MATLAB. Type

• runtime off
  rehash toolboxreset
  matlabrt
  

If the application now runs as expected, then there are probably uncompiled M-files. If the problem persists even with commercial MATLAB, then the path specification in pathdefrt might be incomplete. In either case, the MATLAB error messages should provide a good indication of which files are not being found.

Analyzing Functions Called by eval.   Calls to buildp or depfun might not find functions whose names are assembled at runtime within the calling function, and which are executed using eval, evalc, or evalin. For example, if your application calls a function named action1.m by concatenating the strings 'action' and '1' in an eval statement,

• x = 1;
  eval(strcat('action',int2str(x)));
  

then depfun does not recognize that there is a function called action1.m.

To make certain that depfun does analyze this file, insert the following code in one of the other application files, such as matlabrt.

• if 0
     action1
  end
  

The if statement above does not execute at runtime, but it allows depfun to see the full action1 function name when it analyzes matlabrt.

Using inmem to Find Files That depfun Misses.   To find out whether buildp or depfun is missing certain application functions, you can compare the depfun diagnostics to the list of functions that are in MATLAB memory after the application is executed. You can view this list by using the inmem function, as described below.

1. Type rehash toolboxreset to renew the session, and then type

• matlabrt
  

1. to launch the application.

2. Use the application as thoroughly as possible by pressing buttons, selecting menus, etc. The goal of this is to force MATLAB to load all or most of the application's functions into memory. If there is a particular area of the application that is a source of problems for depfun, then use it especially heavily to make sure that MATLAB loads all the relevant functions.
3. When you have used the application sufficiently to load the relevant functions into memory, quit the application without exiting MATLAB.
4. Generate the list of functions in memory by typing

• memlist = inmem
  

1. The listed functions are those that MATLAB used to carry out the tasks that you just performed in Step 2.

5. Use depfun, as before, to generate a list of the application's dependent functions.

• list = depfun('matlabrt')
  

6. Compare the functions in list and memlist. You can do this visually, or by using a script like the one below.

• % Extract filenames from DEPFUN output
  for i = 1:length(list)
     [path,name,ext,ver] = fileparts(list{i});
     list{i} = name;
  end
  % DEPFUN results not listed by INMEM:
  depfiles = setdiff(char(list),char(memlist),'rows')
  % INMEM results not listed by DEPFUN:
  memfiles = setdiff(char(memlist),char(list),'rows')
  

The memfiles variable contains a list of functions found by inmem but not by depfun. To force depfun to analyze these functions, you can place a nonexecuting if conditional in an application file such as matlabrt.m, as shown in Analyzing Functions Called by eval.

The depfiles variable contains a list of functions found by depfun but not by inmem. These are probably valid application files that were not called by MATLAB (and not loaded into memory) when you ran the application.

Compiling Extra M-Files.   If you cannot anticipate what functions might be invoked via an evaluation command, then you might decide to compile some extra M-files. As a last resort, you can compile all functions on the path and in the current directory, using the pcodeall function.

Compiling the Application (GUI)

Testing with the Runtime Server Variant (GUI)