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]
Re: Problem with gnucash 1.4.0-1 -- it wants obsolete libraries
Clark Jones writes: 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 wan (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 concep 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. You're right, we definitely need packages for more than just RedHat and Debian. Thanks for posting your fix. Hopefully we will have Mandrake packages in the future as well. thanks, dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: backup proposal
On Wed, Jun 21, 2000 at 07:18:20PM -0700, Dave Peticolas wrote:
Autosaving: every autosave_period() time units {
if (database_has_changed()) {
save_database_to_file("original name.autosave");
if (error)
report_error_to_gui();
}
}
As for explicit saves, the autosave should be done to a temporary
file, then moved to the original spot. (Or is this too nitpicky?)
Probably the temporary files should be in /tmp or /usr/tmp and contain
the process number.
--Dylan Thurston
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: backup proposal
Dylan Paul Thurston writes:
On Wed, Jun 21, 2000 at 07:18:20PM -0700, Dave Peticolas wrote:
Autosaving: every autosave_period() time units {
if (database_has_changed()) {
save_database_to_file("original name.autosave");
if (error)
report_error_to_gui();
}
}
As for explicit saves, the autosave should be done to a temporary
file, then moved to the original spot. (Or is this too nitpicky?)
Not too nitpicky at all, thanks.
Probably the temporary files should be in /tmp or /usr/tmp and contain
the process number.
If we put them in /tmp, then we really need to use something like
mkstemp(char *template) to get a unique name. But I'm not sure we
should put them there. First, if there is an error moving them, it's
easier to find them if we use the same directory (after all, they
should still have good data). Also, I was hoping to use the 'rename'
system call to make things simple (and usually atomic), but rename
doesn't work across different filesystems.
thanks,
dave
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Qif import fail on 1.4.0
Richard Wackerbarth writes: On Wed, 21 Jun 2000, Jenny Roy wrote: I am new to using gnucash; just started seriously looking at it on the 1.4.0 version of the software. I'm working at importing a moderately complicated set of QIF files from a quicken 98 version of software. /usr/share/gnucash/scm/qif-import/qif-to-gnc.scm:824:16: In procedure car in expression (car splits): Bill fixed this yesterday. (At least he fixed it for some of the cases that gave this same failure). Can you upgrade your qif-import directory and try again? Also, if you're not using CVS, 1.4.1 will be released this Sunday with the fixes. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: backup proposal
On Thu, Jun 22, 2000 at 01:40:30AM -0700, Dave Peticolas wrote: Probably the temporary files should be in /tmp or /usr/tmp and contain the process number. If we put them in /tmp, then we really need to use something like mkstemp(char *template) to get a unique name. But I'm not sure we should put them there. First, if there is an error moving them, it's easier to find them if we use the same directory (after all, they should still have good data). Also, I was hoping to use the 'rename' system call to make things simple (and usually atomic), but rename doesn't work across different filesystems. OK, good points. What happens in the case when the file is writeable but the directory is not? What if the names you want to use are already taken, and the files are not writeable? (Example case: the distribution of gnucash comes with sample files, and a user wants to be able to try gnucash on these files without copying them to another directory.) It might be good to keep files in the same directory as much as possible, picking another name if necessary. I think Emacs handles all these cases pretty well; it might be worth looking at how it does it. (But it might also be worth implementing _something_ first.) --Dylan Thurston -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: backup proposal
Dylan Paul Thurston writes: On Thu, Jun 22, 2000 at 01:40:30AM -0700, Dave Peticolas wrote: Probably the temporary files should be in /tmp or /usr/tmp and contain the process number. If we put them in /tmp, then we really need to use something like mkstemp(char *template) to get a unique name. But I'm not sure we should put them there. First, if there is an error moving them, it's easier to find them if we use the same directory (after all, they should still have good data). Also, I was hoping to use the 'rename' system call to make things simple (and usually atomic), but rename doesn't work across different filesystems. OK, good points. What happens in the case when the file is writeable but the directory is not? What if the names you want to use are already taken, and the files are not writeable? (Example case: the distribution of gnucash comes with sample files, and a user wants to be able to try gnucash on these files without copying them to another directory.) It might be good to keep files in the same directory as much as possible, picking another name if necessary. I think Emacs handles all these cases pretty well; it might be worth looking at how it does it. (But it might also be worth implementing _something_ first.) I had the same idea! (about Emacs, I mean). I'll see if I can find out. thanks, dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Wed, 21 Jun 2000, Christopher Browne wrote: Although that's only half the story; the other half is that you do have another amount that needs to be tracked, namely the cost. Right. You must track both the number of units AND their actual cost. It is pretty useless on an ongoing basis, when what you care about is what the stock is WORTH, rather than what it COST. Until it comes time to compute gain (profit) ... -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Wed, 21 Jun 2000, Christopher Browne wrote: I believe, historically at least, banks have used "mils," or $0.001. They may use finer divisions now. Currently stock exchanges use sixteenths (or is it eights?), but there is talk of going decimal. I'm quite disappointed in the thought of "heading decimal;" the fact of using 16ths is entirely compatible with the use of computers; you can do _exact_ arithmetic with that using binary arithmetic. In contrast, 0.1 must be represented as a binary continued fraction, which is _exactly_ why round-off errors occur when you try to manipulate decimal fractions . Actually, "decimal" has many advantages. The problem that you address is better handled by counting in a different set of units. If you want to count in "eights" then you should report the price as "407/8" rather than the mixed expression "50 7/8". Mixing eights and decimal doesn't really make sense. As for the "binary fractions" problem, "don't do that". Nobody requires that you count in dollars. Count in pennies. I can represent $50.88 exactly as 5088. pennies. Or get a computer that knows how to do decimal arithmetic. They used to make those, you know. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Thu, Jun 22, 2000 at 04:35:56AM -0500, Richard Wackerbarth wrote: Or get a computer that knows how to do decimal arithmetic. They used to make those, you know. IBM still makes them. I expect your phone bill is printed by one of them. :) -- Randolph Fritz Eugene, Oregon, USA -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
SaveAs label?
Sorry for the elementary remarks. I'm back to gnucash after an abortive try at it some time ago. To close the application, one must save the data, but the Save As... dialog that opens strikes me as ambivalent when it comes to the file name. Displayed is a log file with the current date. While one intuitively does not think of a "log" as a save, it almost looks like it is being suggested as the default filename. I think the user needs a little direction here. Perhaps nothing more than a label next to the filename textfield that says to create a new save-file name here. Although neither used nor needed, telling the user to use a .sav extenion to the file name might remove some ambiguity. Also, should the user incorporate the current date in the save file name, in the manner of the log file? If a subsequent Save simply replaces the old Save file, a file name incorporating the date would be inappropriate. Perhaps both points would be addressed to some extent with a label that includes a sample file name. It would also be nice to see some feedback, such as "Your data saved as ~/filename.sav". That would be comforting, because people often get to this point after a lot of work entering information, and are paranoid about loosing it. Perhaps even add to the dialog or the feeback a very simple indication of how one recovers old data should there be a disastor. That would be comforting. The dialog seems to have the room for some more labels. I think someone mentioned an auto-save feature, and that sure would be nice, too, especially if there were a disable option in a Preferences... dialog. How about a single autosave after 30 minutes of no activity in the Registry window? Sorry to belabor these points, but I'll bet many folks are as paranoid as I am about saving data and backups, and so the process of a Save should be both very explicit and very clear. Haines Brown -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Guile 1.4 Released
I'd seen the fact that Guile 1.4 existed mentioned somewhere, but it's now announced on freshmeat. Release announcement is at: http://sourceware.cygnus.com/ml/guile/2000-06/msg00198.html I suppose we should find out what breaks. . . Robert Merkel [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: 1.4.0 check printing
[EMAIL PROTECTED] writes: Do I understand correctly that check printing has been removed from 1.4.0 and will reappear in 1.5.0? The Help file gives a full set of instructions for printing checks, but Open Check Printing is not in my Transaction menu. That's right. gnome-print isn't "universally-enough" available, so we decided to pull check printing for now. You can expect the 1.5 release series to start depending on more Gnome-related stuff in very short order. In particular, gnome-print and gtkhtml are among the first. This will get us a significant amount of free printing infrastructure. Bill Gribble -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Guile 1.4 Released
On Fri, 23 Jun 2000 00:50:13 +1000, the world broke into rejoicing as Robert Graham Merkel [EMAIL PROTECTED] said: I'd seen the fact that Guile 1.4 existed mentioned somewhere, but it's now announced on freshmeat. Release announcement is at: http://sourceware.cygnus.com/ml/guile/2000-06/msg00198.html I suppose we should find out what breaks. . . I'd suggest holding off a little bit; part of the goal of the release was to allow syncing up GOOPS development with Guile, and so there is fairly likely to be another release fairly soon. The good news being that _that_ release is fairly likely to make GOOPS be a standard part of Guile, but that's another story... -- [EMAIL PROTECTED] - http://www.ntlug.org/~cbbrowne/lsf.html Rules of the Evil Overlord #49. "If I learn the whereabouts of the one artifact which can destroy me, I will not send all my troops out to seize it. Instead I will send them out to seize something else and quietly put a Want-Ad in the local paper." http://www.eviloverlord.com/ -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: backup proposal
On Wed, 21 Jun 2000, Dave Peticolas wrote: 3. The creation of a GnuCash database file that is a readable but incorrect in a non-obvious way. Such a problem may not be discovered for some time. Such a problem could be caused by a bug in GnuCash or by the user accidentally entering wrong data or performing an operation that was later determined to be undesirable (like deleting an account). For fixing user errors, keeping a bunch of save versions around and going back to find a good-enough one seems inelegant. What I'd really like is a good infinite Undo facility, like Gnu Emacs gives me. Better yet, I'd like to be able to make a mistake, close GnuCash, realize my mistake, reopen GnuCash, and undo the mistake. Could you use the log facility to provide this "eternal" undo? You wouldn't have to create a 'save history' trail: less complexity, less disk space. You could also get rid of the "Do you want to save the changes" dialog that comes up when exiting GnuCash, and just save automatically. In the rare case where I don't want to save, I'll just undo before exiting. (Since the answer to the current dialog is almost always 'yes', the dialog has pretty low efficiency.) -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: backup proposal
Glen Ditchfield writes: On Wed, 21 Jun 2000, Dave Peticolas wrote: 3. The creation of a GnuCash database file that is a readable but incorrect in a non-obvious way. Such a problem may not be discovered for some time. Such a problem could be caused by a bug in GnuCash or by the user accidentally entering wrong data or performing an operation that was later determined to be undesirable (like deleting an account). For fixing user errors, keeping a bunch of save versions around and going bac to find a good-enough one seems inelegant. What I'd really like is a good infinite Undo facility, like Gnu Emacs gives me. Better yet, I'd like to be able to make a mistake, close GnuCash, realize my mistake, reopen GnuCash, an undo the mistake. Could you use the log facility to provide this "eternal" undo? You know, we just might. The text export/import that Rob Browning is working on is also being designed for logging and automatic recovery. Infinite undo could be hard, but at least you could load the original file, and then load just part of the log file. In light of the upcoming text i/o facility, I think I will modify the backup proposal somewhat. With automatic recovery from the logs, autosaving isn't really necessary. thanks dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: SaveAs label?
Haines Brown writes: Sorry for the elementary remarks. I'm back to gnucash after an abortive try at it some time ago. All comments are welcome, thanks. To close the application, one must save the data, but the Save As... dialog that opens strikes me as ambivalent when it comes to the file name. Displayed is a log file with the current date. While one intuitively does not think of a "log" as a save, it almost looks like it is being suggested as the default filename. I think the user needs a little direction here. Perhaps nothing more than a label next to the filename textfield that says to create a new save-file name here. Although neither used nor needed, telling the user to use a .sav extenion to the file name might remove some ambiguity. Also, should the user incorporate the current date in the save file name, in the manner of the log file? If a subsequent Save simply replaces the old Save file, a file name incorporating the date would be inappropriate. Perhaps both points would be addressed to some extent with a label that includes a sample file name. It would also be nice to see some feedback, such as "Your data saved as ~/filename.sav". That would be comforting, because people often get to this point after a lot of work entering information, and are paranoid about loosing it. The development version now displays the current filename in the main window title bar. Would that be enough? Perhaps even add to the dialog or the feeback a very simple indication of how one recovers old data should there be a disastor. That would be comforting. The dialog seems to have the room for some more labels. The dialog is the standard one from gtk+, and is hard to modify. What I'd like to do is add recovery to the GUI in the main window, under the File menu. I think someone mentioned an auto-save feature, and that sure would be nice, too, especially if there were a disable option in a Preferences... dialog. How about a single autosave after 30 minutes of no activity in the Registry window? I think we're going to go with automatic recovery from logs. This is similar to autosaving, but is, essentialy, continuous autosaving without the overhead of writing the database each time. Sorry to belabor these points, but I'll bet many folks are as paranoid as I am about saving data and backups, and so the process of a Save should be both very explicit and very clear. Paranoia is good, thanks for your comments :) dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: backup proposal
Dylan Paul Thurston writes: On Thu, Jun 22, 2000 at 01:40:30AM -0700, Dave Peticolas wrote: Probably the temporary files should be in /tmp or /usr/tmp and contain the process number. If we put them in /tmp, then we really need to use something like mkstemp(char *template) to get a unique name. But I'm not sure we should put them there. First, if there is an error moving them, it's easier to find them if we use the same directory (after all, they should still have good data). Also, I was hoping to use the 'rename' system call to make things simple (and usually atomic), but rename doesn't work across different filesystems. OK, good points. What happens in the case when the file is writeable but the directory is not? What if the names you want to use are already taken, and the files are not writeable? (Example case: the distribution of gnucash comes with sample files, and a user wants to be able to try gnucash on these files without copying them to another directory.) It might be good to keep files in the same directory as much as possible, picking another name if necessary. I think Emacs handles all these cases pretty well; it might be worth looking at how it does it. (But it might also be worth implementing _something_ first.) I looked around the Emacs (rather XEmacs, but it's probably very similar) source and they save files pretty much in the same way, i.e., they save to a temporary file in the same directory, and then rename it. If they can't create a new file in the directory, and the file doesn't have a 'precious' flag set, then they just write over the existing file. I think we can assume that any GnuCash data file is 'precious', so I think we should just require the directory to be writable, rather than resort to that. dave -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
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. I've heard that there are *laws* regulating how rounding is carried out. It probably differs from jurisdiction to jurisdiction. :-( Anyone have any details? -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: SaveAs label?
I think someone mentioned an auto-save feature, and that sure would be nice, too, especially if there were a disable option in a Preferences... dialog. How about a single autosave after 30 minutes of no activity in the Registry window? We already maintain a log, which does not eat disk in huge chunks. All that is needed is to enable gnucash to read the log. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
