Re: scripting language vs. developer community size
Tyson Dowd wrote: > > On 15-Jan-2001, Dan Kegel <[EMAIL PROTECTED]> wrote: [...] > > Now I'm reading about car, cdr, caar, cddr, cadr, cdar, and the like. > > How nice that all the keywords of the language are so intuitive and high-level, > > uninfluenced by the hardware the language originally ran on. > > Hmm... C++ has a PDP-11 instruction in its *name*... ;-) Just in case anyone's not aware of it, the "CAR" and "CDR" in Lisp (I'm not familiar with Scheme) are register names for a computer designed in the late 1950's. (Please don't ask me what the acronyms stand for, or what the computer was -- I haven't dealt with that in about 15 or 20 years.) I rather suspect that "CAR" and "CDR" will still be used even when only crusty old curmudgeons like me remember what a "Pentium III" was... Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: how to create nice HTML tables in reports?
Christian Stimming wrote: [...] > Assets... > Cash... > Checking... > > I think this solution looks a bit more sound than the rather ad-hoc I like this solution, but for a reason that many "web developers" neglect. This relies on the web-browser to do the "size" calculations based on the actual font being used. This means that, as page-writer, you can request a font relative to the end-user's selection of "default" and it will come out nice. I know that one of the things that irks me is that GUI systems ass/u/me that everything should be displayed in a constant number of pixels, and oh, if I get a higher resolution monitor/video card, I _simply MUST_ want everything displayed smaller. The problem is that my vision isn't any better than it was with the previous monitor/video card (in fact, it's worse) and I would ___MUCH___ prefer to simply see more sharply-rendered characters, maybe a little _bigger_ if nothing else. If you use a font size relative to _my_ default, then suddenly _I_ have control over how it gets displayed on my screen, and I can set my browser to a large enough default so that I can read it comfortably (rather than making colorful, if unlikely, suggestions as to the ancestry of [and sexual practices thereof] of the person who wrote the code). (BTW, I'm writing this using 18 pt. default. :-) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: pre-design-doc budgeting notes [long]
Joshua Sled wrote:
>
[...]
> BudgetCategories [BCats] are the categorical entries of the budget,
> used for both income and expense. They have a name, and probably a
> description. A recurring income or expense, at least, has a frequency
> of recurrence:
>
> enum RecurrenceEnum {
> DAILY,
> WEEKLY,
> BI_WEEKLY,
> MONTHLY,
> QUARTERLY,
> YEARLY,
> };
I haven't read the whole thing, but this caught my eye. I'm wondering
if an enum might not be too restrictive here. You've already missed at
least one frequency that applies to me, to wit, SEMI_MONTHLY. My paychecks
come on the 15th and last day of the month. There are a lot of companies
in the U.S. that use this pay cycle, at least for salaried employees.
Come to think about it, I also have at least one expense that is SEMI_YEARLY:
my auto insurance (November and May on one vehicle, July and January on the
other).
Clark
--
Disclaimer: The opinions expressed herein are mine and not necessarily
those of anyone else. (As if anyone else would want them!)
Internet: [EMAIL PROTECTED] RF: KI7TU
ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: pre-design-doc budgeting notes [long]
Joshua Sled wrote: > > On Tue, Jan 23, 2001 at 08:52:28AM -0700, Clark Jones wrote: > | I haven't read the whole thing, but this caught my eye. I'm wondering > | if an enum might not be too restrictive here. You've already missed at > | least one frequency that applies to me, to wit, SEMI_MONTHLY. My paychecks > | come on the 15th and last day of the month. There are a lot of companies > | in the U.S. that use this pay cycle, at least for salaried employees. > > The "wackiest recurring expense" mail was an attempt to ensure that something > simple [like this enum] was sufficient. Actually, I was more curious about > the granularity of amount specification wrt recurrance freq [and amount-change > frequency]... I was spending far too much time not coming up with a solution > for a highly-granular approach I was thinking of. I think this will be fine > until I/someone can figure that out, sometime down the road. I didn't consider any of my periods "wacky", so I didn't respond. Mine are all pretty standard. > I should have included this in that doc, but semi-monthly == bi-weekly. > Maybe semi-monthly is the right term for it. [My paycheck is that way, as > well]. WRONG!!! They are NOT the same. Semi-monthly == 24 times per year. Bi-weekly == 26+ times per year. On Semi-monthly, you ALWAYS have _EXACTLY_ two per month. Some periods will have 16 days, some will have 15, and (typically) one per year will have either 13 or 14 days (depending on leap year). On Bi-weekly, you ALWAYS have _EXACTLY_ 14 days per period. Most months will have 2 periods, but at least two months per year will have 3 period ends. Once in a while, a year will have 27 periods end in it, meaning that there will be three months with three periods ending in them in that year. You might also want to add a "RANDOM"... my irrigation water account has to have at least enough money in it to cover the water I want -- I get water on a 13 day cycle (_that's_ bizzare), and sometimes I need $7 worth, sometimes $9, sometimes $12, and sometimes other values -- it literally depends on the weather and time of year (I haven't used any since about October). When the account gets down to about $10, I usually send the supplier a check for $50. Is it a "recurring" cost? Yes. Is it a predictable one? No, though if you looked at it over several years you might see a reasonable average value per year. Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: stock split questions
Bill Carlson wrote: > > On Tue, Jan 30, 2001 at 02:44:01AM -0800, Dave Peticolas wrote: > > > > 1. Are stock splits always reported as the ratio of two integers? > > I have never seen anything but this. It's not all that unusual for certain types of "companies" to have a "fractional split", e.g., 1.003/1, often called a "stock dividend". > > > > 2. If your stock splits in a ratio that doesn't multiply to give > > you an integral number of shares (say 3 for 2 and you have 3 shares), > > then you get some cash for the extra share right? Is there a > > name for that cash disbursement? > > I have all seen this called "cash in leiu". What it really is > (transactionally) is the sale of a small number of shares prior > to the split so that the split itself works correctly. Sometimes > it is the sale of a fractional share after the split transaction > itself, but I think the prior makes more sense. > > Another way to think of splits is as a form of "stock dividend". > What happens is the company gives you more shares (i.e., 1 share > for every two you hold in a "3 for 2 split"). Obviously in the > market place this results in the revaluation of the shares to > about 2/3 of their previous value. The reason I put it this way > is that I have long seen a split as simply a transaction in which > you purchase the new shares for zero dollars and then immediately > set the price of all the shares to the approprate (predicted) market > value. In gnucash to date, I have always done this as two transactions, > but that is not perfect because there is an instantaneous balance of > zero because of the zero cost of the shares. > > (There are actually two forms of stock dividend, one is a taxable > event and really like a dividend (as it is a transfer of company assets > to the shareholder), the other is not a taxable event and is > used for splits. The former is almost never used.) Actually, it depends more on the type of "company". Certain types of "funds" have a strong penchant for doing this -- and they also tend to keep "fractional shares" on the books. So you might, for instance, get a statement that says you currently own 314.1596 shares. > Cheers, > > Bill > > > > > thanks, > > dave Special disclaimers: I'm not a stock broker, nor an accountant, nor a lawyer, nor do I play one on TV. I'm just reporting what I've seen on statements from stock brokers. Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: stock split questions
Dave Peticolas wrote: > > Clark Jones writes: > > Bill Carlson wrote: > > > > > > On Tue, Jan 30, 2001 at 02:44:01AM -0800, Dave Peticolas wrote: > > > > > > > > 1. Are stock splits always reported as the ratio of two integers? > > > > > > I have never seen anything but this. > > > > It's not all that unusual for certain types of "companies" to have a > > "fractional split", e.g., 1.003/1, often called a "stock dividend". > > Is that actually reported as a split? In the funds I have owned, you > could elect to have your dividends used to purchase more shares, but > that wasn't a 'split'. Remember that tax laws change from time to time, and that many folks reading this aren't subject to the tender mercies of the I.R.S. :-) I think that there may have been a tax law change since the last time I saw it actually happen. I recall something about it being a fund that had a "stated value" for the shares, i.e., something like a "money market" fund. > Can mutual funds split? Why not? There are reasons for wanting to keep your share prices in a certain range -- that is one of the reasons for splits. And another thing that needs to be considered are "negative splits" -- e.g., a "two for three" or "one for two" split -- sometimes this happens when a company decides that the share price is too low. Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: scheduled transactions
Joshua Sled wrote:
[...]
> * For each element of the frequency enum, we must have some set of
> * anchors from which to compute the new date.
> *
> * daily : N/A
> * weekly : { 0==sun, .., 6==sat }
> * biweekly: start day of month
> * semi_monthly: first, second days of month
> * bi-monthly : day of month
> * monthly : day of month
> * quarterly : start month,day in year \
> * semi_yearly : first month,day in year } [watch out for leap day]
> * yearly : day of year /
> **/
I think you're getting there. However, I really think that some way should be
provided for the [ab]user to specify his/her own frequency -- one I can think
of right off hand that someone might want would be "every 90 days" -- again,
this differs from "quarterly" as it will "drift" 5 or 6 days a year, and can
even have five "event days" in one year -- the problem is that this will take
an "anchor" (day, month, year) and a period. And as I think of it, I can
easily come up with one that can only be described as a "series of one-time
events" -- they _can_ be predicted well in advance (often two or three years),
but vary slightly from year to year as to the exact "when" -- an example of
that would be "start of semester".
A point also just dawned on me: "biweekly" needs a "day, month, year" anchor
point -- if it starts on 2-Mar-2001, the next will be 16-Mar-2001, the next
will be 30-Mar-2001, the next will be 13-Apr-2001 (not 2-Apr-2001!).
I was about to say that "since we're not trying to write a calendar, I don't
think we need to deal with think we have to deal with things like 'first
Thursday in the month' or 'third Wednesday'", but now that I think of it, I
happen to have an expense that's liked to "first Thursdays" (though at the
moment it doesn't find its way into Gnucash) -- I always purchase dinner at a
certain restaurant where a meeting is held that evening. (I used to also have
one that was "Wednesday before first Thursday", which would sometimes fall on
the last day of the previous month -- but that sort of strangeness is rare
enough that I'd be willing to have to enter a series of "one-time" events.)
One bit of simplification, though: "daily", "weekly", and "biweekly" can all
just be special cases of "defined period", with a "period" of 1, 7, and 14,
respectively.
And there's one other related tidbit here: should we have an ending date?
I know, for instance, that I have one monthly bill that is due the 12th of
each month that will have its last payment in May, 2004. (An alternative
might be to have the ability to say how many times it will occur. When one
signs up for a loan, typically, there will be N payments.)
Hmmm... a "one-time" event is really a "defined period" with start-date ==
stop-date and a period of 1.
Clark
___
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Problem with gnucash 1.4.0-1 -- it wants obsolete libraries
Hi! Sorry to have to use this venue for this, but I didn't see a "report bugs" on the gnucash.org web page. First a brief word of background: I have been developing system-level software professionally for over 20 years, mostly highly specialized compilers. I've dealt with a lot of software over the years, and go back to the days when "editing" meant sitting at a card-punch (keypunch) machine. I've just tried to install gnucash 1.4.0-1 under Mandrake 7.0 from the RPM that I downloaded from the "mirror" site. Unfortunately the package is wanting libguile.so.4 and libreadline.so.3. However, the currently available RPMs for guile contain /usr/lib/libguile.so.6.0.0 with softlinks from libguile.so.1, libguile.so.5, and libguile.so.6 to it, and the currently available RPM for readline (readline-4.1) contains /usr/lib/readline.so.4.1 with a softlink from libreadline.so.4 to it. I also tried planting additional softlinks for libguile.so.4 and libreadline.so.3 in /usr/lib, but this still didn't make kpackage any happier. The point is that it seems to me (having spent 20 years trying to make _my_ customers happy) that you either need to upgrade to building with the current versions of these libraries, or alternatively make the older versions available on your download site. By the way, I've been having this problem since I first tried to install gnucash 1.3.1, right after installing Mandrake 7.0. I would really like to see GnuCash succeed. It sounds like it would be a good replacement for Quicken, at least for what I need. Quicken is the one practical application that I still regularly use Windows 98. If GnuCash lives up to its promise, I can probably blow Windows off my machines. Due to the problems I've had installing GnuCash, though, I can't just advise people to switch to Linux -- the replacement for Quicken is a critical piece of the puzzle at this point. Unfortunately, I can't justify a bunch of time trying to download sources and recompiling -- the time I've already spent trying to get GnuCash to work would have just about paid for a copy of W2K and Quicken 2000... Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Problem with gnucash 1.4.0-1 -- it wants obsolete libraries
Dave,
FWIW, the mdk object RPMs at the URL you suggested are for 686, and I've got
a "586".
Someone else (I can't find the e-mail at the moment) suggested tuning off
"dependancy checking" (the command line RPM install). I hadn't noticed that
I could "uncheck" the "check dependancy" button on kpackage, which I did, and
it installed. Once the soft-links were (re)planted for the .so's GnuCash wants
(pointing to the current versions), GnuCash at least comes up, though I don't
have time to actually try using it tonight. (All I really need out of it is
checking account tracking.)
Rod had written that the installation is much improved. Well, the RPM concept
has dramatically improved installation of _all_ packages that use it. FWIW,
I remember the days when "installing" software meant running a few boxes of
punch-cards through the card reader... or runing a waste-basket full of
punched paper tape through the reader.
I noticed someone said that GnuCash was #1 on hits... that does suggest that
"installation concerns" need to be addressed for the next release.
Clark
Dave Peticolas wrote:
>
> Clark Jones writes:
> > Hi!
> >
> > Sorry to have to use this venue for this, but I didn't see a "report bugs"
> > on the gnucash.org web page.
> >
> > First a brief word of background: I have been developing system-level
> > software professionally for over 20 years, mostly highly specialized
> > compilers. I've dealt with a lot of software over the years, and go back
> > to the days when "editing" meant sitting at a card-punch (keypunch) machine.
> >
> > I've just tried to install gnucash 1.4.0-1 under Mandrake 7.0 from the
> > RPM that I downloaded from the "mirror" site. Unfortunately the package
> > is wanting libguile.so.4 and libreadline.so.3. However, the currently
> > available RPMs for guile contain /usr/lib/libguile.so.6.0.0 with softlinks
> > from libguile.so.1, libguile.so.5, and libguile.so.6 to it, and the currently
> > available RPM for readline (readline-4.1) contains /usr/lib/readline.so.4.1
> > with a softlink from libreadline.so.4 to it.
> >
> > I also tried planting additional softlinks for libguile.so.4 and
> > libreadline.so.3 in /usr/lib, but this still didn't make kpackage any happier
>
> Sorry about the problems you've been having. The rpms on the gnucash
> website were created for RedHat 6.2, which uses guile-1.3, not guile-1.3.4.
>
> However, Scott Haug has graciously created a guile rpm for Mandrake that
> creates the needed .so links, but still uses guile-1.3.4 so you don't break
> other dependencies. It is available at:
>
> ftp://ftp.gnucash.org/pub/gnucash/redhat-6.x/upgrade/
>
> You'll want to get the guile*mdk*.rpm.
>
> thanks,
> dave
>
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: [EMAIL PROTECTED]
--
Disclaimer: The opinions expressed herein are mine and not necessarily
those of anyone else. (As if anyone else would want them!)
Internet: [EMAIL PROTECTED] RF: KI7TU
ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
Accounts/catagories, splits, and autonumbering...
First, I want to thank everyone who responded with suggestions about my problems getting GnuCash running under Mandrake 7.0 (586). Secondly, I was briefly worried about "accuracy" issues when I saw the discussion about fractional cents with respect to stock purchases, but I did manage to verify that the "checking" portion seems to be dealing correctly with cents. (I probably should read the source code on this one, though. There are some subtle mistakes that are very easily made if one is not very careful. I know from experience! :-) Moving on: I've been using Quicken for a number of years, and it is about the last "practical" thing that I regularly use Windows around for. (There are still some games, but that's a minor issue, plus a few things that I use maybe once every year or so.) I use Quicken (and want to use GnuCash) to simply keep track of my checking account. After seeing some of the other postings, I finally found that what Quciken calls "catagories", GnuCash calls accounts, which is fine -- just a different naming convention. I also (upon RFM'ing for about the third time) realised that _THAT_ is what the "transfer" column is for -- specifying where to put it. Is there a way to get GnuCash to "remind" me to select an account to transfer to? However, Quicken allows me to "split" a transaction -- for example, when I deposit my paycheck, I usually get some cash. I like to put the whole paycheck "in" under "Salary" and have an "out" of the cash-back amount, so that what goes into the "deposit" column for the transaction shows up as the "net deposit", which I can correlate to my statement at the end of the month, and still have the Salary correlate to what goes on my 1040 each year. (Yes, I realise that "manual entry" of the "double" allows me to split it as many ways as I want, but it seems like a lot of hassle -- and besides, Quicken's way allows it to immediately complains if the "splits" don't match the "net" on a single transaction, rather than waiting for a "trial balance".) A less important feature, but one who's absence is still annoying, is an "autonumber" -- in Quicken, in the "transaction number" column, I can just hit the 'n' key, and it will automatically give me the next number in the sequence. E.g., if I enter check 3456, then a deposit, then have another check, all I have to do with the cursor in the number column is hit 'n' key and Quicken will automagically enter 3457. This definitely speeds up entry, and also serves to verify that you've entered every check into the program. I realise that these features may already be in GnuCash but that I'm just not seeing them, so if they do, I'd appreciate pointers. Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: gnucash 1.4.1
Rolando, I had a very similar problem installing under Mandrake 7.0. Identical complaints, in fact. The solution that let me run was to plant soft links (ln -s) for libguile.so.4 and libreadline.so.3 in /usr/lib, and then turn off dependancy checking when installing the RPM for GnuCash. The "real" libraries I actually have on my system are libguile.so.6.0.0 and libreadline.so.4.1, respectively. So far, I haven't had any problems with GnuCash that can't be traced to "user error". :-) Mandrake allows use of the "kpackage" GUI for loading RPMs, and there's a button to disable the dependancy checking. I'm sorry, I don't know what the command line switch is, since I've never loaded an RPM from the command line. Anyway, it's worth a try -- though I'd tinker a bit trying whatever you think is important to you prior to entering a lot of data, just in case it doesn't work for you. Clark Rolando Roman wrote: > > well isin't 1.3.4 newer than 1.3 i also did it from source and > still crash > > On Mon, 26 Jun 2000, Dave Peticolas wrote: > Rolando Roman > writes: > > i just installed guile.rpm from suse and i still get this > error as > > far as i see both of those libs are in my system > > > > > > root@Ptorico:/home/landy/rpms > rpm -Uvh gnucash-1.4.1-1.i386.rpm > > > error: failed dependencies: > > > libguile.so.4 is needed by gnucash-1.4.1-1 > > > libreadline.so.3 is needed by gnucash-1.4.1-1 > > > root@Ptorico:/home/landy/rpms > > > > > The version of guile for suse is 1.3.4, the one used to build > > the rpm is 1.3. You will be better off compiling from source. > > > > dave > > > > -- > > Gnucash Developer's List > > To unsubscribe send empty email to: [EMAIL PROTECTED] > -- > Rolando Roman > icq 3783184 > > -- > Gnucash Developer's List > To unsubscribe send empty email to: [EMAIL PROTECTED] -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Some minor problems in "reconcile"
Please remember that I'm pointing out these problems so that GnuCash can be _improved_, not out of any hostility towards it! :-) I've got GnuCash 1.4.0, installed under Mandrake 7.0 from the RH 386 RPM. In doing a "reconcile" of my checking account, I noticed the following problems: - In the "date" field for the statement, the +/- shortcut keys don't work. (Actually, the calendar can sometimes be useful -- I would suggest making it available in the register date fields as well.) - When I do a reconcile in Quicken, it gives me the opportunity to enter "interest" and "fees" from the statement, rather than having to go back to the register to do so. - With Quicken, I can move around in the "outstanding transactions" fields, and hit to check something off. With GC 1.4.0, although I can move around, I still have to use the mouse to click on the item to check it off. I'll admit that I'm an OF, but I still prefer my hands on the keyboard/keypad to having to grab the mouse. :-) Suggestion: having a "reconcile" icon on the register window would be a nice addition -- especially for the "newbies". Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Some minor problems in "reconcile"
Bill Gribble wrote: > > Clark Jones <[EMAIL PROTECTED]> writes: > > - With Quicken, I can move around in the "outstanding transactions" > > fields, and hit to check something off. With GC 1.4.0, > > although I can move around, I still have to use the mouse to > > click on the item to check it off. > > You can use the space bar to check items off in the reconcile window, > and tab/shift-tab to move back and forth between the Deposits and > Withdrawals panes. > > Bill Gribble More meat for the "tip of the day" list! :-) :-) :-) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: gnucash 1.4.1
Developers: This is at least the third time (counting myself) that I've seen this. I'm running GnuCash (under Mandrake 7.0, 386) with guile 6.0 and readline 4.1. I'm not having any problems with these later libraries. (I turned off the dependancy checking and planted the appropriate softlinks.) I would suggest that whoever's the keeper of the "makefile" that's used for the RPM please consider looking to see if you can't chop off the ".4" on libguile.so and the ".3" on libreadline.so so that we can use the "generic" softlinks. If there's not a specific reason to require the earlier version, please don't. It makes it difficult for people who aren't familiar with how the .so libraries work. Even though I've dealt with this stuff on occasion for many years, it took me a while to figure out how to get around it. Clark Shawn Lee wrote: > > I hate to complain, but we've entered a nasty little vicious circle here. > > Running Mandrake 7.1. I can't compile because I've yet to get past the > first problem that I posted here: > > g-wrap --api c ... gnc.gwp > Error in execlp: No such file or directory... > > Installing from the RPM nets this problem. So now what? Can someone > familiar with the build and making the RPMs PLEASE look into Mandrake 7/7.1. > I just moved over to Linux and I'm totally unfamiliar with swig/guile/g-wrap > etc. I program for the Dreamcast so I'd have NO idea how all of this is > supposed to work together and I don't have the time to hack. > > sdl > > -Original Message- > From: Dave Peticolas [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 26, 2000 7:06 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Re: gnucash 1.4.1 > > Rolando Roman writes: > > i just installed guile.rpm from suse and i still get this error as > > far as i see both of those libs are in my system > > > > root@Ptorico:/home/landy/rpms > rpm -Uvh gnucash-1.4.1-1.i386.rpm > > error: failed dependencies: > > libguile.so.4 is needed by gnucash-1.4.1-1 > > libreadline.so.3 is needed by gnucash-1.4.1-1 > > root@Ptorico:/home/landy/rpms > > > The version of guile for suse is 1.3.4, the one used to build > the rpm is 1.3. You will be better off compiling from source. > > dave > > -- > Gnucash Developer's List > To unsubscribe send empty email to: [EMAIL PROTECTED] > > -- > Gnucash Developer's List > To unsubscribe send empty email to: [EMAIL PROTECTED] -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Some minor problems in "reconcile"
Dave Peticolas wrote: > > Clark Jones writes: [...] > > Suggestion: having a "reconcile" icon on the register window would be a > > nice addition -- especially for the "newbies". > > I agree. There's no standard icon that really applies to 'reconcile', > so we're going to need to make one. Trying to get the creative juices flowing, how about a balance with a big red checkmark in front of it? And, of course, the word "reconcile" below it. (Sorry, I'm lousy at drawing icons, so someone else will have to do the actual artwork.) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: GNUCash
Bob Stanfield wrote: [...] > First, I hope to get them to recognize that one of their wealthy > customers is not a Basidiomycetes. Congratulations, Bob! You actually made me break out the Webster's New Collegiate. For the rest of the mailing list, dropping the pronunciation and derivation stuff: "basidiomycete: any of a large class (Basidiomycetes) of higher fungi having septate hyphae, bearing spores on a basidium, and including rusts, smuts, mushrooms, and puffballs" OK, my turn: Bob, do you know what an octothorpe is? :-) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: gnucash 1.4.1
Dave Peticolas wrote: > > Clark Jones writes: > > Developers: [...] > > I would suggest that whoever's the keeper of the "makefile" that's used for > > the RPM please consider looking to see if you can't chop off the ".4" on > > libguile.so and the ".3" on libreadline.so so that we can use the "generic" > > softlinks. [...] > The problem is one we're really not supposed to work around. As I > understand it, the idea behind changing the library major version is > that it is *supposed* to break backwards compatibility, because the > library developers have decided that the api has changed enough that > backwards compatibility cannot be supported. > > In the guile case, it seems that "fooling" the system into using the > new library with a soft link will still work, but in general it's not > something we should be doing automatically. The guile package itself plants soft links for major versions 3, 5, and 6, all pointing to 6.0.0. (The GnuCash problem seems to be arising from the fact that it isn't planting one for version 4. To me, this suggests that major version 4 had some major muck-up, and shouldn't be used at all...) > The correct way to solve this problem would be to build a binary package > on a mandrake system, and have mandrake users use that instead. Ditto for > SuSE, etc. Unnecisarily linking to a specific version will still be a problem. If there is a good reason for tying to a specific version of a given library, then it seems to me that the particular version of the library in question should be copied to the application (in this case, GnuCash's) download area, to assure its continued availability. I have yet to find sources for guile 4, let alone an RPM (but since it works fine with 6, I've quit trying, and never did try too hard -- I probably could have if I'd wanted to badly enough). Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: gnucash 1.4.1
Dave Peticolas wrote: [...] > As long as we build our packages on standard distributions, then > there won't be a problem, unless a user has upgraded their libraries > to incompatible versions. But if you're doing that, then you're on > your own anyway. > > dave Dave, The whole point is that the Mandrake 7.0 distribution includes a later (incompatible) version, and I was _UNABLE_ to find the supposedly _COMPATIBLE_ version of guile. Capiche? I DID NOT HAVE A CHOICE. If you are going to lock your package into particular versions of libraries, then you should at least assure that there are copies of those libraries available. Since they are GPL'ed, you can put them onto your download site. Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Bug in transaction report?
Matthew Vanecek wrote: [...] > I went back and reviewed the accounts, searching for differences in the > ones that did and didn't work. After I set the view to the entire date > range, instead of the current year, I noticed that the Opening Balance > on the crashing accounts was dated 12/31/1969. After I changed that to > something more appropriate, things seemed to work OK. > > False alarm or Y2K bug? =P Us OFs recall that Unix (Linux) system time is kept in the number of seconds since 00:00:00 1-Jan-1970. So big surprise that there are problems with dealing with accounts dated 12/31/1969. NOT! (Try, for example, "man ctime" and read the first paragraph of text...) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Kudos, and a suggestion...
Something caught my attention that deserves praise: At least in the versions of Quicken that I've used, there's a limit to the size of catagory names, and "sub-catagories" are even more severely limited. This makes for some very awkward abbreviations. GnuCash at least has much larger fields for account names -- to the point that I haven't run into the limit yet, and haven't been abbreviating things at all! Good work, folks! :-) Now, a suggestion: It might be instructive/helpful to beginners/etc. to have a set of fairly common "accounts" as a loadable starting point for keeping track of your personal checking account. (Things that many/most people would find useful, such as "income:salary", "expenses:Mortgage payments", and "expenses:Car:Insurance".) Yes, I've seen the list in the documentation, but it would be nice to have the "package" (RPM/tarball) include the "data files" that have them pre-entered. (Or do I need to RFM again? :-) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
In the message below, Bill Gribble points out some "intrinsic" problems with how GnuCash deals with currency amounts. It has been pointed out by some others (as well as myself) that at least some "commercial" systems (notably in COBOL) use "fixed point" representations. My very limited experience with "business"-type languages is that fixed-point representations are quite common in those languages, though in my much greater experience with engineering/scientific languages "fixed-point" data types (other than "integer" and variants on it) are rare to the point of vanishing. (FWIW, I write customized "engineering" compilers for a living.) A thought has occurred to me: A possible solution would be to "migrate" to C++ (not a humongous project, since a quick look through a "tar -tvzf" of a source-tarball reveals that it's mostly in C) and then use C++'s ability to "overload" the normal operators to, in essence, construct "custom fixed-point data types". This approach has the advantage that it can probably be implemented without re-writing a lot of existing code (I'm saying this without having actually looked at the existing code, so there's a fair amount of room for "not" on that "probably"). There would be a fair amount of modification needed, but it would be mostly in terms of declaring and initializing variables. Indeed, it might be worthwhile doing some searching to see if there are existing "fixed-point" C++ packages that could be used -- and if none are turned up, put one together as a "by-product". The down-side is that the code will probably run somewhat slower than had it been implemented "directly" in C -- however, we're NOT talking about an accounting package that will will be used to, say, print the paychecks for the U.S. Post Office. :-) I suspect that a few extra milliseconds per transaction would not be noticed by most users... I'd be surprised if it slowed it down much more than a couple hundred milli- seconds per transaction. Anyway, it's a thought. :-) Clark Bill Gribble wrote: > > After discussion with some of the other developers, it is becoming > clear that most if not all of the problems people are having with > rounding and fractional cents are because, in fact, gnucash does not > know that there is a minimimum quantum of transactions for certain > types of accounts. This is an attempt to lay out the problem and a > possible solution. Please discuss. > > Bill Gribble > > == > > PROBLEM: gnucash does not take into consideration the possibility > that a financial institution may not conduct transactions in fractional > currency units. > > EXAMPLE: purchase 1 share of "foo" at 9 7/8 (9.875) from "bank". > "bank" balance is displayed as -9.88 (which is correct). purchase 1 > more share of "foo" at 9 7/8 from "bank", in another transaction. > "bank" balance is displayed as -19.75. This is incorrect, since it > implies that the intermediate balance was -9.875 rather than (as > was displayed) -9.88. > > In fact, the displayed value "-9.88" is rounded from the actual > double-precision representation of the amount, -9.875. The transfer > from the bank should have been, in each separate transaction, an > integer number of pennies (localized appropriately) meaning that the > bank balance should be -19.76. > > This demonstrates the way in which gnucash currently represents all > quantities as double-precision floats and rounds these as appropriate > *for display only*. > > PROPOSED SOLUTION: there must be account-type-specific (localized for > currency) rules describing the minimum unit of transaction for a > particular type of account and what to do with fractionally-unbalanced > amounts. For example, it should be possible to restrict bank-account > transfers to integer pennies but allow for fractional-cent balances in > brokerage accounts if the brokerage handles the accounting in this > way. QUESTION: what types of accounts have what types of > transaction-quanta in the real world? > > SIDE EFFECTS: In the case described in the EXAMPLE, 9.88 should be > transferred from the bank to purchase 1 share at 9.875. The remaining > 1/2 cent must be accounted for. > > Accounting for the fractional amount: > > Alternative 1 is to add a split to the transaction which transfers the > remaining fractional amount into an account designated for such > things. For security accounts, this could be a "commissions" account, > since the 1/2 cent is effectively a tiny commission on the > transaction. This has the drawback of being confusing to naive users. > > Alternative 2 is to fractionally adjust the price per share to reflect > the "true cost" of the shares purchased. In the EXAMPLE, > price-per-share would be adjusted to 9.88, since the purchaser did > have to transfer 9.88 to purchase each share, though the market price > was 9.875. This has the drawback of having possibly surprising > effects on the tota
Re: Money transfer between accounts
Herbert Thoma wrote: [...] > > A simplfied way of dealing with one-shot currency exchanges needs to be > > implemented, essentially just a simple calculator popup. > > I volunteer here (soon now, really) I'm not at all familiar with the internals of GnuCash, but it would seem to me that if someone is going to go to the trouble of implementing a calculator popup, they might as well make it available whenever you're entering data into a "currency" field (e.g., a "credit" or a "debit"). Also, the currently displayed "value" in the "calculator" should transfer from/to the field in question "automagically", at least when the popup is first brought up and every time the "=" key is hit. Quicken has something like this, and although it's useful, frankly, for my purposes it's pretty far down on my personal "wish list", but here we have a saying that "a job worth doing is worth doing right". Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
Bill Gribble wrote: [...] > Please be careful about use of the term "fixpoint". It implies that > the smallest-countable-unit is related to the unity-unit by a > power-of-ten relationship. That's true for US Dollars, but it's not > something we can assume for other currencies or for other numeric > values that we will want to represent in this format. Even if we > *can* find a fixed-point library out there, it's not what we need, > IMO. Well, floating point is definitely NOT the proper solution for US dollars (or any other currency of which I am aware -- anybody know a currency still in use that isn't decimal? The UK abandoned the "shillings & pence" in the '60's). One could use multiprecision integer and represent US dollars in "cents", but that becomes a real pain in the tush, and so is not a proper solution, either, IMHO. The one place I can think of where you still see fractions commonly is in stockmarket quotations, e.g., nonsense like "73 213/256". However, the SEC has told the U.S. stock markets "thou shalt decimalize", and though I don't recall off hand exactly when the deadline is, it's within the next few months. Also, I think if you dig into it, you'd find a rule that the smallest fraction they're allowed to use (at least for things over $1) is 1/256. Although the SEC doesn't have any direct control over non-US stock markets, "international market forces" (i.e., brokerage firms moaning and groaning about having to maintain two different systems) tend to keep them all doing pretty much the same things. Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
Richard Wackerbarth wrote: > > On Fri, 30 Jun 2000, Clark Jones wrote: > > > Well, floating point is definitely NOT the proper solution for US dollars > On this, I think we finally agree. :-) > > One could use multiprecision integer and represent > > US dollars in "cents", but that becomes a real pain in the tush, and so > > is not a proper solution, either, IMHO. > > But that is exactly the common implementation of "fixed point", namely > "scaled integers". This may have changed in the 20 years or so since I was actually dealing with them, but the "business oriented" languages usually do it with "binary coded decimal", rather than scaled integers. Since few processors support BCD in their instruction sets (the exception that comes to mind off hand is the Z-80) this is one of the reasons that the code they produce is so _OOOWWW_. > > nonsense like "73 213/256". However, > > the SEC has told the U.S. stock markets "thou shalt decimalize", and though > > I don't recall off hand exactly when the deadline is, it's within the next > > few months. > > Except that all of the historical data will still be in the old system for > some time. A thought that has occurred to me is that the examples that people are coming up with are all "binary fractions" of either dollars or cents. This may be a useful observation... > In addition, we still have to handle "$1.99 per dozen" I think that no matter how we slice it, "7 at $1.99 per dozen" is always going to involve some roundoff error, especially if "dozen" is a "baker's dozen"! Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
Randolph Fritz wrote: > > On Fri, Jul 07, 2000 at 01:11:20AM -0500, Richard Wackerbarth wrote: > > > > Commodities are counted. That, by definition, means that they are represented > > by an integer. If you must use a rational, the denominator is always unity. > > > > Unless they're sold by the foot--like lumber, fabric and wire, the > pound--like nails, iron, and sugar, or the gallon--like milk and gasoline. Stocks can also be in fractional shares, thanks to things like stock splits and "share-dividends". Also, there can be need to deal with things like "4 pounds, 3 and a half ounces"... now, are these avoirdupois pounds (U.S. "standard" for most things, 16 ounces to the pound) or troy pounds (used for precious metals, 12 ounces to the pound)? Hmmm... I don't recall anybody mentioning "time" as the unit of measure... convert to seconds? minutes? hours? days? weeks? months? years? I often deal with measurements in nanoseconds... many things get charged for by unit time... e.g., phone calls, wages, room rents, ... Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: what do we want to graph?
Robert Graham Merkel wrote: > > Bob Stanfield writes: [...] > > There are two standards the 50 and 200 day moving average. Is there a reason > > why we couldn't make that a user option? > > > None at all. To be "user friendly", IMHO, the software should have "reasonable defaults" but allow the [ab]user to select whatever value [s]he really desires. I can see where "15 day" or "90 day" moving averages might be interesting in some situations... having the choices be "50", "200", and "User specified" on a menu would be reasonable. I hope that this is what you had in mind. [...] > > Again I use line graphs. When comparing a stock(s) and an index > > I normalize by the initial prices. This is useful to see how a General > > Motors follows swings in the price of crude oil, for example! There are > > few of us old dinosaurs who like information. If I want art, I'll go to a > > museum. > > Believe me, I want our graphs to be informative. If "pretty" and > "informative" clash, I'd go for "informative" every time. Where > practical, we should provide choice. And most of the time, there is > no reason for there to be a clash between attractive and functional. Unfortunately, I've had occasions in the past to [attempt to] work with "suits" for whom "pretty" was more important than "informative". Although I generally agree that if there is a clash, "informative" is usually the way to go, I would hope that the [ab]user can be the final "arbiter" on this one. (Just my 3/150 of a U.S. dollar's worth, to abuse another recent thread. :-) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: GNUCash
Hendrik Boom wrote: > > [EMAIL PROTECTED] write: > > > > OK, my turn: Bob, do you know what an octothorpe is? :-) > > > > Clark > > > > Isn't it the thing everyone calls the number sign or the hash mark on the > 12-key touch-tone telephone keybiard? > > > > -- hendrik Correct. The character that most computer keyboards these days have as "shift 3", sometimes referred to as "pound sign" in the U.S. I've also seen it called "dies" in French documentation. My preference, though, is "octothorpe". (It's also sometimes spelled "octothorp".) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Ordering and grouping: how do I do it, or suggestion for enhancement
Hi folks! I'm using gnucash 1.4.0 (after the hassles getting _that_ installed, I'm waiting awhile on trying to upgrade :-). I have spotted a couple of things that I'd like to do with it, and after having RFM'ed and not found the answer (maybe it's there and I missed it), I thought I'd ask ... and if these are not things that can currently be done, I'd like to put them forward on the "wish list": - In the "Register" window, is it possible (without modifying and recompiling the source code) to change the order in which the columns appear? For instance, in my "dead tree" register, the check number is on the left, followed by the date. Also, the "withdrawal" is to the left of the "deposit". It would be less confusing if the two could be made to match, and it would seem that if there were a "display order" menu item somewhere it would be easier to do than trying to edit the "dead tree" register. - I've got some accounts set up, for instance auto:insurance:pickup auto:insurance:rv auto:maintenance:pickup auto:maintenance:rv auto:registration:pickup auto:registration:rv It would be very nice to be able to get something like a transaction report that lists all of the items for the pickup together, and all of the items for the rv together so that I can get a "cost of ownership" number. However, I can't just re-do the accounts, as some things (like registration) need to be grouped together for other purposes -- i.e., taxes. As I said, if gnucash can already do these things, I'd appreciate pointers on getting them done, and if not, please add them to the "wish list". Clark P.S. I've noticed that there's an "address harvester" that's subscribed to this list -- fortunately I've only gotten two or three pieces of junk e-mail, but I'm reasonably sure they came because of my postings here. -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Proposal for modifying gnucash to use exact quantities
Bill Gribble wrote: > > Clark Jones <[EMAIL PROTECTED]> writes: > > I hate to quibble with Gribble :-), but in actuallity the bill establishing > > the Dollar as the U.S. currency (written by Thomas Jefferson) defines the > > "mill" -- which is 1/1000 of a U.S. Dollar -- though the only places where > > you're likely to run into it is at the gas pump and calculating real estate > > taxes. > > I'm a little confused about this. Where is a "mill" actually a valid > amount for a financial transaction? You certainly can't take one out > of a bank account. > > Is this just an anachronism? Are there *any* places where correct > record keeping requires one to keep track of dollar values down to the > 1/1000 of a dollar? > > b.g. Gee, Bill, I was afraid I might offend you with the "play on words" on your name. :-) The mill is _legal_ to use anywhere in the United States, though, if I recall correctly, the U.S. government has never issued a coin or currency denominated in mills. (The U.S. laws do allow for issuing by other "authorities" under certain circumstances -- and it's been too many decades since I've studied numismatics [coin collecting] to recall exactly what others have done.) Many jurisdictions that tax real estate calculate it based on mills, and as I pointed out earlier, virtually all retail gasoline vendors in the U.S. price their product in mills. I, personally, have never encountered a situation, though, where actual transactions weren't rounded/truncated to the cent. (Have to be careful here, as technically the U.S. doesn't have "pennys" -- we have "cents" and "dimes".) So, in reality, it's just "quibling" -- I didn't recall anyone else having mentioned mills, so I thought I should. Someone recently sent me something saying, in effect, "know the rules, so that you can break them correctly", attributed to the Dalhi Lama. So we now know the rules, so we can break them intelligently. :-) Clark P.S. It sounds to me like we should try to dig up a CPA to "consult" on the whole problem, since it does sound to me like something the accounting community has probably already addressed. -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Proposal for modifying gnucash to use exact quantities
Bill Gribble wrote: [...] > 1. gnc_commodity knows about the smallest possible transactional > unit for trading the commodity (for example, 1/100 of a US Dollar > or 1/1000 of a mutual fund share). I hate to quibble with Gribble :-), but in actuallity the bill establishing the Dollar as the U.S. currency (written by Thomas Jefferson) defines the "mill" -- which is 1/1000 of a U.S. Dollar -- though the only places where you're likely to run into it is at the gas pump and calculating real estate taxes. (The same act established a number of other interesting things, too, though they're not relevant to the current discussion.) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Integration with other applications?
Robert Graham Merkel wrote: > > John Strange writes: > > Hi, > > > Just my two cents, what is everyone else's thoughts on integration between > > applications? [...] > However, the idea of more integration with other applications is a > good idea - the rudiments of Gnumeric-format export are > sitting around in the CVS archive, but nobody has been sufficiently > enthused to do any more work. I know that most may think me a heretic for this, but personally I prefer a group of programs that each do their work very well to a single, sorta-does-all, all-sorta-dancing program. All singing, all dancing programs tend to be vastly larger, far slower to load, have more bugs, and present more security "holes" than the smaller ones. As long as I can "cut and paste" between applications, that's generally sufficient for most purposes. Flames for my being a heretic should be addressed to /dev/null :-) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: default directories
Robert Graham Merkel wrote: > > Clark Jones writes: > > Dave Peticolas wrote: > > > > > > Someone recently posted a request for having a user-configurable > > > default directory which the file opener would show by default. > > > > > > I've been thinking about this and it seems to me that it might be > > > better and more convenient just to have GnuCash use the directory > > > of the last opened file. Thus, the user would not need to explicitly > > > set a default directory. > > > > > > Any preferences there? > > > > > > dave > > > > How about having an environment variable to define it? That way if > > someone has to "look" in other directories from time to time, but has > > correctly set the environment variable in their .login or .cshrc or > > whatever, they'll still be popped back to their "base" directory. > > > > Although nothing like gnucash, the stuff that I work on in my "day" > > job makes heavy use of environment variables to set various things and > > allow the [ab]user to set them as [s]he sees fit -- although it takes > > a bit of "explaining" to the new user, we get lots of kudos from folks > > who've used it a while. (The one downside for this is that it won't > > work under M$ software that masquerades as operating systems, as far > > as I know.) > > We've largely gone down the route of making things configurable from > the GUI. The items that aren't configurable from the UI are mostly > things that only GnuCash would use. > > While I know that many of us would prefer to have things configurable > from the command line or from config files, we've gone down the > GUI-configurable route for the benefit of our less computer-savvy > users and there's no reason not to be consistent, IMHO. > > So, if you do decide to make it configurable, make it configurable > from the GUI. > > My 4 Pacific Pesetas worth :) I agree that there's good reason to be consistant, however, this is one of those rare cases in which you could "have your cake and eat it too": The configuration that the user has selected via the GUI has to be stored somewhere, somehow on disk, so that it is "persistant" across sessions. It seems to me that making said storage be "human readable/modifiable" would then allow the "more advanced user" to alter it at will. I could say something about following the M$ lead, but you might take it as a flame. :-) That's my 20 mills worth! :-) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Dimensions?
Robert Graham Merkel wrote: > > Christopher Browne writes: > > On Wed, 27 Sep 2000 10:46:27 +1000, the world broke into rejoicing as [...] > > ... And in perhaps-overly-brief response to the multiply-expressed > > question, > > "What if it's not a tree?" [...] > As for the user interface question, ideas are rolling around in the > back of the head, but you're right, it is *nasty*. Well, I have a thought on this, but first let me explain, briefly, my situation: I have two vehicles, a pickup and an RV, and so have things like auto:pickup:insurance auto:pickup:repairs auto:pickup:taxes auto:RV:insurance auto:RV:repairs auto:RV:taxes and I have home:insurance home:maintenance home:taxes:irrigation_district home:taxes:realestate and so on. One of the reports that I'd like to see would group together all of the related stuff across the vehicles (and ignore anything related to home), while another report would say, in essence, here's what I've spent on insurance this year, and here's what I've spent on taxes, and so on. Anyway, as for the [ab]user interface, I've seen several instances around of two windows where "here's what's currently selected for inclusion" and "these items are not currently included" -- you click on one to highlight it, and then click on the arrow that's between the two columns to move it. What I would envision is that when you're setting up/modifying a report, you would create new "catagory" (or some appropriate word) (or possibly select an existing one if modifying an existing report) and then you would get the "two column" included/not included display described in the previous paragraph. (We might want to include a "check box" that the user could check to only allow a given account to only appear on one catagory, and possibly also a choice between "ignore unselected accounts"/"report unselected accounts as an error"/"put unselected accounts into a default 'misc.' catagory".) I think that such a user interface could be made both sufficiently general as to satisfy the vast majority of people's needs, and is also relatively intuitive if the GUI is set up correctly. There are, of course, many "implementation details", such as the need to allow the user to have multiple reports set up, an easy/intuitive way of selecting things like "date ranges" (including an "all before"!), what to do about new accounts that have been created since the last time the report was run, just how we represent the report on disk, and so on. Also, when selecting accounts, we'd want to (eventually) be able to select multiple accounts (with shift lmb and control lmb), and maybe even a way to "select accounts based on a regular expression" (after all, this _IS_ a "Unix-like" OS :-). Remember, a conclusion is where you got tired of thinking -- this is my conclusion. :-) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Dimensions?
Robert Graham Merkel wrote: > > Clark Jones writes: > > Robert Graham Merkel wrote: > > > > > > Christopher Browne writes: > > > > On Wed, 27 Sep 2000 10:46:27 +1000, the world broke into rejoicing as > > [...] > > > > ... And in perhaps-overly-brief response to the multiply-expressed > > > > question, > > > > "What if it's not a tree?" > > [...] > > > As for the user interface question, ideas are rolling around in the > > > back of the head, but you're right, it is *nasty*. > > > > Well, I have a thought on this, but first let me explain, briefly, my > > situation: I have two vehicles, a pickup and an RV, and so have things > > like > > > > auto:pickup:insurance > > auto:pickup:repairs > > auto:pickup:taxes > > auto:RV:insurance > > auto:RV:repairs > > auto:RV:taxes > > > > and I have > > > > home:insurance > > home:maintenance > > home:taxes:irrigation_district > > home:taxes:realestate > > > > and so on. > > > > One of the reports that I'd like to see would group together all of the > > related stuff across the vehicles (and ignore anything related to home), > > while another report would say, in essence, here's what I've spent on > > insurance this year, and here's what I've spent on taxes, and so on. > > > > Anyway, as for the [ab]user interface, I've seen several instances around > > of two windows where "here's what's currently selected for inclusion" and > > "these items are not currently included" -- you click on one to highlight > > it, and then click on the arrow that's between the two columns to move it. > > > A two-column type setup is the sort of thing I had in mind. However, > what you need to be able to do is build a *tree* for a report to > summarise things into. I see no reason why the "report catagories" can't be a heirarchy just like the way gnucash deals with accounts and sub-accounts. The GUI selecting the "report catagory" to create/modify(/delete?) could look something like the existing one to select an account in gnucash to give the user "warm fuzzies" that [s]he's familiar with it. A couple of further thoughts: In the two-column thing, there needs to be a way to say "move all the sub-accounts too" vs "just move the selected account and leave sub-accounts where they are". Also, a way to create a new report with a catagory/sub-catagory for each existing account/sub-account would be a good starting point for developing several "interesting" reports, as well as being a useful report in its own right. [...] > > Remember, a conclusion is where you got tired of thinking -- this is my > > conclusion. :-) > > Yep. My thoughts are along similar lines. This should probably be > firmed up into a proposal, somwhere in the not too distant future. > ATM I'm trying to make guppi graphs display from GnuCash. > I should have a simple demo ready soon :) Hmmm... graphs from the reports would be nice, too. One that comes to mind off hand would be a "pie-chart" of how my "auto" money went, with regards to x% for insurace, y% for repairs, and z% for taxes, across both "autos". This also gets me to thinking that it would be nice to be able to get charts showing different time periods -- say total cost for each auto, comparing years 2000, 2001, 2002, and so on. That's going to require some more thinking -- and it's time for a conclusion! :-) (Especially as something in X locked up and I had to type most of this twice. :-( Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: default directories
Dave Peticolas wrote: > > Someone recently posted a request for having a user-configurable > default directory which the file opener would show by default. > > I've been thinking about this and it seems to me that it might be > better and more convenient just to have GnuCash use the directory > of the last opened file. Thus, the user would not need to explicitly > set a default directory. > > Any preferences there? > > dave How about having an environment variable to define it? That way if someone has to "look" in other directories from time to time, but has correctly set the environment variable in their .login or .cshrc or whatever, they'll still be popped back to their "base" directory. Although nothing like gnucash, the stuff that I work on in my "day" job makes heavy use of environment variables to set various things and allow the [ab]user to set them as [s]he sees fit -- although it takes a bit of "explaining" to the new user, we get lots of kudos from folks who've used it a while. (The one downside for this is that it won't work under M$ software that masquerades as operating systems, as far as I know.) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Revisiting the database
Gary Bickford wrote: [...] > The following may seem cranky, but it isn't. :O) OK, so I trust you won't mind me going into "psuedo-curmudgeon" mode! :-) [...] > So please take this as an attempt to be > constructive :O) Likewise, I'm sure! :-) > To my > knowledge, _all_ enterprise level accounting systems built on database > management systems. If you'll ammend that statement to read "all commercially available enterprise level accounting systems", I might be willing to let you get away with it. However, I very strongly suspect that there are a lot of "legacy" systems in large (older) enterprises that are _NOT_ built on a DBMS (though you might make an argument that they are de-facto DBMS's themselves, but as a compiler guy, I've made the argument that most [all?] editors are actually "de-facto real-time interpreters"...) [...] > As for performance, nowadays a majority of users are running 400 MHz or > better machines. AHEM (clearing the throat loudly)... I beg to differ. This is coming to you through the auspices of a 233 MHz MMX, which was only upgraded from 200 MHz due to an incorrectly suspected CPU problem. (Turned out to be a bad SIMM.) One of the big "claims to fame" of Linux is that it WILL run on hardware that M$ victims consider to be "obsolete". (I love to point out that W98 won't let you upgrade to FAT-32 on less than a 90MHz Pentium, but Linux is happy to do it on a 386 -- suggesting that Linux can deal with W98's "native" disk structure than W98 can! :-) I'll admit that at this point we probably don't need to put a _LOT_ of worry into support for 386, but we still need to give consideration to slow Pentiums... (Although this is off the topic of gnucash, I will mention that when I get around to it I have a 486 machine that I intend to use as a "firewall" and run Linux on it.) I should also point out that there are a lot of users outside the U.S. (and other "industrialized" countries) where a lot of older computers are still in use. Linux is nice for these folks because they can at least upgrade the software, even if they have hardware that in Japan would be relegated to either the museum or the trash can. Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Proposal for modifying gnucash to use exact quantities
Rob Walker wrote: > > >>>>> On Mon, 24 Jul 2000 22:18:28 -0700, Clark Jones > >>>>> <[EMAIL PROTECTED]> said: > > Clark> Bill Gribble wrote: [...] > > >> 1. gnc_commodity knows about the smallest possible transactional > >> unit for trading the commodity (for example, 1/100 of a US Dollar > >> or 1/1000 of a mutual fund share). > > Clark> I hate to quibble with Gribble :-), but in actuallity the bill > Clark> establishing the Dollar as the U.S. currency (written by Thomas > Clark> Jefferson) defines the "mill" -- which is 1/1000 of a > Clark> U.S. Dollar -- though the only places where you're likely to > Clark> run into it is at the gas pump and calculating real estate > Clark> taxes. (The same act established a number of other interesting > Clark> things, too, though they're not relevant to the current > Clark> discussion.) > > got an URL to that interesting stuff? > > rob Unfortunately I don't have it handy. I'm not sure I actually saw it on the net, but I'll try to see tomorrow if I have a bookmark at the office. If so, I'll post it here. Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Get PostgreSQL installed as part of the distros
Christopher Browne wrote: [...] > The options that leap to mind are: > a) Berkeley Sleepycat DB. This tends to be _included_ with GNU-related >systems, and provides, in its latest versions, transaction logging, >locking, and all that sort of thing. There has been some discussion >of replacing PostgreSQL's data store with this. I'm not at all familiar with the package. My only concern, off hand, would be to assure that the "locking" is such that the recovery from a "left-around lock" isn't much more difficult than removing a single file... The electric outlet isn't very reliable in some areas, and here it's been down just a little bit longer than the UPS can hold the system twice within the past couple of months. (Yes, I know I should have a way for the UPS to tell the machine to "shut down -- I'm not going to last much longer", there are a lot of higher priority items on my to-do list.) Besides, there are other things that make you have to "ungracefully kill" all the proceses on the machine, though thankfully this is much rarer on Linux than on M$. Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: Implementing proper cost basis tracking for shares
Rob Browning wrote: > > Robert Graham Merkel <[EMAIL PROTECTED]> writes: > > > > I don't really know how much flexibility we'd want to allow initially, > > > but changing the internals at some point might make accomodating > > > various different schemes easier. > > > > > I dunno if you saw the discussion I was having on the list a while ago > > about being able to do this, but only for reports. If we generalised that to > > *everything*, it would be an interesting possibility :) > > If we did this, I'd probably want to make the flat account list a > GList or a GArray, and make the "views" into it, a GList (or GSList) > of GLists (or GSLists) which "bottoms out" in Account*'s. I'm sorry, I'm not familiar with GLists or GSLists, but the comment about "'bottoms out' in Account*'s" makes me a bit nervous that it would only allow entries into the "leaf" accounts. There are times when it is convenient to put some entries into a given "level", and others into a "sublevel", e.g., I might have "autos->pickup->maintenance" that catches most of the costs, but if I wanted to keep track of, say, tires, these might go into "autos->pickup->maintenance->tires". > Seem's pretty straightforward, though I believe the point we stalled > at last time was, given this setup, what do account names mean? Right > now, the full-name is an implicit part of the Group path used to reach > it, but in this "new" approach, an account might appear in a variety > of arrangements. I think the right answer is that the Account name > would need to be more descriptive, and probably enforced unique, > something like "MegaBank Savings" rather than just "Savings". I hope that you're just using the space delimiter in "MegaBank Savings" as an arbitrary name. One of the nifty things about gnucash as opposed to Quicken is that I don't have to replace spaces in the account names with underscores... (and I also don't have to stop at some tiny number [16?] of characters!) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Bug in register display
A few days ago, I upgraded my box to Mandrake 7.2, and found that included as part of that distribution is GnuCash 1.4.7 (I'd been using 1.4.0, and hadn't bothered to upgrade since the older one had fulfilled my immediate needs). When I was entering data into the register (two-line mode), I noticed that when it got to the "Transfer" column the "Account browser"'s scroll bar was hiding behind the register scroll bar, so was essentially useless. (Just enough of it was peeking out to be able to tell it was there, but not enough to easily get onto with the mouse.) I also couldn't find anything to "grab onto" to "slide" the "browser" over, and widening the register window didn't help either. FWIW, this was using the KDE window manager that is the Mandrake "default". (I vaguely recall having seen this in 1.4.0, but at the moment it doesn't seem worth the effort to find out for sure.) Clark -- Disclaimer: The opinions expressed herein are mine and not necessarily those of anyone else. (As if anyone else would want them!) Internet: [EMAIL PROTECTED] RF: KI7TU ICBM: 33 22' 01" N 111 43' 52" WHome Page: www.inficad.com/~jones ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
