Re: budgets Was: quicken migration

[Hendrik Boom]

> Hendrik Boom <[EMAIL PROTECTED]> writes:
> 
> > P.S. Maybe some thing this perverse, but I enjoy the practice we seem
> > to have of quoting the entire discussion in each message.
> 
> It's certainly not a practice all of us have (or like).

When I wrote the P.S., I thought " Everyone will probably think I am being
sarcastic, but I'm not."
In retrospect, I probably was being sarcastic and didn't realize it because
I was tired.

What's really needed is not massive quoting (quadratic bandwidth usage),
but a way to reconcile multiple partially quoted partially edited messages
so that you can, if you choose, see the entire conversation history easily.
But that's probably not a problem for gnucash to solve.

-- hendrik.

> 
> -- 
> Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
> 
> --
> Gnucash Developer's List 
> To unsubscribe send empty email to: [EMAIL PROTECTED]
> 
> 

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

How should I proceed on budgets?

[Bryan Larsen]

I've got quite a few little things left on the budget report that I want to
clean up, but I've got two big architectural concerns.

1)  How do I do the UI?  I've made the budget complicated enough that each line
should be entered using a Druid or something similar.  How should I manage the
list of budget lines?  Perhaps the register window could be used.

2)  How do I store the budget?  The budget needs to be saved & read from disk. 
It it was up to me, I'd use XML, but the this doesn't fit in with how the
register is stored.

Bryan

 -- 
-
Bryan Larsen, Senior Software Engineer & fall guy
Analog Design Automation:  Analog Circuit Synthesis?  Problem Solved.

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

Re: How should I proceed on budgets?

[Christopher Browne]

On Mon, 03 Apr 2000 06:55:26 MDT, the world broke into rejoicing as
Bryan Larsen <[EMAIL PROTECTED]>  said:
> I've got quite a few little things left on the budget report that I want to
> clean up, but I've got two big architectural concerns.
> 2)  How do I store the budget?  The budget needs to be saved & read from disk
. 
> It it was up to me, I'd use XML, but the this doesn't fit in with how the
> register is stored.

Since GNOME requires XML, that's a not unreasonable option, and might
lead to "other components using XML."

The other major option would be to save the budget information as an
S-expression, e.g. - as Scheme data.
--
"Keep your arms and legs attached to your torso at all times."
-- [EMAIL PROTECTED] (Eric Griswold)
[EMAIL PROTECTED] - 

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

Re: wtf? scheme weirdness

[Rob Browning]

Bryan Larsen <[EMAIL PROTECTED]> writes:

> remainder is complaining that I'm not using an integer, but I'm
> using floor to give it an integer.

Hmm.  Could you annotate your call to floor with a wrapper that prints
the before/after value, and perhaps the type?  I'd like to see if this
is a bug in floor or somewhere else.

Thanks

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

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

Re: ignore last message.

[Rob Browning]

Bryan Larsen <[EMAIL PROTECTED]> writes:

> Sorry.  I was RTFM'ing, but I didn't get quite far enough before I
> gave up.

OK, ignore my previous response, then too :>

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

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

Re: Eperl/swig

[Rob Browning]

David Fenyes <[EMAIL PROTECTED]> writes:

> After a fresh install of Mandrake, I was reminded that gnucash won't
> install without eperl and swig.  While I don't really mind
> re-installing these, Perhaps a switch could be made available (such
> as --without-eperl --without-swig) to simplify the installation?

I want to fix it so that it doesn't need swig if it's not detected.

Maybe I'll get to that this week.

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

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

Re: budgets Was: quicken migration

[Rob Browning]

Hendrik Boom <[EMAIL PROTECTED]> writes:

> What's really needed is not massive quoting (quadratic bandwidth
> usage), but a way to reconcile multiple partially quoted partially
> edited messages so that you can, if you choose, see the entire
> conversation history easily.  But that's probably not a problem for
> gnucash to solve.

You might already know about this, and it might not be what you want,
but threaded mail readers (like Gnus, mutt, etc) help tremendously.  I
can't imagine dealing with the volume of mail I get without Gnus.

FWIW

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

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

Re: How should I proceed on budgets?

[Rob Browning]

Bryan Larsen <[EMAIL PROTECTED]> writes:

> 2) How do I store the budget?  The budget needs to be saved & read
> from disk.  It it was up to me, I'd use XML, but the this doesn't
> fit in with how the register is stored.

The other question is "where do I store the budget".  If I get a
couple of hours in the next day or so, which I probably will, I'll
have a good answer for you...

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

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

Gnucash's website problem (BugTracker)

[LE NY Yannick]

Hello Jeremy,

The latest bug report is :
Notification incoming/128 , the 16th March 2000.

And for the Gnucash BugTrack at  :
http://www.gnucash.org/cgi-bin/bugtrack

I have this message:

 gnucash
bug tracker
  The system encountered a fatal error
  failed to set guest gid
  The last error code was: Operation not permitted

Can you correct this problem?

Thanks

Yannick

 
__
Si votre email etait sur iFrance vous pourriez ecouter ce message au tel !
http://www.ifrance.com : ne laissez plus vos emails loin de vous ...
gratuit sur iFrance :  emails (20 MO, POP, FAX), Agenda, Site perso 


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

How do you handle mutual fund purchases and roundoff?

[Rob Browning]

Strange experience today.  I was entering some of my old financial
data, and I had an investment account that recorded the purchase of a
mutual fund into a retirement account.  So I entered the transaction
into a mutual fund register (actually I entered it into the
cash-account clearing register and then modified the share values in
the mutual fund register).

