Challenging python coders: Who can create a gnucash-like GUI in python in a few weeks?
Dear all, We've been discussing various future directions for gnucash, including a switch to a different programming language for the GUI code [1]. GUI coding in C sucks. Because of this, I've experimented with C++/Qt and was able to write up a usable gnucash-like register window GUI in 2-3 weeks which already includes features that are unavailable in conventional gnucash [2]. I chose C++/Qt because I'm very familiar and productive with that platform. However, a scripting language might be even more suitable for writing the GUI code of a project like gnucash. The language Python is a particularly good candidate here because gnucash already has python wrappers for most of its underlying data type and storage code, thankfully provided by Mike Evans and others. See src/optional/python-bindings/ and the doxygen output [3] and the example scripts in python-bindings/example_scripts/, in particular scripts like simple_book.py: Loading an existing file, modifying some of the data, and writing again, all in 12 lines. Here's my challenge to coders who *are* familiar with GUI coding in python (because I'm not): Who of you is able to write up some python code that creates a gnucash-like GUI, using the existing python wrappers to re-use the data store of normal gnucash, but your python code is at least a thousand times more elegant than the previous code? And you won't need more than 1-2 weeks to achieve something where we can view our data files and enter new transactions, will you? I was able to do this in C++/Qt in four weeks; are you able to do it in python in two? If your results are convincing, I will join. I am extremely curious to see how python can drive the GUI of a large application like gnucash. I experimented in one direction; now I want to learn about other possible directions. In case the results turn out unconvincing - well, you cannot loose more than a little bit of time and we will all have learnt something about the potentials and limitations here. But if you achieve something convincing, you will of course gain unlimited bragging rights that python is the language of choice for discriminating hackers... [4] And now, let the coding begin! Best Regards, Christian [1] http://lists.gnucash.org/pipermail/gnucash-devel/2010-December/030516.html and thread [2] http://wiki.gnucash.org/wiki/Cutecash [3] http://svn.gnucash.org/docs/HEAD/python_bindings_page.html [4] http://en.wikipedia.org/wiki/ICFP_Programming_Contest#Prizes ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Challenging python coders: Who can create a gnucash-like GUI in python in a few weeks?
On 10 Jan 2011, at 12:24 PM, Christian Stimming wrote: We've been discussing various future directions for gnucash, including a switch to a different programming language for the GUI code [1]. GUI coding in C sucks. Because of this, I've experimented with C++/Qt and was able to write up a usable gnucash-like register window GUI in 2-3 weeks which already includes features that are unavailable in conventional gnucash [2]. I chose C++/Qt because I'm very familiar and productive with that platform. Something that would be really awesome would be to look at the GUI code in such a way as to ensure that writing the GUI code for the native platform would be simple and easy to do. In other words, it would be awesome if there was a native MacOSX version of gnucash, that used the Cocoa interface natively, and a native Windows version of gnucash, that used the Windows APIs natively, etc. I think rather than focusing on a GUI, rather focus on a clean API to the gnucash core, that a GUI might call easily. That will free up a python coder to use the python bindings to make a python based interface (as you've suggested), or a Cocoa coder to make MacOSX bindings, etc. Regards, Graham -- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo
On Thursday 06 January 2011, Mike Alexander wrote: --On January 5, 2011 2:12:06 PM -0500 Derek Atkins warl...@mit.edu I get the git is cool aspect of it. But I'm trying to get people ignore the git is cool part and to seriously think about the technicalities: what does git buy us that we don't have now, and will we really truly use those features that git provides that svn (or other tools built on svn, including git-svn) does not? For the record, I agree entirely with this. Changing is painful and needs to be worth the pain. There are lots of source code management systems out there and almost all of them have advantages (and people who swear by them). Personally my favorite is Clearcase, but we're certainly not moving to that! Mercurial is not too bad either, and I already use that for other open source projects. Git is probably good too, but I don't know it very well. I have worked with clearcase as well - almost 10 years ago. I remember I liked it's concept of views and strong branching. I also remember that merging was as tricky then as it still is today in other source management systems I used in the meantime. And indeed, Clearcase isn't even an option for GnuCash, so I won't go into it more. I started playing with git a couple of months back, just to see what it could do. My first test was to import the gnucash project using git-svn. I have a fair amount of experience in svn, which I don't have yet in git. Still it didn't take me long to prefer git over svn. I can't very well describe why. I think it's a mix of subjective and objective criteria. On the subjective side, I am under the impression that the git way of doing things seems to align better with my sense of logic and representation of development history. More technically, I find that git has a set of commands that is more helpful in many situations. I can find ways to do most things in svn as well, but in git it is often easier, or more direct, or more flexible. I particularly like the flexibility that branches have in git, I already enjoyed the rebase command, partial commits (like committing only a few of the changes in one file), ... I should also add that I have had to search hard to do certain things and am frequently confused because I'm conditioned in the svn way of doing things and git does some things fundamentally different. So there would definitely be a learning curve. Equally, so far I have only had a couple of occasions to experience git's merge capabilities. My first impression is again that git tends to be more helpful and more flexible at that time. The more recent svn versions have improved in that area though, but in my (subjective) opinion are not up to git's standards yet. What I don't have experience with at all yet is working with others via git. Like pushing or pulling changes to/from other git repositories. What I am missing in git is the linear version numbering that comes with svn. I suppose it wouldn't work very well in a system that uses branches as its primary metaphor, but I miss it nonetheless. It's not obvious to see to states of the source code and know at a glance which one is more recent or not. The sha1 sum defines each commit uniquely, but seeing it in the about dialog box from GnuCash doesn't tell me if this build is from a more recent source than I built yesterday, and whether I should update my sources for a rebuild or not. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo
On Wednesday 05 January 2011, Jeff Kletsky wrote: I don't like that history is a pretty flexible thing and that branches are just pointers to specific commits, rather than the kind of followable path that svn provides. That's interesting, because I feel exactly the oposite. I don't like it that for svn a branch or tag is a path into the repository. It has always felt artificial to me and if not treated with proper care could put you into very unwanted situations like people inadvertently committing changes to a tagged release. I guess this is mostly a matter of taste and what you are most used to though... Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug in GnuCash Docs PDF generation (german help docs?)
Frank, Frank H. Ellenberger f.ellenber...@online.de writes: Hi Derek, should be fixed in r20037. Thanks. It does appear to be working again. Frank -derek Am Mittwoch, 5. Januar 2011 um 21:47:56 schrieb Derek Atkins: Hi All, The GnuCash docs have failed to build the last few days. I decided to take a few minutes today to figure out why it failed, and here's what I found. This failure only started a few days ago. Maybe someone could look at it? -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: Challenging python coders: Who can create a gnucash-like GUI in python in a few weeks?
On Mon, Jan 10, 2011 at 12:50:25PM +0200, Graham Leggett wrote: I think rather than focusing on a GUI, rather focus on a clean API to the gnucash core, that a GUI might call easily. That will free up a python coder to use the python bindings to make a python based interface (as you've suggested), or a Cocoa coder to make MacOSX bindings, etc. Coincidentally, PyObjC means that good Python bindings also enable a native Cocoa MacOS X GUI. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Challenging python coders: Who can create a gnucash-like GUI in python in a few weeks?
In my opinion, it is great that Scheme and Guile are on the way out. I would suggest though, that something more than how few lines of code are needed go into the determination of the language for the UI. Otherwise, APL is going to win hands down. Even the presence of bindings doesn't sway me much. The amount of UI code (and proper re-factoring of business logic out of the UI) is probably going to be much larger than the bindings. Part of me also cringes at the thought of using two different languages for one application unless there is a good reason. I'd argue for at least the following: * Modern, object-oriented code This one really goes without saying, I hope. I'd personally prefer one that handles multiple inheritance in a reasonable way and clearly supports anonymous functions, closures, and lazy build functionality. * Popular among developers You want people to already have the skills to be able to contribute to the project. The Open Source world is not really much different than the commercial world. Now matter how slick your language is, it is going to be much easier to, for example, find top-notch Java programmers, than some niche language (unless it is deemed the next great thing). * xPad aware Consider that I wouldn't be surprised if there are more iPads out there than Linux desktops. Android is on the upswing. The increasing number of handheld devices, to some extent, argues against heavyweight interpreters. Why should the user have to not only download an app, but also another language interpreter, and potentially another GUI framework? I'm not saying that GNUCash must be in Objective C, but thinking about platform support and impact is worthwhile. * Understandability and Maintainability I guess that rules out APL... On 01/10/2011 02:24 AM, Christian Stimming wrote: Dear all, We've been discussing various future directions for gnucash, including a switch to a different programming language for the GUI code [1]. GUI coding in C sucks. Because of this, I've experimented with C++/Qt and was able to write up a usable gnucash-like register window GUI in 2-3 weeks which already includes features that are unavailable in conventional gnucash [2]. I chose C++/Qt because I'm very familiar and productive with that platform. However, a scripting language might be even more suitable for writing the GUI code of a project like gnucash. The language Python is a particularly good candidate here because gnucash already has python wrappers for most of its underlying data type and storage code, thankfully provided by Mike Evans and others. See src/optional/python-bindings/ and the doxygen output [3] and the example scripts in python-bindings/example_scripts/, in particular scripts like simple_book.py: Loading an existing file, modifying some of the data, and writing again, all in 12 lines. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo
Geert Janssens janssens-ge...@telenet.be writes: On Wednesday 05 January 2011, Jeff Kletsky wrote: I don't like that history is a pretty flexible thing and that branches are just pointers to specific commits, rather than the kind of followable path that svn provides. That's interesting, because I feel exactly the oposite. I don't like it that for svn a branch or tag is a path into the repository. It has always felt artificial to me and if not treated with proper care could put you into very unwanted situations like people inadvertently committing changes to a tagged release. I guess this is mostly a matter of taste and what you are most used to though... I like that branches are paths, because you DO want to be able to make additional commits into a branch. So I don't agree with you there. However, I do agree with you about tags. IMHO branches and tags are (and should be) fundamentally different. A branch should be a path, but a tag is, well, a tag. Geert -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: Public Git repo
On Monday 10 January 2011, Geert Janssens wrote: What I don't have experience with at all yet is working with others via git. Like pushing or pulling changes to/from other git repositories. Oh, and I forgot to add that I don't have experience with svk. So I don't know it that also improves the svn experience in similar ways. Neither have I ever uses mercurial or bazar, which are -like git- distributed version control systems. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: missing gnucash-2.4.0.tar.bz2 in ftp.at.gnucash.org/pub/gnucash/sources/stable/
On Tuesday 04 January 2011, Derek Atkins wrote: On Mon, January 3, 2011 9:35 pm, Frank H. Ellenberger wrote: Servus Tony, in the chat http://lists.gnucash.org/logs/2011/01/2011-01-03.html#T14:23:35 a user asked, why gnucash-2.4.0 is not availabe at ftp.at.gnucash.org = gd.tuwien.ac.at. For what it's worth, the tarball is also missing at www.gnucash.org. How does it normally end up there ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo
On 10 January 2011 15:12, Derek Atkins warl...@mit.edu wrote: Geert Janssens janssens-ge...@telenet.be writes: On Wednesday 05 January 2011, Jeff Kletsky wrote: I don't like that history is a pretty flexible thing and that branches are just pointers to specific commits, rather than the kind of followable path that svn provides. That's interesting, because I feel exactly the oposite. I don't like it that for svn a branch or tag is a path into the repository. It has always felt artificial to me and if not treated with proper care could put you into very unwanted situations like people inadvertently committing changes to a tagged release. I guess this is mostly a matter of taste and what you are most used to though... I like that branches are paths, because you DO want to be able to make additional commits into a branch. So I don't agree with you there. I am not sure what you are suggesting here. Using git there is no problem committing to a branch, just checkout the branch, make the changes, and commit. The changes go onto the branch. However, I do agree with you about tags. IMHO branches and tags are (and should be) fundamentally different. A branch should be a path, but a tag is, well, a tag. I believe they *are* different in git, at least in terms of the normal usage via the git commands and utilities. Colin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: missing gnucash-2.4.0.tar.bz2 in ftp.at.gnucash.org/pub/gnucash/sources/stable/
Normally, I copy it. I forgot this time. Phil - I used to be a hypochondriac AND a kleptomaniac. So I took something for it. From: Geert Janssens janssens-ge...@telenet.be To: gnucash-devel@gnucash.org Cc: Antonín Sprinzl anto...@sprinzl.info; Derek Atkins de...@ihtfp.com Sent: Mon, January 10, 2011 10:33:33 AM Subject: Re: missing gnucash-2.4.0.tar.bz2 in ftp.at.gnucash.org/pub/gnucash/sources/stable/ On Tuesday 04 January 2011, Derek Atkins wrote: On Mon, January 3, 2011 9:35 pm, Frank H. Ellenberger wrote: Servus Tony, in the chat http://lists.gnucash.org/logs/2011/01/2011-01-03.html#T14:23:35 a user asked, why gnucash-2.4.0 is not availabe at ftp.at.gnucash.org = gd.tuwien.ac.at. For what it's worth, the tarball is also missing at www.gnucash.org. How does it normally end up there ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo
At least as I understand it, branches in git are nothing more than a pointer to the head commit and, structurally, are pretty much the same (if not identical) to tags. A branch in git is a tag on point in development that is moved to other commits if you commit to that branch. In simpler words, it is a tag that gets conveniently moved each time you commit. You really aren't working on/in a branch but are more moving what the notion of the head of the branch is. Yeah, it's really different from svn that way. While there is the notion of parent and child commits (which can be multiple) in git, one of the things that is different about git branches is that there is no notion of a branch point or a branch history the way there is in svn, for example. Sure, as long as you don't merge the branch, you can determine where it diverges from another branch. However, once you merge, that gets dicey to impossible. As long as you don't really care where you came from and how, git branches are fine. They can take care of * most recent 2.2-Release version * most recent 2.4-Release version * most recent Stable version * most recent Current (bleeding-edge) version Git tags are really the static things to take care of the concept of: * what are all the 2.2-Release versions? * what are all the 2.4-Release versions? On 01/10/2011 07:38 AM, Colin Law wrote: On 10 January 2011 15:12, Derek Atkinswarl...@mit.edu wrote: Geert Janssensjanssens-ge...@telenet.be writes: On Wednesday 05 January 2011, Jeff Kletsky wrote: I don't like that history is a pretty flexible thing and that branches are just pointers to specific commits, rather than the kind of followable path that svn provides. That's interesting, because I feel exactly the oposite. I don't like it that for svn a branch or tag is a path into the repository. It has always felt artificial to me and if not treated with proper care could put you into very unwanted situations like people inadvertently committing changes to a tagged release. I guess this is mostly a matter of taste and what you are most used to though... I like that branches are paths, because you DO want to be able to make additional commits into a branch. So I don't agree with you there. I am not sure what you are suggesting here. Using git there is no problem committing to a branch, just checkout the branch, make the changes, and commit. The changes go onto the branch. However, I do agree with you about tags. IMHO branches and tags are (and should be) fundamentally different. A branch should be a path, but a tag is, well, a tag. I believe they *are* different in git, at least in terms of the normal usage via the git commands and utilities. Colin ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo
On 10 January 2011 15:48, Derek Atkins warl...@mit.edu wrote: Colin Law clan...@googlemail.com writes: On 10 January 2011 15:12, Derek Atkins warl...@mit.edu wrote: Geert Janssens janssens-ge...@telenet.be writes: On Wednesday 05 January 2011, Jeff Kletsky wrote: I don't like that history is a pretty flexible thing and that branches are just pointers to specific commits, rather than the kind of followable path that svn provides. That's interesting, because I feel exactly the oposite. I don't like it that for svn a branch or tag is a path into the repository. It has always felt artificial to me and if not treated with proper care could put you into very unwanted situations like people inadvertently committing changes to a tagged release. I guess this is mostly a matter of taste and what you are most used to though... I like that branches are paths, because you DO want to be able to make additional commits into a branch. So I don't agree with you there. I am not sure what you are suggesting here. Using git there is no problem committing to a branch, just checkout the branch, make the changes, and commit. The changes go onto the branch. We're not talking about git; we're talking about svn. Sorry, I thought you were comparing the two and saying that the way svn handles branches is better than the way git does it. Colin L. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Make check fails at dbi test
Wonderful news, Jeff. Thanks. I should have made it clear that the zero amount issue happens with SQL, not the XML. Sorry 'bout that. Bill On 01/10/2011 01:54 AM, Jeff Kletsky wrote: [...] Hello! I am having a problem with make check on r20048 (and a few versions before that). I am also having problems with gnucash 2.4.0 storing accounts as an SQL database. The transaction dates and descriptions are displayed in the register but the amounts always show zero. Here's the error I get when I run make check. There are no errors during the ./autogen / ./configure / make phases of building. I'm running Ubuntu 10.10 with sqlite3 3.7.0. I believe I have all the dbi stuff installed. I'm still running gnucash 2.2.9 with no problems. What vers ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo
On 10 January 2011 15:56, Jeff Kletsky gnuc...@allycomm.com wrote: At least as I understand it, branches in git are nothing more than a pointer to the head commit and, structurally, are pretty much the same (if not identical) to tags. A branch in git is a tag on point in development that is moved to other commits if you commit to that branch. In simpler words, it is a tag that gets conveniently moved each time you commit. You really aren't working on/in a branch but are more moving what the notion of the head of the branch is. Yeah, it's really different from svn that way. It may well be true that branches and tags in git are structurally very similar, but in terms of operation they are completely different. Git knows the difference and handles the concept of working on a branch in virtually the same way as svn (as far as the user is concerned). So one can create a new branch, make changes, committing along the way. One can use gitk to give a graphical representation showing the branch separate from other branches. While there is the notion of parent and child commits (which can be multiple) in git, one of the things that is different about git branches is that there is no notion of a branch point or a branch history the way there is in svn, for example. Up to the point of merging there is effectively a branch point and history. Sure, as long as you don't merge the branch, you can determine where it diverges from another branch. However, once you merge, that gets dicey to impossible. That is true, once a branch is merged into the master branch, for example, it is as if the changes were made on the master. Personally I have not found this to be an issue. As long as you don't really care where you came from and how, git branches are fine. They can take care of * most recent 2.2-Release version * most recent 2.4-Release version * most recent Stable version * most recent Current (bleeding-edge) version One of the most useful features is the ability to setup local branches (on ones local clone of the repository) for experimental work. Once one is happy with the work then the changes can be merged into whatever branch is appropriate on the master repository. Colin Git tags are really the static things to take care of the concept of: * what are all the 2.2-Release versions? * what are all the 2.4-Release versions? ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo
On Monday 10 January 2011, Jeff Kletsky wrote: At least as I understand it, branches in git are nothing more than a pointer to the head commit and, structurally, are pretty much the same (if not identical) to tags. A branch in git is a tag on point in development that is moved to other commits if you commit to that branch. In simpler words, it is a tag that gets conveniently moved each time you commit. You really aren't working on/in a branch but are more moving what the notion of the head of the branch is. Yeah, it's really different from svn that way. While there is the notion of parent and child commits (which can be multiple) in git, one of the things that is different about git branches is that there is no notion of a branch point or a branch history the way there is in svn, for example. Sure, as long as you don't merge the branch, you can determine where it diverges from another branch. However, once you merge, that gets dicey to impossible. I don't know about the command line tools, but the graphical tool gitk seems to have no problems with that ? As far as I know it nicely shows where branches diverge and merge together again ? Perhaps you have a specific use case in mind that is easier to handle in svn that in git ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: IRR on Advanced Portfolio report
Yes, you are right, IRR can be misinterpreted because it assumes reinvestments with the same return rate, but this is anyway widely used and is present on other products. NPV can be easily added starting from my code (we just need to add an option to take the rate to calculate NPV, and add the column), but I think this is more complex to use since it requires to think first to which is the expected return rate. Regards, Franco On Mon, Jan 10, 2011 at 4:42 PM, Donald Allen donaldcal...@gmail.comwrote: On Mon, Jan 10, 2011 at 3:22 AM, Franco Mossotto franco.mosso...@gmail.com wrote: I was looking for the ability in gnucash to calculate the IRR (Internal Rate of Return) for investments. This is something that other products has and that I found essential in order to evaluate the investments in my portfolio. IRR is certainly useful, but can be misinterpreted. See http://hadm.sph.sc.edu/courses/econ/invest/invest.html I realize that what I've said here is a bit off-topic, but since Professor Baker explains the issues very clearly, I thought I'd mention it. /Don I've found some old request to add this capability on the advanced portfolio report, but I didn't find any implementation for that. I've tried doing that by myself on 2.2.7 that is the version I'm currently using. Attached there are my scm version and the patch file for 2.2.7. It works, even if this probably doesn't comply with your coding standards (this is my first implementation using Scheme) I was trying to port it on trunk, but I've some issues with advanced portfolio shipped on 2.4.0 that I need to investigate first. Regards, Franco ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: IRR on Advanced Portfolio report
On Mon, Jan 10, 2011 at 11:38 AM, Franco Mossotto franco.mosso...@gmail.com wrote: Yes, you are right, IRR can be misinterpreted because it assumes reinvestments with the same return rate, but this is anyway widely used and is present on other products. What Prof. Baker is pointing out is that you can be fooled by IRR comparisons, which are dependent on the shape of the NPV v. discount rate curves (concave v. convex). If you are comparing situations where large costs/outgoing flows occur late in the game, it can be the case that inferior investments have higher IRRs than superior ones. If you don't look at the NPV/discount rate curve, you might not know this and make an incorrect decision, by assuming blindly that a larger IRR is always better, which is not true. /Don NPV can be easily added starting from my code (we just need to add an option to take the rate to calculate NPV, and add the column), but I think this is more complex to use since it requires to think first to which is the expected return rate. Regards, Franco On Mon, Jan 10, 2011 at 4:42 PM, Donald Allen donaldcal...@gmail.com wrote: On Mon, Jan 10, 2011 at 3:22 AM, Franco Mossotto franco.mosso...@gmail.com wrote: I was looking for the ability in gnucash to calculate the IRR (Internal Rate of Return) for investments. This is something that other products has and that I found essential in order to evaluate the investments in my portfolio. IRR is certainly useful, but can be misinterpreted. See http://hadm.sph.sc.edu/courses/econ/invest/invest.html I realize that what I've said here is a bit off-topic, but since Professor Baker explains the issues very clearly, I thought I'd mention it. /Don I've found some old request to add this capability on the advanced portfolio report, but I didn't find any implementation for that. I've tried doing that by myself on 2.2.7 that is the version I'm currently using. Attached there are my scm version and the patch file for 2.2.7. It works, even if this probably doesn't comply with your coding standards (this is my first implementation using Scheme) I was trying to port it on trunk, but I've some issues with advanced portfolio shipped on 2.4.0 that I need to investigate first. Regards, Franco ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: IRR on Advanced Portfolio report
I see your point, but what's your suggestion? I don't think that the actual information on Advanced Portfolio are useful to take a decision on the investments because there is no information considering the duration of the investments. And for me this is the main missing feature in gnucash compared to the product I was using before. Do you agree? Franco On Mon, Jan 10, 2011 at 5:54 PM, Donald Allen donaldcal...@gmail.comwrote: On Mon, Jan 10, 2011 at 11:38 AM, Franco Mossotto franco.mosso...@gmail.com wrote: Yes, you are right, IRR can be misinterpreted because it assumes reinvestments with the same return rate, but this is anyway widely used and is present on other products. What Prof. Baker is pointing out is that you can be fooled by IRR comparisons, which are dependent on the shape of the NPV v. discount rate curves (concave v. convex). If you are comparing situations where large costs/outgoing flows occur late in the game, it can be the case that inferior investments have higher IRRs than superior ones. If you don't look at the NPV/discount rate curve, you might not know this and make an incorrect decision, by assuming blindly that a larger IRR is always better, which is not true. /Don NPV can be easily added starting from my code (we just need to add an option to take the rate to calculate NPV, and add the column), but I think this is more complex to use since it requires to think first to which is the expected return rate. Regards, Franco On Mon, Jan 10, 2011 at 4:42 PM, Donald Allen donaldcal...@gmail.com wrote: On Mon, Jan 10, 2011 at 3:22 AM, Franco Mossotto franco.mosso...@gmail.com wrote: I was looking for the ability in gnucash to calculate the IRR (Internal Rate of Return) for investments. This is something that other products has and that I found essential in order to evaluate the investments in my portfolio. IRR is certainly useful, but can be misinterpreted. See http://hadm.sph.sc.edu/courses/econ/invest/invest.html I realize that what I've said here is a bit off-topic, but since Professor Baker explains the issues very clearly, I thought I'd mention it. /Don I've found some old request to add this capability on the advanced portfolio report, but I didn't find any implementation for that. I've tried doing that by myself on 2.2.7 that is the version I'm currently using. Attached there are my scm version and the patch file for 2.2.7. It works, even if this probably doesn't comply with your coding standards (this is my first implementation using Scheme) I was trying to port it on trunk, but I've some issues with advanced portfolio shipped on 2.4.0 that I need to investigate first. Regards, Franco ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: IRR on Advanced Portfolio report
On Mon, Jan 10, 2011 at 12:04 PM, Franco Mossotto franco.mosso...@gmail.com wrote: I see your point, but what's your suggestion? I don't think that the actual information on Advanced Portfolio are useful to take a decision on the investments because there is no information considering the duration of the investments. And for me this is the main missing feature in gnucash compared to the product I was using before. Do you agree? I agree that doing something in this area would be useful, but I think gnucash can and should do better than giving people enough rope to hang themselves, by just computing the IRR for them. Perhaps it could present the NPV v. discount rate curve for a proposed investment (or investments), to help people avoid the common misuse of IRR. /Don Franco On Mon, Jan 10, 2011 at 5:54 PM, Donald Allen donaldcal...@gmail.com wrote: On Mon, Jan 10, 2011 at 11:38 AM, Franco Mossotto franco.mosso...@gmail.com wrote: Yes, you are right, IRR can be misinterpreted because it assumes reinvestments with the same return rate, but this is anyway widely used and is present on other products. What Prof. Baker is pointing out is that you can be fooled by IRR comparisons, which are dependent on the shape of the NPV v. discount rate curves (concave v. convex). If you are comparing situations where large costs/outgoing flows occur late in the game, it can be the case that inferior investments have higher IRRs than superior ones. If you don't look at the NPV/discount rate curve, you might not know this and make an incorrect decision, by assuming blindly that a larger IRR is always better, which is not true. /Don NPV can be easily added starting from my code (we just need to add an option to take the rate to calculate NPV, and add the column), but I think this is more complex to use since it requires to think first to which is the expected return rate. Regards, Franco On Mon, Jan 10, 2011 at 4:42 PM, Donald Allen donaldcal...@gmail.com wrote: On Mon, Jan 10, 2011 at 3:22 AM, Franco Mossotto franco.mosso...@gmail.com wrote: I was looking for the ability in gnucash to calculate the IRR (Internal Rate of Return) for investments. This is something that other products has and that I found essential in order to evaluate the investments in my portfolio. IRR is certainly useful, but can be misinterpreted. See http://hadm.sph.sc.edu/courses/econ/invest/invest.html I realize that what I've said here is a bit off-topic, but since Professor Baker explains the issues very clearly, I thought I'd mention it. /Don I've found some old request to add this capability on the advanced portfolio report, but I didn't find any implementation for that. I've tried doing that by myself on 2.2.7 that is the version I'm currently using. Attached there are my scm version and the patch file for 2.2.7. It works, even if this probably doesn't comply with your coding standards (this is my first implementation using Scheme) I was trying to port it on trunk, but I've some issues with advanced portfolio shipped on 2.4.0 that I need to investigate first. Regards, Franco ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo
On Jan 10, 2011, at 8:13 AM, Colin Law wrote: On 10 January 2011 15:56, Jeff Kletsky gnuc...@allycomm.com wrote: At least as I understand it, branches in git are nothing more than a pointer to the head commit and, structurally, are pretty much the same (if not identical) to tags. A branch in git is a tag on point in development that is moved to other commits if you commit to that branch. In simpler words, it is a tag that gets conveniently moved each time you commit. You really aren't working on/in a branch but are more moving what the notion of the head of the branch is. Yeah, it's really different from svn that way. It may well be true that branches and tags in git are structurally very similar, but in terms of operation they are completely different. Git knows the difference and handles the concept of working on a branch in virtually the same way as svn (as far as the user is concerned). So one can create a new branch, make changes, committing along the way. One can use gitk to give a graphical representation showing the branch separate from other branches. While there is the notion of parent and child commits (which can be multiple) in git, one of the things that is different about git branches is that there is no notion of a branch point or a branch history the way there is in svn, for example. Up to the point of merging there is effectively a branch point and history. Sure, as long as you don't merge the branch, you can determine where it diverges from another branch. However, once you merge, that gets dicey to impossible. That is true, once a branch is merged into the master branch, for example, it is as if the changes were made on the master. Personally I have not found this to be an issue. As long as you don't really care where you came from and how, git branches are fine. They can take care of * most recent 2.2-Release version * most recent 2.4-Release version * most recent Stable version * most recent Current (bleeding-edge) version This is absolutely not true, and spending a few seconds with a history visualization in git-gui or the network view on Github will show it. (With git gui, you have to pay attention to the colors of the links between commits: They indicate in which branch the commit was made.) It's SVN that loses identity unless the merge commit mentions it in the comment: A merge is represented as a single patch on the merge-to branch (trunk is a special branch). Github's visualization is especially cool because it tracks pulls across multiple repositories on Github. As Jeff mentioned in passing, any commit can have multiple children (a branch point) and multiple parents (a merge point). (Only parents are recorded in the commit object; children have to be reconstructed.) The git history plumbing follows those branches and merges and displays them correctly -- as long as one uses the tools correctly. It's possible with git to replay the changes in one branch onto another branch (git cherrypick), which creates a new set of commits on the receiving branch which have no references to the original. See http://utsl.gen.nz/talks/git-svn/intro.html for a good exposition on migrating to git from svn and how to get more from git, as well as a comparison of svn, svk, git, darcs, bzr, and Hg. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Public Git repo
On 01/10/2011 08:28 AM, Geert Janssens wrote: On Monday 10 January 2011, Jeff Kletsky wrote: At least as I understand it, branches in git are nothing more than a pointer to the head commit and, structurally, are pretty much the same (if not identical) to tags. A branch in git is a tag on point in development that is moved to other commits if you commit to that branch. In simpler words, it is a tag that gets conveniently moved each time you commit. You really aren't working on/in a branch but are more moving what the notion of the head of the branch is. Yeah, it's really different from svn that way. While there is the notion of parent and child commits (which can be multiple) in git, one of the things that is different about git branches is that there is no notion of a branch point or a branch history the way there is in svn, for example. Sure, as long as you don't merge the branch, you can determine where it diverges from another branch. However, once you merge, that gets dicey to impossible. I don't know about the command line tools, but the graphical tool gitk seems to have no problems with that ? As far as I know it nicely shows where branches diverge and merge together again ? Perhaps you have a specific use case in mind that is easier to handle in svn that in git ? Geert git and svn are just different on things which is better depends on how you work (that said, I personally prefer git for my local work) 1) You're somewhere along in development - A - B - C Branch 1 = C 2) You Create Branch 2 - A - B - C Branch 1 = C Branch 2 = C 3) Make some commits on Branch 2 - A - B - C - D - E - F Branch 1 = C Branch 2 = F 4) Make some commits on Branch 1 - A - B - C - D - E - F \ \ G - H Branch 1 = H Branch 2 = F 5) Someone else makes a topic branch, Branch 3, off commit B (maybe that was the last released version) and makes some commits / I - J / - A - B - C - D - E - F \ \ G - H Branch 1 = H Branch 2 = F Branch 3 = J 6) You merge in some of the changes from Branch 3 into Branch 2 / I - J -- \ /\ - A - B - C - D - E - F - K \ \ G - H Branch 1 = H Branch 2 = K Branch 3 = J Sooo, where is the branch point for Branch 2? Was it commit B or commit C? Also, from git's perspective, commmits I and J are just as much on Branch 2 as are commits D, E, and F. From svn's perspective, there was a branch made at point C and some additional changes were introduced in commit K When I remember, I tag the branch points when I make them. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Python Shell
Hello and a happy new year ! My interest in gnucash is to have a python-shell-environment which lets me easily access and display data. I have written some things for myself like simple functions PrintTransaction(Transaction) and so for other objects. I use IPython for that purpose. I would like to submit my tries in that direction but for myself I would like to find the best solution for at least these printing functions before I do to not submit something too preliminary. I wonder in which way a function that prints an complex object should be done. When looking around in the internet i saw things like object.prettyPrint(). I came across object.__format__(). When I print out for example a transaction i want to print out information of objects that are nested into it. For example I would probably also to print out the splits. I would like to have some function of the objects that are always called the same way. In the end I would like to have something as easy as print object. Could someone point me something helpful ? regards, Christoph Holtermann ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python Shell
On Mon, 10 Jan 2011 17:04:50 -0500, Christoph Holtermann c.holterm...@gmx.de wrote: Hello and a happy new year ! My interest in gnucash is to have a python-shell-environment which lets me easily access and display data. I have written some things for myself like simple functions PrintTransaction(Transaction) and so for other objects. I use IPython for that purpose. I would like to submit my tries in that direction but for myself I would like to find the best solution for at least these printing functions before I do to not submit something too preliminary. I wonder in which way a function that prints an complex object should be done. When looking around in the internet i saw things like object.prettyPrint(). I came across object.__format__(). When I print out for example a transaction i want to print out information of objects that are nested into it. For example I would probably also to print out the splits. I would like to have some function of the objects that are always called the same way. In the end I would like to have something as easy as print object. Could someone point me something helpful ? How far into Python are you? It should be pretty easy to write an interpreter for a very simple language like your last suggestion. You would need to decide how you wanted it to work (how will you refer to the objects?). Also, you would need to decide how fancy the environment should be. For instance you could model what you want on IDLE, so there's a prompt, and various commands defined under it. I think IDLE is written using tkinter. I don't know what the best way to do GUI's in Python is; there's a Gtk+ interface that's essentially the same as the c/c++ interface (http://www.pygtk.org/) (and Glade is supposed to work either with c or with python). The object/method syntax is fine (a) if you know it, and (b) you code ways to make Gnucash objects into Python objects (object.prettyPrint() just calls the prettyPrint method on the value of object, so you need to define that kind of object with its methods, and set its data fields to be a Gnucash object). ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Unit Testing
I've written a fairly extensive change to manage database version changes, and I'd like to add unit tests for the new functions before I commit it. Longer-term, of course, I'd like to have full unit test coverage of the non-gui parts of Gnucash before we start on the major surgery we've been discussing the last couple of weeks. The issue is what framework to use? GLib from 2.16 (supported by everything stable except RHEL 5 and its derivatives, so I don't feel any remorse about using it in 2.4 before we branch it) provides a serviceable, though primitive, framework that we can introduce without adding a dependency, and it integrates nicely with automake. It would, however, increase our dependency on GLib and it lacks the automatic registration of test cases and suites afforded by more sophisticated frameworks. Any comments? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Unit Testing
John, On Mon, January 10, 2011 7:04 pm, John Ralls wrote: I've written a fairly extensive change to manage database version changes, and I'd like to add unit tests for the new functions before I commit it. Longer-term, of course, I'd like to have full unit test coverage of the non-gui parts of Gnucash before we start on the major surgery we've been discussing the last couple of weeks. The issue is what framework to use? GLib from 2.16 (supported by everything stable except RHEL 5 and its derivatives, so I don't feel any remorse about using it in 2.4 before we branch it) provides a serviceable, though primitive, framework that we can introduce without adding a dependency, and it integrates nicely with automake. It would, however, increase our dependency on GLib and it lacks the automatic registration of test cases and suites afforded by more sophisticated frameworks. Any comments? My feeling is that so long as it doesn't add new dependencies and ties into make check then you can do whatever you want. We already have some code to generate random GnuCash data; tie that into whatever 'check' system you want to perform functional tests, and make it work with make check. Regards, John Ralls -derek ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Unit Testing
On Jan 10, 2011, at 5:17 PM, Derek Atkins wrote: John, On Mon, January 10, 2011 7:04 pm, John Ralls wrote: I've written a fairly extensive change to manage database version changes, and I'd like to add unit tests for the new functions before I commit it. Longer-term, of course, I'd like to have full unit test coverage of the non-gui parts of Gnucash before we start on the major surgery we've been discussing the last couple of weeks. The issue is what framework to use? GLib from 2.16 (supported by everything stable except RHEL 5 and its derivatives, so I don't feel any remorse about using it in 2.4 before we branch it) provides a serviceable, though primitive, framework that we can introduce without adding a dependency, and it integrates nicely with automake. It would, however, increase our dependency on GLib and it lacks the automatic registration of test cases and suites afforded by more sophisticated frameworks. Any comments? My feeling is that so long as it doesn't add new dependencies and ties into make check then you can do whatever you want. We already have some code to generate random GnuCash data; tie that into whatever 'check' system you want to perform functional tests, and make it work with make check. Glib it is, then. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Challenging python coders: Who can create a gnucash-like GUI in python in a few weeks?
On Jan 10, 2011, at 6:31 AM, Phil Frost wrote: On Mon, Jan 10, 2011 at 12:50:25PM +0200, Graham Leggett wrote: I think rather than focusing on a GUI, rather focus on a clean API to the gnucash core, that a GUI might call easily. That will free up a python coder to use the python bindings to make a python based interface (as you've suggested), or a Cocoa coder to make MacOSX bindings, etc. Coincidentally, PyObjC means that good Python bindings also enable a native Cocoa MacOS X GUI. But using Python just to have a Cocoa Gui would be really silly. Objective-C interfaces perfectly well with C and is as expressive, dynamic, and terse as Python. Maybe even more terse. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Challenging python coders: Who can create a gnucash-like GUI in python in a few weeks?
On Jan 10, 2011, at 7:12 AM, Jeff Kletsky wrote: * xPad aware Consider that I wouldn't be surprised if there are more iPads out there than Linux desktops. Android is on the upswing. The increasing number of handheld devices, to some extent, argues against heavyweight interpreters. Why should the user have to not only download an app, but also another language interpreter, and potentially another GUI framework? I'm not saying that GNUCash must be in Objective C, but thinking about platform support and impact is worthwhile. That's somewhat conflicting: Android is Java: Portable, but looks crappy on everything else. Might require rewriting the backend in Java, too. Apple's iOS is Objective-C native, but I think that Qt supports it and I know that wxWidgets does, so the C backend with a C++ frontend will work. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
