Discover MakerZone

MATLAB and Simulink resources for Arduino, LEGO, and Raspberry Pi

Learn more

Discover what MATLAB® can do for your career.

Opportunities for recent engineering grads.

Apply Today

Thread Subject:
path problems in 2009b

Subject: path problems in 2009b

From: Alan B

Date: 13 Jul, 2010 20:54:06

Message: 1 of 9

My office just upgraded to 2009b, and now every time I try to run code with f5 or ctrl-enter, Matlab gives me the "... is not found in the current directory or on the MATLAB path" dialog box. When I try "change directory", the script runs, but the current directory does not actually change. This happens regardless of the location of the script, the contents of the path variable, and the current working directory. That is, I can try to run a script that is in my current working directory, and the dialog box will still appear.

My startup.m (where I normally add all my project directories using addpath) is still running fine, and when I view the path in the command window it appears to contain all the necessary directories.

Does anyone know why this is happening? How can I fix it?

Subject: path problems in 2009b

From: Alan B

Date: 16 Sep, 2010 14:39:04

Message: 2 of 9

"Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message <i1ijpd$lfn$1@fred.mathworks.com>...
> My office just upgraded to 2009b, and now every time I try to run code with f5 or ctrl-enter, Matlab gives me the "... is not found in the current directory or on the MATLAB path" dialog box. When I try "change directory", the script runs, but the current directory does not actually change. This happens regardless of the location of the script, the contents of the path variable, and the current working directory. That is, I can try to run a script that is in my current working directory, and the dialog box will still appear.
>
> My startup.m (where I normally add all my project directories using addpath) is still running fine, and when I view the path in the command window it appears to contain all the necessary directories.
>
> Does anyone know why this is happening? How can I fix it?

Can anyone give me any kind of suggestion for this? I never saw this problem before upgrading to 2009b. It is not a small problem, it significantly affects my workflow, and slows me down a lot - it nearly negates every other benefit of using the Matlab editor. Does anyone have even the slightest idea where I might find a config file, or ANYTHING, that has something to do with the search path, and/or the editor?

Subject: path problems in 2009b

From: Steven_Lord

Date: 16 Sep, 2010 17:08:06

Message: 3 of 9



"Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message
news:i6ta68$qca$1@fred.mathworks.com...
> "Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message
> <i1ijpd$lfn$1@fred.mathworks.com>...
>> My office just upgraded to 2009b, and now every time I try to run code
>> with f5 or ctrl-enter, Matlab gives me the "... is not found in the
>> current directory or on the MATLAB path" dialog box. When I try "change
>> directory", the script runs, but the current directory does not actually
>> change. This happens regardless of the location of the script, the
>> contents of the path variable, and the current working directory. That
>> is, I can try to run a script that is in my current working directory,
>> and the dialog box will still appear.
>>
>> My startup.m (where I normally add all my project directories using
>> addpath) is still running fine, and when I view the path in the command
>> window it appears to contain all the necessary directories.
>>
>> Does anyone know why this is happening? How can I fix it?
>
> Can anyone give me any kind of suggestion for this? I never saw this
> problem before upgrading to 2009b. It is not a small problem, it
> significantly affects my workflow, and slows me down a lot - it nearly
> negates every other benefit of using the Matlab editor. Does anyone have
> even the slightest idea where I might find a config file, or ANYTHING,
> that has something to do with the search path, and/or the editor?

You should contact Technical Support and work with them to diagnose the
cause of this behavior.

--
Steve Lord
slord@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

Subject: path problems in 2009b

From: Alan B

Date: 16 Sep, 2010 22:34:03

Message: 4 of 9

"Steven_Lord" <slord@mathworks.com> wrote in message <i6titm$aae$1@fred.mathworks.com>...
>
>
> "Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message
> news:i6ta68$qca$1@fred.mathworks.com...
> > "Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message
> > <i1ijpd$lfn$1@fred.mathworks.com>...
> >> My office just upgraded to 2009b, and now every time I try to run code
> >> with f5 or ctrl-enter, Matlab gives me the "... is not found in the
> >> current directory or on the MATLAB path" dialog box. When I try "change
> >> directory", the script runs, but the current directory does not actually
> >> change. This happens regardless of the location of the script, the
> >> contents of the path variable, and the current working directory. That
> >> is, I can try to run a script that is in my current working directory,
> >> and the dialog box will still appear.
> >>
> >> My startup.m (where I normally add all my project directories using
> >> addpath) is still running fine, and when I view the path in the command
> >> window it appears to contain all the necessary directories.
> >>
> >> Does anyone know why this is happening? How can I fix it?
> >
> > Can anyone give me any kind of suggestion for this? I never saw this
> > problem before upgrading to 2009b. It is not a small problem, it
> > significantly affects my workflow, and slows me down a lot - it nearly
> > negates every other benefit of using the Matlab editor. Does anyone have
> > even the slightest idea where I might find a config file, or ANYTHING,
> > that has something to do with the search path, and/or the editor?
>
> You should contact Technical Support and work with them to diagnose the
> cause of this behavior.
>
> --
> Steve Lord
> slord@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

