Re: [GNC-dev] Normalizing live data
On Sat, Feb 02, 2019 at 04:30:30PM +0100, Geert Janssens wrote: > Op zaterdag 2 februari 2019 14:31:43 CET schreef Hendrik Boom: > > > On 2/1/19 5:36 AM, Wm via gnucash-devel wrote: > > > > [2] as long as the transaction stream balances the actual numbers > > > > don't matter (their will be occasions where the numbers are important > > > > but these tend to be number extremes related to commodities rather > > > > than anyone using gnc to do a Mr Putin vs Mr Trump sports bet).? In > > > > most cases multiplying any matching numbers by the same semi-random > > > > should produce a good file for examination so long as it is done > > > > consistently [4] > > > > If the numbers in the file are integers times some account or > > currency-dependent unit, then just clculationg the greatest common > > divisor of all the obfuscated numbers will give a good guess as to the > > semirandom multiplier. > > Do you think that still is possible if a different random number was used for > each transaction ? (That's how I understood Wm's suggestion) > > Each transaction will have it's own random number. So for transaction A all > splits may have been multiplied with 450, for Transaction B all numbers may > have been multiplied by 500. That might work. That way eash transaction balances, but the account balances will be nonsense. Still, by finding the gcd you can still produce a lower bound on the transaction values. And if you, say, split off sales tax into a separate split your lower bound will oftern be the actual value. And it's likely that one could also identify income and expense accounts as such by the pattern of debits vs credits. -- hendrik > > Regards, > > Geert > > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] Normalizing live data
> On 2/1/19 5:36 AM, Wm via gnucash-devel wrote: > > > > [2] as long as the transaction stream balances the actual numbers > > don't matter (their will be occasions where the numbers are important > > but these tend to be number extremes related to commodities rather > > than anyone using gnc to do a Mr Putin vs Mr Trump sports bet).? In > > most cases multiplying any matching numbers by the same semi-random > > should produce a good file for examination so long as it is done > > consistently [4] If the numbers in the file are integers times some account or currency-dependent unit, then just clculationg the greatest common divisor of all the obfuscated numbers will give a good guess as to the semirandom multiplier. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash-devel Digest, Vol 142, Issue 14
On Tue, Jan 27, 2015 at 12:00:01PM -0500, John Ralls jra...@ceridwen.us wrote: ... That sounds great, with one question: Are you able to write proper DocBook patches? That was the big blocker to getting documentation contributions the last time it came up here, and it's still unresolved except for those who are willing to dive in with a plain XML editor or to work with the foibles of the one extant free (unfortunately only as in beer) DocBook editor. Not much good for patches to an existing document, but Asciidoc was designed for writing books (unlike Markdown), and will produce Docbook. Indeed I think that may have been its original purpose. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Recommend IDE for coding in C -- some historical context
On Wed, 20 Mar 2013 13:13:00 -0400, Buddha Buck wrote: Paul, As should be clear from the other responses, there's no clear if you work in C/C++, then this is the IDE you should use. Both languages have been around for a very long time (C since the early 1970's, C++ since the mid 1980's), and have been used across a large number of different environments, there's no category-killer. Both C and C++ are old enough languages that they have a certain amount of cruft in their design with makes it hard for IDEs to get their hooks into them to provide advanced services. The macro preprocessor for C/C++ really gets in the way of an external program making sense of the code. ... ... It should be noted that in Linux/Unix, all the development tools are command-line based, and so any IDE is going to call make, gcc, git, gdb, javac, etc behind the scenes anyway to do the actual work. And C was originally invented jointly with a command-line Unix system. So using it this way fits with tradition. So which you choose is more a matter of taste than functionality. Everyone is going to prefer the one they are most familiar with. That said, here are the choices I can speak to: Emacs -- This is an old extensible text editor, nearly as old as C. Since it is older than most windowing interfaces, it is very much geared towards usage on a terminal -- keyboard based commands, fixed window size, monospace type, etc. It has, in the past decade or so, added some ability to be used with a mouse, but the keyboard is really the way to use it. Since it is designed to be extensible (it uses elisp, a language similar to the Guile language GnuCash uses), it has a lot of features available (in the 1980's it's desktop icon was a kitchen sink). As far as an IDE goes, it provides all the basic hooks so you don't have to leave the program in order to develop, and it has support to handle a large number of languages. Emacs has a reputation for being heavyweight and larded with features, but I've found that compared to modern editors with a fraction of the capabilities, it's rather lightweight and spry. The old joke that the name means Eight Megabytes And Constantly Swapping is meaningless when your browser can take a gig of memory. What emacs accomplished in those early days was to be a UI for text terminals. You had multiple 'buffers', which could be put in differennt places on the screen, or placed in the background to be recalled later. Some buffers would contain files t edit, others aould act as command- language terminals, and so forth. Emacs i those days was as much of a way of life as desktop GUIs are now. That's why it was big. But compared to today's memory hogs, it's tiny. Vi -- This is almost as old as Emacs, but wasn't originally written to be quite as extensible. Like Emacs, it's text-and-keyboard oriented. It provides syntax highlighting, but I'm not sure about hooks to other tools. I don't use it for development myself, that much. It has always been considered lightweight compared to Emacs. The first time I saw vi, it was already on a system that had mouse-and- windows. Whether vi or X windows was first, I suspect that functionality that might have drifted into vi got placed in the window system instead. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Recommend IDE for coding in C -- some historical context
On Thu, Mar 21, 2013 at 02:56:04PM -0400, Buddha Buck wrote: On Thu, Mar 21, 2013 at 2:31 PM, Hendrik Boom hend...@topoi.pooq.comwrote: On Wed, 20 Mar 2013 13:13:00 -0400, Buddha Buck wrote: Paul, It should be noted that in Linux/Unix, all the development tools are command-line based, and so any IDE is going to call make, gcc, git, gdb, javac, etc behind the scenes anyway to do the actual work. And C was originally invented jointly with a command-line Unix system. So using it this way fits with tradition. Yup. Worse, from an editing/developing standpoint, the standard terminal was a teletype terminal, a combination printer and keyboard that usually printed at the rate of about 4 characters/second (45 Baud). The slowest I ever encountreed in the 60's was 110 boud, about 10 characters per second. But for typing, the old KSR teletypes required so much force that it may well have taken superhuman finger strength to enter more than about 4 characters per second, whatever the baud rate. This virtually demanded a terse command line syntax and the bare minimum of excess output. And it's why the common Unix commands are so cryptically short. What emacs accomplished in those early days was to be a UI for text terminals. You had multiple 'buffers', which could be put in differennt places on the screen, or placed in the background to be recalled later. Some buffers would contain files t edit, others aould act as command- language terminals, and so forth. It still does those things, which is still very, very useful. Yes. X was started as a project in 1984 at MIT. Both Emacs (from MIT) and vi (from Berkeley) were first written in 1976 or so. Both Emacs and vi came out of a desire to make line or tape oriented editors easier to use on the new-fangled CRT displays. Emacs was originally a set of macros for the TECO (Tape Editor and COrrector) editor, Yes.. But it's not the one we have now. Richard Stallman had a copyright dispute with MIT, which resulted in MIT taking his emacs proprietary. He has an early free-software licence in the emacs manual, declaring emacs to be free, and MIT decided that it was work-for-hire and took it over. THis was one of the events on the way to his GNU public license ans the dree software foundation. As I understand it, one of the first pieces of GNU software was a new emacs, this time based on a Lisp dialect. The result was the emacs we have today. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: GnuCash for Symbian
On Wed, 04 Apr 2012 15:24:47 +0200, Łukasz Spas wrote: Hello. I've developed small application for Symbian (tested on S60) which allows users to manage their finances using their Symbian phone. (Here is the repo: https://gitorious.org/gnucash-s60/gnucash-s60) It is still incomplete because I would like to add functionality which allows to synchronize list of transactions with desktop' GnuCash via Bluetooth using QIF file format. And here goes the question - is it hard to add reciving QIF file via Bluetooth importing it to GnuCash's database functionality? I have never look inside GnuCash's code and I don't know where I could start. (Maybe someone could help?) Moreover, is it even possible to add such Bluetooth import functionality to main GnuCash repo? I think it might be useful for many of smart-phones owners and gives a possibility to write many of mobile ports/clients of GnuCash easily. Doing bluetooth is probably the easy part. It's just a comm protocol, after all. The trouble lies with QIF. At least the last time I looked, it just doesn't have all the information you need. It doesn't identify the account the QIF file is about, and it doesn't clearly identify the accounts that are at the other end of transactions. The result is that the QIF reader in gnucash contains *lots* of code about guessing what accounts are to be used for different transactions and recording user feedback about the guesses to make better ones in the future. Not to mention that if you get another QIF from the bank a week later, it has to identify which transactions are *already* in the gnucash file and which are new. QIF provides no transaction serial numbers to make this reliable. Such serial numbers are de rigeur in any professionally designed protocol. In any case, if the user has edited the transaction using gnucash, you *don't* want that change to make the importer fail to recognize it and import it anew. So, to do the job *right* (whether it's worth the effort or not), gnucash would have to have unique transaction IDs for each transaction in its database. (Does it already do this? I don't know.) Then you could perhaps look at the code for qif import (or maybe there's another importer you could look at which might be better) and adapt it to whatever intermediate file format you'd *like* to use with your application. That file format should explicitly identify the accounts at both ends of each transaction. Gnucash accounts, at least in the XML file, have some king of binary hash ID to identify them uniquely. That might be useful here. I don't know if those hashes are in the actual data base, though, or just part of the XML file format. You app would of course have to know the names of the accounts so that the user with the mobile phone could select them unambiguously. It might even be possible that gnucash's XML format for transactions might have the right information for your intermediate files. Or not. All in all, it's a big job, and *I* didn't volunteer to do anything like it a few years ago when I thought it might be useful. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: For The Love Of Bitcoin
On Thu, 02 Feb 2012 10:18:47 -0500, Derek Atkins wrote: karmic...@bitcoin2pay.com writes: [Bitcoin history elided] I didn't see any actionable requests in this long diatribe. What exactly are you asking? Note that you can always add your own commodity to GnuCash, although you need to treat it like a stock or fund instead of a currency, but all that means is that GnuCash forces you to always explicitly transact with an exchange rate. (It also means you cannot have income/expense accounts denoted in that commodity). Would there be any technical difficulty in allowing users to add their own currencies, instead of just their own commodities? -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: xaccAccountEqual ?
On Mon, 09 Jan 2012 16:17:02 -0500, Derek Atkins wrote: Hendrik Boom hend...@topoi.pooq.com writes: I thought you were working on learning to script Gnucash with Guile. In part, yes. But I'm really trying to learn to write an introduction for people who want to learn to script Gnucash with Guile. True, and from a user perspective xaccAccountEqual() is the API way to test whether two account objects point to the same Account. Just testing for acc1 == acc2 may work in some cases, My question was prompted by my surprise that tere were such cases. and I believe that xaccAccountEqual() does have that short-circuit in there. But users should use the API. This isn't C++. If it were then yes, we could have overridden the '==' operator to do a deep-inspection compare if the pointers are different. And I'm happy that you didn't override ==. That would be confusing. But because this is C we had to write our own API and ask users to use it. -derek -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: xaccAccountEqual ?
On Sat, Jan 07, 2012 at 04:23:16PM -0500, Derek Atkins wrote: Hi, On Sat, January 7, 2012 2:35 pm, Hendrik Boom wrote: What's xaccAccountEqual for? Is it actually something gnucash uses (I can't imagine what for), or is it just there because guile wants the smob to have a function that tests deep equality? I don't understand the question. It's there to test equality of two Account objects. The API is used in a dozen places throughout the code. I can see testing two pointers to Account objects to see if they point to the same Account object. But I thought, perhaps wrongly, that the engine would make sure that no account would ever have two different Account objects, presumably by some kind of test before creating the second Account object.. I do find myself wondering how one could ever be in the situation where two accounts are Equal, with Equal subaccounts, and even Equal splits except by amazing coincidence. And then why that coincidence should be worth testing for. Evidently I'm misunderstanding something here. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: xaccAccountEqual ?
On Sun, Jan 08, 2012 at 11:52:41AM -0800, John Ralls wrote: On Jan 8, 2012, at 10:40 AM, Hendrik Boom wrote: On Sat, Jan 07, 2012 at 04:23:16PM -0500, Derek Atkins wrote: Hi, On Sat, January 7, 2012 2:35 pm, Hendrik Boom wrote: What's xaccAccountEqual for? Is it actually something gnucash uses (I can't imagine what for), or is it just there because guile wants the smob to have a function that tests deep equality? I don't understand the question. It's there to test equality of two Account objects. The API is used in a dozen places throughout the code. I can see testing two pointers to Account objects to see if they point to the same Account object. But I thought, perhaps wrongly, that the engine would make sure that no account would ever have two different Account objects, presumably by some kind of test before creating the second Account object.. I do find myself wondering how one could ever be in the situation where two accounts are Equal, with Equal subaccounts, and even Equal splits except by amazing coincidence. And then why that coincidence should be worth testing for. Evidently I'm misunderstanding something here. Not two accounts, two account objects -- both of which might have been loaded from the same data in storage, or might have been deep-copied. (There was a partially-completed book closing implementation that did that as the first step. We're slowly weeding out the remnants.) I thought you were working on learning to script Gnucash with Guile. In part, yes. But I'm really trying to learn to write an introduction for people who want to learn to script Gnucash with Guile. Why are you worrying about the internals? Because (a) it's hard to know which things are internal and which aren't. And everyone trying to write scripts is going to have to figure out what they really need to know. (b) When I saw this, I started to wonder if I had completely misunderstood how gnucash works. (c) It's impossible to write something well without knowing more than you're writing. Even in fiction, it's a truism that if the author don't know what brand of cereal the main character eats for breakfast, there's a gaping hole in the story, even if that fact never really enters into it. (d) Besides, I start wandering through the docs, and encounter things like this. (Yes, it's true that the scripting interface exposes too much -- *far* too much -- of Gnucash's internals. That's partly laziness on the part of those writing the wrapper code and partly a legacy of Gnucash 1.x when it was written mostly in Guile. There's lots more here than needed for report generation, true. But I'm sure there are going to be other things the scripting interface is good for, for which we may need to expose those internals. So I vote no change here, for now. But when it gets documented properly, one of the things that's going to have to be decided is just which of the internals are going to be the official interface, which ought to be preserved during further development, and which of them, though useful in the moment, are *not* guaranteed to be there in the next revision. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gnucash mentioned in guile docs.
Just a matter of slight interest -- gnucash is mentioned in the guile 1.8 documentation. It seems that gnucash is part of a significant code eco- system for Guile-based applications. See the last paragraph of http://www.gnu.org/software/guile/docs/docs-1.8/ guile-ref/Scheme-vs-C.html#Scheme-vs-C -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Guile 2
On Fri, 09 Dec 2011 23:52:25 +0100, Geert Janssens wrote: Op vrijdag 9 december 2011 10:59:31 schreef Ted Creedon: Is anyone working on the Guile 2 issues? Not right now, but it's on my to do list. I plan to work on it somewhere in the next couple of weeks. Please keep me informed what's happening -- I'm trying to write documentation for the users who want to write their own reports and such in guile -- both for those who want their onw report generators invoked from within gnucash and those who want to use the gnucash engine in their own scheme code to access the database. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
xaccAccountEqual ?
What's xaccAccountEqual for? Is it actually something gnucash uses (I can't imagine what for), or is it just there because guile wants the smob to have a function that tests deep equality? -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Anyone speak french (gnucash-fr needs a new moderator)?
On Fri, 06 Jan 2012 09:14:46 -0500, Derek Atkins wrote: Hey, Email to the moderator of the gnucash-fr mailing list has been bouncing for a while. I want to ask the gnucash-fr list if there is anyone that would like to step up to be a moderator, but I don't speak french. I presume I could just write in English and hope people there understand me, or I could attempt to use Google Translate to make myself somewhat understood. But I was hoping someone on this list might be able to help? I'm learning French. I could try a translation with the help of a dictionary. I'm still shaky on verb conjugation and such, but I might still be better than Google Translate. In any case. I could at least vet the output from Google Translate; I may not be able to improve it, but I won't make it worse. But I really think enough of the gnucash-fr readers understand enough English to figure out that you're looking for a moderator, and you won't really need a translator. In Europe it's usual for the school system to teach multiple languages. You could even ask if one of the readers on gnucash-fr would translate your English message. They'd probably do a better job than I. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: iPad 2 app - please?
On Mon, 02 Jan 2012 17:33:25 -0800, John Ralls wrote: On Jan 2, 2012, at 1:32 PM, Nick Kemp wrote: I am a big gnucash fan – however, I would really love to have an ipad app... please? This has been discussed at length before. It isn't going to happen, not least because Gtk doesn't support iOS. Also, it's not at all clear whether gnucash's use of guile would get past Apple's approval process. If it was an easy port, I'd say let someone try it and see. But to do a major rewrite and have it rejected would be annoying. The gambit (another implementation of Scheme) implementors had a gambit app approved for a short while, then rejected and removed from the app market. The last thing you'd want would be to start relying on it and then have Apple pull the app. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: iPad 2 app - please?
On Sat, 07 Jan 2012 19:58:57 +, Hendrik Boom wrote: Also, it's not at all clear whether gnucash's use of guile would get past Apple's approval process. If it was an easy port, I'd say let someone try it and see. But to do a major rewrite and have it rejected would be annoying. Technically, it is allowed to write part or all of an app in an interpreted language. But if the user could write his own reports in guile, he could write them to download code off the net and execute it, which is forbidden. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Explorer's log: Entering the maze
On Sat, 03 Dec 2011 13:03:41 -0800, John Ralls wrote: If you haven't already, you might find it helpful to take a few minutes to skim over the Doxygen documentation. That will help you understand why the docs are structured the way they are. People using a scripting languagee to access gnucash date structures would probably be most interested in the pages starting at src/doc/html/group__Engine.html, or online, at http://svn.gnucash.org/docs/HEAD/group__Engine.html because most of the links at http://svn.gnucash.org/docs/HEAD/index.html#doxylist seem to refer to obsolete documentation. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: 2.6 Release -- SCheme
On Fri, 30 Dec 2011 18:19:58 +0100, Geert Janssens wrote: Op vrijdag 30 december 2011 09:06:58 schreef u: Swig/Guile: It looks to me like we have a much broader problem: Swig's Guile support is not maintained. For the short term we can try applying the patch from the Swig bug report and see if that gets us Guile 2.0 support, but in the longer run it looks like we need to either switch back to GWrap or replace Guile with something that's better supported. Yes, this is a bad problem. This is probably a more drastic change than guile 2.0, but: There's another implementation of Scheme available that actually compiles Scheme to C or C++ -- Gambit-C. You can actually embed C++ code within the C code, even #include stuff. There's also an interpreter, but the interpreter doesn't have embedded C/C++ code, though it can call previously compiled code that does. The Debian package is called gambc. I have no idea whether this would be easier to use and maintain than using guile. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash reports using php and mysql
On Thu, 29 Dec 2011 10:44:31 +0100, Gour wrote: On Wed, 21 Dec 2011 10:10:39 -0500 Donald Allen donaldcal...@gmail.com wrote: My motivation was the same as yours -- I could not get what I wanted from the built-in reports and I felt that the cost of trying to learn to work within gnucash (in spite of the fact that I am a *very* experienced Scheme programmer) was higher than the approach I took. Huh...this does not sound optimistic for potential GC users wanting to customize their invoices/reports... Is there any plan to improve reporting system in 2.6 or we cannot expect anything before 3.0? I'd suggest having a look at an interesting thread, Scripting API, on gnucash-devel started by Hendrik Boom in November. It discusses similar issues and the subject of the fairly new python bindings capability comes up, something I have not investigated myself (only because I already have something that serves my purpose, developed before the python bindings capability became available) but is probably worth looking at if you are actively developing reports for yourself. It's still on my personal TODO list, but family and other matters have severely diverted me from writing the necessary documentation, and possibly any code the documentation will suggest to me as necessary. I still intend to get back to this. I still thiink that the primary problem with the report-writing tools is not that they are unusable, but that no one knows how to use them. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy
On Sat, 03 Dec 2011 16:40:07 -0500, Donald Allen wrote: I've been watching with interest the messages flying by from various people that confirm the impression (from just trying to build it) that Gnucash has become a gigantic hairball. John Ralls has been saying a number of things that sound smart (I'll tell you later where to send the check, John) about design errors, problems in the data model, etc., and has embarked upon a re-design. Christian has taken a similar step back with Cutecash. Then there's the whole issue of the use of Scheme. Much as I love the elegance of the language, I doubt that its use is appropriate here, for all the reasons that we've discussed ad nauseum. So I'd like to suggest that perhaps none of the proposed ways-forward are radical enough. I have little to no knowledge of Gnucash internals. The only thing I know about the quality of the design and the code is what I read from the people who are currently doing the real work. But I do have many, many years of experience working and managing projects of similar and greater complexity, and there are times when you just have to cut your losses. Gnucash has been around for a long time, and its life-span covers the development of a lot of tools. If you were going to start with a blank sheet of paper today, I doubt very much whether you would do a lot of the system as it is today. The big question is, when is it worth it to cut your losses and start over? I don't know that Gnucash is at that point, but I'm suggesting that you give this question very careful consideration, before doing something incremental. Rewriting is a normal process in the design and implementation of quality software. In fact, I consider it essential in maintaining clarity and making reliability possible. But most rewriting is incremental in a well- modularized program. And rewriting that makes a program more modular is often the best kind. In a large program, I often spend half my time rewriting existing code with no change in program behaviour. It's essential to pave the way for later substantive changes. The truth is also that it's very difficult to know how a program should be organized from the start. Only if you've written a number of similar programs before do you have much of a chance of guessing right ab initio. So rewriting and reorganization had better be part of ones' strategy all along. Keep in mind that if you did start over, the current system wouldn't be a total loss. I'm sure there is a lot of value in things like accounting rules that it enforces, and other knowledge embedded in the code. Some of it might be salvageable by lifting parts of the code itself, or at least doing translations. Other cases might involve just transferring knowledge of how to do things and how not to do things. But I say don't throw good money *possibly* (not definitely) after bad without at least considering whether it's time for Gnucash II. Seriously, I've thought of it before deciding to join this project in any role but kibitzer. There's lots of ways I'd like to rewrite it all from scratch (redoing it all in Modula 3, for example). But in my opinion it provides me more return for effort just participating in what's here already. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Strategy
On Sun, 04 Dec 2011 18:35:08 +0200, Graham Leggett wrote: On 03 Dec 2011, at 11:40 PM, Donald Allen wrote: Gnucash has been around for a long time, and its life-span covers the development of a lot of tools. If you were going to start with a blank sheet of paper today, I doubt very much whether you would do a lot of the system as it is today. The big question is, when is it worth it to cut your losses and start over? I use gnucash because a) it's been around a long time, and b) because gnucash is likely to be around a long time still. Anyone can start over at any time - that's called a new product - but when people decide to abandon what they have and start over, that's when you lose faith in the project and start to look somewhere else. Sure, new fandangled languages are shiny, but will they still be popular in 5 years? No idea. I am happy to bet that C will be around in 5 years, so investing in the language as unsexy as it might be for me is a good investment. Yeah. C will still be around. Scheme is almost as old, (older if you consider it Lisp) and will be around too. I'd guess Python will too, but I'm not nearly as sure of that. I think gnucash needs a heavy set of refactoring. I'd like to see a proper libgnucash split out as a separate library that I can depend on in other software. I'd like to use a libgnucash library as a basis for a restful service that will allow me to share gnucash with others, like my accountant. But I don't think gnucash needs to be started over. There was once and enterprise-resource system (whatever that is) that comprised around 200,000 lines of C (or was it C++?) code. They decided that for some new functionality they should add a scripting language. They picked Gambit, and implementation of Scheme, as their scripting tool. Now it happens that Gambit is exceptionally compatible with C and C ++, because although it's usually interpreted, it can also be compiled to C or C++ (that's how it's bootstrapped, as it happens). And in the compiled form, it has specific mechanisms to declare and call C functions, include C header files, and so forth. After they started down this path, they discovered other stuff within the program that needed improvement, and found the easiest way to do it was to rewrite in Gambit. Eventually in the course of two years or so, the 200,000 lines of C/C++ had been reduced to about 15,000 lines of Gambit code (or was it 25,000? I forget. I'll look it up if it's really important.) Not only that, but the program ran significantly faster, because of the insights they had into how badly they had been doing things, and because of extensive use of the profiling tools in Gambit. The effect was a complete rewrite. But it was all incremental change. Every bit of it could be seen as improvement over what was there before, and worked in context. Evolutionary change. No. I'm in no hurry to throw Scheme out. Nor am I eager to start a project to rewrite everything in Scheme, or C++ or C# or Mesa, or even one of my favourites, Modula 3. Change what needs to be changed. Change what's ugly and becoming unmaintainable. Prove all things; hold fast to that which is good. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Explorer's log: Entering the maze
Thanks for all the help so far. I now generate the users and doxygen documentation, and have started exploring it. The internal system documentation is a maze. And unlike mazes printed in puzzle books, there aren't clearly identified start and finish points :) Or, at least, I haven't found them yet. I'm going to try and keep a log of my adventures getting into the maze; it may help later when I or someone else is writing or rewriting documentation. Should I send the log entries here? Most will not be cries for help, but they may serve as a guide for an author of a StartReadingHere page or some such. I hope my style here will be light and engaging, but if it doesn't turn out that way, I can only apologize. So far I've found gnucash/src/doc/html/index.html, which looks like a start page. It contains lots of links, but has no notion of which links are more or less important. The first Doxygen overviews I went to were Engine Framework and Engine Architecture. Engine Framework is minimal, and doesn't seem to have anything to say about an engine framework. It does have an API link, and that's perhaps the important part of that page. Other than that, there's a mention of additional API documentatino in src/doc/design/engine.texinfo, which , rather helpfully, advises me not to read it as being hopeless obsolete. The companion page, Engine Architecture, merely tells me it is becoming obsolete, and, rather helpfully, recommends I refer to the design documentation in src/doc/design for a complete description of the Engine architecture src/doc/design for a complete description of the Engine architecture. I do so, and discover that every file with content in that directory is marked as hopelessly obsolete. No, don't rush to delete them right away -- I think the history is valuable. They are plainly enough marked that they won't confuse anybody as too the current state of affairs. Now the API link I mentioned above (to file:///home/hendrik/dv/gnucash/ workspace/gnucash/src/doc/html/group__Engine.html) *is* important, and links to that kind of stuff is what should be on an API intro page, together with short descriptions of what one can expect to find at the end of each link. The group__*.html pages seem to organize the meat of the API. I'll start on such a page. I'll leave it to later to decide whether it should be assembled out of pieces by doxygen or written as a single coherent piece of prose. I'll have to have some content before determining the form. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Building user documentation -- just one glitch.
As John Ralls pointed out, the proper way to check out the user documentation is svn checkout http://code.gnucash.org/repo/gnucash-docs/trunk gnucash-docs Everything was almost smooth sailing from there. The first problem was that I didn't have the command xsltproc. The ./configure suggested that I should have libxslt installed. I already had it installed. It turned out that xsltproc was not in the libxslt package, but in a package of its own, called xsltproc. Is this a Debian testing peculiarity, or is it likely to be widespread? I can propose a patch to gnucash-docs/README to add xsltproc to the list of prerequisites, but I'd first like to know whether this is necessary in general, or just a Debian testing peculiarity. Anyway after that things went smoothly, and I got a lovely set of html documentation. I haven't tried to make epub yet, and it may be a while before I do. It seems to need calibre, and as far as I can tell at the moment, calibre on Debian testing is broken. I boot Debian stable when I need calibre to make epubs for my bookreader. Looking into this is an entirely different project from gnucash, and I can live without epub for the time being. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting documentation
On Wed, 30 Nov 2011 15:12:31 -0500, Derek Atkins wrote: Hi, The API docs are generated via doxygen. You can generate them yourself using make docs. The sourcesof the API docs are spread out through the source tree. But when I'm in the top directory of the source tree (the same placs I originally executed ./configure and the general make commands), when I execute make docs it tells me make: *** No rule to make target `docs'. Stop. Until further notice, I'll look through the source tree for Makefiles that do have a docs target. AH! There's a doc target. Would that be the one you mean? -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting documentation
On Thu, 01 Dec 2011 15:16:53 +, Hendrik Boom wrote: On Wed, 30 Nov 2011 21:13:58 +, Yawar Amin wrote: Hi Hendrik, The user documentation is in the gnucash-docs repository ( http://svn.gnucash.org/trac/browser/gnucash-docs). Evidently there's still something I don't know, Sorry to waste your time. I found it: svn checkout http://code.gnucash.org/repo/gnucash-docs/trunk gnucash-docs -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting documentation
On Thu, 01 Dec 2011 15:16:05 +, Hendrik Boom wrote: On Wed, 30 Nov 2011 15:12:31 -0500, Derek Atkins wrote: Hi, The API docs are generated via doxygen. You can generate them yourself using make docs. The sourcesof the API docs are spread out through the source tree. But when I'm in the top directory of the source tree (the same placs I originally executed ./configure and the general make commands), when I execute make docs it tells me make: *** No rule to make target `docs'. Stop. Until further notice, I'll look through the source tree for Makefiles that do have a docs target. AH! There's a doc target. Would that be the one you mean? Possibly not, because make doc tells me that doxygen.cfg is not found. hendrik@notlookedfor:~/dv/gnucash/workspace/gnucash$ make doc make -C src/doc doc make[1]: Entering directory `/home/hendrik/dv/gnucash/workspace/gnucash/ src/doc' rm -f doxygen.cfg.tmp sed doxygen.cfg.in doxygen.cfg.tmp \ -e 's:@-top_srcdir-@:../..:g; s:@-VERSION-@:2.4.99:g' mv doxygen.cfg.tmp doxygen.cfg doc: /home/hendrik/dv/gnucash/workspace/gnucash/src/doc distdir: rm -rf html refman.pdf doxygen.cfg /bin/bash: doxygen.cfg: command not found make[1]: *** [doc] Error 127 make[1]: Leaving directory `/home/hendrik/dv/gnucash/workspace/gnucash/ src/doc' make: *** [doc] Error 2 hendrik@notlookedfor:~/dv/gnucash/workspace/gnucash$ -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting documentation
On Thu, 01 Dec 2011 11:22:34 -0500, Derek Atkins wrote: This would imply you do not have doxygen installed. I didn't. I do now. It still doesn't work, failing in the same way. No time to investigate now. I'll look into it further tonight. Maybe there's a configure parameter I forgot. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: I probably did something wrong; having configure problems. SOLVED
On Fri, 18 Nov 2011 19:44:09 +, Hendrik Boom wrote: Op vrijdag 18 november 2011, Geert Janssens screef: On vrijdag 18 november 2011, Hendrik Boom wrote: Do build details really depend on the presence of .svn directories? It does. Not strictly from the directories, but svn tools are used to check if you are working from an svn directory. If you remove the .svn directories, you effectively prevent svn tools from considering your directory as a working directory. I really never thought the version control system would be involved in the build process. Live and learn. Now I have the .svn directories and it all makes properly. Thanks. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Scripting documentation
OK. I've managed to compile gnucash and get it to pass its checks (except for the database back end, which I had excluded. Now I'm ready to start prowling around looking for scripting API to document. Could someone tell me: Is there any existing API documentation, either in the source tree (which now has lots of automatically generated files) or on the wiki (please let me know where -- it's a huge source tree). Where are the source codes for the scripting API -- both the X side and the Python/Scheme side(s). So far I haven't found the rather extensive user documentation I'm used to seeing as a longtime gnucash user. Is it in the source tree too? Or somewhere else. Do I have to use a different make target to gennerate it? Anything else that might be useful? -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
I probably did something wrong; having configure problems.
This is the actual message I get. checking for ./src/swig-runtime.h... no configure: error: It looks like you are NOT building from Subversion but I cannot find swig-runtime.h. Check your PATH and make sure we can find svnversion in your PATH! Either that or contact gnucash-devel@gnucash.org because the tarball you downloaded is broken. hendrik@notlookedfor:~/dv/gnucash/workspace/gnucash$ Now the funny things are: (1) I am building from subversion, except that to avoid messing with my pristine copy, and to avoid accidentally uploading junk in case I should ever get upload privileges, I'm using a copy of the downloaded-by-svn source code that does not have the .svn directories in it. Do build details really depend on the presence of .svn directories? (2) I can find svnversion in my $PATH. hendrik@notlookedfor:~/dv/gnucash/workspace/gnucash$ echo $PATH /home/hendrik/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/hendrik/ bin/i686/:/usr/local/cm3/bin/:/usr/local/Gambit-C/current/bin/ hendrik@notlookedfor:~/dv/gnucash/workspace/gnucash$ which svnversion /usr/bin/svnversion hendrik@notlookedfor:~/dv/gnucash/workspace/gnucash$ (3) But indeed, I can't find swig-runtime.h anywhere either. Where is it supposed to come from? -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: I probably did something wrong; having configure problems.
Op vrijdag 18 november 2011, Geert Janssens screef: On vrijdag 18 november 2011, Hendrik Boom wrote: Do build details really depend on the presence of .svn directories? It does. Not strictly from the directories, but svn tools are used to check if you are working from an svn directory. If you remove the .svn directories, you effectively prevent svn tools from considering your directory as a working directory. I really never thought the version control system would be involved in the build process. Live and learn. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system - declarative
On Sat, 09 Jul 2011 18:05:48 -0400, Yawar Amin wrote:
Hi John,
On 2011-07-08, at 23:33, John Ralls wrote:
[…]
Fun. Two questions: Can that be easily converted into a string parser
so that normal users aren't put off by the extra parentheses,
I guess we could replace all the parens with more HTML-reminiscent
characters like and , so you’d get stuff like (btw I’m using dots
to represent spaces everywhere as my MUA is eating up the first blank
space on every line):
report ...
..defs
def-date ...
def-date ...
..
then do a search-and-replace to turn that back into Scheme. We might
overcome a lot of phobia if we hide the fact that we’re really making
them write Scheme :-)
There's also the use of [ ] in the old much-forgotten Lisp 1.5
metalanguage -- using foo[a, b, c] instead of (foo a b c). Perhaps foo[a
b c] would suffice. And C uses context-prefixed curly brackets, as in do
{ ... } and else{ ... }.
Another thing we could recommend is lining up the parens below the
function names on multi-line function calls. I mean:
(report ...
..(defs
(def-date ...)
(def-date ...)
..)
)
In the beginning I found it a lot more digestible when I didn’t have to
deal with the mess of ‘)))’.
I still find your layout more digestible, after years or using Scheme-
related languages. I prefer it in C with its curly brackets, too.
Now the parentheses in List are a syntactic price that's paid to make the
metaprogramming aspects more modular. There's no question of what can
fit within what, as there would be with independent pieces of context-
free grammar. I consider uniform means of reducing the parentheses
problem a boon.
In my own Lisp dialect I used an additional convention: '/' in a list
signals the start of a sublist as its last element; thus ( a / b ) is
equivalent to ( a ( bb )), and ( a / b / c ) equivalent to ( a ( b ( c
))). This eliminated most of the closer-clusters. It ended up having a
role similar to the that of ';' in other programming languages.
Unfortunately, '/' and ';' now have other, incompatible meanings in
Scheme.
But most Scheme programmers object to any suggestion that brackets are a
problem for Real Programmers, as if methods of dealing with parentheses
attack their virility or something like that
I just think programs should be written in a manner that makes them as
clear as possible. Programming is hard enough without unnecessary
obfuscation.
and is there anything about that that works in Scheme but not in C?
I really, really don’t want to deal with memory management….
Anyway, I kind of mercilessly hacked the ‘Hello, World’ report that
comes with GC, in
share/gnucash/guile-modules/gnucash/report/hello-world.scm, and wrote a
few functions which do what I was talking about. So now I’m able to say:
(d:report
income-statement ; name
0 ; defs
; Have to keep this title while experimenting in the sample report that
; comes with GnuCash
Hello, World ; title
2011-01-01 to 2011-07-31 ; subtitle (d:filter-none ; body
Is there a missing line break in this line?
(d:p Some text.”)
(d:p A little more text.)))
… and that generates the report that you’d expect. The ‘d:’
(‘declarative’) prefix is just to make sure I don’t clash with anything.
Code is up on https://github.com/yawaramin/gc-decl-reports (I'm not
pushing anything which causes a crash for me, so it should be reasonably
safe. But caveat emptor).
Regards,
Yawar
___ gnucash-devel mailing
list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Feature suggestion: display account numbers in register and account selection popup
On Wed, 24 Aug 2011 14:32:16 +0200, Florian Haas wrote: Some existing account hierarchies (in the de_DE locale) presently work around this limitation rather crudely, by including the account number as a prefix to the account name. Apart from that being a rather inelegant redundancy, it also creates a suboptimal user experience: GnuCash displays account names right-aligned in the register -- so for long account names, even if the only display leaf account names option is checked, the account number is often invisible. As a workaround, perhaps you could postfix (instead of prefix) the account number to the account name, as part of the leaf account name? Then it would show up in the right-aligned register display. Still inelegant, but ... -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python script: Gnucash
On Fri, 07 Oct 2011 14:38:37 +1300, Andrew Ruthven wrote: Also, I'm not sure if has been mentioned here already, but myself, Micha Lenk and mostly Philipp Kern packaged up the python bindings for Debian. They're in the python-gnucash package in Debian testing unstable. If that was recent, it explains an anomaly I noticed today. The package python-gnucash has arrived in Debian wheezy according to aptitude on one of my machines, but not on another, which uses different mirrors. In any case, thanks. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On Thu, 07 Jul 2011 20:48:27 -0500, Tim M wrote: What I'm looking for is this: 1. Create the 'new' reporting system alongside the existing one so that the reports do not suffer until the existing functionality can be fully replaced by the new system. After all reports are replaced and working, the old scheme code could be pulled. 2. Create a set of libraries and/or use the existing gnucash libraries for querying information from the database. Based on the discussion, I presume C or Objective C would be best and just avoid Python/Scheme altogether (I am not sure how the scheme system actually performs the data queries right now). If all the necessary code is already in place, then this does not require any work. As far as I've been able to figure out so far, the python and scheme bindings use the existing gnucash libraries to access the data base. So if the current reports are what you need, why rewrite in C? But it does make sense to allow the Scheme reporting system to generate XML. And if it's essential for some reason to have them compiled, the Gambit C implementation of Scheme (as in Debian package gambc) is capable of compiling Scheme into (rather unreadable) C. Of course there are subtle differences between Gambit and guile, and including another tool into gnucash would be a big step. 3. Using these libraries, create the code for aggregating the data (also in C or Objective C) for each report. A single prototype report would be OK to start. Output the report data as structured XML. The XML data should adhere to an XML schema. All in favour of allowing reports to be in XML. It probably won't take too much effort to allow this. It's what I'm already doing with my personal reporting tool that reads the gnucash XML file. It's written in C++ and has to be changed every year or so to adapt to changes in teh gnucash file. All I needed for neat output was a .css file. It's quite effective. 4. For each report, create an XSLT file which will transform the data into HTML/XHTML for display. 5. A small amount of javascript would be needed to perform the actual XSLT transformation but it would be pretty small. 6. Style the page elements using CSS. Also, I think the jqplot patch that has been made could be migrated in to the new reporting system, as those graphs look really nice. If we're brainstorming about report-describing formalisms, has anyone looked at RPG, a commercial workhorse from back in the 1960's? It wouldn't be directly applicable unless it's changed drastically since then, but some of its ideas may be. I think there are several benefits to this approach: 1. Currently reports can only be exported as HTML. By making the reporting code export an XML data structure, reports could be easily exported from GnuCash as XML (pre-transformation) or as HTML (post-transformation). Much desired. But could probably be achieved with only minor changes in the present system. 6. No reliance on Scheme or Python. Minimal Javascript, but that should be handled easily by webkit. To achieve advantage 6 would require major changes, though. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Reporting system and potentially Python
On Fri, 08 Jul 2011 23:33:16 -0400, John Ralls wrote: On Jul 8, 2011, at 8:15 PM, Yawar Amin wrote: If we stick with Scheme, we can take advantage of all the low-level functions that already exist for data extraction and report layout. But we can also move to a declarative model where we can have convention (re-use the report definitions as options) over configuration (build an options dialog box). Also, is it still true that we have to restart GnuCash every time we change a Scheme report, to see the changes? In any case, we need to make it dead easy for users to import and run and custom reports. Best, Yawar * I find that I’m saying ‘declarative’ a lot nowadays–I think it has to do with the fact that I’m learning Haskell :-) Fun. Two questions: Can that be easily converted into a string parser so that normal users aren't put off by the extra parentheses, and is there anything about that that works in Scheme but not in C? One of the hallmarks of Scheme is its metaprogrammability, for applications just like this. And its simple syntax promotes this. Not that it isn't possible to write string parsers and the like, and many Scheme systems come with packages for this. But once you go this route, coding tends to become inflexible, like in C. But as I've said elsewhere, the greatest barrier users encounter in trying to use the existing reporting tools isn't that they're written in Scheme. It's that the API they use is undocumented. That's something I hope to do something about. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting
On Sat, 12 Nov 2011 12:55:08 -0500, Derek Atkins wrote: Hi, Hendrik Boom hend...@topoi.pooq.com writes: [snip] (1) The bulk of the code for gnucash should be a shared library, whose API (s) provide all the essential functionality of gnucash. This would include code for starting up gnucash, shutting it down, reading gnucash fies, opeining the usual gnucash window, and so forth. The current work of converting ad-hoc code to use Gobjects could go a long way to making this API consistent. (2) The gnucash main program itself should operate entirely by using this library's API. Maybe (1) and (2) is how gnucash is already structured; I don't know. This is already the case.. However it's not a single Shared Library. It's a ton of shared libraries. Good. (3) This library would be the basis for scripting interfaces to gnucash. The API would make the gnucash library itself indifferent to the scripting language being used. Of course, the API must still be clearly documented, or it will be practically useless. Documentation in the header files may suffice. This is also the case. The Scheme and Python bindings are based on the C APIs by wrapping using SWIG. Good. By the Scheme bindings do you mean the hooks for the report- generating guile code? [snip] But now I'm getting far in advance of myself. I'm currently arguing only for a clear, conprehensive, documented API that others could use to build their own edifices on top of gnucash. That would open the gates to all kinds of unexpected collaborations. I agree wholeheartedly. Are you willing to help document the APIs that exist? Yes, in principle. I hadn't known about the python bindings. First, it would make sense for me to try to use the python bindings to see if I can do what I need, writing a kind of a diary of what I discover I need to know and producing bits of preliminary documentation as I go. How does collaboration work with documentation? Is it a wiki? or svn access? or something else? -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: developer account created mchochlov
On Tue, 01 Nov 2011 15:41:47 -0400, GnuCash Admin wrote: This is an automated e-mail via the add-new-developer script ($Revision: 1.7 $). Developer account Muslim Chochlov has been created: mchoch...@code.gnucash.org. Admins (root) should update CVS access for this user. Are you still using CVS? Or does this message need to be changed? Or is this completely out of your control? -- hendrik Welcome to the team. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Scripting API
On Sat, 12 Nov 2011 11:35:46 -0500, Nicolae Crisan wrote: I am 100% on-board this score. Again, finding the boots on the ground to do this is another matter altogether. The existing Python scripting API would be a good place to start. Maybe, all told, it's all we really need, except users who are obsessive about their language preferences. If I were to try using Python and still felt I needed something more, I'd be tempted to volunteer for this. Wasn't there an attempt to devise a common run-time system for dynamic languages some time ago? If so, could that provide some scripting- language independence? This is far-off stuff, not really a gnucash issue, though. An accessible and well documented API is definitely a worth while venture in my opinion. API's have the effect of not only opening up other possibilities to the programs reach, but it generally has the effect of cleaning up other parts of the application that have not been so heavily developed or carefully attended to. Yes. Any formal review of a large code body usually finds places where it can be improved. Question, would this API change affect the portable nature of GnuCash or would it have absolutely no effect whatsoever? I'm used to working with languages and libraries that are provided everywhere I'm programming, so I'm not used to the portable aspect of programming. Most of my work is heavily based on server-side scripting (PHP, mainly) as well as local client scripting (JS, CSS, HTML, etc.). Having the API by itself should have no effect on the portability of gnucash. It would be just more code written in the same language as the rest of gnucash.But *use* of the API as a shared library would be possible only on systems that have shared libraries. And the semantics of sharing may differ substantially between operating systems. I seem to remember that Windows shared libraries share writable data, whereas Linux ones don't. Can anyone confirm this? Where things could be really nonportable is in the scripting languages that might be implemented (by us or others) on top of the API. There are probably lots of nonportable scripting languages. In regards to your comment on creating some sort of front-end web-based architecture ... I have some reservations about this feature set. While I completely agree that would enhance and extend the reach of GNC, I would recommend that by default such a feature set be DISABLED. I know we're talking about stuff way in the future here, ,but just thought I'd point that out. I wouldn't want gnucash to provide a front-end web-based architecture at all. That's strictly for people who want to put financial information on the web. Let them do the web programming to suit their aesthetic, practical, and security needs as part of their website implementation. All that the API would do is give them the hooks they need. If I did anything like this at home, I'd restrict all access to my LAN, for a starter. Now I have been producing XML reports with CSS. But they're not connected to my web server at all. I leave them as files on the hard drive, accessible only to local users who can use file:/// URLs. Occasionally I produce updated ones. Hope to see more support for development of an API. As I am pursuing my Accounting degree at the moment ... I unfortunately cannot partake in a big way (at least I'll tlel the wife I can't!) right at this moment. But, if I can get a sense that this community is really behind this, I'll be more than happy to drop everything and contribute. It's crazy, I've been an IT professional for over 10 years, and I'm now pursuing my Accounting degree, what an awsome mix! IT and Accounting would indeed be good skills combination. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Scripting
A few years ago I wanted some printouts of gnucash data formatted in a form that my wife and I could use. It was frustrating to me that the easiest way to accomplish that was to reverse-engineer the gnucash file and hand-coding a C++ program that read in the XML file and further processed it. The initial, usable, form of this program was written in C+ + in about a day. Over the years, I've embellished it in various ways, sometimes to change functionality, sometimes to accomodate subtle changes in the gnucash file format. But it seems silly to duplicate stuff that's probably in gnucash itself, and is even maintained by the gnucash implementers. And it's obvious that with the shift to a database, I should consider reading the database instead of the (probably derivative and deprecated) XML file. I had looked at the gnucash source code, but I found it much harder to understand than the XML file itself. I had asked for information about an API for understanding the internal gnucash state and was referred to some (IIRC machine-generated) documentation. It didn't help much either. In particular, it didn't make it clear what I had to do to set up the internal gnucash state that it was reporting on. While a fine API for code that ws embedded within gnucash, it didn't really suffice for external code. And looking at the guile interface for reports didn't help much either, even though I was an experienced Lisp/Scheme programmer. At the time (is this still the case?) the only usable documentation to the reporting subsystem was the source code for the reports themselves. This definitely wasn't enough. The report code was full of functions with obscure names and equally obscure significance. This isn't a problem with Scheme being a difficult language to learn. It isn't difficult. It can be learned by a competent programmer in a day or two. It's a problem with obscurity of the API the reporting subsystem provides to the Scheme programmer. In subsequent years I've wanted to produce report output in forms other than HTML, which, as far as I know, is the only one supported by gnucash. I've also wanted to write some custom data-entry software for getting data into gnucash. Now presumably, given enough time, I'd have been able to overcome these obstacles to interfacing with gnucash code the way it obviously wants to be used. But, of course, at the moments I was faced with the need to produce, there wasn't enough time. *** Now I'm not really interested in just complaining. If you'll forgive a lurker, but long-time user, from speaking up, let me at least make a proposal. Yes, I know it will probably be a lot of work, and who will be found to do it, etc. What I'd like to hear is whether there are serious flaws here, and whether it's ever likely to gain the social support to make it worthwhile to try, etc. (1) The bulk of the code for gnucash should be a shared library, whose API (s) provide all the essential functionality of gnucash. This would include code for starting up gnucash, shutting it down, reading gnucash fies, opeining the usual gnucash window, and so forth. The current work of converting ad-hoc code to use Gobjects could go a long way to making this API consistent. (2) The gnucash main program itself should operate entirely by using this library's API. Maybe (1) and (2) is how gnucash is already structured; I don't know. (3) This library would be the basis for scripting interfaces to gnucash. The API would make the gnucash library itself indifferent to the scripting language being used. Of course, the API must still be clearly documented, or it will be practically useless. Documentation in the header files may suffice. It's worth noting here that some systems that can be used as scripting languages are capable of handling the C and C++ interfacing on their own, requiring no significant footprint in the gnucash library itself. (I'm thinking specifically about Gambit C here, which is an implementation of Scheme taht can compile to C. No doubt there are others.) Other languages that different users might want to use on top of gnucash? JavaScript, Python, Ruby and Erlang have been mentioned as languages that are in the Lisp camp as far as semantics goes. Several of them are interpreted. Google has recently put out a language that's designed for programs that partly run on a server and partly on a browser. Accessing gnucash from a browser, even only read-only, could be useful. But now I'm getting far in advance of myself. I'm currently arguing only for a clear, conprehensive, documented API that others could use to build their own edifices on top of gnucash. That would open the gates to all kinds of unexpected collaborations. -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Working more closely with GNOME
On Thu, 20 Jul 2000, you wrote: Terry [EMAIL PROTECTED] writes: On Wed, 19 Jul 2000, you wrote: As a biased observer and gnucash user, I would agree that this is probably good with some reservations from a user standpoint. Right now gnucash works with both gnome and KDE. If gnucash developers become committed to gnome, does that preclude running gnucash under KDE in the future? or would gnucash become a gnome only app. Or are the KDE and gnome APIs becoming closer and better coordinated so as to preclude gnome/KDE only apps. I may switch from KDE to Gnome in the future or I may use both at different times, but as a user I definitely do not want apps that work only on one or the other Right now I think having both Gnome and KDE is a big win/win/win situation for Linux, Gnome, KDE and all the users. This is especially so if Gnome and KDE APIs continue being coordinated so that everybody can use one or the other or both. Well, there are two levels on which I could answer your question. First, using the GNOME APIs does not preclude an application from running under a KDE desktop enviornment. Second, a project does not need to commit to being "GNOME only" to be involved in the GNOME Foundation. For example, Sawmill and Gtk+ both consider themselves to have broader reach than just GNOME. - Maciej I've certainly had no trouble running pre 1.4 versions of gnucash under KDE, though I started it from a shell instead of from an icon. -- hendrik ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
Re: GNUCash
[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 ___ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
denominators
One of the big issues seems to be whether we have just one denominator for a commodity, or many. Examples are being thrown around about whether there is a quantum unit of a commodity, whether it changes, and how often, and whether the quantum unit is so intrinsic to a commodity that, say, milk bought by the gallon is a different commodity from milk bought by the quart. Indeed, if every transaction involves its own denominator, independent of any other, using a fixed denominator would seem to be madness. It all transactions can be expressed in the same denominator, which is known a priori, there is no need to store it with every transaction. The choice of data representation is merely an optimization issue. Reality does not seem to be as neat as either of these extremes, though, and so the optimisation issue may have to resolved by a compromise. Let each commodity to have its own common denominator, but change this denominator when new transactions make it necessary. The new denominator be a multiple of the old one. Changing a denominator involves retroactively rewrite all existing transactions that involved that denominator. In typical situations the I imagine, the denominator for any commodity will settle down after a few transactions, after which all remaining transactions will be expressible in exact multiples of the final quantum. Even if an exchange redenominates fron 1/64 to 1/100, this would only change our common denominator for one of its commodities from 1/64 to 1/1600. - There is one nightmare situation for this approach: a series of transactions in a commodity whose amounts have relatively prime denominators. For example you might buy milk on consecutive days: 1/liter, 1/3 liter, 1/5 liter, 1/7 liter, 1/11 liter, 1/13 liter, 1/17 liter, 1/19 liter, 1/23 liter, 1/29 liter. The denominator will skyrocket, and reach the limit of 32 or 64-bit integer representation rather quickly, after which your grocery-budget accountant will worry about thee gnucash integer overflow. Actually, a problem that none of the proposals in this mailing list addresses is the possibility that a commodity mught be bought and sold in units whose conversion factors are irrational. Can you, for example buy angles in degrees and sell them in radians? Now the accountant can no longer remain silent. He formally accuses you of being a mathematician. :-) -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
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, ... An excellent example of a commodity whose units are changing. Remember when phone calls were charged by the minute? If we use a common unit of nanoseconds, how many bits will be need to account for years or centuries? -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominators
Actually, a problem that none of the proposals in this mailing list addresses is the possibility that a commodity mught be bought and sold in units whose conversion factors are irrational. As I said before, you can have irrational pricing but not irrational prices. The ledgers represent inventories. Inventories can be counted. Prices are exchange ratios. You trade items in one inventory for items in a different inventory. As such, field theory tells us that we will never have to deal with values that cannot be mapped onto the rational numbers. People do _not_ use irrational numbers; supposing they count in radians, the one situation where it might _appear_ to be an exception, they're likely basing this on _integer fractions_ of radians, which means that the unit of measure is an integer fraction that just happens to get multiplied by Pi so as to make it _appear_ irrational. Good Grief, that irrational number thing was a joke! Can you, for example buy angles in degrees and sell them in radians? humor Well, I won't "buy" that angle. Where did you buy your degree? Radian's already been sold. /humor But not marked as such because I was unaware of the HTML humor tag. :-( Or is that a joke, too? :-) -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominators
Unfortunately, it is sometimes difficult to distinguish humor from lack of understanding. There may be good reason for this difficulty. I suspect humour may have eveolved as a social mechanism by which those who do not understand can express same without embarassment. I suspect this thread has now wandered completely off topic. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
I don't think there is one; the _arguable_ counterexample would be the situation where a market changes "denominations," but that may also be argued to redenominate the commodity, which means it's not really the same commodity anymore... -- When I owe someone 12 1/2 shares of some security on a futures contract and the exchange redenominates to decimal, he is likely to accept 12.5 shares instead. It really is the same commodity. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: help on disabling preferences widgets
I agree that error handling is a PITA in functional languages.
Actually, it's not functional languages in general with this problem.
Unfortunately, your proposal only works one level deep.
One of the real advantages of "functional" languages is that you nest calls.
(let ((x (f1 (f2 (f3 foo)) (f4 bar)
Now, since f3 might return an error, you either have to manually "compile" a
string of 'and-let's
NB: Switching languages because a procedural language better illustrates the
process.
x = f1(f2(f3(foo)),f4(bar));
becomes
temp3 = f3(foo);
temp2 = f2(temp2);
temp4 = f4(bar);
temp1 = f1(temp2,temp4);
x = temp1;
Now, there are three approaches to handling the errors.
1) The language compiler can handle exceptions.
2) The caller can handle exceptions by placing a test BETWEEN each of the
function calls. (This is what 'and-let' does)
3) Each function return a {status, result}-tuple and check each of its
arguments for an error status
f1(a1,a2)
begin
if (!valid(a1)) return a1
elseif (!valid(a2)) return a2
elseif (*BadThing*) return {ERROR, BadThing}
else return {VALID, answer}
end
Each approach has its problems.
Primarily.
1) The language of choice may not handle the problem.
2) Nested function calls become unreadable
3) There is a danger that a programmer will forget the properly implement all
arguments in -tuple format and properly revert to non-tuples for calls to
sections written to a different convention.
Typed functional languages that include possibly launched exceptions
in the function's data type can do better -- if you forget to
handle an exception, you are so informed by the compiler.
But Scheme is not a typed functional language.
And, for reasons I have yet to fathom, typed scripting languages
are as scarce as hen's teeth.
-- hendrik.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
On Fri, Jun 30, 2000 at 01:39:07PM -0500, Bill Gribble wrote: Clark Jones [EMAIL PROTECTED] writes: 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 Partially true, but stock prices are an important part of gnucash, and while the US stock exchange is going decimal "pretty soon", there are historical prices which will always be in 64ths and the bond market is not likely to decimalize any time soon (according to Jon Trowbridge, who does this stuff for a living; is that a correct interpretation of your mail to me?). Yes. There are also lots of other examples from futures markets, which are a wonderful source of pricing perversity. For example, 10yr and 30yr US Govt Bonds trade in 32nds, and 5yr Bonds trade in 64ths. Soybeans futures (as well as Corn, Oats and Wheat) are quoted in 1/8th of a cent per bushel. These are all powers of two. Powers of two can all be represented exactly in decmal. The converse fails: poers of ten cannot always be exactly represented in binary. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
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). I believe some former British colonies still use pounds, shillings, and pence. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: backup v2
On Wed, 28 Jun 2000, Robert Graham Merkel wrote: But what if some catastrophic event happens while the modified log file is written to disk? Couldn't you possibly lose the entire log? I think not, but I don't know for sure. I was thinking that GnuCash would open() the log for appending only, and every now and then write a single log entry using a single write() call. What are the chances of a write error destroying data earlier in the log? War stories, anyone? (When chopping off the front of a log, GnuCash would use the same write-and-move procedure as it would when saving the database.) When appending to a file, unless the end of file is exactly aligned on a physical block boundary, the entire last block must be rewritten. This puts the (partial) contents of the last block at risk. Note that physical blocks on modern hard disks are much larger than the nominal 512 bytes oa 1k that Linux uses internally. -- hendrik -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: RFC : Correcting some problems in rounding/number handling
Clark Jones writes: 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". It's a good thought, and the use of C++ operator overloading is convenient for this kind of thing, but there is a rather large problem. Don't want to start a language flame war, but after listening to several weeks of C++ propaganda, I am no longer able to remain silent. In my experience (which includes writing a C++ parser and semantic analyser in C++ --- I'm not exactly a C++ novice), C++ is a slippery slope. You start out innocently enough defining a few operators to improve notation, and maybe a machanism for automating reference counting. After a while, you start using more and more of the metaprogramming tools built into the system and it becomes more and more difficult to know what your program is doing (and if it is doing the right thing). It takes ths utmost discipline to refrain from this behaviour in C++, a discipline that is alien to the gung ho style with whoch the C++ language was invented. In fact, the discipline needed is very close to restricting oneself to the subset of C++ that is essentially equivaleng to C semantically, which poses the question, why not stick with C? -- hendrik. -- 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]
Re: Log File behaviour
On Thu, Jun 15, 2000 at 07:41:29PM -0500, Richard Wackerbarth wrote: On Thu, 15 Jun 2000, Dave Peticolas wrote: Now, those .xac files - are they the previous data file, or are they written in parallel with the main file? (Or copied after the main file is written?) They are written immediately after the main file is written. So, if I have (only) a main file and start to edit it, are you saying that at the end, I have two copies of the modified file and NO copies of the original? Furthermore, while the main file is being written, there is no valid copy of the data? Surely at least the backup files should be written _before_ the main file is modified. You would still have the backup file that was created *last time*. --Dylan Thurston [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
When bankers first used mainframes, some slick programmers established "hidden accounts" which received the tinsy fractional part of the interest, the part lost when rounding DOWN to integer pennies ... It wasn't much, but as it happen at the end of every day, on every savings account ... they made money for themselves. A case of one procedure for me, another for all the rest of you. :-) I heard of this story, too, back in the 70's. Apparently the programmer inserted this into the program he was writing, and placed the stray pennies into his own account. (The pennies originated from him rounding up on one end of a transaction and down on the other). After a while, the bank wondered where their breakage was. It seems the bank had also been doing this themselves, and now this revenue stream mysteriously disappeared when they automated. They tracked down the code, and found the programmer's bank account number... -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency
You are correct. 32 bits are inadequate. It would be sufficient for MY personal accounts :-( but not those of Mr. Gates. Mr Gates is unlikely to use gnucash on Linux. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: denominating currency - was: non-functional 'if clause
Prices are handled differently from amounts. The price is multiplied by the quantity and that result is adjusted to the "integral" amount of exchange. At one time the US used "mils" ($0.001). However, clerks worked for $1 per day or less. With inflation, the smallest exchange is now the penny ($0.01) and commerce is conducted in those units. ... Each currency has its own "primitive" amount and all transactions are conducted in terms of that unit. Prices are often expressed to a higher precision or as a rational fraction of that unit. This suggests that we should be storing integers that indicate how many of the primitive amount are to be used. For US$ this would me an exact count of pennies. The range of integers must be greater than 32-bits, because that would limit amounts to about #40,000,000.00. So the obvious type is int64, which is not quaranteed to be present by either C or glib, but often is; the less obvious type is double, provided we make sure we only store integer values in the double variables (i.e., frequent rounding to integral). Thus, for display purposes, we may have to know the primitive amount for each currency as well as the format to be used. -- hendrik. I've always been doubtful about the use of floating point by gnucash. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
version 1.3.100 on SuSE?
I'm starting to install version 1.3.100 on SuSE Linux. First, I notice I don't have g-wrap. Unless I am mistaken, this package does not appear in either the SuSE 6.3 or 6.4 distribution. I download g-wrap-0.9.1-1.i386.rpm from the gnucash web site. I rpm -i --test g-wrap-0.9.1-1.i386.rpm, and am told: error: failed dependencies: guile-devel is needed by g-wrap-0.9.1-1 libguile.so.4 is needed by g-wrap-0.9.1-1 libreadline.so.3 is needed by g-wrap-0.9.1-1 I look for them: guile-devel I did not find guile-devel in SuSE. I did find a package called guile, which does contain a lot of .h files. Are these the files I need? libguile.so.4 Package guile contains a libraries usr/lib/libguile.so usr/lib/libguile.so.6 usr/lib/libguile.so.6.0.0 Is this a problem? libreadline.so.3 I appear to have a library /usr/lib/libreadline.a This will probably not do. Any suggestions? I could try to compile g-wrap myself, but its documentation does not make it clear that I can control where it places all its files. (nor is it clear I can uninstall cleanly -- anybodu know?) I do *not* want components I compile myself getting mixed up with the ones installed by RPMs. It's too hard to track them down during reinstallation or upgrade. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
version 1.3.100 on SuSE? (fwd)
I'm starting to install version 1.3.100 on SuSE Linux. First, I notice I don't have g-wrap. Unless I am mistaken, this package does not appear in either the SuSE 6.3 or 6.4 distribution. I download g-wrap-0.9.1-1.i386.rpm from the gnucash web site. I rpm -i --test g-wrap-0.9.1-1.i386.rpm, and am told: error: failed dependencies: guile-devel is needed by g-wrap-0.9.1-1 libguile.so.4 is needed by g-wrap-0.9.1-1 libreadline.so.3 is needed by g-wrap-0.9.1-1 I look for them: ... libreadline.so.3 I appear to have a library /usr/lib/libreadline.a This will probably not do. I just found usr/lib/libguilereadline.a usr/lib/libguilereadline.la usr/lib/libguilereadline.so usr/lib/libguilereadline.so.0 usr/lib/libguilereadline.so.0.0.0 Any chance that these will do? By the way, the README.SuSE file seems to have disappeared. Is there some reason for this? -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Stability of 1.3.99
T.Pospisek's MailLists writes: On 13 Jun 2000, Bill Gribble wrote: Ben Stanley [EMAIL PROTECTED] writes: When I last entered all of my transactions, which would have taken me about an hour, I had just finished and then GNUcash had a crash. I can't remember if it was a seg fault or bus error or what, but I subsequently had to re-enter everything I had just put in, by referring to the log file. Ouch. I'm sorry :( I guess that's yet another case where "save early, save often" is your friend. What about having a: [] autosave ever [] minutes option? That is by default set to ... let's say 1 minute? That's a good idea, but it'll of course have to wait till 1.5. For implementing this, what about checking a "time since last autosave" every time a transaction is committed (language might be less than precise here, correct me if I'm wrong). If we're over the threshold, autosave. Comments, anyone? It seems to me that recover-from-log is a cleaner solution. We make the logs for this purpose and keep them continuously up-to-date, don't we? This should fit in the engine, or immediately above it; the data base could be considered to consist of the existing file togetner with the log of all more recent transactions. When you load a file, you could automatically check whether it has any associated more-recent logs. This could be treansparent, or you could ask the user for advice if you find any. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Re-opening a file.
Glen Ditchfield writes: If I open an account file with GnuCash 1.3.99, and if I immediately re-open the file (either through the File Open... dialog or by selecting the file directly from the recent file list under File), I get an error alert saying that "the file /home/gjditchf/rats-nest.xac appears to be in use by another user...". Perhaps the messge should say, "You have already opened this file," assuming Gnucash know what files are open. If I make any changes before re-opening the file, I am prompted to save th changes first, but then I get the error alert. My first thought was that GnuCash should treat this as a no-op and just leave the file open, but perhaps it should ask whether I want to revert to th saved version? -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: 64 bit nonportability
On Sat, 03 Jun 2000 22:06:09 PDT, the world broke into rejoicing as Dylan Paul Thurston [EMAIL PROTECTED] said: On Sat, Jun 03, 2000 at 10:20:40AM -0700, Peter C. Norton wrote: On Sat, Jun 03, 2000 at 05:01:51AM -0500, Richard Wackerbarth wrote: I agree. Using gint32 rather than int only solves part of the problem. foo_t is much more flexible.It reduces the architecture dependency to a single point in the code. How is this different from using already-created typedefs in glib? glib seems to provide a lot of the types necessary, already done. I think the point is that you might decide to change the size of one of the types at some point. Ah, yes. Basic idea being that it might be good to have a single type, of platform-independent shape, that GnuCash uses. Thus, perhaps, the gcint type. Thus, everything in GnuCash would use the gcint type. gcint is defined via: typedef gint32 gcint; which accordingly references whatever glib.h provides. Note that this costs us _nothing_ at runtime, as the evaluation of types is done by the C preprocessor, and this gets expanded, by the compiler, to whatever is the "real" type from its perspective. I've always had trouble getting constants to have the right type. I don't think the preprocessor will hanle this cleanly (or have things changed since I last looked at C?). Evin if (gint32)7 works (I seem to remember thst this is not what is technically called a "constant expression"), there is still trouble with things like getting the maximum integer of type gint32. I see #define G_MININTINT_MIN #define G_MAXINTINT_MAX in glibconfig.h, but nowhere do I see a G_MAXINT32. Or is there something else I need to knw? -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
speed?
I'm slowly gearing up to use GnuCash on live data, and am attempting to start parallel operation with Quicken before cutting over comletely. As a result I am continuing to find problems, some of which are relatively easy to fix. But some, I suspect are not. Is there a speed problem, or am I doing something wrong.? I just imported *all* my Quicken accounts, and then started tracking down duplicated entries. Once I find one, it takes 45 seconds to delete it, starting from the moment I confirm the deletion to the moment the register has its new contents. This is the performance I expect from Java. I also notice that scrolling is quite slow. Also, if I happen to move the delete-confirmation window by grabbing it by its title bar, the window leaves a trail of ghosts, which slowly disappear at the rate of about one per second. The account I am editing has something like 7000 or so transactions. Could this be relevant? My guesses (using psychic debugging, without reference to source code) is: (a) - because gtk+ imposes a scrolling area limit af 32K pixels, you have too handle scrollong at a higher level in the protocol. - the higher layer is written in guile, which is interpreted (like Java) - so scrolling slows down quite a bit. (b) - deleteing a transaction involves recalculating sizes for the entire scroling area, and this also is done in guile, is interpreted, and so each deletion might end up taking the same order of magnitude of time as some of the analysis activities during importing. (c) - Events are queued, and not subsumed. So if you press the up cursor three times in a row, you end up displaying the register in three separate positions, instead of counting up-cursor presses and moving the register three lines all at once. I don't know if these analyses are correct, or whether the problems are in gnome/gtk+ or in the guile code for gnucash. In any case, this is probably not something to try and fix before the 1.4 code freeze. And perhaps the proper fix would be in gnome, not gnucash. Any comments? -- hendrik. P.S. For what it's worth, my processor is a Pentium running at 39.73 BogoMIPS; 48 meg of RAM. I'm running SuSE Linux 6.3. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: speed?
I think the bottleneck is in the Gnome Canvas, which is the basis of the register display. Dave P would know more about that. I suspect this is where it's happening, but we will need to do some profiling to be sure. Is each entry field in the register a separate Gnome widget? Do you suppose that the canvas does its complete set of layout calculations over again when a transaction is deleted? Or entered? Or changed? Would it be useful if I looked into the Gnome source code about this? Do you happen to know what profiling tools I should look for under Linux? Every OS I've used has a different way of doing this, and the best one is usually discovered by word-of-mouth, not by looking in manuals. By the way, is there a maximum allowable size to the memo field, cheque number field, etc? (I don't care if there are current limits on how much is displayed (these are at worst temporary(and they resize with the window (Aha! Four nested parentheses in an English prose. Natural language catches up to Lisp))), as long as all the data get into the file.) -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: importing one-ended transfers
On Wed, 31 May 2000, Hendrik Boom wrote: I now see the following possibility: One transaction, that debits the chequing account by $200, memo groceries debits the chequing account $10, memo cash debits the chequing account $90, memo allowances credits the allowance account $90, credits the cash account $210 This way the Quicken splits become gnucash splits in the same accounts. And Quicken splits that are associated with a category end up associated with the appropriate account. I'm not sure that I follow your logic here. Look at it from another view: Credit Allowance $ 90 Debit Chequing $300 Credit Cash $200 groceries Credit Cash $ 10 cash except that you lose the memo "allowances". This seems to me to be closer to the transaction items that you would actually realize. I'd be just as happy with your version as mine. It's just that I don't clearly see how your version generalises to situations where both ends of the transaction have been split in Quicken. I suspect that the bank only knows that you withdrew $300. From an accounting view, you have chosen to credit part of that to the Allowance account and the rest to the Cash account. You are using the memo field to represent subaccounts Cash:Groceries and Cash:Petty_Cash. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
importing one-ended transfers
When I imported *everything* from Quicken to gnucash, I noticed the balances were different in gnucash from in Quicken, even after fixing the "Opening Balance" transaction. Hoping to nail a gnucash bug, I binary-searched throug about 8 years of transaction data, and found that it was not Gnucash, but Quicken that seems to have been at fault. Here's an extract from my (Quicken) [Checking] account: 12/04 pos provigo33.67 X368.88 1998 memo: cat: Groceries 12/04 cash cash 300.00 X 68.88 1998 SPLIT [cash] 200.00 groceries allowances 90.00 allowances [cash] 10.00 cash 12/04 interac fee 1.25 X 67.63 1998 memo: cat: Bank Chrg 12/04 039 Mini-Menage65.00 X 2.63 1998 memo: cat: Cleaning and in [cash]: 12/04 cash 210.00 49,641.91 1998 memo: cat: [Checking] As you see, one cash withdrawal is split into several purposes, two of which are handled in the cash account. When I import this into gnucash, the transactions become duplicated. I get both the split transaction from checking and the unsplit transaction from cash, presumably because it does not recognise that the split transaction in [Checking] corresponds to the nonsplit transaction in [cash]. Now I don't expect you to run and fix this (though it would be nice) immediately before a stable release, for fear of disturbing something else. But if the mass import process were to produce a log of unmatched transfers, this would help me track them down. gif file extracts follow: -- hendrik. from cash: ^ D12/ 4/98 T210.00 Pcash L[Checking] ^ from Checking: ^ D12/ 4/98 T-33.67 CX Npos Pprovigo LGroceries ^ D12/ 4/98 T-300.00 CX Ncash Pcash L[cash] S[cash] Egroceries $-200.00 Sallowances Eallowances $-90.00 S[cash] Ecash $-10.00 ^ D12/ 4/98 T-1.25 CX Pinterac fee LBank Chrg ^ D12/ 4/98 T-65.00 CX N039 PMini-Menage LCleaning ^ -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
importing one-ended transfers (fwd)
Whoops! I miswrote myself. - Forwarded message from Hendrik Boom - "Opening Balance" transaction. Hoping to nail a gnucash bug, I binary-searched throug about 8 years of transaction data, and found that it was not Gnucash, but Quicken that seems to have been at fault. - End of forwarded message from Hendrik Boom - As you can see from the details, the bug is in gnucash not in Quicken. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: importing one-ended transfers
Hendrik Boom [EMAIL PROTECTED] writes: Now I don't expect you to run and fix this (though it would be nice) immediately before a stable release, for fear of disturbing something else. This period of time is for bug fixes, and you've found a bug, so it's the perfect time to fix it. The question is, what's the right way to fix the problem? In your ideal solution, would Gnucash merge the two splits into one, following the Cash account's representation of the event, or split the Cash transaction, following the Checking account's representation? Let's see.. In chequing, 12/04 cash cash 300.00 X 68.88 1998 SPLIT [cash] 200.00 groceries allowances 90.00 allowances [cash] 10.00 cash in cash, 12/04 cash 210.00 49,641.91 1998 memo: cat: [Checking] There are two Quicken accounts involved - chequing, and cash. There are three gnucash accounts involved - chequing, cash, and allowances. I had trouble deciding between your two choices, until I remembered that we do have multiple entry bookkeeping. This means we can choose how to split a little more cunningly that Quicken did. I now see the following possibility: One transaction, that debits the chequing account by $200, memo groceries debits the chequing account $10, memo cash debits the chequing account $90, memo allowances credits the allowance account $90, credits the cash account $210 This way the Quicken splits become gnucash splits in the same accounts. And Quicken splits that are associated with a category end up associated with the appropriate account. This resolution seems to specialize properly to the way you handle other transfers and categories. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Problem with transfers/double accounting
I have this problem too. I'm using multi-line mode. Terminology: proto-transaction: a transaction which is being entered in the register window onto a blank transaction, and is still in one line mode (or has one blank split displayed below...). In gnucash 1.3.7, the transfer field is labelled `Transfer From'. Now, I find this label confusing, because it is only right when you receive money, not when you spend it... (talking about a cash account) but, let's keep going. In gnucash 1.3.8, this column is labelled `transfer to'. Entering an account into this column on a one-line proto-transaction causes the transaction to be moved to that account, and to have no connection with the originating account. This breaks the way I usually enter transactions. In version 1.3.7, the first line of a multi-line transaction contained the source account, which is always the one you are in. The other lines displayed the to accounts for the various splits. I found this quite understandable. When the transaction was displayed in one line (while entering the first part), the transfer field represented the destination account of the first split. This was convenient. I must admit that all this would be very difficult to explain to a newcomer, so, if you are trying to clean this up, you are to be commended. However, I don't understand how 1.3.8 is supposed to work, and I've gone back to 1.3.7. Well, it is pretty confusing, so we may just be better off taking it out for 1.4. It actually works exactly the same as in 1.3.7, with the exception that, in multi-line mode, where there used to be a blank space in the transaction line, there is now a field you can use to move the transaction to another account. As before, the transaction line refers to the current account. This is reflected by the fact that this field starts with the current account already filled in. Other than the new field, multi-line mode works exactly as before. No need to take it out for 1.4. Just label it properly. In multiline mode, the title for the 'transfer' column should just be a 'account'. Each line then describes what happens to a specific account, and what could be more natural than to edit the account name to move the entry to another account? But in single-line mode, where the column has a very different meaning, it's just fine to label it 'transfer'. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: missing xml, print; 1.3.7, SuSE
gnome-print is in series gnm: gnprint and gnprintd I added these (yet another) dependencies to SuSE-6.3.txt. (Perhaps we should recommend to buy a new big harddisk and just install the whole 6 CDROMs ;-).) Dave: Please add the attached SuSE-6.3.txt to CVS. Herbert. Thanks. It compiles and runs now. -- hendrik
missing xml, print; 1.3.7, SuSE
When compiling 1.3.7 on SuSE 6.3, it could not find two libraries: xml print When I installed packages libxml (and libxmld too, just in case) from series d, the xml problem went away (although I had to delete the source tree and reuntar it to make it find xml; a make clean didn't work). One or both of these (I don't know which) should be mentioned in doc/SuSE-6.3.txt Does anyone know which package contains the print library?
Re: Libraries
Hmm, how about some kind of install program? I was thinking of doing this as a generic thing on my spare time, but something that checks if certain libraries are installed, and if they are not, wgets them or something similiar and installs them. You might get more newbie users to come over from windows that way. It seems that all the major commercial applications come with all the libraries they need. That's a good idea. If you plan on working on this, you might check out the helix code installer (available at their website at www.helixcode.com) which seems to be pretty good. dave When you install an RPM, the system usually checks which packages you need (provided the packager of the RPM bothered to identify them). Under SuSE, and I presume others, you have the option of having them installed automatically too. Admittedly, the list of packages may be system-dependent; I suspect not all linuxes package everything in the same combinations. But a gnucash package that is included with a distribution will presumably not have library problems. And *that* is, I suspect, how most naive users will get it. -- hendrik.
Re: QIF format ?
Richard Wackerbarth [EMAIL PROTECTED] writes: I am thinking in terms of a "plugin" to reformat the "memo" information into the fields, like cheque number and Payee, which are more appropriate. Could you clarify this last part a bit? Have you observed the QIF memo field to be used in place of the existing QIF check number and payee fields? Thanks, Bill Gribble While we're opn the subkect, my bank puts the transaction date into the memo field on credit card statements. The cleared date is in the date field. ^ M11/1/99 D11/4/99 PCOMMUNICATIONS ACCESSI MONTREAL PQ T-40.20 N ^ Also, note the placement of foreign currency amounts in the P line. (for me, US is foreign, and Canadian is domestic). ^ M11/7/99 D11/8/99 PANNABELLE`S BAR + BISTRO SAN FRANCISCO CA US AMT = 30.44US T-45.46 N ^ Some kind of scripting seems appropriate. But maybe I should just use a Perl script befire importing? -- hendrik.
Re: gnucash 1.3.7 bugs.
Randolph Fritz [EMAIL PROTECTED] writes: Could someone tell me, please, the historical background of this odd use of language? If it's already been discussed, then please point me to the archives. When you make a deposit in a bank account, the bank OWES YOU money. You become a "creditor" and the bank is a "debtor", just as if you had loaned the bank money. Which you have. A "credit" is a "payment by a debtor on an amount due" by both common sense and accounting practice. Therefore, a withdrawal of money from the bank, which reduces the balance of the account and therefore the amount that the bank owes you, is a "credit". A "debit" is etymologically a "debt", i.e. an increase in the amount owed by a debtor, again in both common sense and accounting practice. Therefore, a deposit of money into the bank, which is an increase in the balance of the account and of the amount of money that the bank owes you, is a "debit". I had to have this explained to me a million times but now it makes perfect sense and I can't even think of a withdrawal being a "debit" any more (how's that? I don't owe the bank any money!) Let's see if I understand this now. Does this mean that if I overdraw my chequing account, and subsequently deposit $16.74 to cancel the overdraft, that the $16.74 is a credit, because I owed the bank money? And if I subsequently deposit $15.75 to make the balance positive, the $15.75 is a debit, because it establishes the bank's debt to me? -- hendrik. Bill Gribble
debits and credits WAS: gnucash 1.3.7 bugs.
Randolph Fritz [EMAIL PROTECTED] writes: Could someone tell me, please, the historical background of this odd use of language? If it's already been discussed, then please point me to the archives. Bill, Let me make another try to understand this. In a previous posting you (I believe?) said that the reason terminology had become so confused was that peoples bank statements were produced from the bank's point of view, instead of the client's point of view. So clients who did not understand this (i.e., most people) ended up with an exactly reversed meaning for the words "credit" and "debit". But you posting I am quoting below seems to completely ognore the point-of view issue. Let me try to weave my confusion it into the text and see if it makes sense. Or should I just find a good book on accounting? When you make a deposit in a bank account, the bank OWES YOU money. You become a "creditor" and the bank is a "debtor", just as if you had loaned the bank money. Which you have. So the points-of-view are that of a "creditor" and a "debtor". A "credit" is a "payment by a debtor on an amount due" by both common sense and accounting practice. Therefore, a withdrawal of money from the bank, which reduces the balance of the account and therefore the amount that the bank owes you, is a "credit". Is point of view relevant here? Is this a credit from the bank's point of view and a debit from yours? Or is it a credit from any point of view? A "debit" is etymologically a "debt", i.e. an increase in the amount owed by a debtor, again in both common sense and accounting practice. Therefore, a deposit of money into the bank, which is an increase in the balance of the account and of the amount of money that the bank owes you, is a "debit". And is this a debit from the bank's point of view and a credit from yours? Because you now have an increased assets, and the bank has reduced assets? Or is the terminology independent of point of view? I had to have this explained to me a million times but now it makes perfect sense and I can't even think of a withdrawal being a "debit" any more (how's that? I don't owe the bank any money!) Bill Gribble -- hendrik.
Re: gnucash 1.3.7 bugs.
How about, as a first step, we make the reconcile window be configurable to use, e.g., 'Funds In' and 'Funds Out' instead of debit/credit as you suggest? Something like that is probably necessary. Gnucash looks to me like one of the crucial tools that will get Linux onto desktops everywhere. But that's going to be a lot harder if "normal" users find the interface confusing. I think it's more important for people to be able to handle their finances without getting confused or worrying about getting things wrong than having the technically correct terminology. What we *have* to avoid is using the technically correct terminology with an incorrect meaning. An option for using informal language is perfectly OK by me, as long as the informality does not consist of using correct words with incorrect meanings.
Re: on-line banking qif import
On Sat, 13 May 2000, Hendrik Boom wrote: On Fri, 12 May 2000, Hendrik Boom wrote: As for changing "reconciled" transactions, it is unclear to me what relationship exists between the "transaction" and the "JEs". It is the JEs that get reconciled. Right. But to what does the "Payee" belong? I presume whoever you wrote the cheque out to. I think that you missed by point. My question was "With respect to reconciliation, when is the 'payee' field considered to be reconciled?" I guess I missed your point because I don't understand what it means to reconcile a 'payee' field. Remember that a "transaction" has to be reconciled multiple times, once for each of the JE splits that make up the transaction.
Re: on-line banking qif import
On Fri, 12 May 2000, Hendrik Boom wrote: As for changing "reconciled" transactions, it is unclear to me what relationship exists between the "transaction" and the "JEs". It is the JEs that get reconciled. Right. But to what does the "Payee" belong? I presume whoever you wrote the cheque out to. Payees are not necessarily in one-to-one correspondence with the accounts at the other ends of transactions. (a) The payee might be the name of an agent for whomever you are paying. (b) the other account might be more like a Quicken category than a payee, perhaps "Automobile expense" instead of "Jim's gas station". I occasionally do change the date when I find the date on which I actually wrote the cheque (the bank only gives cleared dates). Which brings us to a slight problem. For tax purposes, I must use the date written. That can make it difficult to match up with the file from the bank. Do we need to store both a transaction date and the posted date? I thought we already did store both dates. -- hendrik.
Re: on-line banking qif import
On Thu, 11 May 2000, Hendrik Boom wrote: In general, I think that we must assume no correlation between importing data and reconciliation. All that we know is that each entry imported from the bank must appear in the ledger and that it has cleared the bank. A JE must progress through the following "reconciliation states" 1) Entered 2) Cleared 3) Candidate 4) Reconciled That's right. Only I like to add a note to each candidate and reconciled transaction to pair it I'm not sure that I would allow you to alter the entry while it is "reconciled". However, I would assume that you are happy to do it in the "candidate" state. With Quicken, I often change reconciled entries. Wjat I never do is change the amounts. It's not umusual for me to find out more information about an entry after it is cleared and reconciled (for example, who it was really paid to, when I finally find my chequebook at the back of the kitchen utensil drawer. I wonder how it gets there??)
Re: on-line banking qif import
As for changing "reconciled" transactions, it is unclear to me what relationship exists between the "transaction" and the "JEs". It is the JEs that get reconciled. Each JE would get reconciled separately. Therefore you could have a transaction transferring funds from one account to another with one entry reconciled and the other still pending. Changing the "Payee" would not affect the JEs. However, changing the date could. I occasionally do change the date when I find the date on which I actually wrote the cheque (the bank only gives cleared dates). However, in Gnucash, this would probably not be necessary -- I would merely be providing extra information when I find the chequebook.
Re: Order of transactions
I'm not sure how it works in Quicken. I was referring to just sorting by the date of entry, not changing it. But now that I think of it, if we switch to sorting by the date of entry, we could go ahead and show the date of entry in the left column instead of the 'real' date typed in, and allow the user to edit that. Any thoughts about that? Unfortunately, if you happen to edit the date-typed-in by mistake, there is no way of finding the error by looking for recently entered (or recently changed) transactions. Also, if the date-changed is to be used for audit, it won't be much use if it is easy to change. Also, it we are to be doing audits, it would be useful to retain the old transactions after a change -- not so that they would be actively displayed and added into totals and such, but that they could be found and used to check whether the change was correct (or, possibly, to restore the old version if the change were wrong). Also, if we are going to be doing all this, we should record the name of the person making the change. In Linux, would a numerical user-id be sufficient? -- hendrik.
Re: on-line banking qif import
On Tue, May 09, 2000 at 12:50:09AM -0500, Linas Vepstas wrote: I was talking to someone about on-line banking gnucash. I hadn't thought about ti much, but a large part of on-line banking is reconciling statements against what the bank has. Now, many 'online banks' use QIF export as a way of sending statements to users. Sooo (sound of lightbulb turning on) isn't the right way to import QIF files is to run them through a reconcile-like dialogue? Anyone out there using gnucash and also looking at thier bank-staements on-line? What do y'all think? Last time I looked, my bank's qif imports give me all the transactions since the last statement, not since the last qif import. If gnucash were to remember the complete text of the qif-version of the transactions, it could easily and reliably eliminate duplicate qif-transactions. Matching them with the manually entered ones should not be automatic -- except, of course if gnucash recognizes that a new qif transaction is identical to a previously matched qif-transaction. Reconciling with monthly bank statements is a separate issue, because monthly bank statements (a) do not repeat transactions, and (b) are a separate sequence of consistent data from the downloads. Maybe some users do download consistent, non-verlapping batches of qif transactions. They should then be reconcilable independently from paper statements. That's exactly what I am currently doing manually, once a week. My Credit Union can provide transaction records in QIF format, but there doesn't seem to be a good way to use them with GnuCash. One of the things I like about this combination of services is the amount of work it saves; errors are caught early, and there is no need to laboriously drag through a month or more of transactions to unsnarl mistakes. -- Randolph Fritz Eugene, Oregon, USA
Re: on-line banking qif import
In general, I think that we must assume no correlation between importing data and reconciliation. All that we know is that each entry imported from the bank must appear in the ledger and that it has cleared the bank. A JE must progress through the following "reconciliation states" 1) Entered 2) Cleared 3) Candidate 4) Reconciled That's right. Only I like to add a note to each candidate and reconciled transaction to pair it off with a specific line on the bank statement. My credit card statements contain line numbers, and i use them in the ledger to establish a one-to-one correspondence. The act of reconciliation is that of selecting candidates so that they match the statement to which they are being reconciled. When it is complete, the "commit" operation moves all the candidates to the reconciled state. From a user's POV, it is convenient to be able to invoke a function which moves all "Cleared" entries to the "Candidate" state if they are on or before the closing date of the statement. The user can then manually select exceptions. Except that when I reconcile, I match up the transactiuons with the statement one at a time and check them off on the paper statement. If I Converted I would lose track of which lines on the paper statement had been matched. I don't think that it is necessary to attempt to remember the complete text. Transaction(cheque) identifier(number) and amount should be adequate to identify most transactions once they have been matched the first time. Except a lot of the transactions I get don't have meaningful numbers on the bank statement -- whether .qif or paper. -- hendrik.
Re: question: What is a JE?
[Charset iso-8859-1 unsupported, filtering to ASCII...] -Original Message- From: Richard Wackerbarth [mailto:[EMAIL PROTECTED]] Sent: Thursday, May 11, 2000 12:33 PM To: Herbert Thoma; [EMAIL PROTECTED] Subject: Re: question: What is a JE? On Thu, 11 May 2000, Herbert Thoma wrote: ... A JE must progress through the following "reconciliation states" ... I read it several times now, what does JE mean??? Sorry for the shorthand. JE==Journal Entry. It'll cause less confusion, but won't eliminate it. I tend to think of "Journal Entries" as being like GnuCash "transactions" (i.e., a collection of splits that are related and balance). The splits themselves I tend to think of as "Ledger Entries", since they correspond to an individual entry in a ledger book. Maybe "Ledger Entry", abbreviated "LE", would be a better term. - hendrik
Re: multiple currencies
Christopher Browne wrote: My inclination (which is somewhat educated in the matter :-)) is to have the register report _Cost._ Cost does not change over time, and since it tends to reflect cash changing hands, it is _fairly_ objective. I agree. But I think that the engine does not work this way, although I don't know the engine well enough to be sure. I think the engine works this way: It has a balance of total shares and the most recent price per share. The reported balance then gets total_shares x price_per_share. To do it right we may have to change the engine and the stock register. All those who know the engine better, please comment. It sounds to me that when the balance changes because of price changes, this needs to be realized by a transaction, which, of course, needs to be balanced by an entry into some kind of unrealized capital gains account. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: Dividends
So GnuCash definetly needs a currencies conversion. For EURO, we can hardcode a fixed table of all "Euro currencies" since they are NOT supposed to evolve. For the other, we can have a table updated by the user (and automagically by gnc-prices). I woudn't rely on fixed exchange rates until the old national currencies are so obsolete that no one uses them any more. Since the fixed exchange rates were defined by politics, they can be changed by politics, no matter how permanent the politicians say they are. We still need a solution to the general problem of (variable) exchange rates. If we have one, it should handle the euro automagically. If we don't, we'll still need to build one, and then special effort on the euro will have been wasted. Is there something I don't understand here? -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: budgets Was: quicken migration
Hendrik Boom [EMAIL PROTECTED] writes: P.S. Maybe some thing this perverse, but I enjoy the practice we seem to have of quoting the entire discussion in each message. It's certainly not a practice all of us have (or like). When I wrote the P.S., I thought " Everyone will probably think I am being sarcastic, but I'm not." In retrospect, I probably was being sarcastic and didn't realize it because I was tired. What's really needed is not massive quoting (quadratic bandwidth usage), but a way to reconcile multiple partially quoted partially edited messages so that you can, if you choose, see the entire conversation history easily. But that's probably not a problem for gnucash to solve. -- hendrik. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: quicken migration
Hello. Just wondering what the consensus is for migrating savings goal accounts. One idea I have I'm not clear what a savings goal account is, but it sounds like a budgeting issue. Does it make sense to represent budgets as accounts? -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: budgets Was: quicken migration
What I've always wanted was a way to relate each transaction to the budget category and period it belongs to. So if I put off paying a bill for a few months (maybe there's a dispute as to the correct amount or something), when I finally do pay it it sould count against the budget period it logically belonged to, not the one in which the payment finally occurred. And it would be wrong to say I had managed to go $1000 under budget simply because I postponed paging a large bill. There would seem to be a planned envelope of spending for each budget period, estimates of committed spemding (which ought to fit within the spending envelope), and actual spending when the cheque is in the mail. I'd like some mechanism that keeps track of all this gracefully. But a savings-goal subaccount is a lovely stopgaps to make one feel worried at the right moments about the big picture. -- hendrik. P.S. Maybe some thing this perverse, but I enjoy the practice we seem to have of quoting the entire discussion in each message. It provides a really convenient, printable summary. And I can delete old messages that have been followed up on so as not to fill up the 20gig hard disk I've just ordered :-). Well, it's not quite perfect; sometimes there are several replies ot one message. :-( Of course, what I suggested in the last message could probably be simply accounted for by having the budgeting module automatically put a Budgeting Balance transaction, similar to an Opening Balance transaction into every Expense and Income account. The Budgeting Balance would be adjusted every day to account for the increased money allowed for spending. This transaction could be turned on or off by a user interface switch. -Patrick On Thu, 30 Mar 2000, Bryan Larsen wrote: On Thu, 30 Mar 2000, Patrick Baker wrote: Expenditures are *discrete* events. I do not see the difference betweeen your "velocity of money" approach and Quicken/MSMoney's approaches. The only difference is that your base time period is much smaller (1 day rather than 1 month). Over the long term, your approach works, but in the short term it falls down. The reason I was thinking more about this approach than a report scenario is because I don't tend to do a budget reconciliation at a particular time of year. I would like more of a continuous approach, and thus took the logical extreme in considering a velocity rather than looking at discrete transactions. I admit that it's a unfamiliar way of looking at things, and if it is not obvious to most then it should not be implemented. Mine's not all that familiar either. I also was thinking about my approach because it's nice to have the expense accounts show how much you're allowed to spend at a particular moment in time, rather than the amount already spent from an aribitrary date when you started keeping track. That's exactly what I want. From my example: if the budget report says that a line item has a lower limit of $18 and an upper limit of $36, and an actual of $14, that means I can blow $4 on anything, and $18 on the line item. Integrating budgeting with accounts then allows you to do things like transfer money between budget accounts if you want to cut back on something in order to do something else. -Patrick Baker In the budget realm, that's simply called adjusting your budget. I've never used the Quicken virtual savings accounts, though. Bryan With my prototype budget report, you can ask it for a budget report for any arbitrary period, and it will give you a real answer on whether you are spending too much or too little. For example, it knows that you are paid on the 1st of the month, or on a Friday every 2 weeks. If you have a 17 day budget report that encompasses two pay periods, there should be 2*pay in your budget, not 17*pay/14. Other expenses occur fairly regularly, but not on a known date. I fill up my car for $18 approximately every 6 weeks (gotta love diesels). If I ask for a report for the last 9 weeks, there should be either 1 or 2 fill ups, not 1.5 fill ups, so $18 is under budget and $36 is over budget. It's still possible to trick the system. For example, a 5.9 week report would consider $36 over budget. No big deal -- you know your tank is full, so you aren't worried. Conversely, a 6.1 week report where you didn't spend anything on fuel, but your tank is empty. Extraordinary/contingency expenses are handled very similarly, but are handled slightly differently. If you set up the above diesel expense as a contingency instead, a 9 week budget report would have a lower limit of $9 and an upper limit of $45. ($18/6 * 9 +/- $18) The idea is that you can be hit with
QIF import *and* save/load trouble
Hendrik Boom [EMAIL PROTECTED] writes: However, transactions which in Quicken had been reconciled in only one account show up as reconciled in both accounts. This is wrong, but I can probably track then down by hand and hand-edit them. That's definitely a bug... I wasn't thinking straight when I added the reconcile handling. It looks as if tracking them down and hand-editing won't be very useful -- as described below, reconciliation status does not appear to be conserved during save-restore. Just to be clear, I'm running version 1.3.3, downloaded as gnucash-1.3.3.tar.gz and compiled under SuSE Linux. No patches have been applied. You mentioned that Opening Balance transactions are still duplicated? Can you explain the situation before and after the import wrt Opening Balance? Before the imports, there is *nothing* in the register. After, there are two Opening Balance transactions: 7/31/1992Opening Balance chequing n 13,433.91-17,475.43 7/31/1992Opening Balance chequing n-13,433.91 -17,475.43 And here's an extrace from the .qif file: ^ D7/26/92 T-1,110.12 CX N221 PScotiabank Visa (prof) ^ D7/31/92 T13,433.91 CX POpening Balance L[Checking] ^ D8/ 2/92 T-400.00 CX PCash, Royal Bank ^ The opening balance, by the way, is *not* the first transaction in the account. There is, however, another entry ^ D12/ 1/92 T-107.36 CX POpening Balance Adjustment Ladjustment ^ which I must have put in by hand for some reason some time. But it's probably not relevant, and show up properly, just once, in ther register. I'm also a little puzzled by the 'R' column. Last night I had both reconciled and nonreconciled entries. After saving last night and reloading this morning, they have all turned into "n"'s. (Including the incorrect 'r' entries I mentioned in my previous letter. Also, jump no longer works to get to the other end of transfers. The UI accepts the menu item, the menu disappears, and then nothing noticable happens. It looks as if something has gone wrong during save-restore. I'm actually treating an Opening Balance transaction as a real transaction from an Equity account (by default) into the target. Some programs uses the OB as just a trick to get an account name in the file, and it's a transfer from the account to itself. Literally interpreting this results in a zero opening balance. My opening balance entry is there to establish an opening balance. 'Jump" gets me nowhere from either 'Opening Balance' line. However (surprise), from 'Opening Balance Adjustment', 'Jump' *does* get me to the account for the 'adjustment' category. I tried a few other transactions. It looks as if jump works to and from accounts created from Quicken categories, but not to accounts created from Quicken accounts. This behaviour is different from that before the save/restore. Do banks put Opening Balance transactions in incremental downloads just to identify the account? If so, I'll end up putting multiple real transfers of money into the account where they shouldn't be. I don't know about banks. The .qif files I am dealint with were saved by an old DOS version of Quicken on December 31, 1999, just before Y2K. b.g. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: QIF import (fwd)
Somehow I failed to notice the separation between the two mappings: file-name onto Quicken account name Quicken account name to gnucash account name Maybe it would help to emphasize these two mapping in the documentation or in the UI. How would you suggest that the UI change to make this clearer? The right half of the Files tab is intended to capture information globally relevant to a selected QIF file, including the Quicken account it references, and the Accounts and Categories tabs are intended to specify the mappings from Quicken accounts/categories to Gnucash accounts. I came up with a few ideas, but when I tried importing again today (successfully) I noticed that the import dialogue already had them. So I'll definitely have to think about it some more. Thanks, Bill Gribble -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED] -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: i18n and check printing and Europe (fwd)
I passed the number formatting problem on to a friend of mine who happens to be a linguist as well as a computer hacker. (there I go again, using a word in an older, this time respectable, meaning) He replied as follows: -- hendrik - Forwarded message from stephen p spackman - From [EMAIL PROTECTED] Wed Mar 22 15:35:40 2000 Message-ID: [EMAIL PROTECTED] Date: Wed, 22 Mar 2000 15:48:42 -0500 From: stephen p spackman [EMAIL PROTECTED] Organization: pooq.com X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en-GB,en,fr,de To: Hendrik Boom [EMAIL PROTECTED] Subject: Re: i18n and check printing and Europe (fwd) References: [EMAIL PROTECTED] [Hendrik: forward to the group if you deem appropriate] Even in English we have, in many dialects, "five hundreds of dollars" (as opposed to "five hundred dollars") not to mention "threescore dollars and twelve". I believe my grandfather wrote "Seventy-Five Pounds and 26/100", but "Seventy-Five Pounds Only"; yet "One Hundred Pounds Exactly". French (in France and Quebec) expresses 71 as 60+11 and 91 as 4*20+11, of course. Other variants of French have words for 70 and 90. And it is of not to be forgotten that the U.S. "one hundred ten" is "one hundred and ten" for the rest of us. Evidently european languages differ in whether a milliard is more or less than a million. Britain is currently in flux as to whether a billion is a thousand million (following the U.S. and the "billionaire's" ego) or a million million (following tradition, logic, and the rest of the world). Fortunately the thousand million/million million formulations themselves are unambiguous and acceptable. There also seem to be variants of English that use milliard and billiard; I don't know where these are spoken, though. It gets worse: some languages - I think Japanese among them, could be wrong - use different number series for counting different things (much as eggs come in dozens and shoes come in pairs, but much, much worse), so if you care about more than just dollar values on cheques there are. You might need to worry about gender agreements as well. The moral: you need a methodology before you start making tables. The tables need to be editable, and they need to take the form of ordered rules with number theoretical guards on the left and grammatical productions on the right. Attribute grammars for maths. In the following, (x ! y) is (x - x % y); ~0 means "nonzero"; $ is the quantity we're encoding. An empty lhs matches anything. We use e3 etc. as an abbreviation for 1000. Sorry for all the _notation_ being ad hoc; I've already spent too long thinking about the content :-). -- one variant of english eng.UK.centAmount: 0: nothing ~0 % 100: [dollarAmount $ / 100] and [number $ % 100] cents ~0 % e4: [dollarAmount $ / 100] only : [dollarAmount $ / 100] exactly eng.UK.dollarAmount: 0: no dollars 1: one dollar : [number $] dollars eng.UK.number: 0: zero 1: one 2: two 3: three 4: four 5: five 6: six 7: seven 8: eight 9: nine 10: ten 11: eleven 12: twelve 13: thirteen 15: fifteen 20: [$ % 10]teen 20: twenty 30: thirty 40: forty 50: fifty 100 0%10: [$/10]ty 100: [$ ! 10]-[$ % 10] ~0 % 100: [$ ! 100] and [$ % 100] e3: [$ / 100] hundred ~0 % e3: [$ ! e3] [$ % e3] e6: [$ / e3] thousand ~0 % e6: [$ ! e6] [$ % e6] : [big(million) $ / e6] eng.UK.big($1): e6: [number $] $1 ~0 % e6: [big(million $1) $ / e6] [$ % e6] : [big(million $1) $ / e6] -- e.g. [centAmount 1234567890123456789044] [dollarAmount 12345678901234567890] and [number 44] cents [number 12345678901234567890] dollars and [number 40]-[number 4] cents [number 12345678901234567800] and [number 90] dollars and forty-four cents [number 12345678901234567000] [number 8] hundred and [number 9]ty dollars... [number 1234567890123400] [number 567] thousand eight hundred and ninety ... [big(million) 12345678901234] [number 500] and [number 67] thousand eight ... [big(million million) 12345678] [big(million) 901234] [number 5] hundred and [number 60]-[number 7] thousand ... [big(million million million) 12] [big(million million) 345678] [number 901234] million five hundred and [number 6]ty-seven thousand ... [number 12] million million million [number 345678] million million [number 901200] and [number 34] million five hundred and sixty-seven thousand ... twelve million million million [number 345600] and [number 78] million million [number 901000] [number 200] and [number 30]-[number 4] million five ... twelve million million million [number 345000] [number 600] and [number 70]-[number 8] million million [number 901] thousand [number 2] hundred and thirty-four million five ... twelve million million million [number 345] thousand [number 6] hundred and [number 7]ty-eight million million [number 900] and [number 1] thousand two hundred ... twelve million million million [n
Re: QIF import (fwd)
A few more details about the transaction(s?) in my previous note: For example, the register for account "chequing" now contains (in multiline mode): 11/23/1998 nettransfer to visa r 1,000.00 450,788.03 33038681 visa - personal1,000.00 and a few lines later, 11/23/1998 ov013 transfer to visa n 1,000.00 452,288. 33038681 visa - personal1,000.00 For the record, here ate the qif entries for this transaction in the qif files. First, in the file "chq": ^ D11/23/98 T-1,000.00 CX Nnet Ptransfer to visa M33038681 L[visa - personal] ^ And in the file "visapers.old" ^ D11/23/98 T1,000.00 Nov013 Ptransfer to visa M33038681 L[Checking] ^ When I used the "Accounts" tab in the import dialog, I informed it that accounts "chq" and "Checking" were to be the gnucash account "chequing", and that "visapers" and "visa - personal" were to be "visa - personal". Does this help you to duplicate the problem? -- hendrik -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: i18n and check printing and Europe (fwd), Re: i18n and check printingand Europe (fwd)
Even in English we have, in many dialects, "five hundreds of dollars" (as opposed to "five hundred dollars") not to mention "threescore dollars and twelve". I believe my grandfather wrote "Seventy-Five Pounds and 26/100", but "Seventy-Five Pounds Only"; yet "One Hundred Pounds Exactly". Bear in mind here that we don't need to be able to parse all of the possible valid constructions in a given language, we just need to be able to output *one* valid construction for each language, which is a much simpler problem. Yes, parsing is harder than determinstic generation. But: Some constructions are allowable in English (but not mandatory). Such constructions are within the gamut of the language center of the human brain. Virtually any natural-language syntactic construction that can be processed by the human brain turns out to be mandatory in some language, somewhere. Indeed, given the thousands of languages of astonishing variability that exist, it would be astonishing if this were not so. So chances are that some language or culture, somewhere, will require a construction like this. If our formalism for describing number notations can handle it, people will be able to do their own linguistic customization. (and contribute the results to our internationalization library, natch). Whether we want to do all this now, instead of just letting everyone program their own number code in Scheme, is another matter, or course. But Stephen's ad-hoc notation may indicate regularities that could simplify our code in the long run. -- Rob Browning [EMAIL PROTECTED] PGP=E80E0D04F521A094 532B97F5D64E3930 -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
Re: duplicate transactions
Well, I got gnucash 3.6.2 running on SuSE Linux 6.3. You mean gnucash 1.3.2? Yes. Stupid typo. When I import my entire financial state from a set of Quicken exports (one for each account, natch), all the transfers from one account to another get duplicated. A transfer is physically present in the .qif files of both the "from" and the "to" account; presumably the duplication is a simple-mided consequence of this. When the transfer has been reconciled in one account but not the other, one of the two resulting transactions is reconciled; the other is not. What I would want is one transaction which is reconciled at one end only. The obvious workaround is to delete one of the two transactions, but then I also have to get a way of unreconciling one end or reconciling the other end of each such transaction. Is there an easy way of accomplishing this edit? And I have about six years' worth of data to convert -- maybe three of four hundred transfers altogether. It's hard to imagine editing it all correctly by hand. It seems there should be a more elegant way to handle this, perhaps with special handling of imports. I suspect that a transfer should be considered to be a duplicate if there is already another transaction bearing the same date and amount and bank accounts (and such pairs must be paired off during inporting so that if you see four of them you still end up with two). I do not know where to even start looking in the source code to do something about it. Any suggestions? Or am I missing something obvious? There is a new qif importer in gnucash 1.3.3 which allows you to import multiple qif files at once. You might try that. It appeared a day or so ago while I was hacking 1.3.2. Thanks, I will. Where is the code that checks for duplicate transactions during import? I suspect my problem may be that Quicken does not force identity across transfers for some details (such as cheque number) that gnucash compares. If I were to patch gnucash (even temporarily, for just one run) to ignore cheque numbers and memos and such for transfers between bank, credit, and cash accounts (but not for income or expense accounts) my data would likely import flawlessly. The obvious place to make the changes in xaccSplitMatch or xaccTransMatch, but I can't seem to find how they are called from QIFIO or gc-import-qifs. Am I still missing something here? (actually, I tried changing some of the scheme code as a first step, to get it to write out the list of transactions as one humongous S-expression (so that I might examine it by other means) but my changes seem to have no effect whatsoever. Evidently there's something I still don't know about Scheme or about the Makefiles.) What scheme code did you change? the function gnc:import-file-into-account-group in gc-import-qifs. I now gather from a doc file that qif imports may still be done in QIFIO.c and not yet in Scheme. Is this still true? If so, I expect that editing gc-import-qifs can be expected to have no effect. Is there an easy way to (a) uninstall? No, not with the current build system. But if I make an gnucash RPM for SuSE I might be able to uninstall that. (b) build an RPM? Have you built one before? The gnucash.spec file in the rpm directory is what I have used. Thanks. No, I haven't. It looks as if I have some reading to do. dave
duplicate transactions
(revised message -- yesterday's version bounced) Well, I got gnucash 3.6.2 running on SuSE Linux 6.3. When I import my entire financial state from a set of Quicken exports (one for each account, natch), all the transfers from one account to another get duplicated. A transfer is physically present in the .qif files of both the "from" and the "to" account; presumably the duplication is a simple-mided consequence of this. When the transfer has been reconciled in one account but not the other, one of the two resulting transactions is reconciled; the other is not. What I would want is one transaction which is reconciled at one end only. The obvious workaround is to delete one of the two transactions, but then I also have to get a way of unreconciling one end or reconciling the other end of each such transaction. Is there an easy way of accomplishing this edit? And I have about six years' worth of data to convert -- maybe three of four hundred transfers altogether. It's hard to imagine editing it all correctly by hand. It seems there should be a more elegant way to handle this, perhaps with special handling of imports. I suspect that a transfer should be considered to be a duplicate if there is already another transaction bearing the same date and amount and bank accounts (and such pairs must be paired off during inporting so that if you see four of them you still end up with two). I do not know where to even start looking in the source code to do something about it. Any suggestions? Or am I missing something obvious? (actually, I tried changing some of the scheme code as a first step, to get it to write out the list of transactions as one humongous S-expression (so that I might examine it by other means) but my changes seem to have no effect whatsoever. Evidently there's something I still don't know about Scheme or about the Makefiles.) Is there any way to mass-import a whole directory full of .qif files? Or do I have to do it one at a time? Is there an easy way to (a) uninstall? (b) build an RPM? The crucial desideratum for either of these is the list of installed files. -- hendrik.
Re: installung gnucash-1.3.0 on SuSE-6.3
Hendrik Boom wrote: Since you seem to have succeeded in your installation, you presumably have the missing file. Have I left out something from my SuSE that would explain this problem? Yes, you need to install the gettext package, which is in the d series, I think. This helped. It now gets past the ./configure. Unfortunately, now the make gnome fails. Mresumably I'm missing snother useful package, the one containing various include files whose names start starting with "gdk_". The tail end of the installation log follows. These initials sound familiar, but I can't quite place them. Can you tell me where to find these? And, to save some email, do you know of any handy way to search the SuSE disks for packages that contains specific files that are *not* installed? One additional hint: You may need to run gnucash once as root, so that guile can set up a catalog for slib. Didn't quite get this far. -- hendrik. ... ... ... make[3]: Entering directory `/home/hendrik/cash/expand/gnucash-1.3.0/src' gcc -Wp,-MD,obj/gnome/MultiLedger.d.tmp -c -g -O2 -I/usr/X11R6/include -I. -I.. -I./engine -I./register -Ireports -I./../include -I/usr/local/include -pg -I./gnome -I/opt/gnome/include -DNEED_GNOMESUPPORT_H -I/opt/gnome/lib/gnome-libs/include -I/usr/X11R6/include -I/usr/lib/glib/include -DGNOME -o obj/gnome/MultiLedger.o MultiLedger.c In file included from register/table-gnome.h:33, from register/table-allgui.h:103, from register/splitreg.h:54, from MultiLedger.h:31, from MultiLedger.c:30: /opt/gnome/include/gnome.h:7: gdk_imlib.h: No such file or directory In file included from /opt/gnome/include/libgnomeui/libgnomeui.h:10, from /opt/gnome/include/gnome.h:9, from register/table-gnome.h:33, from register/table-allgui.h:103, from register/splitreg.h:54, from MultiLedger.h:31, from MultiLedger.c:30: /opt/gnome/include/libgnomeui/gnome-animator.h:28: gdk_imlib.h: No such file or directory In file included from /opt/gnome/include/libgnomeui/gnome-animator.h:30, from /opt/gnome/include/libgnomeui/libgnomeui.h:10, from /opt/gnome/include/gnome.h:9, from register/table-gnome.h:33, from register/table-allgui.h:103, from register/splitreg.h:54, from MultiLedger.h:31, from MultiLedger.c:30: /opt/gnome/include/libgnomeui/gnome-pixmap.h:7: gdk_imlib.h: No such file or directory In file included from /opt/gnome/include/libgnomeui/libgnomeui.h:19, from /opt/gnome/include/gnome.h:9, from register/table-gnome.h:33, from register/table-allgui.h:103, from register/splitreg.h:54, from MultiLedger.h:31, from MultiLedger.c:30: /opt/gnome/include/libgnomeui/gnome-canvas-image.h:16: gdk_imlib.h: No such file or directory In file included from /opt/gnome/include/libgnomeui/libgnomeui.h:21, from /opt/gnome/include/gnome.h:9, from register/table-gnome.h:33, from register/table-allgui.h:103, from register/splitreg.h:54, from MultiLedger.h:31, from MultiLedger.c:30: /opt/gnome/include/libgnomeui/gnome-canvas-load.h:5: gdk_imlib.h: No such file or directory In file included from /opt/gnome/include/libgnomeui/libgnomeui.h:27, from /opt/gnome/include/gnome.h:9, from register/table-gnome.h:33, from register/table-allgui.h:103, from register/splitreg.h:54, from MultiLedger.h:31, from MultiLedger.c:30: /opt/gnome/include/libgnomeui/gnome-color-picker.h:13: gdk_imlib.h: No such file or directory In file included from /opt/gnome/include/libgnomeui/libgnomeui.h:51, from /opt/gnome/include/gnome.h:9, from register/table-gnome.h:33, from register/table-allgui.h:103, from register/splitreg.h:54, from MultiLedger.h:31, from MultiLedger.c:30: /opt/gnome/include/libgnomeui/gnome-icon-list.h:15: gdk_imlib.h: No such file or directory In file included from /opt/gnome/include/libgnomeui/libgnomeui.h:106, from /opt/gnome/include/gnome.h:9, from register/table-gnome.h:33, from register/table-allgui.h:103, from register/splitreg.h:54, from MultiLedger.h:31, from MultiLedger.c:30: /opt/gnome/include/libgnomeui/gnome-druid-page-start.h:23: gdk_imlib.h: No such file or directory In file included from /opt/gnome/include/libgnomeui/libgnomeui.h:107, from /opt/gnome/include/gnome.h:9, from register/table-
Re: installung gnucash-1.3.0 on SuSE-6.3
This helped. It now gets past the ./configure. Unfortunately, now the make gnome fails. Mresumably I'm missing snother useful package, the one containing various include files whose names start starting with "gdk_". The tail end of the installation log follows. These initials sound familiar, but I can't quite place them. Can you tell me where to find these? And, to save some email, do you know of any handy way to search the SuSE disks for packages that contains specific files that are *not* installed? Thanks for the hints. The package I wanted turned out to be imlibdev. Please mention *this* in the README.SuSE, too. Now it is running nicely, except that importing quicken files seems to be *awfully* slow. It looks as if the program crashes, but come back after doing the laundry, and, lo, the import has finished. I guess I only have to do this once. loacing ans saving are fast enough, though. One additional hint: You may need to run gnucash once as root, so that guile can set up a catalog for slib. I guess I have to find out about guile to know what this means. Just doing it worked fine, though. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
installung gnucash-1.3.0 on SuSE-6.3
I tried installing gnucash-1.3.0 on SuSE-6.3 using the version of your instructions distributed with gnucash-1.3.2 (it describes the installation of 1.3.0). Unfortunately I encountered a missing file error during the ./configure step: creating po/extract-macros.perl creating include/messages_i18n.h creating lib/Makefile creating lib/Xbae-4.6.2-linas/Makefile creating lib/Xbae-4.6.2-linas/src/Makefile creating lib/ComboBox-1.33/Makefile creating config.h linking ./intl/libgettext.h to intl/libintl.h configure: error: ./intl/libgettext.h: File not found hendrik@topoi:~/cash/expand/gnucash-1.3.0 Since you seem to have succeeded in your installation, you presumably have the missing file. Have I left out something from my SuSE that would explain this problem? -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
