Dave Peticolas writes:
 >  writes:
 > > It's been rumoured that Robert Graham Merkel said:
 > > > 
 > > > This patch fixes a crash in the average balance report when the
 > > > starting and ending dates are entered incorrectly.
 > > 
 > > Um, I admit that I didn't really look at this patch, but have a stupid
 > > question about it anyway.  Are you computing avg balances in scheme, or
 > > in C?  (I suspect the answer is 'scheme').
 > 

Just a clarification - the report isn't my code.  I just noticed a bug

 > I think the real issue is not scheme vs. C, but that is would be useful
 > to have a 'statistics' module that know how to compute various desirable
 > attributes of engine data, like average balances, cost-basis, etc. This
 > doesn't necessarily need to be in the engine.
 > 
 >  
 > > I want to suggest that a better long-term architecture might be that
 > > the financial calculators & etc. be implemented in C, as a part of the
 > > engine.  My arguments for this is that this will make for a better
 > > client-server interface:
 > > 
 > > -- there is potentially less traffic, fewer bytes crossing the wire,
 > >    if the computations happen in the engine.
 > 
 > I don't think this is as big an issue as you might think. The average
 > balance report is probably doing the most calculations of any report,
 > and it is pretty speedy, even on large data files.

I can't recall the speed of guile ever being a live issue.  The part of
the code with performance issues ATM (the register) is written in C
anyway.

 > 
 > > -- if its in C, then I can potentially export this function e.g. via
 > >    CORBA, to other modules.  If its in scheme, it stays 'locked up in
 > >    scheme'.
 > 
 > This is not true. Calling guile functions from C is easy, we do it
 > all over the place right now.

True.  AFAIK, however, there are no CORBA bindings for scheme, which
means we have to wrap any scheme functions we wish to export via CORBA
in C.  Also, it will mean we will have to create some C wrappers so 
that scheme can call CORBA services from other programs (for instance,
if we want to use CORBA to interface to guppi).

A scheme CORBA mapping would be really nice, because as Christopher put
it on Slashdot recently, the C CORBA mapping is "horrible", and I'm
not looking forward to having to work with it.
Actually, Christopher, is there a scheme language mapping out there?

 > I think there are some good arguments for a scheme implementation.
 > Scheme is much more flexible than C. Having the statistics package
 > in scheme would make it easier for users to add their own functions
 > if the existing ones don't provide something they need.

Agreed.  Having users (and developers) use scheme where appropriate 
makes it a little bit harder to inadvertantly shoot oneself in the
foot :)

-- 
------------------------------------------------------------
Robert Merkel                              [EMAIL PROTECTED]

------------------------------------------------------------

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]


Reply via email to