Re: Performance improvement for xml loads (+comments)

[Patrick Spinler]

Derek Atkins wrote:
> 
> I admit that I don't know very much about DBMS systems.  Are columns
> in a table labeled?  And can you arbitrarily add a new column to an
> existing table 

Yes, and yes.  

While it is possible to access SQL data in a position dependant manner,
it is considered bad practice and heavily frowned upon.  At least, I've
never approved code that does that in any of my code reviews.

More typical is to say something like this (making up a gnucashish
example):

select transaction_date, transaction_id, reconciled_flag, 
   amount, description
into :trans_date, :trans_id, :rec_flag, :trans_amount, :desc
from splits
where from_account = :account_code



> 
> But if this _IS_ how you do it, I still claim that it is equivalent to
> reading in all your data and then writing it out in the "new" format
> (or, in this case, a new table with an additional column).  I suppose
> the only benefit here is that if you run an older application that
> doesn't understand the new data against the newer database table with
> the newer data, then it could still theoretically understand the rest
> of the data.  

Not the only benefit, by any means.  To my mind, the _real_ benefit is
that I, or Jane Schmo, or programmer from the street, can start poking
around in this SQL database _with_no_other_information_or_tools_, and
gather a lot of useful data therefrom.

This is also the true strength of an ASCII data format.  Even the
example you gave in the snipped portions of your original post contains
a lot of information I can look at and start to see how things work and
what they mean, claims to the contrary aside.

This is the true reason why all the major unix subsystems do their
configurations in ASCII flat files.  Think about apache, for instance,
or even worse, sendmail.  That's one hellish config file, especially
since it has to be parsed on startup _every_single_time_, which happens
frequently on e.g. a busy mail system.  Yet, neither of these monsters
have gone to a binary config file format (although I will grant you that
sendmail's is pretty, um, obfuscated :-).  Go hunt around on the
sendmail or apache mailing list archives, or the linux kernel archives,
etc.  In all of these cases, you can find discussions about binary vrs
text config file formats.  The discussions are illuminating.

-- Pat

-- 
  This message does not represent the policies or positions
 of the Mayo Foundation or its subsidiaries.
  Patrick Spinler   email:  [EMAIL PROTECTED]
  Mayo Foundation   phone:  507/284-9485

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Patrick Spinler]

Rob Browning wrote:
> 
> it's also possible
> that when we move to SQL, that we might drop the kvp_frames
> altogether.  That's something we'll have to discuss.  One of the
> reasons for implementing them was that it made adding new fields when
> we needed them much easier, but it's my impression that databases also
> have established ways for handling this kind of thing, so we may be
> able to just leverage those bits.  Hard to tell before we really
> consider the issues carefully...

Ayup - snipped from the postgresql manual:

  Name

 ALTER TABLE -- Modifies table properties

  Synopsis

  ALTER TABLE table
  [ * ] ADD [ COLUMN ] column type
  ALTER TABLE table
  [ * ] RENAME [ COLUMN ] column TO newcolumn

Also, speaking from experience, it's generally pretty trivial to save a
table, recreate it, and reload it from the save. E.g.:

  create table foo_save as select b, c from foo;
  drop table foo;
  create table foo (new_a char, changed_b int, c date);
  insert into foo values select 'filler', int (b), c from foo;

I do this a lot in the database projects I'm a dba for at work.

-- Pat


-- 
  This message does not represent the policies or positions
 of the Mayo Foundation or its subsidiaries.
  Patrick Spinler   email:  [EMAIL PROTECTED]
  Mayo Foundation   phone:  507/284-9485

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Patrick Spinler]

Derek Atkins wrote:
> 
> Well, using MySQL or PostgreSQL is just one part of it.  It's a
> storage mechanism, but you still need to create the data formats that
> are stored.  You still need to define the transaction objects or split
> objects or whatever that get stored in the database.  

Well, not really.  

More specifically, on a fundimental level a database will provide a
number of predefined data types that it will deal with gracefully (int,
date, money, char, etc).  In order to gain some of the advantages of a
database, such as ease of access to the data from other applications,
you really need to use these data types.

Of course, you can store any arbitrary binary data in a database engine,
it's called a BLOB in modern parlence.  But what's the point ?  You have
to have special code to deal with it.

> So, defining a
> binary data format now would certainly be useful, IMHO, down the road
> when we move to a DBMS.

As I mention above, I disagree.

-- Pat

-- 
  This message does not represent the policies or positions
 of the Mayo Foundation or its subsidiaries.
  Patrick Spinler   email:  [EMAIL PROTECTED]
  Mayo Foundation   phone:  507/284-9485

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Derek Atkins]

Patrick Spinler <[EMAIL PROTECTED]> writes:

> Derek Atkins wrote:
> > 
> > Well, using MySQL or PostgreSQL is just one part of it.  It's a
> > storage mechanism, but you still need to create the data formats that
> > are stored.  You still need to define the transaction objects or split
> > objects or whatever that get stored in the database.  
> 
> Well, not really.  
> 
> More specifically, on a fundimental level a database will provide a
> number of predefined data types that it will deal with gracefully (int,
> date, money, char, etc).  In order to gain some of the advantages of a
> database, such as ease of access to the data from other applications,
> you really need to use these data types.

I think every programmible data description/storage/transfer/encoding
system has a set of predefined data types that it will deal with
gracefully.  The question is, what are those types and how
standardized are they?  If they are not standard, is there a core set
from which you can build everything else?

