Re: GSoC2011
Dear ?ukasz, thank you for your interest in working with gnucash in the GSoC 2011 program. Did you already build gnucash from SVN? If yes, you can already experiment with some test changes in the GUI to see how working with the code will feel like. As for your explained features: It will be a good proposal to work on an alternative GUI. Your GSoC application should be a bit more specific in terms of the goals you have in mind. E.g., you should create a mockup of your GUI proposal (e.g. in Qt designer) and explain how your proposal will be better than what is currently there, or how your proposal fits better to specific user requirements than the current GUI. Also, your export idea is a good goal as well. This is a different task than the GUI work, but nevertheless a good idea, as the goal is quite clear. You will have several different technologies available for writing such an exporter. Some python script inside gnucash is one possibility http://lists.gnucash.org/pipermail/gnucash-devel/2011-March/031506.html , but C code or C++ code (either in cutecash with qt or src/optional/gtkmm with gtkmm) or Scheme script is possible as well. You can pick one of those options for your proposal, but keep in mind another option might turn out to be better during your work, in which case you will have the option to switch to the other technology. Zitat von ?ukasz Spas : (...) Is there any possibility in this project to put my own ideas? Sure there is. Your ideas are a good start for your application. If you extend your application on the points mentioned above, I believe this will be a good proposal to the GSoC team. Best Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems getting python console to launch
Dear Emil, Zitat von Emil Kantis : I must've missed the documentation regarding the python-specific build options (--enable-python in ./configure), or maybe it's obvious to people with experience. No, it's not obvious. Sorry for not mentioning it earlier. It would have been visible from the output of "./configure --help", but that output is rather unintuitive to read. After running ./configure --enable-python --enable-compile-warnings --prefix=/opt/gnucash/ make clean make make exits with the following error swig-app-utils-python.c: In function 'SwigPyObject_richcompare': swig-app-utils-python.c:1519: error: dereferencing pointer 'res' does break strict-aliasing rules Basically this says the auto-generated C code (as generated by SWIG) is refused to be compiled by your gcc compiler in your available version. Things to try: If you configure without the --enable-compile-warnings, maybe this warning/error goes away? Then: What is your swig version and your gcc version? I have gcc-4.4 and swig-1.3.6 (somewhat old, though) and I didn't use --enable-compile-warnings, and I haven't seen this error so far. Perhaps upgrading to a newer SWIG will solve this problem, in case the configure argument removal doesn't help. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GSoC Proposal: Live news feed from financial newspapers
Dear Ajay, Zitat von Ajay Thomas : I didn't quite get the difference between Menu only Plugins and Content Plugins, the difference in functionality between the two. I looked into gnc-plugin-bi_import.c source code under plugins but it still didn't answer my doubt. I don't think there is any difference. Also, the "bi_import" code is rather new and probably not so good as an example - I would recommend looking at the src/import-export/aqbanking/ code as an example because it has received multiple developers' iterations of code cleanup and improvements. (Incidentally, I also know that code much better, so I can answer questions there much better as well.) I don't think there is anything like a "content plugin". There is a chance of some name confusion, because there is the "gnome-utils/gnc-plugin-page.h" object but this doesn't necessarily have to be tied to a "plugin". The correct naming is used for "gnome-utils/gnc-plugin.h" - that object is a GObject-derived class which represents one loadable module, with init and fini functions, that will usually add some GtkAction menu items to the gnucash menus, but additionally it could add some hooks at engine/gnc-hooks.h or event handlers at libqof/qof/qofevent.h for specific events. Then there is gnome-utils/gnc-plugin-page.h. This is meant for a plugin that not only has some GtkActions, but additionally it will want to display data in a tab window inside the gnucash main window. If the plugin wants to implement such a tab window on its own, from my understanding the gnc-plugin-page.h supplies a useful framework to manage all the dynamic menu items that are specific to that tab window. The plugins can use such a gnc-plugin-page.h but they don't have to. I am currently going through the src/optional/gtkmm. I also looked into the gnucash report renderer using webkit (src/html/gnc-html-webkit.c) and I have a small doubt regarding implementation of my proposal using webkit. Will it be coding html and Javascript codes in a webkit c file? The recent discussion with javascript in the reports http://lists.gnucash.org/pipermail/gnucash-devel/2011-March/031509.html were all about some code that generates a HTML page with embedded javascript, including loading of further HTML and/or javascript files from the gnucash installation path. This means your Internet-related ideas about a live feed could be implemented by writing a HTML/javascript page just like you would write one for a web browser, then writing some very short gnucash plugin code that just opens a webkit window, loads your HTML page (from somewhere of gnucash's installation path), and the rest is done by your javascript code that is embedded in that HTML page. This is just one implementation option. Other options exist as well. Last, I would like to know, if I have to come to a conclusion about which technology I am going to use before the application deadline (April 8). I feel there won't be enough time by then to actually come to a conclusion about the implementation to be used. I intend to study thoroughly and develop some test plugins using both gtk widgets and webkit window before I can actually come to a conclusion. This is completely fine. After all, trying more than one technology is already an important part of the project on its own, so it can be done during the summer and not before the application. I'm just explaining the availability of different options so that you have that in mind during the project. For now, it is fine to do some more experiments with one of the technologies, then explain your already observed advantages and disadvantages in your application. If your application is accepted, you can continue with your initially chosen technology, but for each disadvantage, you have the option to either live with it or to decide to try a different technology in case that disadvantage is grave enough. I mean, it is a good situation for you! You have your goal in mind, and you are not stuck to one single technology to reach that goal but instead you already know there are multiple different ways to reach that goal. If there were only one technology available, and after half of the project you found out some unsurmountable difficulties, you would be stuck - but due to the availability of various options, you already know you will have back up technologies available. There are other projects or goals where this is not the case, so this situation should be more comfortable for you. Best Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GSOC] Data model unit testing
Zitat von John Ralls : I came up with some assessments regarding the project. More in detail: - Different measurement tools calculate about 16-17k lines of code in libqof module. - Number of unique functions is ~800 and ~ 500 of them are public, that is available to other packages. Your assessment is fine. If getting LibQof fully tested is what you think you can get done in the scope of GSoC, then that's the right target. After all, at this point you're the only one here who knows how fast you can work, and frankly you're probably understimating the complexity. While a lot of those functions are simple setters and getters, there are also functions that are over 100 lines long and will need many tests run many times to fully exercise the different paths. Some of those will need to be refactored in order to get at the intermediate results for good testing. There are also interfaces (e.g., Backend) which will need mocks to exercise the paths in the interfaced code, and I expect that you'll want to mock parts of Qof itself while testing other parts to keep complexity under control. It's plenty of work to get done in ~90 days. I completely agree with John here. Additionally, I would like to point out that some of the libqof functions might turn out to be unused throughout gnucash. If you or we encounter any of those functions, we can disable them immediately and not spend any further unittesting effort on them. The initial design of the "libqof" module by Neil Williams had the intention of using that code as a library from several independent projects. From that time, several functions might still exist which were never useful for gnucash and are subsequently unused. The best decision about those functions is to throw them out immediately such as here http://svn.gnucash.org/trac/changeset/20402 because if they're unused, they are also untested for a very long time and have a high probability of being wrong in the first place. Just throw them out. I'm making good progress on the Gir2Umi program, so I hope to have a skeleton UML model in another week or so. Once we have that we can assess how much hand-modelling we need to do. There's no real priority within LibQof. It's at the middle of Gnucash and in the way of some important changes that we need to make, and we need to be sure that we don't break anything when we make those changes. That's what the tests are for. It seems to me that that should make a pretty clear goal for your application, too. Indeed. Thanks for the UML modelling work - I'm curious how this is going to look like when it's ready :-) Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Initial Draft application for Python Scripting Engine
Dear Rahul, Zitat von Rahul Gaur : I've made some corrections to my application.Is it better now ?what more should I add ..? thanks for the additions. However, the basic problem in your application has not received much of an improvement: The main parts of your text are just some "generic programming project" description, but not at all specific to gnucash. Hence, from your applications it is not yet obvious whether you already have spent time and thinking on how your goals can be implement *specifically* in the gnucash project. I mean, from our point of view you can start working with gnucash nevertheless, but the GSoC staff that takes the final decision on your application might want to see further evidence that you've already got to know the gnucash project specifically. Also, the sentence "reporting engine,which primarily involves migrating all of the current reporting scripts to python" is grossly underestimating the time of "migrating all reports" and hence is rather unrealistic. Instead, you should *now* decide on one or two specific things that you will want to migrate to python or implement in python. User-visible things. Apart from this I've thinking of introducing a feature so that generated reports can directly be exported to some cloud service so that user have the access to reports even on a report system.If any thing similar to this is in the loop please let me know. Currently nobody is working on anything similar. Your idea is good. Maybe you should focus your application more on this particular idea and feature. I believe this will result in a better application than discussing the abstract notion of "working on python engine in gnucash". Incidentally, your "upload" feature (either for the data file, or for generated reports, or both) might be implemented in python as well, once you've added some minor missing parts to the python module in gnucash. Hence, probably your application should emphasize your feature idea as the main goal, and mention the python engine only as a way to implement your main goal. I think this will make your application better. Best Regards, Christian *Basic Information* Student name:Rahul Gaur Location: Meerut City , UP ,India, Home Town :New Delhi ,India Email:rahul@gmail.com Instant messaging contact details (Skype or similar):iamaregee/iamaregee2 on IRC (irc.ubuntu.com) Phone : +91-8755426793 *Background/Programming Information:* I've experience of building GNU cash from source via SVN on a linux system.A few years ago,I learned C++ and Java as a part of my School curriculum.While this is my first year in college ,Now I am pursuing Bachelors in Engineering and my Major is in Computer Science.So I am learning C and Python here in College.By the time GsoC 2011 starts ,I will be done with my end semester exams and equiped with skills to work full time on coding,so I wan't to do some good project in order to strengthen my foundations in understanding of Sofware Systems. *What project in GnuCash would you like to work on?* I would Like to work on Python reporting and Scripting engine for Gnu cash over my summer vacations. *What will be the result of your project :* Upon the successful development of the scripting engine ,primarily all the current reporting scripts will be migrated to python plus it will open the possibilites of implementing various new financial reports as python has a vast accounting library support.For instance libraries like matplotlib, PyCompta can be used to genrate graphs and reports in xml,html and pdf formats.While in the long run,python being a more common scripting language,it will be easier for developers to contribute to the code and improve the efficiency. *How do you propose to solve the problem(s) posed in the project you'd like to work on?* *Project Schedule :* While I plan to follow the description given in the idea of the proposal.I've already familiarised my self with the working of GNU cash (v 2.4.4 SVNr20419).I took a brief idea of sample python scripts.As I've already stated , I've my University exams from 8th to 30thof May ,so during this period I will be in touch with the GNUCash community through emails.During the time before exams ,I hope to : - Get to know the mentor and other community members. - Going through Devloper Docs. - Understand working of the reporting engine. - Brainstorm plans with the community. After I am Done with my exams , I plan to Procede as follows : *Program time-line :* - To create a more accurate programing timetable. - Initial step would be to work on already included python patch in order build the scripting engine which interacts with gnu cash and do the functions like accessing the entries in the Database.This will be followed by working on the reporting engine,which primarily involves migrating all of the current reporting scripts to python.This mil
Re: Question Regarding Saving Custom Reports
Zitat von Geert Janssens : On woensdag 30 maart 2011, David T. wrote: It seems to me that some developer in the recent past changed the underpinnings of the reports system such that they are now identified to the system using a GUID, rather than the human-readable report title. Given that fact, is it really necessary still to require users to rename a report just to save it? While I understand that it can get confusing to a user if they have multiple "Transaction Report" entries in the custom reports list, it seems to me that this would be a situation the user should have the option of remedying (by learning to rename their reports as they see fit), rather than enforcing it by the program. Furthermore, since custom reports are no longer placed in the menu tree, it would seem to me that unique report names are even less critical. David These are valid point in my opinion. Unfortunately, the reporting stuff is not my area (at all), so while I agree with you I'm not very inclined to try and fix that. Perhaps a good suggestion for the uservoice requests ? Agreed. David's ideas are very valid. The "custom report" choice window could easily be extended so that not only the report name is shown, but additional information so that different reports can be distinguished even though the name might be identical. However, I'm not inclined to work on this area myself as well. @David: Create a write-up of your proposal in bugzilla or in http://gnucash.uservoice.com/ and then hope that someone finds this idea so exciting that they will actually implement it... sorry for this reply. http://wiki.gnucash.org/wiki/Bugzilla#Stock_messages Best Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems getting python console to launch
Christian Stimming writes: > Things to try: If you configure without the --enable-compile-warnings, > maybe this warning/error goes away? Then: What is your swig version > and your gcc version? I have gcc-4.4 and swig-1.3.6 (somewhat old, I'm sure you don't mean "1.3.6", the minimum is 1.3.31. Maybe you mean 1.3.36? (I have 1.3.40 on Fedora 12) -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems getting python console to launch
Am Donnerstag, 31. März 2011 schrieb Derek Atkins: > Christian Stimming writes: > > Things to try: If you configure without the --enable-compile-warnings, > > maybe this warning/error goes away? Then: What is your swig version > > and your gcc version? I have gcc-4.4 and swig-1.3.6 (somewhat old, > > I'm sure you don't mean "1.3.6", the minimum is 1.3.31. Maybe you mean > 1.3.36? (I have 1.3.40 on Fedora 12) I meant 1.3.36. On another computer I have swig-1.3.40 and also gcc-4.4. Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems getting python console to launch
Christian Stimming skrev 2011-03-31 18:36: Am Donnerstag, 31. März 2011 schrieb Derek Atkins: Christian Stimming writes: Things to try: If you configure without the --enable-compile-warnings, maybe this warning/error goes away? Then: What is your swig version and your gcc version? I have gcc-4.4 and swig-1.3.6 (somewhat old, I'm sure you don't mean "1.3.6", the minimum is 1.3.31. Maybe you mean 1.3.36? (I have 1.3.40 on Fedora 12) I meant 1.3.36. On another computer I have swig-1.3.40 and also gcc-4.4. Regards, Christian Thanks for your attention, I'm currently running swig 1.3.40, gcc 4.4.5 on ubuntu 10.10 iirc. I can come online on the IRC channel for smoother troubleshooting if possible. Regards, Emil ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Budget, cash flow and scheduled transactions - roadmap?
Hi, I would like a budgeting system that allows me to combine my scheduled transactions, budget amounts and asset balances to allow me to plan my future spending. This is for managing personal finance rather than business accounting which has its own rules and language. The current budget does not do that for reasons that were discussed among the developers of GnuCash several years ago. In the end we got separate budget and scheduled transactions systems. Is there any ongoing discussion of how this might be developed further now we have the two systems in the codebase? I am not a programmer so I do not know where to start in trying to develop patches for what I would like to see but I have been around computers a lot and have dabbled with some database work so I have a reasonable notion of most of the backend concepts involved. I would like to help where I can and I have some ideas of what I think might work and how to implement it. Where do you think the most appropriate place to post my ideas would be? Yours, Nick ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GSOC] Data model unit testing
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, time to test one condition (branch) takes me about 10 minutes. All above brings me to (4.2875 * 866 * 10)/(60*8) = 77.35 working days. Now google allocates 3 months of coding that is 66 working days (being realistic :). 77 and 66 don't match at all. What I propose is to change the goal to "cover at least 80% of the libqof module". Then we get (4.2875 * (866 * 0.8) * 10)/(60*8) = 61.88 working days. In the worst case this will still provide a pretty cool code coverage (as 80% is considered a standard in SW engineering) and I will be able to finish my project in time. In the best case the 100% coverage will be done. Let me know if such goal modification is ok with you guys. In that case I'll have all the requirements gathered from you and submit the project. Saluti, M.Chochlov On Thu, Mar 31, 2011 at 10:20 AM, Christian Stimming wrote: > Zitat von John Ralls : > >> I came up with some assessments regarding the project. >>> More in detail: >>> - Different measurement tools calculate about 16-17k lines of code in >>> libqof module. >>> - Number of unique functions is ~800 and ~ 500 of them are public, that >>> is available to other packages. >>> >> >> Your assessment is fine. If getting LibQof fully tested is what you think >> you can get done in the scope of GSoC, then that's the right target. After >> all, at this point you're the only one here who knows how fast you can work, >> and frankly you're probably understimating the complexity. While a lot of >> those functions are simple setters and getters, there are also functions >> that are over 100 lines long and will need many tests run many times to >> fully exercise the different paths. Some of those will need to be refactored >> in order to get at the intermediate results for good testing. There are also >> interfaces (e.g., Backend) which will need mocks to exercise the paths in >> the interfaced code, and I expect that you'll want to mock parts of Qof >> itself while testing other parts to keep complexity under control. It's >> plenty of work to get done in ~90 days. >> > > I completely agree with John here. > > Additionally, I would like to point out that some of the libqof functions > might turn out to be unused throughout gnucash. If you or we encounter any > of those functions, we can disable them immediately and not spend any > further unittesting effort on them. The initial design of the "libqof" > module by Neil Williams had the intention of using that code as a library > from several independent projects. From that time, several functions might > still exist which were never useful for gnucash and are subsequently unused. > The best decision about those functions is to throw them out immediately > such as here http://svn.gnucash.org/trac/changeset/20402 because if > they're unused, they are also untested for a very long time and have a high > probability of being wrong in the first place. Just throw them out. > > > I'm making good progress on the Gir2Umi program, so I hope to have a >> skeleton UML model in another week or so. Once we have that we can assess >> how much hand-modelling we need to do. >> >> There's no real priority within LibQof. It's at the middle of Gnucash and >> in the way of some important changes that we need to make, and we need to be >> sure that we don't break anything when we make those changes. That's what >> the tests are for. It seems to me that that should make a pretty clear goal >> for your application, too. >> > > Indeed. Thanks for the UML modelling work - I'm curious how this is going > to look like when it's ready :-) > > Regards, > > Christian > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
An alternative GUI, a detailed proposal - GSOC 2011
Key-Implementations: Unified Transaction Dialog, First Person Overview, Backlog fetching, Auto-Suggest. Hello, I am Nitish. I am interested in developing an alternative GUI for GnuCash. Using Qt as the UI framework to integrate and provide rich interactive front end for GnuCash core, through CuteCash.. First I would like to list out the goals which I envision from a general user's perspective. Then later, I talk about the specific technical implementations that I would like to contribute to the project within the period of GSOC. Deliverables and Timeline present at the end with a brief description on what I have done till now. Goals: = 1) To use the current prototype to integrate existing report views using webkit. 2) To focus on most used interfaces and enhance them, with a goal to better integrate and make it more user friendly. 3) Implement a "dynamic and interactive" reporting view, based on an idea of First Person Dynamic Reporting. 4) Document development activities and project workflow and layout, so as to encourage other developers to easily get in and contribute. Also document user ideas and suggestions about UI obtained during the period. 4) Develop ideas and discuss on how the vast library of Qt can be used to rapidly extend the functionality of CuteCash. Description of Goals: === 1)To create a basic usable version of CuteCash by offering atleast two report views. In practice, after creating two report view, it would be easier to create more types within project period. But for the sake of numerical deliverables, 2 is chosen. 2)The next immediate goal is to enhance the front end of data entry system for transactions (transaction entry dialog box). Working on the idea to provide a central "unified interface" to enter transactions "to and from different accounts". Also to provide a fluid and rich experience to enter data into fields with three specific areas to improve on: a) to users who prefer to use only the keyboard b) to users who prefer use the mouse 3) Make possible to enter multiple entries involving multiple accounts through this single interface + taking care of point a) and b). Here is a mockup of the dynamic sort field for Transfer From / To fields, it is a rough draft done in a limited time, designed to put out the idea on this email: http://cdn.nishmu.com/cutecash/mockups/dynamic-search-drop-down.png The field dynamically matches account name based on first few characters entered. The idea behind this. Currently the option to select From / To is non intuitive in transaction dialog. Also in the tab based entering method, there is redundancy of category name appearing in front of each account name in the From / To fields, making it difficult to select the appropriate account name quickly. This can be avoided by a tree based view + dynamic search. Here is a rough mockup of the unified transaction entry dialog: http://cdn.nishmu.com/cutecash/mockups/unified-transaction-entry-dialog.png The "Another" button would allow a user to rapidly feed entries where the >From - To accounts remain the same. A user can basically cycle through the process of 4 tabs and 1 enter key to feed entries one after other. A possible issue would be if user needs to enter transactions for different dates. This can be solved by including date field inside "Basic Info" group at the expense of extra tab key to cycle through. A more better way is to offer the choice to user by making it a user preference setting. 3)To integrate (with unified transaction dialog created above or / and on an independent tab) a new feature called First Person Overview or First Person Dynamic Reporting. The idea behind this is that of a human being's memory. A person can very well remember what he/she has spent/earned of the past few days (like previous 2 days). If that person were to document his transactions on a physical book, it would follow a specific pattern most similar to General journal reporting or diary writing. The idea is to integrate this common human way of visualising and present these entries below transaction dialog. So for example a user can enter a transaction and its dynamically updated below it in the "First Person Overview" (FPO). This view will further allow as a central point to open up various types of reports and charts. This would either open up in a new tab or a popup depending on the amount of reporting the user wishes to see. Implementation of pie charts in pop ups is one of the ideas being thought about first. Further, this FPO would implement backlog fetching (like in some irc clients like Quassel which fetch previous entries as and when we scroll up). The advantage is that there is no pre rendering and the need to generate a complete report. Here is a very rough mockup with details: http://cdn.nishmu.com/cutecash/mockups/first-person-overview-details.png Just plain mockup: http://cdn.nishmu.com/cutecash/mockups/first-person-overview.png The various reports that
Re: [GSOC] Data model unit testing
On Mar 31, 2011, at 1:02 PM, Muslim Chochlov wrote: > 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, time to test one condition > (branch) takes me about 10 minutes. All above brings me to (4.2875 * 866 * > 10)/(60*8) = 77.35 working days. Now google allocates 3 months of coding that > is 66 working days (being realistic :). 77 and 66 don't match at all. What I > propose is to change the goal to "cover at least 80% of the libqof module". > Then we get (4.2875 * (866 * 0.8) * 10)/(60*8) = 61.88 working days. In the > worst case this will still provide a pretty cool code coverage (as 80% is > considered a standard in SW engineering) and I will be able to finish my > project in time. In the best case the 100% coverage will be done. > Let me know if such goal modification is ok with you guys. In that case I'll > have all the requirements gathered from you and submit the project. 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. Here's how I'd do the estimate: You can get the actual number of branches with `egrep '(if|else|case)' src/libqof/qof/*.c | wc -l ` and get the actual number of branches (2674). Add the number of functions for the total number of simple tests (3580). Recognizing that we're estimating, call it 3600, which happens to be a very convenient number when dealing with minutes. A goodly number of those functions are simple getters and setters which don't need testing, but we can ignore that; the effect is less than an order of magnitude. Accepting your 6 tests/hour expectation (I think that that's ambitious, because it doesn't allow much time for writing fixtures and mocks) it's around 600 hours, or 10 weeks at 60 hours/week. GSoC allows 13 weeks, so I don't really see the problem. ;-) Actually, I do see a problem, as I mentioned: Writing 6 tests/hour is realistic for well-designed C++ where the functions are small, have no side effects, make good use of polymorphism, have minimal dependencies, and have no local variables which need to be tested. The real world isn't like that, and Gnucash is infinitely worse. The best of it (only a couple of files in libqof) is written in C using an obtuse we-can-write-object-oriented-code-in-C library (GObject); there's a lot of "GObject is a pain to set up so I'll go halfway there with homemade vtables, but no inheritance or polymorphism", and a generous helping of not very well structured normal C code in huge functions with lots of branching. There are internal and external dependencies, so tests will need fixtures and mocks to isolate the function-under-test from the outside. While I hope that you'll be inspired (and have time) to keep working on this after GSoC is over, we want to set you up for a successful GSoC project. I think we need to be looking at 25-30% slack in your goal to allow for fixturing, mocking, and refactoring... and while I don't have any real insight into what the Google folks are looking for, I think that it makes a stronger presentation (and a more measurable goal for writing your evals) to select some files in Qof and propose fully testing those files rather than to propose X% test coverage of the whole module. It's too easy to fudge a test coverage number (for example, by including silly tests, like testing the getters & setters). I'll troll through the LibQof sources tomorrow and propose a list of files; Christian may have some thoughts on which ones would be good candidates as well. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
