Back to the main page.
Bug 1231 - what's the intended output of ft_getopt({'rpt' []}, 'rpt', 'all')?
| Status | CLOSED FIXED |
| 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 |
| URL: | |
| Tags: | |
| Depends on: | 1237 |
| Blocks: | |
| 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.