We (Apple developers) run the latest Mac OS (10.10.2 as of 3/27/2015) with the latest version of Matlab (8.5) or (Linux developers) Ubuntu 64-bit (Gutsy) and 32-bit (Feisty) with Matlab 7.4 and the binaries are created to run on these systems. As noted above, some older versions (notably Matlab 14.1) are not able to use these mex files and crash when you try to run mglOpen. If this happens, then all you need to do is recompile MGL using mglMake(1). You may also have to make sure that you link to the correct version of the Mac OS X system frameworks.
The Matlab license manager checks every 30 seconds for the license. This can cause there to be an apparent frame glitch in your stimulus code, especially if you are using a network license (on our machines it can take ~200 ms to check for the license). The only known workaround to this is to run on a machine that has a local copy of the license. You can check this for yourself by seeing how long it takes to do screen refreshes:
mglOpen; global MGL; checkTime = 30*MGL.frameRate; timeTaken = zeros(1,checkTime); mglFlush; for i = 1:checkTime flushStart = mglGetSecs; mglFlush; timeTaken(i) = mglGetSecs(flushStart); end mglClose; plot((1:checkTime)/MGL.frameRate,timeTaken); zoom on;xlabel('seconds');ylabel('Frame refresh time (seconds)');
If you have the same problem, you should see one large spike in the time course like this:
This one shows it taking about 65 ms. Note that you may see small deviations in which one frame takes longer and then the following frame takes shorter than the mean. These are normal flucations persumably due to multi-tasking and other events that are intermittently taking up time. As long as these are shorter than a frame refresh interval minus the time it takes you to process the stimuli for your display, you will not drop any frames. Note that in the above code, if you change mglFlush to any other command, such as WaitSecs(1/frameRate);, you will still see the big spike for the license manager check–confirming that this has nothing to do with drawing to the screen.
If you are trying to compile on Mac OS X and are running into problems, you may not be linking against the proper systems libraries. We typically (as of 3/27/2015) are compiling against Mac OS X 10.10.2 SDK, but you may need an earlier or later version of the Mac OS X SDK's. We have updated mglMake so that it does some basic checks and uses different mexopts.sh files for different operating systems (i.e. can either compile with 10.10.2 SDK or 10.8 SDK, etc), but if this fails for your system you may want to try to go in by hand and change the mexopts.sh file yourself to link against the appropriate SDK. To do so, for example, for 10.5:
In later SDKs, (e.g. SDK=10.13), you can also compile MGL using clang rather than the default c compiler, by:
optf = sprintf('-f %s',fullfile(fileparts(which('mglOpen')),'clang_maci64.xml'));
<dirExists name="$$/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk" /> <cmdReturns name="find $$ -name MacOSX10.13.sdk" />
If you have problems updating with SVN because you have changed files, you might be running into file or tree conflicts. See here for more info.
I have run into some unresolvable conflicts with the following error:
svn: GET of '/svn/mgl/!svn/bc/946/trunk/mgllib/mglEyelink/mglPrivateEyelinkReadEDF.c': Could not read response body: connection was closed by server (http://gru.brain.riken.jp)
You may try to svn checkout the whole repository again (remember to make a copy of your current repository and then copy back the files you have changed). It seems that this can be caused by Apache timing out for long updates, but that doesn't seem to be the reason why we are getting that (we have set out timeout very long and this happens for single files and always at the same place in certain revisions). I suspect that it is some problem with the Mac Apache svn/PHP module, but have not been able to figure it out. A workaround is to use svn+ssh for accessing the repository, but this is only for developers who have an account on our server gru.brain.riken.jp (email to justin if you think you need this). Also, if someone knows what the problem is and can provide a fix, let us know.
Note that only version 1.5 supports linux, version 2.0 and beyond do not have linux support at the moment (actually could be supported with a little bit of work, if someone is interested in putting in the effort).
The list of funcitons not supported yet on linux for version 1.5 are:
If you want to use text under the linux operating system, you can use mglStrokeText.
Here is a more recent update from Jonas about the Linux version:
I am in the process of upgrading the Linux version of MGL to run under Ubuntu (64-bit and 32-bit) with NVIDIA and ATI graphics cards. Although the upgrade is still incomplete, most functions work equally well under Linux at this stage. Some differences that will remain between the platforms are listed below.
For the time being, only NVIDIA and ATI cards will be supported (because I only have access to those two machines).