On Fri, 09 Jun 2000 11:03:34 +1000, the world broke into rejoicing as
Robert Graham Merkel <[EMAIL PROTECTED]> said:
> > > 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.
I'd want to wait until this could unambiguously be claimed to actually
be a problem with Guile. Thinking that it could, someday, _possibly_
become an issue doesn't count.
Note that by the time that takes place, we may see a generally deployable
Hobbit system whereby Guile code could be turned into C, and compiled into
place. Which can cope with those situations where something is too slow,
and _could_ get compiled.
Hobbit exists now; general deployment is the problem...
> > > -- 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?
ILU supports Guile, and I'm sure it wouldn't be _too_ difficult to
do a mapping using ORBit. There has been comment of such on the
Guile development list; look on <http://www.google.com/> for
"guile" and "orbit" and "corba."
There isn't a formalized mapping for Scheme yet, although there may be
enough info in the ILU docs to provide something "good enough." One of
the ILU guys joint-authored the Python Mapping, which now has _four_
implementations (Fnorb, ILU, 2 ORBit-based). I'd _really_ like to see
a Guile implementation; I'm doing some writing for a book based on the
C mapping, and it's just gross. The _awful_ part is coping with memory
management.
I'd be game to wait things until there is a Guile/ORBit binding, and have
GnuCash's CORBA support go through the Guile side of things, particularly
because this allows memory to stay managed in the garbage-collected side
of the world. It seems to me that _that_ would substantially improve
the _robustness_ of this.
> > 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 :)
One of the major merits, as I see it, of using Guile is that it means
leaving memory management to the garbage collector, which is likely to
be better at memory management than I am.
--
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/linux.html>
"Like I've always said, if you don't have anything nice to say, come
sit by me." -- Steel Magnolias
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
