Back to the main page.
Bug 1892 - configuration tracking and callinfo tracking collide
| Status | ASSIGNED |
| Reported | 2012-12-13 23:40:00 +0100 |
| Modified | 2015-02-11 15:35:01 +0100 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Mac OS |
| Importance: | P3 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | 1964 |
| See also: |
Robert Oostenveld - 2012-12-13 23:40:38 +0100
global ft_default ft_default = [] cfg = [] cfg.trackcallinfo = 'no' cfg.trackconfig = 'cleanup' ft_sourceplot(cfg, mri); results in Undefined function or variable 'ftohDiW7th_FuncTimer'. Error in ft_postamble_provenance (line 44) cfg.callinfo.proctime = toc(ftohDiW7th_FuncTimer); Error in ft_postamble (line 55) evalin('caller', ['ft_postamble_' cmd]); Error in ft_sourceplot (line 1309) ft_postamble provenance which is due to trackconfig-cleanup removing the field trackcallinfo. Initially the provenance preamble knows that it should not track, but the provenance postamble does not know (and tries to access the timer). There might be other fields in the pre/postambles that interfere with the cfg tracking.
Robert Oostenveld - 2012-12-13 23:42:09 +0100
luckily the config tracking is not on by default. should we consider moving the config tracking to a pre/postamble? Nowadays that would be the place where I'd expect it, but back when Saskia and I implemented we did not have that yet.
Roemer van der Meij - 2013-01-30 17:40:30 +0100
(In reply to comment #1) Do you mean to stop using the cfg-object? Or do you have something similar in mind?
Robert Oostenveld - 2013-01-30 17:45:38 +0100
(In reply to comment #2) I was considering moving the cfg object stuff that is now in ft_checkconfig to a pre+postamble. Or more generally, I was thinking along the lines ft_checkconfig currently does (from its documentation) % 1: It checks whether the cfg contains all the required options, it gives % a warning when renamed or deprecated options are used, and it makes sure % no forbidden options are used. If necessary and possible, this function % will adjust the cfg to the input requirements. If the input cfg does NOT % correspond to the requirements, this function gives an elaborate warning % message. % % 2: It controls the relevant cfg options that are being passed on to other % functions, by putting them into substructures or converting them into the % required format. % % 3: It controls the output cfg (data.cfg) such that it only contains % relevant and used fields. The size of fields in the output cfg is also % controlled: fields exceeding a certain maximum size are emptied. % This part of the functionality is still under construction! 1 and 2 is appropriate, like ft_checkdata. For this it would only be called at the start for 3 it currently needs to be called at the start and end of each FT function. That is also where we have the pre and postambles.
Robert Oostenveld - 2013-01-30 17:48:39 +0100
(In reply to comment #3) and actually it would make sense not to introduce yet another pre/postamble pair, but to make it part of the pair we have (as of recently) for the provenance. The first part of the provenance implementation pertained to data md5 hashes. Eelke just added the usercfg (complementing the "used cfg"). The cfg object fits in the same corner.