add functions to deal with pre-analysis steps from CPP_SPM

[marcobarilari]

No description provided.

[Remi-Gau]

Reviewed the README in the other PR.

Once this is accepted, we remove those functions them from the CPP_SPM repo, correct?

[Remi-Gau]

Question: do we want to move the batch setting functions to this repo as we might also need them for CPP_SPM (especially to zip the derivatives or to convert the 3D beta images into 4D ones).

For the latter I had never done that in the past but I have seen several people in the lab using that strategy, so I am happy to make their life easier.

So the idea would be that the CPP_sourceMRI folder would have most the demos and the "workflows" to work on a source dataset, and then anything that is not purely source specific, we put in CPP_SPM?

[Remi-Gau]

Other question: do we want to use SPM batches for zipping (and unzipping)?

I know that not everything has to go through a freaking SPM batch, but it makes for a "nice" way to create tests and ensure that things are properly formatted before we run them (ideally prevents to have error at run time).

Also this can help create log file to track what was done when.

[Remi-Gau]

For the continuous integration:

I have been struggling to create a test with SPM and moxunit.

So for the tests on CPP_SPM I still run the tests via travis but I think that I now "know" enough to maybe finish that transition.

Just to let you know why your tests are failing in CI.

If you want run them you might have to look into the travis config of CPP_SPM: https://github.com/cpp-lln-lab/CPP_SPM/blob/1b890f38257abcc603ed2ef78154a327640134ca/.travis.yml#L51

[marcobarilari]

Other question: do we want to use SPM batches for zipping (and unzipping)?

I am open to other solutions that might fit better with our purpose. I chose SPM cause it was the "faster" to implement it

[marcobarilari]

Question: do we want to move the batch setting functions to this repo as we might also need them for CPP_SPM (especially to zip the derivatives or to convert the 3D beta images into 4D ones).

For the latter I had never done that in the past but I have seen several people in the lab using that strategy, so I am happy to make their life easier.

So the idea would be that the CPP_sourceMRI folder would have most the demos and the "workflows" to work on a source dataset, and then anything that is not purely source specific, we put in CPP_SPM?

Good questions, I have no idea about what could be ideal. Hard to figure out at this stage without a first experience at those "later" stages.

[Remi-Gau]

Other question: do we want to use SPM batches for zipping (and unzipping)?

I am open to other solutions that might fit better with our purpose. I chose SPM cause it was the "faster" to implement it

OK let's keep this one in mind for later. :-)

[Remi-Gau]

Question: do we want to move the batch setting functions to this repo as we might also need them for CPP_SPM (especially to zip the derivatives or to convert the 3D beta images into 4D ones).

For the latter I had never done that in the past but I have seen several people in the lab using that strategy, so I am happy to make their life easier.

So the idea would be that the CPP_sourceMRI folder would have most the demos and the "workflows" to work on a source dataset, and then anything that is not purely source specific, we put in CPP_SPM?

Good questions, I have no idea about what could be ideal. Hard to figure out at this stage without a first experience at those "later" stages.

other possibility: have a separate repo that only contains the code to setBatch that are shared across several repos.

and we add as a submodule where needed.

pro:

• we only have one copy to maintain
• it means that you don't have to get the whole of CPP_SPM as a dependency for this repo

con:

• if you have CPP_SPM and CPP_sourceMRI in the same project, it could be that they both point to different versions of the repo with the batches (dependency version conflict)

[Remi-Gau]

merging this because I need to use it. :-)