Back to the main page.
Bug 1614 - ft_default.trackconfig = 'report' results in obscure low-lvl cfg-object error when plotting interactively in ft_multiplotTFR
| Status | CLOSED FIXED |
| Reported | 2012-07-19 14:22:00 +0200 |
| Modified | 2015-02-11 10:39:59 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Linux |
| Importance: | P3 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fcdonders.nl/show_bug.cgi?id=1762 |
Roemer van der Meij - 2012-07-19 14:22:05 +0200
When ft_default.trackconfig = 'report' and When selecting interactively what to plot next after calling ft_multiplotTFR, I get the series of errors posted below (even though the new plot is actually made correctly, I think). But, only when baselining is requested(!). Note, the baselining part could simple be because another level of nesting is requested in the 'output cfg', and maybe has nothing to do with baselining itself. This can be replicated by using the frequency data from test_tutorial_timefrequencyanalysis.m, and calling: global ft_default ft_default.trackconfig = 'report'; cfg = []; cfg.baseline = [-0.5 -0.1]; cfg.baselinetype = 'absolute'; cfg.layout = 'CTF151.lay'; cfg.interactive = 'yes'; ft_multiplotTFR(cfg, TFRhann); ************ the call to "ft_multiplotTFR" took 1 seconds and an estimated 0 MB selected cfg.channel = {'MLC12', 'MLC13', 'MLC14', 'MLC21', 'MLC22', 'MLC23', 'MLC31', 'MLF33', 'MLF34', 'MLF42', 'MLF43', 'MLF44', 'MLF45', 'MLF51', 'MLF52', 'MLT12', 'MLT13', 'MLT22', 'MLT23', 'MLT32', 'MLT41', 'MLT42'} the call to "ft_singleplotTFR" took 0 seconds and an estimated 0 MB Error using config/subsasgn (line 10) Cell contents reference from a non-cell array object. Error in config/subsasgn (line 35) y2 = subsasgn(y1, index(2:end), val); Error in ft_postamble_previous (line 44) cfg.previous{cnt} = tmpvar.cfg; Error in ft_postamble (line 54) evalin('caller', ['ft_postamble_' cmd]); Error in ft_singleplotTFR (line 521) ft_postamble previous data Error in ft_multiplotTFR>select_singleplotTFR (line 709) ft_singleplotTFR(cfg, varargin{:}); Error in ft_select_channel>select_channel_multiple (line 148) feval(funhandle, label, funargs{:}); Error in ft_select_range>evalCallback (line 236) feval(funhandle, val, funargs{:}); Error in ft_select_range (line 97) evalCallback(callback, userData.range); Error while evaluating figure WindowButtonDownFcn ************
Jan-Mathijs Schoffelen - 2012-11-07 13:58:26 +0100
This one is related to 1762
Roemer van der Meij - 2012-11-09 16:43:00 +0100
How to replicate the bug. a = []; a.field = 1; a.field2{1} = 1; b = config(a); % adding a new field defined as a cell fails >> b.field3{1} = 1 Error using config/subsasgn (line 10) Cell contents reference from a non-cell array object. Error in config/subsasgn (line 35) y2 = subsasgn(y1, index(2:end), val); % reading/modifying/expanding the current cell-field works b.field2{1} b.field2{1} = 2 b.field2{2} = 2 I.e. subsref probably works fine, subsasign doesn't support cell-array being created.
Roemer van der Meij - 2012-11-09 18:11:38 +0100
The issue was a bit more general, and not specific to cell-arrays. What was not supported is creating a new field while indexing it at the same time. So what fails is: b.newfield(1) = 1 b.newfield{1} = 1 Whereas the following succeeds: b.newfield = [] b.newfield(1) = 1 and b.newfield = [] b.newfield{1} = 1 I implemented this by adding a switch when generating a new field, so a field is generated of the appropriate type. The original bug however, is caused by another problem and is still not fixed. The problem occurs when you assign cfg-object to a cell-array inside another config object. So the following fails: b = [] b.field{1} = 1 b = config(b); b.field{1} = b; Whereas the following succeeds: cellvar = {} cellvar{1} = b Curiously, the following also succeeds: b.field{1} = cellvar b.field{1} ans = [1x1 config] To be continued...
Robert Oostenveld - 2014-07-20 14:32:42 +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 - 2014-07-20 14:33:41 +0200
fixed, see previous comment.