> Of course, you can store any arbitrary binary data in a database engine,
> it's called a BLOB in modern parlence.  But what's the point ?  You have
> to have special code to deal with it.

We have to have special code to deal with databases, too.  It's all
code, somewhere.  Maybe we have to write it, maybe it's provided by
another package, or maybe it gets generated for us from some
description file.  But in the end, we still have to come up with the
data formats (call it a schema if you prefer), and we still have to
write the code that will convert between in-core data structures,
on-network data structures, and on-disk data structures.

> > So, defining a
> > binary data format now would certainly be useful, IMHO, down the road
> > when we move to a DBMS.
> 
> As I mention above, I disagree.

Perhaps we can agree to disagree?

> -- Pat

-derek

-- 
   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  N1NWH
   [EMAIL PROTECTED]PGP key available

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Rob Browning]

Al Snell <[EMAIL PROTECTED]> writes:

> Storing tree structures in SQL is hairy. Very hairy. Sufficiently so that
> it may be worthwhile storing the kvp tree for an object in a binary format
> in a BLOB field.

Well, I definitely appreciate your suggestions, but it's also possible
that when we move to SQL, that we might drop the kvp_frames
altogether.  That's something we'll have to discuss.  One of the
reasons for implementing them was that it made adding new fields when
we needed them much easier, but it's my impression that databases also
have established ways for handling this kind of thing, so we may be
able to just leverage those bits.  Hard to tell before we really
consider the issues carefully...

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Al Snell]

On 7 Dec 2000, Derek Atkins wrote:

> I admit that I don't know very much about DBMS systems.  Are columns
> in a table labeled?  And can you arbitrarily add a new column to an
> existing table (I suppose you could create a new table with the
> existing column information and add the new column, then destroy the
> old table and rename the new table back to the old one).  I just want
> to make sure that you're not dependent upon a particular column
> position for data.  (Again, I know next to nothing about DBMS or SQL).

Yep, columns are labelled, but that's just the same as the fact that nodes
are labelled in XML... a label is a label, meaning that uncreognised
labels can either be ignored or flagged as errors; however, there is still
no way for code to know if an unrecognised tag/column is something it can
safely ignore or a flag indicating that the data fields are encrypted!

Extensibility of a storage format is much more than just providing a
structure that does not require detailed format knowledge to parse - IFF,
XML, SQL tables, and CSV files with column headers in the first row all
provide this. PNG uses an IIF-like chunked format with flags on each chunk
specifying how they should be handled by code that does not understand
them; that's the only example of format extensibility I've seen yet.

ABS


___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Rob Browning]

Derek Atkins <[EMAIL PROTECTED]> writes:

> Besides, if you compress the data, you lose random-access into
> the file ;)

We never have, and probably never will use that, so it's not relevant
IMO.

> Seriously, I'm not against having XML import/export, but I don't
> think it's a reasonable primary data format.

We're going to use SQL in the medium run.

XML solves our current problems, and with compression, doesn't
introduce any new ones, other than speed, which I think we can address
adequately for the hopefully short period of time before we get SQL
working, so I don't see the point in worrying about anything else...

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Jason Godfrey]

On Thu, Dec 07, 2000 at 05:44:15PM -0500, Derek Atkins wrote:

> I admit that I don't know very much about DBMS systems.  Are columns
> in a table labeled?  And can you arbitrarily add a new column to an
> existing table (I suppose you could create a new table with the
> existing column information and add the new column, then destroy the
> old table and rename the new table back to the old one).  I just want
> to make sure that you're not dependent upon a particular column
> position for data.  (Again, I know next to nothing about DBMS or SQL).
> 
> But if this _IS_ how you do it, I still claim that it is equivalent to
> reading in all your data and then writing it out in the "new" format
> (or, in this case, a new table with an additional column).  I suppose
> the only benefit here is that if you run an older application that
> doesn't understand the new data against the newer database table with
> the newer data, then it could still theoretically understand the rest
> of the data.  However, I wouldn't trust it, because that extra column
> may have information that the older application NEEDS to know in order
> to properly understand the data.

Maybe not. If gnucash was to add some extra tax information, the older 
version does not need to know about that the new tax information to understand
the rest of the data.

Also, tables can be added at whim without affecting tables that are already
exsisting.

- Jason

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Open project - data file obfuscator

[Mike Sabin]

I fall into the category of "wanting-to-help-but-lousy-at-C-and-scheme".
Your idea is a good one.  Python is about the only language i'm
worth anything in. I will consider it for a few weeks.  December
is looking pretty hopeless, workload-wise.

Mike Sabin
 
