Re: r19916 - gnucash/trunk/src/optional/python-bindings - Add commodity price functions to bindings.
On Wednesday December 8 2010 20:48:32 Derek Atkins wrote:
> Mike Evans writes:
> >> Why did you remove -Werror?
> >>
> >> -derek
> >
> > Ah. I wanted to enable SWIG %feature("autodoc", "1"); to make debugging
> > easier. Compile fails with an error if -Werror in enabled. I forgot to
> > put it back in when I'd finished. I'll commit a fix.
>
> So what's the compile error when you have autodoc enabled?
>
> > Mike
>
> -derek
With %feature("autodoc", "1"); and -Werror I get:
../../../src/engine/Account.h:182: Warning(314): 'from' is a python keyword,
renaming to '_from'
../../../src/engine/Account.h:182: Warning(314): 'from' is a python keyword,
renaming to '_from'
../../../src/engine/Account.h:194: Warning(314): 'from' is a python keyword,
renaming to '_from'
../../../src/engine/Account.h:194: Warning(314): 'from' is a python keyword,
renaming to '_from'
../../../src/libqof/qof/gnc-numeric.h:266: Warning(314): 'in' is a python
keyword, renaming to '_in'
../../../src/libqof/qof/gnc-numeric.h:266: Warning(314): 'in' is a python
keyword, renaming to '_in'
../../../src/libqof/qof/gnc-numeric.h:297: Warning(314): 'in' is a python
keyword, renaming to '_in'
../../../src/libqof/qof/gnc-numeric.h:297: Warning(314): 'in' is a python
keyword, renaming to '_in'
../../../src/libqof/qof/gnc-numeric.h:450: Warning(314): 'in' is a python
keyword, renaming to '_in'
../../../src/libqof/qof/gnc-numeric.h:450: Warning(314): 'in' is a python
keyword, renaming to '_in'
../../../src/libqof/qof/gnc-numeric.h:465: Warning(314): 'in' is a python
keyword, renaming to '_in'
../../../src/libqof/qof/gnc-numeric.h:465: Warning(314): 'in' is a python
keyword, renaming to '_in'
../../../src/engine/gnc-commodity.h:949: Warning(314): 'from' is a python
keyword, renaming to '_from'
../../../src/engine/gnc-commodity.h:949: Warning(314): 'from' is a python
keyword, renaming to '_from'
make[1]: *** [gnucash_core.c] Error 14
make[1]: Leaving directory `/home/mikee/Projects/gnucash/src/optional/python-
bindings'
make: *** [all-recursive] Error 1
Mike E
--
GPG Key: 1024D/050895C2
Keyserver: http://pgp.mit.edu/
Search String: 0x050895C2
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Python bindings doc and doxygen
On Wednesday 08 December 2010, Christoph Holtermann wrote: > Hello ! > > It surely would be useful to have some more documentation to the > python bindings. I can imagine to write some things I understand when > figuring out how things work if I see that the feature is not documented. > I wonder if it wouldn't be useful to include some documentation in > doxygen ? As far as I can see there is nothing in there yet. > > regards, > > Christoph Holtermann > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel That would make a nice contribution in my opinion. Since most people that want to use the python bindings are looking for interface documentation, I also agree that doxygen would be a good place to add the it. Thanks for your offer ! Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
gnc-prices has dokumentation but it seems that it doesn't exist anymore
Hello ! I just found the documentation for a perl skript calles gnc-prices [1]. It seems to me that it doesn't exist anymore. Maybe the documentation can be deleted then ? regards, Christoph Holtermann [1] http://www.linuxmanpages.com/man1/gnc-prices.1.php in the source tree : doc/gnc-prices.1(.in) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SQL Databases from before 2.3.16
John Ralls writes:
>> Maybe this is a silly question, but why couldn't we use the versions
>> table to notice this, too? It's still a bug in the SQL, and we should
>> get used to fixing SQL bugs internally.
>>
>> I understand it might take a few tries to get right, but that's what
>> "mysqldump" is for. :)
>
> The versions table has only one row for each table, having the table
> name and a version number. As long as the schema of the table doesn't
> change, different versions of Gnucash whose table description array
> matches the schema can write to the table... but they might understand
> the data differently. That's a row-by-row difference and the version
> table isn't fine-grained enough to capture it. That's the way it works
> now.
Sure, it defines the syntax and semantics of the table, which makes
sense. In this particular case an older version may not know what to do
with the newer table structure, so it probably does have to throw an
error and say that an update is required. Right?
> But we could add a row to the versions table with the last Gnucash
> version to touch the database. When we write a change to the backend
> that changes the way data are stored, we can invoke a routine that
> reads everything in the old way and writes it back out the new way,
> then updates the gnucash entry in the versions table. Older versions,
> not knowing what newer versions have changed, would have to punt with
> an error dialog ("Sorry, the database has been written by a newer
> version of Gnucash. This version can't safely read it.") It would get
> unwieldy in pretty short order (like the scrub routines in engine),
> but we could do it.
I think you're right that this is almost exactly like a "Check &
Repair." The "Check & Repair" function exists to fix bugs that cause
broken data to enter the database. In this particular case, I don't
think we need to prevent older versions from reading a database that was
"checked & repaired" by a newer version of GnuCash. It's perfectly
reasonable to expect that older versions can read newer versions.
> All of which is entirely skew to cleaning out the extra rows in
> Elwood's slots table.
Is it? I would think that a "Check & Repair" would exactly do that.
In this case the "Check & Repair" state would get re-written on every
run of GnuCash. You use it to know whether or not you need to run the
C&R functionality on the database. If the database was last touched by
a version >= current-version then you don't need to run the C&R.
However if the last database write was from a version < current-version,
then C&R is required.
The requirement would be that you set LastC&R to "current-version" any
time you make changes to the database, and then you check the LastC&R
whenever you startup.
> Oh, and there isn't enough sql yet to have "bugs in the sql".
The fact that we're having this discussion would prove this incorrect.
There already has been a bug in the SQL causing the slots to not get
deleted properly.
> The sql
> is all very simple (select * from foo where guid="bar" is about as
> complex as it gets right now) with all of the interesting work done by
> qof.
Yes, I understand that. But even simple SQL can have logic bugs.
>Rather a waste of an RDB, frankly. We'll have to change that in
> order to support multiple access, and the redesign will probably reach
> through qof into the engine. That will be another discussion, for
> after we get 2.4 released.
Agreed, but as you say it's an after-2.4 thing. Much of GnuCash
currently depends on having all the data in core. It will require a
thorough cleaning of all those assumptions in order to "fix" that.
Let's get 2.4 out the door first, and then we can talk about how we can
fix this in a piecemeal fashion. It would be nice if we could get
releases out approximately yearly. Can we come up with a
feature-set/timeline that would allow for that (and makes sense)?
> Regards,
> John Ralls
-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
warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r19916 - gnucash/trunk/src/optional/python-bindings - Add commodity price functions to bindings.
Hi,
Mike Evans writes:
> With %feature("autodoc", "1"); and -Werror I get:
>
> ../../../src/engine/Account.h:182: Warning(314): 'from' is a python keyword,
> renaming to '_from'
> ../../../src/libqof/qof/gnc-numeric.h:266: Warning(314): 'in' is a python
> keyword, renaming to '_in'
> ../../../src/engine/gnc-commodity.h:949: Warning(314): 'from' is a python
> keyword, renaming to '_from'
I think it's perfectly reasonable to change the name of these variables
in the three GnuCash headers in order to fix these warnings for you.
> Mike E
-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
warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SQL Databases from before 2.3.16
On Dec 9, 2010, at 7:05 AM, Derek Atkins wrote: > John Ralls writes: > > >> Oh, and there isn't enough sql yet to have "bugs in the sql". > > The fact that we're having this discussion would prove this incorrect. > There already has been a bug in the SQL causing the slots to not get > deleted properly. > Nope, it was a bug in C. SQL doesn't do recursion by itself. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SQL Databases from before 2.3.16
On Dec 9, 2010, at 7:05 AM, Derek Atkins wrote: > > Let's get 2.4 out the door first, and then we can talk about how we can > fix this in a piecemeal fashion. It would be nice if we could get > releases out approximately yearly. Can we come up with a > feature-set/timeline that would allow for that (and makes sense)? Right. For the record, there's already a "scrub" bug for sql: https://bugzilla.gnome.org/show_bug.cgi?id=600347 We can carry on the discussion there. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SQL Databases from before 2.3.16
On Thu, December 9, 2010 12:01 pm, John Ralls wrote: > > On Dec 9, 2010, at 7:05 AM, Derek Atkins wrote: > >> John Ralls writes: >> >> >>> Oh, and there isn't enough sql yet to have "bugs in the sql". >> >> The fact that we're having this discussion would prove this incorrect. >> There already has been a bug in the SQL causing the slots to not get >> deleted properly. >> > > Nope, it was a bug in C. SQL doesn't do recursion by itself. Semantics. Call it a bug in the Database Backend if you prefer. The point being going forward we should auto-correct these kinds of issues. > Regards, > John Ralls -derek ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: SQL Databases from before 2.3.16
On Dec 9, 2010, at 7:05 AM, Derek Atkins wrote:
> John Ralls writes:
>
>> But we could add a row to the versions table with the last Gnucash
>> version to touch the database. When we write a change to the backend
>> that changes the way data are stored, we can invoke a routine that
>> reads everything in the old way and writes it back out the new way,
>> then updates the gnucash entry in the versions table. Older versions,
>> not knowing what newer versions have changed, would have to punt with
>> an error dialog ("Sorry, the database has been written by a newer
>> version of Gnucash. This version can't safely read it.") It would get
>> unwieldy in pretty short order (like the scrub routines in engine),
>> but we could do it.
>
> I think you're right that this is almost exactly like a "Check &
> Repair." The "Check & Repair" function exists to fix bugs that cause
> broken data to enter the database. In this particular case, I don't
> think we need to prevent older versions from reading a database that was
> "checked & repaired" by a newer version of GnuCash. It's perfectly
> reasonable to expect that older versions can read newer versions.
It isn't just "fixing bugs" or "broken data". The interpretation of data and
the way it is stored will change as the program evolves. Such evolution should
be transparent to the user so long as s/he moves only forward and stays with
stable releases.
Testers working with unstable releases (even release candidates) must accept
that storage representations can change and that it might be necessary,
particularly early on when we're experimenting with new features or new storage
modes, that they may have to go back to a stable-version-generated database and
start over.
I guess it's OK for an older version to load a newer-versioned database if it's
read-only, though it might misinterpret the stored data and do something wrong.
(2.3.15 will happily load a 2.3.16-written database, but the slots will be
hopelessly corrupt. r19911 can read a 2.3.15 database, but it can't put back
the slots that 2.3.15 didn't write. Between r19729 and r19911, some slots that
pre-19729 had stored weren't retrieved correctly.)
If the older version is allowed to write to it, then we're back to the
mixed-record problem or worse (lost data in the case of pre-2.3.16).
Anyway, if we're going to introduce the gnucash-version row, we should do it
now, before 2.4 is released.
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: queries on mysql
Hello ! I read this just now. Report generation, moving transactions according to name criteria are all things that can quite easily be done with the python- bindings. They're actually quite a source of joy ;-) Momentarily you just have to fall in love with svn, too and build gnucash from source - which is actually not too difficult. bye, Christoph Holtermann Am 27.11.2010 17:40, schrieb Donald Allen: > On Sat, Nov 27, 2010 at 11:23 AM, John Ralls wrote: >> On Nov 27, 2010, at 4:40 AM, Donald Allen wrote: >> >>> On Sat, Nov 27, 2010 at 5:23 AM, Fred Verschueren wrote: Don, thanks for your advice and explanation. I've done it the way you described and it took me 50 sec per year for one account, so in total 25 minutes. >>> Good. >>> Nevertheless I think having the layout of the database can help making own reports easy. >>> Absolutely. I've already done my own report-writing outside gnucash, >>> processing the xml file (with a python program; python has good xml >>> parsing facilities in its library), which I reverse-engineered. Having >>> the data in a database and the data-model documented will makes this >>> sort of thing much easier and the code less messy. >>> >> You do know that there are python bindings to Gnucash's internals in 2.3? No >> need to reverse-engineer (well, maybe a bit -- the developer documentation >> isn't that great). > Yes, though I haven't looked at it yet; thanks for the reminder. My > python report-generating stuff was written a few years ago, long > before the python bindings. When the new version is released, offering > more and better choices than I had back then, I will re-visit this > and use what seems most suitable for my report-generation needs. > > /Don > > >> Regards, >> John Ralls >> >> > ___ > 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: SQL Databases from before 2.3.16
--On December 9, 2010 10:24:51 AM -0800 John Ralls wrote: Anyway, if we're going to introduce the gnucash-version row, we should do it now, before 2.4 is released. It seems like this is a good idea, even if it is never used for automatic upgrades or fixups. At the very least it would help with debugging to know which version last wrote the data base. Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: close books
Am Mittwoch, 8. Dezember 2010 um 20:46:25 schrieb Derek Atkins: > Geert Janssens writes: > > On Tuesday 07 December 2010, John Ralls wrote: > >> Schema: OK. To make the policy clearer, backwards-incompatible schema > >> changes in 2.5 require a change to 2.4 to provide a read facility for > >> the new schema. > > > > Do we have a wiki page for this kind of policies ? It will get lost when > > it's only mentioned on the mailing list... > > No, but honestly this particular policy is just common sense.. > > -derek But for security reasons, I added http://wiki.gnucash.org/wiki/Development_Process#Backwards-Incompatible_Schema_Changes . Frank ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Terminology Clarification requested
Hi, Using this excerpt as a context: Message: 1 Date: Tue, 7 Dec 2010 09:33:58 -0800 From: John Ralls Subject: Re: close books To: Derek Atkins Cc: devel gnucash Message-ID: <2b1f2747-854c-430c-8aaa-05637e30a...@ceridwen.us> Content-Type: text/plain; charset=us-ascii [...] A KVP *is* better, but because it's better architecture: The closing-entry mark would apply only to one transaction per year, would only be important to one split in that transaction (the income/expense split; one wouldn't want to hide the split from equity reports), and wouldn't have any applicability to any transactions which don't touch income or expense accounts. Something of such limited scope doesn't deserve a column. Note that the KVP should be on the split, not the transaction, because many income/expense reports don't need to look at the whole transaction, they just need to total up the credits and debits shown in the splits occurring between two dates. Regards, John Ralls Let me ask your help as I work my way to a new understanding of the term "transaction". My formation long ago as a young accountant contained this understanding of a transaction: it was the accounting expression of an activity that happened in the physical world, which the accounting ledgers were tracking in their own notation. For example, suppose the activity is buying a car using cash and debt on 11/10/2010. The accounting transaction is that act of purchase. The accounting notation was the language of debits and credits with accompanying names describing the purpose of the monetary "buckets" or value holders. Thus, in a journal, the transaction would be recorded similarly to this: Debit Credit 11/10/2010 New car 15,000 11/10/2010 New car loan 10,000 11/10/2010 Cash in bank 5,000 Above John says "...the KVP should be on the split, not the transaction,..." but in a later follow-up Derek says that the KVP should be on the transaction and not on the split, noting further that the date is resident in the transaction and not the split. Which of the above in GC terminology is the "transaction" and which the "split"? What makes one of the parts of the above the "transaction" and the others the splits? Can any one of the 3 parts be named the transaction be different people? What keeps the transaction from being arbitrarily identified? In my mind all three parts are splits and there is no transaction unless all three are there with debits and credits in balance. If one or two parts are missing, the transaction is said to be incomplete or broken, because it would not balance. Clearly, GC has a different sense of naming these elements and it is important to include in basic documentation a clear discussion of the terminology as used in the GC world and as used in the Accounting world. I am not interested particularly in changing GC usage. I am interested in understanding clearly how developers see things and why things are perceived that way. Once I see that perspective, then the documentation as presently written will become clearer, at least to this accountant, and I expect others in the Users' List. Thanks to all who can help me with this. Tom ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Terminology Clarification requested
On Dec 9, 2010, at 1:10 PM, Thomas Bullock wrote: > Hi, > > Using this excerpt as a context: > > Message: 1 > Date: Tue, 7 Dec 2010 09:33:58 -0800 > From: John Ralls > Subject: Re: close books > To: Derek Atkins > Cc: devel gnucash > Message-ID: <2b1f2747-854c-430c-8aaa-05637e30a...@ceridwen.us> > Content-Type: text/plain; charset=us-ascii > > > [...] > > A KVP *is* better, but because it's better architecture: The closing-entry > mark would apply only to one transaction per year, would only be important to > one split in that transaction (the income/expense split; one wouldn't want to > hide the split from equity reports), and wouldn't have any applicability to > any transactions which don't touch income or expense accounts. Something of > such limited scope doesn't deserve a column. > > Note that the KVP should be on the split, not the transaction, because many > income/expense reports don't need to look at the whole transaction, they just > need to total up the credits and debits shown in the splits occurring between > two dates. > > Regards, > John Ralls > > > > Let me ask your help as I work my way to a new understanding of the term > "transaction". > > My formation long ago as a young accountant contained this understanding of a > transaction: it was the accounting expression of an activity that happened in > the physical world, which the accounting ledgers were tracking in their own > notation. For example, suppose the activity is buying a car using cash and > debt on 11/10/2010. The accounting transaction is that act of purchase. The > accounting notation was the language of debits and credits with accompanying > names describing the purpose of the monetary "buckets" or value holders. > > Thus, in a journal, the transaction would be recorded similarly to this: > Debit > Credit > 11/10/2010 New car 15,000 > 11/10/2010 New car loan > 10,000 > 11/10/2010 Cash in bank > 5,000 > > Above John says "...the KVP should be on the split, not the transaction,..." > but in a later follow-up > Derek says that the KVP should be on the transaction and not on the split, > noting further that the date is resident in the transaction and not the split. > > Which of the above in GC terminology is the "transaction" and which the > "split"? What makes one of the parts of the above the "transaction" and the > others the splits? Can any one of the 3 parts be named the transaction be > different people? What keeps the transaction from being arbitrarily > identified? > > In my mind all three parts are splits and there is no transaction unless all > three are there with debits and credits in balance. If one or two parts are > missing, the transaction is said to be incomplete or broken, because it would > not balance. > > Clearly, GC has a different sense of naming these elements and it is > important to include in basic documentation a clear discussion of the > terminology as used in the GC world and as used in the Accounting world. I > am not interested particularly in changing GC usage. I am interested in > understanding clearly how developers see things and why things are perceived > that way. Once I see that perspective, then the documentation as presently > written will become clearer, at least to this accountant, and I expect others > in the Users' List. > > Thanks to all who can help me with this. > Tom, Sorry, Derek and I were in programmer mode in that exchange, not accountant mode. We were talking about two data structures in the program, which are mostly equivalent to the accounting terminology. So we have a data structure called a "transaction" that includes a variable number (but at least 2) of subordinate data structures called "split", along with some date fields, and some "key-value" or KVP data. Each split contains an account, an amount, and some more KVP data. The splits are required to balance, otherwise the transaction is marked as unbalanced and displayed with a little gray ☒ in the amount fields. The exchange was about in which data structure it makes more sense to attach a KVP "flag" indicating that it's a closing transaction (i.e, a transaction moving a summary amount from an income or expense account to an equity account). Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: close books
On Thursday 09 December 2010, Frank H. Ellenberger wrote: > Am Mittwoch, 8. Dezember 2010 um 20:46:25 schrieb Derek Atkins: > > Geert Janssens writes: > > > On Tuesday 07 December 2010, John Ralls wrote: > > >> Schema: OK. To make the policy clearer, backwards-incompatible schema > > >> changes in 2.5 require a change to 2.4 to provide a read facility for > > >> the new schema. > > > > > > Do we have a wiki page for this kind of policies ? It will get lost > > > when it's only mentioned on the mailing list... > > > > No, but honestly this particular policy is just common sense.. > > > > -derek > > But for security reasons, I added > http://wiki.gnucash.org/wiki/Development_Process#Backwards-Incompatible_Sch > ema_Changes . > > Frank Thanks ! Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Log File Explosion on Check & Repair
Is it normal for the Check & Repair All command to generate a log file 25x the size of my original XML datafile? I was having problems with very slow loading of my data file, so I ran Check & Repair All a couple of different times, and all of a sudden the partition holding the data file reached capacity. When I looked, the log files were on order of 45-50MB (my stored, compressed file is about 1.7 MB)... David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
