Building gnucash 2.6.0 python bindings on Debian
Hi, I'm a new user to gnucash version 2.6, using a postgresql backend and I'm impressed with it. I used to build invoices using Word and I now intend to use gnucash for accounting. The installed templates don't work for me, so I decided to start building a web interface when I learned about python-gnucash. This web interface should allow me to use templates I'm experienced with to construct an invoice. That's the basic idea. I've got the gnucash GUI running on multiple Windows machines, the postgresql database on a single NAS and I intend to run the web interface on a raspberry pi. I was not able to install pre-build python-gnucash packages, as these are build for version 2.4 and there were version mismatch errors when I used version bindings version 2.4 on a database build with gnucash 2.6. I build the gnucash python bindings using configure --enable-python --disable-gui --enable-locale-specific-tax, make, make install. Importing the gnucash bindings fail after installation. There's a message mentioning the schema is missing: GLib-GIO Settings schema 'org.gnucash.general' is not installed There was a question on the list about that, so the fix was easy, but it got me wondering when the schema files were installed, and I guess that happens when the gui is build, right? Could those files be automatically installed when the python bindings are installed, or any other part of the backend? This enables a developer to build an API distribution only for gnucash, which is exactly what I need at this time ;-) Since I'm posting to the list; there's a warning message when I import gnucash: -- process:1075): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: No such file or directory -- Is there something I can do about this? For reference; there was a dbus message too: -- * 20:51:19 WARN Command line `dbus-launch --autolaunch=57ae80824714b7b337db9bbc5115ac19 --binary-syntax --close-stderr' exited with non-zero exit status 1: Autolaunch error: X11 initialization failed.\n -- That message is gone when dbus is started in shell syntax and the script is started afterwards: eval `dbus-launch --sh-syntax` Thanks, Bas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building gnucash 2.6.0 python bindings on Debian
Hi Bas, On Wednesday 15 January 2014 21:08:34 Bas ten Berge wrote: Hi, I'm a new user to gnucash version 2.6, using a postgresql backend and I'm impressed with it. I used to build invoices using Word and I now intend to use gnucash for accounting. The installed templates don't work for me, so I decided to start building a web interface when I learned about python-gnucash. This web interface should allow me to use templates I'm experienced with to construct an invoice. That's the basic idea. Tom Lofts contributed an initial REST api to the python bindings which may be useful for your situation. I've got the gnucash GUI running on multiple Windows machines, the postgresql database on a single NAS and I intend to run the web interface on a raspberry pi. I was not able to install pre-build python-gnucash packages, as these are build for version 2.4 and there were version mismatch errors when I used version bindings version 2.4 on a database build with gnucash 2.6. You probably know already but I'll repeat the mantra anyway: don't be tempted to open you database simultaneously with multiple users. You will have to time-share your access one user at the time. Ignoring this will at best leave one user with outdated information or in the worst case data loss. I'm thinking particularly at your webserver user. Here are some design considerations: - you can't have the webapi keep the GnuCash book open all the time. GnuCash loads all data into memory at startup and only looks at that data until it's closed again. So if the web user opens the book permanently, it will see outdated information as soon as another user on a Windows machine changes anything. (GnuCash writes each change immediately through to the database but assuming your web-api will access the file read-only, that's not relevant here) - so given you should open the GnuCash book each time the web-server needs access to it the size of your book may at some point become a bottleneck. As I just mentioned GnuCash reads the whole book into memory when it's opened. So that would mean that the whole book is read for each web access you do. For a small book that's not too important. But I have a book for example with 10 years of history which takes about half a minute to open via the python bindings. Doing that for each web-access may be a slow solution. I build the gnucash python bindings using configure --enable-python --disable-gui --enable-locale-specific-tax, make, make install. Importing the gnucash bindings fail after installation. There's a message mentioning the schema is missing: GLib-GIO Settings schema 'org.gnucash.general' is not installed There was a question on the list about that, so the fix was easy, but it got me wondering when the schema files were installed, and I guess that happens when the gui is build, right? Could those files be automatically installed when the python bindings are installed, or any other part of the backend? This enables a developer to build an API distribution only for gnucash, which is exactly what I need at this time ;-) The schema files are indeed installed together with the gui components. Frankly the --disable- gui hasn't been tested in years IMO. GnuCash is primarily a desktop application and not a library or service. Having said that I don't think there's a strong reason it should stay that way. The main schema files could easily be installed in for example the app-utils module. This module is responsible anyway for the GSettings backend. A couple of schemas are only installed as part of optional modules (like aqbanking and ofx). These can remain in their respective directories. Can you file this as an enhancement request in bugzilla [1] ? Since I'm posting to the list; there's a warning message when I import gnucash: -- process:1075): GLib-WARNING **: GError set over the top of a previous GError or uninitialized memory. This indicates a bug in someone's code. You must ensure an error is NULL before it's set. The overwriting error message was: No such file or directory -- Is there something I can do about this? You could try to figure out which error is being set first and overridden later by using a combination of gdb and setting G_DEBUG to fatal-warnings [2] For reference; there was a dbus message too: -- * 20:51:19 WARN Command line `dbus-launch --autolaunch=57ae80824714b7b337db9bbc5115ac19 --binary-syntax --close-stderr' exited with non-zero exit status 1: Autolaunch error: X11 initialization failed.\n -- That message is
Re: Building on Windows from scratch - guile problem SOLVED
On Friday 10 January 2014 17:41:15 Gary Bilkus wrote: On 10/01/2014 15:03, John Ralls wrote: On Jan 9, 2014, at 11:13 PM, Gary Bilkus m...@gary.bilkus.com wrote: Well, interestingly enough, the problem is not directly with the compiler optimizer. It's with the configure test for strncasecmp. This test fails on mingw in its current incarnation because guile uses a standard test for the function, but on mingw strncasecmp is actually a cpp definition. As a result, guile is compiled with #HAVE_STRNCASECMP unset, and so guile tries to create its own version in read.c Now if you compile with no optimization, the compiler notices that read.c is attempting to create this with a different signature and bombs out. However, with optimisation on, the code compiles for some reason, and then fails to run properly. So there seem to be two problems: one in configure for guile and/or the standard configure macros on mingw, the other in the compiler. Fortunately, there's a very easy although ugly workaround, which is to add an echo #define HAVE_STRNCASECMP config.h Would adding -DHAVE_STRNCASECMP to $CFLAGS work? It's a bit cleaner than echoing a #define into the config header. Better yet, sometimes there's a variable that can be defined on the configure command line -- perhaps $ac_have_strncasecmp -- to force configure to do the right thing. in install-impl.sh just after the guile configure and before the make I've incorporated this fix into my downloadable file of fixes as referred to on the wiki page I updated. More as and when I find any further issues. As always, feedback or other experiences welcome. Regards, John Ralls I agree that the configure commandline change would be cleaner, and if I can find out what to do I'll change my fix. I disagree that a CFLAGS define is cleaner. With my solution the define is in the right file, even if it gets there for the wrong reason. That way, it guarantees not to affect any compilation which doesn't involve including config.h, which saves having to check for any unexpected consequenses elsewhere. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel Gary, Thanks for all your updates. Today I found some time to check which of your fixes I should still add to my windows branch, but got lost in your patch. It looks like you are generating a patch to be applied to the current trunk branch, including all the separate commits from my branch. Unfortunately that makes it hard if not impossible to see only the changes needed on my branch. It's not the intention to apply such a large patch one day to current trunk. Instead my branch will be merged in eventually (likely after the 2.6 branch is generated and certainly not before the dist part and build server scripts are also fixed). So can you extract only the changes that still need to be applied to my branch please ? Ideally split up in small patches per topic (fix -no-undefined, fix guile's str_ncase_comp, ...). That way we generate clean and readable history in the repository. You may want to set up your own clone of the git repository [1] as git can be very helpful in generating such patches. Thanks, Geert [1] http://wiki.gnucash.org/wiki/Git#Non-Committers ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Thursday 16 January 2014 11:10:30 Geert Janssens wrote: Gary, Thanks for all your updates. Today I found some time to check which of your fixes I should still add to my windows branch, but got lost in your patch. It looks like you are generating a patch to be applied to the current trunk branch, including all the separate commits from my branch. Unfortunately that makes it hard if not impossible to see only the changes needed on my branch. It's not the intention to apply such a large patch one day to current trunk. Instead my branch will be merged in eventually (likely after the 2.6 branch is generated and certainly not before the dist part and build server scripts are also fixed). So can you extract only the changes that still need to be applied to my branch please ? Ideally split up in small patches per topic (fix -no-undefined, fix guile's str_ncase_comp, ...). That way we generate clean and readable history in the repository. You may want to set up your own clone of the git repository [1] as git can be very helpful in generating such patches. Thanks, Geert [1] http://wiki.gnucash.org/wiki/Git#Non-Committers Also note that I have rebased the mingw-rebasing branch again in my repository to pick up the most recent version of aqbanking and gwenview. I haven't had the opportunity yet to check if these versions build in the new mingw environment. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch
On Thursday 26 December 2013 17:41:14 Geert Janssens wrote: On Wednesday 25 December 2013 18:46:32 Gary Bilkus wrote: On 24/12/2013 18:25, Gary Bilkus wrote: - There seems to be a version issue with GWENHYFAR_VERSION It builds OK but every time I restart it rebuilds. For some reason it's built a version which annouces itself as 4.7.0beta even though the file it downloads says it's 4.8.0beta If I build and change the version to 4.7.0beta it doesn't then try and rebuild each time. But seems a bit strange. That looks like a bug in Gwenhywfar then. In the end I don't think this is a Gwenhywfar bug. The download url specifies both the gwen version and some download id number. Both have to be updated when a new version of gwen is available. I missed the update to the id number. This should be fixed with Christian's more recent gwen/aqbanking updates. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 16/01/2014 11:43, Geert Janssens wrote: On Thursday 16 January 2014 11:10:30 Geert Janssens wrote: Gary, Thanks for all your updates. Today I found some time to check which of your fixes I should still add to my windows branch, but got lost in your patch. It looks like you are generating a patch to be applied to the current trunk branch, including all the separate commits from my branch. Unfortunately that makes it hard if not impossible to see only the changes needed on my branch. It's not the intention to apply such a large patch one day to current trunk. Instead my branch will be merged in eventually (likely after the 2.6 branch is generated and certainly not before the dist part and build server scripts are also fixed). So can you extract only the changes that still need to be applied to my branch please ? Ideally split up in small patches per topic (fix -no-undefined, fix guile's str_ncase_comp, ...). That way we generate clean and readable history in the repository. You may want to set up your own clone of the git repository [1] as git can be very helpful in generating such patches. Thanks, Geert [1] http://wiki.gnucash.org/wiki/Git#Non-Committers Also note that I have rebased the mingw-rebasing branch again in my repository to pick up the most recent version of aqbanking and gwenview. I haven't had the opportunity yet to check if these versions build in the new mingw environment. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel So just to make sure I understand exactly what you need. 1. I should get the gnucash.git repository from git://github.com:gjanssens/gnucash.git 2. I should git branch -t mingw origin/mingw-rebasing and check out that branch 3. I should appy my patches to that branch - ignoring any which are already there 4. I should run git diff to get a series of patches against the branch in the repository 5. I should split the resulting diff into different files relating to the different fixes 6. I should post the result somewhere and tell you where it is Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Thursday 16 January 2014 12:14:49 Gary Bilkus wrote: So just to make sure I understand exactly what you need. 1. I should get the gnucash.git repository from git://github.com:gjanssens/gnucash.git 2. I should git branch -t mingw origin/mingw-rebasing and check out that branch 3. I should appy my patches to that branch - ignoring any which are already there 4. I should run git diff to get a series of patches against the branch in the repository 5. I should split the resulting diff into different files relating to the different fixes 6. I should post the result somewhere and tell you where it is Gary Gary, That's close. But git's workflow is slightly different: 1 and 2 are correct 3. Apply your patches and ignore those that are already there is also correct. Then before committing anything it's worth considering which changes logically belong together and check these changes in in separate commits. 'git add -i' will be tremendously helpful for this part (adding changes into the index interactively). 4. Each time you have added a coherent set of changes to the index file, you can create a (local) commit using 'git commit'. You may want to use clear commit messages in this step as they will eventually end up in the master repository. You can look at my commits for examples but they're only that not hard rules. I suggest though that you explicitly add an author line in your commit message. Since we're still linked to the svn repo, git's author information gets lost for non-committers when we commit to the master repository. This line is in the form: Author: name email 5. When there are no more changes to commit, you can run 'git format-patch' to generate a series of patch files like so: git format-patch origin/mingw-rebasing That should generate the patch files in the current working directory. 6. The normal way to make these patches available to me is to create an enhancement request in bugzilla and attach the patches there. But in this case I'm equally fine if you post them to the list or tell me where you stored them on your own server or whatever. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
Gary, While looking at your changes I noticed you changed two lines in the vbs script. One is that you added my repository/branch in a comment. That's ok and makes it easier for others to start. The second is to install msys-patch. Is there a reason you do this in the vbs script and not in install-impl.sh ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On 16/01/2014 13:26, Geert Janssens wrote: Gary, While looking at your changes I noticed you changed two lines in the vbs script. One is that you added my repository/branch in a comment. That's ok and makes it easier for others to start. The second is to install msys-patch. Is there a reason you do this in the vbs script and not in install-impl.sh ? Geert Hi Geert. The reason I added in msys-patch to my version of your script is so that the instructions I posted on the wiki would work, since they tell you to run your vbs script and then run patch against the 2.6 repo with my patchfile, and that doesn't work if you don't yet have patch installed. Of course, as and when there's a git repo with the patches already incorporated, that step is no longer needed and nor is patch. But it doesn't do much harm to leave it around, and would make it easier for people who have to play catch-up the next time a downstream dependency gets broken. Gary ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Thursday 16 January 2014 15:06:55 Gary Bilkus wrote: On 16/01/2014 13:26, Geert Janssens wrote: Gary, While looking at your changes I noticed you changed two lines in the vbs script. One is that you added my repository/branch in a comment. That's ok and makes it easier for others to start. The second is to install msys-patch. Is there a reason you do this in the vbs script and not in install-impl.sh ? Geert Hi Geert. The reason I added in msys-patch to my version of your script is so that the instructions I posted on the wiki would work, since they tell you to run your vbs script and then run patch against the 2.6 repo with my patchfile, and that doesn't work if you don't yet have patch installed. Of course, as and when there's a git repo with the patches already incorporated, that step is no longer needed and nor is patch. But it doesn't do much harm to leave it around, and would make it easier for people who have to play catch-up the next time a downstream dependency gets broken. Gary Hi Gary, That makes sense. The reason I'm very cautious about adding stuff in the bootstrap script is that mingw-get is fairly fragile. The bootstrap script unconditionally installs the most recent version of the various packages, but in the install.sh script we force specific versions. If at some point the most recent version is more recent than what we explicitly set this will probably cause mingw-get to error out. That may or may not be bad but at least pretty confusing to new users. We may fix this by installing very specific versions in the bootstrap script already instead of the latest available. Although that approach risks that these versions will at some point get out of sync with the versions defined in defaults.sh. But IMO that is less of an issue. If this happens the installation script will update the packages to the proper versions without errors the first time it runs. I'll admit this is close to nitpicking. There are bigger issues to solve right now, but I mention it because now I noticed it. I will probably forget later on. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Jan 16, 2014, at 5:23 AM, Geert Janssens janssens-ge...@telenet.be wrote: 3. Apply your patches and ignore those that are already there is also correct. Then before committing anything it's worth considering which changes logically belong together and check these changes in in separate commits. 'git add -i' will be tremendously helpful for this part (adding changes into the index interactively). Pardon me for barging in. I just want to add that a git GUI makes it much less painful to pull diffs apart into commits compared to `git add -i`. TortoiseGit (http://code.google.com/p/tortoisegit/) works well on M$Windows. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch - guile problem SOLVED
On Thursday 16 January 2014 07:49:53 John Ralls wrote: On Jan 16, 2014, at 5:23 AM, Geert Janssens janssens-ge...@telenet.be wrote: 3. Apply your patches and ignore those that are already there is also correct. Then before committing anything it's worth considering which changes logically belong together and check these changes in in separate commits. 'git add -i' will be tremendously helpful for this part (adding changes into the index interactively). Pardon me for barging in. I just want to add that a git GUI makes it much less painful to pull diffs apart into commits compared to `git add -i`. TortoiseGit (http://code.google.com/p/tortoisegit/) works well on M$Windows. Regards, John Ralls Interesting. I never used a gui for this yet. Which one do you use on your mac ? Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building on Windows from scratch
(Oops, this was meant to go to the list not Gary directly) On Thursday 16 January 2014 12:06:15 Gary Bilkus wrote: On 16/01/2014 11:53, Geert Janssens wrote: On Thursday 26 December 2013 17:41:14 Geert Janssens wrote: On Wednesday 25 December 2013 18:46:32 Gary Bilkus wrote: On 24/12/2013 18:25, Gary Bilkus wrote: - There seems to be a version issue with GWENHYFAR_VERSION It builds OK but every time I restart it rebuilds. For some reason it's built a version which annouces itself as 4.7.0beta even though the file it downloads says it's 4.8.0beta If I build and change the version to 4.7.0beta it doesn't then try and rebuild each time. But seems a bit strange. That looks like a bug in Gwenhywfar then. In the end I don't think this is a Gwenhywfar bug. The download url specifies both the gwen version and some download id number. Both have to be updated when a new version of gwen is available. I missed the update to the id number. This should be fixed with Christian's more recent gwen/aqbanking updates. Geert The latest version of gwenhyfar which one can download manually says it's 4.9.0beta but the tar file internally has a directory name of 4.7.0beta and that's what it unpacks to. That probably doesn't affect the build much, but it is confusing if nothing else. Hmm, I reran the test. With my branch it now properly unpacks into 4.9.0beta. Are you sure your defaults.sh has updated both the file version and download id ? If not you are probably really downloading 4.7.0beta but renamed to 4.9.0beta by the website software. I have dropped the gwen patch by the way. It appears to be included in 4.9.0beta. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Building gnucash 2.6.0 python bindings on Debian
Hi,
Since I'm posting to the list; there's a warning message when I import
gnucash:
--
process:1075): GLib-WARNING **: GError
set over the top of a previous GError or uninitialized memory.
This indicates a bug in someone's code. You must ensure an error is
NULL before it's set.
The overwriting error message was: No such file or directory
--
Is there something I can do about this?
Getting rid of GLib-WARNING message appeared to be really simple. The
python-bindings - or a part thereof - were looking for the GNUCash
environment file, which was not installed. I guess it gets installed when
the gui is installed. I created a file named
/usr/local/etc/gnucash/environment containing only this:
---
[Variables] LANG=nl_NL LANGUAGE={LANG}
---
Thanks again, Bas
On Thu, Jan 16, 2014 at 10:21 AM, Geert Janssens
janssens-ge...@telenet.bewrote:
Hi Bas,
On Wednesday 15 January 2014 21:08:34 Bas ten Berge wrote:
Hi,
I'm a new user to gnucash version 2.6, using a postgresql backend and
I'm impressed with it. I used to build invoices using Word and I now
intend to use gnucash for accounting. The installed templates don't
work for me, so I decided to start building a web interface when I
learned about python-gnucash. This web interface should allow me to
use templates I'm experienced with to construct an invoice. That's
the basic idea.
Tom Lofts contributed an initial REST api to the python bindings which may
be useful for your situation.
I've got the gnucash GUI running on multiple Windows machines, the
postgresql database on a single NAS and I intend to run the web
interface on a raspberry pi. I was not able to install pre-build
python-gnucash packages, as these are build for version 2.4 and there
were version mismatch errors when I used version bindings version 2.4
on a database build with gnucash 2.6.
You probably know already but I'll repeat the mantra anyway: don't be
tempted to open you database simultaneously with multiple users. You will
have to time-share your access one user at the time. Ignoring this will at
best leave one user with outdated information or in the worst case data
loss.
I'm thinking particularly at your webserver user. Here are some design
considerations:
- you can't have the webapi keep the GnuCash book open all the time.
GnuCash loads all data into memory at startup and only looks at that data
until it's closed again. So if the web user opens the book permanently, it
will see outdated information as soon as another user on a Windows machine
changes anything. (GnuCash writes each change immediately through to the
database but assuming your web-api will access the file read-only, that's
not relevant here)
- so given you should open the GnuCash book each time the web-server needs
access to it the size of your book may at some point become a bottleneck.
As I just mentioned GnuCash reads the whole book into memory when it's
opened. So that would mean that the whole book is read for each web access
you do. For a small book that's not too important. But I have a book for
example with 10 years of history which takes about half a minute to open
via the python bindings. Doing that for each web-access may be a slow
solution.
I build the gnucash python bindings using configure --enable-python
--disable-gui --enable-locale-specific-tax, make, make install.
Importing the gnucash bindings fail after installation. There's a
message mentioning the schema is missing:
GLib-GIO Settings schema 'org.gnucash.general' is not installed
There was a question on the list about that, so the fix was easy, but
it got me wondering when the schema files were installed, and I guess
that happens when the gui is build, right? Could those files be
automatically installed when the python bindings are installed, or
any other part of the backend? This enables a developer to build an
API distribution only for gnucash, which is exactly what I need at
this time ;-)
The schema files are indeed installed together with the gui components.
Frankly the --disable-gui hasn't been tested in years IMO. GnuCash is
primarily a desktop application and not a library or service.
Having said that I don't think there's a strong reason it should stay that
way. The main schema files could easily be installed in for example the
app-utils module. This module is responsible anyway for the GSettings
backend. A couple of schemas are only installed as part of optional modules
(like aqbanking and ofx). These can remain in their respective directories.
Can you file this as an enhancement request in bugzilla [1] ?
Re: Replacement for libdbi
Hi all, I think I'm the crazy guy trying to re-write GnuCash to use GDA. Now I'm one of the maintainers of GDA on GObject Introspection and Vala bindings support, but patch some things here and there when possible. May be is time you consider to use GDA, it has a current Debian version and well supported on other distros, at 5.0 and recently released 5.2.2 waiting some one to package and that and regularly happens. Hope when you say to move away from Gtk you don't mean from GLIb/GObject, because that is a hard dependency of GDA. GDA has a C++ bindings if that helps you [1]. GDA has lots of features, including transactions, SQL parsing, multiple connections to different databases and more. I would like to know what features you require in order to check its availability. Please check C [2] and C++ [3] documentation I've written a (hope to be) a Vala library in GDA source code, to try make more easy to access a database, may be close to QOF. It provides a C/GObject interface too, because Vala. May be you can test Vala Extensions and GDA. Vala bindings and Vala Extensions, can be used from C with no problem. It's a candy to use GDA from Vala and Vala Extensions [4] May I can help you in some way. I'm a C/Vala guy now, then for GDA bindings C++ support, contact Murray Cumming. [1] https://git.gnome.org/browse/libgdamm/ [2] https://developer.gnome.org/libgda/5.2/ [3] https://developer.gnome.org/libgdamm/ [4] https://wiki.gnome.org/Projects/GdaValaExtensions 2014/1/13 Derek Atkins warl...@mit.edu Sébastien Villemot sebast...@debian.org writes: Concerning the time_t issue, I could carry a Debian-specific patch if that change was not modifying the ABI (but I guess it does on 32-bit archs). And anyways that would not fix the issue for other GNU/Linux distributions. I could however add my voice to convince libdbi developers. Is there a bug report to track this issue? Unfortunately that doesn't help us; we'd have to find people on every Linux distribution to maintain that patch, and we would have to somehow test for it to make sure it was working right. :-( -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 -- Trabajar, la mejor arma para tu superación de grano en grano, se hace la arena (R) (en trámite, pero para los cuates: LIBRE) ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Replacement for libdbi
On Jan 16, 2014, at 2:36 PM, Daniel Espinosa eso...@gmail.com wrote: Hi all, I think I'm the crazy guy trying to re-write GnuCash to use GDA. Now I'm one of the maintainers of GDA on GObject Introspection and Vala bindings support, but patch some things here and there when possible. May be is time you consider to use GDA, it has a current Debian version and well supported on other distros, at 5.0 and recently released 5.2.2 waiting some one to package and that and regularly happens. Hope when you say to move away from Gtk you don't mean from GLIb/GObject, because that is a hard dependency of GDA. GDA has a C++ bindings if that helps you [1]. GDA has lots of features, including transactions, SQL parsing, multiple connections to different databases and more. I would like to know what features you require in order to check its availability. Please check C [2] and C++ [3] documentation I've written a (hope to be) a Vala library in GDA source code, to try make more easy to access a database, may be close to QOF. It provides a C/GObject interface too, because Vala. May be you can test Vala Extensions and GDA. Vala bindings and Vala Extensions, can be used from C with no problem. It's a candy to use GDA from Vala and Vala Extensions [4] May I can help you in some way. I'm a C/Vala guy now, then for GDA bindings C++ support, contact Murray Cumming. [1] https://git.gnome.org/browse/libgdamm/ [2] https://developer.gnome.org/libgda/5.2/ [3] https://developer.gnome.org/libgdamm/ [4] https://wiki.gnome.org/Projects/GdaValaExtensions Nope, not just Gtk, GLib and especially GObject. Vala is right out. Sorry. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
base-typemaps.i and budgets
In attempting to use qof query to look up budgets I have come across an issue in base-typemaps.i for which Im not sure would be the approved way to fix. The first python Query class usage to attempt to return budgets returned a list of gnc_monetary types, yet it should have been GncBudget. (note the only implementation involved was in python setting up the query and calling the query run function). This appears to be a problem in the swig out typemap in base-typemaps.i for GList type structures. This typemap is defined differently for python versus scheme - here Im specifically dealing with the Python version. Currently there is a test for some specific list element data types which then types each data element. However, there is a special test for MonetaryList which maps the gnc_monetary type. else if ($1_descriptor == $descriptor(MonetaryList *)) PyList_Append(list, SWIG_NewPointerObj(data, $descriptor(gnc_monetary *), 0)); The problem found returning budgets is that this matches any arbitrary GList whose type is not defined in the previous else if components of the if structure, hence a list of budgets is returned as a list of gnc_monetary type. So far Ive created a separate out typemap for MonetaryList specifically which assumes the elements of a MonetaryList are all gnc_monetary type. (Its not clear to me its possible for it to be anything else). I removed the above test from the more generic GList out typemap and added a specific check for data elements of the swig budget type similar the current style. Question is why is this routine defined for various specific types eg CommodityList *, SplitList *, AccountList *, LotList *, PriceList *, EntryList * where it seems to me the elements must always be of a specific type. Also, returning a void type for untested element types would seem to me to be better than returning a wrong type for a generic GList (it may be possible to re-map the swig void type in python later). David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