After a few minutes of scratching my head, I realized that the numbers
they were giving me weren't telling me what I thought they were.  The
information they give (making up some numbers) is a total cost for the
purchase (say $1000), including the share price (say $10.001), and the
quantity (100.000).  In the description for the transaction, they also
list a transaction cost (say $30 -- it's a loaded fund).

First note that the total isn't the same as the quantity times the
price.  It's actually off by about $0.10 in my favor, which they claim
is just roundoff in the share price as compared to what it "should
have been".  Even given that, if the share price and the quantity are
correct, then I can't figure out what happened to the transaction
cost.  because it's not deducted from anywhere else, and for it to be
included in the "direct way", the overal transaction value would have
had to be $1030.

So two questions:

  * If the transaction fee really is incorporated into the cost of the
purchase, then the quantity or price values can't be right.
What's going on, and what's the right way to record this?  I
thought perhaps they just adjusted the price per share upward from
the "value at purchase time" to account for the transaction cost,
but if so, then should I compute the "real" value and use it, even
though my gnucash records won't match the financial insitution's,
or should I do something to record the difference in the mutual
fund register itself?

  * Presuming I'm not just interpreting things wrong, if there is a
roundoff error, how should that normally be handled?  Do I enter
them as an adjustment?  If so, from what type of account?

Thanks.

PS: Once I understand this, I'll be happy to add a section to the
docs.

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

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

cvs 2000-04-03

[Dave Peticolas]

CVS has been updated.

New Stuff:

 + Bryan Larsen's patch to the budget report and date-utilities.

 + Some tweaks to the register operation.


dave

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

question about having a "pure" gtk interface

[Sean 'Shaleh' Perry]

Hi, the archive search on the website seems dead.  So, will have to ask here.

I am interested in having a GUI that was not tied to GNOME (or KDE).  So a
"pure" gtk+ or even qt interface would be more to my liking, seeing as the
Motif interface is dead (no tears there).  Are there plans to do this
currently?  Would it be possible to #ifdef the existing GUI framwork to allow
this?  I am interested in helping, just wanted to ask before I gave a patch and
was told to sod off.

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

Re: question about having a "pure" gtk interface

[Dave Peticolas]

> Hi, the archive search on the website seems dead.  So, will have to ask here.
> 
> I am interested in having a GUI that was not tied to GNOME (or KDE).  So a
> "pure" gtk+ or even qt interface would be more to my liking, seeing as the
> Motif interface is dead (no tears there).  Are there plans to do this
> currently?  Would it be possible to #ifdef the existing GUI framwork to allow
> this?  I am interested in helping, just wanted to ask before I gave a patch a
> was told to sod off.

The central GUI widget of the UI, the register, uses the
gnome canvas. This is a gnome widget, not a gtk widget,
and there's no way we could #ifdef our way out of using
it.

dave

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

Re: wtf? scheme weirdness

[Bill Gribble]

Rob Browning <[EMAIL PROTECTED]> writes:
> Bryan Larsen <[EMAIL PROTECTED]> writes:
> > remainder is complaining that I'm not using an integer, but I'm
> > using floor to give it an integer.

floor doesn't return an integer (which is an exact quantity), just a
floating point number (inexact quantity) with the fractional part
being zero.  You need to call inexact->exact on the result to convert
it to a "real" (exact) integer.

b.g.

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

Re: question about having a "pure" gtk interface

[Sean 'Shaleh' Perry]

> 
> The central GUI widget of the UI, the register, uses the
> gnome canvas. This is a gnome widget, not a gtk widget,
> and there's no way we could #ifdef our way out of using
> it.
> 

I understand.  What else is the UI depending on from GNOME libs?  The canvas
may not be an issue.

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

Re: question about having a "pure" gtk interface

[Dave Peticolas]

> 
> > 
> > The central GUI widget of the UI, the register, uses the
> > gnome canvas. This is a gnome widget, not a gtk widget,
> > and there's no way we could #ifdef our way out of using
> > it.
> > 
> 
> I understand.  What else is the UI depending on from GNOME libs?  The canvas
> may not be an issue.

We also use the gnome date entry widget, the gnome app widget,
the gnome app bar widget, the gnome app helper routines, gnome
dialog widgets, the gnome file picker, gnome_url_show, gnome popup menus,
the gnome dock widget and the gnome property box. We plan on using
the gnome druids, too. I think I probably missed a few, as well.

If you do decide to make a gtk-only version, I would prefer you
use a separate tree for the gtk stuff, as in the unfinished qt
version, rather than cluttering up the code with tons of #ifdefs.

dave

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

Re: question about having a "pure" gtk interface

[Bill Gribble]

"Sean 'Shaleh' Perry" <[EMAIL PROTECTED]> writes:
> I understand.  What else is the UI depending on from GNOME libs?  The canvas
> may not be an issue.

Right now, the code that I have in gnucash depends on the gnome-dialog
widget (this is probably expendable) and the gnome-print facilities.
gnome-print also depends on the canvas.  I am hoping that we will
fairly soon move to the new GNOME gtk-html widget, which is itself
dependent on gnome-print.  I'm interested in looking at using Bonobo
for building smarter and more interactive reports, but none of that is
in gnucash right now.

What's the problem with GNOME dependencies as long as we don't
preclude interoperability with KDE-based desktops and systems that
don't use desktop "frameworks"?  The GNOME libraries are no more
invasive than, say, GNU readline.. just a set of libraries that
applications can link with.  Installing the gnome libraries is
something that can be done smoothly and automatically at install time
with no real impact on the user.

Are you looking at a particular application for gnucash that would
choke on the additional resource requirements of GNOME?  You mention
that the canvas dependency "may not be an issue", indicating that
you're looking at a display-less or reduced-display gnucash.  Is that
a misinterpretation of your post?
 
Bill Gribble

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

Re: question about having a "pure" gtk interface

[Sean 'Shaleh' Perry]

Purely religious.  But I see no need to hash over it.  Playing with either the
qt tree or a new gtk+ one is fine by me, I just wanted to see how far down the
path you were.

Thanks Bill and Dave.

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

Re: question about having a "pure" gtk interface

[linas]

It's been rumoured that Sean 'Shaleh' Perry said:
> 
> Hi, the archive search on the website seems dead.  So, will have to ask here.
> 
> I am interested in having a GUI that was not tied to GNOME (or KDE).  So a
> "pure" gtk+ or even qt interface would be more to my liking, seeing as the

Why?  I gather there is something about hooking in too strongly to gnome
that you won't like ...

--linas

p.s. I hope to split off the 'engine' which has no gui bits in it at all
into a separate packge not to long from now.


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

Re: How do you handle mutual fund purchases and roundoff?

[linas]

It's been rumoured that Rob Browning said:
> 
> 
> After a few minutes of scratching my head, I realized that the numbers
> they were giving me weren't telling me what I thought they were.  The
> information they give (making up some numbers) is a total cost for the
> purchase (say $1000), including the share price (say $10.001), and the
> quantity (100.000).  

Well, $10.001 * 100.000 != $1000  
Whose making this error? gnucash? (ouch, bad bug!)
Or your financial institution (FI)?

To be paranoid, in the good-old days, sub-dollar amount errors were 
indicative of white-collar crime.  I used to have a checking account
that one day stopped balancing and after half a year of this, the FDIC
shut them down.

You need to determine whther the price was really $10.001 and you own 
99.999 shares, or whether you have 100 shares, and actually just
happened to pay $10.000/share, instead of what they say the price was.

> In the description for the transaction, they also
> list a transaction cost (say $30 -- it's a loaded fund).
> 
> First note that the total isn't the same as the quantity times the
> price.  It's actually off by about $0.10 in my favor, which they claim
> is just roundoff in the share price as compared to what it "should
> have been".  Even given that, if the share price and the quantity are
> correct, then I can't figure out what happened to the transaction
> cost.  because it's not deducted from anywhere else, and for it to be
> included in the "direct way", the overal transaction value would have
> had to be $1030.

Right ... this would be a split, with $30 marked as a fee.

Or are you saying that the share price was really 9.700?
There is a difference w.r.t. cap gains taxes ...

Or maybe there is a separate $30 decuction somewhere else, in a not
obvius place (e.g. on page 3 of what the bank sent you)?

It sounds to me like your FI has poorly-designed reports.  I am not 
sure what to do in such a case...

--linas
 

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

gnome-print?

[Linas Vepstas]

Check printing requires gnome-print.  The only (precompiled) gnome-print
that I could find was that which comes with gnumeric.  Howeve, installing
gnumeric doesn't make it work.  What's the secret?  (And can we add it to
the README?)

--linas

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

Re: gnucash compilation error

[Rob Browning]

Bruce and Liz Chaplin <[EMAIL PROTECTED]> writes:

> Thanks Bryan...that fixed the problem. My g-wrap-install directory
> had also been created at / (!)...not sure why. After moving it to
> gnucash/lib/g-wrap-install, things compiled cleanly.

This was a bug in my recent changes to the build code.  autoconf just
really doesn't quite do what you want sometimes.

In any case, this is a good example of why you should probably *never*
be building development code as root.

Sorry for the inconvenience.

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

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

Re: How do you handle mutual fund purchases and roundoff?

[Rob Browning]

[EMAIL PROTECTED] writes:

> Well, $10.001 * 100.000 != $1000  
> Whose making this error? gnucash? (ouch, bad bug!)
> Or your financial institution (FI)?

It's the report from the financial institution.  Don't worry, if I
thought it was gnucash, I would have made a lot more noise.  First
thing I did was check that.

It looks like Dakshi may be right.  The price per share that they
quote isn't actually what you paid.  It's rounded, and what's worse,
the load is computed as part of the purchase price, so to figure out
what you really paid, i.e. what you need to enter into gnucash, you
have to take the total transaction price, subtract off the transaction
fee they quote, then divide the remainder by the number of shares.
This is the *real* price you paid for each share.  In cases like this
(loaded funds) it'll never be what's on the statement, and it looks
like at least two large institutions do things this way.

I may double check with the institution to make sure I've interpreted
this right, but if so, then I'll see about writing this up for the
docs.

> Or are you saying that the share price was really 9.700?
> There is a difference w.r.t. cap gains taxes ...

Hard to tell really.  It does look like the transaction fee was
incorporated into the purchase, but given that, then either the number
of shares or the price is "wrong".  The price seems the most likely.
I *think* perhaps they actually sell the shares to you at a marginally
inflated cost at the time of purchase to cover the load.

> Or maybe there is a separate $30 decuction somewhere else, in a not
> obvius place (e.g. on page 3 of what the bank sent you)?

I don't think so; so far it doesn't look like it affects any of the
other balances.

> It sounds to me like your FI has poorly-designed reports.  I am not
> sure what to do in such a case...

It's definitely not intuitive, but I've heard similar things from
others about mutual funds being weird.  I'll see if I can get some
clarification from the institution; they at least seemed somewhat
interested in fixing the reports if they need "fixing".  I suspect
though, that there may be some "standard" here that I just don't know
about.

It's also possible that I'm just overlooking something obvious.  I'm
going to go back and check things carefully again.

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

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

so many files

[Lauren Matheson]

What are all of the gnucash data files for?  which are necessary to keep
(it just seems to create more and more)?

Lauren.



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

Re: gnome-print?

[Bill Gribble]

Linas Vepstas <[EMAIL PROTECTED]> writes:
> Check printing requires gnome-print.  The only (precompiled) gnome-print
> that I could find was that which comes with gnumeric.  Howeve, installing
> gnumeric doesn't make it work.  What's the secret?  (And can we add it to
> the README?)

I use Debian, which has a gnome-print package.  I figured
(incorrectly, it seems) that if there was a Debian package there would
also be one for other common distributions.

Under Debian, what you need to do is 
  # apt-get install gnome-print 

I have heard the term "rpmfind" associated with locating RPMs of
various software, but I don't know if that's a program you run on your
machine, a web site, or what.

You can get the source for the Debian gnome-print package at 
ftp.debian.org:/debian/dists/potato/main/source/admin/gnome-print*,
or through the Gnome CVS server:

  cvs -d :pserver:[EMAIL PROTECTED]:/cvs/gnome login
(hit return at prompt)
  cvs -d :pserver:[EMAIL PROTECTED]:/cvs/gnome checkout gnome-print

I'm a little perturbed that gnome-print isn't more readily available
for non-Debian distributions; my working assuption has always been
that there's basically the same set of packages available for all the
major distributions.  Since configure detects whether gnome-print is
installed, there's no harm in leaving it in the source tree, I guess,
but can someone with more knowledge about Red Hat, SuSE, etc give an
opinion about how long it's likely to be before the newer Gnome
components are widely available for them?

Thanks,
Bill Gribble


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

Re: ignore last message.

[Christopher Browne]

On 03 Apr 2000 09:51:04 CDT, the world broke into rejoicing as
Rob Browning <[EMAIL PROTECTED]>  said:
> Bryan Larsen <[EMAIL PROTECTED]> writes:
> 
> > Sorry.  I was RTFM'ing, but I didn't get quite far enough before I
> > gave up.
> 
> OK, ignore my previous response, then too :>

The problem, which I ran into with SRFI 19, was that the "obvious"
way of grabbing the integer part of a floating point number does not work.

(truncate 25.0) returns 25.0.  Which is still a FP value.   Oops.
(inexact->exact 25.0) returns 25.  An integer, as desired...

There looks to be some sort of nonconformance with R4RS (or R5RS) in
this somewhere...
--
"Keep your arms and legs attached to your torso at all times."
-- [EMAIL PROTECTED] (Eric Griswold)
[EMAIL PROTECTED] - 

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

Re: gnome-print?

[Dave Peticolas]

> Linas Vepstas <[EMAIL PROTECTED]> writes:
> > Check printing requires gnome-print.  The only (precompiled) gnome-print
> > that I could find was that which comes with gnumeric.  Howeve, installing
> > gnumeric doesn't make it work.  What's the secret?  (And can we add it to
> > the README?)
> 
> I use Debian, which has a gnome-print package.  I figured
> (incorrectly, it seems) that if there was a Debian package there would
> also be one for other common distributions.
> 
> Under Debian, what you need to do is 
>   # apt-get install gnome-print 
> 
> I have heard the term "rpmfind" associated with locating RPMs of
> various software, but I don't know if that's a program you run on your
> machine, a web site, or what.
> 
> You can get the source for the Debian gnome-print package at 
> ftp.debian.org:/debian/dists/potato/main/source/admin/gnome-print*,
> or through the Gnome CVS server:
> 
>   cvs -d :pserver:[EMAIL PROTECTED]:/cvs/gnome login
> (hit return at prompt)
>   cvs -d :pserver:[EMAIL PROTECTED]:/cvs/gnome checkout gnome-print
> 
> I'm a little perturbed that gnome-print isn't more readily available
> for non-Debian distributions; my working assuption has always been
> that there's basically the same set of packages available for all the
> major distributions.  Since configure detects whether gnome-print is
> installed, there's no harm in leaving it in the source tree, I guess,
> but can someone with more knowledge about Red Hat, SuSE, etc give an
> opinion about how long it's likely to be before the newer Gnome
> components are widely available for them?

The only rpm packages for gnome-print I am aware of
are the helix code ones. I haven't tried them, though.

The thing is, gnome-print isn't considered part of
the gnome development platform proper, it's still
considered unstable afaik. I wouldn't expect to see
packages for it until it is considered a part of the
stable platform. ditto for gtk-html and bonobo.

dave

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

Re: gnome-print?

[linas]

It's been rumoured that Dave Peticolas said:
> The only rpm packages for gnome-print I am aware of
> are the helix code ones. I haven't tried them, though.

thanks, I cactually found an rpm on rufus.w3.org and am recompiling now.


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

Re: so many files

[linas]

It's been rumoured that Lauren Matheson said:
> 
> What are all of the gnucash data files for?  which are necessary to keep
> (it just seems to create more and more)?

Well, the *theory* was that efveryone who mainipulated financial data
would be backup-paranoid.  Each date-stamped *.xac file is just a 
backup of the last time you clicked on 'save'.   Each date-stamped
*.log file is a log of all the adds, deletes, changes that you did.
You can erase all of them, although, of course, if you break something
whuile balancing your checkbook, you won't have an old version to go
back to ...

Anyone have a better idea on how to have backup-paranoia without
cluttering up the directory too much?

--linas


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

Re: so many files

[Paul Fenwick]

G'day GnuCashers,

On Mon, Apr 03, 2000 at 09:07:40PM -0400, [EMAIL PROTECTED] wrote:
 
> Well, the *theory* was that efveryone who mainipulated financial data
> would be backup-paranoid.  Each date-stamped *.xac file is just a 
> backup of the last time you clicked on 'save'.   Each date-stamped
> *.log file is a log of all the adds, deletes, changes that you did.
> You can erase all of them, although, of course, if you break something
> whuile balancing your checkbook, you won't have an old version to go
> back to ...
 
> Anyone have a better idea on how to have backup-paranoia without
> cluttering up the directory too much?

Some ideas:

(1) Configurable settings on how many backups GnuCash will keep.
This could be in days, bytes, files, or all three.  Properly
paranoid people would select `unlimited'.

(2) Configurable directory to place backups.  This would allow
users to keep lots of backups without having to look at them
all the time.  For example, I might store my `working'
GnuCash file in "~/finance/personal/pjf.xac", but want the
backups to go into "~/.gnucash-backups/personal/".  In this
way my ~/finance/personal/ directory looks nice and clean,
but I can still get to all my backups if I need them.  It
also allows truly paranoid people to store their files on
a different disk (for example) for extra security.

Personally I don't think item number (1) is worth it.  The
backup files don't take up much space, and probably SHOULD be kept
even if the user thinks they only need to keep 5 days worth of data.

Option (2) shouldn't be too tricky to implement and provides
a nice clean method of keeping all the backups without them cluttering
the working directory.

Cheers,

Paul

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

Re: so many files

[Scott Haug]

On Tue, Apr 04, 2000 at 12:19:36PM +1000, Paul Fenwick wrote:
> G'day GnuCashers,
> 
> On Mon, Apr 03, 2000 at 09:07:40PM -0400, [EMAIL PROTECTED] wrote:
>  
> > Well, the *theory* was that efveryone who mainipulated financial data
> > would be backup-paranoid.  Each date-stamped *.xac file is just a 
> > backup of the last time you clicked on 'save'.   Each date-stamped
> > *.log file is a log of all the adds, deletes, changes that you did.
> > You can erase all of them, although, of course, if you break something
> > whuile balancing your checkbook, you won't have an old version to go
> > back to ...
>  
> > Anyone have a better idea on how to have backup-paranoia without
> > cluttering up the directory too much?
> 
> Some ideas:
> 
>   (1) Configurable settings on how many backups GnuCash will keep.
>   This could be in days, bytes, files, or all three.  Properly
>   paranoid people would select `unlimited'.

I like this idea a lot.

> 
>   (2) Configurable directory to place backups.  This would allow
>   users to keep lots of backups without having to look at them
>   all the time.  For example, I might store my `working'
>   GnuCash file in "~/finance/personal/pjf.xac", but want the
>   backups to go into "~/.gnucash-backups/personal/".  In this
>   way my ~/finance/personal/ directory looks nice and clean,
>   but I can still get to all my backups if I need them.  It
>   also allows truly paranoid people to store their files on
>   a different disk (for example) for extra security.
> 

I like this idea, too.  I also think it would be nice if, in the gnucash
preferences, it would store the name/path of the last file saved, and would
open that file by default if no file is given as a command-line parameter.

>   Personally I don't think item number (1) is worth it.  The
> backup files don't take up much space, and probably SHOULD be kept
> even if the user thinks they only need to keep 5 days worth of data.
> 

I think it's worth it.  And my gnucash data file is over 500K in size, and I'm
many other users have backups that far exceed that.  I use gnucash nearly every
day, and during extensive use I might save several times a session.  Those half
meg backups add up.  Having some sort of time/size/etc. limitation (or, at the
very least, an option to not automatically save a backup copy with every)
backup would help keep that under control.

The version of quicken I used would prompt the user to make a backup every
third save.  I think that number was configurable.  It would then prompt for a
place to save the backup, with the last backup path used as a default path.

>   Option (2) shouldn't be too tricky to implement and provides
> a nice clean method of keeping all the backups without them cluttering
> the working directory.

Agreed.

> 
>   Cheers,
> 
>   Paul
> 

-Scott

-- 

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

Re: so many files

[Rob Walker]

> On Mon, 3 Apr 2000 21:07:40 -0400 (EDT), [EMAIL PROTECTED] said:

linas> Anyone have a better idea on how to have backup-paranoia
linas> without cluttering up the directory too much?

text (XML?) data files and RCS directories, with ,v files therein..

rob

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

Re: so many files

[Rob Walker]

> On Tue, 4 Apr 2000 12:19:36 +1000, Paul Fenwick
> <[EMAIL PROTECTED]> said:

Paul> (2) Configurable directory to place backups.  This would allow

that's brilliant!  as a matter of fact, it is so brilliant, emacs has
already done it, thus cementing that idea into the "brilliant idea
hall of fame".

C-h v auto-save-directory RET  (note the other wonderful directories
at the bottom, for efs-stuff).

oh, how I long for the day when I can use efs over ssh to "edit" my
gnucash data files in an emacs major mode, with the efs-saves ocurring 
on the home side of the link.

rob

ps.  /home/rob is on nfs, so autosaves are done locally.


`auto-save-directory' is a variable declared in Lisp.

Value: "/var/tmp/rob/rob-autosave"

Documentation:
If non-nil, fixed directory for autosaving: all autosave files go
there.  If this directory does not yet exist at load time, it is
created and its mode is set to 0700 so that nobody else can read your
autosave files.

If nil, each autosave files goes into the same directory as its
corresponding visited file.

A non-nil `auto-save-directory' could be on a local disk such as in
/tmp, then auto-saves will always be fast, even if NFS or the
automounter is slow.  In the usual case of /tmp being locally mounted,
note that if you run emacs on two different machines, they will not
see each other's auto-save files.

The value (expand-file-name "~/autosave/") might be better if /tmp
is mounted from swap (possible in SunOS, type `df /tmp' to find out)
and thus vanishes after a reboot, or if your system is particularly
thorough when cleaning up /tmp, clearing even non-empty subdirectories.

It should never be an efs remote filename because that would
defeat `efs-auto-save-remotely'.

Unless you set `auto-save-hash-p', you shouldn't set this to a
directory in a filesystem that does not support long filenames, since
a file named

/home/sk/lib/emacs/lisp/auto-save.el

will have a longish filename like

AUTO-SAVE-DIRECTORY/#\!home\!sk\!lib\!emacs\!lisp\!auto-save.el#

as auto save file.

See also variables `auto-save-directory-fallback',
`efs-auto-save' and `efs-auto-save-remotely'.

-- 
"You know, I used to think it was awful that life was so unfair.  Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

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

Re: so many files

[Rob Walker]

> On Mon, 3 Apr 2000 21:27:22 -0500, Scott Haug
> <[EMAIL PROTECTED]> said:

Scott> I might save several times a session.  Those half meg backups

you shouldn't _have_ to hit save, as emacs users already know:

C-h v auto-save-interval RET

`auto-save-interval' is a built-in integer variable.

Value: 1500

Documentation:
*Number of keyboard input characters between auto-saves.
Zero means disable autosaving due to number of characters typed.
See also the variable `auto-save-timeout'.


C-h v auto-save-timeout RET

`auto-save-timeout' is a variable declared in Lisp.

Value: 30

Documentation:
*Number of seconds idle time before auto-save.
Zero or nil means disable auto-saving due to idleness.

The actual amount of idle time between auto-saves is logarithmically related
to the size of the current buffer.  This variable is the number of seconds
after which an auto-save will happen when the current buffer is 50k or less;
the timeout will be 2 1/4 times this in a 200k buffer, 3 3/4 times this in a
1000k buffer, and 4 1/2 times this in a 2000k buffer.

See also the variable `auto-save-interval', which controls auto-saving based
on the number of characters typed.


rob



-- 
Windows NT crashed.
I am the Blue Screen of Death.
No one hears your screams.


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

Re: so many files

[Christopher Browne]

On Mon, 03 Apr 2000 21:27:22 CDT, the world broke into rejoicing as
Scott Haug <[EMAIL PROTECTED]>  said:
> On Tue, Apr 04, 2000 at 12:19:36PM +1000, Paul Fenwick wrote:
> > G'day GnuCashers,
> > 
> > On Mon, Apr 03, 2000 at 09:07:40PM -0400, [EMAIL PROTECTED] wrote:
> >  
> > > Well, the *theory* was that efveryone who mainipulated financial data
> > > would be backup-paranoid.  Each date-stamped *.xac file is just a 
> > > backup of the last time you clicked on 'save'.   Each date-stamped
> > > *.log file is a log of all the adds, deletes, changes that you did.
> > > You can erase all of them, although, of course, if you break something
> > > whuile balancing your checkbook, you won't have an old version to go
> > > back to ...
> >  
> > > Anyone have a better idea on how to have backup-paranoia without
> > > cluttering up the directory too much?
> > 
> > Some ideas:
> > 
> > (1) Configurable settings on how many backups GnuCash will keep.
> > This could be in days, bytes, files, or all three.  Properly
> > paranoid people would select `unlimited'.
> 
> I like this idea a lot.
> > 
> > (2) Configurable directory to place backups.  This would allow
> > users to keep lots of backups without having to look at them
> > all the time.  For example, I might store my `working'
> > GnuCash file in "~/finance/personal/pjf.xac", but want the
> > backups to go into "~/.gnucash-backups/personal/".  In this
> > way my ~/finance/personal/ directory looks nice and clean,
> > but I can still get to all my backups if I need them.  It
> > also allows truly paranoid people to store their files on
> > a different disk (for example) for extra security.
> 
> I like this idea, too.  I also think it would be nice if, in the gnucash
> preferences, it would store the name/path of the last file saved, and would
> open that file by default if no file is given as a command-line parameter.
> 
> > Personally I don't think item number (1) is worth it.  The
> > backup files don't take up much space, and probably SHOULD be kept
> > even if the user thinks they only need to keep 5 days worth of data.
> > 
> 
> I think it's worth it.  And my gnucash data file is over 500K in size,
> and I'm many other users have backups that far exceed that.  I use
> gnucash nearly every day, and during extensive use I might save several
> times a session.  Those half meg backups add up.  Having some sort
> of time/size/etc. limitation (or, at the very least, an option to not
> automatically save a backup copy with every) backup would help keep that
> under control.

Toss in a bit more complexity and this might make some of the choices 
easier...

Meaningful Storage Options:
  a) Store binary backups
  b) Store *compressed* binary backups
  c) Store *text* backups, compressed.
  d) Store *text* backups, checked in to RCS :-).

