When I execute an application compiled using MATLAB Compiler 4.3 (R14SP3), how can I prevent personal information such as my MATLAB preferences information from being extracted?

Problem Description:

I have compiled an application ‘test’ using MATLAB Compiler 4.3 (R14SP3). Upon execution I noticed that a new folder gets created in the ‘test_mcr’ folder. This folder is named ‘test_‘.
Opening this folder revealed that some of the files were stored in my MATLAB preferences directory, including my MATLAB preferences file.
I want to know if there is any way to avoid the creation of this directory when my application executes.

Solution:

It is not possible to avoid having MATLAB Compiler include the preferences directory in each compiled application. The Compiler includes the user’s preference information because the application may rely on it. There are two possible workarounds:
1) On UNIX, use SETENV and the ! operator to compile. For example:

!setenv MATLAB_PREFDIR /tmp/emptydir;
mcc -Nmgv test

On Windows, open a DOS command window and execute

set -- USERPROFILE = C:\Temp\emptydir

Start MATLAB from this DOS prompt (to use the appropriate environment variable in the MATLAB session) and execute the MCC command at the MATLAB command prompt.
Note: If you are using MATLAB Compiler 4.4 (R2006a) you can also use the SETENV function at the MATLAB command prompt

setenv('-- USERPROFILE','C:\Temp\emptydir');
mcc -Nmgv test

This temporarily sets the preference directory to /tmp/emptydir or C:\Temp\emptydir, and the compiled application will therefore only have the default settings (or the preference directory settings from your installation of MATLAB 7.0.4 (R14SP2)).
2) Move the contents of the preference directory, or rename the directory, before compilation, and restore afterwards. To do this on Windows, for example, execute the following command to compile the function test.m:

mymcc -m test.m

The code of the function mymcc is:

function mymcc(varargin)
% MYMCC does the same as MCC. The only difference is that the created
% application doesn't contain information of the MATLAB
% prefdir anymore.
%
% For the description of possible options please look at the help of
% the command MCC.
command = 'mcc ';
for i = 1 : length(varargin)
   command = [command,varargin{i},' '];
