Q about integration with SPM8
iversen at NSI.EDU
Tue Jan 13 00:04:33 CET 2009
Sorry, my reply just crossed with yours. Ok, I'm now a bit confused as
to the specifics of the co-evolution of the two projects. It sounds
like the FT in SPM is a custom fit good at a particular moment in
time, but that separate changes in either SPM or FT could bring some
conflicts. That seems like a good argument to use the SPM version of FT.
To clarify my perspective, what I didn't note in my original email,
and I should have, is that the 'headache' I referred to is mainly due
to the fact that I've made some modifications of my own on FT, and
wasn't keen to need to fold them into two separate versions of FT that
might be updated at different times. Granted that's a self-inflicted
headache and perhaps at this point I should reconsider whether those
modifications are in fact necessary. More generally, though, I like to
tweak and be familiar with every detail of the code I'm using, so
having two different versions is just that much more for my finite
brain to keep track of.
Of course, more generally the number one issue would be to avoid a
situation in which two versions yielded different analysis results,
but that doesn't seem to be a concern that either of you have
expressed, so perhaps that is not something to worry about.
So, now I'm considering just using the version of FT included in SPM
for all my uses. I don't take advantage of the daily upgrades to FT,
so the slower release schedule is fine. How does that sound?
On Jan 12, 2009, at 2:13 PM, Vladimir Litvak wrote:
> Although what Robert described (deleting the private subdirectories)
> will do the trick, I don't see any reason to do it. I do see a reason
> not to do it because it may generate errors that will be very hard for
> us to reproduce and resolve. We are now often developing things in
> parallel where changes are made to FT to make some SPM feature work so
> if the two get slightly out of sync those new features will not work.
> Thus, I repeat my recommendation to leave things as they are. Don't
> you agree, Robert?
> There might be some problems with clashes if Robert starts naming some
> FT functions with the same names as wrappers in SPM. I don't know if
> there are any cases like this already.
> On Mon, Jan 12, 2009 at 8:12 PM, Robert Oostenveld
> <r.oostenveld at fcdonders.ru.nl> wrote:
>> Hi John,
>> Vladimir and I (and other spm developers) have considered this
>> and the present spm8+fieldtrip mixture was the best we could come
>> up with.
>> The versions are automatically kept in synch, but the release
>> schedule of
>> fieldtrip is daily, whereas for spm8 it is less frequent. So the
>> getting slightly out of sync on your computer is inevitable.
>> With the latest 2008a and 2008b versions of Matlab there are better
>> for supporting such mixtures ofg packages (using "namespaces"), but
>> both spm and fieldtrip should work on older matlab versions, we
>> cannot use
>> those features yet.
>> On 9 Jan 2009, at 19:31, Vladimir Litvak wrote:
>>>> To avoid this issue,
>>>> I was planning to have SPM8 use my existing Fieldtrip installation
>>>> exclusively. Is there is any downside to this?
>>> Yes because there is no guarantee that your particular FT version is
>>> compatible with your SPM version (unless you keep updating both
>>> is redundant).
>>> The best way for you to work if you already have an FT version that
>>> works for you and don't want to update it for a while is to ignore
>>> FT version that SPM uses and pretend it's not there. Wrappers will
>>> prevent any clashes as I explained.
>> To add on Vladimirs comment: In practice it means that you delete the
>> spm8/external/fieldtrip/private directory and keep the
>> spm8/external/fieldtrip directory for the wrappers. You can do the
>> same for
>> fileio and forwinv (also both in fieldtrip and spm8/external).
>> you should ensure that the ft_xxx wrappers in spm8, respectively the
>> fileio_xxx and the forwinv_xxx wrappers are on your matlab path,
>> just as
>> your normal fieldtrip version. SPM8 will call those wrappers, which
>> call your standard fieldtrip functions.
>> The aim of this list is to facilitate the discussion between users
>> of the
>> FieldTrip toolbox, to share experiences and to discuss new ideas
>> for MEG
>> and EEG analysis. See also
>> http://listserv.surfnet.nl/archives/fieldtrip.html and
> The aim of this list is to facilitate the discussion between users
> of the FieldTrip toolbox, to share experiences and to discuss new
> ideas for MEG and EEG analysis. See also http://listserv.surfnet.nl/archives/fieldtrip.html
> and http://www.ru.nl/fcdonders/fieldtrip.
The aim of this list is to facilitate the discussion between users of the FieldTrip toolbox, to share experiences and to discuss new ideas for MEG and EEG analysis. See also http://listserv.surfnet.nl/archives/fieldtrip.html and http://www.ru.nl/fcdonders/fieldtrip.
More information about the fieldtrip