Re: r15207 - gnucash/trunk/src/gnome-utils - Rename private min/max functions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Stimming schrieb: Author: cstim Date: 2006-12-12 06:28:08 -0500 (Tue, 12 Dec 2006) New Revision: 15207 Trac: http://svn.gnucash.org/trac/changeset/15207 Modified: gnucash/trunk/src/gnome-utils/gnc-frequency.c Log: Rename private min/max functions to avoid name collisions with existing functions of macros That should have read functions or macros. No particular macro magic has been intended. :-) Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRX6FoGXAi+BfhivFAQL9owP/SOdO0Ij/lr/jQDPOxKXw25i/4uEbVT3k iMyV4rIUrLRXevE8ckQ9OKwfjyyhTPD+ODsn/PO5i0jxXbPg9vcBvwYTQekCSser EMb99yKw/n3ECQu09drzYnhbK1zSCkQIxx20eO0K32bdKO6AeKJtDjza3lGuROs2 ZIulyFj5xo8= =4cbx -END PGP SIGNATURE- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Automatically split transactions with sales tax or VAT (Value added tax) when a transaction is booked to an sales or value-added-tax related account
Andrew Sackville-West wrote: On Tue, Nov 14, 2006 at 11:35:17AM +0100, Oliver König wrote: Hello, I have posted two feature request for GnuCash at bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=364378 http://bugzilla.gnome.org/show_bug.cgi?id=371581 Both feature requests are actually just one feature request. The first one describes the problem for users of GnuCash in countries who have got a Value added tax (e.g. Europe, etc) and the latter one for those countries with sales tax (e.g. USA). However the feature is the same in both cases: Just to let you know that I got around this problem (basically as Andrew suggested) by writing a perl script to suck transaction details out of my POS system and generate a QIF file which then imports without problem into gnucash. Why I didn't think of this earlier I'm not sure, but thanks to Andrew for kicking my brain into gear. Nigel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Automatically split transactions with sales tax or VAT (Value added tax) when a transaction is booked to an sales or value-added-tax related account
Hi, Maybe it would be nice to include such a script in the contrib directory of the source. I'm sure other users may be interested in such an example. Perhaps even a small wiki page to explain how it works could serve as a mini howto on QIF. Just a suggestion. Regards, Geert On Tuesday 12 December 2006 11:40, Nigel Titley wrote: Andrew Sackville-West wrote: On Tue, Nov 14, 2006 at 11:35:17AM +0100, Oliver König wrote: Hello, I have posted two feature request for GnuCash at bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=364378 http://bugzilla.gnome.org/show_bug.cgi?id=371581 Both feature requests are actually just one feature request. The first one describes the problem for users of GnuCash in countries who have got a Value added tax (e.g. Europe, etc) and the latter one for those countries with sales tax (e.g. USA). However the feature is the same in both cases: Just to let you know that I got around this problem (basically as Andrew suggested) by writing a perl script to suck transaction details out of my POS system and generate a QIF file which then imports without problem into gnucash. Why I didn't think of this earlier I'm not sure, but thanks to Andrew for kicking my brain into gear. Nigel ___ 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: Automatically split transactions with sales tax or VAT (Value added tax) when a transaction is booked to an sales or value-added-tax related account
Geert Janssens wrote: Hi, Maybe it would be nice to include such a script in the contrib directory of the source. I'm sure other users may be interested in such an example. Perhaps even a small wiki page to explain how it works could serve as a mini howto on QIF. I could certainly do this and since the POS I'm using is Interchange, this could be of general interest to the Open Source community. I'll polish the rough edges off the script and submit it together with some explanatory documentation. Just a suggestion. Regards, Geert On Tuesday 12 December 2006 11:40, Nigel Titley wrote: Andrew Sackville-West wrote: On Tue, Nov 14, 2006 at 11:35:17AM +0100, Oliver König wrote: Hello, I have posted two feature request for GnuCash at bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=364378 http://bugzilla.gnome.org/show_bug.cgi?id=371581 Both feature requests are actually just one feature request. The first one describes the problem for users of GnuCash in countries who have got a Value added tax (e.g. Europe, etc) and the latter one for those countries with sales tax (e.g. USA). However the feature is the same in both cases: Just to let you know that I got around this problem (basically as Andrew suggested) by writing a perl script to suck transaction details out of my POS system and generate a QIF file which then imports without problem into gnucash. Why I didn't think of this earlier I'm not sure, but thanks to Andrew for kicking my brain into gear. Nigel ___ g ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: engine objects vs. SX or invoices (was: GDA: A few questions)
On Tue, Dec 12, 2006 at 09:47:10AM +0100, Christian Stimming wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Shoemaker schrieb: I'm just saying SXs could use the real engine objects, just like Invoices. The only difference is that the engine has to learn that real SX transactions aren't _that_ real. :) Except Invoices don't either, for the same reason that it's causing trouble that SXes do -- it complicates all the code when EVERYONE has to be aware that a foo-object is really part of a bar-object. Much easier to just have foo object and bar object and then use KVP GUIDs to link back and forth. I can see your point, but I just don't agree that the benefit of not requiring the engine to know how to provide a list of transactions that excludes SXs is greater than the benefit of reusing the data-structures and constraint code. There's an interesting additional twist here: We also have imported transactions, i.e. those that have been read by some import-export module and are being reviewed by the user in the generic transaction matcher. These took exactly the opposite approach than invoices or SX: They are being created as real transactions, except that all of them are not yet committed until the generic transaction matcher dialog is finished (at which point in time each imported transaction is either fully committed or deleted again). However, this leads to all sorts of problems with the registers of the accounts in question. See http://bugzilla.gnome.org/show_bug.cgi?id=150569 http://bugzilla.gnome.org/show_bug.cgi?id=341076 to name a few. The whole generic importer framework would rather need a data type of its own as well - OR the real objects might have another flag added that says I'm not a real object to the engine. Chris, would your understanding of a potential SX implementation lead to a solution like that? Yes, in my opinion, imported transactions and template transactions are both similar enough to real transactions to reuse the existing data structure and code. This obviously (almost) works for import. I would diagnose the problem with import being that it makes no attempt to distinguish transactions in the process of being imported from real posted transation. Import Transactions can be really created at the beginning of the import process. At the end they can be promoted into real transactions or deleted. All the while, we wouldn't be keeping transactions in an open state for long periods, and we wouldn't be affecting any other views that only care about real transaction. AFAICT, this is really quite a minor change for Import, but I think it would work. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: engine objects vs. SX or invoices (was: GDA: A few questions)
Christian Stimming [EMAIL PROTECTED] writes: Chris Shoemaker schrieb: I'm just saying SXs could use the real engine objects, just like Invoices. The only difference is that the engine has to learn that real SX transactions aren't _that_ real. :) Except Invoices don't either, for the same reason that it's causing trouble that SXes do -- it complicates all the code when EVERYONE has to be aware that a foo-object is really part of a bar-object. Much easier to just have foo object and bar object and then use KVP GUIDs to link back and forth. I can see your point, but I just don't agree that the benefit of not requiring the engine to know how to provide a list of transactions that excludes SXs is greater than the benefit of reusing the data-structures and constraint code. There's an interesting additional twist here: We also have imported transactions, i.e. those that have been read by some import-export module and are being reviewed by the user in the generic transaction matcher. These took exactly the opposite approach than invoices or SX: They are being created as real transactions, except that all of them are not yet committed until the generic transaction matcher dialog is finished (at which point in time each imported transaction is either fully committed or deleted again). However, this leads to all sorts of problems with the registers of the accounts in question. See http://bugzilla.gnome.org/show_bug.cgi?id=150569 http://bugzilla.gnome.org/show_bug.cgi?id=341076 to name a few. The whole generic importer framework would rather need a data type of its own as well - OR the real objects might have another flag added that says I'm not a real object to the engine. Chris, would your understanding of a potential SX implementation lead to a solution like that? I think it might solve it; we'd have to add one more flag to the transaction object, a transaction type (although that term is already taken for something else so I think we'll need to think of something else, maybe txn model or something... Every transaction would have to get this set to something (although we could make it so that standard txns are empty). Then we'd have to change EVERY query to explicitly look for a specific type: NORMAL_TXN, SX_TXN, IMPORT_TXN, etc. It would require touching every place we make a query.. It's sort of like what the qofQuerySearchFor() API is for, but this would be subtyping on Split (or Transaction).. HOWEVER, I think there's another issue here.. When you're doing a large import and you create new accounts as part of the import, if you then cancel the import process these new accounts don't get backed out too. Christian -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: engine objects vs. SX or invoices (was: GDA: A few questions)
On Mon, 2006-12-11 at 22:06 -0500, Chris Shoemaker wrote: Invoices basically reuse the engine objects. But SXs have: struct TTInfo_s [...] which look suspiciously like a Transaction, and struct TTSplitInfo_s [...] which looks suspiciously like a Split. And then the whole duplicated accounts setup. These structures aren't the actual storage, and are only barely used as runtime representations of Template [Splits and] Transactions. They were sourced from Robert Merkel's work on the SX-from-transaction dialog, and are used (by my hand) in the Mortgage/Loan Druid. In both cases, they're immediately passed to xaccSchedXactionSetTemplateTrans(...), which just converts these degenerate structures into the real template Transactions. Looking back on it, I'd just the calling code to write the template structures directly, though maybe with some convenience functions for readability. The only structures relevant are the Accounts, Transactions and Splits rooted in the Template Account-Group. -- ...jsled http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r15205 - gnucash/trunk - Load and store a commodity's KVP-frame (IFF it's non-empty).
On Mon, Dec 11, 2006 at 11:01:55PM -0500, Derek Atkins wrote:
I'll just point out a couple of things:
1) This patch doesn't actually change any data formats, because there's
no data in those fields. So without additional changes (which I agree
should not get backported), there's no chance of a data format change.
That requires us to be careful not to make any changes that use
commodity KVPs.
2) Your proposed change makes it WORSE, because it no longer preserves
data! It would happly read in the KVP data but then NOT SAVE IT BACK
OUT! I think that would be even worse than tossing chunks.
Keep in mind that just making the XML parser not blow chunks on
unrecognized tags isn't sufficient -- we also need to re-write out
those unrecognized tags or we destroy data. Reading and silently
discarding is worse than erroring out.
That's an ideal, but I'm pragmatic. Preserving unrecognized data is
best; Preventing me from opening the file at all is worst. Discarding
unrecognized data is somewhere inbetween. (And it doesn't have to be
silent.)
So, I argue that this change still is safe because it's effectively
unused code, but it would let us add additional information in a 2.2
release and not destroy that data in 2.0, which is why I think we should
backport this change.
Just to be clear, in my opinion, this feature (which we have yet to
actually see) does not by itself justify breaking backward
compatibility, even 2.0 - 2.2.
When we _do_ implement new features, I want to be intentional about
breaking compatibility, not just accept that, well if you're trying to
use your new file with 2.0.4 you're fine, but if you've got 2.0.3,
sorry you can't even open it. That's lousy.
-chris
-derek
Quoting Chris Shoemaker [EMAIL PROTECTED]:
I don't think this should be back-ported. At least not the whole
thing. I don't mind backporting the first and last hunks, but I'm
against breaking backward compatibility of the datafile within a
stable branch.
In fact, even between major releases I think these types of changes
should only be made if there's enough of them to warrant it.
Also, I'd prefer to see the proposed feature implemented _before_
breaking compatibilty, not the other way around.
Now, if someone wanted to make it so that our xml reader didn't croak
on unrecognized tags, that would make this kind of change easier.
So, can we please comment out hunks 2 and 3 with a comment about
re-enabling them when we're willing to break backward compatibility?
-chris
Property changes on: gnucash/trunk
___
Name: svk:merge
-
3889ce50-311e-0410-a464-f059747ec5d1:/local/gnucash/branches/swig-redo:802
3889ce50-311e-0410-a464-f059747ec5d1:/local/gnucash/trunk:943
d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/trunk:13679
d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/trunk2:13366
+
3889ce50-311e-0410-a464-f059747ec5d1:/local/gnucash/branches/swig-redo:802
3889ce50-311e-0410-a464-f059747ec5d1:/local/gnucash/trunk:943
d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/trunk:13699
d2ab10a8-8a95-4986-baff-8d511d9f15b2:/local/gnucash/trunk2:13366
Modified: gnucash/trunk/src/backend/file/gnc-commodity-xml-v2.c
===
--- gnucash/trunk/src/backend/file/gnc-commodity-xml-v2.c 2006-12-11
22:28:36 UTC (rev 15204)
+++ gnucash/trunk/src/backend/file/gnc-commodity-xml-v2.c 2006-12-12
02:51:37 UTC (rev 15205)
@@ -58,6 +58,7 @@
#define cmdty_get_quotes cmdty:get_quotes
#define cmdty_quote_source cmdty:quote_source
#define cmdty_quote_tz cmdty:quote_tz
+#define cmdty_slots cmdty:slots
xmlNodePtr
gnc_commodity_dom_tree_create(const gnc_commodity *com)
@@ -66,8 +67,11 @@
const char *string;
xmlNodePtr ret;
gboolean currency = gnc_commodity_is_iso(com);
+xmlNodePtr kvpnode =
+ kvp_frame_to_dom_tree(cmdty_slots,
+ qof_instance_get_slots(QOF_INSTANCE(com)));
-if (currency !gnc_commodity_get_quote_flag(com))
+if (currency !gnc_commodity_get_quote_flag(com) !kvpnode)
return NULL;
ret = xmlNewNode(NULL, BAD_CAST gnc_commodity_string);
@@ -108,6 +112,10 @@
if (string)
xmlAddChild(ret, text_to_dom_tree(cmdty_quote_tz, string));
}
+
+if (kvpnode)
+ xmlAddChild(ret, kvpnode);
+
return ret;
}
@@ -159,6 +167,12 @@
gnc_commodity_set_quote_source(com, source);
xmlFree (string);
}
+else if(safe_strcmp((char*)node-name, cmdty_slots) == 0)
+{
+ /* We ignore the results here */
+ dom_tree_to_kvp_frame_given(node,
+ qof_instance_get_slots(QOF_INSTANCE(com)));
+}
else
{
struct com_char_handler *mark;
___
gnucash-changes mailing list
Re: Win32 Port Efforts (eKA$H)
Well, thank you for the source code. Out of curiosity I've spent some more time on the larger batch of changes (step1 in my previous email), as it turned out to be possible to separate the name changes from the rest quite easily. @Everyone: Attached you'll find the patch that changes GUID into GNC_GUID (guidrenaming), another path with some other name changes (otherrenaming), and all the rest (step1). * In src/app-utils/gnc-ui-utils.c you did two changes, adding gnc_lconv_set_utf8(lc.positive_sign, ); and - - while (fraction != 1) + while (fraction 1) Any reasons for these two? I honestly don't remember. I think it was more scar tissue when I thought there was a bug. The bug (I think) was in an incoherently linked set of libraries. I would trash these changes if I were you. I think I'll apply some of the name changes that concern only the .c files. But especially the s/GUID/GNC_GUID/ change concerns a lot of code, and, as I said, with SVN-trunk we don't observe any problems of the potential name collision here. I'd suggest to defer this until we actually run into the problem again. What have you done instead, to insulate yourselves from the exposure? Do you not see it because you are using different win32 includes than I? Are you #ifndef guarding it so the symbols do not get into the gnucash areas? I understand your hesitation, but why don't you think you'll see it? * In src/gnome/gnc-plugin-page-register.c you added a lot of code; I can see additional filter functions on description, with or without case sensitivity, and unequality filters for the amount. What do you use these for? Do you think those would be useful in general? These were developed by me for my personal use. I used them when I attempted to import 2 years worth of transactions and reconciled the register. Having these filters made it easier to work with and find transactions I was missing. I found it useful. It just seemed to me that a search on the register fields would be useful. Others may or may not find it so. * Your report modifications (modified cash-flow.scm, portfolio.scm, added asset-class.scm) would be a nice contribution to the existing SVN-trunk code. Could you summarize your changes to the cash-flow report? The cash-flow.scm report change was primarily to support showing the percentage of cash to different categories in addition to the absolute currency figures. It was developed by me because I was curious to express my spending in this way. The portfolio and asset class reports simply report on the afforementioned asset class whose implementation is under some debate. As far as I can see, most of your other changes have already been implemented in SVN-trunk, especially all build system changes and path name handling. Unless I've missed anything, I think you get all these functions from SVN-trunk as well. So I'm looking forward to any further contributions from you. Thank you very much. I'll try to be more careful in implementing changes in future. The main purpose of my project is to provide a broad range of OpenSource software to the win32 public. When I began, the gnucash project's win32 port was still early and rather than do the right thing and wait, I hacked it. It seems that I will be able to go back to the strategy of take a stable release and patch only what needs it for coherency with my system. -Jon Arney ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r15205 - gnucash/trunk - Load and store a commodity's KVP-frame (IFF it's non-empty).
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Atkins schrieb: 1) This patch doesn't actually change any data formats, because there's no data in those fields. So without additional changes (which I agree should not get backported), there's no chance of a data format change. Does that mean this code doesn't write any data (in the KVP fields) if and only if there isn't any data written during runtime? If yes, then I'd happily accept that code, BUT we'd have to be really sure we don't accidentally back-port any of the code that would introduce data into those kvp fields. Keep in mind that just making the XML parser not blow chunks on unrecognized tags isn't sufficient -- we also need to re-write out those unrecognized tags or we destroy data. Reading and silently discarding is worse than erroring out. *sigh* You're probably right, although a crashing gnucash is always not a good thing. We should have some different method available if users want to read a non-backward-compatible file, with the clear notion that this will almost certainly mean data loss. Something like Import gnucash file from other version or similar. So, I argue that this change still is safe because it's effectively unused code, but it would let us add additional information in a 2.2 release and not destroy that data in 2.0, which is why I think we should backport this change. I agree on the backport. Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRX7IH2XAi+BfhivFAQKQNgQAsTOv6O3XpNqsbPCY8hnIrQhX7N/EuxOc Og4ZMbaKtPWVvuyWQeGGx3NsSqo00O1QZRXLIOqaJUhz0u6Hal5wGrfzu0YtPnXv BWKXldvrFeVHFqSERmgGMLPjl3xqmMGpkJDsu/FZsYfHm4KIBJ4J+pRNbJ11bJWx LQG8MyCcmOc= =lwvE -END PGP SIGNATURE- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: engine objects vs. SX or invoices (was: GDA: A few questions)
On Tue, Dec 12, 2006 at 10:05:21AM -0500, Josh Sled wrote: On Mon, 2006-12-11 at 22:06 -0500, Chris Shoemaker wrote: Invoices basically reuse the engine objects. But SXs have: struct TTInfo_s [...] which look suspiciously like a Transaction, and struct TTSplitInfo_s [...] which looks suspiciously like a Split. And then the whole duplicated accounts setup. These structures aren't the actual storage, and are only barely used as runtime representations of Template [Splits and] Transactions. They were sourced from Robert Merkel's work on the SX-from-transaction dialog, and are used (by my hand) in the Mortgage/Loan Druid. In both cases, they're immediately passed to xaccSchedXactionSetTemplateTrans(...), which just converts these degenerate structures into the real template Transactions. Looking back on it, I'd just the calling code to write the template structures directly, though maybe with some convenience functions for readability. Ah, thanks for explaining that. That does make a lot more sense. The only structures relevant are the Accounts, Transactions and Splits rooted in the Template Account-Group. So, they already are real Transactions/Splits in an alternate Account hierarchy, where every account must refer to a real account, (named by its guid). So then, my recommendation is just to use real accounts and flag the transactions as templates. Although, this was originally brought up in the context of the register-rewrite, and using the alternate accounts is not a big deal in the register-rewrite. So, this has just been me harping on what I think is a good code improvement. -chris ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r15205 - gnucash/trunk - Load and store a commodity's KVP-frame (IFF it's non-empty).
Quoting Christian Stimming [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Derek Atkins schrieb: 1) This patch doesn't actually change any data formats, because there's no data in those fields. So without additional changes (which I agree should not get backported), there's no chance of a data format change. Does that mean this code doesn't write any data (in the KVP fields) if and only if there isn't any data written during runtime? If yes, then I'd happily accept that code, BUT we'd have to be really sure we don't accidentally back-port any of the code that would introduce data into those kvp fields. Correct, if the KVP fields are empty then there is no change to the XML. Indeed, I tested this by reading my data file and re-writing it out, and the gnc:commodity entries in the XML file did not change. So the only time it will write extra data to the XML file is if there was already extra data in the file, or if somehow during runtime something adds data to that KVP. Right now nothing writes to that KVP, so I think it's safe to say that we wont backport anything that would... So what we're doing is making 2.0.4 backwards- and forwards-compatible with potential changes in 2.2. Keep in mind that just making the XML parser not blow chunks on unrecognized tags isn't sufficient -- we also need to re-write out those unrecognized tags or we destroy data. Reading and silently discarding is worse than erroring out. *sigh* You're probably right, although a crashing gnucash is always not a good thing. We should have some different method available if users want to read a non-backward-compatible file, with the clear notion that this will almost certainly mean data loss. Something like Import gnucash file from other version or similar. Well, I dont think it would crash, per se.. It should just output an error. HOWEVER in this particular case the gnc-commodity parser WILL ignore anything it doesn't understand, so we already have the 'data loss' state.. So chris' worry isn't really there; this change IS safe and just makes it safer -- 2.0.[0123] will read a data file with this new object and just ignore it (and drop it on the floor) without erroring out. So, I argue that this change still is safe because it's effectively unused code, but it would let us add additional information in a 2.2 release and not destroy that data in 2.0, which is why I think we should backport this change. I agree on the backport. Thanks, -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: AUDIT: r15205 - gnucash/trunk - Load and store a commodity's KVP-frame (IFF it's non-empty).
Quoting Chris Shoemaker [EMAIL PROTECTED]: On Tue, Dec 12, 2006 at 10:36:42AM -0500, Derek Atkins wrote: snip 2.0.[0123] will read a data file with this new object and just ignore it (and drop it on the floor) without erroring out. If that's true, then I withdraw my objection. Just to clarify, are you saying that it drops the unrecognized data silently, or that it prints an error and continues? If the latter, what is the error message? Looking at the code (this is all by inspection, I haven't tested this) it will silently drop unrecognized XML nodes in the gnc:commodity subtree. In either case, as long as the file opens, I'm satisfied. By inspection it should just open. I can try to modify and open a file if you want, but I'm fairly confident in the code. -chris -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Win32 Port Efforts (eKA$H)
--On December 12, 2006 11:19:24 AM +0100 Christian Stimming [EMAIL PROTECTED] wrote: * You replaced the type names GUID by GNC_GUID and CURRENCY by GNC_CURRENCY, IGNORE by GNC_IGNORE and others. Any reasons for this, especially the latter two? I vaguely recall GUID being defined in some winapi header file, but in SVN-trunk apparently there's no longer a problem with this. The win32 API header files do define GUID, CURRENCY, and IGNORE. The GNC_ versions of these are intended simply to remove this colission. I think I'll apply some of the name changes that concern only the .c files. But especially the s/GUID/GNC_GUID/ change concerns a lot of code, and, as I said, with SVN-trunk we don't observe any problems of the potential name collision here. I'd suggest to defer this until we actually run into the problem again. The Windows header files certainly do define those symbols. Is it perhaps the case that SVN-trunk hasn't run into this because it's being built with Cygwin instead of MSVC? Although I did Windows development for years, I haven't looked at the Windows port of Gnucash so this may be off the wall. -- Mike Alexander [EMAIL PROTECTED] Ann Arbor, MIPGP key ID: BEA343A6 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Win32 Port Efforts (eKA$H)
Quoting Mike Alexander [EMAIL PROTECTED]: I think I'll apply some of the name changes that concern only the .c files. But especially the s/GUID/GNC_GUID/ change concerns a lot of code, and, as I said, with SVN-trunk we don't observe any problems of the potential name collision here. I'd suggest to defer this until we actually run into the problem again. The Windows header files certainly do define those symbols. Is it perhaps the case that SVN-trunk hasn't run into this because it's being built with Cygwin instead of MSVC? Although I did Windows development for years, I haven't looked at the Windows port of Gnucash so this may be off the wall. Well, we actually use MinGW, not Cygwin, but it's still GCC. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
fixed bugs in 2.0.3?
Is there an easy way to generate a list of which bugs have been fixed in gnucash 2.0.3? Thomas signature.asc Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: fixed bugs in 2.0.3?
Quoting Thomas Bushnell BSG [EMAIL PROTECTED]: Is there an easy way to generate a list of which bugs have been fixed in gnucash 2.0.3? The ChangeLog? Another option is a Bugzilla Query searching on Target = 2.0.3 Thomas -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: #gnucash public logging?
Am Dienstag, 12. Dezember 2006 03:23 schrieb Derek Atkins: On the whole, I think publishing channel logs is a win, or I wouldn't be suggesting it. :) But what do you think? I guess the options are: - do it. - do it for a month or two and re-evaluate. - don't do it. 1) I'm for it. 2) I think a notice in the channel topic is sufficient. 3) I assume there would be some mechanism for an op to toggle logging off for the whole channel. Yeah, I would choose option #2 (do it and then re-evaluate). I also agree with Chris' statements. Agreed from here as well. Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: engine objects vs. SX or invoices (was: GDA: A few questions)
On Tuesday 12 December 2006 09:54, Derek Atkins wrote: HOWEVER, I think there's another issue here.. When you're doing a large import and you create new accounts as part of the import, if you then cancel the import process these new accounts don't get backed out too. That's probably not worth solving. Creating the accounts requires a user intervention anyway, and backing out of the import does not necessarily mean that the user wants or expects all the accounts he manually created to be deleted. -- Benoit Grégoire Technologies Coeus inc. pgpI85tWr1rln.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: engine objects vs. SX or invoices (was: GDA: A few questions)
Quoting Benoit Grégoire [EMAIL PROTECTED]: On Tuesday 12 December 2006 09:54, Derek Atkins wrote: HOWEVER, I think there's another issue here.. When you're doing a large import and you create new accounts as part of the import, if you then cancel the import process these new accounts don't get backed out too. That's probably not worth solving. Creating the accounts requires a user intervention anyway, and backing out of the import does not necessarily mean that the user wants or expects all the accounts he manually created to be deleted. While I agree it's not worth solving on its own, if we can solve it at the same time as everything else we're working on here then we should. In my opinion, if a user clicks Cancel then EVERYTHING from the import should be canceled, including the new account creation. I'll point out that the way the QIF importer did this was that it created a duplicate account hierarchy for the import and then during the 'finish' it merged everything from the new hierarchy into the original one. But yes, I agree that this problem shouldn't be worked on by itself, I was just pointing out it's one of many ways that the import process isnt atomic. Benoit Grégoire Technologies Coeus inc. -derek ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Automatically split transactions with sales tax or VAT (Value added tax) when a transaction is booked to an sales or value-added-tax related account
On Tue, Dec 12, 2006 at 10:40:49AM +, Nigel Titley wrote: Andrew Sackville-West wrote: On Tue, Nov 14, 2006 at 11:35:17AM +0100, Oliver König wrote: Hello, I have posted two feature request for GnuCash at bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=364378 http://bugzilla.gnome.org/show_bug.cgi?id=371581 Both feature requests are actually just one feature request. The first one describes the problem for users of GnuCash in countries who have got a Value added tax (e.g. Europe, etc) and the latter one for those countries with sales tax (e.g. USA). However the feature is the same in both cases: Just to let you know that I got around this problem (basically as Andrew suggested) by writing a perl script to suck transaction details out of my POS system and generate a QIF file which then imports without problem into gnucash. Why I didn't think of this earlier I'm not sure, but thanks to Andrew for kicking my brain into gear. happy to help. A signature.asc Description: Digital signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gda-dev does not compile
Mark Johnson wrote:
I've modified the config file as follows:
?xml version=1.0?
libgda-config
section path=/apps/libgda/Datasources/SalesTest
entry name=DSN type=string
value=URI=/home/phil/.libgda/sales_test.db/
entry name=Description type=string value=Test database for
a sales department/
entry name=Password type=string value=/
entry name=Provider type=string value=SQLite/
entry name=Username type=string value=/
/section
section path=/apps/libgda/Datasources/gnucash
entry name=Description type=string value=Test database for
gnucash/
entry name=Passwordtype=string value=kirk/
entry name=Providertype=string value=MySQL/
entry name=Usertype=string value=gnucash/
entry name=Hosttype=string value=enterprise/
entry name=DSN type=string value=DB_NAME=gnucash/
/section
/libgda-config
I logged into MySql (as root) and created the user and database. I did
not create tables, assuming that gnucash would create them.
I started gnucash with:
$ gnucash gda://gnucash
It indicated that the database did not seem to exist and asked if I
would like to create it. I clicked yes. Nothing further happened.
The following was printed on my terminal:
[EMAIL PROTECTED]:/opt/gnucash-svn15198/bin$ gnucash gda://gnucash
This is a development version. It may or may not work.
Report bugs and other problems to [EMAIL PROTECTED]
You can also lookup and file bug reports at http://bugzilla.gnome.org
The last stable version was GnuCash 2.0.2
The next stable version will be GnuCash 2.2
SQL error: Can't connect to local MySQL server through socket
'/tmp/mysql.sock' (2)
SQL error: Can't connect to local MySQL server through socket
'/tmp/mysql.sock' (2)
The unix socket file is a problem. It needs a host and port to connect
to my db server on another machine. (The default port is what I am
using here.) I had thought that the entry name for host above would
indicate that.
Phil,
I checked the gda documentation and tried adding:
entry name=Porttype=string value=3306/
I was thinking this might convince it to use the network socket rather
than the unix socket file. Same result as before.
I tried running gnucash under gdb to see what was being passed to gda's
gda_client_open_connection. Here is the results:
(gdb) break gnc-backend-gda.c:1333
Breakpoint 1 at 0xb67a6236: file gnc-backend-gda.c, line 1333.
(gdb) cont
Continuing.
Detaching after fork from child process 3591.
[Switching to Thread -1231022400 (LWP 3583)]
Breakpoint 1, gnc_gda_session_begin (be_start=0x8230f98,
session=0x844e1b8, book_id=0x8450600 gda://gnucash,
ignore_lock=0, create_if_nonexistent=0) at gnc-backend-gda.c:1333
1333be-pClient = gda_client_new();
(gdb) print *book_id
$1 = 103 'g'
(gdb) print book_id
$2 = (const gchar *) 0x8450600 gda://gnucash
(gdb) n
1336book_info = g_strdup( book_id );
(gdb) n
1337dsn = strchr( book_info, ':' );
(gdb) print book_info
$3 = (gchar *) 0x8231148 gda://gnucash
(gdb) n
1338*dsn = '\0';
(gdb) print dsn
$4 = (gchar *) 0x823114b ://gnucash
(gdb) n
1339dsn += 3;
(gdb) print dsn
$5 = (gchar *) 0x823114b
(gdb) n
1340username = strchr( dsn, ':' );
(gdb) print dsn
$6 = (gchar *) 0x823114e gnucash
(gdb) n
1341if( username != NULL ) {
(gdb) print username
$7 = (gchar *) 0x0
(gdb) n
1344username = ;
(gdb) n
1346password = strchr( username, ':' );
(gdb) n
1347if( password != NULL ) {
(gdb) print password
$8 = (gchar *) 0x0
(gdb) n
1350password = ;
(gdb) n
1353be-pConnection = gda_client_open_connection( be-pClient,
(gdb) n
1358g_free( book_info );
(gdb) n
1360if( be-pConnection == NULL ) {
(gdb) n
1361printf( SQL error: %s\n, error-message );
(gdb) n
1362qof_backend_set_error( be_start,
ERR_BACKEND_NO_SUCH_DB );
(gdb) cont
Continuing.
Program exited normally.
(gdb)
It appears this code is expecting a URI like this:
gda://DSN:username:password
And that the .libgda/config file is not used.
I tried:
$ gnucash gda://gnucash:gnucash:kirk
But then it complained that the database gnucash:gnucash:kirk did not
exist, and printed the errors about the socket file again.
I need help connecting. I am able to run the MySql query browser and
administrator programs from this machine, so it can definitely connect
to the db server.
Thanks,
Mark
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