On Thu, Dec 07, 2000 at 05:41:43PM +1100, Robert Graham Merkel wrote:
> Looking for a way to help gnucash, but your scheme and C is a little
> rusty?  Want to learn some xml?  Want to help speed up development?
> Want to build a tool that could be the building block for a bunch of
> other very nifty things?  Well, have I got a project for YOU!
> 
> Generally, one of the first steps to fixing a bug is being able to
> reliably reproduce it.  Consequently, bug reports are often
> accompanied with a data file which can be used to reproduce the bug.
> However, gnucash users are understandably reluctant to provide this
> information to developers.  I don't like divulging my financial
> records either.
> 
> One approach to avoid this is something analagous to the C code
> "obfuscators" like opqcp and the like.  The idea is simple - replace
> names of accounts, payees, and the like with meaningless text.
> 
> However, it gets a little bit more complex than that.  You don't want
> to simply replace each field text randomly.  You'd want to replace
> each text in a consistent way - for instance, each instance of "Bloggs
> Inc." should be replaced with "Payee 01" or something similar.
> Similarly, sometimes amounts are important to demonstrate the bug,
> sometimes they aren't, so you'd probably want to think about providing
> the option to randomize amounts.
> 
> Now, this program doesn't have to be part of gnucash - it can be (and
> probably) should be stand-alone, and doesn't have to be written in
> scheme.  In fact, you might consider some of the xml parsing and
> generation tools available for Perl.  
> 
> If you get this working, you'll not only provide a useful tool in its
> own right, you'll have a working environment for people to write code
> to parse and output valid gnucash data files in Perl - a capability
> that will be *extremely* useful.
> 
> So, all those lurkers out there - is there anybody that finds a
> project like this interesting??
> 
> 
> Robert Merkel[EMAIL PROTECTED]
> 
> "We are excited and optimistic about its usage going 
> forward and, yes, we can teach penguins the military 
> close-order drill", Mark Norton, US Department of Defense. 
> 
> 
> 
> 
> ___
> gnucash-devel mailing list
> [EMAIL PROTECTED]
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Rob Browning]

Derek Atkins <[EMAIL PROTECTED]> writes:

> > If you are worried about load times and memory usage, we should consider
> > using a SAX interface to read in the XML.  See this link for tradeoffs:
> > http://www.daa.com.au/~james/gnome/xml-sax/xml-sax.html
> 
> Unfortunately the problem isn't just at read-time.  It seems that the
> problem is also during file-writes.  And according to this web page,
> the SAX interfacewont affect file writes, only file reads.

And since we already use SAX, I doubt adding it now would have much
affect :>

> What synergy?  I was never enthused about XML (mostly because I
> don't like ascii file formats for large data objects or network
> protocols).

I think the synergy here is that people think that if you use XML,
it's more likely that there will be tools that will be availble to
allow you to manipulate your data outside the app.  This is in fact
true.  Writing a parser/transformer to do some arbitrary thing to an
XML file (massage it, extract things, etc.), or even to any text file,
is far easier than it would be for some home-brewed format.  Heck you
can use emacs/perl/whatever...and I have.

Also, if you do decide to try and whip something up, make sure you're
aware that we use kvp_frames now, in various places, so you will have
to be able to accomodate items with arbitrarily deep, recursive
key/value trees.

> However, I was willing to let others take a gander at it (mostly
> because I _DO_ think that XML input/output is necessary, especially
> once we want OFX support).  The fact that storing 1 transactions
> requires 50M of ram in order to build the XML tree is, IMHO,
> unconscionable.

IMO This is a bug in the library, and not an inherent problem in XML
itself, and as I've described several times before, this may be
something that can be dramatically improved with very little effort...

> I think I'll actually try to write an XDR-based data storage system
> and we'll see.  I just don't believe anymore that XML is a reasonable
> way to store large data sets.  XML is a cool technology, but just
> because a technology is cool doesn't mean that it's the right tool for
> the job.

Of course you're welcome to, but why would you waste time on this
rather than trying to go forward with trying to integrate an embedded
MySQL or PostgreSQL?

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: DxaccPrintAmount returns always absolute value?

[Dave Peticolas]

Christian Stimming writes:
> Hi,
> 
> I recently discovered that all amounts in, say, the Profit and Loss Report 
> are positive. Somehow all minus signs disappeared... and this happens in 
> the function 
> 
>   DxaccPrintAmount (double dval, GNCPrintAmountInfo info)
> 
> by calling
> 
>   val = double_to_gnc_numeric (ABS (dval), 1, GNC_RND_ROUND);
> 
> Is it intentional that there will be no negative amounts printed? The 
> respective scheme function, gnc:amount->string-helper, is nothing more 
> than a wrapper for DxaccPrintAmount right now, so one of these two 
> funtions should probably be changed. 
> 
> It seems that the absolute value in DxaccPrintAmount was checked in CVS 
> with the following log entry:
> revision 1.6 
> date: 2000/11/08 10:53:35;  author: peticolas;  state: Exp;  lines: +44 -74
> More numerics conversions.
> 
> So, Dave, how do we get the negative amounts into the reports?

Well, first we fix that bug :)

It should work now. Note, though, the the D in Dxacc... means 'deprecated'.
Eventually, everything needs to use the gnc_numeric versions of functions.

dave

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Bill Gribble]

On Thu, Dec 07, 2000 at 06:36:58PM -0500, Derek Atkins wrote:
> So the question is: are these data files meant as a storage backend
> for GnuCash, or are they meant for users to interface to directly?  I
> think some people here are in the latter camp, while I am firmly in
> the former.

Both.  One of the reasons we chose a text file format was that MANY,
MANY users have very serious problems with any application that has a
non-text save-file format.  "That's MY DATA, don't you go hiding it in
a binary file!".

People like to use grep on their data files, and all the other
standard unix tools.  Text data file formats are an important
component of the spirit of the free software movement; the application
is just the custodian of the data, which belongs to the user, and the
application shouldn't lock the user into using it to get access to his
or her data.

Binary file formats make people mad.  Including me.  They're just
another thing that we developers have to make excuses for, and I don't
want to have to make excuses for a binary data format, because I think
it's a bad idea.