Unfortunately my office is no longer paying for technical support, so this is my next option.

Subject: path problems in 2009b

From: Jan Simon

Date: 17 Sep, 2010 10:27:05

Message: 5 of 9

Dear Alan,

Please explain more details: Did this behaviour appear directly after the installation? Or just after you included your startup.m?
Can you start functions from Matlab's toolboxes?
Are the concerned folders stored on a network drive or locally? Do you use UNC paths?

It is always easier to solve a problem if the necessary number of details is known. Most of all the fundamental: What exactly has changed since it was working?

Good luck, Jan

Subject: path problems in 2009b

From: Alan B

Date: 17 Sep, 2010 16:30:16

Message: 6 of 9

"Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <i6vfpp$810$1@fred.mathworks.com>...
> Dear Alan,
>
> Please explain more details: Did this behaviour appear directly after the installation? Or just after you included your startup.m?
> Can you start functions from Matlab's toolboxes?
> Are the concerned folders stored on a network drive or locally? Do you use UNC paths?
>
> It is always easier to solve a problem if the necessary number of details is known. Most of all the fundamental: What exactly has changed since it was working?
>
> Good luck, Jan

Hi Jan,
Thanks for trying to help. Like you, I've seen many posts here that were obviously missing crucial information, the poster seemingly oblivious to the fact that his question is unanswerable with the amount of information given. It is not so obvious to see that you have left out information, when you have absolutely no idea what is causing your problem. The "unknown unknowns" are the issue.

HOWEVER, since you took the time to read my post, and make a few suggestions, even though you too were shooting in the dark, I was able to solve the problem myself. You knew some unknowns that I didn't know. In fact, because the problem was limited to the editor, I assumed it was somehow related to the editor and not to my startup.m, where I add my directories to the search path. The point is, communication annihilates ignorance, and that is why I post on this group - but it is only useful when communication actually occurs.

As it turns out, I had a function, assert.m, which I wrote several years ago, before it existed as a Matlab built-in. It was not present in 2006b, but it is in 2009b. Compounding the problem was the fact that I have intentionally overloaded several built-in functions. Because the warnings for those name conflicts are excessively verbose, I never actually read them. So, after the upgrade, when screen upon screen of name conflict warnings appeared as my startup.m ran, I never saw the warning for assert.m.

John and Walter and the rest of you can laugh at me now, as I learn my lesson about overloading built-ins. Jan, thanks for taking the time to respond.

Subject: path problems in 2009b

From: Alan B

Date: 17 Sep, 2010 16:44:05

Message: 7 of 9

"Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message <i7052o$krj$1@fred.mathworks.com>...
> "Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message <i6vfpp$810$1@fred.mathworks.com>...
> > Dear Alan,
> >
> > Please explain more details: Did this behaviour appear directly after the installation? Or just after you included your startup.m?
> > Can you start functions from Matlab's toolboxes?
> > Are the concerned folders stored on a network drive or locally? Do you use UNC paths?
> >
> > It is always easier to solve a problem if the necessary number of details is known. Most of all the fundamental: What exactly has changed since it was working?
> >
> > Good luck, Jan
>
> Hi Jan,
> Thanks for trying to help. Like you, I've seen many posts here that were obviously missing crucial information, the poster seemingly oblivious to the fact that his question is unanswerable with the amount of information given. It is not so obvious to see that you have left out information, when you have absolutely no idea what is causing your problem. The "unknown unknowns" are the issue.
>
> HOWEVER, since you took the time to read my post, and make a few suggestions, even though you too were shooting in the dark, I was able to solve the problem myself. You knew some unknowns that I didn't know. In fact, because the problem was limited to the editor, I assumed it was somehow related to the editor and not to my startup.m, where I add my directories to the search path. The point is, communication annihilates ignorance, and that is why I post on this group - but it is only useful when communication actually occurs.
>
> As it turns out, I had a function, assert.m, which I wrote several years ago, before it existed as a Matlab built-in. It was not present in 2006b, but it is in 2009b. Compounding the problem was the fact that I have intentionally overloaded several built-in functions. Because the warnings for those name conflicts are excessively verbose, I never actually read them. So, after the upgrade, when screen upon screen of name conflict warnings appeared as my startup.m ran, I never saw the warning for assert.m.
>
> John and Walter and the rest of you can laugh at me now, as I learn my lesson about overloading built-ins. Jan, thanks for taking the time to respond.

FYI, the (only) functions that I overloaded are semilogx, semilogy and loglog. Each of those generates a warning everytime the path variable is modified, which makes for dozens of warnings for my startup.m.

The reason I overloaded them was that they do not seem to work when defaultAxesNextPlot='add' (which it does, for me). I now recall hoping this would be fixed when we upgraded, but it is not.

Subject: path problems in 2009b

From: Steven_Lord

Date: 17 Sep, 2010 17:12:14

Message: 8 of 9



"Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message
news:i705sl$e8p$1@fred.mathworks.com...
> "Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message
> <i7052o$krj$1@fred.mathworks.com>...
>> "Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message
>> <i6vfpp$810$1@fred.mathworks.com>...
>> > Dear Alan,
>> >
>> > Please explain more details: Did this behaviour appear directly after
>> > the installation? Or just after you included your startup.m?
>> > Can you start functions from Matlab's toolboxes?
>> > Are the concerned folders stored on a network drive or locally? Do you
>> > use UNC paths?
>> >
>> > It is always easier to solve a problem if the necessary number of
>> > details is known. Most of all the fundamental: What exactly has changed
>> > since it was working?
>> >
>> > Good luck, Jan
>>
>> Hi Jan,
>> Thanks for trying to help. Like you, I've seen many posts here that were
>> obviously missing crucial information, the poster seemingly oblivious to
>> the fact that his question is unanswerable with the amount of information
>> given. It is not so obvious to see that you have left out information,
>> when you have absolutely no idea what is causing your problem. The
>> "unknown unknowns" are the issue.
>>
>> HOWEVER, since you took the time to read my post, and make a few
>> suggestions, even though you too were shooting in the dark, I was able to
>> solve the problem myself. You knew some unknowns that I didn't know. In
>> fact, because the problem was limited to the editor, I assumed it was
>> somehow related to the editor and not to my startup.m, where I add my
>> directories to the search path. The point is, communication annihilates
>> ignorance, and that is why I post on this group - but it is only useful
>> when communication actually occurs.
>>
>> As it turns out, I had a function, assert.m, which I wrote several years
>> ago, before it existed as a Matlab built-in. It was not present in 2006b,
>> but it is in 2009b. Compounding the problem was the fact that I have
>> intentionally overloaded several built-in functions. Because the warnings
>> for those name conflicts are excessively verbose, I never actually read
>> them. So, after the upgrade, when screen upon screen of name conflict
>> warnings appeared as my startup.m ran, I never saw the warning for
>> assert.m.
>>
>> John and Walter and the rest of you can laugh at me now, as I learn my
>> lesson about overloading built-ins. Jan, thanks for taking the time to
>> respond.
>
> FYI, the (only) functions that I overloaded are semilogx, semilogy and
> loglog. Each of those generates a warning everytime the path variable is
> modified, which makes for dozens of warnings for my startup.m.
>
> The reason I overloaded them was that they do not seem to work when
> defaultAxesNextPlot='add' (which it does, for me). I now recall hoping
> this would be fixed when we upgraded, but it is not.

Define "do not seem to work". If you mean that they do not change the
scaling of the appropriate axes, this is in fact the documented behavior.
See the last sentence in the Remarks section of the reference page for
SEMILOGX.

http://www.mathworks.com/help/techdoc/ref/semilogx.html

Setting the default Axes NextPlot property to 'add' is, in this case, the
same as calling HOLD ON. You've explicitly told the axes that you don't
want its properties to change, so SEMILOGX will not change the axes XScale
property. To me, that seems like the correct behavior. I'm curious what
you feel is the correct behavior in this scenario (which I assume is what
you have done in your shadowing versions of those built-ins.)

--
Steve Lord
slord@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

Subject: path problems in 2009b

From: Alan B

Date: 17 Sep, 2010 18:35:19

Message: 9 of 9

