Help needed in C++ / seqan issue
Hi, I've got some request to package mugsy which I started in Git[1]. The source contained several code copies. I think I sorted out the code copy of mummer by adding the patches contained in mugsy to the Debian packaged mummer (see my last upload). I also tried to get rid of the outdated seqan copy but this creates several issues of kind In file included from mugsy/mugsy.cpp:36:0: mugsy/rna_alphabet.h:183:40: error: conflicting declaration 'typedef class seqan::SimpleType seqan::Rna' typedef SimpleType Rna;^M ^ In file included from /usr/include/seqan/basic/basic_alphabet.h:90:0, from /usr/include/seqan/basic.h:68, from mugsy/mugsy.cpp:29: /usr/include/seqan/basic/alphabet_residue.h:402:41: note: previous declaration as 'typedef class seqan::SimpleType seqan::Rna' typedef SimpleType Rna; ^ In file included from mugsy/mugsy.cpp:36:0: mugsy/rna_alphabet.h:185:20: error: redefinition of 'struct seqan::ValueSize >' template <> struct ValueSize< Rna > { enum { VALUE = 4 }; };^M ^ In file included from /usr/include/seqan/basic/basic_alphabet.h:90:0, from /usr/include/seqan/basic.h:68, from mugsy/mugsy.cpp:29: /usr/include/seqan/basic/alphabet_residue.h:405:8: error: previous definition of 'struct seqan::ValueSize >' struct ValueSize ^ In file included from mugsy/mugsy.cpp:36:0: mugsy/rna_alphabet.h:186:20: error: redefinition of 'struct seqan::BitsPerValue >' template <> struct BitsPerValue< Rna > { enum { VALUE = 2 }; };^M ^ ... Just use git-buildpackage on [1] to see more of them. My C++ knowledge is basically zero so I do not feel able to fix this what seems to be a simple task for a C++ programmer. Before I'll direct this question to debian-mentors I'd like to test whether I can get some help on our list. Kind regards Andreas. [1] git://anonscm.debian.org/debian-med/mugsy.git -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150415073929.gb...@an3as.eu
Re: Help needed in C++ / seqan issue
Hello Andreas, I did a debcheckout --user git://git.debian.org/debian-med/mugsy.git \ --git-track '*' and then tried git-buildpackage -uc -us which gives me a gbp:error: upstream/1r2.3+dfsg is not a valid treeish I guess you have to do a "git push --tags". I also have two dead links in the source tree mugsyWGA -> mugsy-seqan/projects/library/apps/mugsy/gcc/mugsy synchain-mugsy -> chaining/synchain-mugsy The latter one is properly set when the build starts, the first one not, that is at least not before the build fails. dpkg-buildpackage -uc -us -b starts and I get all the errors. The first series of errors is related to the fact that mugsy-seqan/projects/library/apps/mugsy/rna_alphabet.h contains what seems to be a copy of /usr/include/seqan/basic/alphabet_residue.h with a slightly different naming scheme. Which means one can remove the line 36 #include "rna_alphabet.h" from mugsy.cpp, BUT! I do not know if the underlying code really does the same. That's why I didn't upload this change. Does the package actually provide tests? The remaining errors are primarily related to differences in the bundled seqan and the installed one (I used 1.4.1+dfsg-2). I have no idea how to fix these. Then there are also a few errors that seem to be related to the more restrictive handling of C++ with newer compilers. I happily step in again to fix these if someone else was able to correct the seqan version related errors. Best, Gert On Wed, 2015-04-15 at 09:39 +0200, Andreas Tille wrote: > Hi, > > I've got some request to package mugsy which I started in Git[1]. The > source contained several code copies. I think I sorted out the code > copy of mummer by adding the patches contained in mugsy to the Debian > packaged mummer (see my last upload). > > I also tried to get rid of the outdated seqan copy but this creates > several issues of kind > > In file included from mugsy/mugsy.cpp:36:0: > mugsy/rna_alphabet.h:183:40: error: conflicting declaration 'typedef class > seqan::SimpleType seqan::Rna' > typedef SimpleType Rna;^M > ^ > In file included from /usr/include/seqan/basic/basic_alphabet.h:90:0, > from /usr/include/seqan/basic.h:68, > from mugsy/mugsy.cpp:29: > /usr/include/seqan/basic/alphabet_residue.h:402:41: note: previous > declaration as 'typedef class seqan::SimpleType > seqan::Rna' > typedef SimpleType Rna; > ^ > In file included from mugsy/mugsy.cpp:36:0: > mugsy/rna_alphabet.h:185:20: error: redefinition of 'struct > seqan::ValueSize >' > template <> struct ValueSize< Rna > { enum { VALUE = 4 }; };^M > ^ > In file included from /usr/include/seqan/basic/basic_alphabet.h:90:0, > from /usr/include/seqan/basic.h:68, > from mugsy/mugsy.cpp:29: > /usr/include/seqan/basic/alphabet_residue.h:405:8: error: previous definition > of 'struct seqan::ValueSize >' > struct ValueSize > ^ > In file included from mugsy/mugsy.cpp:36:0: > mugsy/rna_alphabet.h:186:20: error: redefinition of 'struct > seqan::BitsPerValue >' > template <> struct BitsPerValue< Rna > { enum { VALUE = 2 }; };^M > ^ > ... > > > Just use git-buildpackage on [1] to see more of them. My C++ knowledge > is basically zero so I do not feel able to fix this what seems to be a > simple task for a C++ programmer. Before I'll direct this question to > debian-mentors I'd like to test whether I can get some help on our list. > > Kind regards > > Andreas. > > [1] git://anonscm.debian.org/debian-med/mugsy.git > > -- > http://fam-tille.de > > signature.asc Description: This is a digitally signed message part
Re: Help needed in C++ / seqan issue
Hi Gert, On Wed, Apr 15, 2015 at 10:53:27AM +0200, Gert Wollny wrote: > > gbp:error: upstream/1r2.3+dfsg is not a valid treeish > > I guess you have to do a "git push --tags". Done. Sorry for the nuisance. > I also have two dead links in the source tree > > mugsyWGA -> mugsy-seqan/projects/library/apps/mugsy/gcc/mugsy > synchain-mugsy -> chaining/synchain-mugsy > > The latter one is properly set when the build starts, the first one not, > that is at least not before the build fails. The upstream tarball is a bit in flux. I removed a lot of stuff and left these dangling links intentionally as a reminder for myself to make sure that the needed files will be really built. I admit that's a bit questionable for other people. > dpkg-buildpackage -uc -us -b > > starts and I get all the errors. > > The first series of errors is related to the fact that > > mugsy-seqan/projects/library/apps/mugsy/rna_alphabet.h > > contains what seems to be a copy of > > /usr/include/seqan/basic/alphabet_residue.h > > with a slightly different naming scheme. Which means one can remove the > line 36 > > #include "rna_alphabet.h" > > from mugsy.cpp, BUT! I do not know if the underlying code really does > the same. That's why I didn't upload this change. Does the package > actually provide tests? No, it does not. :-( I was told that these tools are somehow established and remain unchanged. Most people seem to simply take the prebuild amd64 binary (which is also the only supported tarball - source comes from svn). I guess we need to do our own tests - volunteers would be welcome to provide a test suite. I admit I somehow regret that I had the following GSoC idea to late: Provide test suites for all Debian Med packages I think this makes a great GSoC project - we should remember this for next year. As a temporary solution to see if we would get at least any binary I applied your suggested patch. We might hide the resulting binary (which might be only a minor part of mugsy) in some experimental staging area and lead users via docs to this. Otherwise I see no chance to find this out. > The remaining errors are primarily related to differences in the bundled > seqan and the installed one (I used 1.4.1+dfsg-2). I have no idea how > to fix these. I also build against seqan-dev 1.4.1+dfsg-2 as this is the current Debian package. > Then there are also a few errors that seem to be related to the more > restrictive handling of C++ with newer compilers. I guess the code copy of the old seqan will show several C++ problems as well. So IMHO trying to work with this is similarly fruitless as trying to port the code to new seqan. > I happily step in > again to fix these if someone else was able to correct the seqan version > related errors. Cool. Thanks a lot for this offer Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150415094731.gc...@an3as.eu
Re: Help needed in C++ / seqan issue
Hello Andreas, > I admit I somehow regret that I had the following GSoC idea to late: > > Provide test suites for all Debian Med packages > > I think this makes a great GSoC project - we should remember this for > next year. +1 One option to provide some tests in this case could be based on publicly available data, e.g. from [1]: Create results with the old version of the software and test the new version against these results. This should not be too difficult, but the selection of the data should be done by someone who actually knows about this gene sequencing stuff in order to obtain a test set that covers a wide variety of possible inputs. > I guess the code copy of the old seqan will show several C++ problems as > well. So IMHO trying to work with this is similarly fruitless as trying > to port the code to new seqan. Usually solving these errors is quite straightforward, so if you think that for know it would make sense to include the old code, I could do the porting to the new C++ compiler, and then, when we have a test set we could focus on moving to the new seqan. Best, Gert [1] http://www.gigasciencejournal.com/ signature.asc Description: This is a digitally signed message part
Re: Help needed in C++ / seqan issue
Hi Gert, On Wed, Apr 15, 2015 at 12:21:07PM +0200, Gert Wollny wrote: > > I admit I somehow regret that I had the following GSoC idea to late: > > > > Provide test suites for all Debian Med packages > > > > I think this makes a great GSoC project - we should remember this for > > next year. > +1 :-) > One option to provide some tests in this case could be based on publicly > available data, e.g. from [1]: Create results with the old version of > the software and test the new version against these results. This should > not be too difficult, but the selection of the data should be done by > someone who actually knows about this gene sequencing stuff in order to > obtain a test set that covers a wide variety of possible inputs. ... and this someone is neither you or me. :-) So if you (=as the reader of this list) always wanted to know how to help this is your chance to contribute. > > I guess the code copy of the old seqan will show several C++ problems as > > well. So IMHO trying to work with this is similarly fruitless as trying > > to port the code to new seqan. > Usually solving these errors is quite straightforward, so if you think > that for know it would make sense to include the old code, I could do > the porting to the new C++ compiler, and then, when we have a test set > we could focus on moving to the new seqan. I'd prefer to wait whether there is somebody volunteering to adapt straight to the new seqan. Kind regards Andreas. > [1] http://www.gigasciencejournal.com/ -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150415102841.gd...@an3as.eu
Seqan knowledge needed (Was: Help needed in C++ / seqan issue)
Hello, I intend to package mugsy which contains a copy (fork?) of some old seqan version. In contrast to Gert's advise below I would prefer to port this to the current (and future) seqan versions but I obviously need some help. The full discussion between Gert and me starts here[2] in the mailing list archive. On Wed, Apr 15, 2015 at 12:21:07PM +0200, Gert Wollny wrote: > > > I guess the code copy of the old seqan will show several C++ problems as > > well. So IMHO trying to work with this is similarly fruitless as trying > > to port the code to new seqan. > Usually solving these errors is quite straightforward, so if you think > that for know it would make sense to include the old code, I could do > the porting to the new C++ compiler, and then, when we have a test set > we could focus on moving to the new seqan. I wonder whether somebody might be able to give some hint on errors like these: ... g++ -I /usr/local/projects/angiuoli/boost/include/boost-1_38 -pedantic -ftemplate-depth-200 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 synchain-mugsy.cpp -c -o synchain-mugsy.o In file included from /usr/include/c++/4.9/ext/hash_set:60:0, from synchain-mugsy.cpp:83: /usr/include/c++/4.9/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a futur e date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp] #warning \ ^ g++ -I /usr/local/projects/angiuoli/boost/include/boost-1_38 -pedantic -ftemplate-depth-200 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -Wl,-z,relro synchain-mugsy.o -o /tmp/buildd/mugsy- 1r2.3+dfsg/chaining/synchain-mugsy; chmod 755 /tmp/buildd/mugsy-1r2.3+dfsg/chaining/synchain-mugsy make[2]: Leaving directory '/tmp/buildd/mugsy-1r2.3+dfsg/chaining' make -C mugsy-seqan/projects/library/apps make[2]: Entering directory '/tmp/buildd/mugsy-1r2.3+dfsg/mugsy-seqan/projects/library/apps' g++ -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -I.. -O9 -pedantic -W -Wall -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_FORTIFY_SOURCE=2 -Wl,-z,relro -lrt mugsy/mugs y.cpp -o mugsy/mugsy In file included from /usr/include/seqan/basic/basic_debug.h:58:0, from /usr/include/seqan/basic.h:52, from mugsy/mugsy.cpp:29: mugsy/mugsy.cpp:79:1: error: '_proFloat' does not name a type SEQAN_PROTIMESTART(__myProfileTime); // Profiling ^ mugsy/mugsy.cpp: In function 'void buildMatchesFromGraph(TGraph&, seqan::StringSet&, TFragmentString&, TScoreValues&)': mugsy/mugsy.cpp:2161:17: error: 'TFragment' has no member named 'reversed' if(currfrag.reversed){ ^ In file included from /usr/include/seqan/basic/basic_debug.h:58:0, from /usr/include/seqan/basic.h:52, from mugsy/mugsy.cpp:29: mugsy/mugsy.cpp: In function 'void generateLCBs(seqan::Graph >&, TLCB&, TStringSet1&, TNames&, TGenomeNames&, TVertexOrientMap&, TIntervals&, const seqan::MsaOptions, TScore>&)': mugsy/mugsy.cpp:3300:66: error: '__myProfileTime' was not declared in this scope std::cerr << "Anchor conversion done: " << SEQAN_PROTIMEUPDATE(__myProfileTime) << " seconds" << std::endl; ^ mugsy/mugsy.cpp: In function 'std::vector alignLCBs(TGraph&, TLCBs&, TStringSet1&, TStringSet2&, TNames&, TGenomeNames&, TVertexOrientMap&, TStream1&, std::map >&, const seqan::MsaOptions, TScore>&)': mugsy/mugsy.cpp:3854:71: error: '__myProfileTime' was not declared in this scope std::cerr << "Saving interval tree done: " << SEQAN_PROTIMEUPDATE(__myProfileTime) << " seconds" << std::endl; ^ mugsy/mugsy.cpp:4152:47: error: there are no arguments to 'MafFormat' that depend on a template parameter, so a declaration of 'MafFormat' must be available [-fpermissive] write(strmmaf,currgOut,currnameSet,MafFormat(),curroffsets,currspanlens,currseqlens,currorients,lcblabel.str()); ^ mugsy/mugsy.cpp:4152:47: note: (if you use '-fpermissive', G++ will accept your code, but allowing the use of an undeclared name is deprecated) In file included from /usr/include/seqan/basic/basic_debug.h:58:0, from /usr/include/seqan/basic.h:52, from mugsy/mugsy.cpp:29: mugsy/mugsy.cpp: In function 'void wholeGenomeAlignment(TGraph&, TStringSet&, TStringSet2&, TNames&, TGenomeNames&, const seqan::MsaOptions, TSc ore>&, TLCBs&, TVMap&, TStream&, TIMap&)': ... Any help is welcome Andreas. [1] http://mugsy.sourceforge.net/ [2] https://lists.debian.org/debian-med/2015/04/msg6.html -- http://fam-tille.de -- To UNSUBSCRIBE, email to de
Re: Seqan knowledge needed (Was: Help needed in C++ / seqan issue)
Hi Andreas, Here's my take on mugsy issues. I worked on a tree checked out with: $ svn checkout svn://svn.code.sf.net/p/mugsy/code/trunk mugsy-code Building with gcc-4.9.2. The version of boost I compiled it against is 1.56. I couldn't get it to link, because the authors apparently never heard of autotools. Generally, those handwritten Makefile's just.. made me cry. Hope this helps, Andrei -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1429929049-21676-1-git-send-email-andrei.zavada@gmail.com
Re: Seqan knowledge needed (Was: Help needed in C++ / seqan issue)
Hi Andrei, On Sat, Apr 25, 2015 at 05:30:39AM +0300, johnhom...@gmail.com wrote: > Here's my take on mugsy issues. I worked on a tree checked out with: > > $ svn checkout svn://svn.code.sf.net/p/mugsy/code/trunk mugsy-code > > Building with gcc-4.9.2. The version of boost I compiled it against is 1.56. OK, thanks for your patches. I'll check them soon. > I couldn't get it to link, because the authors apparently never heard > of autotools. Generally, those handwritten Makefile's just.. made me > cry. +1 However, if we really want automake on these old projects we probably need to add it ourselves. I did so in the past for living projects and it was adapted upstream but I'm not sure here. Thanks a lot for your contribution - I'll come back in case of trouble Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150425065252.gb32...@an3as.eu
Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))
Hi, I think I need to come back to this nearly one year old mail which I seem to have left uncommented. It concerns mugsy[1]: On Sat, 25 Apr 2015 08:52:52 +0200 Andreas Tille wrote: > On Sat, Apr 25, 2015 at 05:30:39AM +0300, johnhom...@gmail.com wrote: > > Here's my take on mugsy issues. I worked on a tree checked out with: > > > > $ svn checkout svn://svn.code.sf.net/p/mugsy/code/trunk mugsy-code > > > > Building with gcc-4.9.2. The version of boost I compiled it against is > > 1.56. > > OK, thanks for your patches. I'll check them soon. > > > I couldn't get it to link, because the authors apparently never heard > > of autotools. Generally, those handwritten Makefile's just.. made me > > cry. > > +1 > > However, if we really want automake on these old projects we probably > need to add it ourselves. I did so in the past for living projects and > it was adapted upstream but I'm not sure here. > > Thanks a lot for your contribution - I'll come back in case of trouble The pathces provided by Andrei are probably fine but they are patching the original code from SVN which are basically code copies that are removed in our source tarball anyway. The current status is: 0. The code seems to be orphaned / unmaintained since 2011. 1. Mugsy contains a *patched* version of MUMmer 3.20. I took over those changes to the Debian MUMmer 3.23 package that sounded sensible 2. Mugsy also contains a code copy of some files of an old seqan version. Most of these seem to be not needed and are removed inside get-orig-source script Somehow the removal of the seqan files was a bad idea since when trying to build against Debian packaged seqan I was running into several errors which was the reason for my ask for help close to one year ago. Since my colleagues stalled the request for the installation of Mugsy I stopped my effort into this but the topic came up recently again. I wonder what might be the best way to accomplish the wish to package mugsy: 1. Go with the seqan code copy? 2. Find some modern replacement that is better regarding code maintenance as well as functionality / speed. I can not really imagine that the last 5 years did not brought up something better. Any hints? Kind regards Andreas. [1] git://anonscm.debian.org/debian-med/mugsy.git -- http://fam-tille.de
Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))
Hi Andreas, I spent the last few weeks meandering in the murky marshes of the mugsy source code; It is a monstrosity. Before answering to your individual points I'd like to stress that I *literally* spend days trying to compile mugsy with seqan 1.3 which comes with Ubuntu 14.04 LTS. A hundred changes in, I gave up. Most of the time, the compiler produces console-filling warnings, overflowing with templates and hiding the actual problems. Next, I built mugsyWGA with the given seqan code, which succeeded. But I have reason to believe the included code is not the one used to produce the binary in the tarball: The seqan library code produces debug output which does not appear in the upstream binary. (Having a library print to std::cerr is extremely fishy.) The "build system" is weird, to say the least. I have nothing against hand-written makefiles per se, but these are simply over-engineered. They try to be platform-agnostic, yet at the same time they include hard-coded paths to locations of libraries on the upstream authors system. Also, the seqan code is piped through a 600-lines-Python-script to produces "forwards". (I don't even …) On 05.04.2016 14:45, Andreas Tille wrote: > On Sat, 25 Apr 2015 08:52:52 +0200 Andreas Tille wrote: >> On Sat, Apr 25, 2015 at 05:30:39AM +0300, johnhom...@gmail.com wrote: >>> I couldn't get it to link, because the authors apparently never heard >>> of autotools. Generally, those handwritten Makefile's just.. made me >>> cry. >> >> +1 +1 (See above) >> >> However, if we really want automake on these old projects we probably >> need to add it ourselves. I did so in the past for living projects and >> it was adapted upstream but I'm not sure here. I am unsure if this is feasible w.r.t. to the weird hacks implemented in the build system. > > The current status is: > > 0. The code seems to be orphaned / unmaintained since 2011. > 1. Mugsy contains a *patched* version of MUMmer 3.20. I took over > those changes to the Debian MUMmer 3.23 package that sounded > sensible I have some extra patches for those tools, making them up to ten times faster. Will commit in due course. > 2. Mugsy also contains a code copy of some files of an old seqan > version. Most of these seem to be not needed and are removed > inside get-orig-source script > > Somehow the removal of the seqan files was a bad idea since when trying > to build against Debian packaged seqan I was running into several errors > which was the reason for my ask for help close to one year ago. For porting mugsy to a newer seqan version you'd need one of the seqan authors from 2011 willing to waste a or two week of their lifes at debugging crazy error messages. > > Since my colleagues stalled the request for the installation of Mugsy I > stopped my effort into this but the topic came up recently again. I > wonder what might be the best way to accomplish the wish to package mugsy: > >1. Go with the seqan code copy? It has to be patched first, to provide the same functionality as the upstream build (see above). >2. Find some modern replacement that is better regarding code > maintenance as well as functionality / speed. > I can not really imagine that the last 5 years did not brought > up something better. > My advise: drop mugsy entirely. It is just not worth it, waisting any more time on it. Also, according to the study [1], mugsy has inferior quality to other tools. Best, Fabian [1]: http://www.ncbi.nlm.nih.gov/pubmed/25273068
Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))
Hi Fabian, On Tue, Apr 19, 2016 at 12:29:59PM +0200, Fabian Klötzl wrote: > Hi Andreas, > > I spent the last few weeks meandering in the murky marshes of the mugsy > source code; It is a monstrosity. > > Before answering to your individual points I'd like to stress that I > *literally* spend days trying to compile mugsy with seqan 1.3 which > comes with Ubuntu 14.04 LTS. A hundred changes in, I gave up. Most of > the time, the compiler produces console-filling warnings, overflowing > with templates and hiding the actual problems. > > Next, I built mugsyWGA with the given seqan code, which succeeded. But I > have reason to believe the included code is not the one used to produce > the binary in the tarball: The seqan library code produces debug output > which does not appear in the upstream binary. (Having a library print to > std::cerr is extremely fishy.) > > The "build system" is weird, to say the least. I have nothing against > hand-written makefiles per se, but these are simply over-engineered. > They try to be platform-agnostic, yet at the same time they include > hard-coded paths to locations of libraries on the upstream authors > system. Also, the seqan code is piped through a 600-lines-Python-script > to produces "forwards". (I don't even …) Thanks a lot for the energy you have put into this code. > On 05.04.2016 14:45, Andreas Tille wrote: > > On Sat, 25 Apr 2015 08:52:52 +0200 Andreas Tille wrote: > >> On Sat, Apr 25, 2015 at 05:30:39AM +0300, johnhom...@gmail.com wrote: > >>> I couldn't get it to link, because the authors apparently never heard > >>> of autotools. Generally, those handwritten Makefile's just.. made me > >>> cry. > >> > >> +1 > > +1 (See above) > > >> > >> However, if we really want automake on these old projects we probably > >> need to add it ourselves. I did so in the past for living projects and > >> it was adapted upstream but I'm not sure here. > > I am unsure if this is feasible w.r.t. to the weird hacks implemented in > the build system. I also think that it might be a waste of time adding automake to a dead project. > > The current status is: > > > > 0. The code seems to be orphaned / unmaintained since 2011. > > 1. Mugsy contains a *patched* version of MUMmer 3.20. I took over > > those changes to the Debian MUMmer 3.23 package that sounded > > sensible > > I have some extra patches for those tools, making them up to ten times > faster. Will commit in due course. Cool. Just ping me for sponsering. > > 2. Mugsy also contains a code copy of some files of an old seqan > > version. Most of these seem to be not needed and are removed > > inside get-orig-source script > > > > Somehow the removal of the seqan files was a bad idea since when trying > > to build against Debian packaged seqan I was running into several errors > > which was the reason for my ask for help close to one year ago. > > For porting mugsy to a newer seqan version you'd need one of the seqan > authors from 2011 willing to waste a or two week of their lifes at > debugging crazy error messages. We can't probably gather a sufficient amount of money to bribe anybody to do this horrible job. > > Since my colleagues stalled the request for the installation of Mugsy I > > stopped my effort into this but the topic came up recently again. I > > wonder what might be the best way to accomplish the wish to package mugsy: > > > >1. Go with the seqan code copy? > > It has to be patched first, to provide the same functionality as the > upstream build (see above). Once there were patches posted to this list[2] - are you aware of these? > >2. Find some modern replacement that is better regarding code > > maintenance as well as functionality / speed. > > I can not really imagine that the last 5 years did not brought > > up something better. > > My advise: drop mugsy entirely. It is just not worth it, waisting any > more time on it. Also, according to the study [1], mugsy has inferior > quality to other tools. Thanks for the summary I'll foreward for further discussion. Kind regards Andreas. > [1]: http://www.ncbi.nlm.nih.gov/pubmed/25273068 [2] https://lists.debian.org/debian-med/2015/04/msg00036.html -- http://fam-tille.de
Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))
Hi, On 19.04.2016 14:03, Andreas Tille wrote: > On Tue, Apr 19, 2016 at 12:29:59PM +0200, Fabian Klötzl wrote: >> Hi Andreas, >> >> I spent the last few weeks meandering in the murky marshes of the mugsy >> source code; It is a monstrosity. >> >> [ … lots of whining … ] > > Thanks a lot for the energy you have put into this code. Yeah, I was lucky that “improving mugsy” was supposed to be my next big project at work. Little did we know I had to get past “compiling” first. >>> The current status is: >>> >>> 0. The code seems to be orphaned / unmaintained since 2011. >>> 1. Mugsy contains a *patched* version of MUMmer 3.20. I took over >>> those changes to the Debian MUMmer 3.23 package that sounded >>> sensible >> >> I have some extra patches for those tools, making them up to ten times >> faster. Will commit in due course. > > Cool. Just ping me for sponsering. I guess it makes sense, to move the packaging to git, first. >> It has to be patched first, to provide the same functionality as the >> upstream build (see above). > > Once there were patches posted to this list[2] - are you aware of these? Yes, I had seen them; But the rest of the code still is abysmal. The patches are a drop in the ocean, basically. >>>2. Find some modern replacement that is better regarding code >>> maintenance as well as functionality / speed. >>> I can not really imagine that the last 5 years did not brought >>> up something better. >> >> My advise: drop mugsy entirely. It is just not worth it, waisting any >> more time on it. Also, according to the study [1], mugsy has inferior >> quality to other tools. > > Thanks for the summary I'll foreward for further discussion. Cheers, Fabian >> [1]: http://www.ncbi.nlm.nih.gov/pubmed/25273068 > > [2] https://lists.debian.org/debian-med/2015/04/msg00036.html >
Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))
On Tue, Apr 19, 2016 at 02:40:34PM +0200, Fabian Klötzl wrote: > > Yeah, I was lucky that “improving mugsy” was supposed to be my next big > project at work. Little did we know I had to get past “compiling” first. :-) > >> I have some extra patches for those tools, making them up to ten times > >> faster. Will commit in due course. > > > > Cool. Just ping me for sponsering. > > I guess it makes sense, to move the packaging to git, first. Huh? Its at git://anonscm.debian.org/debian-med/mugsy.git > > Once there were patches posted to this list[2] - are you aware of these? > > Yes, I had seen them; But the rest of the code still is abysmal. The > patches are a drop in the ocean, basically. :-( Kind regards Andreas. -- http://fam-tille.de
Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))
On 19.04.2016 14:53, Andreas Tille wrote: > On Tue, Apr 19, 2016 at 02:40:34PM +0200, Fabian Klötzl wrote: I have some extra patches for those tools, making them up to ten times faster. Will commit in due course. >>> >>> Cool. Just ping me for sponsering. >> >> I guess it makes sense, to move the packaging to git, first. > > Huh? Its at > > git://anonscm.debian.org/debian-med/mugsy.git > Yeah, but you ported those tools to the MUMmer package, which is still on SVN according to https://tracker.debian.org/pkg/mummer
Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))
Hi Fabian, On Tue, Apr 19, 2016 at 02:59:15PM +0200, Fabian Klötzl wrote: > >>> Cool. Just ping me for sponsering. > >> > >> I guess it makes sense, to move the packaging to git, first. > > > > Huh? Its at > > > > git://anonscm.debian.org/debian-med/mugsy.git > > Yeah, but you ported those tools to the MUMmer package, which is still > on SVN according to https://tracker.debian.org/pkg/mummer Ahhh, you are right - we were talking about mummer. Feel perfectly free to move it to Git or ask me to do so and I'll do in the next couple of hours. Kind regards Andreas. -- http://fam-tille.de