Hi We would like to do the project on improving Java bindings. It is a GSoC project, although I guess we can take it up as such. But before we go ahead, we would like to have some details as to how much work it would be and also how would we evaluate the work done. (compare test cases / compare java code with c++ code ?) Is there any way in which we can quantify the improvements made to the API? Lets hope our prof agrees to this project. If not, we'll have to think of something else. Regards, *Siddhant Mutha* Undergraduate Student Department of Computer Science and Engineering IIT Madras Chennai http://www.siddhantmutha.com/ <http:/www.siddhantmutha.com/> On Mon, Mar 10, 2014 at 5:17 AM, Olly Betts <olly at survex.com> wrote:> On Fri, Mar 07, 2014 at 10:05:08PM +0530, Siddhant Mutha wrote: > > We're a group of 5 CS undergrads. As a part of our Software Engineering > > course, we are required to work on a large scale software to understand > the > > design of such software. For this, open source is the best choice. > > We have around 1.5 months for the project (mid-March to April end) and > > would like to know whether there is any sort of work which can be taken > up > > by us. > > (For the benefit of other list readers who aren't on IRC, this was asked > first on IRC and I suggested asking on the list in case other people had > any good ideas). > > Having thought had a chance to think about it, I've come up with a > couple of fairly open ended projects, either of which would give you a > good idea of what working on a large scale piece of software is like, > yet offer a fairly gentle introduction (no need to understand the > whole system before you can start): > > * One possible project would be to set up a system using Xapian to index > and search a large number of documents, and use profiling tools to > identify bottlenecks in the code. > > Where you find code which is taking a lot of time, you can try to > improve the situation. > > * Another is to improve test coverage. We can generate reports of how > well our testsuite covers the code by using gcov and lcov - you can > see a regularly updated report here: > > http://lcov.xapian.org/ > > Currently we have around 90% of source code lines and 90% of functions > exercised by the testsuite, but it's quite uneven - many files are > over 90% but some are much lower. And coverage of branches (i.e. > whether a branch in the code is both taken and not taken during a run > of the testsuite) is rather poor. > > A useful project would be looking through the coverage report, and > finding places where writing a new testcase would improve coverage. > You can also try to fix any bugs found by doing this, or at least open > bug reports for them (we've found quite a few bugs in the past by > writing new testcases to improve test coverage). > > Do either of those appeal? > > If not, do you know what sort of work you're interested in doing? > > Cheers, > Olly >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xapian.org/pipermail/xapian-devel/attachments/20140311/8a8d4208/attachment-0002.html>
On Tue, Mar 11, 2014 at 08:50:14PM +0530, Siddhant Mutha wrote:> We would like to do the project on improving Java bindings. It is a GSoC > project, although I guess we can take it up as such.The timing is rather problematic - we've had at least four students already express an interest in that project idea for GSoC, and at least one has put in a significant amount of research already. I've no idea at this stage how many of those would result in proposals actually being submitted to us, or if any of the proposals would be good enough for us to want to accept, or how many slots we'll get from Google (I don't even know how many mentors we'll actually have). But if you're going to work on this, it doesn't seem sensible for someone to also be working on it as a GSoC project, so if we're going to do that we really need to withdraw the idea promptly and let the students who expressed an interest know and help them find other ideas to work on. However, from below it seems you need to get agreement from your professor, so I'd guess we may not even know for a few more days. My preference would be to find you something which isn't on the GSoC list, or at least something which we've not had interest in yet so we can remove it without messing GSoC students around. Perhaps implementing bindings for Go (http://golang.org/) would be a good project for you? It's an interesting language with some nice design ideas, and you'd probably find implementing a fresh set of bindings more interesting than trying to fix up the shortcomings of some existing bindings.> But before we go ahead, we would like to have some details as to how much > work it would be and also how would we evaluate the work done. (compare > test cases / compare java code with c++ code ?)For Java, you could also compare how compatible they are with the hand-wrapped JNI Java bindings, though I think "providing a clean Java-like API" is more important than such compatibility - there don't seem to be a lot of existing users of the Java bindings.> Is there any way in which we can quantify the improvements made to the API? > > Lets hope our prof agrees to this project. If not, we'll have to think of > something else.You could measure what proportion of C++ API methods can be used from Java or Go; also what proportion of wrapped methods are exercised by the testsuite of the Java or Go bindings. Cheers, Olly
Hi We had discussed yesterday about taking up issue 596 ( http://trac.xapian.org/ticket/596) as our project. As for our professors, they have approved it. Now, with regard to moving forward, what should be our next step? *Siddhant Mutha* Undergraduate Student Department of Computer Science and Engineering IIT Madras Chennai http://www.siddhantmutha.com/ <http:/www.siddhantmutha.com/> On Wed, Mar 12, 2014 at 8:23 AM, Olly Betts <olly at survex.com> wrote:> On Tue, Mar 11, 2014 at 08:50:14PM +0530, Siddhant Mutha wrote: > > We would like to do the project on improving Java bindings. It is a GSoC > > project, although I guess we can take it up as such. > > The timing is rather problematic - we've had at least four students > already express an interest in that project idea for GSoC, and at least > one has put in a significant amount of research already. I've no idea > at this stage how many of those would result in proposals actually being > submitted to us, or if any of the proposals would be good enough for us > to want to accept, or how many slots we'll get from Google (I don't even > know how many mentors we'll actually have). > > But if you're going to work on this, it doesn't seem sensible for > someone to also be working on it as a GSoC project, so if we're going > to do that we really need to withdraw the idea promptly and let the > students who expressed an interest know and help them find other ideas > to work on. However, from below it seems you need to get agreement from > your professor, so I'd guess we may not even know for a few more days. > > My preference would be to find you something which isn't on the GSoC > list, or at least something which we've not had interest in yet so > we can remove it without messing GSoC students around. > > Perhaps implementing bindings for Go (http://golang.org/) would be a > good project for you? It's an interesting language with some nice > design ideas, and you'd probably find implementing a fresh set of > bindings more interesting than trying to fix up the shortcomings of some > existing bindings. > > > But before we go ahead, we would like to have some details as to how much > > work it would be and also how would we evaluate the work done. (compare > > test cases / compare java code with c++ code ?) > > For Java, you could also compare how compatible they are with the > hand-wrapped JNI Java bindings, though I think "providing a clean > Java-like API" is more important than such compatibility - there don't > seem to be a lot of existing users of the Java bindings. > > > Is there any way in which we can quantify the improvements made to the > API? > > > > Lets hope our prof agrees to this project. If not, we'll have to think of > > something else. > > You could measure what proportion of C++ API methods can be used from > Java or Go; also what proportion of wrapped methods are exercised by the > testsuite of the Java or Go bindings. > > Cheers, > Olly >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xapian.org/pipermail/xapian-devel/attachments/20140313/0d1ba7fc/attachment-0002.html>