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:
BUG in deployement with CD and function handle ?

Subject: BUG in deployement with CD and function handle ?

From: Bruno Luong

Date: 23 Apr, 2013 19:01:09

Message: 1 of 5

I have a code that I use for deployment. I use CD command to select what kind processing. This code is deployed using the compiler. It works well with the old compiler 2006B.

Recently I upgrade the compiler to 2013, and some nasty thing is going on with CD command, and uniquely when deploying with the compiler. To illustrate it I have a minima example at the end of this post.

I read Loren's article
http://blogs.mathworks.com/loren/2008/08/11/path-management-in-deployed-applications/
in 2008, where it mentions:
[
cd
Try to avoid using the cd command in deployed applications because it creates implicit dependencies between the application and the structure of the file system. If the machine running the application does not meet these requirements, the application will fail in confusing ways. ]

I'm not sure I fully understand that, and how official is this recommendation, and whereas what I observe is a bug or a feature.

One thing I know is the architecture of my code is heavily relies on CD command to do the work. Can anyone comment and suggest a work around?

% Example code
function foo(varargin)
% function foo(varargin)
% > mcc -C -m foo.m -a subfolder/subfun.m
% Minima example to illustrate a BUG that occurs
% in compiler deployment (2013A, Win64) when using cd + and FEVAL function handle

% Path where subfun is located
if isdeployed()
    locpath = [ctfroot() filesep() 'subfolder'];
else
    locpath = fileparts(mfilename('fullpath'));
end
%%
% Work if SUBFUN call #1 is disabled and CD call is disabled
% Work if SUBFUN call #1 is enabled and CD call is disabled
% Work if SUBFUN call #1 is enabled and CD call is enabled
% Fail if SUBFUN call #1 is disabled and CD call is enabled, in deployment mode
%subfun(1); % subfun call
cd(locpath); % cd call

try
    % call dummy(2) using FEVAL
    feval(@subfun, 2);
catch
    % This will printed only if subfun call is disabled, and cd call is enabled
    fprintf('feval with function handle fails\n');
end

end % foo

%%
function subfun( n )
% subfun( n )
% A dummy function located in subfolder/subfun
fprintf('subfun call #%d\n', n);
end % subfun

% Bruno

Subject: BUG in deployement with CD and function handle ?

From: Bruno Luong

Date: 24 Apr, 2013 15:06:09

Message: 2 of 5

I have submitted a BUG report and already get a feedback from TMW. I don't think they can do anything for me. Here are few points of the reply:

1) They refer to the same Loren's blog page I post earlier as if it is a reference guideline. Are the users supposed to be aware about what written on various blogs on the intenet? I must admit that I don't visit them a lot, even if some of them are very good.

2) They again write "Please note that using the CD command in deployed applications creates implicit dependencies between the application and the structure of the file system. If the machine running the application does not meet these requirements, the application will fail in confusing ways." What does that means exactly? By what miracles it is working on Compiler that come with V2006B? I appreciate to keep posted, but do we (users) suppose to know the implicit dependencies to the file system of deployed application? I only expect calling a simple function works regardless where is my current path.

3) They write "We are aware of this behaviour and we normally strongly suggest that you never use CD in deployed applications.". How could be a fundamental OS command such as CD is prohibited? My code is complex GUI. Users suppose to navigate on the tree structure that we define in the application. Now we are told that changing directory is not possible?

4) They said "In the example you provided, you certainly do not need to CD into the subfolder in order to call that function.". This is true, but I need CD for other purpose, notably using shadowing mechanism, which is also does not compliance with the official doc in deployed mode.

http://www.mathworks.com/matlabcentral/newsreader/view_thread/328551#903082

How can we do to accomplish it?

I'll see how is the official answer to the BUG report on this second issue too. I don't expect much my issue will be resolved.

Bruno

Subject: BUG in deployement with CD and function handle ?

From: Bruno Luong

Date: 27 Apr, 2013 09:43:09

Message: 3 of 5

> 3) They write "We are aware of this behaviour and we normally strongly suggest that you never use CD in deployed applications.". How could be a fundamental OS command such as CD is prohibited? My code is complex GUI. Users suppose to navigate on the tree structure that we define in the application. Now we are told that changing directory is not possible?
>

I confirm that deployed applications have to stuck forever with the default folder. Any CD command will call for trouble.

I expect any application (MATLAB or otherwise) should be able to change its current directory during its run.

This limitation was not in older MATLAB compiler, e.g, the one that come in 2006B.

What's a pity.

I would like to suggest TMW to consider to remove this limitation in the next release of the compiler. (I also ready write them officially in the log of the bug).

Bruno

Subject: BUG in deployement with CD and function handle ?

From: Steven_Lord

Date: 29 Apr, 2013 18:38:30

Message: 4 of 5



"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message
news:klg6jd$jfv$1@newscl01ah.mathworks.com...
>> 3) They write "We are aware of this behaviour and we normally strongly
>> suggest that you never use CD in deployed applications.". How could be a
>> fundamental OS command such as CD is prohibited? My code is complex GUI.
>> Users suppose to navigate on the tree structure that we define in the
>> application. Now we are told that changing directory is not possible?
>>
>
> I confirm that deployed applications have to stuck forever with the
> default folder. Any CD command will call for trouble.