It is not overly difficult to check for the presence of gzip and
RCS; those options provide the ability to:
a) Diminish disk space consumption without any loss of useful data;
b) Use meaningful version control that sort of amounts to providing
   "transactional roll-back."

Option d) [RCS] is a *prime* reason why I would argue for using a
text-based data format.

Note that this establishes that it is preferable for there to be
a consistent ordering of transactions so that if one transaction is
changed, only that portion of the output changes.  e.g. - if there are
1500 transactions, and one in the "middle" is changed, there should only
be a few lines of the file that change.  It would be rather aggravating
if changing one transaction changed the order of the results.  Therefore
while it may be perfectly fine to store the data in a hash table in
memory, a sort should be done to determine output ordering...
--
We are Pentium of Borg.  Division is futile. You will be approximated.
(seen in someone's .signature)
[EMAIL PROTECTED] - 

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

Re: so many files

[Rob Walker]

> On Mon, 03 Apr 2000 21:47:53 -0500, Christopher Browne
> <[EMAIL PROTECTED]> said:

Christopher> d) Store *text* backups, checked in to RCS :-).

Christopher> Option d) [RCS] is a *prime* reason why I would argue for
Christopher> using a text-based data format.

Agreed completely.  However, I think that Larry McVoy is on to
something when he mentions the lack of data integrity being built into 
RCS via checksums or some other method.

