On Fri, Apr 1, 2011 at 9:12 AM, Christian Stimming <stimm...@tuhh.de> wrote:
> Zitat von John Ralls <jra...@ceridwen.us>: > >> I estimate the effort in the following way: >>> >>> (AVG_of_branching * number_of_functions * >>> time_to_test_one_branch_in_minutes)/(minutes_in_hour * >>> number_of_working_days). >>> Avg of branching in function is something that i get by dividing code >>> complexity number (3729) by number of functions, (...) >>> >> >> Like I said, you're the only one at this point who knows how fast you can >> code. But your calculations are a bit, um, overly precise. >> > > I agree with John on the "overly precise" bit. However, I don't think this > is a problem at this point in time at all. > Couldn't agree more. Measurements in software engineering become kind of speculative when it comes to time/effort estimation. But still it's the only way to at least try to see the "big picture". John, I'm using C and C++ Code Counter to evaluate complexity. And I guess it performs some very similar calculations to those you did, because the numbers we get are very close 3600 and 3729. The difference is in hours per week, I count it as 40 hours/week :) For your project we can simply confirm that the goal of "full unittest > coverage of all of libqof" is too ambitious for GSoC. Doing the complexity > estimations is one out of several useful ways to tell up front whether the > task can or cannot be done, and it is also a valid part of such a GSoC > project. Thanks for the numbers :-) > > I agree with John that you should pick a useful subset of libqof, and this > way, the project will surely fit inside GSoC again. > > As for how to find the "useful subset": I've created a list of libqof's > symbols which are used from the rest of gnucash (attached) with usage count. > This list of used symbols has 346 entries, whereas the list of libqof's > exported symbols contains 524 entries. This is already a strong indication > that libqof might contains 524-352=172 functions which are unused throughout > gnucash. Following my remarks in my last message I'd say almost all of those > 176 unused functions should be removed anyway, which means your project size > might already reduce into useful ranges. > > Note: I've done this for *symbols*. A symbol corresponds to an exported > function. The libqof code might provide more functions to the rest of > gnucash which are still used but are not a symbol. For example, all macros > and all enums are provided to the rest of gnucash but are not symbols. > Similar for inline functions even though I don't know whether we actually > use those. The details for my research is shown below. > > For now, I'd propose you should go ahead in writing up your application, > and we can just confirm we will find a useful subset of libqof to be covered > that will be doable within GSoC. > Let me get it right, will you provide me with the subset before the application deadline (April 8)? Or I continue to research by myself and come up with more or less precise estimations. I already submitted the draft of proposal today. It's almost complete, except for assessment part. You should be able to check it out through gsoc application. > Regards, > > Christian > > > # Create list of symbols exported from libqof in file "exportedsymbols" > nm -A src/libqof/qof/.libs/libgnc-qof.so | grep ' T ' > exportedsymbols > > # Find all non-libqof binaries of gnucash > L=`find . -name '*.so' | grep -v libgnc-qof` > L="$L src/bin/.libs/gnucash" > > # For each other binary, lookup the imported (unresolved) symbols, grep > those > # that are from libqof, then sort the resulting list and count by > occurrence > for A in $L ; do nm $A | grep ' U ' | sed 's/^.* \([^ ]*\)$/\1/' | grep > -wFf- exportedsymbols | cut -d: -f2 ; done | sort | uniq -c | sort -nr > > all-qof-usage > > One more thing. Don't know if I have to inform you that I was able to build application from source and run it. But anyway I did it :) And big thanks to you guys for comprehensive and fast feedback you provide. You are being more than helpful! Saluti, M.Chochlov _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
