Upgrading to 0.7

[timholy]

Within days the Images suite will be ready for julia 0.7 and 1.0, and hence it is time to start thinking about upgrading our packages. Here is an outline of the recommended process.

Steps that can be taken before testing on 0.7:

• push a branch called julia0.6, so that anyone still using 0.6 can follow that branch without disruption
• check out a local branch called julia0.7
• run Femtocleaner locally with the REQUIRE file set to julia 0.6 and see if there are any deprecations. Let it fix those and make a commit.
• bump the REQUIRE file to julia 0.7 and re-run femotcleaner. Note femtocleaner only runs on 0.6, there is no need to use 0.7 for this step. Commit the fixes.

The next steps require 0.7. 0.7 and 1.0 are both built and available in /usr/local/julia on both cannon and flash:

• just try using PkgName where PkgName is, e.g., BlockRegistration. For our more complex packages it would not be surprising if even this failed. Make any needed fixes to get the package to compile and commit.
• start working your way through the tests. Fix both errors and deprecation warnings. For the bigger packages it is probably worth making a commit for each test file that you get working.
• before you submit to the HolyLab repo, be sure you update the .travis.yml and appveyor.yml scripts. Note that Appveyor.jl has a cut-and-paste script in the README that can be used everywhere.

Note that Revise and Rebugger are quite handy for fixing bugs.

[timholy]

Another point worth making is that there is no reason to try to maintain 0.6 compatibility: the julia0.6 branch will be available, and since 0.7 is "the future" there is little point having a lot of cruft around to support older versions.

[Cody-G]

I pushed a candidate julia0.6 branch. I had to remove a commit so the history got a bit messy, see #89

[Cody-G]

I see that many of the sub-modules of this package have been separated and updated for Julia 0.7. Is this still a work in progress and this package will be updated too? Or is the plan to deprecate this package and have all the individual modules as dependencies in BlockRegistrationScheduler?

[timholy]

My understanding is that this is basically done except for the CUDA stuff. It will probably still exist as a "meta-package" but most of the code will be moved out. If you want to experiment with it locally, you could probably duplicate the top-level file (name it something different perhaps so it's not confusing when the "official" version comes out). I haven't tested it myself.

[Cody-G]

Gotcha. I think also the QuadDIRECT-based registration methods haven't been updated and separated yet. Those are a dependency of my EmpiricalTiming package. I could either break those out into a different package or I could depend on HistogramRegistration instead. I only need 2D rigid registration (translation + rotation), do you think that package is a good option? I may even be able to get away with translation only. I don't think the CUDA version is ideal in my case because it would need to run on the microscope server which doesn't have a good GPU.

Edit: I just noticed that RegisterOptimize does have the QuadDIRECT registration code, but the tests weren't ported yet so maybe this is still a work in progress?

[kdw503]

Most of sub-packages of BlockRegistrations were separated and updated except RegisterMismatchCuda.
I am working on RegisterMismatchCuda right now. The top level package is RegisterOptimize which includes qd_rigid.jl (I think this is the QuadDIRECT-based registration) but related test scripts were not included originally. I think these packages could be connected directly to BlockRegistrationScheduler without BlockRegistrations package later. Although the BlockRegistrationScheduler is also not updated yet, you can use these sub-packages directly.

[Cody-G]

Got it, I'll work on integrating the QuadDIRECT registration tests into RegisterOptimize (One could argue that the QuadDIRECT registration should be in its own package, but I'll leave it there for now).

[kdw503]

Thank you. If you integrating the tests as it is, I'll update QuadDIRECT and the tests.
And, I prefer separating the QuadDIRECT out from RegisterOptimize, if the work is not that hard.

[Cody-G]

I'll update QuadDIRECT and the tests

I think QuadDIRECT is already updated?
See timholy/QuadDIRECT.jl#12

[kdw503]

I found some deprecations by eye and updated.
If your test script fully covers the QuadDIRECT, it may complain some more deprecations I missed.

[Cody-G]

See https://github.com/HolyLab/RegisterQD.jl for a work in progress splitting out the code. Currently tests are failing due to optimization results, I'm looking into it.

[Cody-G]

Crossreferencing HolyLab/RegisterQD.jl#1, the move to Julia 0.7 seems to have come with a big regression in the runtime of QuadDIRECT-based registration, and a smaller regression in the accuracy of the results.