How can I log commands being executed by matlab? Like diary() but for all function calls.

Hi there,

I have a GUI that wanted to log what the user interacts with. In my understading this would be which function calls are being executed in the background and their order, as the user goes about using the app.

Is there a way to tap into this "input stream" and log them into a file? Similar to diary() function but for all the function calls being executed.

My ultimate goal with this log of inputs is to be able to "replay" and rexecute the set of steps the user has made, programatically. Let me know if you suggest another aproach. I imagine this would be a large stack but I can probably come up with something to filter the relevant bits.

Thanks in advance!

[Walter Roberson]

If it were possible at all, it would have to be very extensive since quite a bit of MATLAB is implemented in MATLAB. For example if fsurf() were called, then every line of argument processing of fsurf.m would have to be traced, every test to see what was being done, every calculation to do mesh refinement... until eventually built-in graphics commands were called.

[Luciano Branco]

Sure, but I was thinking I could just filter based on the folder of the functions that were called. For example, using profiler as suggested by @Bruno Luong I can easily tell which functions are from my GUI and which are from Matlab.

Answer 1

[Bruno Luong]

Check out profile see if it meets your need.

[Luciano Branco]

This was initially nice but it lacks the contextual arguments that were called with the function. To be able to "replay" what the used did, I would need to know what arguments the GUI passed to the function:

'... >@(src,evt) ChangeFilter (obj,src) '

[Bruno Luong]

What you ask (log with fuction call with full input arguments) is kind of practically impossible. The arguments of the functions when it was called can not be valid (such as object/graphic handle, a position of the mouse, of the slider...) when replay later. You also ask to save an arguments that could potentially be huge and can be stored separately in memory at a given instant (a huge matrix for example). MATLAB can shared data in the memory to save during the run. But when asking to save argument it will take the whole place by itseft, and that multiplied by the time history of the run, it would fillup your storage space very quickly. No one could dare to do that. And saving such stack will slow down significantly function calling and disrupt significantly the normal run.

Some heavily numerical library can have possibility of warm start; development such feature requires a great organization and it is not easy. What you ask is such a generic tool for any existing function out there.

I doubt such tool would exist for any language, any development tool.

[Walter Roberson]

In part, it depends what they need for a replay.

Suppose for example during the original run that figure 3 existed and was a parameter to a function and had accumulated particular properties. Now, during the replay, is the required input a figure that exactly matched the original figure 3, right down to figure number and right down to the fact that at the time of the original run, axes7 existed with 'Tag', 'Walla Walla' (except possibly with the handles being at different locations in memory, as long as they were handles to the same contents) ? Is the purpose to be able to later step through and watch step-by-step how the results were formed based on identical objects?

Or is the purpose more like a "notebook" style of wanting the user to be able to play around and take a closer look at aspects if the user wants to? Because that is different -- the "notebook" style starts with fresh objects (or whatever objects are in memory) and evaluates the steps from the beginning, possibly a section at a time. Matrices do not need to have been saved at each step: the code works based on whatever it happens to find in memory at the time.

The "notebook" style is more or less what Livescript is for.

[Luciano Branco]

I see! Yeah, it seems this approach I came up with won't be the way to go. Please see if you suggest any other way or if it's all unfeasible.

So my scenario is, I have this (massive) GUI with lots of functionalities to review datasets (timeseries) and in my group we each use it slightly different. But there's always a set of steps all of us take initially once we load a dataset. For example, I like to filter (Fourier transform) my data with parameters X, then select certain channels to (1 to 16), then select certain window, etc. All of these are buttons we press in the GUI while tweaking certain input parameters.

My end goal is to have a button I can press to run my default initial processing. And this button would perform differently for each one of my collegues. I imagined we all "save" our processing steps onto a file and the button just reads it and call the functions on file. These functions would be the GUI functions I clicked on (ChangeFilter, SelectChannels, ChangeWindow, ...) but here applied in the current data.

I went with this approach of my question because this way I could add flexibility (any user can "record" a set of instructions that they like) while adding minimal changes to the GUI- I would just "tap" into what's already implemented without changing function calls and record it.

This way it would also work for all GUI functions since they all would be recorded- provided the dataset is similar enough, i.e. if I need to select channels 1 to 16, there should be at least 16 channels to begin with.

Honestly, the profile() initially suggested might still do the trick. I just need to figure out how to call those functions properly given a new dataset.

What do y'all think?

Thanks again for all the help!

[Walter Roberson]

I dealt with something similar in the past. The way I handled it was to create a text-based command language. Each GUI operation was coded in terms of what it did in the internal command language.... which could be recorded and replayed or executed in batch.

Generally speaking, when you have a display component and you have an execution component, there are three major ways that the two can be combined:

• display and execution could be tightly coupled, knowing a lot about each other, in which case changing to a new display model or a new execution strategy might require a lot of co-dependent work; or
• display might be primarily coded as sort of a "front end" to the execution portion, in which case it might be fairly easy to create "macros" because the graphics is calling into a well-defined interface to do the real work anyhow; or
• display might be primary, and the way to create macros might end up being more or less recording mouse movements and key presses and then using java robot facility to replay them. Such macros are not typically human readable (or human comprehendible) and run the risk of failing if the font is changed or a spelling mistake is fixed (because that might make a button a different size and so alter where the robot needs to move to.)

[Luciano Branco]

Interesting.. I will think about these suggestions and see how they would fit our project in the upcoming weeks.

Thank you for your comments, @Walter Roberson @Bruno Luong!

[Strider]

@Luciano Branco My design space sounds similar to yours and I was approaching it with making a SQLite table(s) of known 'meta-deta' to get back to the state of a GUI. The trivial example would be recreating a tiled layout with several signals on it and having a class that can unpack that SQLite file.

I am interested to hear what solution you chose.