What's your favorite year end method?

Mon Dec 17 13:31:35 EST 2007

On Dec 17, 2007 1:17 PM, Derek Atkins <warlord at mit.edu> wrote:
> I think both Josh and I agree that the report subsystem
> needs an overhaul.  Neither of us are whetted to Scheme,
> and I'm sure that Josh would be quite happy to replace
> Scheme with some other "language".   I think Josh would
> also prefer to see a system where the report has two
> part, the "calculation" part and the display part.
>
> As a side project, it would be great to swap out GtkHTML
> for something else, perhaps GtkMozEmbed?
>
> Would you be interested in working on this in the context
> of GnuCash?

As I said to Andrew, I would be interested. The issue is time --
despite my rapidly advancing years (it feels like more than one
year/year), I'm still working full time and a hell of a lot busier
than I ought to be. So if we can find a role for me that fits into the
available time, and isn't a drag on the project, I'll be happy to do
what I can.

And, of course, we need to agree on a salary, bonus, and stock option
structure :-)  (Don't bother wearing out your zero key).

/Don

>
> -derek
>
>
> "Donald Allen" <donaldcallen at gmail.com> writes:
>
> > I think it is pretty clear that the current reports implementation is
> > a problem. I don't want to mis-represent what Derek and Josh have
> > said, but I have the clear impression from reading email from each of
> > them that they are unhappy with the current implementation (and how
> > it's implemented).
> >
> > For me, the reports are the weakest part of gnucash, which I've been
> > using otherwise very happily for over two years now. I find many of
> > the reports inadequate not only from a performance standpoint (and,
> > yes, I've experienced the 5-10 minutes grinding away (Asset Barchart),
> > which in my case resulted in just a legend -- no data) but from a
> > content and presentation standpoint as well.
> >
> > In an ideal world, gnucash would be as brilliant at making information
> > of all that data that  it lets us accumulate so naturally, and in
> > practice I think it fails in that regard (and, yes, I fully understand
> > that this is a labor of love and that the developers have day jobs;
> > I'm not being critical of anyone; I'm simply calling a spade a spade,
> > at least as I see it). This is why I'm working on the Python program I
> > mentioned in an email to this thread last night. I'm already getting
> > income statement, balance sheet, net worth, and unrealized gains (with
> > dividends) reports from it, sorted and presented the way I want them.
> > Where they should, items it reports agree with gnucash to the penny.
> > And it generates these reports in less than 30 seconds on a TP T60 (2
> > Ghz Core 2 Duo). This was an act of desperation on my part, because I
> > couldn't get gnucash to answer many key questions I had about my own
> > finances, and a look at the reporting code led me to conclude that
> > making an investment in improving what's there was not likely to be
> > feasible or effective, given my time constraints and my worries about
> > the performance of guile/scheme (and I'm an experienced Scheme
> > programmer -- Jerry Sussman and Chris Hanson are old friends and I
> > used MIT Scheme as the basis for Butterfly Lisp when I ran that
> > project at BBN 20 years ago; I don't know Guy Steele as well as Jerry
> > and Chris, but did work with him at Thinking Machines in the early
> > 90s). So it was either this, or abandon gnucash, which I would have
> > hated to do.
> >
> > /Don
> >
> > On Dec 17, 2007 11:47 AM, Andrew Sackville-West <ajswest at mindspring.com> wrote:
> >> On Sun, Dec 16, 2007 at 05:29:17PM -0700, Ron Morse wrote:
> >> > I would offer that the Gnucash data file is really pretty compact (three
> >> > years worth of stuff for me is still under 300Kb) so I don't feel a
> >> > pressing need to split the file.  I do make a copy as I close out each
> >> > year, but that's a simple matter of file > save as when I get to the
> >> > point that I have reconciled all the accounts that are going to get
> >> > reconciled.
> >>
> >> the size of the data set begins to become an issue in the reports
> >> before anywhere else. My largest file is currently 1.5MB compressed, and
> >> while all the register functions, find, sorting, etc work just fine,
> >> the reports are beginning to become a problem. Some of them are not
> >> very efficient (especially Income Statement pre 2.2.2) with a single
> >> run of the report taking a couplem inutes or more (not a very fast
> >> machine here, but still...). Other reports aren't so bad, but it does
> >> get to be a drag.
> >>
> >> So that's the issue I see with large data sets.
> >>
> >> A
> >>
> >> -----BEGIN PGP SIGNATURE-----
> >> Version: GnuPG v1.4.6 (GNU/Linux)
> >>
> >> iD8DBQFHZqgfaIeIEqwil4YRAqeHAKClrdFF/dcbeF6elLupTrase9iRLgCgpdCO
> >> jN0bups4kwbJjSIcfJAh8sQ=
> >> =Uxt5
> >> -----END PGP SIGNATURE-----
> >>
> >> _______________________________________________
> >> gnucash-user mailing list
> >> gnucash-user at gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> >> -----
> >> Please remember to CC this list on all your replies.
> >> You can do this by using Reply-To-List or Reply-All.
> >>
> > _______________________________________________
> > gnucash-user mailing list
> > gnucash-user at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-user
> > -----
> > Please remember to CC this list on all your replies.
> > You can do this by using Reply-To-List or Reply-All.
> >
> >
>
> --
>        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
>        warlord at MIT.EDU                        PGP key available
>