You have complained about 3 things: memory footprint, file size, and
speed.  These are *all* implementation difficulties that are being
worked on.  Using a GCache or other string ref counter in the XML
reader/writer will make a huge difference in the memory footprint, and
improve the speed.  The file size problem is eliminated with zlib on
the XML backend.

You seem to be technically capable and motivated, so I hope you will
contribute to gnucash, but I wish you would find another problem to
solve.  

Thanks,
Bill Gribble

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Patrick Spinler]

I disagree.  

Now, I may very well be talking out my butt here, since I've never
looked at XML closely, but my understanding is that one of the key
aspects of XML is that there's a tagged description of the data format
in the data itself, yes ?  That is, XML always includes the meta data
along with the data, so you can figure out what the data is.

Okay, this characteristic (including the meta-data) is also part of the
definition of an RDBMS system.  That is, a complete data format and type
description of all the data in the database is included in that
database.  You can't call yourself an RDBMS unless you store your
meta-data inside your database.  Every database I've ever worked with
(PostgreSQL, Sybase, Ingres, Oracle, MS-SQL Server, Interbase, yadda
yadda) does this.

So, once you have the data in the database, it's relatively as easy to
extend as any other meta-data containing system.

The other componant of XML as I understand it (or of any other meta-data
containing system), is to have predefined DDL's and componants to work
on those DDL's, so that you don't just know what the meta-data is, but
what it _means_.  This problem is similar _however_ you store your
data.  No advantage to any format here, you still have to have code to
handle it.

-- Pat

Derek Atkins wrote:
> 
> But this is just the same as:
> 
> account_tree = load_file_version_1(filename);
> save_file_version_2(filename2, account_tree);
> 
> You're not making an extensible format, you're changing the format
> of the data.
> 
> -derek
> 
> Patrick Spinler <[EMAIL PROTECTED]> writes:
> 
> > Ayup - snipped from the postgresql manual:
> >
> >   Name
> >
> >  ALTER TABLE -- Modifies table properties
> >
> >   Synopsis
> >
> >   ALTER TABLE table
> >   [ * ] ADD [ COLUMN ] column type
> >   ALTER TABLE table
> >   [ * ] RENAME [ COLUMN ] column TO newcolumn
> >
> > Also, speaking from experience, it's generally pretty trivial to save a
> > table, recreate it, and reload it from the save. E.g.:
> >
> >   create table foo_save as select b, c from foo;
> >   drop table foo;
> >   create table foo (new_a char, changed_b int, c date);
> >   insert into foo values select 'filler', int (b), c from foo;
> >
> > I do this a lot in the database projects I'm a dba for at work.
> >
> > -- Pat
> >
> >
> > --
> >   This message does not represent the policies or positions
> >of the Mayo Foundation or its subsidiaries.
> >   Patrick Spinler email:  [EMAIL PROTECTED]
> >   Mayo Foundation phone:  507/284-9485
> >
> > ___
> > gnucash-devel mailing list
> > [EMAIL PROTECTED]
> > http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
> 
> --
>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  N1NWH
>[EMAIL PROTECTED]PGP key available

-- 
  This message does not represent the policies or positions
 of the Mayo Foundation or its subsidiaries.
  Patrick Spinler   email:  [EMAIL PROTECTED]
  Mayo Foundation   phone:  507/284-9485

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Al Snell]

> > Also, if you do decide to try and whip something up, make sure you're
> > aware that we use kvp_frames now, in various places, so you will have
> > to be able to accomodate items with arbitrarily deep, recursive
> > key/value trees.
[...]
> > Of course you're welcome to, but why would you waste time on this
> > rather than trying to go forward with trying to integrate an embedded
> > MySQL or PostgreSQL?

Storing tree structures in SQL is hairy. Very hairy. Sufficiently so that
it may be worthwhile storing the kvp tree for an object in a binary format
in a BLOB field.

I've seen SQL databases with XML in the fields. It's not pretty. But you
still end up needing a neat way of storing trees, and the relational
model doesn't cut it.

Eg, even if we DO move to SQL, the complex bits of the disk format will
still be needed :-)

KVP in XDR from the top of my head:

enum kvp_type { /* Can't remember what types there are :-) */
KVP_STRING = 0,
KVP_INT = 1,
KVP_FRAME = 2
};

union kvp_item switch(kvp_type type) {
case KVP_STRING:
string string_body<>;
case KVP_INT:
int int_body;
case KVP_FRAME:
kvp_frame tree_body;
};

struct kvp_pair {
string name<>;
kvp_item value;
};

struct kvp_frame {
kvp_pair contents<>;
};

...from the top of my head. Can't remember exactly what are allowed as
values in kvp_frames, but I'm sure you get the idea.

ABS

-- 
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software  


___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Derek Atkins]

Patrick Spinler <[EMAIL PROTECTED]> writes:

> I disagree.  
> 
> Now, I may very well be talking out my butt here, since I've never
> looked at XML closely, but my understanding is that one of the key
> aspects of XML is that there's a tagged description of the data format
> in the data itself, yes ?  That is, XML always includes the meta data
> along with the data, so you can figure out what the data is.

Nope.  I believe the DTD (e.g. format metadata) COULD be included,
but usually it is not.  Indeed, looking at my GnuCash output, it starts
with:


  1
  

  
NASDAQ
RHAT
RHAT
...

So, as you can see, there is no data format description.  There is
nothing that describes what "gnc" means, nor what "ledger-data" means,
nor "commodity", etc.  The application that reads the tree must know
how to handle that information.

