With Matlab’s latest release yesterday (R2011b, a.k.a. 7.13), once again I came across a few undocumented hickups. I have a plain-ol’ Win XP machine and hate to think what users of Macs/Linux (esp. Ubunto) need to go through in each installation. Perhaps the items below might alleviate some of the pain.
Note that on your system you may be unaffected by some or all of the issues below. All these issues have occurred for the past several Matlab installations, and are NOT unique to the new R2001b:
Bootstrap loader
Matlab uses a simple download_agent.jnlp file as its installer bootstrap loader. This is a very small (2KB) XML file that tells your Operating System’s Java runtime engine, which automatically runs JNLP files, which JAR files to download (yes, the basic loader is Java-based).
The hickup I encounter four times a year (two pre-releases and two production releases) is that at least on my system, FireFox downloads the file not as download_agent.jnlp but as download_agent. I cannot then run this file, since it has no file extension. Adding the .jnlp extension manually solves this issue.
Installer
Double-clicking the JNLP file then runs the JNLP using the OS’s JRE. After downloading the specified JARs, com.mathworks.agent.AgentGUI is invoked with a specified URL of another XML file. This second XML file actually contains the list of installer application file URL and some zip files that contain the actually installable files.
The hickup here is that the installer automatically downloads dozens of MB of Japanese-related materials (documentation, translation files etc.) that are irrelevant to me (as well as for most Matlab users). I have nothing against Japanese in general, I just hate my time, bandwidth and disk space being wasted in vain. I can’t do much regarding the first two, but at least I can delete the Japanese installer files after they have been downloaded: install_guide_ja_JP.pdf, archives/MATLAB713_doc_ja.zip, help/ja_JP etc.
Pre-release
Matlab’s installer is smart enough to automatically detect an existing pre-release installation of Matlab, and polite enough to ask me whether to overwrite that location or to install Matlab into a new folder. I often choose the later since I make changes to system files and I do not want them to be overwritten automatically. Unfortunately, the Matlab installer may be too smart: It installs Matlab onto the new folder but prevents running the old pre-release in parallel. In effect, it uninstalled my pre-release without physically removing the files. So while I can still see my modified files in the pre-release folders, I can no longer see them in action. This is a real shame.
A more pressing problem is that the new installation keeps the old Matlab path (which points to the pre-release folders), rather than to the new production folders. This can easily be fixed using pathtool or the main menu’s File / Set path…, but I am guessing that most users would not have easily noticed this issue.
Java
Matlab’s installer copies many user-generated preference files, but unfortunately not some files that are critical to using Java in Matlab, namely librarypath.txt and classpath.txt. I needed to manually copy my changes from the previous version onto the new version’s files.
You could say that this proves (yet again) the need to place librarypath.txt and classpath.txt in a user folder rather than modifying the system files. However, in some cases, particularly when, as in my case, there are numerous start-up folders for different projects, it is often easier and simpler to modify the central system files rather than using and maintaining numerous user copies.
A related issue is the installer’s failure to generate (and copy the contents) of the %matlabroot%/java/patch folder. This is a very important folder for java users in Matlab, since it is automatically included in Matlab’s static classpath (the aforementioned classpath.txt) and any class file placed in this folder will therefore be automatically recognized and available in all Matlab sessions without the need for calling javaaddpath (which has some serious drawbacks). I have a set of Java classes that I always use and the path folder is the perfect place for them. I just need to remember to copy this folder after each installation…
These minor woes behind us, we can start enjoying the new Matlab release. Here’s a candy from the new version: It is a built-in demo of what may be Matlab’s upcoming GUI capabilities, in this case a Toolstrip. I will explore it in detail in some later post:
>> com.mathworks.xwidgets.desktopexamples.ToolstripShowCase.main('') |
Thank you for sharing your experience!
Just in case you missed it:
(run line-by-line; beware, closing some of those windows shuts Matlab down)
One undocumented tip for people who are not afraid of changing things in the MATLAB installation directories is to create *.phl files for your MATLAB path additions. When you install a new version of MATLAB copy these phl files to $matlabroot$/toolbox/local/path. Then issue the MATLAB command restoredefaultpath followed by savepath and your additions will be included in the path. There is phl file for every toolbox you have installed to use as examples.
For what it’s worth, I have no trouble with the bootstrap loader in Chrome. I think it’s more of a Firefox issue.
Thanks again for checking/reporting the tweaks and fixes we need to get our Matlab running as we expect it to do.
This inspired me to share some rather general comments:
For people who need to update or reinstall Matlab frequently, it may be useful to create their own “checkinstall.m” script. Some of my toolboxes have such a checkinstall.m, mainly to check/fix missing or interfering path extensions, pathdef, classpath etc in case that the toolbox needs M-files, MEX-files or libraries elsewhere on the path, but also to setup/clear persistent and global variables and doing some set(0,’Default…’,stuff). However, I did not yet need a global checkinstall.m for Matlab itself, and I did never go so far and copy/move/delete or dynamically rewrite critical files on hard disk automatically (see, e.g., savepath.m, update_toolbox_cache.m). Since my checkinstall.m files are all highly project-specific, it would not make much sense to upload them anywhere. The point I want to make here is:
It can save lots of future work to copy+paste some code from matlabrc.m, hgrc.m, pathdef.m, classpath.txt and others, learn about the ressources used there, and remix all this to create your own checkinstall.m, init.m, startuser.m or whatever you may call it. Of course, one can also edit any toolbox/local/*.* file directly, at least if it does not make one mad to fix a dozen of core Matlab files manually twice a year, always taking care that nothing important gets lost. Hence, I would always try to fix setup issues by user/project specific path automation scripts which are executed only on demand.
Neverthesess, I always found it quite conclusive to load the matlabrc.m and alike functions into an editor and compare them with older versions. Changes in these functions may reveal more about new features than one would find in the official Matlab release notes.
Of course, the above recommendations are clearly a matter of personal taste, and some issues are definitely awkward to solve by purely project/toolbox specific scripting. But finally, although a manually or automatically patched Matlab installation may be much more convenient and performant on the programmer’s single-user machine, one should never forget that such tweaks can easily turn into severe flaws: (1) My M-code may possibly not run as intended on other systems; and I suppose most customers won’t like me to tell them that something is wrong with their Matlab/Java. (2) After pimping my Matlab, how could I even test whether my code is still suitable for other users?
I hope I made clear that I do not citicize but rather appreciate anybody who thoroughly investigates and understands post-installation issues, specifically those who know where fixes are mandatory, optional, or even dangerous. However, take care!
Yair – sorry for the grief you’ve had getting 11b up and running on your machine. I’ve poked around a bit, and can comment on a few of the issues you’ve mentioned:
Bootstrap loader: we’ve seen this issue occasionally, too. We’ve made sure that the development team knows that it’s still happening.
Installing Japanese doc: We are aware that this is unnecessary and hope to be able to address it to reduce download sizes/times for our users.
Running prerelease after installing general release: I’m not sure what issues you are finding here. Our installer doesn’t touch the existing prerelease installation when installing the general release. We do point the operating system to the latest release, so that shortcuts, add/remove programs, etc. find the latest release. You should be able to run the prerelease by running MATLAB.exe directly from the bin dir (or making a new shortcut to it).
path: I’m a bit puzzled about your path issue, too. We don’t migrate path from release to release (this is actually something I’d like to see changed), so the only way I see this happening is if you have your new MATLAB intentionally pointing to your old pathdef.m. The default locations for pathdef.m are in release-specific folders. I’m sure I’m missing something, so please clarify if I am.
@Michelle – Thanks for your follow-up. The items I listed above are a minor inconvenience rather than cause of actual grief… Perhaps the term “woes” in the title was an exaggeration. On the other hand, I rarely have a chance to use this term in day-to-day, and it had a nice ring to it, and article titles do need to attract the eye…
Anyway, running the pre-release exe directly from its bin folder doesn’t work. It’s the first thing I tried upon discovering that all my old Start-menu shortcuts have been deleted by the new R2011b installation. When you run the pre-release exe it simply launches the the new R2011b executable. I’m guessing that some important Windows registry key has been overwritten by the new installer. The bottom line is that while the PR is still “installed” on my computer, it cannot in fact be run. This is a moot point now, as the PR expiration date has now passed, but I think it should be investigated to determine whether there is any bug in there that could have a wider effect. For example, what happens when we get a service-pack release as last year? – will the original (“SP0”) not be accessible any longer? If so, this could be troublesome. Let the user decide if they want to overwrite the existing version or not. Matlab users are smart enough to design rockets and cars, surely they can manage this decision.
Path – I am not sure why this happened. Perhaps because of the pre-release vs. Prod versions mixup that caused the previous issue.
[…] I won’t bother repeating the list that I published here exactly one year ago […]
Thank you very much for posting this, am an elccarietl engineering student too n this solves just 1 of my problems. Before i applied this neat trick, matlab 7 wasn’t even opening on my manchine, now it opens n i get to see it briefly about 2 seconds then it closes itself. Am on an X64 AMD machine n i think that is the problem. Could you know of a work around to this? I’ll appreciate any help
@Valeria – there is no “silver bullet” for this problem. It could be due to many different reasons. I suggest that you contact support@mathworks.com