Back to the main page.

Bug 1231 - what's the intended output of ft_getopt({'rpt' []}, 'rpt', 'all')?

Reported 2011-12-13 17:27:00 +0100
Modified 2012-01-10 13:04:21 +0100
Product: FieldTrip
Component: core
Version: unspecified
Hardware: PC
Operating System: Mac OS
Importance: P3 normal
Assigned to: Eelke Spaak
Depends on: 1237
See also:

Jan-Mathijs Schoffelen - 2011-12-13 17:27:43 +0100

I would expect [], but the output is 'all'. Discuss with Robert and or in FT-meeting

Robert Oostenveld - 2011-12-14 10:48:10 +0100

according to test_ft_getopt, it would be 'all'. See cfg = []; cfg.key1 = []; success = success && isequal(ft_getopt(cfg, 'key1'), []); success = success && isequal(ft_getopt(cfg, 'key1', 'default'), 'default'); Let's indeed discuss.

Robert Oostenveld - 2011-12-14 13:32:00 +0100

the issue is that here [] has a meaning whereas throughout much of the code, [] is treated as being not defined. we could add a fourth input to ft_getopt to overrule the default behavior (of defaulting to the default) and return the meaningful [] in case it is present.

Eelke Spaak - 2011-12-20 14:50:11 +0100

bash-3.2$ svn commit Sending src/ft_getopt.mexa64 Sending src/ft_getopt.mexw32 Sending src/ft_getopt.mexw64 Sending test/test_ft_getopt.m Sending utilities/ft_getopt.m Transmitting file data ..... Committed revision 5055. Added functionality: % The optional fourth argument allows you to specify whether % or not an empty value in the configuration structure/cell array should be % interpreted as meaningful. If emptymeaningful = 1, then an empty % configuration option will be returned if present. If emptymeaningful = 0, % then the specified default will be returned if an empty value is % encountered. The default value for emptymeaningful = 0. Note that the MEX-files have NOT been compiled for Mac, I only added Win32, Win64, and Linux64 versions. Given that the fourth argument is not yet used, this seemed safe to commit to me.

Craig Richter - 2011-12-20 14:55:08 +0100

What needs to be done for a mac compilation? Us mac users need it! I'm naive to .mex production, but I can compile from source and upload if this is all that is entailed.

Jan-Mathijs Schoffelen - 2011-12-20 14:57:40 +0100

I just compiled it, do an svn update and it should appear (at least for MacOS 64-bit, 32-bit will follow shortly PS: you can do it yourself by running the ft_compile_mex function

Eelke Spaak - 2011-12-20 15:01:06 +0100

Thanks, Craig! But apparently JM is already on it. @JM: ft_compile_mex only compiles mexfiles for the platform from which it is called, right? So if I run it on, say, Linux64, I only get .mexa64 files I think?

Jan-Mathijs Schoffelen - 2011-12-20 15:02:01 +0100

yep, so that's why I am now running it on my Mac ;-) (both with a 32 and 64 bit Matlab)

Jan-Mathijs Schoffelen - 2011-12-20 15:03:39 +0100

updated on revision 5057

Boris Reuderink - 2012-01-03 15:28:36 +0100

(In reply to comment #3) I think this fix caused bug 1237...

Eelke Spaak - 2012-01-09 11:30:45 +0100

(In reply to comment #9) No it didn't, the problem with the 'Access denied' mex-files already existed before I committed the fix.

Boris Reuderink - 2012-01-10 13:04:21 +0100

Ok, great. Then I change this bug's status to CLOSED.