> Okay, this characteristic (including the meta-data) is also part of the
> definition of an RDBMS system.  That is, a complete data format and type
> description of all the data in the database is included in that
> database.  You can't call yourself an RDBMS unless you store your
> meta-data inside your database.  Every database I've ever worked with
> (PostgreSQL, Sybase, Ingres, Oracle, MS-SQL Server, Interbase, yadda
> yadda) does this.

I admit that I don't know very much about DBMS systems.  Are columns
in a table labeled?  And can you arbitrarily add a new column to an
existing table (I suppose you could create a new table with the
existing column information and add the new column, then destroy the
old table and rename the new table back to the old one).  I just want
to make sure that you're not dependent upon a particular column
position for data.  (Again, I know next to nothing about DBMS or SQL).

But if this _IS_ how you do it, I still claim that it is equivalent to
reading in all your data and then writing it out in the "new" format
(or, in this case, a new table with an additional column).  I suppose
the only benefit here is that if you run an older application that
doesn't understand the new data against the newer database table with
the newer data, then it could still theoretically understand the rest
of the data.  However, I wouldn't trust it, because that extra column
may have information that the older application NEEDS to know in order
to properly understand the data.

> So, once you have the data in the database, it's relatively as easy to
> extend as any other meta-data containing system.

If tables are named and columns are labeled (as opposed to indexed)
then yes, you are correct.

> The other componant of XML as I understand it (or of any other meta-data
> containing system), is to have predefined DDL's and componants to work
> on those DDL's, so that you don't just know what the meta-data is, but
> what it _means_.  This problem is similar _however_ you store your
> data.  No advantage to any format here, you still have to have code to
> handle it.

Right, so XML doesn't help you here (compared to other data format
systems). XDR provides a DDL as well, as does ASN.1.  So this is a
wash.

> -- Pat

-derek
-- 
   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  N1NWH
   [EMAIL PROTECTED]PGP key available

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Derek Atkins]

Rob Browning <[EMAIL PROTECTED]> writes:

> I think the synergy here is that people think that if you use XML,
> it's more likely that there will be tools that will be availble to
> allow you to manipulate your data outside the app.  This is in fact
> true.  Writing a parser/transformer to do some arbitrary thing to an
> XML file (massage it, extract things, etc.), or even to any text file,
> is far easier than it would be for some home-brewed format.  Heck you
> can use emacs/perl/whatever...and I have.

Honestly, I think this is a red herring.  I'm not at all convinced
that if said tools did exist they would at all be useful.  Sure, you
have a tagged data tree, but you have to know what the tags mean in
order to do anything with them.  And besides, what would said tool do
with the data anyways?  Anything that you program to be able to
understand the XML could easily be programmed to read a binary format
as well.

I suppose it's useful to use XML for data interchange.. If I wanted to
email you some of my transactions, exporting them in XML and emailing
them would probably be a good thing to support.  OTOH, I don't believe
that a binary format is any more home-brewed than XML.  For example,
using ASN.1 or XDR would require a data format description which is
comparable to a DTD.  The difference is data storage size (before
compression).

> Also, if you do decide to try and whip something up, make sure you're
> aware that we use kvp_frames now, in various places, so you will have
> to be able to accomodate items with arbitrarily deep, recursive
> key/value trees.

I think this can be coped with, but thanks for the warning.

> > I think I'll actually try to write an XDR-based data storage system
> > and we'll see.  I just don't believe anymore that XML is a reasonable
> > way to store large data sets.  XML is a cool technology, but just
> > because a technology is cool doesn't mean that it's the right tool for
> > the job.
> 
> Of course you're welcome to, but why would you waste time on this
> rather than trying to go forward with trying to integrate an embedded
> MySQL or PostgreSQL?

Well, using MySQL or PostgreSQL is just one part of it.  It's a
storage mechanism, but you still need to create the data formats that
are stored.  You still need to define the transaction objects or split
objects or whatever that get stored in the database.  So, defining a
binary data format now would certainly be useful, IMHO, down the road
when we move to a DBMS.

> Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

-derek

-- 
   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  N1NWH
   [EMAIL PROTECTED]PGP key available

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Derek Atkins]

Tyson Dowd <[EMAIL PROTECTED]> writes:

> On 06-Dec-2000, Derek Atkins <[EMAIL PROTECTED]> wrote:
> > Nobody is suggesting going back to the old binary format.  I'm
> > certainly not.  I *AM*, however, suggesting a NEW binary format.
> 
> Any new binary format will have to be at least as extensible as XML.
> After all, there's no point writing a nice tight binary format today,
> when tomorrow there will be another field that needs to be added.

Please define 'extensible'?  I can easily devise a binary format where
I can add new fields in the future.  The straightforward means of
doing this would imply that older file-parsers would not be able to
read newer file-formats, but I think this is a reasonable limitation.
This can be accomplished by simple object (or file-format) versioning.
It's also extremely easy to make sure you don't have byte-order or
word-size issues.  Indeed, this can easily be done with something like
XDR or ASN.1, where we just define our data structures and generate
parsing (and unparsing) routines to read and write data files/streams.
When our data structures change, we up the version number (and keep
the old structures around).  That way, when we see a file of version
#X, we know to use objects of version X.

