Menu
▾
▴
libdbi-devel
|
From: Christoph H. <c.h...@gm...> - 2011-01-27 13:06:32
|
Hello !
I'm using GnuCash with a MySql backend using libdbi. There are some
strange errors with some versions of libdbi for which a workaround has been built
which says one should change the version of libdbi. This error message has just
been included and it stops me from using my financial data. Because of that
i tried to find the error. At the moment it seems to me that it is linked to
dbi_conn_queryf.
The test in Gnucash calls it with
result = dbi_conn_queryf( conn,
"INSERT INTO numtest VALUES (%lld, %llu, %17e)",
testlonglong, testulonglong, testdouble );
where
gint64 testlonglong = -9223372036854775807LL, resultlonglong = 0;
guint64 testulonglong = 9223372036854775807LLU, resultulonglong = 0;
gdouble testdouble = 1.7976921348623157E+307, resultdouble = 0.0;
This fails at my system. The logfile of MySql states
110127 13:40:28 21 Connect christoph@localhost on gnucash
21 Query CREATE TEMPORARY TABLE numtest ( test_int BIGINT, test_unsigned BIGINT, test_double FLOAT8 )
21 Query INSERT INTO numtest VALUES (-9223372036854775807, 9223372036854775807, 1,797692e+307)
The last row is wrong because it is 1,797692e+307 instead of 1.797692e+307. The separator is wrong. I guess this is because
the locale for germany where i live puts it that way.
I don't know if this is a feature or a bug. But i guess it would make life simpler if printf in that function wouldn't be so locale specific ;-)
I'm not a C programmer and I'm not sure if the solution should be a change of libdbi or GnuCash.
regards,
Christoph Holtermann
|
|
From: Christoph H. <c.h...@gm...> - 2011-01-27 13:12:55
|
Hello ! Further information can be found at: http://www.mail-archive.com/gnu...@gn.../msg28150.html and https://bugzilla.gnome.org/show_bug.cgi?id=611936 regards, Christoph Holtermann Am 27.01.2011 14:10, schrieb Christoph Holtermann: > Hello ! > > I'm using GnuCash with a MySql backend using libdbi. There are some > strange errors with some versions of libdbi for which a workaround has been built > which says one should change the version of libdbi. This error message has just > been included and it stops me from using my financial data. Because of that > i tried to find the error. At the moment it seems to me that it is linked to > dbi_conn_queryf. > The test in Gnucash calls it with > result = dbi_conn_queryf( conn, > "INSERT INTO numtest VALUES (%lld, %llu, %17e)", > testlonglong, testulonglong, testdouble ); > where > gint64 testlonglong = -9223372036854775807LL, resultlonglong = 0; > guint64 testulonglong = 9223372036854775807LLU, resultulonglong = 0; > gdouble testdouble = 1.7976921348623157E+307, resultdouble = 0.0; > > This fails at my system. The logfile of MySql states > > 110127 13:40:28 21 Connect christoph@localhost on gnucash > 21 Query CREATE TEMPORARY TABLE numtest ( test_int BIGINT, test_unsigned BIGINT, test_double FLOAT8 ) > 21 Query INSERT INTO numtest VALUES (-9223372036854775807, 9223372036854775807, 1,797692e+307) > > The last row is wrong because it is 1,797692e+307 instead of 1.797692e+307. The separator is wrong. I guess this is because > the locale for germany where i live puts it that way. > > I don't know if this is a feature or a bug. But i guess it would make life simpler if printf in that function wouldn't be so locale specific ;-) > > I'm not a C programmer and I'm not sure if the solution should be a change of libdbi or GnuCash. > > regards, > > Christoph Holtermann |
|
From: Artyom <art...@ya...> - 2011-01-27 13:57:42
|
Hi, libdbi uses standard sprintf or asprintf and it is defenatelly not something simple to fix. As standard C library does not provide any "reasonable" tool to format and parse double without connection with current locale (atof would fail to parse "1.3" in "de_DE.UTF-8") I think you would have to use C locale at least when you call libdbi (if your program is single threaded it would be ok to swich locale in run time). setlocale(LC_ALL,"C"); do queries setlocale(LC_ALL,""); If you program in C++ it would be simpler as it has things to do this correctly. Note: I'm not libdbi developer. Artyom ----- Original Message ---- > From: Christoph Holtermann <c.h...@gm...> > To: lib...@li... > Sent: Thu, January 27, 2011 3:17:12 PM > Subject: Re: [libdbi-devel] locale > > Hello ! > > Further information can be found at: > > http://www.mail-archive.com/gnu...@gn.../msg28150.html > and > https://bugzilla.gnome.org/show_bug.cgi?id=611936 > > regards, > > Christoph Holtermann > > Am 27.01.2011 14:10, schrieb Christoph Holtermann: > > Hello ! > > > > I'm using GnuCash with a MySql backend using libdbi. There are some > > strange errors with some versions of libdbi for which a workaround has been >built > > which says one should change the version of libdbi. This error message has >just > > been included and it stops me from using my financial data. Because of that > > i tried to find the error. At the moment it seems to me that it is linked to > > dbi_conn_queryf. > > The test in Gnucash calls it with > > result = dbi_conn_queryf( conn, > > "INSERT INTO numtest VALUES (%lld, %llu, >%17e)", > > testlonglong, testulonglong, testdouble ); > > where > > gint64 testlonglong = -9223372036854775807LL, resultlonglong = 0; > > guint64 testulonglong = 9223372036854775807LLU, resultulonglong = 0; > > gdouble testdouble = 1.7976921348623157E+307, resultdouble = 0.0; > > > > This fails at my system. The logfile of MySql states > > > > 110127 13:40:28 21 Connect christoph@localhost on gnucash > > 21 Query CREATE TEMPORARY TABLE numtest ( test_int >BIGINT, test_unsigned BIGINT, test_double FLOAT8 ) > > 21 Query INSERT INTO numtest VALUES >(-9223372036854775807, 9223372036854775807, 1,797692e+307) > > > > The last row is wrong because it is 1,797692e+307 instead of 1.797692e+307. >The separator is wrong. I guess this is because > > the locale for germany where i live puts it that way. > > > > I don't know if this is a feature or a bug. But i guess it would make life >simpler if printf in that function wouldn't be so locale specific ;-) > > > > I'm not a C programmer and I'm not sure if the solution should be a change >of libdbi or GnuCash. > > > > regards, > > > > Christoph Holtermann > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > libdbi-devel mailing list > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdbi-devel > |
|
From: <mar...@mh...> - 2011-01-27 22:08:11
|
Christoph Holtermann writes: > Hello ! > > Further information can be found at: > > http://www.mail-archive.com/gnu...@gn.../msg28150.html > and > https://bugzilla.gnome.org/show_bug.cgi?id=611936 > Hi, first of all, I was surprised to learn that GnuCash uses libdbi these days. One more reason to finally get a feature-complete and bug-free 1.0 done! A few comments to the problems that you reported here and in the mailing list threads above. 1) I think Artyom is right in that the library libdbi cannot do much about how a program linked against it influences (or doesn't influence) printf's interactions with locale settings. One of the GnuCash developers obviously included some patch for this problem. I hope this is going to work for you. 2) if not, would it be possible to set a different locale in a GnuCash start script as a temporary workaround? 3) we seem to have a bootstrapping issue with building our new test kit. I've seen similar problems after "make check", however they seem to exist only on first-time installations. The reason seems to be that gcc doesn't pick up the libdbi headers although an appropriate option (-I/usr/include in your case) is present. I haven't got around debugging this and I'd appreciate if others could confirm this problem or report how to get around it. 4) we do have a problem with an outdated and ill-conceived build system. It should be modified to pick up user-defined CFLAG and LDFLAG settings, and it should drop those platform-specific optimizations and leave that to either package maintainers or to users who know what they're doing. This includes the -ffast-math option which obviously gets in your way. This was requested recently on the ML or in a tracker item. 5) we have rewritten the test kit completely. The tests are now designed to detect incorrect return values in addition to any program failures. However, your make test snippet (apparently from GnuCash's copy of the old test kit) indicates that the _tz data are expected to be returned as 0 because the tests were skipped for that driver. I'd have to investigate why this is the case here. It should not happen in the latest versions as MySQL does support timezones IIRC. In any case, please let us know if the GnuCash developers' latest patches make things work for you. I'll try to fix the above-mentioned libdbi issues as soon as time permits. Running libdbi-based apps shouldn't be that disappointing, after all. regards, Markus -- Markus Hoenicka http://www.mhoenicka.de AQ score 38 |
Thanks for helping keep SourceForge clean.
X