Error message: matlab Variable "VARNAME" is inaccessible. When a variable appears on both sides of an assignment statement, the variable may become temporarily unavailable during processing.

My code looks something like this:

[inputObject,Container] = myfunction(inputObject,param1,param2,Container);

Container is a containers.Map object; I'm basically trying to use it as a hashtable.

Also, of note, myfunction is a recursive function call; there are calls to myfunction within myfunction.

So here's the problem. I am making several calls to myfunction in a row. I want Container to be available to the next function call as soon as the previous one has completed. However, when I try to evaluate "Container" in debug mode, I get the error given above. VARNAME in this case is Container.

Here's the weird part. If I make a line solely containing the word "Container", and then using "step" in debugger, step my way to that line (with a breakpoint on that line) I can finally get MATLAB to evaluate "Container". Then, this value becomes "available", and MATLAB finally starts passing it from function call to function call. But that ONLY happens AFTER I do this thing where I step my way to that line with a breakpoint on it.

So I think the issue is that Container isn't being "refreshed" in MATLAB's memory. I need a way to get it to do this. Any ideas?

[dpb]

_"when I try to evaluate "Container" in debug mode, ..."

I presume you have no issue outside debugging (other than, perhaps, the function isn't yet fully debugged and working correctly which would seem only reason to use the debugger)?

I'd guess it's the additional instrumentation/hooks needed to run in debug mode that is causing the conflict and likely that's a hard limitation that there isn't a workaround for at least without TMW intervention to find a way inside the debugger to manage to make your case work...

[Joshua Diamond]

No, it doesn't work outside debugger either. I don't get an error, but my Container just never fills.

In debugger, if go through that specific series of steps, only then does the container start filling.

[Walter Roberson]

For debugging, rewrite as

[inputObject, newContainer] = myfunction(inputObject,param1,param2,Container);
Container = newContainer;

[Joshua Diamond]

Thank you Walter--that works.

Unfortunately, it's even slower than the alternative, which is having my container be a Global. I think the issue is that instead of one massive Container, we have two to deal with in the memory (Container and newContainer).

Indeed, both options seem inefficient. For the global, I get the warning "GLOBAL could be very inefficient unless it is a top level statement in its function". Can we think of any other ideas?

[Walter Roberson]

shared variables are more efficient than globals.

[Joshua Diamond]

I found an excellent solution to the problem here, in the answer provided by Joan Puig.

Thank you!