> If you are worried about load times and memory usage, we should consider
> using a SAX interface to read in the XML.  See this link for tradeoffs:
> http://www.daa.com.au/~james/gnome/xml-sax/xml-sax.html

Unfortunately the problem isn't just at read-time.  It seems that the
problem is also during file-writes.  And according to this web page,
the SAX interfacewont affect file writes, only file reads.

> Personally, I'm not convinced that performance of the XML routines is
> going to be a long term problem.  Besides, a lot of people feel more
> comfortable with XML (or compressed XML) than being "locked in" to a
> binary format (even if the source is available).  I'd much rather see
> improvements to the XML based system than a completely different system,
> because there's a lot of synergy to be gained by going with XML.

What synergy?  I was never enthused about XML (mostly because I don't
like ascii file formats for large data objects or network protocols).
However, I was willing to let others take a gander at it (mostly
because I _DO_ think that XML input/output is necessary, especially
once we want OFX support).  The fact that storing 1 transactions
requires 50M of ram in order to build the XML tree is, IMHO,
unconscionable.

I think I'll actually try to write an XDR-based data storage system
and we'll see.  I just don't believe anymore that XML is a reasonable
way to store large data sets.  XML is a cool technology, but just
because a technology is cool doesn't mean that it's the right tool for
the job.

>Tyson Dowd   # 

-derek
-- 
   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  N1NWH
   [EMAIL PROTECTED]PGP key available

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

tax documentation

[linas]

Hi,

I just took a look at the tax code documentation.  This looks like it
was copied from somewhere. (specifically,
doc/html/C/xacc-txf-categories.html)

This is great stuff, but are we violating any copyrights by copying
this stuff?  Last thing I want is to have Intuit try to shut us down
because we've included some of thier copyrghted material ... 

--linas

Forwarded message:
> To: [EMAIL PROTECTED]
> Subject: CVS update: gnucash/doc/html/C
> Date: Tue,  5 Dec 2000 15:18:02 -0600 (CST)
> 
> 
> Date: Tuesday December 5, 2000 @ 15:18
> Author:   peticolas
> 
> Update of /home/cvs/cvsroot/gnucash/doc/html/C
> In directory www.linas.org:/tmp/cvs-serv14851/doc/html/C
> 
> Added Files:
>   xacc-tax-report-example.html xacc-txf-categories.html 
> Log Message:
> Richard Gilligan's tax & txf export code & docs.
> 
> 
> ___
> gnucash-patches mailing list
> [EMAIL PROTECTED]
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-patches
> 


___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: tax documentation

[Richard -Gilligan- Uschold]

Well, this information did come from a file provided by Quicken 2000, but
I believe the IRS and the tax code is the original source, as all this
does is document what is supposed to go on particular lines of particular
tax forms.  Whether that is sufficient to cover us, I couldn't say.
I contacted several vendors of tax preparation software to get documentation
for the TXF format and they either gave no response, or told me that they
did not have such a document.  (Odd that they could build their software
without such a thing, unless they reverse engineered their competitors
software as I did)  If anyone knows of a source for the TXF export
format spec, it would resolve this problem.
Gilligan
[EMAIL PROTECTED] wrote:
Hi,
I just took a look at the tax code documentation.  This looks like
it
was copied from somewhere. (specifically,
doc/html/C/xacc-txf-categories.html)
This is great stuff, but are we violating any copyrights by copying
this stuff?  Last thing I want is to have Intuit try to shut us
down
because we've included some of thier copyrghted material ...
--linas
Forwarded message:
> To: [EMAIL PROTECTED]
> Subject: CVS update: gnucash/doc/html/C
> Date: Tue,  5 Dec 2000 15:18:02 -0600 (CST)
>
>
> Date: Tuesday December 5, 2000 @ 15:18
> Author:   peticolas
>
> Update of /home/cvs/cvsroot/gnucash/doc/html/C
> In directory www.linas.org:/tmp/cvs-serv14851/doc/html/C
>
> Added Files:
>   xacc-tax-report-example.html
xacc-txf-categories.html
> Log Message:
> Richard Gilligan's tax & txf export code & docs.
>
>
> ___
> gnucash-patches mailing list
> [EMAIL PROTECTED]
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-patches
>

-- 

Gilligan    |    __o   .oooO
   /|  _ \<,_  (   )
  /p|\    (_)/ (_)  \ (   Oooo.
 /  | \  \_)  (   )
       ) /
    [EMAIL PROTECTED]   (_/
    [EMAIL PROTECTED]
 

Re: Performance improvement for xml loads (+comments)

[Derek Atkins]

Christopher Browne <[EMAIL PROTECTED]> writes:

> XML has the merit of being easily serialized; it wouldn't be too
> difficult to use it for THAT purpose, and using other formats that are
> isomorphic to it for more direct access.

Lots of formats can be easily serialized.  So can ASN.1.  So can
XDR.  That's not a unique feature of XML.

> One thought would be that the IronDoc object database system was
> designed with isomorphism with XML as one of the secondary goals. [See
>  for linkage to IronDoc
> info; it's vaporware, but characteristic of the sort of DB that might be
> appropriate...]

According to the IronDoc docs you "can consider IronDoc a binary
compiled fornat(sic) [for XML]" which implies to me that it would have
the same extensibility problems that XDR would have.  In other words,
if you change the data structures you not only need to recompile but
you need to keep the old data structures around in order to read older
data formats.  This also has the side-effect that if you change the
data structures, a parser for the older structures wont be able to
read the newer structures.

I think that the only data object description language that solves
this particular problem is ASN.1, but even ASN.1 can leave pitfalls in
object definitions (where extending an object leads to
incompatibilities in the same way that it would here).  So, you don't
win anything with ASN.1 (except object bloat due to self-describing
objects).

> I don't think this is the right answer; the "semi-automatic" part causes
> me concern, in that it doesn't guarantee extensibility.

Again, can you please define what you mean by "guarantee
extensibility"?  I'd like to see exactly what the extensibility
requirements are, because I certainly don't feel that I understand
what they are.  I just want to make sure that collectively we do all
understand them (or at least we're all on the same page as to what is
meant by the term).

-derek

-- 
   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  N1NWH
   [EMAIL PROTECTED]PGP key available

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Derek Atkins]

