aa 5.6.0 - #246

Feel free to submit a PR to my branch.

Perhaps would should add an isfield(aap.options,"hardlinks" ) check to aas_retrieve_inputs_part_2 before attempting to use the parameter?

Yes, the parameter is included in the latest example parameter sets, but if you're running an old parameter file (like we are) you might not think to add it (and then aas_retrieve_inputs_part_2 barfs and dies when it tries to use it).

The question becomes: should the default be hardlinks = yes or hardlinks = no when the parameter is undefined.

I vote hardlinks = yes because that was the default behavior for many years (ergo making hardlinks more of an "opt-out" parameter).

My assumption is that if someone uses the new version, then they also use the newer parameterset . AFAIS, it is the default case if you simply update aa from git (via pull) rather than keeping each revision as a separate folder.
Is there any reason/advantage for you why you still use the old parameterset? Is it because you have separate versions of aa side-by-side?

In general, I can see no issue with adding this backward compatibility; however, there may be more issues like this.
I am also OK with hardlinks = yes.

Feel free to add it to the PR.

Could you remind me why the hardlinks option was added?

Because certain clusters (including ours) do not support hardlinks.

Fair enough.

I ran into problems because we use old parameter files that don't reference the repo vis-a-vis xi:include (and the old parameter files don't have a hardlinks field). Someday we might implement better checking of the parameters -- a user shouldn't be able to crash aa just by doing something unexpected. However, that is a fight for another day.

In the meantime, I'll continue testing 246. Currently, the only machine I have available is a single-core laptop with about 10 MB of free space, so progress is slow...

Good catch, however, we may want to revisit our pledge for backward compatibility, and I am considering 3 years rolling (i.e. 2018a for 2021) a good target.
What do you think? Do you need support for earlier versions? What about you, @ethanknights?

Personally, I tend to use 2019+ at the moment. So no issue for me.

This PR (finally!) passed all of the tests I ran on it (specifically: all the tests in my PR240). As far as WashU is concerned, it can be merged.

I didn't have a chance to push the changes I noted above (modifying arrayfun any and the hardlink check) because -- oddly enough -- all of our Matlab licenses expired on Aug 01. So I'm now in a position to either upgrade us to a later version of Matlab (in which case my edits don't really need to go into the PR) or re-upping a license on R2018a (in which case they do).

@tiborauer has a point about only supporting the last few Matlab releases. I've continued to use an older version of Matlab not to be contrary, but because my thinking is always "how can we make aa available to the largest possible user base?" However, maybe my imagined scenario of someone wanting to try aa but not able or willing to upgrade Matlab is so improbable that the extra dev effort isn't worth it.

Thoughts?

Update: So I went with the path of least resistance and just reupped my licenses for R2018 (R2018a on one machine and R2019b on another)

We don't have to officially support these older versions, but I'll still be able to test whether aa works on them and fix little stuff (like the any-all change above)

Speaking of which, how do I add my fixes? Can I just do a git push origin pr246 from my local clone of the PR? The docs seem to suggest I need permission to do that.

Here is a description of a workflow when collaborating via git(hub): https://tiborauer.github.io/blog/2021/02/09/git-recipes-collab.html

Briefly, git push origin pr246 submits your local branch to your repo on GitHub. From there, you can submit a PR to my working branch.

Briefly, git push origin pr246 submits your local branch to your repo on GitHub. From there, you can submit a PR to my working branch.

Done.

I have also merged your commits.

Can we merge this?

Yes

Would you merge it now or after I can merge yours?

1. you merge this PR
2. I'll pull master into my local PR branch when I'm done unmangling it.
3. I'll push to my PR
4. You merge my PR

Does this work?

Update: Or, if you like, you can merge my PR first. (I merged your PR to my PR, reverted to my version of aas_processBIDS as we discussed, and pushed everything to PR240).

(also, I saved a copy of your new version of aas_processBIDS.m so we can easily add it later)

Either works. Merging your PR first makes it a bit easier for you. However, there is not much overlap between the two merges IMHO.
I am going to merge your PR first, then, and updated my PR accordingly.

(you do not have to save my version of aas_processBIDS because it is saved in GitHub's "memory". ;)

I resynched this PR according to #240.

Considering that it is a new (sub)version, I wonder whether we would like to update aas_processBIDS now.

Considering that it is a new (sub)version, I wonder whether we would like to update aas_processBIDS now.

My reluctance is this will break every script that currently uses aas_processBIDS.

OTOH, I would really like to see this PR closed.

Proposal: Merge without updating aas_processBIDS, and then I will do a dedicated PR for the new version that includes updating all of the test and example scripts.

Sounds good to me.

@jones-michael-s, would you merge it, then?