Back to the main page.

Bug 1762 - config object fails on struct-array

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
Depends on:
See also:

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},; 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.

Robert Oostenveld - 2015-02-11 10:40:40 +0100

Closed several bugs that were recently resolved. Please reopen if you are not happy with the resolution.