Then I think I'll stick to Hmmer3 implementation as far as GSoC is concerned. I hope the licensing issues are sorted out soon.
Thanks! -- *Dhruv Sharma* *Student B.E.(Hons.) Computer Science BITS, Pilani * *India* On Mon, Apr 2, 2012 at 9:00 AM, Scooter Willis <[email protected]> wrote: > I think HMMER implementation should be viewed as the source code of > interest. When they went from HMMER2 to HMMER3 significant changes in what > answer you get. > > On 4/1/12 8:15 PM, "Andreas Prlic" <[email protected]> wrote: > > >That could work in terms of license and would be an interesting > >feature to have. I am still slightly concerned that the scale of the > >project might be too big and it might be difficult to accomplish this > >during the limited time of the project. > > > >Andreas > > > >On Sun, Apr 1, 2012 at 2:32 PM, Dhruv Sharma <[email protected]> > >wrote: > >> Hi Andreas, > >> > >> In response to our last discussion, I would like to suggest porting > >>General > >> Hidden Markov Model (GHMM) library (http://ghmm.org/) from C to Java. > >> > >> The library is licensed under LGPL and is currently available as RC1 > >> version. The code is not very big and it is very much possible to port > >>100% > >> code to Java which would make it not only efficient in comparison to > >>use of > >> converters or JNI but also make it platform independent. > >> > >> Would it be possible to add this library to BioJava? > >> > >> If yes, I would surely like to work on it. > >> > >> > >> > >> > >> On Sun, Apr 1, 2012 at 11:24 PM, Andreas Prlic <[email protected]> > wrote: > >>> > >>> Hi Dhruv, > >>> > >>> We are quite flexible regarding the projects and what we are really > >>> looking for are sound projects and motivated students. As such our > >>> project suggestions are quite open. We will interact with accepted > >>> students from remote, so a certain degree of self-sufficiency will be > >>> required from the side of the student. > >>> > >>> If you already see tons of problems coming up during your initial > >>> assessment of the project, perhaps focus your proposal on something > >>> smaller and more achievable. There are quite a number of interesting > >>> algorithms out there and it does not have to be one of the ones > >>> suggested by us. > >>> > >>> Andreas > >>> > >>> > >>> > >>> On Sat, Mar 31, 2012 at 1:46 PM, Dhruv Sharma <[email protected]> > >>> wrote: > >>> > Hi, > >>> > > >>> > I am Dhruv Sharma, a senior undergraduate student pursuing > >>>B.E.(Hons.) > >>> > Computer Science at BITS, Pilani, India. > >>> > > >>> > I am very much interested in 'porting BLAST algorithm to Java' as a > >>>GSoC > >>> > 2012 project. I am proficient and primarily work using Java and C. > >>>Also, > >>> > I > >>> > have past experience of working in C++ before migrating to Java. > >>> > However, I > >>> > am new to GSoC and haven't used version control in the past. > >>> > > >>> > My recent project was based on developing a web application in Java > >>>for > >>> > posting data to remote CS-BLAST web > >>> > service<http://toolkit.tuebingen.mpg.de/cs_blast/> with > >>> > FASTA sequence, parse and auto-filter its results using the release > >>>date > >>> > from RCSB PDB <http://www.rcsb.org/pdb/home/home.do> and download > the > >>> > PDB > >>> > files. > >>> > > >>> > Since, the project aims at converting the legacy C/C++ code to Java, > >>> > already suggested approaches on the Bio-Java page and my observations > >>> > are:- > >>> > > >>> > 1) Using C++ to Java converters for 100% conversion. I have tried > >>> > converting the ncbi-blast-2.2.26 source code using a few freely > >>> > available > >>> > converters but all of them either crashed or failed to convert even > >>> > after I > >>> > resolved certain header file dependency issues that emerged. Most > >>> > failures > >>> > occurred at function calls to non-standard C++ libraries. > >>> > > >>> > 2) Using JNI as an alternative solution. JNI programming would be a > >>> > tedious task and would anyway require understanding of the purpose of > >>> > underlying C++ code. Hence,has little advantage over rewriting the > >>> > equivalent Java code. A significant advantage can be seen when there > >>>is > >>> > no > >>> > efficient Java alternative of the C++ code. However, platform > >>>dependence > >>> > would still exist. > >>> > > >>> > According to my understanding of the problem, a hybrid approach can > >>>be > >>> > taken up which includes using code converters for simpler files, > >>>manual > >>> > coding for tricky areas and using JNI for typical C++ code involving > >>> > non-standard libraries. But, I am still not clear about my exact > >>>course > >>> > of > >>> > action. > >>> > > >>> > Can you please tell me if my analysis of the problem is correct? > >>>Please > >>> > also comment on the feasibility of my suggested approach and please > >>>make > >>> > any suggestions as they would help me in improving my application > >>>draft > >>> > that I would soon be sharing for review. > >>> > > >>> > As BLAST is a collection of programs, so, keeping in mind the length > >>>of > >>> > code to be ported, can we work on certain selectively critical > >>>programs > >>> > in > >>> > it from the GSoC's perspective? > >>> > > >>> > > >>> > Thanks. > >>> > > >>> > -- > >>> > *Dhruv Sharma* > >>> > *Student > >>> > B.E.(Hons.) Computer Science > >>> > BITS, Pilani > >>> > * > >>> > *India* > >>> > _______________________________________________ > >>> > Biojava-l mailing list - [email protected] > >>> > http://lists.open-bio.org/mailman/listinfo/biojava-l > >> > >> > >> > >> > >> -- > >> Dhruv Sharma > >> Student > >> B.E.(Hons.) Computer Science > >> BITS, Pilani > >> India > >> > > > >_______________________________________________ > >Biojava-l mailing list - [email protected] > >http://lists.open-bio.org/mailman/listinfo/biojava-l > > _______________________________________________ Biojava-l mailing list - [email protected] http://lists.open-bio.org/mailman/listinfo/biojava-l