Patrick Spinler <[EMAIL PROTECTED]> writes:

> This is the true reason why all the major unix subsystems do their
> configurations in ASCII flat files.  Think about apache, for instance,
> or even worse, sendmail.  That's one hellish config file, especially
> since it has to be parsed on startup _every_single_time_, which happens
> frequently on e.g. a busy mail system.  Yet, neither of these monsters
> have gone to a binary config file format (although I will grant you that
> sendmail's is pretty, um, obfuscated :-).  Go hunt around on the
> sendmail or apache mailing list archives, or the linux kernel archives,
> etc.  In all of these cases, you can find discussions about binary vrs
> text config file formats.  The discussions are illuminating.

Config files are different than data files.  Yes, config files (which
by definition have a human interface to them ;) should be readable and
modifyable by humans.  But also, to take the sendmail example, look at
how sendmail deals with mail aliases.  The user uses emacs or vi to
create a file, and then processes that file into a binary format for
the sendmail application.  Sendmail itself never reads the ascii
aliases file.

So the question is: are these data files meant as a storage backend
for GnuCash, or are they meant for users to interface to directly?  I
think some people here are in the latter camp, while I am firmly in
the former.

> -- Pat

-derek
-- 
   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  N1NWH
   [EMAIL PROTECTED]PGP key available

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Rob Browning]

Derek Atkins <[EMAIL PROTECTED]> writes:

> Honestly, I think this is a red herring.  I'm not at all convinced
> that if said tools did exist they would at all be useful.  Sure, you
> have a tagged data tree, but you have to know what the tags mean in
> order to do anything with them.

Well, for me it hasn't been a red herring.  I've already used
perl/sgrep several times to check various things about my data file
(number of accounts, number of transactions, count transactions
containing foo and write total to a file, etc.).  Now granted, most
people won't want/need to do this, but as a developer (and as a
curious higher-level user), I've already found this quite valuable.

Further, the binary format was completely opaque, and very hard to
debug.  The XML one has been quite easy.  I was able to do a number of
validity checks, and spot errors with obvious fixes just using diff.
You can't say that of non-text formats.

Further, say the file gets minor corruption for some reason.  With the
text file, you can just open it up and fix it with emacs/vi/whatever.
With a binary format, you're probably screwed unless you're *really*
an expert, and have a lot more time.

As I said, you and I may just have different perspectives here.  I've
*already* found the text format useful.

> Well, using MySQL or PostgreSQL is just one part of it.  It's a
> storage mechanism, but you still need to create the data formats
> that are stored.  You still need to define the transaction objects
> or split objects or whatever that get stored in the database.  So,
> defining a binary data format now would certainly be useful, IMHO,
> down the road when we move to a DBMS.

But for the most part, this would just involve defining the SQL tables
we need.  I don't see how that involves a "binary data format".  I
must not understand what you mean.

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

ROI discussion

[Robert Graham Merkel]

Bill, you wanted some information about ROI calculation.

All this stuff is all archived in the ML - read the thread starting
at this URL:

http://gnucash.org/gnucash-devel/June-2000/msg00409.php3

This calculations are slightly nontrivial, so sharing them with 
gnumeric if possible may not be a bad idea.


Robert Merkel  [EMAIL PROTECTED]

"We are excited and optimistic about its usage going 
forward and, yes, we can teach penguins the military 
close-order drill", Mark Norton, US Department of Defense. 


___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Rob Browning]

Derek Atkins <[EMAIL PROTECTED]> writes:

> You're a developer.  You don't count. 

When I wasn't a developer, I still cared.  And if you poke through the
gnucash logs over the past few years, I think you'll find I'm not
alone, but again, we obviously have different experiences here.

The 50MB of RAM you're worried about is a *BUG*, and it needs to be
fixed.  Other than that, and some performance work that seems fairly
straightforward, I still have a hard time seeing why you're pushing so
hard for a whole new format.

> With a good binary format, you can write a small program that prints
> out the data-file in a text format for debugging.

As long as it recovers gracefully from corruption, I'm fine with
that.  It's just been my experence that writing binary->text
converters that handle corruptions gracefully is a very difficult
business.  Humans are much better at that and text lets them act.

> Not everything in the GnuCash data is an SQL primitive data type.

I'm having a hard time thinking of anything.  I was planning that we
go out of the way to make sure we use primitives for all the primary
stuff.  As I mentioned before, this might even mean getting rid of the
arbitrary hierarchical frames stuff.

-- 
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Derek Atkins]

But this is just the same as:

account_tree = load_file_version_1(filename);
save_file_version_2(filename2, account_tree);

You're not making an extensible format, you're changing the format
of the data.

-derek

