I've just tried compiling the latest CVS version on FreeBSD 3.4
In both configure and compiling, I get the error:
cc1: Invalid option `-Werror-implicit-function-declaration'
For example, an excerpt from config.log:
configure:5461: checking for XpmReadFileToXpmImage in -lXpm
configure:5480: gcc
Dave Peticolas <[EMAIL PROTECTED]> writes:
> Terry Boldt writes:
>
> > This may not be a big deal for the total gnucash package - but
> > using scaled integer arthimetic for the financial calculator and
> > amortization schedule computations I am finalizing and getting
> > ready to send to Dave
Bill Gribble wrote:
> Gary Bickford <[EMAIL PROTECTED]> writes:
> > At this time there's no easy way to upload the data on Linux - one
> > has to use "backup" in JPilot, for example, and then there's no tool
> > for accessing the data.
>
> Are you sure there's no export tool? I used the Newton v
Gary Bickford <[EMAIL PROTECTED]> writes:
> At this time there's no easy way to upload the data on Linux - one
> has to use "backup" in JPilot, for example, and then there's no tool
> for accessing the data.
Are you sure there's no export tool? I used the Newton version of
PocketMoney for years
Buddha Buck <[EMAIL PROTECTED]> writes:
> You are a scheme programmer, right? I maintain that IEEE floating
> point is optimised for inexact real computations. As such, it is an
> ideal represenation of Scheme inexact real classes. On the otherhand,
> I also think that accounting, by it's n
Folks,
I'm new so please excuse if I've missed something. I was reading the
thread regarding Palm support. I use a shareware Palm application
called Pocket Money from http://www.catamount.com. It is much more
capable than the Palm expense application, and the writer has published
the database f
Kevin Reid writes:
> I just tried out the Gnucash 1.3.99 developers release and I have to say
> that I was very impressed. Great job all !!
Thank you.
> However, I have come across a slight issue with regards to how Gnucash
> displays transactions for deposits and withdrawals. For example, if
Randolph Fritz <[EMAIL PROTECTED]> writes:
> Every time interest is computed.
But right now we never compute interest. You *hand enter* the value.
However, as I said before. I agree that there are going to be times
when we need to round, but that doesn't have anything to do with the
underlyin
I just tried out the Gnucash 1.3.99 developers release and I have to say
that I was very impressed. Great job all !!
However, I have come across a slight issue with regards to how Gnucash
displays transactions for deposits and withdrawals. For example, if I
make
both a deposit and a withdrawal
> When bankers first used mainframes, some slick programmers established
> "hidden accounts" which received the tinsy fractional part of the
> interest, the part lost when rounding DOWN to integer pennies ...
>
> It wasn't much, but as it happen at the end of every day, on every
> savings account
Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> But every time I make the entry, gnucash is changing the price.
Please describe how you made the entry you describe below. I'd like
to try to reproduce it myself.
> If you would
> accept the price as 3 for $2.00 and
> accept that I purchased 1
On Sat, 17 Jun 2000, Bill Gribble wrote:
> Repeating this example doesn't make it any more relevant. This is a
> straw man.
>
> Gnucash isn't responsible for computing how much the store charges
> you; you enter $2.00, or $2.01, whichever your receipt tells you.
But every time I make the entry,
Ed Porras writes:
>
> Is there a reason why credit accounts do not have some of the same
> default actions (or at least a subset) that bank accounts do? i.e:
> Credit, Online, AutoDebit..
Nope. I'll add some. Off the top of my head, it should also have:
Credit, Fee, Int (interest), Online, and
Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> Assume the case where an item is priced at 3 for $2.
> For this discussion, the price NEVER changes.
>
> Purchase one item.
> and another
> and a third
> Total cost = 3* $0.67 = $2.01
> Now purchase 3 at once. Cost = $2.00
Repeating this example
Is there a reason why credit accounts do not have some of the same
default actions (or at least a subset) that bank accounts do? i.e:
Credit, Online, AutoDebit..
-e
--
Ed Porras [EMAIL PROTECTED]
http://www.cise.ufl.edu/~ep
--
Gnucash Developer's List
To unsubscribe send empty email
On Sat, 17 Jun 2000, Shimpei Yamashita wrote:
> Well, 22 trillion Italian lire is "only" about 11 billion (US) dollars (US)
But what is the smallest amount that accountants use for commerce?
IOW, if I sell something for 1/3 million lira, exactly how many will be
posted to my banking account.
On Fri, Jun 16, 2000 at 10:56:29PM -0400, Buddha Buck wrote:
> Can someone tell me if I am missing anything here?
>
> Needs of a currency class for GnuCash:
> ==
>
> Assumption: Unless otherwise specified, all currencies are the same
> denomination (all dollars, all lir
On Sat, 17 Jun 2000, Christopher Browne wrote:
> _Can't_ we assume 64 bit integers?
No, you should assume that there is a struct definition. Period.
> I would strongly argue _against_ gmp: It means that money values are
> no longer of fixed size.
Although I strongly agree that gmp is of any re
On Fri, 16 Jun 2000 23:01:21 MST, the world broke into rejoicing as
Dave Peticolas <[EMAIL PROTECTED]> said:
> Buddha Buck writes:
> > Can someone tell me if I am missing anything here?
>
> > allow us to properly handle dollar values as large as
> > $92,233,720,368,547,758.07 without loss of pr
On Thu, Jun 15, 2000 at 07:41:29PM -0500, Richard Wackerbarth wrote:
> On Thu, 15 Jun 2000, Dave Peticolas wrote:
>
> > > Now, those .xac files - are they the previous data file, or are they
> > > written in parallel with the main file? (Or copied after the main file
> > > is written?)
> >
> > Th
Dave Peticolas writes:
> > We can't assume that every architecture will have a 64-bit integer.
> >
> > For that reason, and for the simple fact that if we are going to go to
> > the trouble of doing this, we might as well go all the way :), I think
> > we should use gmp's multiple precision
21 matches
Mail list logo
