Back to the main page.
Bug 2982 - cfg.debug=saveonerror should be supported by all main FT functions
| Status | ASSIGNED |
| Reported | 2015-10-09 09:33:00 +0200 |
| Modified | 2016-01-04 11:56:16 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P5 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: |
Robert Oostenveld - 2015-10-09 09:33:19 +0200
I noticed that cfg.debug (or ft_default.debug) was not working in all functions. With mac011> grep -L preamble.*debug *.m I made a list, which I'll reorder below ** for these it should be supported ** ft_artifact_clip.m ft_artifact_ecg.m ft_artifact_eog.m ft_artifact_jump.m ft_artifact_muscle.m ft_artifact_threshold.m ft_artifact_tms.m ft_artifact_zvalue.m ft_definetrial.m ft_movieplotER.m ft_prepare_headmodel.m ft_prepare_layout.m ft_recodeevent.m ft_stratify.m ft_wizard.m ** these are not called directly ** ft_statistics_analytic.m ft_statistics_crossvalidate.m ft_statistics_montecarlo.m ft_statistics_stats.m ** not needed for these ** ft_defaults.m Contents.m besa2fieldtrip.m edf2fieldtrip.m fieldtrip2besa.m fieldtrip2ctf.m fieldtrip2fiff.m fieldtrip2spss.m loreta2fieldtrip.m spass2fieldtrip.m spm2fieldtrip.m
Robert Oostenveld - 2015-10-09 10:01:30 +0200
Looking at my favourite example, ft_timelockanalysis, I see the order % do the general setup of the function ft_defaults ft_preamble init ft_preamble loadvar data ft_preamble provenance data ft_preamble trackconfig ft_preamble debug but in ft_freqanalysis and ft_sourceanalysis I see % do the general setup of the function ft_defaults ft_preamble init ft_preamble provenance ft_preamble trackconfig ft_preamble debug ft_preamble loadvar data i.e. another order. I also notice that the provenance does not consistently get the input data passed (for md5 hash computation). So the preamble order also needs to be checked.
Robert Oostenveld - 2015-10-09 20:11:45 +0200
(In reply to Robert Oostenveld from comment #1) mac011> svn commit Sending ... Committed revision 10765. this includes 103 files in which the pre and/or post amble have been reordered for consistency.
Johanna - 2016-01-01 15:09:11 +0100
Hi Robert, Happy new year! I'm experiencing an error which I think is related to the svn commit 10765 in this bug. I'm calling ft_preprocessing to initially load data, with just raw_hpf=ft_preprocessing(cfg); (not with 'data' also as input). But then it crashes with this error: Error using ft_preamble_provenance (line 61) Not enough input arguments. Error in ft_preamble (line 56) evalin('caller', ['ft_preamble_' cmd]); Error in ft_preprocessing (line 175) ft_preamble provenance data I traced it to that if 'data' does not exist, then it will give the above error to line 61 of ft_preamble_provenance, which is effectively calling this: eval('data') If I simply change ft_preprocessing line 175 (back) to ft_preamble provenance (how it was before the change) then there is no error and it loads the data fine. Thus, perhaps if the provenance of data must be checked in the preamble, this should only be done 'if hasdata'? An easy fix, but I wanted to check with you if this is the intended usage. Best, Johanna
Robert Oostenveld - 2016-01-03 11:14:23 +0100
(In reply to Johanna from comment #3) happy New Year! I am surprised that it fails for you, since this has not been touched in some time and I heard no other problems with the code. The check that you propose is already there. When I try a simple cfg = []; cfg.dataset = something ft_preprocessing(cfg) then I see that in line 61 of ft_preamble_provenance, the isvar is returned as a 1x1 vector with a single false, i.e. the ft_default.preamble cell array (which contains {'data'}) is not a variable. Subsequently in line 62 nothing gets copied (using eval) into tmpargin, which means that tmpargin at line 64 becomes {[]}. You getting an error on line 61 suggests that ft_default.preamble is not initialized properly. If I emulate line 61 on the command line, I see isvar = cellfun(@(x) exist(x, 'var')==1, {'data'}) returns [0] isvar = cellfun(@(x) exist(x, 'var')==1, {'a', 'b', 'c'}) returns [0 0 0] isvar = cellfun(@(x) exist(x, 'var')==1, {}) returns [] isvar = cellfun(@(x) exist(x, 'var')==1, []) returns "Error using cell fun, Input #2 expected to be a cell array, was double instead" Could you set a debugger on that line and see what happens? best Robert
Johanna - 2016-01-04 11:33:01 +0100
(In reply to Robert Oostenveld from comment #4) Hi Robert, Thank you for your quick and thorough reply! Just to note, I had done an 'svn update' just prior to my previous bug report, so I was sure I was using the most up-to-date FT last Friday. I just did another 'svn update' today. I'm not sure if that fixed it, or whether there was a path issue (sometimes an spm/external/fieldtrip gets in the way), but in any case it's all fixed now. And I tested the output at the line 61 you mentioned and it all agrees with what you wrote. I'm sorry to have raised a false alarm, probably some old code was creeping in even though 'which' showed the correct path (for the functions I checked last week). Best, Johanna