Back to the main page.
Bug 3244 - modules should remain stand-alone
| Status | ASSIGNED |
| Reported | 2017-02-08 09:39:00 +0100 |
| Modified | 2017-02-08 10:49:14 +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 - 2017-02-08 09:39:54 +0100
Nathalie reported ============ while trying running qsubfeval I got the notification: ??? Undefined function or method 'ft_platform_supports' for input arguments of type 'char'. Error in ==> qsubfeval at 190 if ft_platform_supports('program_invocation_name') The same problem appears in all versions of Matlab and across multiple sessions. ============ I realize that this is due to making ft_platform_supports a full FT function (i.e. moving it out of private). On http://www.fieldtriptoolbox.org/development/modules it is explained (shortly) that some subdirectories act as mini-toolboxes. Hence they should not have external dependencies. Some functions therefore need to be replicated in their respective private directories.
nno - 2017-02-08 09:53:42 +0100
(In reply to Robert Oostenveld from comment #0) The issue is due to a PR I sent earlier [1]. I was not aware that some sub-directories should be able to run without external dependencies. I would be happy to send a PR to fix the ft_platform_supports issue? Also, it may be useful to add to the website that the organisation into mini-toolboxes means that functions should be duplicated along the multiple directories. This is something that may not be obvious to new potential contributors - at least it was not to me. > Some functions therefore need to be replicated in their respective private directories. ft_platform_supports was upgraded to first class citizen, mainly to solve the issue of functions in private directories calling each other - which seems not supported in Octave [1]. Would you agree that in this case ft_platform_supports should therefore be included in the other directories as well, not in the private subdirectory but in their root? Or mix it so that ft_platform_supports is included as first class citizen in utilities, but second class (private) in the subdirectories? I have to admit, this seems to become a bit messy with respect to the search path... [1] https://github.com/fieldtrip/fieldtrip/pull/313
Robert Oostenveld - 2017-02-08 10:01:38 +0100
[I just had a mid-air collision; let me first add this] The might not only apply to ft_platform_supports, but also to other functions. In the past I have occasionally checked with "depfun" that the modules don't have dependencies outside their own directory... Ah, I found it, it is test_dependencies. Apparently it failed to detect the dependency. I checked the code, it primarily aims at checking the "compat" directory. That was (once upon a time) needed to smooth the transition from preprocessing (without ft) to ft_preprocessing. So the modular dependencies are not tested. I will add that.
Robert Oostenveld - 2017-02-08 10:06:14 +0100
(In reply to nno from comment #1) Private functions not being able to call other private functions seems a bug in octave to me. Its implications would be much wider than this (explicitly exposed) function, which is now part of the official FieldTrip user interface and API. The reason for private is to ensure that some functions are not relied on by users, and that we can change them (keeping our own usage consistent of course). How is octave dealing with icosahedron42 (and some other numbers), which calls icosahedron? Both are in private, and called whenever a triangulated sphere is needed.
Robert Oostenveld - 2017-02-08 10:17:02 +0100
I am aware that documentation for developers is incomplete and sometimes outdated. Documentation for beginners, more advanced users and power users is also incomplete. I cannot do everything myself and also need developers to contribute to the various pieces of documentation. There is mention of this particular requirement at http://www.fieldtriptoolbox.org/development/guidelines/code#calling_functions_that_are_located_elsewhere. Could you read (and review) the whole development guidelines and provide comments/improvements?
Robert Oostenveld - 2017-02-08 10:26:15 +0100
to implement a quick fix, I will add it back to mac011> git commit -a [master d831e7a] HOTFIX - added ft_platform_supports.m back to the respective private directories. See http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3244 11 files changed, 3137 insertions(+) create mode 100644 connectivity/private/ft_platform_supports.m create mode 100644 engine/private/ft_platform_supports.m create mode 100644 fileio/private/ft_platform_supports.m create mode 100644 forward/private/ft_platform_supports.m create mode 100644 inverse/private/ft_platform_supports.m create mode 100644 peer/private/ft_platform_supports.m create mode 100644 plotting/private/ft_platform_supports.m create mode 100644 preproc/private/ft_platform_supports.m create mode 100644 qsub/private/ft_platform_supports.m create mode 100644 specest/private/ft_platform_supports.m I have pushed to it the master branch. Still to be done is to improve test_dependencies to check that all modules are stand-alone. One reason for it failing might also be that test_dependencies -> mydepfun -> depfun and >> depfun Error using depfun (line 4) DEPFUN has been removed. Use matlab.codetools.requiredFilesAndProducts instead. which is silently caught in mydepfun. I should first test it on an old MATLAB version and then think of how to improve the test. I can imagine that the "depfun" command is also missing (or implemented differently) on Octave.
nno - 2017-02-08 10:42:27 +0100
(In reply to Robert Oostenveld from comment #3) > Private functions not being able to call other private functions seems a bug in octave to me I'll look more into it. The following code mkdir private echo "function foo() bar()" > private/foo.m echo "function bar() disp('bar was called');" > private/bar.m echo "function main() foo()" > main.m which calls main -> private/foo -> private/bar runs fine. Yet there are errors reported on travis (https://travis-ci.org/nno/fieldtrip/jobs/196967097): failure: no such file, '/home/travis/build/nno/fieldtrip/utilities/private/private/ft_platform_supports.m' randomseed:47 (/home/travis/build/nno/fieldtrip/utilities/private/randomseed.m) ft_preamble_randomseed:40 (/home/travis/build/nno/fieldtrip/utilities/private/ft_preamble_randomseed.m) ft_connectivitysimulation:114 (/home/travis/build/nno/fieldtrip/ft_connectivitysimulation.m) ft_preamble:72 (/home/travis/build/nno/fieldtrip/utilities/ft_preamble.m) ft_connectivitysimulation:114 (/home/travis/build/nno/fieldtrip/ft_connectivitysimulation.m) test_old_connectivityanalysis:29 (/home/travis/build/nno/fieldtrip/test/test_old_connectivityanalysis.m) MOxUnitFieldTripTestCase>run_function_in_dir:72 (/home/travis/build/nno/fieldtrip/contrib/MOxUnit_fieldtrip/@MOxUnitFieldTripTestCase/MOxUnitFieldTripTestCase.m) which does seem to indicate some issues with functions in private directories. I'll see if I can identify the issue here.