On 17/01/14 10:15, Garth N. Wells wrote:
On 2014-01-17 08:52, Martin Sandve Alnæs wrote: I agree largely with this and support the proposal.
I also support the proposal.
there are changes that if a deprecated interface is maintained will likely introduce bugs (e.g. with the very recent changes, MPI deadlocks)
I understand the concern about deadlocks. Garth: am I wrong in thinking that MPI deadlocks are fairly easy to debug quickly? Whenever I had one I would just gdb in to the deadlocked processes and see where they had stalled. I think you'd pretty quickly see that the processes deadlocked on the call to MPI::whatever were using the wrong communicator. I also think that most user codes will probably have some MPI::max or MPI::mins in there somewhere. So in this case I would guess that the impact of higher risk of deadlocks for the rare case where someone is using multiple different communicators is less than the pain of incompatible immediate API changes for everyone. (I expect you might disagree, though.) So I would say the gradual strategy for API changes as discussed by Martin is appropriate here.
We should add to the deprecation warnings when an interface will be removed; for users and to remind developers when an interface should be removed.
Speaking of which, UnitSquare et al. are still in 1.3. Cheerio, Patrick _______________________________________________ fenics mailing list [email protected] http://fenicsproject.org/mailman/listinfo/fenics
