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 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 Thu, Mar 21, 2013 at 02:56:04PM -0400, Buddha Buck wrote: > On Thu, Mar 21, 2013 at 2:31 PM, Hendrik Boom wrote: > > > 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: 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: 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: > 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 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 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
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: 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: 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: 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
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: 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
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: 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 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 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
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
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 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: 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 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 Wed, 30 Nov 2011 21:13:58 +, Yawar Amin wrote: > Hi Hendrik, > > On Wed, Nov 30, 2011 at 8:06 PM, Hendrik Boom > wrote: > >> [...] >> >> 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? >> >> > 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, because when I run svn checkout http://svn.gnucash.org/trac/browser/gnucash-docs gnucash-docs it tells me svn: The OPTIONS response did not include the requested activity- collection-set; this often means that the URL is not WebDAV-enabled Ah! I see. This is where it's all been processed and presented as nice, neat web pages. What's the verbiage I need to get the user-documentation source tree? Or is that in some corner of gnucash source tree I haven't looked yet? -- hendrik -- 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
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
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
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
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: 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: 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):
>
> < ..< <>
> <>
> ..>>
>>>
>>>
> 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: Reporting system and potentially Python
On Tue, Nov 15, 2011 at 04:16:10PM -0500, Yawar Amin wrote: > Hi Hendrik, > > On Tue, Nov 15, 2011 at 8:30 AM, Hendrik Boom wrote: > > > [...] > > One of the hallmarks of Scheme is its metaprogrammability, for > > applications just like this. And its simple syntax promotes this. > > > > I've started writing a proof-of-concept declarative report ( > https://github.com/yawaramin/gc-decl-reports/blob/master/hello-world.scm ). > It doesn't really do anything other than populate a few options into the > report options dialog box, and render a few lines of HTML. I'm trying to > come up with a flexible format for pushing the accounting data around > internally, so that it can filtered, sorted, and grouped, and then shown in > either a tabular or graphical layout. > > If you want to try it out, just copy over hello-world.scm and replace your > version of it (in your GnuCash install's shared reports directory) with my > one. > > [...] > > > > 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. > > > Very true. Are you planning to start up a wiki page? Maybe we can pool > efforts. Pooling efforts is the only thing that makes sense. But perhaps that should be on a wiki page specifically dedicated as a draft Guile API page, rather than as your personal page. I don't feel good editing other peoples' personal pages. First, though, I'm setting up my development environment, and trying to get over a bout of some kind of mild stomach flu. And I'll have to get some kiind of feel for the system's internals before I really feel free to start documenting it. Except for maybe a bit of personal development diary and function descriptions that start like "Could this possibly be the function that ..." And it's more than just API that's needed. There's also things like how to run gnucash-env to run scheme code on its right environment (as mentioned in another post on this forum; thanks, derek). My personal development log will probably tell me the unobvious about what needs to be documented. As for your draft declarative report, I'm not ready yet. -- 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: 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: 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: Scripting
On Sun, 13 Nov 2011 19:17:38 -0500, Derek Atkins wrote: > Hendrik Boom writes: > >>>> (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? > > Amongst others, yes. The reports use the scheme bindings, but there are > more APIs wrapped than just those used by the reports. For a while back > in the 1.x days the gnucash "application" was actually a guile script. I suppose then that the paragraphs in src/scm/startup-design.txt are obsolete: - gnucash is a hybrid /bin/sh and guile script which first execs gnucash-env on itself to set up the proper environment and then run the rest of the code in the gnucash file as a guile script. - from the gnucash script itself, the (gnucash bootstrap) is loaded, and then control transfers to the scheme function, main. Is there still a way, other than as a report, to run a scheme script that uses gnucash's API? -- hendrik ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: developer account created
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: > . > > 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
On Sat, 12 Nov 2011 12:55:08 -0500, Derek Atkins wrote: > Hi, > > Hendrik Boom 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: 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: Types of reports required
> > > Is GNUCash multi-user? Won't different users store their accounts in > different directories and hence separate styles in that way? I guess a > business setting is a place where many people may use and update the same > account. Does GNUCash have facilities for distinguishing between > different users? If so, we'll probably want to have some sort of hash > table of properties with the user name as a part of each proptery name > (i.e. "jrennie.register-style=auto-single"). I guess this is easy enough > to do on any unix-ish system: just have all the users open up the same > account file. Environment variables will then distinguish different > users accordingly. Still easier, put the preferences in a ~/.gnucashrc file. -- 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
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: 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? > > > > > > Well, I won't "buy" that angle. > > Where did you buy your degree? > > Radian's already been sold. > > But not marked as such because I was unaware of the HTML tag. :-( Or is that a joke, too? :-) > > -- 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]
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
> > 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
> 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: 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
> 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: 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: 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: 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: 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]
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]
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]
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]
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]
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]
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: speed?
> > Another topic: what sorts of duplicate transactions are you finding > after QIF import? IIRC you have mentioned two classes of problem: one > is the Opening Balance in non-first-position and one is Quicken > collapsing two splits into one. Are there other types of problem > transactions you have identified? No. The ones I have identified in the last few days are the only ones I have encountered. > > > My guesses (using psychic debugging, without reference to source code) > > is: > > ... > > These two are not right. There's no Guile code involved in the > register display at all, that I know of, and certainly not in the > actual display-construction. Well, my reputation as a psychic has always been dismal. ;-) > > > 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. > > Well, that's hardware that would kindly be called "pathetic" these > days :), but I think gnucash should be able to run fine on it. If it > doesn't, that's something we need to work on. So far, it's fine for everything I really need except video games. We have a nearly-dedicated Windows 95 machine for that. It's not supposed to have any sensitive or critical data on it; hence the desire to move from Quicken there to gnucash here. > > Bill Gribble > -- 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: translation
> ... Normaly if I don't know what a > word means I try to find it in the program and then understand it with > help from the context. But since there is a new stable version coming I > will try to fix this fast by asking instead... Feel free to ask even if there is not an imminent stable release. It's best if the translation is right. > > Here is a string from the po-file: > > "Find securities transactions with share price of" > > There are a some other strings about securities transactions. I don't > know what it is and I have some trouble to translate them. For now they > are not translated. I only have english as a second language, but in my > ears "securities transactions" sounds wrong. Should it not be security > transactions. Or is securities some sort of economical item (I would > guess the later). Securities are things like shares in a company. They have value that fluctuates with the expected success of the company. Usually you buy or sell many of them at a time (like hundreds, or hundreds of thousands), hence the plural. > > "Credit Line" - I simply don't know what it is. Kind of a bank account, except they are still happy if your balance is negative (up to a limit) because they trust you and are delighted to collect interest. It's an easy way of borrowing and repaying money in small amounts as needed. -- hendrik. -- Gnucash Developer's List To unsubscribe send empty email to: [EMAIL PROTECTED]
opening balances again
There's still the one small matter of opening balances that are not the first transaction in the file. I am aware of the danger of using them to guess the true identity of the file. But if the identity is determined by other means (such as explicit user-specification in the import dialog), and the opening balance thereupon turns out to be a transfer from the account to itself, might this case merit the treatment offered opening balances at the start of the file - that it should be treated as a transfer from an equity account or whatever account is used for initial opening balances? I think this would fix the last import anomaly I encounter. -- 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: 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]
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]
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]
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
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.
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: 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.
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.
> 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 > > >
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
> > 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: 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: 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: 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: 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: 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: 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: so many files
> linas> Ugh, I have more than once run out of file system space. The > linas> current backup scheme is designed to always leave you with a > linas> usable (if older) copy no matter what. I don't want to loose > linas> that. > > Why would we have to lose that? Another nice thing about RCS is that > it doesn't need to have the entire file saved each time. I was under the impression that RCS uses backward deltas. As a result, it does write the entire final versio every time, and adjusts previous versions so that they are just deltas from the most recent version. If this fails, you've lost big, unless RCS is careful to maintain a backup of the entire RCS file. Am I wrong? Is cvs any different? -- 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: 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 u
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: 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: QIF import
> > Also, I had an idea regarding duplicate transactions during QIF importing.
> > Since the QIF files are now being imported as a batch process, you can make
> > the assumption that if a transfer exists between two accounts that are
> > being imported, it should appear in both accounts.
>
> That's right. Is that not working correctly for you? The import code
> is supposed to detect transfers between accounts and handle
> elimination of duplicates.
I just set up 1.3.3 and imported all my .qif files as a single batch,
starting from an empty gnucash.
I was delighted to see the huge balance in my chequing account.
But not by the very negative one in my professional account.
What it comes down to is that I *still* get duplicates.
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
The only thing different between these two transactions is the "Num"
field ("net" vs "ov013"), and the "R" field ("r" vs. "n"). I believe you
said you ignore these differences. Something must wtill be wrong.
When I jump to the "visa - personal" account register, both transactions
also appear there -- with the same one reconciled and the same one unreconciled.
The proper result should have been only one transaction, reconsiled on the
"chequing" account, and unreconciled on the "visa - personal" account.
And in another place in the register, entries are duplicated even though
there is no difference in Num or "R" (both have a blank number and an "R" field of
"r".)
>
> > Maybe with an assumption like this it could be possible to relax the
> > restrictions on detecting a duplicate transaction, and then more
> > things would match.
>
> The assumption now is just that the accounts are cross-references, the
> amounts are equal and opposite, and the date is the same. How much
> more relaxed could we get?
>
> What sort of duplicates aren't getting weeded out now? Keep in mind
> that if a QIF transaction is a duplicate of a transaction already in
> your Gnucash account, it must meet more exacting match criteria to get
> eliminated by the account merge procedure. Is that the situation
> you're seeing?
I'm seeing transactions duplicated that I can see *no* difference between.
Oh. One thing I just thought of. During import, I had to identify
a few accounts -- cases where gnucash had made two accounts, one from the
Quicken account name, and one from the name of the file.
As far as I know, each of my transfer transactions in the entire six years
of records involves at least one such account. Could there be a confusion
between account identity before and after renaming? Or is this a red herring.
>
> 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]