rob

-- 
The good thing about standards is that there are so many to choose
from.  -- Andrew S. Tanenbaum

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

Re: How do you handle mutual fund purchases and roundoff?

[Christopher Browne]

On 03 Apr 2000 19:38:57 CDT, the world broke into rejoicing as
Rob Browning <[EMAIL PROTECTED]>  said:
> [EMAIL PROTECTED] writes:
> 
> > Well, $10.001 * 100.000 != $1000  
> > Whose making this error? gnucash? (ouch, bad bug!)
> > Or your financial institution (FI)?
> 
> It's the report from the financial institution.  Don't worry, if I
> thought it was gnucash, I would have made a lot more noise.  First
> thing I did was check that.
> 
> It looks like Dakshi may be right.  The price per share that they
> quote isn't actually what you paid.  It's rounded, and what's worse,
> the load is computed as part of the purchase price, so to figure out
> what you really paid, i.e. what you need to enter into gnucash, you
> have to take the total transaction price, subtract off the transaction
> fee they quote, then divide the remainder by the number of shares.
> This is the *real* price you paid for each share.  In cases like this
> (loaded funds) it'll never be what's on the statement, and it looks
> like at least two large institutions do things this way.
> 
> I may double check with the institution to make sure I've interpreted
> this right, but if so, then I'll see about writing this up for the
> docs.
> 
> > Or are you saying that the share price was really 9.700?
> > There is a difference w.r.t. cap gains taxes ...
> 
> Hard to tell really.  It does look like the transaction fee was
> incorporated into the purchase, but given that, then either the number
> of shares or the price is "wrong".  The price seems the most likely.
> I *think* perhaps they actually sell the shares to you at a marginally
> inflated cost at the time of purchase to cover the load.
> 
> > Or maybe there is a separate $30 decuction somewhere else, in a not
> > obvius place (e.g. on page 3 of what the bank sent you)?
> 
> I don't think so; so far it doesn't look like it affects any of the
> other balances.
> 
> > It sounds to me like your FI has poorly-designed reports.  I am not
> > sure what to do in such a case...
> 
> It's definitely not intuitive, but I've heard similar things from
> others about mutual funds being weird.  I'll see if I can get some
> clarification from the institution; they at least seemed somewhat
> interested in fixing the reports if they need "fixing".  I suspect
> though, that there may be some "standard" here that I just don't know
> about.
> 
> It's also possible that I'm just overlooking something obvious.  I'm
> going to go back and check things carefully again.

Suggestion:

What this is establishing is that the calculations may be "fuzzy" on
the statements.

Which means that a reasonable thing to do is to have GnuCash try to
do *exact* calcs, find the "fuzz," and then ask you what to do about
it.

It is *reasonably* likely that what is happening here is that the
institution is rounding off the price-per-unit.

If you've paid in $532.25, with a $20 commission, and the recent
fund price was $25.52, then what likely happens is that they charge
you $532.25 for 20.07 shares.

That is off by about $0.06; the values that, in this case, are most
likely to be precise are:

a) The $532.25, and
b) The $20.07 shares.

If GnuCash does a "precise" calculation here, it can find the $0.06
cents, and it makes sense for it to ask you to tell it what to do about
the "fuzz."

Sensible options:
a) Adjust the price-per-share.  Probably a good default.
b) Adjust the total price paid.  Probably a *bad* default; this is most
   likely the most precise number that's here.
c) Adjust the commission.  Second best to a).
d) Adjust the number of shares.  Probably a *bad* default; this is 
   likely to be almost as precise as the total price.

Giving a choice is probably good; supplying a good default so that
"pressing enter" is most likely to "do the right thing" is also a good
idea.
--
"(Windows NT) version 5.0 will build on a proven system architecture
and incorporate tens of thousands of bug fixes from version 4.0."
-- 
[After the "65000 bugs" episode, this is Rather Scary...]
[EMAIL PROTECTED] - 

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

Re: so many files

[linas]

It's been rumoured that Rob Walker said:
> 
> 
> Christopher> d) Store *text* backups, checked in to RCS :-).
> 
> Christopher> Option d) [RCS] is a *prime* reason why I would argue for
> Christopher> using a text-based data format.

Well, I like this, it does have a certain aesthetic appeal.

-- I beleive it should be quite easy to create an xml version of the
   data file.  Just copy FileIO.c and replace all occurances of
 write( fd, &numAcc, sizeof(int) ); 
   with 
 fprintf (fh, "%d\n", numAcc);

-- I have battle scars from five years ago, when the VRML mailing list
   used to list '#1 top priority - binary file format' and I naively
   suggested using gzip on the then-current ascii file format.
   Despite considerable back & forth, I lost; the binary file format 
   was invented and was still much better than gzip, and faster too.

   Although cpus are faster today, and will continue to be,  if 
   save file is 500K binary, how big would the gzipp'ed version be?
   How long would it take to zip/unzip?

> Agreed completely.  However, I think that Larry McVoy is on to
> something when he mentions the lack of data integrity being built into 
> RCS via checksums or some other method.

Hmm. This does make me nervous. 

-- Single byte corruptions, e.g. someone vi'ed the rcs file, intending
   to only view some version number, and accidentally deleted/added one
   byte.  Oops!  *all* versions potentially corrupted.

