Matt Martin writes:
> Hello list,
>
> First off, congrats on getting gnucash into stable/usable form. Things
> are vastly improved since I started playing with this more than 6 months
> ago.
>
> There have been lots of patches flying by, many targeting reports, but
> even after hopefully applying them I still seem to get something to the
> effect of:
>
> ERROR: In procedure string-length:
> ERROR: Wrong type argument in position 1: #f
> ....
> then crash
>
> when trying to get reports.
>
That's odd. I don't *use* string-length (I wrote the transaction
report code), and as far as I can see neither do any of the other
reporting functions.
If possible, could you send me an example data file and instructions
for causing the crash(es) you describe, so as I can reproduce them?
> In the best case,test report seems to work. And sometimes the
> transaction report shows
> a blank report (header only) instead of crashing.
>
So when you change the preferences do generate a non-empty transaction
report, does it then crash?
> Sooo, what I would like to know is:
>
> Can anyone summarize where gnucash is with respect to reports ?
>
Sure. In previous versions of gnucash, reporting was provided by Perl
code. In the interests of standardising and (eventually) removing
Perl dependancies, reports were rewritten in Scheme (the Perl code is
still around but will be removed somewhere along the line).
At the moment, there are three Scheme-based reports available -
balance sheets, profit and loss statements, and transaction reports.
The profit-and-loss statement needs to be extended to work over a
specific period, and the transaction report still has a minor date
selection bug in and needs extension to allow configurable transaction
sorting order and perhaps subtotaling.
At the moment, the report code directly emit HTML, which is then
rendered by a HTML display widget. I've recently added the ability to
save the generated HTML (so you can print it, for instance).
However, there is a proposal waiting in the wings for a more
sophisticated system, which would involve a set of report-writing
functions which were adaptable to support multiple output formats,
including output to HTML, LaTeX, printing using gnome-print, export
to ASCII, and even export to Gnumeric. This is all fine and dandy,
but there are still some details to be agreed upon before we can
go and implement this. However, when we do, we will have a very
sophisticated reporting system.
> Most importantly, what will it take to get them working ?
They *should* work right now.
> How can those outside the inner development circle help ?
Send in bug reports :) Seriously, when you do send a bug report,
try to provide as much information as possible, including which
version you are using (in fact, it's best if you use the latest CVS
+ Dave Peticolas' bigpatch, as it's what the developers are using),
exact details of error messages, and, if it's a scheme error, details
about your Guile and SLIB setup.
> Not being a scheme wizard, I'm not even sure where to start when
> looking at these beasts !
> I know things are still in development, but is there any
> documentation which could explain the function calls, etc ?
Yes. Have a look at src/g-wrap/gnc.html. It explains most of the
function calls to the engine. The guile-ref info file explains any
guileisms we may have used, and the slib info file explains the
slib library.
The engine itself is pretty well documented - have a poke around in
the src/engine subdirectory and read the comments if you need more
details about how the engine calls work.
If you need general information about Scheme,
http:///www.cs.indiana.edu/scheme-repository/home.html
has some pointers to get started.
It may initially look a little weird to a C or Perl coder, but
Scheme is actually a quite easy-to-learn and really cool language.
>
> Also, given that these things are going to be in a state of flux for
> a while, can the gui/engine be made resiliant to the crash of improper
> report code ?
>
I don't know (I'm not familiar with that part of the code). Somebody
else will have to answer this one. The point is that the report code
*shouldn't* crash, and if it does it should be fixed.
> I would dare say that the ability to quickly summarize ones financial
> position is much of the point for tracking money in the computer. This
> would be especially useful if done in graphical form(someday)
>
Agreed. Work on GUPPI has apparently started up again. If they
succeed in getting something up and running, we can probably use
Bonobo to add charting capabilities with a minimum of extra coding.
Gnumeric will also eventually have plotting capabilities, so talking
to Gnumeric using CORBA is also a quite viable option.
> Glad to help, if somebody can provide some starting pointers...
Sure. Once we get your bug sorted out (which I suspect is probably
a Guile configuration problem), pick a small feature that you'd like
to add, have a look at the code and figure out how you'd add it.
To keep in sync with other developers, get the latest CVS and apply
Dave's bigpatches. When you have some code that you want to share,
make a patch with the make-gnucash-patch script and send it to
gnucash-patches.
If you get stuck (and we all do - I'm regular asking the more
experienced developers lots of questions), ask the list and we'll try
to help you out. It's not that hard to get started - I started a
couple of months ago and within a week or so I'd contributed a little
patch.
--
---------------------------------------------------------------------------
Robert Merkel [EMAIL PROTECTED]
Humanity has advanced, when it has advanced, not because it has been sober,
responsible, and cautious, but because it has been playful, rebellious, and
immature.
-- Tom Robbins
---------------------------------------------------------------------------
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