end
a = prefdir;
b = regexp(a,'\','start');
c = a(b(end)+1:end);
p = cd;
cd(prefdir)
cd ..
!md tmp
cd(prefdir)
!move * ../tmp
cd(p)
% Because of the displacement MATLAB cannot access the saved preferences
% and that's why you have to indicate each time, which compiler shall be used.
try
   eval(command);
catch
   warning('WarnTests:Warning', ...
           'Calling mcc causes Error. Please check your input arguments.\n No file was compiled ...\n')
end
cd(prefdir)
cd ..
cd tmp
eval(['!move * ../',c]);
cd ..
!rmdir tmp
cd(p);

A similar function could also be written for the UNIX platform.
Note that the above workaround is not officially supported by MathWorks.

Related Solutions:

Why are my preference files included in my stand-alone application created with MATLAB Compiler 4.9 (R2008b)?
Problem Description:
If I look in the cache folder that my compiled application creates, I can see that the .matlab folder contains my preference files with my last development activities in plain text. The files are: cwdhistory.m, history.m, matlab.prf, MATLAB_Editor_State.xml, etc. How can I avoid the inclusion of these files in the stand-alone application?
Solution:
The stand-alone does not include your preference files. You can see the preference files in the cache folder because you are running the stand-alone in your development environment. At runtime, the stand-alone determines those preferences from a local MATLAB installation and copies them to the cache folder for it’s own use. If you run your stand-alone application on a machine without a MATLAB installation, you will see that the cache folder does not contain your preference files.

The post Removing user preferences from deployed apps appeared first on Undocumented Matlab.

In case that the first columns of your Excel table have only numeric numbers, then the command [num,txt] = xlsread(...) returned in older Matlab releases for txt a cell array with blanks in the corresponding columns. In Release 2012b [sic – should be R2012a] these columns are missing at all. This has the consequence that column numbers must be changed if you read from cell array txt.
This caused some trouble in our code and I want to forward this warning to other users.

For example, let’s take the following simple Excel data file:

>> [num,txt] = xlsread('test.xls')
num =
     1   NaN    10
     2   NaN   NaN
     3   NaN    30
     4   NaN   NaN
txt =
    ''    'a'    ''
    ''    'b'    'B'
    ''    'c'    ''
    ''    'd'    'D'

>> [num,txt] = xlsread('test.xls')
num =
     1   NaN    10
     2   NaN   NaN
     3   NaN    30
     4   NaN   NaN
txt =
    'a'    ''
    'b'    'B'
    'c'    ''
    'd'    'D'

The response from Mathworks (1-K21ZFE) was:

It is certainly true that there is an inconsistency. If you use the syntax:

[num, txt] = xlsread('DeleteMe.xls','Sheet1','','basic');

you obtain the same outputs dimension as in the previous releases. Our documentation was not updated with the change of behavior in xlsread.

Note: the sheet-name is optional – you can specify '' (an empty string) instead of 'Sheet1'.
Unfortunately, this workaround leaves much to be desired.
The problem here is not only the missing documentation about the change in functionality. This is actually the lesser of the problems. The main issue is backward compatibility. A major function such as xlsread, which is widely used by numerous Matlab users and has remained stable for years, can not – MUST NOT! – change existing functionality, with or without proper documentation. Numerous Matlab programs rely on the existing functionality and behavior of xlsread. MathWorks cannot seriously expect thousands of Matlab users to change all their existing Matlab programs when upgrading to R2012a. And what if the program needs to work on both R2012a AND earlier Matlab releases, which do not accept the ‘basic’ input parameter? Or what if we need to use a range sub-set, which is unavailable in ‘basic’ mode? Adding insult to injury, this change was never documented in the release notes, nor in xlsread‘s doc page.
This tells us not to rely on the official release notes when deciding whether or not to upgrade. It causes such a maintenance headache that many users would simply prefer to remain with their older Matlab release, and not to upgrade. A real shame.
As an alternative to the official workaround above, I suggest modifying the %matlabroot%/toolbox/matlab/iofun/private/xlsreadSplitNumericAndText.m function, which is responsible for the functionality change. Specifically, comment line #45:

43:    % Trim the leading and trailing empties from textData
44:    emptyTextMask = cellfun('isempty', textData);
45:    %textData = filterDataUsingMask(textData, emptyTextMask);    % Comment out this line!

This will restore the previous functionality in one go, without having to modify any user programs. Of course, we would need to redo this fix in every future Matlab release as well. Still, considering the alternatives, this appears to be the best choice in my eyes.
While the case with xlsread seems to break a new record in backward-incompatibility, other similar cases have also been reported. One such recent issue was raised over the [this-time] documented removal of some functionality in the widely-used interp1 function. No fewer than 54 comments (and counting) were added within a few days of the initial CSSM post, which indicates the amount of frustration that such changes cause.
Looks like some people may have forgotten the first rule and top commandment of engineering:

The post xlsread functionality change in R2012a appeared first on Undocumented Matlab.

The problem

This change in itself is actually a good idea, but what is absolutely disastrous (IMHO) is the fact that MathWorks have not bothered to link all the old URLs to the new ones. Most serious websites that have tons of links floating around for a decade or two, as in this case, take the trouble to automatically redirect old URLs to the new ones in the server side. This was the case, for example, when Oracle took over Sun a couple of years ago and redirected the Java links. So did Microsoft in their online MSDN. Neither Oracle nor Microsoft redirected all the URLs perfectly, but they made a pretty good effort. Not in Matlab’s case, unfortunately.
It seems that only the basic function reference pages have been redirected, not any of the other doc pages. Tons of links, many of them in MathWorks webpages themselves, are now broken and lead to a generic “page not found” webpage. This includes many thousands of links referenced by loyal community users in response to queries in the Matlab CSSM newsgroup (in the past ~15 years) and MathWork’s own Answers forum (past 1.5 years), not to mention numerous references in books, reports, websites and other resources. These links are now broken. Users who use them will end up in page-not-found. How user-friendly would this be for them? How likely do you think they would use the newsgroup/forum again, as opposed to flooding MathWorks customer support with simple questions that have already been answered online, only to be rendered unusable by an SEO fix that should have been fully transparent?! How likely do you think that loyal CSSM/Answers contributors would post MathWorks links again?! This is about as self-defeating a release as I have seen in a very long time.
In the past, I have highlighted changes to the online documentation center that I found useful. These included the addition of historical documentation archives, and the plot gallery. But today I must say that IMHO the latest change to the doc center should never have gone live, and I fail to understand how it could ever have passed internal QA. Furthermore, I cannot understand why this is still not fixed, a month after the official release.
I don’t believe that I have ever used such strong language in the 3.5 years that this blog has been live, and I do this very reluctantly now. Hopefully my call for action will be heeded (soon!).

So what can be done?

MathWorks can and should correct this problem by adding the server-side redirects, which is typically accompanied by an HTTP 301 Moved Permanently response to the requesting browser. In fact, doing this is also good for SEO, since all the tons of old links will be counted by search engines as directing to the new pages, thereby adding incoming page-rank “juice” to them. Here’s Google’s advise on this matter.
Doing these redirects does not require a Matlab release and can be done immediately and incrementally. Granted it’s not a simple task, given the huge number of URLs involved, but the sooner MathWorks start, the faster they’ll finish. Frankly, they should have thought about it in advance… I have a hunch that the servers’ HTTP 404 (Page Not Found) list has exploded since the latest release. I would suggest going through this list, sorted down by number of occurrences, so that the most frequently-accessed webpages are fixed first.
Until the URLs are restored or redirected, we can try the following workaround:

1. First try the URL directly (e.g., http://www.mathworks.com/help/techdoc/creating_guis/f16-999606.html) – who knows, maybe it will work by the time you try using it…
2. If the URL that doesn’t work, try to add releases/R2012a/ following the “help/” term in the URL. In our example: http://www.mathworks.com/help/releases/R2012a/techdoc/creating_guis/f16-999606.html. If successful, jump to step #4 below.
3. If the URL is still not found, enter it into the Way-Back Machine in the following format: http://wayback.archive.org/web/*/<URL>. For example: http://wayback.archive.org/web/*/http://www.mathworks.com/help/techdoc/creating_guis/f16-999606.html
   If we’re lucky, the Way-Back archive has at least one archived copy of the requested webpage. This also happens to be the case in this specific instance:
   

   

   Click the highlighted date (when an archive copy was taken) to see our requested webpage in all its past glory. We are not assured that it is the latest version of the webpage, but this is ok for now.
4. If all you need is to read the contents of the doc page, then you can stop here. But if you also wish to get the new URL (in its R2012b SEO format), then read on:
5. Copy a long distinctive sentence from the webpage content in to the clipboard; paste into Google within “” (quotation marks) and add the term “site:mathworks.com”. In our case, let’s take “A callback is a function that you write and associate with a specific component in the GUI“. Here is the corresponding Google query: site:mathworks.com “A callback is a function that you write and associate with a specific component in the GUI”.
6. If we are lucky again, Google should turn up the new webpage and by navigating there we should (finally!) get the new URL. In this case, the requested URL is the top answer: http://www.mathworks.com/help/matlab/creating_guis/writing-code-for-callbacks.html
7. Sometimes Google fails to find the sentence in the Mathworks.com website. This can be due to text changes that MathWorks do in their doc pages from time to time. Don’t give up – try a different sentence from the archived webpage, maybe it will show up instead. You can also try to enter the page title as the distinctive sentence. There is a good chance that at least one of these will work. In our specific example, MathWorks changed the title from “Writing Code for Callbacks” to “Write Code for Callbacks” in R2011b (after the Way-Back Machine archived the page). Luckily, the title query still manages to find the new page in this specific case (good ol’ dependable Google!).
8. Any of the above may fail, typically because the Way-Back archive did not archive the specific page we need, or because MathWorks changed the page contents too much. In such a case, too bad for us… In this case, I suggest you email MathWorks to ask for the new URL.

Followups

Vociferous complaints over the new documentation system in R2012a have been heard loud and clear at MathWorks. Wendy Fullam, Matlab’s documentation product manager, has made a point to make it clear that MathWorks is not ignoring these out-of-the-ordinary complaints and will indeed improve the documentation accordingly. Wendy also responded to my SEO complaint, saying that they will indeed try to fix the URL redirects:

However some pages have not been redirected for various reasons. Given feedback like this, we are looking into creating more redirects as soon as possible.

I’m holding my fingers that they will indeed fix this issue, not just for some URLs (as the quote above seems to indicate) but for all of them. MathWorks’ quick and serious response to the complaints on R2012b make me optimistic that there is indeed a good chance that this will be resolved soon. I’ll be following up on this issue in the upcoming months, and will be most happy to post an update here if and when this issue is fully resolved as it should be, on the MathWorks server side.
Addendum Oct 14, 2012 (that was quick!): Wendy Fullam has posted the following comment on the relevant CSSM thread (snipped for brevity):

In response to customer feedback, MathWorks is deploying an additional 700 redirects for documentation URLs.
When combined with the redirects already deployed (for reference pages, landing pages, installation sections, and release notes), we will be redirecting roughly 70% of R2012a documentation URLs to updated page locations.
We will also continue to monitor “page not found” reports, and establish additional redirects as needed.
Additionally, I’d like to note that the discussion has been incredibly insightful in helping the documentation team establish future direction. Customers noted that the doc appears to have undergone a change in organization and have speculated on the motivation. While SEO was part of our motivation (we think it’s a big step in having URLs provide an indication of page focus), we are also working towards serving up information to support common customer workflows. … I want to encourage you all to continue to share experiences and requests for missing information, so our documentation team can continue to expand and improve our content.

Addendum Nov 19, 2012: Looks like the http://www.mathworks.com/help/techdoc/creating_guis/f16-999606.html link is alive again, or rather redirected to the new location which is great. I hope this means that the redirection effort mentioned by Wendy above has finally occured. Thanks Wendy (and all the nameless others behind the scenes)!

The post Changes in the online doc URLs appeared first on Undocumented Matlab.

The post Docs of old Matlab releases appeared first on Undocumented Matlab.