http://www.mathworks.com/help/compiler/writing-deployable-matlab-code.html#bsf4min

> I expect any application (MATLAB or otherwise) should be able to change
> its current directory during its run.

If I understand your description of what you're trying to do correctly, I'd
be very wary about doing this in a NON-deployed application much less trying
it in a deployed application. What guarantee do you have that none of the
functions that you call CD around internally, leaving you in an unexpected
directory? [Been there, done that, had the "fun" of debugging it.] If you
are the only person who ever modifies them, and those functions don't call
user-specified code, you may be able to. But I'm guessing that's not the
case and so you could end up shooting yourself in the foot very easily by
calling a different function than you think you're calling. And do you guard
against your function throwing an error and leaving you in a directory other
than the one where you started?

Instead of trying to CD around, you could make the functions that you are
trying to distinguish methods of different objects and pass a dummy instance
of those objects into the method to select one or the other. I believe this
is an example of the strategy or policy pattern.

https://en.wikipedia.org/wiki/Strategy_pattern

classdef path1
    methods
        function y = method1(~, x)
            disp('Inside method1 of path1');
            y = sin(x);
        end
    end
end

classdef path2
    methods
        function y = method1(~, x)
            disp('Inside method1 of path2');
            y = cos(x);
        end
    end
end

method1(path1, 1:10)
method1(path2, 1:10)

% or

n = 2;
% Call path2's (default) constructor with 0 inputs
whichmethod = feval(sprintf('path%d', n));
% Call path2's method1 method
method1(whichmethod, 1:10)

> This limitation was not in older MATLAB compiler, e.g, the one that come
> in 2006B.

That older version of MATLAB Compiler was not able to compile many things
that the newer versions of MATLAB Compiler can compile.

> What's a pity.
>
> I would like to suggest TMW to consider to remove this limitation in the
> next release of the compiler. (I also ready write them officially in the
> log of the bug).
>
> Bruno

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Subject: BUG in deployement with CD and function handle ?

From: Bruno Luong

Date: 29 Apr, 2013 21:17:17

Message: 5 of 5

"Steven_Lord" <slord@mathworks.com> wrote in message <klmen7$3rf$1@newscl01ah.mathworks.com>...

>
> If I understand your description of what you're trying to do correctly, I'd
> be very wary about doing this in a NON-deployed application much less trying
> it in a deployed application. What guarantee do you have that none of the
> functions that you call CD around internally, leaving you in an unexpected
> directory? [Been there, done that, had the "fun" of debugging it.] If you
> are the only person who ever modifies them, and those functions don't call
> user-specified code, you may be able to. But I'm guessing that's not the
> case and so you could end up shooting yourself in the foot very easily by
> calling a different function than you think you're calling. And do you guard
> against your function throwing an error and leaving you in a directory other
> than the one where you started?

The code is developed/modified/maintained until recently by no less than 5 programmers and not only by my-self. The CD command are not done manually, but controlled by some sort of engine. This is how our SW is architectured, it allows flexible selection of algorithms and deploying any subset algorithms to our will. We have done it since 8 years and we don't encounter any of the maintenance problem you have stated Steve.

Some recommendations you state can be indeed suggested for inexperienced programmers. But we are no longer that naive to get caught by the mistakes you mentioned earlier Steve.

>
> Instead of trying to CD around, you could make the functions that you are
> trying to distinguish methods of different objects and pass a dummy instance
> of those objects into the method to select one or the other. I believe this
> is an example of the strategy or policy pattern.
>
> https://en.wikipedia.org/wiki/Strategy_pattern
>
> classdef path1
> methods
> function y = method1(~, x)
> disp('Inside method1 of path1');
> y = sin(x);
> end
> end
> end
>
> classdef path2
> methods
> function y = method1(~, x)
> disp('Inside method1 of path2');
> y = cos(x);
> end
> end
> end
>
> method1(path1, 1:10)
> method1(path2, 1:10)
>
> % or
>
> n = 2;
> % Call path2's (default) constructor with 0 inputs
> whichmethod = feval(sprintf('path%d', n));
> % Call path2's method1 method
> method1(whichmethod, 1:10)

Interesting use of OOP. But no thanks, the code supposes to process realtime data at high acquisition/processing rate, and no way we can afford to waste too much running time by using OOP.

>
> > This limitation was not in older MATLAB compiler, e.g, the one that come
> > in 2006B.
>
> That older version of MATLAB Compiler was not able to compile many things
> that the newer versions of MATLAB Compiler can compile.

Probably. But my goal is simply carrying out the portage of our code to a new compiler. So far I bump into huge obstacles than any visible advantage.

So specifically in which case the compiler is not able to produce deployed code that can run independently of the current the directory?

I told to my non-matlab SW colleagues what I have been through with this story, they think it i insane that a simple directory change is even not allowed by the compiler (regardless the shadowing issue, since a simple feval() call with a suposingly known function handle will fail).

In any case we already start the process of changing our code to cope with the new compiler 8.1. It will cost us weeks of work.

My final world is that I hope that TMW will still consider one minor user's opinion and do something to remedy it. Please.

Bruno

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