Hello Robert and debian-med... Robert Edgar wrote:
I have just completed merging the changes between muscle 3.6 and muscle 3.7 into the libmuscle library. It didn't take very long but I've been busy with other things so it took a long time to get around to doing it. Be aware that I have only done minimal testing since I don't have a muscle test-suite. While merging the changes, I noticed that 3.7 has fixes for a few of the issues I discovered in 3.6 and fixed independently. That reassures me I wasn't off-my-rocker when making changes. If you're curious Robert, a precise list of bugfix-type changes can probably be gleaned from the subversion repository for libMUSCLE. I've been using subversion religiously.I'd be very interested to hear about bug fixes and new features and merge them into my own sources if possible.
More to the point, I have created a set of diffs against the 3.7 codebase, which when applied will merge in all of my changes to the 3.7 code:
http://gel.ahabs.wisc.edu/~darling/library_refactor.diff.gzThis patch will not bring along all of the automake build system goodies, for that you may as well just check out the whole repository with: svn export http://mauve.svn.sourceforge.net/svnroot/mauve/muscle/trunk muscle
If you look through the patch, please do not be intimidated by the large number of changes. Many changes are storage class changes to static and global variables to put them in thread-safe storage. You'll see lots of variables wrapped with the TLS class. When compiled with OpenMP, the TLS class provides a thread-local version of the variable, when compiled without OpenMP, the class effectively does nothing and the compiler should optimize it away. The subversion logs should allow you to separate the more interesting and substantive changes from the mundane storage-class refactoring.
Please note that the Makefile.am included with libMUSCLE also builds the muscle binary by default. That may need to change if it is to be packaged exclusively as a library for debian.
Robert, I would be delighted if you would consider basing future muscle releases around the library refactorization. Please let me know what else I can do to facilitate it.
-Aaron