Back to the main page.
Bug 1762 - config object fails on struct-array
| Status | CLOSED FIXED |
| Reported | 2012-10-02 18:28:00 +0200 |
| Modified | 2015-02-11 10:40:40 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P5 minor |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=1614 |
Robert Oostenveld - 2012-10-02 18:28:54 +0200
a = [] a(1).field = 1 a(2).field = 2 [a.field] % this works b = config(a) [b.field] % this fails with ??? Error using ==> config.subsref Too many output arguments. -------- the config object should behave exactly like a structure, but apparently it does not. This has consequences for ft_megplanar line 260, which does [neighbsel] = match_str({cfg.neighbours.label}, cfg.channel); I noticed this when testing bug 2 with cfg.trackconfig = 'report'. The problem itself is not related to bug 2 or ft_megplanar and might also occur elsewhere. -------- the workaround is not to use trackconfig.
Roemer van der Meij - 2012-10-02 21:03:19 +0200
I ran into this sometime ago as well with ft_multiplotER, in bug 1614. This time related to subasgn for cfg objects. Maybe they are related?
Roemer van der Meij - 2012-11-09 16:17:27 +0100
I spent a few hours getting to know the object and (mostly) how subsref works, and passes along arguments of various sorts. I added some test-code to the bottom of @config/subsref.m. It should work in all circumstances I think, but there is one thing that isn't working properly, related to how matlab determines the nargout, and (I think) get's lost in recursive functions. Request a field from all structures using a.field VS a(:).field: >>a.field ans = 1 ans = 2 >> a(:).field ans = 1 ans = 2 These should be identical for b using the test-code, however: >> b.field ans = 1 ans = 2 >> b(:).field ans = 1 In the first call, i.e. x.fieldname, matlab determines that nargout = 2. In the second case, it determines that nargout = 0 (i.e. no output defined). Doing [tmp1 tmp2] = b(:).field yields the expected output. How matlab determines nargout before running any of the function-code (easily checked by placing a nargout at places), I do not know. Maybe matlab does some very simple parsing of the input and the code during/after compilation, and the recursiveness is too difficult for it? I do not know. How matlab can be influenced in this I also do not know ;). Any two you have an idea?
Jan-Mathijs Schoffelen - 2014-01-23 14:50:01 +0100
I stumbled on this issue again today, and it took me a while to remember that it already exists as a bug. The workaround at the moment indeed is to use cfg.trackconfig = 'no', or to explicitly convert a potential config object into a struct. Would a solution lie in the non-recursive config'ification of a cfg-structure in the first place? I.e. do not convert the cfg-fields that are struct(-array)s into a config object?
Robert Oostenveld - 2014-07-20 14:33:02 +0200
The specifically reported problems are now resolved. There is still a known incompatibility, which is flagged as warning (not error) in the test script. mac011> svn commit \@config/* test/test_config.m Sending @config/private/get.m Sending @config/subsasgn.m Sending @config/subsref.m Adding test/test_config.m Transmitting file data .... Committed revision 9747.