Patrick Spinler <[EMAIL PROTECTED]> writes:

> Ayup - snipped from the postgresql manual:
> 
>   Name
> 
>  ALTER TABLE -- Modifies table properties
> 
>   Synopsis
> 
>   ALTER TABLE table
>   [ * ] ADD [ COLUMN ] column type
>   ALTER TABLE table
>   [ * ] RENAME [ COLUMN ] column TO newcolumn
> 
> Also, speaking from experience, it's generally pretty trivial to save a
> table, recreate it, and reload it from the save. E.g.:
> 
>   create table foo_save as select b, c from foo;
>   drop table foo;
>   create table foo (new_a char, changed_b int, c date);
>   insert into foo values select 'filler', int (b), c from foo;
> 
> I do this a lot in the database projects I'm a dba for at work.
> 
> -- Pat
> 
> 
> -- 
>   This message does not represent the policies or positions
>of the Mayo Foundation or its subsidiaries.
>   Patrick Spinler email:  [EMAIL PROTECTED]
>   Mayo Foundation phone:  507/284-9485
> 
> ___
> gnucash-devel mailing list
> [EMAIL PROTECTED]
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

-- 
   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  N1NWH
   [EMAIL PROTECTED]PGP key available

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Performance improvement for xml loads (+comments)

[Derek Atkins]

Rob Browning <[EMAIL PROTECTED]> writes:

> Derek Atkins <[EMAIL PROTECTED]> writes:
> 
> > Honestly, I think this is a red herring.  I'm not at all convinced
> > that if said tools did exist they would at all be useful.  Sure, you
> > have a tagged data tree, but you have to know what the tags mean in
> > order to do anything with them.
> 
> Well, for me it hasn't been a red herring.  I've already used
> perl/sgrep several times to check various things about my data file
> (number of accounts, number of transactions, count transactions
> containing foo and write total to a file, etc.).  Now granted, most
> people won't want/need to do this, but as a developer (and as a
> curious higher-level user), I've already found this quite valuable.

You're a developer.  You don't count.  A developer should be expected
to go to extra trouble to debug a program.  What we shouldn't do is
make end-users have to go through trouble (or, store lots of extra
data).

> Further, the binary format was completely opaque, and very hard to
> debug.  The XML one has been quite easy.  I was able to do a number of
> validity checks, and spot errors with obvious fixes just using diff.
> You can't say that of non-text formats.

With a good binary format, you can write a small program that prints
out the data-file in a text format for debugging.  Then you can 'diff'
that, if you like.  Binary isn't necessarily opaque (it may be opaque
to humans, but a human isn't the one supposed to read the data files).

> Further, say the file gets minor corruption for some reason.  With the
> text file, you can just open it up and fix it with emacs/vi/whatever.
> With a binary format, you're probably screwed unless you're *really*
> an expert, and have a lot more time.

Honestly, if the data file gets screwed up, you may never know it.
With a binary file, you KNOW that the file is screwed up.  With a
text file, the screwup may be somewhere where you'll never find it.

> As I said, you and I may just have different perspectives here.  I've
> *already* found the text format useful.

Perhaps.  I'm trying to keep data storage and memory usage at a
minimum while still being extensible for future expansion.  I think
users would prefer that.  Us developers just need better tools to help
us along.  Creating a format just because it's easier to debug is not
necessarily a good reason to do it that way.

> > Well, using MySQL or PostgreSQL is just one part of it.  It's a
> > storage mechanism, but you still need to create the data formats
> > that are stored.  You still need to define the transaction objects
> > or split objects or whatever that get stored in the database.  So,
> > defining a binary data format now would certainly be useful, IMHO,
> > down the road when we move to a DBMS.
> 
> But for the most part, this would just involve defining the SQL tables
> we need.  I don't see how that involves a "binary data format".  I
> must not understand what you mean.

Not everything in the GnuCash data is an SQL primitive data type.
That means we're still going to have to build data structures (or
tables).  And some data, most likely, might get stored as a BLOB,
becuase it doesn't necessarily make sense to store it any other way.

> Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930

-derek
-- 
   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  N1NWH
   [EMAIL PROTECTED]PGP key available

___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel

Re: Open project - data file obfuscator

[Robert Graham Merkel]

Mike Sabin writes:
 > I fall into the category of "wanting-to-help-but-lousy-at-C-and-scheme".
 > Your idea is a good one.  Python is about the only language i'm
 > worth anything in. I will consider it for a few weeks.  December
 > is looking pretty hopeless, workload-wise.
 > 

If you get a chance to work on it, that would be great.  We'll see if
anyone else is interested, and if so how to coordinate.

As far as Python goes, I'm language-agnostic for this, but I think
it's clear that a scripting language is the way to go.  If you wrote
it in scheme, you could use the g-wrap hooks to do the work of parsing
and outputting for you.  If you do it in another language, there's
extra work, but we get an entirely independent implementation that can
parse/export gnucash data files.  Either way, it's a win.

Just a general point which is really addressed to the lurkers in
general, don't be afraid to give scheme a go.  It's a little
odd to those that have only programmed in conventional imperative
languages, but once you get your head around it it's got some really
nifty features (including being perhaps the most extensible and
flexible language I have ever used).


Robert Merkel  [EMAIL PROTECTED]

"We are excited and optimistic about its usage going 
forward and, yes, we can teach penguins the military 
close-order drill", Mark Norton, US Department of Defense. 


___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel