Hi all
I’ve put the plan below into action. There’s a new branch
https://github.com/UCL/STIR/tree/release_4.0.0
which you should use for any PRs that you hope will make it into release 4.0.0.
The scatter PR is now up-to-date with this branch as well. This is the only PR that I’d still like to merge, although if there’s anything else that breaks backwards compatibility that can be merged with minimal effort from my side, or if
anything needs to be fixed, please send to the stir-devel list.
All contributors, please check
https://github.com/UCL/STIR/blob/release_4.0.0/documentation/release_4.0.htm and other documentation.
Hopefully we can get this done soon.
Kris
PS: I’m still waiting for volunteers to test the scatter PR (but this should now be easier) :-;
From: CCP-PETMR Developers list <[log in to unmask]>
On Behalf Of Thielemans, Kris
Sent: 07 April 2020 22:47
To: [log in to unmask]
Subject: Re: use of shared_ptr members and arguments
Hi all
Any input on this still welcome. See
https://github.com/UCL/STIR/issues/485 for latest thoughts.
This has needed quite a lot of changes, and still more to come, with strategy not yet decided. It’s therefore going to delay release of STIR 4.0 even more.
I therefore suggest to make a release branch from the latest commit before we started this adventure (i.e. Daniel’s PR on set_bin_value). I would then “remove” the 2 last “merge” commits (with master) on the scatter PR
https://github.com/UCL/STIR/pull/44/commits, and do a new merge with the release branch. The PR will then go to the release branch.
Similarly, for any last changes, please make PRs based from the new release branch.
If this sounds like a good plan (or at least, the best plan in a difficult situation), I’ll go ahead some time tomorrow hopefully. If you have any better ideas, let the stir-devel list know.
In the mean time, if anyone could build the scatter PR, and run recon_test_pack/run_scatter_test.sh, and let the list know, that’d be hugely appreciated. I still don’t know why there’s 2 Travis jobs that give too large discrepancies between
stored and computed results.
Kris
From: Thielemans, Kris
Sent: 05 April 2020 22:59
To: [log in to unmask] <[log in to unmask]>;
[log in to unmask]
Subject: use of shared_ptr members and arguments
Hi all
In an attempt to avoid creating copies/clones, STIR and SIRF use sometimes use shared_ptr as arguments to set class members.
An example from sirf::NiftyRegistration:
void set_reference_mask(const std::shared_ptr<const ImageData> reference_mask_sptr)
{ _reference_mask_sptr = reference_mask_sptr; }
And from stir::ExamData (after
https://github.com/UCL/STIR/pull/487)
ExamData(const shared_ptr < const ExamInfo > & _this_exam);
This usage is however unsafe, as the original owner of the shared_ptr can modify the object that is being shared. Example is at
https://github.com/UCL/STIR/issues/485
It currently seems to me that we shouldn’t allow shared_ptr arguments at all, but that would be expensive. Any ideas? Might be best to discuss at
https://github.com/UCL/STIR/issues/485
Kris
To unsubscribe from the CCP-PETMR-DEVEL list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=CCP-PETMR-DEVEL&A=1