Back to the main page.
Bug 1449 - implement an ft_version function
| Status | CLOSED FIXED |
| Reported | 2012-05-01 12:25:00 +0200 |
| Modified | 2019-08-10 12:41:38 +0200 |
| Product: | FieldTrip |
| Component: | core |
| Version: | unspecified |
| Hardware: | PC |
| Operating System: | Windows |
| Importance: | P3 normal |
| Assigned to: | Robert Oostenveld |
| URL: | |
| Tags: | |
| Depends on: | |
| Blocks: | |
| See also: | http://bugzilla.fieldtriptoolbox.org/show_bug.cgi?id=3049 |
Eelke Spaak - 2012-05-01 12:25:44 +0200
Which should give information about the version of FT currently running. I have already worked on this, just now making a bug out of it for easy bookkeeping.
Eelke Spaak - 2012-05-21 13:15:51 +0200
Robert, when you're back from vacation, can we sit together for a few hours and set up the hook/cronjob responsible for the generation of the hash table? The matlab part of ft_version.m is basically done.
Eelke Spaak - 2012-06-08 12:19:17 +0200
Commit in rev 5987. Keeping this bug open for now, will close after internal testing has proved successful :)
Eelke Spaak - 2012-06-12 10:31:13 +0200
Two issues: - The /test/ directories are included in the hashtable, but they should not be (they are not included in the FTP release). - Some files, even though they are at the same revision, apparently result in a different md5sum in the working copy on the SVN server from the md5sum when computed on the file in the FTP release (which, in turn, is the same md5sum when I compute it on my own working copy). Strange. I am investigating.
Eelke Spaak - 2012-06-12 10:37:54 +0200
I tracked the second issue, for the example case of specest/private/ft_getopt.m, to line 29. My own working copy, and the one included in the FTP release, read: % $Id: ft_getopt.m 5076 2011-12-22 13:40:40Z borreu $ But the version in the SVN server's working copy reads: % $Id: ft_getopt.m 5384 2012-03-05 09:15:35Z roboos $ Which I do not understand, since the SVN server's version also is at revision 5076: eelspa@dccn-l009:/home/svnroot/fieldtrip/hooks/hashtable/trunk 311 $ svn info specest/private/ft_getopt.m Path: specest/private/ft_getopt.m Name: ft_getopt.m URL: file:///home/svnroot/fieldtrip/trunk/specest/private/ft_getopt.m Repository Root: file:///home/svnroot/fieldtrip Repository UUID: 0cf7c7f0-3615-4144-b4e6-68da3bce3cd0 Revision: 6033 Node Kind: file Schedule: normal Last Changed Author: borreu Last Changed Rev: 5076 Last Changed Date: 2011-12-22 14:40:40 +0100 (Thu, 22 Dec 2011) Text Last Updated: 2012-03-05 10:15:36 +0100 (Mon, 05 Mar 2012) Checksum: 3d8daa823eb8b30a7e9f4ab4abfe2ce1
Robert Oostenveld - 2012-06-12 16:24:29 +0200
(In reply to comment #4) immediately following svn update on my laptop I see mbp> grep Id `find . -name ft_getopt.m` ./connectivity/private/ft_getopt.m:% $Id: ft_getopt.m 5076 2011-12-22 13:40:40Z borreu $ ./engine/private/ft_getopt.m:% $Id: ft_getopt.m 5384 2012-03-05 09:15:35Z roboos $ ./fileio/private/ft_getopt.m:% $Id: ft_getopt.m 5076 2011-12-22 13:40:40Z borreu $ ./forward/private/ft_getopt.m:% $Id: ft_getopt.m 5076 2011-12-22 13:40:40Z borreu $ ./inverse/private/ft_getopt.m:% $Id: ft_getopt.m 2978 2011-02-27 17:13:16Z roboos $ ./peer/private/ft_getopt.m:% $Id: ft_getopt.m 5076 2011-12-22 13:40:40Z borreu $ ./plotting/private/ft_getopt.m:% $Id: ft_getopt.m 5076 2011-12-22 13:40:40Z borreu $ ./qsub/private/ft_getopt.m:% $Id: ft_getopt.m 5076 2011-12-22 13:40:40Z borreu $ ./specest/private/ft_getopt.m:% $Id: ft_getopt.m 5076 2011-12-22 13:40:40Z borreu $ ./utilities/ft_getopt.m:% $Id: ft_getopt.m 5075 2011-12-22 13:40:39Z borreu $ which suggests that either the autosync flag is not set or that autosync failed... mbp> svn propget autosync `find . -name ft_getopt.m` connectivity/private/ft_getopt.m - true engine/private/ft_getopt.m - true fileio/private/ft_getopt.m - true forward/private/ft_getopt.m - true svn: 'inverse/private/ft_getopt.m' is not under version control reveals that it is not set properly.
Eelke Spaak - 2012-06-13 14:24:18 +0200
check out a local working copy on the svn server, see what happens
Eelke Spaak - 2012-06-13 15:38:30 +0200
Checking out a new working copy on the SVN server results in the correct Id-tag within specest/private/ft_getopt.m. So, re-checking out a fresh working copy for the autosync and hashtable scripts should solve the problem.
Philipp Ruhnau - 2014-01-29 16:22:17 +0100
Hey, as this is still an open thread I figured I put my question here: I have different versions of ft on my computer and a server. as some things changed between the two versions I wanted to make use of ft_version. However, its call results in the same message on both systems: This is FieldTrip, version r7276. I checked the signature.md5, which is the basis of ft_version it seems, in three different ft versions and it is identical it seems. Is this known? best philipp
Robert Oostenveld - 2015-09-16 11:54:20 +0200
some time ago, I deleted the signature file from our webserver, as I thought (incorrectly) that it was not used any more. It was not updated, but the ftp package/zip script still downloaded the signature file and incldued it in the daily release zip files. This commit makes ft_version independent from the signature file, and uses Contents.m instead. mac011> svn commit utilities/ft_version.m Sending utilities/ft_version.m Transmitting file data . Committed revision 10674. This commit removes all incomplete and broken functionality from ft_version. If needed (and if we do want to implement something like this), we can always go back in the version control system to look up the original code by Eelke. mac011> svn commit utilities/ft_version.m Sending utilities/ft_version.m Transmitting file data . Committed revision 10675. The release zip packaging should be updated to have the version YYYYMMDD injected into the Contents.m file. -------------------------------------------------------------------------------- (In reply to Philipp Ruhnau from comment #8) @Philipp, to answer your question: yes, it got known as of recently that the signature file did not contain the correct version. It seems that the signature updating already broke a long time ago. The web server (hosting the signature) has been moved an updated a few times over the last year, and this dependency on some script somewhere in a cron job was overlooked.
Holger Krause - 2017-10-26 18:49:28 +0200
(In reply to Robert Oostenveld from comment #9) Hi, as current 'Contents.m' file doesn't provide information required by 'ver' command, 'ft_version()' fails with an error: --------------------- Insufficient number of outputs from right hand side of equal sign to satisfy assignment. Error in ft_version (line 147) ftver = a.Version; --------------------- Sorry, I'm not familiar with git, so I can't offer a pull request. But may I suggest to handle the case of 'ver' command returning an empty structure by an if-clause like this: --------------------- ... else % get it from the Contents.m file in the FieldTrip release a = ver(ftpath); %In case 'ver' can't determine the version from 'Contents.m', it will %return an empty structure. if isempty(a) ftver = 'unknown'; ft_warning('The ''Contents.m'' file of your fieldtrip copy doesn''t provide required version information.') else ftver = a.Version; end ... --------------------- This is of practical relevance for people deviating from the ftp release naming pattern for the fieldtrip main directory. Even if the release zip packaging would inject the date into the Contents.m file, I'd consider to check for this kind of 'file operation' failure.
Robert Oostenveld - 2017-10-27 09:57:22 +0200
(In reply to Holger Krause from comment #10) Thanks for reporting this. I tried replicating your issue The following gets the version from git and not the Contents file. >> [v, ftpath] = ft_version v = 'ee32b39' ftpath = '/Users/roboos/matlab/fieldtrip' If I then do >> ver(ftpath) ----------------------------------------------------------------------------------------------------- MATLAB Version: 9.3.0.713579 (R2017b) MATLAB License Number: 38957 Operating System: Mac OS X Version: 10.11.6 Build: 15G1611 Java Version: Java 1.8.0_121-b13 with Oracle Corporation Java HotSpot(TM) 64-Bit Server VM mixed mode ----------------------------------------------------------------------------------------------------- FieldTrip Version unknown www.fieldtriptoolbox.org it works fine. Also this works >> a = ver(ftpath) a = struct with fields: Name: 'FieldTrip' Version: 'unknown' Release: 'www.fieldtriptoolbox.org' Date: 'DD-MM-YYYY' although the version is not very informative. In your case I wonder whether your ftpath is actually correct... If it is, then it may be that the "ver" command your MATLAB version is behaving different than mine (2017b).
Holger Krause - 2017-10-27 17:01:09 +0200
(In reply to Robert Oostenveld from comment #11) Thanks for looking into this, Robert. Actually, I'm using R2017b as well. So I dug a bit deeper, and found 'ver' handling links given as path argument not consistently. (Background is, that I download the ftp version daily, and have a link 'latest' pointing to that directory allowing users to always have the _latest_ fieldtrip version in use.) The 'ver' command intersects two lists internally, one generated in line 290 by the 'what' command on the argument given, and the entries on the matlab path as the second one. Unfortunately, the former reports canonicalised paths, while the later does not. When the intersection of the lists is empty, 'ver' returns an empty structure. I would appreciate, if you could handle the case of 'ver' returning an empty structure somehow without fieldtrip exiting with an error. Why not return the same struct with static information you quoted in your last comment? Meanwhile, I will try to figure out, why this issue came up only recently, as we've been using this link to the latest downloaded version of fieldtrip without this issue for a couple of years. P.S.: I also contacted The MathWorks with regard to the behaviour of the 'ver' command.
Robert Oostenveld - 2019-08-10 11:21:33 +0200
this is an old bug, which is still open. However, ft_version exists for quite some time and I don't think there are any changes that are pressing right now. So let me close this bug.