-- Multi-byte corruptions, e.g. incomplete writes due to lack of disk
   space.

Ugh, I have more than once run out of file system space.  The current 
backup scheme is designed to always leave you with a usable (if older) 
copy no matter what.  I don't want to loose that.  

> -- 
> The good thing about standards is that there are so many to choose
> from.  -- Andrew S. Tanenbaum
> 
> --

--linas


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

Re: so many files

[Rob Walker]

> On Mon, 3 Apr 2000 23:37:41 -0400 (EDT), [EMAIL PROTECTED] said:

linas> It's been rumoured that Rob Walker said:
>> 
>> 
Christopher> d) Store *text* backups, checked in to RCS :-).
>> 
Christopher> Option d) [RCS] is a *prime* reason why I would argue for
Christopher> using a text-based data format.

linas> Well, I like this, it does have a certain aesthetic appeal.

linas> -- I beleive it should be quite easy to create an xml version of the
linas> data file.  Just copy FileIO.c and replace all occurances of

linas> write( fd, &numAcc, sizeof(int) ); 

linas> with 

linas> fprintf (fh, "%d\n", numAcc);

Interesting.  I tried to do it with sed, but my sed-fu is weak.

linas> -- I have battle scars from five years ago, when the VRML
linas> mailing list used to list '#1 top priority - binary file
linas> format' and I naively suggested using gzip on the then-current
linas> ascii file format.  Despite considerable back & forth, I lost;
linas> the binary file format was invented and was still much better
linas> than gzip, and faster too.

linas> Although cpus are faster today, and will continue to be, if
linas> save file is 500K binary, how big would the gzipp'ed version
linas> be?  How long would it take to zip/unzip?

why do we want to compress it?  if the wrong part of the file gets
corrupted, no one can uncompress it.  at all.  ever.

>> Agreed completely.  However, I think that Larry McVoy is on to
>> something when he mentions the lack of data integrity being built
>> into RCS via checksums or some other method.

linas> Hmm. This does make me nervous. 

linas> -- Single byte corruptions, e.g. someone vi'ed the rcs file,
linas> intending to only view some version number, and accidentally
linas> deleted/added one byte.  Oops!  *all* versions potentially
linas> corrupted.

linas> -- Multi-byte corruptions, e.g. incomplete writes due to lack
linas> of disk space.

Is there a reason some sort of checksums couldn't be created (per
file, per line, per chunk of output, I don't know) for data integrity,
and after someone edited the file, there would have to be some way to
re-check for integrity, and then re-create the checksums so that
future invocations of the file could read the data and trust it.

linas> Ugh, I have more than once run out of file system space.  The
linas> current backup scheme is designed to always leave you with a
linas> usable (if older) copy no matter what.  I don't want to loose
linas> that.

Why would we have to lose that?  Another nice thing about RCS is that
it doesn't need to have the entire file saved each time.

rob

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

Re: about scheme and guile in the future

[linas]

It's been rumoured that LE NY Yannick said:
> 
> Take a look at this page:
> http://www.freshmeat.net/news/2000/04/01/954615693.html

 lapin lapin


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

Re: so many files

[linas]

It's been rumoured that Rob Walker said:
> linas> -- I beleive it should be quite easy to create an xml version of the
> linas> data file.  Just copy FileIO.c and replace all occurances of
> 
> linas> write( fd, &numAcc, sizeof(int) ); 
> 
> linas> with 
> 
> linas> fprintf (fh, "%d\n", numAcc);
> 
> Interesting.  I tried to do it with sed, but my sed-fu is weak.

Well, its a little more complicated than that...

> linas> Although cpus are faster today, and will continue to be, if
> linas> save file is 500K binary, how big would the gzipp'ed version
> linas> be?  How long would it take to zip/unzip?
> 
> why do we want to compress it?  if the wrong part of the file gets
> corrupted, no one can uncompress it.  at all.  ever.

My own data file is 185K today.  In the above example, 
sizeof(int)  is 4 bytes, while 
%d  is 25 to 30 bytes 

Thus, my uncompressed data file would be 185*25/4= 1MB which is a bit
fat.  compression is needed.

> linas> -- Multi-byte corruptions, e.g. incomplete writes due to lack
> linas> of disk space.
> 
> Is there a reason some sort of checksums couldn't be created (per
> file, per line, per chunk of output, I don't know) for data integrity,
> and after someone edited the file, there would have to be some way to
> re-check for integrity, and then re-create the checksums so that
> future invocations of the file could read the data and trust it.

We could have checksums per-transaction, or per-account, or both.
That might not be a bad idea for the binary file format.

I thought you meant 'rcs should have rcs checksums'

> linas> Ugh, I have more than once run out of file system space.  The
> linas> current backup scheme is designed to always leave you with a
> linas> usable (if older) copy no matter what.  I don't want to loose
> linas> that.
> 
> Why would we have to lose that?  Another nice thing about RCS is that
> it doesn't need to have the entire file saved each time.

If the rcsdiff is 1K bytes and you have 10 bytes left on disk, oops!
Its not about versioning, its about leaving one file intact, while
another is being written.  

e.g.
 cp -p RCS/mymoney.gnc,v RCS/mymoney.gnc,v.tmp
 if [ $? -ne 0 ] echo "oops"; exit;
 ci mymoney.gnc
 if [ $? -ne 0 ] echo "oops" exit;
 rm RCS/mymoney.gnc,v.tmp 

