Prev: select features
Next: Error building Real-Time Workshop
From: Steven_Lord on 27 Jul 2010 12:52


"da288 " <dahir288(a)googlemail.com> wrote in message
news:i2mnc5$oo9$1(a)fred.mathworks.com...

*snip*

> The reason I am doing this is whole exercise is because JAVAADDPATH clears
> all live global variables (WHY won't Mathworks fix this GAPING error?),

This is NOT a bug but documented and expected behavior.

JAVAADDPATH is documented to call "clear java" as part of its execution.

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/javaaddpath.html

"clear java" is documented to be "clear all" plus some additional clearing
that is not covered by "all" (and yes, that means "all" isn't really "all".
I think it might have been "all we know that you might want to clear at the
time we introduced this option.")

http://www.mathworks.com/access/helpdesk/help/techdoc/ref/clear.html

"clear all" is documented to remove global variables, as shown on the
reference page I linked above.

I _believe_ why this occurs is because if you had a variable that was an
instance of a Java class, it needs to be cleared in order to update the Java
class path. [I'm not certain of this, as the Java interface isn't exactly
my area of expertise.]

> and so I can populate live globals into temporarly local variables and
> store the existing live global names and their values, run javaaddpath,
> and then repopulate the original globals with their original values. Thus
> the idea is that the original workspace is restored.
>
> As you can tell I've tried a lot of different combinations to no avail.
> Any help would be very much appreciated!

I know you're not going to like this question, but I think it's important to
ask anyway. Why are you using global variables at all? Is there an
alternate approach that you can use instead of globals, which as you
probably know can be dangerous (insofar as ANYONE with access to the global
workspace can change your data, and therefore how your function behaves,
without giving you ANY indication of the change. Functions involving global
variables can be quite painful to debug.)

--
Steve Lord
slord(a)mathworks.com
comp.soft-sys.matlab (CSSM) FAQ: http://matlabwiki.mathworks.com/MATLAB_FAQ
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

From: da288 on 28 Jul 2010 04:13
Hi guys,

Thanks very much for all your prompt replies. Oleg, your proposal does seem to work, but it requires that I create my own global var. The context that I am using it in is to recreate the original global vars that are cleared when calling javaaddpath.

US: You said "the correct syntax would be..." only to give an error? I don't follow how this is correct. Could you please elaborate a little further.

Walter: Unfortunately, this doesn't work either!

Steven: I do know it's documented, it's just i. unexpected behaviour and ii. extremely inconvenient, as multiple people have criticised. I'm not the only one to find it unacceptable.

To everyone who asked: I hate globals too, I am just preparing this script for someone else who will have globals created, and so can't let it be too intrusive by clearing all the globals as soon as it's run! As explained in the orignal post, I want to restore the existing globals and their values after running javaaddpath.

"Oleg Komarov" <oleg.komarovRemove.this(a)hotmail.it> wrote in message <i2mruh$s9k$1(a)fred.mathworks.com>...
> Walter Roberson <roberson(a)hushmail.com> wrote in message <TMB3o.49796$Ls1.25580(a)newsfe11.iad>...
> > da288 wrote:
> >
> > > eval('global names(1)')
> >
> > eval(['global ', names(1)]);
>
> I think you can still avoid eval:
>
> names = {'a','b'};
> global gVars
> gVars.(names{1}) = 5;
>
> Oleg
First  |  Prev  | 
Pages: 1 2
Prev: select features
Next: Error building Real-Time Workshop