Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))

2016-04-19 Thread Andreas Tille
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



Re: Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))

2016-04-19 Thread Fabian Klötzl
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))

2016-04-19 Thread Andreas Tille
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))

2016-04-19 Thread Fabian Klötzl
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))

2016-04-19 Thread Fabian Klötzl
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



Mugsy (Was: Seqan knowledge needed (Was: Help needed in C++ / seqan issue))

2016-04-05 Thread Andreas Tille
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: Seqan knowledge needed (Was: Help needed in C++ / seqan issue)

2015-04-25 Thread Andreas Tille
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



Re: Seqan knowledge needed (Was: Help needed in C++ / seqan issue)

2015-04-24 Thread johnhommer
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



Seqan knowledge needed (Was: Help needed in C++ / seqan issue)

2015-04-17 Thread Andreas Tille
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::StringSetTSequence, TSpec, 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::Graphseqan::AlignmentTStringSet, TCargo, TSpec , 
TLCB, TStringSet1, TNames, TGenomeNames, TVertexOrientMap, TIntervals, 
const
 seqan::MsaOptionsseqan::SimpleTypeunsigned char, seqan::Dna5_, 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::vectors_score alignLCBs(TGraph, TLCBs, 
TStringSet1, TStringSet2, TNames, TGenomeNames, TVertexOrientMap, 
TStream1, std::mapTName, std::vectorTLo
c , const seqan::MsaOptionsseqan::SimpleTypeunsigned char, seqan::Dna5_, 
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::MsaOptionsseqan::SimpleTypeunsigned char, seqan::Dna5_, TSc
ore, TLCBs, TVMap, TStream, TIMap)':
...


Any help is welcome

  Andreas.

[1] 

Help needed in C++ / seqan issue

2015-04-15 Thread Andreas Tille
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::SimpleTypeunsigned char, seqan::_Rna seqan::Rna'
 typedef SimpleTypeunsigned char,_Rna 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::SimpleTypeunsigned char, seqan::Rna_ seqan::Rna'
 typedef SimpleTypeunsigned char, Rna_ Rna;
 ^
In file included from mugsy/mugsy.cpp:36:0:
mugsy/rna_alphabet.h:185:20: error: redefinition of 'struct 
seqan::ValueSizeseqan::SimpleTypeunsigned char, seqan::Rna_ '
 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::ValueSizeseqan::SimpleTypeunsigned char, seqan::Rna_ '
 struct ValueSizeRna
^
In file included from mugsy/mugsy.cpp:36:0:
mugsy/rna_alphabet.h:186:20: error: redefinition of 'struct 
seqan::BitsPerValueseqan::SimpleTypeunsigned char, seqan::Rna_ '
 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

2015-04-15 Thread Gert Wollny
Hello Andreas, 

I did a 

debcheckout --user me 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::SimpleTypeunsigned char, seqan::_Rna seqan::Rna'
  typedef SimpleTypeunsigned char,_Rna 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::SimpleTypeunsigned char, seqan::Rna_ 
 seqan::Rna'
  typedef SimpleTypeunsigned char, Rna_ Rna;
  ^
 In file included from mugsy/mugsy.cpp:36:0:
 mugsy/rna_alphabet.h:185:20: error: redefinition of 'struct 
 seqan::ValueSizeseqan::SimpleTypeunsigned char, seqan::Rna_ '
  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::ValueSizeseqan::SimpleTypeunsigned char, seqan::Rna_ '
  struct ValueSizeRna
 ^
 In file included from mugsy/mugsy.cpp:36:0:
 mugsy/rna_alphabet.h:186:20: error: redefinition of 'struct 
 seqan::BitsPerValueseqan::SimpleTypeunsigned char, seqan::Rna_ '
  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

2015-04-15 Thread Andreas Tille
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



Re: Help needed in C++ / seqan issue

2015-04-15 Thread Andreas Tille
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

2015-04-15 Thread Gert Wollny
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