That way, if we run out of disk space during ci, then at at least
we have an uncorrepted copy around.  

So even if we use rcs, there is a reason to have a backup :-)

--linas

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

Re: so many files

[Rob Walker]

> On Tue, 4 Apr 2000 00:20:10 -0400 (EDT), [EMAIL PROTECTED] said:

linas> fprintf (fh, "%d\n", numAcc);
>> 
>> Interesting.  I tried to do it with sed, but my sed-fu is weak.

linas> Well, its a little more complicated than that...

I thought so, but it might have been worth a try.

>> why do we want to compress it?  if the wrong part of the file gets
>> corrupted, no one can uncompress it.  at all.  ever.

linas> My own data file is 185K today.  In the above example, 
linas> sizeof(int)  is 4 bytes, while 
linas> %d  is 25 to 30 bytes 

linas> Thus, my uncompressed data file would be 185*25/4= 1MB which is
linas> a bit fat.  compression is needed.

1MB is kinda big?  

/home/rob/mail
$ ls -al INBOX
-rw---   1 rob  rob  68721246 Apr  3 22:32 INBOX
$

and VM is happy editing that for, um, _days_ at a time.  I just
performed a save, and top showed the following:

658 rob0   0  121M 120M  2124 D   0 58.7 31.8 266:38  xemacs

yes, 266 minutes of cpu time, with pid 658.

$ uptime
 10:34pm  up 18 days,  9:21, 12 users,  load average: 1.09, 1.08, 1.02
$

linas> We could have checksums per-transaction, or per-account, or
linas> both.  That might not be a bad idea for the binary file format.

not for the text?

linas> I thought you meant 'rcs should have rcs checksums'

I do, I mean that it would be helpful if we could _know_ that our data 
was being read and written properly, with no corruption.  or at least
say, "we are _pretty sure_"

>> Why would we have to lose that?  Another nice thing about RCS is
>> that it doesn't need to have the entire file saved each time.

linas> If the rcsdiff is 1K bytes and you have 10 bytes left on disk,
linas> oops!  Its not about versioning, its about leaving one file
linas> intact, while another is being written.

that's true.  what to do about it?

linas> e.g.
linas> cp -p RCS/mymoney.gnc,v RCS/mymoney.gnc,v.tmp
linas> if [ $? -ne 0 ] echo "oops"; exit;
linas> ci mymoney.gnc
linas> if [ $? -ne 0 ] echo "oops" exit;
linas> rm RCS/mymoney.gnc,v.tmp 

linas> That way, if we run out of disk space during ci, then at at
linas> least we have an uncorrepted copy around.

I see.

linas> So even if we use rcs, there is a reason to have a backup :-)

yes, that is true.  I do, however, think that some sort of
checksumming would be nice, even if it is not required.

rob

-- 
"I would turn the question around, and ask, 'If it's a hobby for us
and a job for you, then why are you doing such a shoddy job?"
-- Linus Torvalds

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

cvs 2000-04-03

[Dave Peticolas]

CVS has been updated.

New Stuff:

 + A fix to the configuration of the locale directory. This should
   eliminate the need to give the --with-locale-dir argument to
   configure.

 + Menu structures used to create the main window and register menus
   are allocated statically. This required some additions to the
   translatable strings.

 + po files have been updated.


dave

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

Re: so many files

[Rob Browning]

Christopher Browne <[EMAIL PROTECTED]> writes:

> Meaningful Storage Options:
>   a) Store binary backups
>   b) Store *compressed* binary backups

or use xdelta, presuming we check in to it and decide that it's stable
and well maintained enough to pursue as our back end.  I haven't
investigated it heavily, but it seems quite interesting.

For those that don't know, xdelta is like RCS, but it's designed to
handle any kind of data, including binary, is supposed to work really
well, and transparently handles gzipped data with some form of MD5sum
verification.  It's also available in library form.  Like RCS it would
give us the ability to do cool things like snapshot the data every so
often for nearly no cost.  Want to see what things looked like 6
months ago?  Just enter the right date into the "time-warp" dialog :>

For those on Debian systems, just install the xdelta and
libxdelta2-dev packages.  Others can get the source from
ftp://www.xcf.berkeley.edu/pub/xdelta/, or just go to
ftp.debian.org:/pub/debian/dists/unstable/main/source/utils/xdelta*.tar.gz

If someone gets a chance before I do, please check it out and report
back on how good it looks.  I've only given it a cursory examination
to date, but I hear that at least at one point, the GIMP was using it
as an optional file-save plug-in with obvious benefits.

We could also stack one of the ecc algorithms on top and get
full-blown redundancy for some fractional increase in file size.
However, both the gzip/bzip2 and ecc additions would require enough
disk space to unpack the entire file before proceeding, but these
days, I'm not too worried about that as long as we're careful to check
error conditions.

> Note that this establishes that it is preferable for there to be a
> consistent ordering of transactions so that if one transaction is
> changed, only that portion of the output changes.

Agreed.  This will be important regardless.

And just for the record, *if* we decide to do anything like this, I'm
equally happy with a text file format and gzip/bzip2 if the parsing
speeds are reasonable, though if we're going with text I might be
inclined to consider a stable, fast, well-tested parser like guile's
rather than rolling our own.  Of course that would insinuate guile
beneath the engine, and I'm not sure Linas would be too happy with
that -- perhaps rightly so.  Though I think the same objection would
apply to an xml library, and unlike xml, we already have guile
available.

In any case, with a text file and compression, the data file size
would probably be smaller, at least on disk, than what we have now.

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

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

Re: How do you handle mutual fund purchases and roundoff?

[Rob Browning]

Christopher Browne <[EMAIL PROTECTED]> writes:

> a) Adjust the price-per-share.  Probably a good default.
> b) Adjust the total price paid.  Probably a *bad* default; this is most
>likely the most precise number that's here.
> c) Adjust the commission.  Second best to a).
> d) Adjust the number of shares.  Probably a *bad* default; this is 
>likely to be almost as precise as the total price.

I agree with your assesment.  In my conversations with the financial
people, I got the impression that the flexible value was the
price-per-share, which makes sense, since it's the one that fluctuates
daily anyway.  The one I *know* you can't play with is the total
transaction value.  That one is the one that gets deducted from the
corresponding "clearing account", and you can see that happen.

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

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