Robert,
After some investigation, sprintf is choking on the #f passed as the string
argument.
As it turns out, "string-length" is right in the begining of the sprintf def.
I am going to try to upgrade my slib from what looks like 2b4
(wish me luck, one can only guess what this will break...)
Though I am curious what #f is supposed to do as the string argument to
sprintf.
(pass back result maybe ?)
Anyway, I will report back how it works.
Robert Graham Merkel wrote:
> 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]
--
Matt Martin
[EMAIL PROTECTED]
600 West Grove Parkway #1042
Tempe, AZ, 85283
(480) 775 2660
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
