Home/ Questions/Q 204531
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T17:28:33+00:00

In MATLAB, how do you tell where in the code a variable is getting

  • 0

In MATLAB, how do you tell where in the code a variable is getting output?

I have about 10K lines of MATLAB code with about 4 people working on it. Somewhere, someone has dumped a variable in a MATLAB script in the typical way:

foo

Unfortunately, I do not know what variable is getting output. And the output is cluttering out other more important outputs.

Any ideas?

p.s. Anyone ever try overwriting Standard.out? Since MATLAB and Java integration is so tight, would that work? A trick I’ve used in Java when faced with this problem is to replace Standard.out with my own version.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Ooh, I hate this too. I wish Matlab had a “dbstop if display” to stop on exactly this.

    The mlint traversal from weiyin is a good idea. Mlint can’t see dynamic code, though, such as arguments to eval() or string-valued figure handle callbacks. I’ve run in to output like this in callbacks like this, where update_table() returns something in some conditions.

    uicontrol('Style','pushbutton', 'Callback','update_table')

    You can “duck-punch” a method in to built-in types to give you a hook for dbstop. In a directory on your Matlab path, create a new directory named “@double”, and make a @double/display.m file like this.

    function display(varargin)
builtin('display', varargin{:});

    Then you can do

    dbstop in double/display at 2

    and run your code. Now you’ll be dropped in to the debugger whenever display is implicitly called by the omitted semicolon, including from dynamic code. Doing it for @double seems to cover char and cells as well. If it’s a different type being displayed, you may have to experiment.

    You could probably override the built-in disp() the same way. I think this would be analagous to a custom replacement for Java’s System.out stream.

    Needless to say, adding methods to built-in types is nonstandard, unsupported, very error-prone, and something to be very wary of outside a debugging session.

    • 0