"Steven_Lord" <slord@mathworks.com> wrote in message <i707he$3f5$1@fred.mathworks.com>...
>
>
> "Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message
> news:i705sl$e8p$1@fred.mathworks.com...
> > "Alan B" <monguin61REM@OVETHIS.yahoo.com> wrote in message
> > <i7052o$krj$1@fred.mathworks.com>...
> >> "Jan Simon" <matlab.THIS_YEAR@nMINUSsimon.de> wrote in message
> >> <i6vfpp$810$1@fred.mathworks.com>...
> >> > Dear Alan,
> >> >
> >> > Please explain more details: Did this behaviour appear directly after
> >> > the installation? Or just after you included your startup.m?
> >> > Can you start functions from Matlab's toolboxes?
> >> > Are the concerned folders stored on a network drive or locally? Do you
> >> > use UNC paths?
> >> >
> >> > It is always easier to solve a problem if the necessary number of
> >> > details is known. Most of all the fundamental: What exactly has changed
> >> > since it was working?
> >> >
> >> > Good luck, Jan
> >>
> >> Hi Jan,
> >> Thanks for trying to help. Like you, I've seen many posts here that were
> >> obviously missing crucial information, the poster seemingly oblivious to
> >> the fact that his question is unanswerable with the amount of information
> >> given. It is not so obvious to see that you have left out information,
> >> when you have absolutely no idea what is causing your problem. The
> >> "unknown unknowns" are the issue.
> >>
> >> HOWEVER, since you took the time to read my post, and make a few
> >> suggestions, even though you too were shooting in the dark, I was able to
> >> solve the problem myself. You knew some unknowns that I didn't know. In
> >> fact, because the problem was limited to the editor, I assumed it was
> >> somehow related to the editor and not to my startup.m, where I add my
> >> directories to the search path. The point is, communication annihilates
> >> ignorance, and that is why I post on this group - but it is only useful
> >> when communication actually occurs.
> >>
> >> As it turns out, I had a function, assert.m, which I wrote several years
> >> ago, before it existed as a Matlab built-in. It was not present in 2006b,
> >> but it is in 2009b. Compounding the problem was the fact that I have
> >> intentionally overloaded several built-in functions. Because the warnings
> >> for those name conflicts are excessively verbose, I never actually read
> >> them. So, after the upgrade, when screen upon screen of name conflict
> >> warnings appeared as my startup.m ran, I never saw the warning for
> >> assert.m.
> >>
> >> John and Walter and the rest of you can laugh at me now, as I learn my
> >> lesson about overloading built-ins. Jan, thanks for taking the time to
> >> respond.
> >
> > FYI, the (only) functions that I overloaded are semilogx, semilogy and
> > loglog. Each of those generates a warning everytime the path variable is
> > modified, which makes for dozens of warnings for my startup.m.
> >
> > The reason I overloaded them was that they do not seem to work when
> > defaultAxesNextPlot='add' (which it does, for me). I now recall hoping
> > this would be fixed when we upgraded, but it is not.
>
> Define "do not seem to work". If you mean that they do not change the
> scaling of the appropriate axes, this is in fact the documented behavior.
> See the last sentence in the Remarks section of the reference page for
> SEMILOGX.
>
> http://www.mathworks.com/help/techdoc/ref/semilogx.html
>
> Setting the default Axes NextPlot property to 'add' is, in this case, the
> same as calling HOLD ON. You've explicitly told the axes that you don't
> want its properties to change, so SEMILOGX will not change the axes XScale
> property. To me, that seems like the correct behavior. I'm curious what
> you feel is the correct behavior in this scenario (which I assume is what
> you have done in your shadowing versions of those built-ins.)
>
> --
> Steve Lord
> slord@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

Yes, that's what I meant. I may or may not have known that it was documented when I wrote my overloaded versions, but if I did, I definitely forgot.

My use case is different than most people I talk to - I never use the hold function, because my axes all have NextPlot set to add by default. I prefer to use clf or cla when I want to replace the axes contents, and have the default behavior be to add to whatever is already there - this is much more common for me. This custom setting has caused other problems in the past (other people, using factory defaults, run my functions which try to make multiple plots on an axes without explicitly calling hold on), so I'm not too surprised to learn that it was ultimately the cause of this problem as well.

I would say the correct behavior for semilogx (which I DID have implemented in my shadowed versions until just now) is to change xscale regardless of axes state. I can't think of a reason that I would call semilogy and not want the axes scale changed. When I have NextPlot='add', and I use xlim, grid, view, campos, etc, these all work as expected, even though I've told the axes that I don't want its properties to change. Semilogx and friends (and, I just realized, polar, though I use that infrequently) seem to be the odd ones out. Of course, most everyone else has the option of simply using semilogx BEFORE calling hold on, whereas I have made it impossible for myself to do that.

Since I was shadowing the built-ins anyway, I also gave additional functionality to semilogx: when called with no inputs, it simply toggles the xscale property of the current axes. I use this functionality more frequently than using it to plot data directly.

Well, this has certainly been an enlightening day. Thanks for your help.

Tags for this Thread

No tags are associated with this thread.

What are tags?

A tag is like a keyword or category label associated with each thread. Tags make it easier for you to find threads of interest.

Anyone can tag a thread. Tags are public and visible to everyone.

Contact us