Modifying currency fractions has no effect?
Arising from Debian bug #333664: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=333664 What is the purpose of the drop down box to modify the commodity fraction when creating a new account? Should this drop-down list even be visible when the user has selected a currency for the account? Why allow users to modify the fraction of a known currency? The current (svn + 1.9.5) behaviour is that if the user chooses a currency (like the Hungarian Florint) that has a fraction of 1 and then changes that fraction in the same dialogue (because they can) to 1/100, gnucash ignores the dialogue setting when using the account. Entering 12.99 in a withdrawal from such an account results in the transaction showing only 12 - just as it does in an account where the fraction has not been changed in the dialogue. Is this a gnucash bug? If so, which is the proper behaviour? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpsEciKAVTjS.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Translation Wiki --> msgmerge
On Sunday 16 April 2006 6:59 pm, Bernie wrote: > Hi, > > When I do a "rpm -qf /usr/bin/msgmergev " I get "error: I hope that terminal 'v' was a typo. > file /usr/bin/msgmerge: no such file or directory" > When I do > "rpm -q gettext" > I get "gettext-0.14.3-6" so I have the package gettext installed on my > system. When I do > "rpm -ql gettext | grep msgmerge" > the prompt returns without any result .. http://lists.opensuse.org/archive/opensuse/2005-Nov/0236.html It looks like opensuse packages msgmerge in gettext-devel. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpYe8YG8TkvY.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Translation Wiki --> msgmerge
On Sunday 16 April 2006 5:57 pm, Bernie wrote: > glossary file" , it is referred to the "msgmerge" program. However, on my > machine (Opensuse 10.1 x86_64) I am unable to find this program (which > should be in /usr/bin) and cannot find any package containing this program > using Yast. Where can I find this ?? Google for msgmerge suse rpm gettext-0.11.5-33.i586 RPM ... Mar 08 2001 - [EMAIL PROTECTED] - Use more rpm macros. ... 0.10.32 * Wed Jan 22 1997 - [EMAIL PROTECTED] - update ... usr/bin/msggrep /usr/bin/msginit The link is to a SuSE 8.1 RPM but you get the idea. :-) Search YAST for gettext. Nearly every GNU translation process involves gettext. For more help, see http://www.iro.umontreal.ca/translation/HTML/ -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpsRWMWO84cN.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13786 - gnucash/trunk - The kvp_frame_get_string() function returns a pointer to an internal
On Saturday 15 April 2006 7:44 pm, David Hampton wrote: > On Sat, 2006-04-15 at 19:23 +0100, Neil Williams wrote: > > On Saturday 15 April 2006 5:40 pm, David Hampton wrote: > > >gnucash/trunk/lib/libqof/qof/kvp_frame.c > > >gnucash/trunk/lib/libqof/qof/kvp_frame.h > > > Log: > > > The kvp_frame_get_string() function returns a pointer to an internal > > > string. Mark it 'const' to prevent callers from trying to free it. > > > > And the API clearly marks it as such - this is gnucash's error, not QOF. > > I diagree 100%. Without a const declaration the API doesn't clearly > mark this function as returning a read-only value. You are hoping that > all developers will read your documentation instead of taking the smart > approach of having the compiler to strictly enforce the requirement. > Maybe, and I'll probably review it during the transition but right now, that is the QOF API. I didn't make that choice. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp0B4Mi2PazI.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13786 - gnucash/trunk - The kvp_frame_get_string() function returns a pointer to an internal
On Saturday 15 April 2006 5:40 pm, David Hampton wrote: >gnucash/trunk/lib/libqof/qof/kvp_frame.c >gnucash/trunk/lib/libqof/qof/kvp_frame.h > Log: > The kvp_frame_get_string() function returns a pointer to an internal > string. Mark it 'const' to prevent callers from trying to free it. And the API clearly marks it as such - this is gnucash's error, not QOF. kvp_frame_get_string is a wrapper around kvp_value_get_string. It simply gets the value at the path requested in the frame specified and calls kvp_value_get_string for that value. /** Value accessor. This one is non-copying -- the caller can modify * the value directly. */ The values returned for GUID, binary, GList, KvpFrame and string are "non-copying" -- the returned item is the actual item stored. Do not delete this item unless you take the required care to avoid possible bad pointer derefrences (i.e. core dumps). Also, be careful hanging on to those references if you are also storing at the same path names: the referenced item will be freed during the store. http://qof.sourceforge.net/doxy/group__KVP.html (Section on KvpFrame Value Fetching that includes kvp_frame_get_string) The current API requires that the user keeps tabs on which functions are used to set and get values, which ones are copying and which are non-copying. I can't accept your changes, David. Fix the gnucash code, don't break QOF. > + * lib/libqof/qof/kvp_frame.[ch]: The kvp_frame_get_string() > + function returns a pointer to an internal string. Mark it 'const' > + to prevent callers from trying to free it. The error is in the gnucash functions, not QOF. I'll be reviewing Kvp during the libqof1->libqof2 transition, but right now Kvp is the original API and it puts the onus on the USER to handle the data properly. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpksrlFJ1fL1.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: DocBook - xml questions
On Friday 14 April 2006 6:39 am, Bengt Thuree wrote: > > 2)We should still follow the guidelines in HACKING? These were added to support those who want to process the DocBook with SGML tools instead of the automated XSL tools. > > a. Avoid using the XML empty tag, specify the closing tag. > > e.g. instead of > > > > ===> > > ===> ends with a /> in every chapter file. Could be why the images aren't located by SGML tools. ;-) > > b. Avoid a newline after tags. > > e.g. instead of \n Another SGML oddity but I don't have an explanation - it was just something that choked the SGML-based parsers that I tried. (docbook2pdf mainly). > > c. Avoid underscores in id attribute values. > > e.g. id="getting-started" instead of id="getting_started" > > ===> > > ===> Found that sect2 in every chapter have id="_" That's the SGML parser again. Again, I don't have a good answer why this would be wrong (I can't see that it's actually invalid) but it does workaround the SGML problems. If SGML parsers like docbook2pdf and docbook2html work OK, these guidelines can be updated. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp9ncqhxZf5g.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Screwy stuff in invoices, bills, etc
On Wednesday 12 April 2006 9:49 pm, Derek Atkins wrote: > Check your currencies...This is a problem that manifests > when you try to combine multiple currencies in an invoice. It might also be related to loading a data file from 1.8 into 1.9 - especially if that data file was loaded (and converted when saved) into one of the early 1.9.x versions. You could start fresh with an updated copy of the original 1.8 file (you *are* using a backup of your 1.8 data, *not* the real file with the 1.9.x series?) Also, create a new file in 1.9.x and test again. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpgGOCQDDQZu.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: compiling on fc5
On Saturday 08 April 2006 11:36 pm, Michael D. Wise wrote: > This is just for informational purposes. > qofbackend.c: In function 'qof_backend_prepare_option': > qofbackend.c:196: warning: dereferencing type-punned pointer will break > strict-aliasing rules Andrew Duggan caught this bug on QOF-devel just now. Try r13757. Sorry - I'm not on gcc 4.1 yet. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpQpD0z3QhL6.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: sourceforge anonymous CVS currently broken
On Saturday 08 April 2006 4:29 pm, Andrew Duggan wrote: > Christian Stimming wrote: > > effect, until sourceforge's anonymous CVS is running again, you should > > either download a released tarball from qof.sourceforge.net, or use the > > QOF from gnucash.org, but not use the anonymous CVS of sourceforge. > > Well I'll see how I can do updating my qof tree from the gnucash's > lib/libqof and see if I can get my qof to build, if not, I guess I'll just > wait until 0.6.4 is released on the 17th. If, for any reason, there are problems like this again, anyone in this situation can also contact me directly or via the QOF-devel mailing list. I'll gladly send a cvs-tarball to anyone who needs it because no-one should have to wait for a released tarball to workaround cvs problems. Remember that releases, by definition, do not contain files that are essential to the cvs build. (A cvs-tarball or snapshot doesn't contain any CVS/ directories - it is created using cvs export and includes all files in QOF cvs, including those that would not be included in a release tarball.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpb3MHS49jnS.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Somewhat OT: Packaging and Canonical repository for qof gnucash svn or qof cvs
On Saturday 08 April 2006 3:29 pm, Andrew Duggan wrote: > Which is the real source for getting QOF? SourceForge. Thanks for pointing out the problems with anonymous CVS at SF - I knew about the developer access and I've now committed the 0.6.4 changes successfully - but I didn't realise anonymous was down still. (Every system has downtime but I do see why gnucash doesn't use SF for CVS/svn anymore.) > As recently as 20 minutes ago the > svn of gnucash had a way more up-to-date QOF than a cvs checkout from > QOF's sourceforge cvs. I always commit to QOF CVS at SourceForge before any commits to gnucash - if only because the testing within gnucash takes longer. QOF CVS at SF is always more up to date via developer access - it's a problem at SF that has meant this isn't coming through to anonymous access. My apologies. This is the first time that QOF CVS has had an interruption due to SourceForge problems. > Should I bother with the QOF sourceforge cvs or not? Yes. This temporary problem will be fixed and if you need help in the meantime, contact me on the QOF-devel mailing list (to save more off-topic messages on gnucash-devel): http://lists.sourceforge.net/lists/listinfo/qof-devel QOF CVS at SourceForge is the canonical QOF source. You need all the build files from SF to be able to build QOF as an external library - the gnucash sources in lib/libqof/ have a slightly customised build environment to suit gnucash. The biggest difference is that gnucash lib/libqof builds without libqof-sql.so or libgda2-dev. i.e. it lacks SQL-type handling. > Any recommendations? 1. If you already have a SF checkout, you can update the source from gnucash/lib/libqof by copying the *.c and *.h files. Note that the gnucash Makefile.am is subtly different to the qof version and will not work in the qof source tree. In effect, you are doing the reverse of how I update gnucash svn from QOF CVS. Just copy the .c and .h files. 2. There are changes in 0.6.4 that involve removing gnc-engine-util.h and gnc-engine-util.c in favour of qofutil.h and qofutil.c. qof-be-utils.h has also been removed (merged into qofutil.h). References in the old qof Makefile.am would need to be altered if this has not already been done with your last update. Removing these files by hand may complicate a subsequent CVS update. Contact me on QOF-devel for detailed information. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgptrmlBuGUau.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Dependency changes and release schedule for QOF 0.6.4
On Thursday 06 April 2006 3:27 pm, Derek Atkins wrote:
> Neil Williams <[EMAIL PROTECTED]> writes:
> > The way QOF handled #include and other library headers in
> > previous versions has led to applications depending on libqof having
> > spurious dependencies and these cause packaging errors. (binary X links
> > against library Y but does not use any symbols).
> >
> > This has been fixed in QOF CVS by preventing QOF headers from
> > transparently including indirect dependencies - in the case of gnucash
> > this means that #include no longer implicitly includes -
> > and by fixing the pkg-config file to make QOF dependencies (like glib)
> > private to qof. The pkg-config --libs line is now just:
> > -lqof
> >
> > (Before it referenced -lz, -lm, -lgda2, -lglib-2.0 and others, all of
> > which simply duplicated the symbols from other libraries.)
>
> Please don't change this. pkg-config --libs libqof should give me
> EVERYTHING I need properly link libqof.
That is (now) what it does. Before it brought in large numbers of unnecessary
libraries. I cut the pilot-qof dependency list by 50% with this change.
It is not scalable *at all* for packages to build-depend on all
libraries referenced indirectly anywhere in the dependency tree.
> It should not be the job of
> every user of your library to figure out what your build-time
> dependencies are
? I can't do everything - it is up to the user to identify the build-time
dependencies. It is with libglib-2.0, it is with libgda2-3 and it is with
libqof1 (>= 0.6.4).
I provide the information on the qof website and each qof programme acts as an
example. qof-gen will expand these examples.
The problem was <= 0.6.3 where the pkg-config was basically lying to the
users.
> Unless, of course, I don't need to link against
> -lgda2 when I link against -lqof?
No, you don't. This behaviour is explicitly designed to prevent binaries being
linked against completely unnecessary libraries.
Neither did you ever need -lm, -lz or any of the others.
This change was done because of packaging warnings about unnecessary
libraries - the whole point is that what has been removed is already
determined as unnecessary.
lgda2 isn't even available on some platforms that already run libqof1 (OSX).
I'd already dealt with that via ${added_libs} but this has also been improved
by making it Requires:private in pkg-config.
> I.e., I should be able to just use the libqof pkgconfig library list
> to link against a qof app. I shouldn't have to know e.g. glib2.
Of course you'll have to link against glib-2.0 to use glib routines - the
point is that libqof should not and cannot do this for you. It's an indirect
dependency.
It is - and should remain - possible to redefine certain glib defines and
prototypes in an external header such that libqof can be built without the
current glib. This allows libqof1 to remain available if, e.g. libglib moves
to glib-3.0.
The user can simply change their own build environment to use glib-3.0 -
libqof1 should not then go and add glib-2.0 behind your back. That's the
problem we currently have with guile-g-wrap:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=359299
guile-g-wrap should not depend on glib-1.2. Preferably, with upstream changes,
it shouldn't even depend on glib-2.0. That choice should be up to the user -
albeit with some backported changes to handle glib-1.2 routines that may have
been removed from libglib-2.0.
This is how I work with pilot-link 0.11.8 and 0.12 - I've had to backport 0.12
code to pilot-qof so that it can work with 0.11.8.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgp1PMR6IrGwk.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Dependency changes and release schedule for QOF 0.6.4
The way QOF handled #include and other library headers in previous versions has led to applications depending on libqof having spurious dependencies and these cause packaging errors. (binary X links against library Y but does not use any symbols). This has been fixed in QOF CVS by preventing QOF headers from transparently including indirect dependencies - in the case of gnucash this means that #include no longer implicitly includes - and by fixing the pkg-config file to make QOF dependencies (like glib) private to qof. The pkg-config --libs line is now just: -lqof (Before it referenced -lz, -lm, -lgda2, -lglib-2.0 and others, all of which simply duplicated the symbols from other libraries.) There are changes needed in gnucash source to cope with these qof changes - typically adding #include to C files and .scm files: M src/register/ledger-core/gnc-ledger-display.c M src/backend/file/test/test-load-backend.c M src/backend/file/sixtp-utils.c M src/business/business-core/gncBusGuile.c M src/business/business-core/gw-business-core-spec.scm M src/business/dialog-tax-table/gw-dialog-tax-table-spec.scm M src/gnome-utils/QuickFill.c M src/engine/gw-kvp-spec.scm M src/engine/gnc-pricedb.c M src/engine/Account.c M src/engine/engine-helpers.c M src/engine/gnc-lot.c M src/engine/kvp-scm.c M src/engine/Period.c M src/engine/Transaction.c M src/engine/test/test-load-engine.c M src/engine/gnc-commodity.c M src/engine/gnc-associate-account.c M src/engine/gnc-engine.c M src/engine/SchedXaction.c M src/engine/gnc-session.c M src/app-utils/gnc-component-manager.c M src/app-utils/gnc-account-merge.c M src/app-utils/gnc-ui-util.c QOF 0.6.4 also replaces gnc-engine-util.* with qofutil.* and incorporates qof-be-utils.h into qofutil.h. Old gnc-engine calls are now deprecated and replaced with qof_util calls. These changes are included in the above gnucash files (as gnucash builds without deprecated libqof symbols). The other change in 4 is that xml encoding is now supported in QSF - there is a QofBackendOption that allows applications to pass an encoding value, e.g. the current locale, to QSF so that libxml2 can write out the XML using the requested encoding. libxml2 then converts back to UTF-8 when the file is loaded. This option adds two translatable strings to QOF and gnucash. These changes therefore need to be committed to gnucash svn prior to the QOF 0.6.4 release, in time for the gnucash string freeze. I'm hoping to make that commit tomorrow. All of these changes have taken place during the development of pilot-qof 0.0.8 and 0.0.9 so this is the first chance to discuss them here. I have been testing with gnucash svn without problems. I've got some final testing to do today and then it'll be ready to commit. QOF 0.6.4 is now ready for release - if there are changes out-of-tree, please let me know and/or commit to gnucash svn. QOF 0.6.4 is scheduled for release April 17th. This will be the final qof release prior to gnucash 2.0. All lib/libqof/ changes up to r13741 are already implemented in QOF CVS. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpgBziprN5Xe.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
guile-g-wrap still depends on glib1 ?
I tried removing all the old gnucash 1.8 libraries today and came across an oddity. gnucash svn (r13702) wouldn't start and complained with a g-wrap error. On checking, guile-g-wrap had been uninstalled. Oops. When I went to reinstall it, I found out why is had been removed - guile-g-wrap depends on libglib1: libglib1.2 (>= 1.2.0) http://packages.debian.org/unstable/interpreters/guile-g-wrap This ends up with gnucash2 depending on both glib2 and (indirectly) glib1. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgplbIocFsehJ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: message string coding style
On Friday 24 March 2006 9:15 am, Christian Stimming wrote:
> However, your coding style concerning the message strings caught my eye.
> I already told hampton on IRC what the translators think about that, and
> I thought I should point out on the mailing list the implications for
> the translators, just for future reference. Your code looks like this:
>
> +static gboolean
> +remove_old_report(gpointer key, gpointer val, gpointer data)
> +{
> +/* ... */
> +gchar *msg, *str = _("Do you want to display '%s'?");
> +gint response;
If the preferred method advised by Christian cannot be used, Chris, you can
use a comment immediately above the gettext call which will be retained into
the POT file:
+/* Translators: the string is the name of a report */
+gchar *msg, *str = _("Do you want to display '%s'?");
+gint response;
(or whatever it actually is.)
This then gets into the pot file as:
#. Translators: Name of the account where all the missing accounts
#. are put into. (FIXME: is this correct?)
#: ../src/backend/file/io-gncbin-r.c:507
msgid "Lost Accounts"
msgstr ""
(Note that some unnecessary comments have made their way into the POT file for
this reason - they are too close to a gettext call. If your comment is
expressly to assist translators, it's worth making that obvious in the
comment, as above.)
IIRC, // comment syntax is not picked up.
BTW a common annoyance, this example should actually be:
"Name of the account into which all the missing accounts can be placed."
(s/can/will/ if you like.)
*Avoid split-infinitives* (ending a sentence with "into", "for", "to" etc.)
Use "which" and "whom" instead.
Split-infinitives, colour, favourite and -ise instead of -ize are the main
reasons for an en_GB translation.
;-)
(two nations separated by a common language)
> Let me explain what this means to translators. Translators will see the
> string "Do you want to display '%s'?" in the gnucash.pot file. Then,
> they will wonder what this mysterious "%s" might be -- is it a verb, is
> it a number, is it the name of a picture, is it the name of whatever?
If you use a comment, it needs to unambiguously answer these questions. You
should describe the string that will replace the %s as fully as possible.
Multiple lines are fine within the same comment.
Grammatical differences may, for example, require that the %s is moved within
the translated string to the middle or even beginning depending on whether it
is a verb, noun or other construct. This can only be done if the msgid and/or
comment make sense and are unambiguous.
> The translator is forced to read through the whole function,
Worse, try to correlate the string with the value passed by a function in
another file if this is a public API string.
> looking for the place where this obnoxious "str" variable is used
> eventually. From a translator point of view this sucks. Royally. Please
> do *not* use this coding style.
(without comments)
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgp1KUxeUOwWq.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13639 - gnucash/trunk - * lib/libqof/backend/file/qsf-backend.c: add
On Thursday 16 March 2006 2:21 pm, Derek Atkins wrote: > Neil Williams <[EMAIL PROTECTED]> writes: > >>* lib/libqof/backend/file/qsf-backend.c: add > >> Note: it think it's probably wrong to set the locale here. > > > > It's a GModule - it needs to load the locale itself according to whether > > the backend is loaded from internal gnucash (use the gnucash text domain) > > or libqof1 (use the qof text domain). > > Eh? A GModule is just a shared library, nothing more. There's > nothing special about a GModule; the g_module API is just a wrapper > around dlopen(), and dlsym(), pretty much. The module is loaded by libqof which in turn does not know the identity of the application. How can it? The application can't translate these strings, the source does not exist in the tree when qof is used externally (e.g. pilot-qof). There's absolutely no point in duplicating these strings into placeholder locations in every application that ever used libqof - even then I'm not convinced gettext would replace the (untranslated) strings in the QSF Gmodule with the placeholder (translated) strings in the application. > > Yes. > > Why? What's the failure mode here? Untranslatable strings. gettext cannot locate the marked up strings because they exist in the QOF source tree, not cashutil or pilot-qof. Only QOF can therefore make these strings available for translation via a qof.pot file and install them in a QOF directory as .gmo files. gnucash is a special case - the strings do exist but only when used internally. When gnucash uses libqof externally, gettext still cannot locate the strings to be translated because they are being loaded from an external library (the identifier has changed because qof does not use the lib/libqof/ prefix). > >> Shouldn't the APP > >> + * have already done this? > >> + */ > > > > There is no "app", it's a GModule, loaded independently by libqof1. > > There most certainly is an application! What the heck do you think is > running? There's some executable that loaded the module. Via the library, not directly. The library doesn't know the identity of the application, neither does the backend. Therefore gettext has to load the strings from the only known domain: qof. QOF therefore has it's own translations for these 6 strings so that they can be translated when qof is used externally. > That > executable (gnucash, cashutil, pilot-qof) most likely already ran > setlocale(). Doing it again is. wrong. The translated strings aren't part of pilot-qof, they can't be - qsf-backend.c doesn't exist in the pilot-qof (or cashutil) source tree for gettext to process. Therefore gettext cannot put the translations into place - it has no knowledge of them unless QOF loads them in it's own textual domain. > > The module > > knows nothing of the app using the library, therefore it cannot locate > > the text domain, so it needs it's own - which it has. libqof1 is > > translated by the GNU TP. > > http://www.iro.umontreal.ca/translation/registry.cgi?domain=qof > > I don't underdstand this statement. Could you please go into more > detail about how it "cannot locate the text domain"? pilot-qof loads libqof1 and doesn't load the backend until a session operation is required. It then calls a libqof function that executes the load. It is only at this point that the strings in qsf-backend.c can be translated. gettext places all translated strings in locations on the filesystem dictated by the textual domain - usually the name of the package. /usr/share/locale/LC_MESSAGES/gnucash or .../qof/ or ../pilot-qof. gettext can only put those strings into the location determined by the textual domain if it can find the marked up strings in the source tree identifying itself as that domain - otherwise they get skipped. So pilot-qof contains 79 translated messages. QOF contains 6. The 6 strings in QOF are all in the QSF backend - more would be added with other backends - and are not present anywhere in the pilot-qof source tree. gnucash is a special case. gettext cannot locate these strings, it cannot put them into the pilot-qof.pot file, it cannot use them if they are put into a po file within pilot-qof. gettext can only load them from a pot file created from the qof source tree - i.e. qof.pot, creating a textual domain called 'qof', creating installation directories of LC_MESSAGES/qof/ and requiring that when the backend loads, it calls gettext with this domain to locate the translations. The only way to load these strings is to give them a textual domain (basically a location in the filesystem) of their own. That is the QOF textual domain. -- Neil Willi
gcc-4.1 ?
I've just had a failure to build bug report for pilot-qof related to the upcoming change in Debian from gcc-4.0 to gcc-4.1 - the code affected is not present in libqof1 or gnucash. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=357113 Has anyone yet tested svn with gcc 4.1? David (FC5/Rawhide?) It is likely to be the default compiler in Debian unstable by the time gnucash 2.0.0 is released. I'm planning to install gcc4.1 (at least temporarily) from Debian experimental to solve the pilot-qof issue. Thomas? Did you use gcc4.0 or 4.1 to create the experimental package for 1.9.1? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpvBsPIBL49B.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13639 - gnucash/trunk - * lib/libqof/backend/file/qsf-backend.c: add
On Wednesday 15 March 2006 5:08 pm, Derek Atkins wrote:
> Author: warlord
> Date: 2006-03-15 12:08:08 -0500 (Wed, 15 Mar 2006)
> New Revision: 13639
> Trac: http://svn.gnucash.org/trac/changeset/13639
>
> Modified:
>gnucash/trunk/ChangeLog
>gnucash/trunk/lib/libqof/backend/file/qsf-backend.c
> Log:
> * lib/libqof/backend/file/qsf-backend.c: add
> Note: it think it's probably wrong to set the locale here.
It's a GModule - it needs to load the locale itself according to whether the
backend is loaded from internal gnucash (use the gnucash text domain) or
libqof1 (use the qof text domain).
> Modified: gnucash/trunk/lib/libqof/backend/file/qsf-backend.c
> ===
> --- gnucash/trunk/lib/libqof/backend/file/qsf-backend.c 2006-03-15
> 16:57:29
> UTC (rev 13638) +++
> gnucash/trunk/lib/libqof/backend/file/qsf-backend.c 2006-03-15 17:08:08 UTC
> (rev 13639) @@ -30,6 +30,7 @@
> #include "qsf-dir.h"
> #include
> #include
> +#include /* for setlocale() and LC_ALL */
>
> #define QSF_TYPE_BINARY "binary"
> #define QSF_TYPE_GLIST "glist"
> @@ -1248,6 +1249,9 @@
> {
> QofBackendProvider *prov;
>
> + /* XXX: Do we REALLY want to do this???
Yes.
> Shouldn't the APP
> + * have already done this?
> + */
There is no "app", it's a GModule, loaded independently by libqof1. The module
knows nothing of the app using the library, therefore it cannot locate the
text domain, so it needs it's own - which it has. libqof1 is translated by
the GNU TP.
http://www.iro.umontreal.ca/translation/registry.cgi?domain=qof
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpLw6bU69gnd.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compilation error with SVN 13637
On Wednesday 15 March 2006 4:50 pm, Phil Longstaff wrote: Ignore that, I've seen the other email from Derek. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp7E7lygmWJL.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Compilation error with SVN 13637
On Wednesday 15 March 2006 4:50 pm, Phil Longstaff wrote: > qsf-backend.c:1252: warning: implicit declaration of function `setlocale' > qsf-backend.c:1252: error: `LC_ALL' undeclared (first use in this function) > qsf-backend.c:1252: error: (Each undeclared identifier is reported only > once qsf-backend.c:1252: error: for each function it appears in.) > make[7]: *** [qsf-backend.lo] Error 1 Have you got gettext installed? If not, we need to find out why configure didn't check because gettext is used throughout the build. Which distro? Which platform? Can you build external QOF on the same platform? (in case it's the configure test that is wrong for some strange reason). -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpk6qTozBzPt.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
QOF 0.6.3 released.
News: - Support iteration over incoming QSF objects inside map operations. - Skip unregistered objects when processing maps. - Correct map handling to allow reverse operations and iteration over hierarchical objects. Improving debug messages and preventing a crash when loading a map directly. - David Hampton's patches to allow users to skip deprecated code in libqof1 and to remove use of config.h in a header. - qof_book_merge replaced with qofbookmerge, structures and functions renamed according to libqof2 convention. - Deprecated old versions and use new calls inside library. - Standardise on gint and gchar. The map changes include a new map that can convert pilot-qof address QSF data on-the-fly into gncCustomer QSF data and back again. This should mean that gnucash can read pilot-qof addresses directly from QSF and vice versa. More testing is required. Work on the incomplete invoice map continues. Along with the XSL stylesheets in gnucash and pilot-qof, this should allow easy exchange of address data between gnucash, pilot-qof, KAddressbook, certain mobile phones and various other programmes. Work on other formats, other databases and other conversions continues. https://sourceforge.net/projects/qof/ Packages are available in the usual places - see Freshmeat for more information. http://freshmeat.net/projects/qof/ -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpeSQL14udXv.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QOF 0.6.3 scheduled for release 14th March.
On Thursday 09 March 2006 4:59 pm, David Hampton wrote: > I have one more change I'd like to get in that finishes the work of > deprecating old functions (not counting your book merge changes) and > makes the code in deprecated.[ch] conditionally compiled based on the > QOF_DISABLE_DEPRECATED flag. > > I hope to commit this tonight, or tomorrow night at the latest. No problem. I've checked the book merge changes and replaced the old functions in src/engine/test and src/gnome already. There's plenty of time for your change(s). Thanks for the heads-up. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpr7uTt6YA90.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
QOF 0.6.3 scheduled for release 14th March.
An early-ish release (0.6.2 will just about have time to make Debian testing) reflecting an interim bug fix release. This leaves plenty of room for a 0.6.4 release in time for gnucash 2.0.0. This release continues the renaming of files, functions and typedefs to the standard QOF conventions, this time bringing qof_book_merge into line by replacing it with qofbookmerge.c|h and adding the old function names to deprecated.c|h. It also includes the fixes made in the gnucash tree up to r13556. (I was planning a pilot-qof 0.1.0 release but I am still waiting for pilot-link 0.12 so I'm doing QOF 0.6.3 instead.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgprWV9RdkoRE.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Translatable XSL stylesheets for QSF
On Wednesday 08 March 2006 10:49 pm, Josh Sled wrote: > On Wed, 2006-03-08 at 11:52 +0000, Neil Williams wrote: > > The stylesheets are gnucash-specific (only deal with gnucash QFS objects) typo. Should be (QSF objects) > > and hence shouldn't go into lib/libqof/ but into a new directory. A new > > top-level directory xsl/ ? doc/xsl/ ? > > doc/xsl/ isn't right ... contrib/xsl/? src/xsl/? I agree, doc/xsl isn't good. I'm not sure about contrib - might give the wrong impression (non-free). Is putting it in src/optional/xsl a little too deep / hidden? It might work well with the existing setup in src/optional/Makefile.am: # N.B. Do *not* specify subdirs, since we do *not* want the swig subdirs # built by default, since many folks may not have swig installed, and this # is, after all, optional. But do put them in the dist. # For some reason, we need to set SUBDIRS to a blank to # get this to work (automake 1.4p5). That's how I see the XSL too - no need to build at all. That also means that any dependencies introduced by the XSL can also be optional, i.e. in a package like gnucash-common, they would be labelled as Suggest or Recommend. Personally, I'd say "suggest" - i.e. for those who are interested or have customised requirements rather than an addition for almost everyone which is how I'd interpret "recommend". The XSL could go here and just be added to DIST_SUBDIRS to be distributed "as-is". -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpT6MR8X7kTU.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13520 - gnucash/trunk - Add po/gnucash.pot to EXTRA_DIST because the translation template is
On Tuesday 07 March 2006 8:50 pm, Christian Stimming wrote: > Author: cstim > Date: 2006-03-07 15:50:11 -0500 (Tue, 07 Mar 2006) > New Revision: 13520 > Trac: http://svn.gnucash.org/trac/changeset/13520 > > Modified: >gnucash/trunk/ChangeLog >gnucash/trunk/Makefile.am > Log: > Add po/gnucash.pot to EXTRA_DIST because the translation template is > needed in the tarball for translators. That breaks make dist for me - because make pot isn't an automatic command. Also, doesn't this mean that make distcheck would also fail? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpqxqohJluTk.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13483 - gnucash/trunk - Rework the events generated by the account/group files and consumed by
On Wednesday 08 March 2006 8:49 pm, Derek Atkins wrote: > David Hampton <[EMAIL PROTECTED]> writes: > >> 2) You've now changed the MODIFY API, and I'm not convinced you've > >>changed it globally. That could be dangerous, in particular if the > >>event gets emitted from somewhere that didn't know about the > >>change. > > > > No, I've added a new modify api using the qof_event_gen function. The > > old api using the gnc_engine_gen_event call is still there and is > > unchanged. But you're still using the default eventId, QOF_EVENT_MODIFY which is sent to old and new handlers. If you want to use the new API, you must define a new QofEventId that is larger than QOF_EVENT_BASE. qof_event_gen still sends events <= QOF_EVENT_BASE to all handlers. It has replaced the deprecated function by adding extra functionality whilst retaining the previous behaviour for the main QOF events. > > Since the account tree model must use the qof_event system > > for the REMOVE notification because of extra data required, it makes > > sense to use that API for all the events that account tree model > > watches. > > > My concern is that you're generating two different event profiles with > QOF_EVENT_MODIFY against an Account QofEntity. I think internally QOF > has only a single list of callback functions (although I must admit I > haven't looked closely). QofEvent does only have one list, events that use QofEventId <= QOF_EVENT_BASE get sent to both new and old handlers. Events where QofEventId > QOF_EVENT_BASE only get sent to the new handlers. > So I think you need to be consistent with > how you use QOF_EVENT_MODIFY with an Account QofEntity and be sure > you're always using the same source and consumer syntax. If you use QOF_EVENT_MODIFY, it will be sent to the old, deprecated, handlers as well as the new. All handlers will therefore have to know how to ignore it or handle it. If you want an event to be handled differently, it's best to create a new event and use a handler that uses the new prototype - that's why the enum was removed. As it stands, use of the default QOF events, ADD, REMOVE, MODIFY, CREATE and DESTROY neither changes how the handlers receive the event nor how they process the event. The handlers can and should expect that the entity involved is to be processed in the same way in all handlers. One event = one definition = one syntax in all handlers. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpY2iUkU8cSd.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Translatable XSL stylesheets for QSF
I'm building a collection of XSL stylesheets for QSF data in pilot-qof and gnucash/cashutil. Each gnucash stylesheet will use standard templates from the XSLTSL project (LGPL) and our own common stylesheet, gnucash-std.xsl. http://xsltsl.sourceforge.net/ So far in gnucash, I've just got a sample xsl that transforms Export->Customers QSF into vcard format, one per gncCustomer. "Chunking" is supported so individual customers can be written as separate files into a directory. These vcards can be imported into KAddressbook without errors or omissions, but haven't been tested in other programmes. Now I need to work on the reverse - that'll depend on how easily I can generate a temporary GUID in XSL to link a gncCustomer to a gncAddress etc.. A similar stylesheet could then transform pilot-qof address records into gncCustomer records. The next pilot-qof release will also have a stylesheet to convert pilot_address records into more limited vcard files that are suitable for upload to mobile phones - e.g. via bluetooth. gnucash could have a similar stylesheet. This process ignores a lot of data from the original QSF because phones use such limited vcards so this is likely to be a one-way transformation. It should mean that users can choose to enter their customer data in a Palm or into gnucash and then share that data with gnucash, a Palm, existing address books and their mobile phone without re-entering it. This is what http://www.data-freedom.org/ is all about. :-) Support for transforming kaddressbook vcards into pilot-qof pilot_address or gnucash gncCustomer QSF could follow. Support for iPAQ's and other data sources is possible too. I'd like these in svn and installed, probably into /usr/share/xml/gnucash/xsl to complement the pilot-qof ones in /usr/share/xml/pilot-qof/xsl. In due course, I'll package XSLTSL for Debian so that the xsltsl standard stylesheets don't have to be installed by each programme (at least on Debian). These would go into /usr/share/xml/xsltsl/ and be referenced by the gnucash and pilot-qof ones. The stylesheets are gnucash-specific (only deal with gnucash QFS objects) and hence shouldn't go into lib/libqof/ but into a new directory. A new top-level directory xsl/ ? doc/xsl/ ? date-time.xsl string.xsl gnucash-customer-vcard2.xsl (denotes that the vcard is version 2.1) gnucash-std.xsl I don't envisage gnucash loading these stylesheets at runtime, these are primarily for users. I'm planning more stylesheets, including HTML and ics output. I've already got a prototype pilot-qof HTML invoice. A gnucash version would mean that by exporting invoices to QSF, users can generate whatever invoice format they require, simply by copying the default XSL to a local directory, tweaking it and passing it to xsltproc. I aim to keep as much of the transformation jargon in gnucash-std.xsl as I can so that each stylesheet is as easy to amend as possible, without causing chaos in the output. Modifying the output could be as simple as changing the xsl:output type and modifying some or HTML tags. All XSL output strings will be available for translation using --stringparam parameters that can be passed via scripts to replace the en_GB defaults with translated versions, e.g. for the words "Invoice", "Date", "Description" etc. as well as supporting other parameters to handle HTML lang values, encoding strings, default values for calculations, like mileage rates, hourly rates etc.. This makes for very long command lines so scripts are advisable. If the XSL is processed via PHP, Perl or bash, it should be possible to read the existing translation files for some of this data - not sure how easy that will be in reality. All HTML output will be HTML 4.01 Strict compliant. An example CSS stylesheet will be included and the HTML will include lots of CSS hooks. $ xsltproc -o ~/data/cards/ \ /usr/share/xml/gnucash/xsl/gnucash-gnccustomer-vcard2.xsl \ /opt/data/g2/test-1-customer.xml All stylesheets outside xsltsl will be licenced under the GPL. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpBCrpLaQqMG.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r13522 - gnucash/trunk/po - updated en_GB translation, 3724 translated
On Tuesday 07 March 2006 9:46 pm, Christian Stimming wrote: > Hi Neil, > > since we just talked about the ngettext(3) messages, I checked these in > en_GB.po. There's an error in one of them, but the other two are correct. Hmmm, can't see why msgfmt -c and KBabel both missed that one. Maybe KBabel doesn't handle these plurals as well as I thought. (It normally refuses to save a po file that contains such errors.) :-( Fixed in r13526. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpMFhol89p7G.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] Maby a new Norwegian translation...
On Tuesday 07 March 2006 9:27 pm, Christian Stimming wrote: > > Christian or someone, can yoy please have a look at the attached updated > > nb.po file This is at least the 3. time i get this error on this > > message def. (it happend some months ago as well,,,) There must be > > something with this message that gtranslator dont like. > > Actually, yes, there is something that gtranslator obviously doesn't > support: gnucash uses a ngettext(3) message here, which does not only have > a msgid "..." > but also a > msgid_plural "..." > , and it doesn't only have one msgstr but several, depending on the plural > forms of your language. This feature of gettext is admittantly not used > very often, but it is really nice and we use it in 3-4 places in gnucash. As an alternative to gtranslator, KBabel does support these plurals nicely. If you don't fancy using emacs for translation, kbabel is worth a try. Just spend some time with it using some smaller files to get used to setting the correct project configuration and check the Edit->Edit Header output to make sure it's similar to the existing svn. Also, moderate some of the options to update various elements at save time - less is more when working with files already edited using a variety of tools. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpRXBrq1llDv.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13390 - gnucash/trunk/lib/libqof/qof - Implement QOF_COMMIT_EDIT_PART2 as a function instead of a macro.
On Wednesday 01 March 2006 3:19 pm, Derek Atkins wrote: > Christian Stimming <[EMAIL PROTECTED]> writes: > > Actually I do. (should we have a vote on this one? :) And as a reader of > > someone else's code I would actually prefer very much to not have macros > > affect the control flow of the calling function. Absolutely. > > So in this discussion I > > indeed agree with Chris' explanation: It might be a big convenience for > > the one who is writing the macro, but for the one reading the code it's > > a PITA and if at all possible it should rather be avoided... Basically > > I'd view this just as our ChangeLog policy: People might consider > > writing an extra ChangeLog entry a big inconvenience for them, but when > > reading someone else's commits, it's a substantial simplification for > > looking up particular changes. > How about this: I'll relent on this if Chris and Neil agree to make > ChangeLog entries along with their commits (instead of collecting lots > of commits and then adding changelog entries after the fact). That's a worthwhile trade-off in my book! Chris? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpHfIUPMKnAV.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: en_GB.po error with msgfmt-0.10.35
On Tuesday 28 February 2006 5:37 pm, Thomas Klausner wrote: > msgfmt-0.10.35 doesn't like the en_GB.po file from gnucash-1.9.1: Already fixed in r13420, purely because I was testing KBabel. None of the translations are in step with 1.9.x NOTE: this is going to keep on happening because, as the announcements and the draft release schedule clearly indicate, the 1.9.x series is a development test bed and there are NO string freezes prior to release. The string freeze for gnucash 2.0.0 is not due for a few weeks. > Could someone please fix them for the next release? No, not until 2.0.0. 1.9.2, 1.9.3 and any other 1.9.x releases will NOT have translations fixed prior to release. The strings are just changing too frequently. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgprueRTHhXQD.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13417 - gnucash/trunk - Bug#332802: fix Export Accounts; remove `price_lookup` and `export` functions from GncFileBackend.
On Tuesday 28 February 2006 2:28 am, Joshua Sled wrote:
> Author: jsled
> Log:
> Bug#332802: fix Export Accounts; remove `price_lookup` and `export`
> functions from GncFileBackend.
The only problem with export is that it's now been moved into the QofBackend
where it is still deprecated, but I'm glad we're not using price_lookup
anymore (also deprecated).
> + * src/backend/file/gnc-backend-file.h (struct FileBackend_struct):
> + Remove unused `pricedb_lookup` and `export` operations from
> + gnucash-specific file backend.
But you've kept export in a different place - if it's really unused we should
dump it altogether.
Currently, only the gnc_backend_file supports export.
What's the functional difference between the two Export commands on the File
menu?
Should we just export the Accounts as QSF - without any starting balance
Transactions and Splits?
QofCollection col;
QofSession export_session;
export_session = qof_session_new();
/* insert code to get filename for export and begin export_session */
col = qof_book_get_collection(book, GNC_ID_ACCOUNT);
if(!qof_entity_copy_coll(export_session, col))
{ PINFO ("export accounts failed"); return; }
qof_session_save ...
then ditch export completely?
> +
> + * src/backend/file/gnc-backend-file.c (gnc_backend_new): Use
> + correct 'export' function-slot, allowing File > Export > Export
> + Accounts to work again. Bug#332802.
Unfortunately, it's a deprecated slot - it'll have to move again at some point
(libqof2).
> Modified: gnucash/trunk/src/backend/file/gnc-backend-file.c
> - gnc_be->export = gnc_file_be_write_accounts_to_file;
> +be->export = gnc_file_be_write_accounts_to_file;
> Modified: gnucash/trunk/src/backend/file/gnc-backend-file.h
> - /**
> - * XXX Export should really _NOT_ be here, but is left here for now.
> - * I'm not sure where this should be going to. It should be
> - * removed ASAP. This is a temporary hack-around until period-closing
> - * is fully implemented.
> - */
> - void (*export) (QofBackend *, QofBook *);
This was just a copy of the same comment in QofBackend relating to be->export.
There is no need for a specific export call in QofBackend because any
selection of session data can be exported.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpjroGbVYKAj.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
QOF 0.6.2 on release.
News: - Fedora fixes from Toshio Kuratomi - qof/qofevent.c : Allow events to be generated with an optional event_data argument. - Replace gnc-event files with qofevent using extensible event identifiers. - Correcting collect handling in QSF. - New file and test to handle reference related code. - Add error value for files that cannot be opened. ERR_FILEIO_READ_ERROR. - Check that files can be opened before trying to work out their type. - Derek Atkin's patch for better handling of event removal. This allows us to actually clean up, but also makes sure we don't destroy the handler list out from under us as we're processing events. - new events test. - Deprecating qof_log_set_level_global due to misleading name - Derek's fixes for reciprocal numeric handling. - Derek's test for the fixed reciprocal handling. - Fix merge handling of QOF_TYPE_CHAR to use gchar instead of casting from a gchar* - Add CACHE_REPLACE(dst, src) macro for common case in string setters. Chris Shoemaker - New Swedish and Vietnamese translations. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpD2feDmSTf9.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13390 - gnucash/trunk/lib/libqof/qof - Implement QOF_COMMIT_EDIT_PART2 as a function instead of a macro.
On Sunday 26 February 2006 4:57 pm, Derek Atkins wrote: > This patch could break a lot of code in lots of places because there > is code that expects that QOF_COMMIT_EDIT_PART2() could return > (exiting the /caller/ of the macro), but the new macro wont return > out of the caller anymore. I've got a fix pending - it's why I asked about macros that change programme flow. I'll reinstate the macro - including it's effects on programme flow - and leave the new function as an alternative. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpMPyH24GCyR.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13352 - gnucash/trunk - Fix "default limit" QOF eventing stuff; thanks Andi.
On Sunday 26 February 2006 4:31 pm, Derek Atkins wrote: > Events should always be a power of 2. This way bitmasking events > works quickly and efficiently. It does, however, limit the number > of events you can have. It's still going to be more than we had under gnc-event. :-) It should be plenty, after all, the new event structure may only be required during libqof1. > One suggestion I had was to do something like: > >#define QOF_MAKE_EVENT(x)(1< > Then you can do: > > #define QOF_EVENT_A QOF_MAKE_EVENT(0) > #define QOF_EVENT_B QOF_MAKE_EVENT(1) > ... > > and then in the API code: > > #define APP_EVENT_A QOF_MAKE_EVENT(QOF_EVENT_BASE+0) > #define APP_EVENT_B QOF_MAKE_EVENT(QOF_EVENT_BASE+1) I can test that for 0.6.2 if you'd like. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpKzMXtTewNs.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Macros that affect program flow.
On Sunday 26 February 2006 4:36 pm, Derek Atkins wrote: > The point of a macro is to simplify the process of programming. > In particular, it's supposed to allow you to replace repetitive > code. In this case, the reduction in repetition reduces the simplicity of the code. I accept the docs need to make this clearer. > Pretty much EVERY INSTANCE of gncFooBeginEdit() and gncFooCommitEdit() > looks EXACTLY THE SAME! in gnucash, maybe. It does differ elsewhere. > It seems really stupid to me to make every > object have to call functions, check the results, and then return > itself when a central macro can do it for you. I've certainly had situations where I had to use the functionality in the macro in a function that returned a value. That's why I created the function versions in the first place. > IMHO this is a DOCUMENTATION problem, not a clarity-of-API issue. OK. > Changing the macro not to return would IMNSHO make the developers > life more difficult. True, but you've no problem with having a complimentary function to use when the macro cannot be used? > In my particular case I would just write > YET ANOTHER MACRO to use in gnucash, so we don't have duplicated > code in every single qof object we define. So why not just leave > that macro, which would get written anyways, in QOF? I'll reinstate it and leave the function as an alternative. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgphRWzULU4NA.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Macros that affect program flow. (was Re: temporary absence)
On Sunday 26 February 2006 3:17 am, you wrote:
> > Apart from that and the changes committed to trunk, does anyone have any
> > more code out-of-tree that should go into QOF 0.6.2?
>
> Yes. I've got some changes related to QOF_COMMIT_EDIT_PART2.
OK, I've got r13390 and r13391 (guid.c). PROBLEM:
The macros in qof-be-utils.h are awkward because they (all) change programme
flow. We can't redefine QOF_BEGIN_EDIT as a call to qof_begin_edit because
functions that use QOF_BEGIN_EDIT rely on it calling return if the instance
is NULL or edit_level < 1. I don't like macros that work like that and I
would like to deprecate each of these macros and force the use of the
functions in libqof2.
We cannot redefine QOF_COMMIT_EDIT_PART2 because the last call in the macro is
'return':
- if ((inst)->do_free) { \
- (on_free)(inst);\
- return; \
- }
Your code simply returns from the qof_commit_edit_part2 function, it does NOT
return from the function that called the original macro. To do that, existing
code would have to check the return value of the function that is behind the
macro. Not impossible, but not required by the current API either. That's an
API change.
I got bitten by this problem when I first tried to use a function in place of
QOF_BEGIN_EDIT.
IF the macro is NOT followed by any further code in the calling function, this
would be OK but there is nothing to say that this is the case (or has to be
the case). The current API (rightly or wrongly) allows programmes to call
QOF_COMMIT_EDIT_PART2 and then continue processing the instance. Such code is
assuming that if the instance was freed as part of the commit that the macro
will have returned OUT of the function itself. A function replacing
QOF_COMMIT_EDIT_PART2 will still free the instance but now processing
continues into the rest of the function which is not expecting a freed
instance to be possible. Even having a LEAVE macro that references the now
freed instance would cause a seg fault.
Derek - I would v.v.v.much like to deprecate all the macros in qof-be-utils.h
precisely because of these problems. They cause no end of confusion and
hidden assumptions. I know you wanted these as macros but I think the API is
too confusing. IMHO, the pros of the macros do not outweigh their problems.
The functions are easier to use - particularly because they can be used in
functions that return a value. To me, macros should not determine whether or
not I can return a value from an internal function.
In fact, once the macros are deprecated (i.e. moved into deprecated.h and
tagged in doxygen), qof-be-utils.h can be removed and the function
declarations made part of qofbackend.h (where I think new users of libqof
would expect to find them).
Chris: We need to replace the macro and have the function as an alternative,
*not* a replacement. It matters not whether gnucash has a problem with the
function, it matters that the API is changed by the change in programme flow
generated within the old macro but not implementable in the function version.
> I have
> verified that this macro is not used outside of GnuCash.
That's not the whole story for an API issue - a macro in an API must retain
it's arguments and behaviour, especially it's use of 'return;'.
i.e. code that uses the old macro must still function the same way. The macro
is still part of the API (until libqof2). We need the macro replaced, for
now. I don't like it, but that's the way it is until libqof2.
If there is agreement to deprecate all these macros, then the functions will
replace all the macros in libqof2. Until then, libqof1 requires the old macro
to be in place.
:-(
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpFpamHce2DX.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [QOF-devel] Outline of new qofevent support
On Saturday 25 February 2006 10:15 pm, Derek Atkins wrote: > > typedef void (*QofEventHandlerWithArg)(QofEntity*, QofEventId, > > gpointer handler_data, gpointer event_data); > > Sorry, yes, this is what I meant. > > > Currently, the gpointer is set when the handler is registered, not when > > it is used after an event is generated. Do you need both? Is the current > > gpointer used? > > Yes, I need both. Bearing in mind your earlier comment that gnucash uses so many events, this is actually getting quite complex with THREE types of handlers now supported - two to remain supported into libqof2. What about if existing calls to gnc_engine_event_gen are mapped (via a define) to qof_event_gen(entity, event_id, NULL) and calls directly to qof_event_gen can choose to use or not to use an argument? Redefine qof_event_gen(entity, event_id, event_data) where event_data is a gpointer and can be NULL. Then we'd have just one typedef, one handler in libqof2 and I can pass an event argument in all cases - it'll just be NULL sometimes. Existing code would use old style handlers that do not support event data, new handlers would use the new code and have a choice about whether to use event data or not. As 0.6.2 is not released yet, the qof_event_* syntax is not yet part of the API so it can be changed, leaving gnc_engine_event_* as the deprecated old style. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpfLAwIXjRYj.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [QOF-devel] Outline of new qofevent support
On Saturday 25 February 2006 9:07 pm, Derek Atkins wrote: > >> I'd propose: > >> > >> typedef void (*QofEventHandlerWithArg)(QofEntity*, QofEventId, > >> gpointer); Umm, those are the exact arguments that we already have for QofEventHandler. Did you actually mean: typedef void (*QofEventHandlerWithArg)(QofEntity*, QofEventId, gpointer handler_data, gpointer event_data); ? Or just that the existing gpointer should be handled differently? (which could be confusing.) Currently, the gpointer is set when the handler is registered, not when it is used after an event is generated. Do you need both? Is the current gpointer used? Maybe if the qof_event_register_handler_with_arg sets the original gpointer in HandlerInfo as NULL and uses the gpointer passed from qof_event_gen_with_arg instead? Then the handler prototype would be the same but the implementation would differ according to HOW the prototype is registered. That's confusing too. Using two prototypes that take the same arguments but handle them differently will need some careful documentation. > >> void qof_event_add_handler_with_arg(QofEventHandlerWithArg); qof_event_regsister_handler_with_arg > >> void qof_event_del_handler_with_arg(QofEventHandlerWithArg); qof_event_unregister_handler_with_arg > >> void qof_event_with_arg(QofEntity*, QofEventId, gpointer); qof_event_gen_with_arg -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpe0Peot1ZYP.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13352 - gnucash/trunk - Fix "default limit" QOF eventing stuff; thanks Andi.
On Saturday 25 February 2006 9:24 pm, Josh Sled wrote: > > > /** Allow scope for more defaults in future. Additional > > > event identifiers must be larger than this. */ > > > -#define QOF_DEFAULT_LIMIT 10 > > > +#define QOF_DEFAULT_EVENT_LIMIT QOF_EVENT__LAST > > > > Josh - why was this a bug? What was wrong with a gap? > > The gap was in the wrong direction. :) The max value (1<<4) is 16, and > 10 was less than that. OK, I see that now. > > Supplementary events will now have to be based on QOF_DEFAULT_LIMIT + n > > rather than just something bigger than 10? > > They should always be specified as based off some constant identifier, > rather than a particular value. I'm not sure what you mean. Why? This probably sounds obvious to you but if new identifiers are expected to be based on QOF_DEFAULT_LIMIT + n, then I need to ensure this assumption is in the API docs because it certainly would not be obvious to me. I expect it's just something you've covered elsewhere that I haven't anticipated but I'd like to be sure. (Blame it on me being self-taught.) > > I thought nobody wanted to iterate over event identifiers? > > I have no idea how that relates to this...? I thought you were using the << operator to create some way of iterating through the list of available event identifiers somewhere but couldn't see why. Derek's pointer to bitmasking cleared that up. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpkxHMVXprMH.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [QOF-devel] Outline of new qofevent support
On Saturday 25 February 2006 9:07 pm, Derek Atkins wrote: > Quoting Neil Williams <[EMAIL PROTECTED]>: > >> The generator and consumer of the QofEventId need to > >> agree on what the object of the event is. > > > > Absolutely. This would almost certainly mean a different QofEventId for > > each type of object used and expected. That can't be resolved by QOF, it > > needs to be stated in the docs and left to the user to ensure it actually > > happens that way. > > Well, maybe. It would mean defining that a particular QofEventId when > applied to a particular QofEntityId would (or would not) imply a particular > type of argument in the callback. Nothing says that QOF_EVENT_FOO when > applied to QofTypeFoo implies an argument of X and when applied to a > QofTypeBar > implies an argument of Y. So leave it open? Let the API user decide how to reconcile which argument goes with which event_id for which entity. I'll put that into the docs. > Admittedly, it would be nice to standardize, but in the grand scheme of > things it's just a contract between the event generator and the event > consumer. OK. In which case, QOF will not put limitations on that contract - it will be completely up to the generator and the consumer to deal with unexpected arguments, incompatible arguments, etc. This implies gpointer arguments. > > Do you actually want a gpointer or would a QofEntity be a better choice? > > I don't know. I think passing gpointer is more general.. However all > the uses I have in mind only require a QofEntity (actually a QofInstance). > > WithArg infers non-objects being passed (like a GHashTable or GList, an > > arbitrary struct / iterator, some arbitrary const gchar* or other weird > > bits of memory) - was this your intention or would this be a better, > > clearer, name base? > > Actually, yes, this was my intention -- it's closer to the way g_signal > works -- g_signal lets you pass any kind of arguments back to the caller. > Indeed, you can even define signals with MULTIPLE callback arguments! > So, leaving it as a gpointer leaves it a little closer to where we'll > get to be eventually with qof2. OK. > > Your use case certainly centres on an item that is more of an Object > > than some > > arbitrary argument. > > > > I prefer the idea of restricting it to objects - or more precisely, a > > QofEntity. > > Why this restriction? Because I always try to make new function names etc. intuitive and your examples (including the statement above about what you have in mind for this part of the API) all related to QofEntity or QofInstance. If, in practice, the *only* uses of these routines will be QofEntity or QofInstance, I'd prefer that the function made this obvious. If there are future situations that will require more than that, gpointer is better. > > Do you need this for QOF 0.6.2 (which otherwise could be released > > tomorrow) or > > 0.6.3 which is a likely release in the first week of April (coinciding > > possibly with 1.9.3)? (i.e. as this is something you've just recently > > thought up, is the idea due to an immediate need, educated foresight or > > wishlist?) > > > I have an immediate use for it.. I'd like to set up an event handler that > gets called whenever we add a new transaction into a particular account.. > The idea is that I can attach this handler to the A/R account and whenever > a new transaction appears (or changes) I can perform business-level > processing on the transaction. For example, I can tell whether the > transaction is tied to an invoice/lot or not, and if not I can try to > figure it out or maybe ask the user for help... > > So, yes, this is something I'd like to see in 0.6.2. OK. gpointer, with_arg naming style, 0.6.2. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpgUm48HbP3y.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13352 - gnucash/trunk - Fix "default limit" QOF eventing stuff; thanks Andi.
On Tuesday 21 February 2006 11:10 pm, Joshua Sled wrote: > Author: jsled > + * lib/libqof/qof/qofevent.[ch] (QOF_DEFAULT_EVENT_LIMIT): rename, set > + to reasonable value (the last-defined event). > Modified: gnucash/trunk/lib/libqof/qof/qofevent.h > === > --- gnucash/trunk/lib/libqof/qof/qofevent.h 2006-02-21 21:46:07 UTC (rev > 13351) +++ gnucash/trunk/lib/libqof/qof/qofevent.h2006-02-21 23:10:33 UTC > (rev 13352) @@ -50,11 +50,12 @@ > #define QOF_EVENT_REMOVE (1 << 4) > +#define QOF_EVENT__LASTQOF_EVENT_REMOVE > #define QOF_EVENT_ALL (0xff) (do we need QOF_EVENT_ALL ?) > /** Allow scope for more defaults in future. Additional > event identifiers must be larger than this. */ > -#define QOF_DEFAULT_LIMIT 10 > +#define QOF_DEFAULT_EVENT_LIMIT QOF_EVENT__LAST Josh - why was this a bug? What was wrong with a gap? Supplementary events will now have to be based on QOF_DEFAULT_LIMIT + n rather than just something bigger than 10? I thought nobody wanted to iterate over event identifiers? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpIosTAQA7Ci.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [QOF-devel] Outline of new qofevent support
On Tuesday 21 February 2006 5:07 am, Derek Atkins wrote: > Actually, I just thought of something.. I'd like to have events that > have both subject AND object.. Right now we just have a Subject + > Verb (QofEntity + QofEventId). I'd like to add an object, too, so we > could have an event Subject + Verb + Object (QofEntity + QofEventId + > gpointer). OK. QOF can do that. > The generator and consumer of the QofEventId need to > agree on what the object of the event is. Absolutely. This would almost certainly mean a different QofEventId for each type of object used and expected. That can't be resolved by QOF, it needs to be stated in the docs and left to the user to ensure it actually happens that way. Do you actually want a gpointer or would a QofEntity be a better choice? > Could we add a second set of APIs that parallel the existing set > that let me pass an extra object back to the event handler? ... object, rather than argument, yes? > I'd propose: > > typedef void (*QofEventHandlerWithArg)(QofEntity*, QofEventId, gpointer); WithArg infers non-objects being passed (like a GHashTable or GList, an arbitrary struct / iterator, some arbitrary const gchar* or other weird bits of memory) - was this your intention or would this be a better, clearer, name base? QofEventHandlerWithObject Your use case certainly centres on an item that is more of an Object than some arbitrary argument. I prefer the idea of restricting it to objects - or more precisely, a QofEntity. Maybe even use QofEventHandlerWithEntity > void qof_event_add_handler_with_arg(QofEventHandlerWithArg); qof_event_register_handler_with_object or qof_event_register_handler_with_entity and ditto below: > void qof_event_del_handler_with_arg(QofEventHandlerWithArg); qof_event_unregister_handler_with_object > void qof_event_with_arg(QofEntity*, QofEventId, gpointer); qof_event_gen_with_object ? > I admit this would be a LOT easier if QOF were based on gobject and we > used g_signal... Mea Culpa. Issue postponed until closer to libqof2 which in turn is certainly after G2. > What do you think? Do you need this for QOF 0.6.2 (which otherwise could be released tomorrow) or 0.6.3 which is a likely release in the first week of April (coinciding possibly with 1.9.3)? (i.e. as this is something you've just recently thought up, is the idea due to an immediate need, educated foresight or wishlist?) (I'd like QOF to have a 5-6 week release cycle during the life of gnucash 1.9.x and probably beyond during the life of libqof1. There are a lot of issues to resolve in libqof1 and I'm tackling them one at a time. I want each release to only have one new format added with it's old format being deprecated.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpA3O9im7vY2.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [QOF-devel] Outline of new qofevent support
On Monday 20 February 2006 3:42 pm, Neil Williams wrote: Update: > 3. A new handler prototype is added: QofEventHandler: > typedef void(* QofEventHandler)(QofEntity *ent, QofEventNameConst > event_type, gpointer user_data) where QofEventNameConst is a const gchar*. Modified: typedef void (*QofEventHandler) (QofEntity *ent, QofEventId event_type, gpointer user_data); where typedef gint QofEventId; This makes for easier comparisons. > Although the added names will be available via a foreach, (removed the iteration - not needed) > 4. New events are added as simple strings using void > qof_event_add_name ( QofEventNameConst new_event_name ) at any time prior > to generating an event using that name. (removed need for pre-registration) > Testing continues and then I'll make a QOF 0.6.2 release. continuing -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpUxdubWMaPr.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Release of GnuCash 1.9.1 (unstable)
On Monday 20 February 2006 3:32 pm, Derek Atkins wrote: > http://svn.gnucash.org/trac/browser/gnucash/tags/1.9.1 Ah. OK. > Also, this information /is/ listed in the tarball... (But you have to download all 10Mb before finding that out!) :-) > > I'll sort out the rewrite of gnc-event to qofevent today and then > > release QOF 0.6.2 to regain compatibility with gnucash 1.9.1. > > Can you be sure to pull up the other changes that have been made > to lib/libqof? Yes, I will. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpzn2UH3Fcty.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Outline of new qofevent support
The changes focus on adding extra support for application-specific event names rather than changing the event mechanism itself. 1. The existing events are retained as defaults, initialised internally. 2. These default events remain available to all currently registered event handlers of type GNCEngineEventHandler which are now deprecated. 3. A new handler prototype is added: QofEventHandler: typedef void(* QofEventHandler)(QofEntity *ent, QofEventNameConst event_type, gpointer user_data) where QofEventNameConst is a const gchar*. Only these new handlers will be able to see both default and added events. Although the added names will be available via a foreach, the events themselves cannot be passed to the deprecated handler so there is no point in trying to access the event names. 4. New events are added as simple strings using void qof_event_add_name ( QofEventNameConst new_event_name ) at any time prior to generating an event using that name. 5. Unless an event name is added, events generated using that name will not appear to handlers. (You'll get a PWARN in the qoflog output.) 6. Support for generating events using only the GUID and QofIdType is deprecated. Future event generation should always use the QofEntity (to ensure the GUID really does relate to the supplied QofIdType and to provide handlers with access to the QofCollection, QofInstance and QofBook for that entity). 7. Within new handlers, event names can be processed using a new callback prototype: typedef void(*QofEventNameCB )(QofEventNameConst name, gpointer user_data) using the function: void qof_event_name_foreach ( QofEventNameCB func, gpointer user_data ). This replaces the switch(GNCEngineEventType) syntax of deprecated handlers. 8. GNC_EVENT_ALL is a no-op. It was not supported by gnc-event (it dropped through to the empty default case) and there appears little use for it now. 9. As with all other deprecated code in QOF, the functions have moved to deprecated.c, the declarations to deprecated.h. Both files will be removed when QOF moves to libqof2 (sometime after gnucash 2.0.0 is on full release). 10. Using the deprecated handlers puts messages in the qoflog output (when enabled) to that effect. 11. Any one HandlerInfo can only hold either one deprecated old handler or one new style QofEventHandler so unregistering a handler_id removes whichever handler was specified. 12. gnc_event_register_handler is now deprecated and pointed at qof_event_register_old_handler by a define in deprecated.h. Use qof_event_register_handler for new handlers. Testing continues and then I'll make a QOF 0.6.2 release. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpBa66HN8ZL0.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Release of GnuCash 1.9.1 (unstable)
On Monday 20 February 2006 5:05 am, Chris Lyttle wrote: > The GnuCash development team proudly announces GnuCash 1.9.1 aka "So we > meet again", Suggestion: Can each unstable announcement (and maybe the stable ones afterwards) mention which svn revision was the latest to make it into the release? > o Qof fixes (and can we use QOF rather than Qof? minor point only.) I'll sort out the rewrite of gnc-event to qofevent today and then release QOF 0.6.2 to regain compatibility with gnucash 1.9.1. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgprBtI7Chg4X.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13272 - gnucash/branches/cashutil - Halting the cashutil branch until further notice - development continues outside svn
On Thursday 16 February 2006 12:44 am, Josh Sled wrote: > On Thu, 2006-02-16 at 00:15 +0000, Neil Williams wrote: > > No-one here probably believes me, but IMHO it's actually easier to use > > CVS, makepatch and manifest files rather than svn merge. > > I don't understand why you need to keep track of any more than 1 number > -- that of revision at which point you branched. That's the point, with my preferred system, I don't even have to do that. It's the files that matter, not some arbitrary r number. > And I don't see why > that can't be in a comment, as the SVN docs suggest. Because it's actually quite hard to find that comment amongst the other 13,000 - especially when the last merge was a little while ago. svn doesn't even tell me WHEN. Once that r number is lost, as it was, merge becomes impossible within any reasonable limits of effort. > Frankly, I don't > understand why you're doing any merges at all...? Because I can't build and test cashutil if I haven't got the updated gnucash objects and backend. Frankly, what on earth is the point of having an svn branch if I don't have easy update access to the trunk? > I think a CLI front-end is a valuable (future) addition to gnucash, and > I think cashutil should be part of the gnucash source tree ... in fact, > using the same translations and build system. It's just another > front-end... `./configure --enable-cli --disable-gtk` ... is it not? No, it is not. It is separate, it deserves to be separate and more important than anything else, despite it being in svn I'm the only one working on it and I can no longer work within the svn branch. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpi31TVBW6yf.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13272 - gnucash/branches/cashutil - Halting the cashutil branch until further notice - development continues outside svn
On Wednesday 15 February 2006 11:26 pm, you wrote: > If you're going to kill it, kill it. Don't "move" development outside of > the SVN tree.. That does nobody any good. Sorry, I simply cannot continue with the gnucash branch - I have said that off-list. The code is not in a maintanable state due to problems with svn merge, the builds take far too long because of the extra GUI code and keeping the branch updated with trunk changes has proved to be simply not worth the effort. 'svn merge' is nowhere near as easy as is frequently claimed. The basic problem of having separate translations for cashutil and gnucash has not gone away - in fact it has added to the complexity of the branch. No-one here probably believes me, but IMHO it's actually easier to use CVS, makepatch and manifest files rather than svn merge. Why? Because I don't have to keep track of arbitrary numbers that are outside my control. r numbers may be the bees knees to others here but I just wish that trunk/ had separate r numbers for a branch and that different trees had their own r sequence, not a single sequential number for the entire repository. It perturbs me each time a commit to htdocs increments the revision number for trunk. Completely bizarre in my book. We'll have r numbers in the tens of millions by the time we get to gnucash3. With CVS and makepatch, I can script the entire process and just get on with viewing the changes, before applying the entire patch in a single operation. As I'm the one doing the updates, I choose to step away from a system that simply does not work for me. It can only be good for development of the cashutil project. > it should either be dead dead, or it should continue in SVN. The only way cashutil can continue in gnucash svn is what I mentioned off-list - changing the branch into a tree. I understand why you don't like that option. I'm happy with that, I knew it was a longshot and that it has significant problems of it's own. I'm not killing cashutil, cashutil continues. What has to die is a development method that simply failed to work - cashutil in a gnucash svn branch. I tried it, I messed it up trying to get it to do what I wanted. There is more to free software development than an svn branch - it didn't work out for me, sorry, time to move on to a model that does work for me. It wasted several months and it's time to give up the branch as lost. No-one else appears likely to work on cashutil so it's up to me. GnuCash changed to svn to suit the development needs of the developers; cashutil is changing away from svn to suit the development needs of it's sole developer. Hey-ho, around we go. It's a no-op really. Anyway, free software never dies - it just reaches a pause in development. There's nothing wrong with cashutil that a separate development tree can't fix. What IS wrong is the idea that it can be built as part of a gnucash branch. That idea, sadly, is dead. The project remains. I've already got a new version of cashutil in the wings, updated to use gnucash 1.9.0 code. CashUtil is very much alive and is likely to go to SourceForge CVS in due course. If anyone comes up with a solution for building multiple packages from a single tarball with separate translations (and dependencies) for each, then I'll look at it again AFTER G2 is released. Until then, cashutil will revert to the development method prior to the svn branch creation and move to SF once a usable release is ready. I see no reason to kill the project, I see no future in the svn branch. Something has to give. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpoyF3ms3HWz.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13248 - updated see r13255
On Monday 13 February 2006 6:41 pm, Chris Shoemaker wrote: > [Neil, please remember to cc gnucash-devel for changeset discussion.] (glitch with the mail folders, the CC: line put it into a different location and I didn't notice - v.busy right now.) > > Wrong changeset - there have been improvements since then. See r13255 > > Yes, I know. OK, as long as we're on the same version. > Perhaps I > should have replied to the the 4th changeset. Nah, just me being hasty - maybe if you'd snipped the bit about the original changeset number :-) > > You can't fix one without the other because the first bug exists as the > > original contributor's solution to the second. > > I disagree. However, even if this were true, the fix is insufficient, > since the second bug still remains, so it wouldn't have been solved by > this replacement solution. The failure is avoided but the recursive loop at the centre of the problem does appear to be a key component in the overall calculation. > I understand from your other email (also not cc'd to -devel) that you > don't have the time to fix this at the moment. So, I'll go ahead and > complete steps 1-3 of my recommendation, so then the code will be > ready for you or whomever to debug the infinite-loop when they get a > chance. Step 1 reverses what Christian recommended and I agreed - to use an assertion to indicate that a zero value is not acceptable. A bug it may be, but a zero value will crash the code - as is. As a bug, it deserves an assertion to prevent it OR a complete reworking to avoid it. I can't see that removing the assertions *without* fixing the infinite loop does anyone any favours. If you're willing to fix the problem so that it *can* deal with a zero interest rate, go ahead - just remember to remove the warning from the dialogue. That is the API - the calculator does insist that the interest rate ENTERED by the user is non-zero. (Try it.) However, the original code relied on that safeguard and did not protect against generating a zero rate internally. Fatal flaw that resulted in a very ugly hack to call exit(1) - the original source of the bug. I did say at the time that the exit(1) call was presumably put in by the original author because s/he saw no other way to handle it. It deserved to be removed. The error is only for 0. because it centres on division by zero. Anything other than zero will simply raise a number. Zero itself raises NaN and that's when the calculator hangs gnucash. AFAICT, there is a recursive loop that tries to endlessly calculate 1/0 instead of accepting that it cannot be done (safely). As long as the number is within the limits of a double, we're OK. 1/0 is not, 1 divided by 0.01 is. Do we really need any more accuracy than that? Unless the internal code is rewritten to safely handle zero, then, yes, IMHO zero is an assertion failure - a critical failure that deserves to get the calculator loop shutdown urgently. The fix allows the calculator code to shutdown without affecting gnucash - indeed it allows a zero value to be demonstrated without being explicitly supported. It did NOT deserve to shutdown gnucash. That's now fixed - anything else is a bonus. (If there's time.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpudKJ4sumG4.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13248 - gnucash/trunk/src/calculation - Fix Bug 107876 - financial calculator would call exit(1) if calculation resulted in an interest rate of zero.
On Monday 13 February 2006 11:53 am, Christian Stimming wrote: > Hi Neil, (I'm beginning to regret fixing this bug!) > > Hopefully, using g_return_val_if_fail will make it clear that returning > > 0.0 from functions that calculate interest rates indicates a failure. > However, I think you got the condition in g_return_val_if_fail() the > wrong way -- OMG. Yes. Fixed. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp1V9elo6rby.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: some news coverage and the custom web report
On Monday 13 February 2006 10:34 am, Christian Stimming wrote: > Hi all, > And there is also a slashdot entry > http://slashdot.org/article.pl?sid=06/02/09/1853239 , posted by someone > I don't know, and (of course) the slashdot "community" of trolls and > slashers and a small minority of serious discussions doesn't have too > many friendly things to say. Surprisinly enough, a non-negligible > fraction of comments is relatively friendly and even seems to have > understood the point of an "unstable release, intended for developers > and tester", in stark contrast to the majority of "first post" comments One interesting comment from Josh: Well, we use gtkhtml for rendering the reports, which emit html. While we used to have it setup to do "arbitrary" browsing, I'm pretty sure that's not working in 2.0. It [abritrary browsing from w/in GnuCash] is certainly not a direction the current devs are interested in going. As the "Custom Web Report" isn't working in svn (I've checked - it prints messages about wanting a replacement library), shouldn't we just remove it? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpuK7zBD28Jy.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13248 - gnucash/trunk/src/calculation - Fix Bug 107876 - financial calculator would call exit(1) if calculation resulted in an interest rate of zero.
On Monday 13 February 2006 9:51 am, Christian Stimming wrote: > Hi Neil, > > > I'm setting up an error state that is perpetuated through the code. > > Oh no. This means you are using the code pattern "one special > calculation return value corresponds to an error value". This code > pattern should better be avoided, if at all possible. I wish it was. However, I can't get assertions to do the job, we just go back into the infinite loop - probably because assert doesn't change the value being returned. What I needed was: #include ... g_return_val_if_fail(eint == 0.0, 0.0); But when I looked at this last night, I didn't want to have to add glib.h just for the error case. The assert commands - like the fprintf before it - fail to actually print to the terminal unless the calculation code is allowed to call exit. I've tried fflush with no success. With g_return_... I get the following entries in /tmp/gnucash.trace: _C: assertion `eint == 0.0' failed _C: assertion `eint == 0.0' failed _C: assertion `eint == 0.0' failed Warning: PrintAmountInternal(): Problem with remainder. _C: assertion `eint == 0.0' failed _C: assertion `eint == 0.0' failed Warning: PrintAmountInternal(): Problem with remainder. So even with the assertions, the code continues to try to calculate - this is the quickest I can get the code to abort - even using the error state. :-( > In this fin.c > case, I don't understand why a different solution isn't possible -- Because unless the return value is set to the error state, the recursive loop becomes infinite. Hopefully, using g_return_val_if_fail will make it clear that returning 0.0 from functions that calculate interest rates indicates a failure. > The calling function _C() obviously will then have the restriction that > eint must be nonzero as well, and it is called a few more times, but it > shouldn't be too difficult to add these checks to all calling places as > well. Please replace your "returned special error code" by a check for > nonzero-ness up front. I tried it but could not get it to work with assert() from It does work when the return value is set to the error state. Using g_return_val_if_fail just makes that clearer when reading the code later - the error state itself persists. Done in r13254. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp1jmrpj9BFH.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13248 - gnucash/trunk/src/calculation - Fix Bug 107876 - financial calculator would call exit(1) if calculation resulted in an interest rate of zero.
On Monday 13 February 2006 2:08 am, Derek Atkins wrote:
> Quoting Neil Williams <[EMAIL PROTECTED]>:
> > _C (double eint, double pmt, unsigned beg)
> > {
> > - return pmt * _B (eint, beg);
> > + unsigned check = _B (eint, beg);
> I'm not convinced this patch is correct. _B() returns a double,
I'm setting up an error state that is perpetuated through the code. If these
are converted back to doubles, gnucash goes into an infinite loop. I'll do
something about the data loss but we have to break the loop too.
I started looking at this just as you did - but eint == 0.0 must be treated as
a special case or the whole thing gets v.ugly.
> but
> you're assigning it to an unsigned -- so you're going to lose data
> in the case.
Once you get to eint == 0.0 being true, the game is up, the code must simply
shutdown ASAP. The code becomes unstable and far more serious data loss is
inevitable. Data loss within the calculator at that point is largely
irrelevant.
This is why exit(1) was being called originally - brute force error handling.
:-(
I've set a wrapper so that the data is preserved in the normal case but the
error state itself does need to be an unsigned int.
> I also don't see why it matters here; there's nothing
> illegal about multiplying by zero.
You'd have thought that, (I did), but reverting causes a permanent loop to be
setup.
All these zero checks are nothing to do with the calculation, these are
intended only as an error state and all code is to abort when this state is
detected. There is no point worrying about data that may need to be
calculated once eint is 0.0, it cannot be done. We just get out of the code
as fast as we can.
> You're also inconsistent with your checks. Sometimes you say:
> if (foo)
The next line takes care of if (foo == 0.0) in the ? : ; conditional. We just
don't want this line executing:
CC = (CC - fv) / (CC + pv);
if CC == 0.0
I know it should be OK because of the +pv but the code just keeps on looping.
we can't risk _any_ calculation once eint == 0.0.
> > + if(CC == 0) return 0.0;
>
> And yet another inconsistency -- == 0 instead of == 0.0.
Sorry about that, got carried away with the int error state. Fixed.
> Are you sure this code even still works? Is there a test case that shows
> the actual bug(s)?
Yes and yes, in the bug report.
http://bugzilla.gnome.org/show_bug.cgi?id=107876
Enter any set of figures that would result from a zero-interest loan.
e.g. Clear interest rate, clear future value and payment amount. Set payment
amount to a simple denominator of the loan amount (500) and future value to
zero. Click calculate.
Gnucash would simply shutdown with exit(1) - offering no chance to save the
current data file - hence the original bug. Now the calculator aborts and
displays an interest rate of '-' and gnucash keeps running. It's almost
intuitive, as errors go.
;-)
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpN22HMlZwwf.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Build and run in separate directory - OSX?
On Sunday 12 February 2006 10:19 pm, Mike Alexander wrote: > > I build gnucash svn regularly on OSX 10.3 using fink. The OSX/Fink > > maintainer for gnucash (Peter O'Gorman) also builds 1.8 and (IIRC) > > svn on 10.4? (Peter?) > > Yes, I'm using MacOSX, but not the Fink version of gnucash OK. Only trying to help. I'm not sure why you want to build gnucash this way but you are, naturally, free to do so. I know fink can be awkward at times but, IMHO, that is how most OSX users are going to obtain gnucash. > (I used Fink > for some of the prereqs simply because it was the easiest way to get > them). I'm building it from the svn source (as I said in my message). I too build svn on OSX using libraries etc. installed via fink. I have also tested a fink info file for QOF so that it can be made available via fink and I build pilot-qof on OSX (although because OSX has problems with USB devices because pilot-link 0.12 is so delayed). > My build builds cleanly (with no compiler warnings) and runs fine. Good. > I'm > not looking for advice on how to build gnucash, I'm just offering you > fixes that make it build better. When using an uncommon build method. It has built fine using the existing methods on OSX for some time. What are the advantages of enabling gnucash to build and run in separate directories? Not just to you, to other users too. i.e. what do we gain? > >> --enable-compiler-warnings=minimum \ > > > > To get gnucash to work, you'll need to up that level or just leave > > off the =minimum. > > I'm not using the tarball and I don't get any compiler warnings. (setting minimum could mean you are missing some) > Just because I'm using Darwin doesn't mean I'm an idiot or a novice. At no point did I intend to give that impression. I was only trying to be helpful - all manner of people raise questions on these lists. Sometimes it pays to latch on to little nuggets in the provided output. > Like it or not, Darwin is now the most widely used desktop Unix system > and making gnucash work well on it is in the best interest of the > gnucash project. Of course it is - I'm just not sure that this separate directory build is necessarily required for builds on Darwin. (And I do like Darwin, I use it and develop on it myself.) > However, I don't think any of the problems I've > submitted patches for are Darwin specific. I could reproduce them on > Solaris or Linux, but it probably isn't worth the trouble. So the question is, apart from these specific tools that you use, what benefits are there - for the masses out there - of using the separate directories? I'm genuinely curious. Debian (my other platform) has pbuilder, we use 'make distcheck', fink has info files and a similar build protocol to Debian. Each uses their own build directory architecture and hierarchy and gnucash does work on all these. I know Derek has (or had) Solaris and we have maintainers interested in providing gnucash for Mandrake/Mandriva, SuSE, Slackware, OpenBSD, NetBSD as well as our "base platform" of FC3, I build regularly on Debian and OSX, David on FC(5?) and the list goes on. (IIRC, Chris - FC4?) It's a lot of work maintaining gnucash on these platforms - especially with the old 1.8 tree because quite a few gnucash maintainers ended up maintaining most of the gnome1 libraries that only gnucash needed. We're looking to ease the burden on all these maintainers with the 1.9.0 and 2.0.0 releases. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpYNdsYydXIZ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: New qof/engine tests
On Sunday 12 February 2006 6:58 pm, Derek Atkins wrote: > If they actually test against GncCustomer, et al then they can't live > in src/engine/test. No, the improvements in the code from creating the tests will benefit gncCustomer et al, but the tests themselves use entirely independent objects. > Shouldn't this code go in libqof/qof/test? OK. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpHPw2v9diNG.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
New qof/engine tests
I've got a test-events.c and test-recursive.c in QOF CVS but they aren't complete yet. They do run without failures (so won't interrupt make check). I've used them in libqof to improve the recursive copying code (e.g. to export an invoice with all it's data, like customer, job, address, billterms, etc.). Shall I test them in src/engine/tests/ and commit now; leave them until they are both fully functional (~1 week); or leave them just in qof cvs? (not my favourite option.) test-events.c will be used to ensure that the upcoming change from gnc-event.c to qofevent.c is backwards compatible. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp0prArJBuaR.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems running GnuCash 1.9.0 on kubuntu 5.10
On Sunday 12 February 2006 4:47 pm, Derek Atkins wrote:
> > I know how that happens - gnucash tries to identify the file by letting
> > each backend try to open it in turn. If none can open it, it complains
> > that it cannot understand which type of file it is meant to be. We can't
> > use mimetypes to distinguish the forms (as two are text/xml and we've
> > never enforced a mime-type on old files) so we do have to open the file
> > to determine the type.
>
> Well, the other option is to actually pass the error up the stack
> so that the caller can get a GNC_BACKEND_ERR_FILE_INACCESSIBLE (or
> something like that) up the stack..
But when trying to determine the type, all we know is if it is the correct
type or not. In QSF, I'm implementing :
f=fopen(path, "r");
if(!f){ qof_backend_set_error(...);}
fclose(f);
block that sets a new QofBackendError: ERR_FILEIO_READ_ERROR at the start of
the file type check which I can also implement in gnucash. So at least then,
if we can't open the file for reading, we can set a backend error and quit
the load.
I'm still sorting out recursive copies. I've got G2 to produce a 1.1Mb QSF
XML file containing all my invoice data : gncInvoice, gncBillTerm, Account,
Transaction, gncCustomer, gncJob, everything referenced by a gncInvoice is
copied. Once sorted, I'll see about exporting individual invoices in this
way. Right now, I've still got awkward problems with collections.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpymnPtAFTtG.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems running GnuCash 1.9.0 on kubuntu 5.10
On Sunday 12 February 2006 12:31 am, Derek Atkins wrote: > Ah, right.. that's a 1.9.6-ism. Are you perhaps missing the > guile-g-wrap package? > > -derek This has tripped up other users as well, http://bugzilla.gnome.org/show_bug.cgi?id=330560 Isn't there some way configure can check for guile-g-wrap? Maybe check for libgw-guile-standard.so ? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpKOq5E2upao.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Build and run in separate directory - OSX?
On Sunday 12 February 2006 6:41 am, Mike Alexander wrote: > I then cd'ed > into /tools/gnucash-1.9/build/ *darwin* _darwin_ - this would be OSX? 10.3 or 10.4? Fink? DarwinPorts? I build gnucash svn regularly on OSX 10.3 using fink. The OSX/Fink maintainer for gnucash (Peter O'Gorman) also builds 1.8 and (IIRC) svn on 10.4? (Peter?) There is no need to build and run in separate directories for darwin. I use a script: #!/bin/bash export LIBTOOL="glibtool" export PATH="/sw/bin:$PATH" export ACLOCAL_FLAGS="-I /sw/share/aclocal" cd /opt/working/gnucash/ guile16-build env LIBRARY_PATH=/sw/lib/ CPATH=/sw/include \ ./autogen.sh guile16-build env LIBRARY_PATH=/sw/lib/ CPATH=/sw/include \ ./configure --disable-qof --enable-doxygen --enable-opt-style-install --prefix=/opt/fergus/gnucash make uninstall rm -rf /opt/fergus/gnucash make distclean guile16-build env LIBRARY_PATH=/sw/lib/ CPATH=/sw/include \ ./autogen.sh guile16-build env LIBRARY_PATH=/sw/lib/ CPATH=/sw/include \ ./configure --disable-qof --enable-doxygen --enable-opt-style-install --prefix=/opt/fergus/gnucash For the 1.9.0 distribution tarball, omit the call to autogen.sh If this is darwin and you don't substitute glibtool or set the path to look in /sw/bin before anywhere else (or whatever other prefix you've set for fink), gnucash may get so far but it will not link successfully. It leads to some nasty (and misleading) error messages and crashes. Ditto the prefix to call guile16-build. > (which was empty) and ran > configure as > > ../../gnucash-1.9/configure \ > --prefix=/tools/gnucash-1.9/install \ > --exec-prefix=/tools/gnucash-1.9/install/darwin \ > --enable-prefer-db1=no \ > --disable-static \ > --enable-ofx \ > --enable-doxygen \ > --enable-maintainer-mode \ This should not be specified when building from a distribution tarball - it's intended for svn builds (but I think it actually does nothing in the current gnucash build anyway). > --enable-compiler-warnings=minimum \ To get gnucash to work, you'll need to up that level or just leave off the =minimum. > --with-g-wrap-prefix=/tools/g-wrap-1.9.6/install/darwin There's that darwin again. > Running make in build/darwin/intl-scm gives these errors: > Running make in build/darwin/lib/libqof/backend/file gives the errors > > There are many other errors of this sort in other directories. But, let me guess, they all refer back to 'darwin'. > The two patches above fix these problems for me. I realize that I'm > building things in a rather odd way, but I'm trying to use some build > tools originally meant for other purposes. Building gnucash on OSX can be hard enough using fink, but at least it does work (I've been building svn on OSX regularly for months). I do have problems with make check but the application itself does work. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpNV6v1wWtLA.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Problems running GnuCash 1.9.0 on kubuntu 5.10
On Sunday 12 February 2006 1:44 am, Aaron Larson wrote: > Thanks, that got it. Perhaps this is a good place to mention that I > was pretty confused when installing the dependencies mentioned in > http://svn.gnucash.org/trac/browser/gnucash/trunk/README.dependencies > The packages listed in the ubuntu 5.10 section don't seem to match > what I had to install If you've got a record of what you did install or just have a list of package names and versions from 'dpkg -l' to replace the ones that don't exist on Ubuntu, send them to the list as a patch for README.dependencies. I don't know if Ubuntu changes package names between releases - would package names in Breezy be any different to Dapper? > It > seems like it would be "a good idea" to have a package specification, > or an apt-get command line, or something that would retrieve the > required packages. If you have an update from your own setup, send it in. The need for so many libg* libraries is because you're running Kubuntu which is predisposed to KDE, IIRC. It may merit a different section in README.dependencies compared to Ubuntu which may carry some of the gnome libraries by default. Remember, gnucash has been updated to Gnome2 libraries but those are still Gnome libraries, not KDE ones. It will run under KDE (I do it that way) - it just needs some libraries, not the entire Gnome desktop. > Pointers to such a thing would be appreciated, or > if it doesn't exist and its a good idea to have one, suggestions for > what form it should take and where I could construct it are solicited. OK. If you know which packages are different: $ dpkg -l will give you what we need for that package. (that's a lower-case L if it's unclear.) > Now, I think I have my first (mini) bug. When opening a file that the > user doesn't have read access to, the error is a bit cryptic: > > The file type of file is unknown. I know how that happens - gnucash tries to identify the file by letting each backend try to open it in turn. If none can open it, it complains that it cannot understand which type of file it is meant to be. We can't use mimetypes to distinguish the forms (as two are text/xml and we've never enforced a mime-type on old files) so we do have to open the file to determine the type. > Rather than some permission error. I think we can determine if the problem is the wrong type or the wrong permissions - probably by trying a fopen() fclose() prior to trying to determine the type. The best thing is to submit this to Bugzilla. > It had me thinking I missed some > upgrade note or something indicating the file format had changed. I > couldn't find a reference to this in Bugzilla. Is this sort of thing > considered "bug worthy"? Yes. If error messages are not helpful or actually misleading, that is a bug. (normal severity). -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp3EvHWw4Pu6.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: New gnucash website - demo available, new content needed.
On Sunday 12 February 2006 1:36 am, Conrad Canterford wrote: > I didn't pry too deeply, but it looks pretty good from here :-) :-) > Neil, the donations page shows a balance from June 2004 I've been working on the structure of the site, rather than the content. New and updated content should be going in soon (and will be simple to update via svn). > (and yes, I was > looking at Neils page, not at the .au mirror site (see below)). Have we > made a decision not to update this Other developers have been waiting whilst I completed the restructuring, that's all. > While poking around I also looked at the AU mirror site... and worked > out that it hasn't updated since 2004. By mirroring the new site in SVN, it is possible to have all mirrors updated on a continual basis. It doesn't need to be frequent, daily should be fine and maybe once the new content is in, even weekly. (Except near release time when the mirrors should really check for news updates more frequently.) Just set up a cron job and tweak it close to release time. i.e. updates are a 'pull' model, we can't push updates to the mirrors. All mirrors will carry all translations but individual mirrors may need extra locales installed to get some translations to work. With enough mirrors, those who don't have sufficient access to install locales may be able to redirect to one that does carry the requested translation. > I believe this is hosted by > planetmirror (the source mirror link is also broken, and its a > planetmirror link). (It doesn't have to stay at planetmirror - if you've got access to planetmirror or some other hosting space, checkout a copy from svn.) ;-) I may keep the demo site as a uk/en_GB mirror - the EU mirror does update, (it's carrying the 1.9.0 announcement) but there's no harm in having another mirror. (The EU mirror, for some reason, isn't currently displaying the link back to the US or AU sites but that will change once the mirror moves to updating via svn.) The EU mirror is using the 'at' subdomain (Austria). Derek: Would it be useful to direct www.uk.gnucash.org to the demo site at http://gnucash.neil.williamsleesmill.me.uk/ ? I could tweak the existing virtual host at this end if the DNS was to point to the correct IP. Or would '.gb.' be preferable? (i.e. do we go by DNS TLD country codes or translation country codes - probably TLD -> uk?) > Does anyone have any contact with whoever set this up on planetmirror? Not needed. If there is no-one from this list or the user list who has access to the old link, just make a new mirror somewhere else where someone does have access. There's no limit to the number of mirrors. > Can we poke them to see if they can get it updating again? Or remove > it If it's not updated, it'll be redirected just as soon as there is a replacement. (hint) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgppWYgWhR24h.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
New gnucash website - demo available, new content needed.
The www.gnucash.org website has undergone an overhaul since going into svn. Large sections that have moved to the wiki have been removed from the main site and a new translation mechanism, using gettext and PHP, is in place. The bulk of the navigation links redirect to the wiki. If your browser correctly sets your language preferences, the site will look for a matching translation. Currently, the only translation is en_GB but any European language can be supported easily - other languages may just need a tweak on the demo and/or main server to install locale support. If no translation is found for any particular message, en_US is used. The bulk of the translatable messages are not likely to change, ever, because they are from the oldnews page, but translators should note that there are some strings that are likely to change. There is a POT file available for translators (currently 1,201 messages) to view in advance of a string freeze once other contributors are happy with the new content. The POT file can be generated from the svn export/checkout. http://www.linux.codehelp.co.uk/i18n/gnucash-htdocs.pot.gz (Translators can start working on any message in www/oldnews.phtml) Instructions in the README in svn. The code is due to transfer to the main gnucash site on Monday but is now ready for testing at: http://gnucash.neil.williamsleesmill.me.uk/ To see the translation, change your browser preferences to look for en_GB before en or en_US. (Firefox may need a restart to properly change the language preferences - it tries to read from it's cache otherwise.) The en_GB translation primarily changes check to cheque, color to colour and favorite to favourite, etc. (Two nations divided by a common language.) Once French, German, Dutch and Portuguese translations become available, the relevant links on the header will be updated to assist those visitors whose browsers don't set the language properly. The Feature slideshow needs updating - new screenshots and new content - via svn. The Documentation page "Tutorial and Help" also needs updating as the gnucash-docs get updated for 2.0. New news items can be uploaded as text/plain. I've got a few more tweaks to put in place for translation of 'new' news. https://lists.gnucash.org/pipermail/gnucash-devel/2006-January/015849.html Oldnews may be split into sub-pages later but this won't affect translation (new .mo binaries can be generated without requiring a new file from the translator). The demo site only updates from svn once daily. Changes should be checked in a local mirror prior to commit. To use an svn checkout with apache, you may need to hide the .svn folder in each directory. See https://lists.gnucash.org/pipermail/gnucash-devel/2006-January/015874.html -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp3DKKbcpDda.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: htdocs and the newest news.
On Saturday 11 February 2006 7:24 pm, Derek Atkins wrote: > > How many sites are actually translated? The old method of separate > > directories led to huge inconsistencies in the different sites and > > still left large sections untranslated. > > Depends on your definition to "translated". To me, as a user, a > translated site is one where I click on an icon (usually a flag, > but sometimes a country name) and see the site in that language. > As a user I don't particularly care how that happens. Well, we are one step ahead there because the PHP translation happens without any clicks whatsoever. (The user only needs to click if their browser fails to declare the correct language variable.) Once some translations come in, I'll change the current links to simply load the correct translation and put a note on the site about how to force the browser to pass the correct language using a querystring ?lang= > As a developer, I want to make the process as simple and > straightforward as possible, and try not to overload the poor > webserver. It seems very light-on-it's-feet so far - most of the translation happens in cache and PHP itself is, IMHO, no slower than redirecting Apache to a separate sub-domain. > Keep in mind that www.gnucash.org is a rather old, overutilized > machine. So, yes, CPU usage per-page is definitely an issue to think > about. The demo machine isn't exactly new - from memory it's at least 10yrs old. It's running maybe a dozen other websites, some quite busy and some with some seriously large (image based) pages. > > As for the content, I can't find any reference to translating the content > > of MediaWiki sites into multiple languages per site, i.e. i18n. Being a > > wiki, the strings in Language.php can be edited in the wiki itself but > > only by admins - one per site. Further development of i18n is still only > > in the planning stage: > > http://meta.wikimedia.org/wiki/Interface_translations_wiki > > It's the content that interests me.. (and me) > As we're moving most of the > content from www.gnucash.org into the wiki, it would seem to imply > that we want to have the wiki content internationalized too, right? If we can . . . but that's nothing to do with the htdocs svn module. The wiki, unfortunately, is almost certain to require a completely different method of translation. > > (Why is this all up to me? Does anyone have some ideas about what we want > > in the Features pages?) I don't think I'm best placed to decide what we > > put up there. > > It's not all up to you.. :-) Thanks. > But I think most people are waiting for you > to finalize the website format before they go make changes to the > content. I've marked up the features pages for new content, I'll commit a few other mark up changes and a tweak to oldnews. Then I'm done. I'll make an announcement on -user and -devel tonight. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpFvJQ0D7G50.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: htdocs and the newest news.
uage.php can be edited in the wiki itself but only by admins - one per site. Further development of i18n is still only in the planning stage: http://meta.wikimedia.org/wiki/Interface_translations_wiki > > I guess the answer to both is a decent syntax highlighting editor. I > > use gedit for php and html - bluefish is good too, as it Kate, or my > > old stalwart, vi. ;-) > > See, I use emacs which makes paren-highlighting very easy.. Every > time you hit right-paren it shows you the corresponding left-paren. I have that too, but it doesn't seem to work with scheme. There are always more ) than (. > Right, which makes the website accessibility even MORE imporant! The > website is what entices the user to download the program. It NEEDS to > be there. > > Speaking of which, we're already getting requests for 1.9 screenshots! (Why is this all up to me? Does anyone have some ideas about what we want in the Features pages?) I don't think I'm best placed to decide what we put up there. > PS: It sounds like Linas is going to update the website to pull from > SVN on MONDAY. So we should have most stuff "solved" by then. ;) OK. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgprxsXIHAFun.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: QOF events (was: Re: the changeset)
On Saturday 11 February 2006 2:39 pm, Derek Atkins wrote: > I'm not sure what exactly you could test here.. It's not like > there's a testable behavior. A test object, two sample handlers, a context and it's OK. I check that the correct handler is being called with the correct info, I check that handlers are registered and unregistered (although this test will only be thorough once the enum is replaced), I explicitly check for the bug that Chris reported and with your patch I can show that it is fixed. > You're not guaranteed a crash, With Chris' report, yes, you were guaranteed a crash. With your patch, it's fixed. The method is to register two handlers, then in a DELETE event in one handler, you unregister the handler that was registered *first* - because new handlers are prepended to the list, this is due to be called next. Seg. fault. Everytime. Once patched, it works fine. I also test in reverse (just to make sure). > I suppose you could create a testcase where you have two callback > functions that share some state and then you can error out when a > callback function is executed when it shouldn't be. I check that too - using the context. I've got a few more tests to add and then I'll commit it and you can see what I'm testing. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpYYlry2fG8N.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Extending the GNC-Event enumeration (QOF API Change?)
On Friday 10 February 2006 11:04 pm, Derek Atkins wrote: > I need to extend the list of events in qof/gnc-event.h to add > at least two new events (I'm not sure what to call them, yet). > I'd rather get them into the QOF code now rather than need to > figure out how to get them in later on when I find the time > to rework the events in the register, etc. Good idea and a very important point. In general, there are no problems adding elements to the API. If there's no overlap or replacement of existing interfaces, it's simple. As far as events are concerned, I'm unconvinced that QOF needs to know anything more about the event than: 1. This event is / is not different to the other events. 2. There is / is not a handler registered for this event. 3. That there are certain default events that it can use for it's own actions - qof_init() can set these up, once the change is in. Quite what each event does, means or achieves beyond that is actually application-specific. i.e. QOF neither knows nor cares about why you need to handle 'container_member_added' differently to GNC_EVENT_CREATE. QOF should not have to know either. It just needs to have a "baseline" and it should allow any application to set as many event types as that application needs. In that context, exposing the enum is prohibitively restrictive and it needs to be deprecated in libqof1 so that it can be replaced in libqof2. > So what's the best way to go about this? The events I'm > going to want to get are to handle: > > container_member_added > container_member_removed > container_member_changed > > Note that there's an ADD and REMOVE already, but these are currently > used to handle the reshuffling of accounts in the account tree. I > want to specifically get events when a transaction is added to an > account or removed from an account (or when a GncEntry is added or > removed from an Invoice). As far as gnc-event should be concerned, they are just different events. The identity or meaning of the event is of no concern to QOF, except that each event must be uniquely identifiable to be matched with the handler. These might as well just be events 1 through 10 - but strings are easier to use in a hashtable. > This way we can differentiate between changes made to an account via > the Edit Account dialog and changes made to an account through the > register. > > I guess the /biggest/ problem is that the event enumeration list > is part of the QOF API and not very extensible. :( Scheduled for conversion when gnc-event.c becomes qofevent.c. I'm thinking of a similar method to qoflog - an internal hashtable. Consider the enum deprecated. I'll implement a generic version that applications can use as they see fit. > So, what do we do here? I'll look at it further over the weekend but here's my first thoughts: 1. the enum can be retired for new code. I'll look at an arbitrary event_ID tag - much like a QofLogModule - that is simply a key to lookup a value because that is all QOF actually needs here. Like QofLogModule, a const gchar* may be the best type. Say, QofEventName - to reinforce the idea that this is not a strict set of types. 2. Support old code by setting the enum values as defaults in the table and implementing deprecated wrappers that do the conversion for us (via enum_as_string macros). The bit operators would not be necessary. 3. New code could use a new handler definition - using a const gchar* instead of GNCEngineEventType. Again, a deprecated wrapper takes care of backwards compatibility, maintaining support for the current API whilst still extending it. 4. It is the responsibility of the application to use the same string when registering as when calling. Any unregistered eventname (i.e. typo) would be equivalent to GNC_EVENT_NONE. Old style handlers would be ignored if a new style event is passed (the enum_as_string macro would return NULL and the opposite conversion would return GNC_EVENT_NONE). Old style events would be converted to the enum value to maintain compatibility. There may be hidden problems in this so don't take this as absolute - it's just my first thoughts before I turn in for the night. (As such, some parts may have suffered from me being tired!) I'll look at it again in the morning - a test routine has become all the more important now. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpU7q4UaDAoQ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13152 - gnucash/trunk/lib/libqof/qof - Don't allow the event handler list to shrink while we're traversing it.
On Friday 10 February 2006 10:49 pm, Chris Shoemaker wrote: > > Is there a test case I can use? Was the crash described below part of a > > bug report? How can I reproduce it? > > There's no bug report - I hit the bug myself. To reproduce it you can > revert the fix (locally, of course) (I'd build gnucash against local QOF CVS, currently unpatched, using the configure options to re-enable external QOF. I already have a second gnucash tree just for this purpose - gnucash-qof and gnucash-internal.) > and just keep testing until you > get unlucky, :-( > or you can write a test case that adds two handlers and > then tries to unregister the second from within the first. Sounds like a much better plan! (It needs a test routine anyway.) > I think I > was closing the main account-tree when I hit it. Thanks. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpPIH8Qw4Bo2.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13152 - gnucash/trunk/lib/libqof/qof - Don't allow the event handler list to shrink while we're traversing it.
On Friday 10 February 2006 10:43 pm, [EMAIL PROTECTED] wrote: > FYI, I've got a fix in place now that I'm about to commit. > > -derek Thanks - looks v.good at this end. I'll look at creating a test routine in QOF for events - once I've ironed out problems in recursive copying. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpBgRjwUMNw1.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13152 - gnucash/trunk/lib/libqof/qof - Don't allow the event handler list to shrink while we're traversing it.
On Friday 10 February 2006 10:06 pm, Derek Atkins wrote: > It's not the best solution. It /is/ simplistic. But the problem is > that the code is re-entrant but it's not quite handling that properly. OK, that gives me a starting point. > Hopefully Chris will chime in here. I honestly don't know offhand > what crash he's seeing, but it's certainly a theoretical problem due > to the re-entrancy. I agree. > > What about making this stage conditional? (It would at least limit the > > inexorable growth of the list.) > > I'm not sure how you make it conditional. The real fix is to do > delayed destruction of the event handler, but then you also need a > nest calculator to make sure you clean up only at nestlevel 0. This > requires at least changing the ABI if not the API What about doing that clean up internally? (at the end of the loop?) > (I don't recall if > the event-handler list is a public QOF object or not). It's not. Only registering and unregistering event handlers is supported in the API. The list is never exposed, there's no foreach or even a count available outside QOF. > Chris, Josh, David, and I had a dicussion about this on IRC before > Chris made this change (see what you miss by not hanging out on IRC?) (There was no way I'd have been around at the time that discussion was going on. Even allowing for timezones, I wasn't online due to other commitments.) > Yes, this is a short-term fix to keep the accessing freed memory. > It's not a long-term fix, which requires a little bit of > re-architecting the QOF Event code. OK. > > This isn't an API issue, it's a technical issue about how best to > > prevent this crash without causing another elsewhere by consuming > > resources on a much more limited platform. > > It /may/ be an API issue depending on whether the eventlist objects > are opaque or not. They are. > I don't recall and I haven't looked right now. > I'll go take a look this evening or this weekend and see if I can come > up with something. Thanks. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpyB7t75qPbf.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: htdocs and the newest news.
On Friday 10 February 2006 9:56 pm, Derek Atkins wrote: > True, although one would think we could continue to do translation via > separate translation subdirs (at least for the main content -- it > probably makes sense to use php + gettext to translate the menus -- > the menus dont change). OK. With the exception of the news files, the website in svn isn't going to change often. > My fear is that someone makes a small change to a website and now the > international viewer gets a partial translation until the po file gets > updated. I suppose the flip side is an out-of-date translation.. but > I'm not sure which is worse, out of date or partial. ? Either present as the same - if the po file is behind the site, English will prevail. It's just how gettext works. (en_US in our case). The existing translations are outdated and partial. At least having a familiar po file (with a smattering of newer news in a single language dependent directory) should be easier than asking people to translate a mixture of HTML, PHP and TXT files across some twenty subdirectories. Judging by how programs get translated, I'd say partial is not as bad to the users as we may like to think. Lots and lots of translated programs have only a fraction of the total number of messages translated. As long as certain critical areas are covered, many users seem happy with partial. The existing wiki translation help can guide others in how to add more translated messages. > > What do you think about translating the news items? > > I still have no idea who does this translation.. I'm sure someone will volunteer in time - after all that's how we have the current mix. Having a POT file may help as it's easier to handle than the previous format. We can ask the GNU Translation Project. > But my feeling is > that yes, news should be translated if there's a translation > available; otherwise it should be printed in English. gettext does that for us, just like with the gnucash code. I'll sort out the rest via the news-script. > > My conversion of oldnews.phtml is geared more towards easier translation > > than easier editing > For the news file I think it's more important towards easier editing. Fair enough. > In fact I almost think that's true for the normal website content, > too.. Keep in mind that MOST of the content is now off on the Wiki, > and the wiki is NOT translated! The Wiki, however, is a lot easier for people to amend and if someone wants to add a translation of an existing page, they can. It's just not transparent as if the site was to detect the language from the browser, as the main site now does. > I honestly have no idea. I'd like to think that news will get > translated, but I also have no idea how rapidly changes to the website > will get translated. Same here. > Keep in mind it can take weeks or months to get > application translation, and AFAIK we still don't get full > translations! I can't imagine how rapidly website content will get > translated. How often are we actually going to be changing it? (with the exception of news?) Most changing content will be on the wiki. > I think multiple translation files is just file.. It's easy to upload > content to the website (or at least it will be once the migration is > done). Indeed, I think multiple small translated news files is going > to be MUCH better than a single PO file. OK. I'm easy with that. > Why can't we do something like: news-script.php can do what we need - it already has the necessary code. > We know what language the user wants. Why can't we just go over the > list of news items and if there's an entry in the translated news > directory we use that instead of the english version? No problem - now that I don't have to get news into a single po file. > Unmatched parentheses in scheme is just as bad as umatched > greater-than, less-than tags in PHP/HTML, and remembering to do the ?> > to close your tags and such. Uggh.. :-) I guess the answer to both is a decent syntax highlighting editor. I use gedit for php and html - bluefish is good too, as it Kate, or my old stalwart, vi. ;-) > > (and php is only on the website, it's not as critical as the scheme in > > gnucash.) > > I dont know -- people who can't get to the website usually can't > download the program! :) :-) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpHpqkBEsonI.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13152 - gnucash/trunk/lib/libqof/qof - Don't allow the event handler list to shrink while we're traversing it.
On Wednesday 08 February 2006 6:04 am > Date: 2006-02-08 01:04:51 -0500 (Wed, 08 Feb 2006) > New Revision: 13152 > Trac: http://svn.gnucash.org/trac/changeset/13152 I've been wondering about this ever since it went in, I'm not sure if it's the best solution. It seems a little too simplistic. Is there a test case I can use? Was the crash described below part of a bug report? How can I reproduce it? > Modified: >gnucash/trunk/lib/libqof/qof/gnc-event.c > Log: >Don't allow the event handler list to shrink while we're traversing it. What about making this stage conditional? (It would at least limit the inexorable growth of the list.) > +/* Normally, we could actually remove the handler's node from the > + list, but we may be unregistering the event handler as a result > + of a generated event, such as GNC_EVENT_DESTROY. In that case, > + we're in the middle of walking the GList and it is wrong to > + modify the list. So, instead, we just NULL the handler. */ If GNCEngineEventType != GNC_EVENT_DESTROY, remove the handler node? >This change isn't ideal in the sense that the handler list is now a >monotonically increasing resource, This worries me - consider if the events are used in a situation where resources are far more limited than in a desktop computer. How big does this list now become if the process is in use continually? >but it's better than crashing when > the handler in node N+1 happens to be deleted while servicing the handler > in node N. Isn't there some way we can test for N+1 != NULL? (we probably should be doing that anyway.) Perhaps we need a hypothetical function on the lines of: static void qofevent_resort_list(void) that is called internally before events are resumed (if suspend_counter == 0 after being decremented) or at some other point when it would be safe to do so? It could iterate over the list, creating a new list that had no gaps, before using that to replace the original. I'd rather not have to iterate so maybe instead of setting the handler to NULL, we can store it somewhere and remove specific handlers when it is safe to do so? (at the end of the loop?) This isn't an API issue, it's a technical issue about how best to prevent this crash without causing another elsewhere by consuming resources on a much more limited platform. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp1FTNhmW7w1.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: htdocs and the newest news.
On Friday 10 February 2006 2:28 pm, Derek Atkins wrote: > Neil Williams <[EMAIL PROTECTED]> writes: > > But, as of now, what is the feeling on the simplified site? > > Looks pretty good to me.. Thanks. > > (I'm also going to create some scripts to automate various stages of the > > translation handling, improve the README and other bits.) > > I'm a bit concerned that the translations are done via php. My reasons were relatively simple: 1. The old site was already using php, albeit without translation. 2. PHP and gettext work well together 3. Using PHP for all translatable text generates a single POT file which is always preferable for translators. What do you think about translating the news items? > when I'm working on a web page I don't want to have to make sure > I get my php quoting syntax correct. I just want to write the > text. This is ESPECIALLY true of the news content, which IMHO > should just be a text datafile. No problem, I fully understand. My conversion of oldnews.phtml is geared more towards easier translation than easier editing because I've specifically excluded as many HTML tags and "markers" (like the 'o' at the start of each feature description) from the translatable text. oldnews.phtml isn't likely to need much editing, except adding existing blocks to the top and maybe siphoning really old content off the bottom. If news isn't to be translated, or at least not translated imminently after upload, then the original text format is fine. The script is still in place and can easily be modified to a new method. To make it available for translation, the file would need to be available to PHP - otherwise you end up with multiple translation files, as we had in the old news method - but all that this means is that news is uploaded as text/plain in a file named .phtml instead of .txt. PHP is sensible enough to wrap includes in the tags anyway. Then, if or when translation is needed, the strings can be marked up. The strings do need to be marked up _in the news file_ before the strings can be available to be translated. So a text/plain format can't be translated as-is, at least without creating a separate translation file. > (I'll note that my abhorrance of PHP isn't as pronounced as your > abhorrance to scheme -- but it's pretty close -- I'm at least willing > to LOOK at php code ;) ;-) All I can say to that is that php - especially as used in the revamped site - is, IMHO, easier to follow than all those unmatched parentheses in scheme! (and php is only on the website, it's not as critical as the scheme in gnucash.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpAXwYnZmG8Q.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: htdocs and the newest news.
On Thursday 09 February 2006 10:12 pm, Neil Williams wrote: > Now that 1.9.0 is out, I'm moving all news prior to 1.9.0 to oldnews.phtml > which is a new static page that fully supports translation. There's more to > do before it's ready for a commit but it should be all done at the weekend. Decided it was time to commit the structure now and work on the finer points later. :-) The demo site has been updated: http://gnucash.neil.williamsleesmill.me.uk/ but the en_GB translation is yet to be updated and lots of files remain that are now unused. For now, I've kept the donations page - personally I like the idea of being open about just how much we have in the kitty - but the rest is my attempt to aggregate the discussions about simplifying the site. I KNOW some pages are no longer HTML valid - I will fix each of those. But, as of now, what is the feeling on the simplified site? (I'm also going to create some scripts to automate various stages of the translation handling, improve the README and other bits.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp5XI0VypKnp.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
htdocs and the newest news.
Now that 1.9.0 is out, I'm moving all news prior to 1.9.0 to oldnews.phtml
which is a new static page that fully supports translation. There's more to
do before it's ready for a commit but it should be all done at the weekend.
I'm also building the ideas about simplifying the site into the next version
but structural changes like this aren't well suited to incremental commits so
I need to wait until each bit is working.
Question: Do we want the newest news translated?
The choice, so far, is:
1. Keep a simple text format and translate when it's time to move it to
oldnews (by converting to php).
2. Create a new news format where news files are actually PHP. This involves
something like:
Accouncement ...");
echo _("translatable content");
?>
(the announcement and time would need to be separate to make it simple to
display those in a banner.)
3. Or simply edit the index.phtml page when adding new news - inserting the
new text as PHP (to translate) or HTML (to not), and commit to svn.
I think it's probably more work than it's worth but it's relatively simple to
spot syntax errors as PHP is very noisy over such things. Others?
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpDHK2vyVLl2.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Help running Gnucash in my language
On Tuesday 07 February 2006 10:18 pm, Tor Harald Thorland wrote: > Hi, > > Unlike last time i'm now running english language on my install... > When i try to issue the following command i'll get an error and gnucash > is still in english.. > > What am I missing here? > > [EMAIL PROTECTED]:~$ LANG=no_NB.UTF-8 /opt/gnucash-1.9/bin/gnucash 1. There is no no_NB.po in svn. I think you meant nb.po, so you'd use nb r13141 Modified: gnucash/trunk/po/nb.po Log: Update Norwegian translation by Tor Harald Thorland 2. You need to export LANG before it becomes available: $ export LANG=nb $ /opt//gnucash/bin/gnucash The "unsupported" warning simply means that there is no translation for the language you specified. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpx5Yo2ajDND.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r13135 - gnucash/trunk/src/backend/postgres
On Monday 06 February 2006 9:33 pm, Chris Shoemaker wrote: > > Log: > > more inst.kvp_data changes to get Postgres backend to compile > > I apologize for the collateral damage here, Neil. Thanks for fixing > it. No problem. It's nothing I haven't done myself before now. > I've now sync'd my configure script between my devel machines so > that I'm bulding the postgres backend everywhere. And for much the same reason. :-) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpiJlriQrTp1.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
GConf and $(HOME) on OSX
A common source of problems on OSX could be incompletely configured environments - I've documented those that need to be set to build gnucash but the $(HOME) variable could catch out users as if it is not set, OSX loads the GConf druid every single time gnucash starts. Whereas g_get_home_dir is used later, this define could be a problem if the environment is incomplete: #define PATH_STRING1 "xml:readwrite:$(HOME)/.gconf\n" src/gnome-utils/druid-gconf-setup.c I can't see it's our fault if HOME isn't set but it might be wise to know in advance. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpV7afVzqcqq.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Fancy Invoice
When viewing the Fancy Invoice report, I get: Phone: (111) 222- Web: http://companysite.com I've found how to change the lines: Make all cheques payable to: and Direct all enquiries to: in the report options -> Display tab -> Extra Notes. Where is the report looking to find the Phone and website details? (Please don't tell me I have to edit the scheme!) :-) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpP4ma9IZ6vX.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: FC3 platform target
On Sunday 05 February 2006 6:59 pm, Neil Williams wrote: > On Sunday 05 February 2006 6:36 pm, Derek Atkins wrote: > > A good question. If it works with 2.4.13 then we can change the > > configure script. If it doesn't work with 2.4.13, well, I'm happy > > telling people they need an updated FC3. :) > > OK, I got passed with gtk+-2.0 == 2.4.13 (i.e. the change to configure makes it gtk+-2.0 >= 2.4.13) > by tweaking configure.in, but now > I've got the same thing with glib-2.0 - 2.4.8 required, 2.4.7 installed. > Proceeding with further testing . . . . Looks good so far, goffice has built OK. The changes are: goffice_reqs=" glib-2.0>= 2.4.7 gobject-2.0 >= 2.4.7 gmodule-2.0 >= 2.4.7 goffice_gtk_reqs=" gtk+-2.0>= 2.4.13 I guess we'd be unlucky to end up with gnucash finding a bug in glib-2.0 2.4.7 that was fixed in 2.4.8. It'll be a while before the rest of the build completes but as long as it looks OK once running, I'll commit the tweaks above. It should only be the GOffice code that would be affected - the rest has always been fine. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpsmfFLi0BSB.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: FC3 platform target
On Sunday 05 February 2006 6:36 pm, Derek Atkins wrote: > A good question. If it works with 2.4.13 then we can change the configure > script. If it doesn't work with 2.4.13, well, I'm happy telling people > they need an updated FC3. :) OK, I got passed with gtk+-2.0 == 2.4.13 by tweaking configure.in, but now I've got the same thing with glib-2.0 - 2.4.8 required, 2.4.7 installed. Proceeding with further testing . . . . -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpzYGxkryUoM.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
FC3 platform target
When we say we are targetting FC3 as target platform, does that mean a completely default FC3 or a regularly updated FC3? I can't build gnucash on my vanilla FC3, gtk+-2.0 is being reported as (slightly) too old. I have 2.4.13 and ./configure is complaining about not having 2.4.14. It then mentions libglade-2.0 >= 2.3.6 (I have 2.4.0), libgnomeprint-2.2 >= 2.8.0 (2.8.0) and libart-2.0 >= 2.3.11 (2.3.16). So it's just gtk that's actually causing it to fail. It appears that the goffice dependencies brought in gtk+2.0 > = 2.4.14: configure.in:936 goffice_gtk_reqs=" gtk+-2.0>= 2.4.14 I guess I'm the only one using a completely default FC3 as this change was made quite a while ago, back in r12096 http://svn.gnucash.org/trac/changeset/12096#file3 I don't tend to build gnucash on it often, I'm afraid, mainly because it's an incredibly underpowered machine (which is also why I haven't updated it from the point of install). I can test with 2.4.13 if it's worth it. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpMZXVJb14i5.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Translations and 1.9.0
On Sunday 05 February 2006 2:27 pm, you wrote: > On Sun, 2006-02-05 at 11:59 +0000, Neil Williams wrote: > > Are we having a string freeze before 1.9.0? If not (and there probably > > isn't time) can we _use_ 1.9.0 as a platform to get the other translators > > started on the work for gnucash 2.0.0 ? > > Have you read http://wiki.gnucash.org/wiki/Release_Schedule ? Oops, I forgot about that page - but yes, I do remember the draft proposal and schedule. > The proposed string-freeze date is March 13th, concomitant with 1.9.2. I'm not sure it's long enough still. > That's about 1.5 months before 2.0.0, assuming it still goes out early > in May. Doing a call for translations before the string freeze might > make sense as there are a lot of strings, and many if not most of them > won't change. I defer to cstim on translations-related stuff, but he > proposed this schedule. (Hence why I added this bit - which relates to the amount of time allowed for previous 1.8 releases that had much smaller % changes:) > > We do have a long list of translations for 1.8 but most of those are not > > up to date with 1.8.11 yet: > > http://www.iro.umontreal.ca/translation/registry.cgi?domain=gnucash > > > > (When I did some work on the en_GB translation, I was asked if it was > > possible to allow a *lot* more time for other translations than gnucash > > may have done historically.) Christian, can we adjust the translation schedule to allow for more time? Maybe an earlier release of the pot file, prior to a full string freeze. As long as translators are aware that a small proportion of the strings may change between now and the real string freeze, they can at least start working on the probable 1,000 fuzzy and 800 untranslated messages (which is roughly what I had with the en_GB translation) - about 25% of the entire po file. At this early stage, translators don't have to have a final build or string freeze, just an approximation of the scale of the task. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpkVQKGqU87q.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Translations and 1.9.0
Are we having a string freeze before 1.9.0? If not (and there probably isn't time) can we _use_ 1.9.0 as a platform to get the other translators started on the work for gnucash 2.0.0 ? There are a huge number of modified translatable strings going from 1.8 to 1.9.0 and even if some of those in 1.9.0 change again in 2.0.0, it's going to be MUCH easier to get the bulk of the new strings translated as early as possible. Only a handful have been done so far, so maybe we should send the 1.9.0 pot file to the GNU translation project asap (i.e. today) so that by the time 1.9.1 comes around, we have at least a majority of translations updated (even if not 100% updated) and by the time 2.0.0 is ready, there is no more than a tweak required to each translation. Otherwise, we could release 2.0.0 and be waiting months (or until 2.1, maybe 2.2) for translations to catch up. We do have a long list of translations for 1.8 but most of those are not up to date with 1.8.11 yet: http://www.iro.umontreal.ca/translation/registry.cgi?domain=gnucash (When I did some work on the en_GB translation, I was asked if it was possible to allow a *lot* more time for other translations than gnucash may have done historically.) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpHG0d9IeDHZ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash and Mac OS X support!!!
On Thursday 26 January 2006 12:16 pm, John W Palmer wrote: > I am using Mac OSX Tiger. I went through what I thought was a > successful installation of Gnucash using Fink, however when I run the > X11 terminal command: sw/bin/gnucash Start with a forward slash - i.e. look in the root directory, not the local one: /sw/bin/gnucash > I get "no such file or > directory". I can't seem to find where Fink installed the > application. /sw/bin/ > Any suggestions? Start every fink-related location with: / :-) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpqEnU1DF91a.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Fwd: [Gnucash-changes] r13084 - gnucash/trunk - Fix overall and ".log"-specific file-retention issues: Bug#329670 (++).]
On Saturday 04 February 2006 5:26 pm, Josh Sled wrote: > On Fri, 2006-02-03 at 22:40 +0000, Neil Williams wrote: > > I'll commit when I've got the docs improved for both this and Chris' > > original question about qoflog.c - probably tomorrow evening. (busy week) > > That's okay ... I'll fix it up as you describe Still need to revert the change in lib/libqof/qof/qofsession.c - I'll do that later. > along side some other > cleanups that I realized should be made. Thanks for the info about the > backend's semantics. No problem. I saw the patch - then realised that I'd missed something myself: it will force a GConf dependency on cashutil if it's shares gnc-backend-file. :-( Ooh-err. Wasn't planning on that, but ne'er mind, as long as depending on gconf is no more cumbersome than depending on libxml2 or libglib-2.0 then I can cross that particular bridge later - i.e. when I've actually got some time to develop on cashutil. :-) Adding libgconf2-4 appears to only add liborbit2 and libidl0 to the dependency list - on Debian anyway. As gnc-backend-file is to be replaced, it may not be too much of a problem. Besides, it may make sense for cashutil to read at least some gnucash preferences - I will promise NOT to change any preference data! I'm not that crazy! :-) -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpJwxER5oMcT.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [PATCH] date zero filling
On Saturday 04 February 2006 5:59 pm, Andreas Köhler wrote: > Hi, > > I do not care about design, like whether date printing should be in > libqof, right now. There may need to be some but probably not all that is currently in place - the gnc-date doxygen documentation says as much. The issue will be resolved during the life of libqof1 but probably not until after G2 because the decisions would require too much discussion here about where the functions should go and how to handle backwards-compatibility in programs like GnoTime that use these functions. Let's slate that discussion for part of the wider discussions on QOF once we have a G2 release. > This is rather a straight forward patch to make > the dates look like the strings in the Date/Time section of the > GnuCash preferences dialog. It adds zero filling to day and month in > dates and times for UK, CE and US Personally, as a gnucash user in the UK, I'd much rather *not* have zero padding on data entry or data display of UK date formats. There is no UK consensus on whether 04/02/06 is preferable to 4/2/6 or 4/2/06. It's a "problem" of the 21st century where single digit years can cause confusion. In my business life, all three of the above are perfectly acceptable, whether on casual notes or official documents. > . This may not catch every > appearance, but the register is much more appealing to me than > without it. Which makes the patch subjective - leading to a probable need for some kind of configuration option. David - is there a HIG issue here? > Feel free to apply any subset of it. I feel we should look at this as a possible config option and bounce the idea around on gnucash-user before assuming that zero padding is the "Right Thing To Do". -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpe0w4Y7vESk.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Fwd: [Gnucash-changes] r13084 - gnucash/trunk - Fix overall and ".log"-specific file-retention issues: Bug#329670 (++).]
On Friday 03 February 2006 10:36 pm, Josh Sled wrote: > On Fri, 2006-02-03 at 22:10 +0000, Neil Williams wrote: > > The bug is actually in the gnc-backend-file - it should initialise the > > "be" configuration itself in the call to : > > session->backend = (*(prov->backend_new))(); > > Repeating the call in the very next line should not be necessary. > > Why does the framework want backends to define interface methods that > the framework doesn't actually use? Data-centric design. Just like many other components of QofBackend, this is supported to provide an interface between the backend and the application. QOF mirrors the information from the backend (which cannot be linked against the application directly) to the application. It's also how the translated tooltip and description strings for each backend are made available to the application (the main reason for using a KvpFrame in the first place). http://www.data-freedom.org/explain.html#example Therefore any program that can exchange data with QOF can use whichever backend is suitable. Any other QOF compatible program can read the data, even if it doesn't use that backend normally. This increases platform independence, data accessibility and program flexibility. > What's the point of having a > backend declare its options to QOF? So that any application using QOF can query the configuration options for any QOF backend without having to be linked against the backend itself (which it can't be in any portable way). Remember that QOF backends can be installed independently of any application and vice-versa. gnucash relies on gnc-backend-file and QSF but future backends will not have such strict limits. Applications will need to be able to read the configuration of these backend modules at runtime and decide how to use the available options. e.g. I plan to use libgda to provide any QOF process with access to any of the databases supported by the gnome-db project. The various configuration options of these modules will be passed up to the application via the KvpFrame. The application will not be able to determine at compile time which precise backend module is to be used (other than sql://) as it will depend on which modules the user has installed. All the application will see is a standard QofBackend that can run queries in the backend, has a local cache of entities etc., and which has N configuration options that the application may or may not choose to use. The KvpFrame is sufficiently flexible for this because although the application can set any option, the backend only reads the options which it understands. The reverse is also true - the application can choose to present the user with only those options it understands, the others are left as defaults. QOF processes can only communicate with the backends via qof_session_* and the supported configuration options. Equally, QofBackends can only receive config options and a QofSession/QofQuery. QOF must act as the gopher for the config options, just as it does for the objects themselves. The application must declare it's objects to QOF so that the backend can operate; the backend must declare it's options, if any, to the application so that the application can use the options. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgprtDFvQBLiI.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Fwd: [Gnucash-changes] r13084 - gnucash/trunk - Fix overall and ".log"-specific file-retention issues: Bug#329670 (++).]
On Friday 03 February 2006 10:10 pm, Neil Williams wrote:
> On Friday 03 February 2006 2:32 am, Josh Sled wrote:
> > Hey Neil...
OK, after a second look:
This is what I think we should have instead of the change in qofsession.c:
(It's virtually identical, just that it only affects gnc-backend-file.)
Index: gnc-backend-file.c
===
--- gnc-backend-file.c (revision 13089)
+++ gnc-backend-file.c (working copy)
@@ -963,6 +963,13 @@
be = (QofBackend*) gnc_be;
qof_backend_init(be);
+/* Initialize be configuration. */
+{
+ KvpFrame *config;
+ config = qof_backend_get_config(be);
+ qof_backend_load_config(be, config);
+}
+
be->session_begin = file_session_begin;
be->session_end = file_session_end;
be->destroy_backend = file_destroy_backend;
Or we could simply not bother with the temporary frame and call the GConf
values directly, setting the data in the statics. Either way, a separate
KvpFrame is created when any function outside the backend actually ASKS for
the config options.
+/* Initialize be configuration. */
+{
+ file_retention_days = (int)gnc_gconf_get_float("general",
+ "retain_days", NULL);
+ file_compression = gnc_gconf_get_bool("general",
+"file_compression", NULL);
+}
+
Preferences?
The direct calls to GConf would appear adviseable.
gnc_backend_new is then called automatically by qofsession.c via
prov->backend_new()
> We can either setup the config KvpFrame directly in gnc_backend_new or
> simply set the existing statics to the GConf values when the backend is
> loaded. If we initialise the frame directly, we may not need the statics at
> all.
(Ignore that, we will need the statics - not that this is a problem.)
I'll commit when I've got the docs improved for both this and Chris' original
question about qoflog.c - probably tomorrow evening. (busy week)
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpr2swiiRL5L.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Fwd: [Gnucash-changes] r13084 - gnucash/trunk - Fix overall and ".log"-specific file-retention issues: Bug#329670 (++).]
On Friday 03 February 2006 2:32 am, Josh Sled wrote:
> Hey Neil...
It shouldn't affect other backends but I'm not sure it needs to be done in
qofsession.c - it causes duplication. Your patch has highlighted where the
QOF Doxygen docs need more clarification.
The bug is actually in the gnc-backend-file - it should initialise the "be"
configuration itself in the call to :
session->backend = (*(prov->backend_new))();
Repeating the call in the very next line should not be necessary.
> > Fix overall and ".log"-specific file-retention issues: Bug#329670 (++).
> > +session->backend = (*(prov->backend_new))();
Instead, put the initialising code in the function called by prov->backend_new
- in the case of gnc-backend-file, that's gnc_backend_new in
gnc_backend_file.c, src/backend/file.
I'll modify the documentation to make it clearer what QofBackendProvider
expects to happen in the backend_new routine. Namely, that a new backend
should fully setup it's own configuration before _backend_new returns.
> > + /* Initialize be configuration. */
> > +{
> > + KvpFrame *config;
> > + config = qof_backend_get_config(session->backend);
> > + qof_backend_load_config(session->backend, config); +
> >
> >}
The only real difference between the QSF and GNC backend new calls is that QSF
initialised it's internal context (params) which *explicitly* sets the be
config values. The GNC backend skipped that stage.
From only a cursory glance at the patch, I think the calls should not be in
qofsession.c but in src/backend/file/gnc-backend-file.c in the
gnc_backend_new function. Either directly or via some _init() function for
other gnc_backend_file parameters.
_backend_new is called every time a backend is created so it would be called
on the line above where your patch calls it:
session->backend = (*(prov->backend_new))();
(without requiring changes in qofsession.c)
(Note that it's not that qofsession.c can't be changed, just that the docs
need to be clarified so that code is not run twice.)
> I know you'd rather be notified before commits to qof, but I figured
> it'd be easier to see the change in context; I'm in no way married to
> this particular change, but this does seem to work ... I'm curious as to
> your take on what the right solution is...
I suspect we should alter how the defaults are initialised in the
gnc-backend-file because other backends do not require this step and I'll
clarify the docs.
> Trying to debug Bug#329670, I noticed that the .xac and .log
> file-cleanup code wasn't being invoked appropriately since the
> file_retention_days wasn't being set.
OK, I'll follow that up. I've noted that your change is primarily to set
whatever value is retrieved from gconf as the on-load default instead of
using static defaults.
> In fact, the gnc-file-backend's
> get- and load-config code was never actually being invoked by either QOF
> or GnuCash...
Yes, it relied on the static defaults of zero and FALSE respectively. Your
GConf solution is far better.
> It seems logical that QOF should configure a backend's options after
> loading it,
It's even better if it is done during the load itself. i.e. there should be no
point at which a backend is available but not configured. I'll ensure the
docs make this clear.
> and as such the change I made here seems right. Is there a
> better alternative?
Yes - a backend specific change and more detailed documentation in doxygen.
Thanks for spotting this, Josh. I'll revert the parts of r13084 that relate to
qofsession.c and implement them in gnc-backend-file.c
This is the vital line in your addition:
+ option->value = GINT_TO_POINTER((int)gnc_gconf_get_float("general",
"retain_days", NULL));
If the effect of this line is replicated in gnc_backend_new (with the line for
the second option), all the problems will be resolved without changes to
qofsession.c because gnc_backend_new is already called by qofsession in the
line above your change.
We can either setup the config KvpFrame directly in gnc_backend_new or simply
set the existing statics to the GConf values when the backend is loaded. If
we initialise the frame directly, we may not need the statics at all.
How does that sound?
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpDQGDnSJo7V.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] QOF Policy
On Monday 30 January 2006 8:02 pm, Neil Williams wrote: > On Monday 30 January 2006 5:15 pm, Chris Shoemaker wrote: > > Developers, > > Here's a proposal. My understanding is that this proposal for a > > change of policy will not take effect until it is accepted. OK, let me just explain a bit about this: This proposal is framed as an "either or" choice when what is needed is a sharing approach. I made a request for this which backfired - the infamous QOF external discussions - but the thrust of that discussion has been lost. All I ever wanted was a little consideration that if I've announced an imminent release it is sensible to let me know about pending changes that are out of tree; if someone is working on a problem in libqof, let me know and just check if there are constraints that would break other programs. All done in an atmosphere of sharing, cooperation, goodwill and for the general improvement of all related code. I do value the contributions of all gnucash developers and their assistance - such assistance has helped me see how to fix _global just today - I don't want to lose all that unless absolutely essential to my sanity. :-) I just want to get back to G2, that's all. All this is just an unnecessary distraction. Let's decide once G2 is out. I'll take any burden from postponing the decision until then. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpjogKYwFosJ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [RFC] QOF Policy
On Monday 30 January 2006 5:15 pm, Chris Shoemaker wrote: > Developers, > Here's a proposal. My understanding is that this proposal for a > change of policy will not take effect until it is accepted. I propose that no change is made prior to the release of GnuCash 2.0.0. Then we can revisit this whole morass. > Do you agree to this change in policy? Not now. > If not, might you change your mind at some future point it time? Yes. > (2) Listing of files in currently in qof: You missed the QSF backend. >qofquery-deserial.c >qofquery-deserial.h No longer built either by libqof1 or gnucash. > qofquery-serialize.c > qofquery-serialize.h ditto. > qofsql.c > qofsql.h ditto. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpCWtuBl09lK.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Finishing the neverending QOF flamewar
out
extraneous code. Every part of QOF is used by these external programs.
> That's a poor way to build a library. I think
> more than 50% of what's in libqof doesn't belong. I also thing that
> the querying infrastructure and the serialization probably don't
> belong together.
By serialisation do you mean QSF? Other serialisation code within QOF is no
longer built either in gnucash or libqof1.
> 1) Gnucash developers can still develop QOF.
>
> 2) Neil's in charge of copying code from svn to where ever he releases
> libraries from.
>
> 3) If we make non-backward compatible changes to QOF, Neil would have
> to reflect that in his library version numbers.
>
> One thing that I don't think was hammered out was should Gnucash 2.0
> use external QOF. Neil has asserted that it should.
I'd like it to do so and I will do what I can to allow it to do so but it
isn't compulsory. It is, however, eminently sensible.
> 1) We shouldn't release 2.0 with external QOF unless we've tested it
> extensively with the version we're depending on.
Any version of libqof1 will be compatible. There are bug fixes in 0.6.1 and
0.6.2 which mean gnucash will function better with those versions, hence I
bumped the configure version to 0.6.2. You cannot fix an application to a
specific version of a library because it breaks all the packaging systems. I
want gnucash to be able to release, as far as bugs allow, independently of
libqof1 and vice-versa.
> 2) We can't test with external QOF because we're frequently making
> changes to QOF that aren't backward-compatible.
Frequently? Two changes since this whole wrangle started?
If you had taken head of my notice of imminent release of QOF 0.6.1 then we
could be using libqof1 0.6.1 NOW, for this upcoming gnucash release.
All I needed was a little email from you saying "I'm working on something that
is in lib/libqof and hope to commit soon." then I could have delayed the
release by a matter of a few days and included your CACHE_REMOVE change. No
problems with that, none whatsoever.
> Note that this _doesn't_ preclude sharing QOF code with other
> projects, even in the form of an external library. It's just a
> question of whether or not _GnuCash_ should depend on an external
> library for QOF functionality.
If you ever want to use libqof1 externally there does remain some need to
coordinate with external qof development and consider the needs of external
programs.
> It might be because they don't approve of my assertive tone. It's
> probably because they'd rather write code than argue. So would I.
And I. PLEASE can we stop this nonsense until AFTER G2. How many times do I
have to ask! Stop wasting my time!
> Neil's words say that I'm free to develop QOF, but his actions are
> that 100% compatible improvements to the API are reverted.
Your else{} block is not compatible. It does not allow modules to be ignored
for selective logging.
> I think it would be appropriate to have some _public_ discussion on
> this point.
Just not NOW please!
> I'll post a question in a new thread to attempt to leave
> some of the baggage of this thread behind.
It would have been better for everyone if you would simply drop the entire
issue and let everyone else actually do the IMPORTANT things in life, like
fix bugs in G2.
Drop this!
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpt14CCyP9Yn.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Finishing the neverending QOF flamewar
On Monday 30 January 2006 6:01 am, Benoit Grégoire wrote: (I agree with all the points Benoit raised.) > There should probably be a discussion of each one individually to reach a > consensus, and settle with some sort of vote if there if one isn't reached. If I can just receive a little consideration for my admittedly crazy decision to implement option 4, we can have this discussion in a measured and relaxed manner once gnucash2.0 is out. I will try to keep the two in sync and to keep both ends happy but this whole issue needs to be put to bed until the other developers have time to get involved. I know it's wasted several days of my time that could have been spent investigating horrid little bugs in the Business objects in G2. > We can then move back to real technical issues in a productive climate. Yes please. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpU6avsdbUai.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: htdocs and gettext
On Monday 23 January 2006 10:57 pm, Derek Atkins wrote: > Neil Williams <[EMAIL PROTECTED]> writes: > > To protect the .svn directories below www/, this snippet should be added > > to the virtual host config: > > > > Order Deny,Allow > > deny from all > > > > Why not just use a .htaccess for this? Sorry for the delay, I did try .htaccess but isn't supported from .htaccess, only which, unfortunately, I couldn't get to work with this type of wildcard. If someone has a method using .htaccess, I'll use it. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpAzf7gXTYhg.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: More build breakages due to incomplete uninstalls
On Monday 30 January 2006 5:34 am, Ganesan Rajagopal wrote: > > :-) > > Looks like you're correct. I found a build problem today because of a > missing symbol that's no longer in the source tree. It turned out that the > linker is picking up older installed libraries. Once I cleaned up my > installed tree everything is fine. The patches I sent are not > required. Sorry for the false alarm. Aha! OK, one bit of advice for everyone building regularly from the svn tree - 1. make uninstall is often incomplete on rapidly changing trees. 2. make will try to use installed libraries and if svn update changes any part of those (which it will), they need to be removed, however you cannot then rely on make uninstall to do this for you because the tree has changed. 3. If you use make uninstall, this relies on you having completed a previous ./autogen and configure. 4. If you've done 'svn update' prior to 'make uninstall', then make will re-run autogen and configure and therefore potentially miss some modified installed code. Therefore, my advice is: If you use 'make uninstall', follow it up with 'rm -rf '. Or just use 'rm -rf '. I guess there would be a way of detecting whether files still remain below the path but I'm not convinced they would be worth either saving or selectively deleting. The unfortunate result is that you must then complete a full make install. The breakages that result from NOT deleting the installation directory and all files beneath it are not due to Debian libtool or anything else, they are simply due to you having incompatible code lying around. Sorry. :-( -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpum4K2Rpp9X.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Strange OSX problems
When running make check (with the guile16-build preface) I can't get the gnc_modules to test correctly. It appears that OSX fails to look in the .libs/ directory in each location. ** (process:26524): WARNING **: Failed to dlopen() '../../../src/gnc-module/test/mod-bar/libgncmodbar.la': dlcompat: file "../../../src/gnc-module/test/mod-bar/libgncmodbar.0.dylib" not found That'd be because it's actually: "../../../src/gnc-module/test/mod-bar/.libs/libgncmodbar.0.dylib" :-( and again and again: ** (process:26524): WARNING **: Failed to dlopen() '../../../src/gnc-module/test/mod-baz/libgncmodbaz.la': dlcompat: file "../../../src/gnc-module/test/mod-baz/libgncmodbaz.0.dylib" not found etc. test-dynload.c: testing dynamic linking of libgncmodule ... OK PASS: test-dynload test-scm-dynload: testing dynamic-link of libgncmodule from Scheme. PASS: test-scm-dynload test-scm-init: testing Scheme-only module system init. ERROR: Unbound variable: names FAIL: test-scm-init 7 of 12 tests failed make[7]: *** [check-TESTS] Error 1 Also on OSX (only): GConf setup dialog loads every time gnucash2 is started, appears to work OK but either it's not writing the settings or not finding them next time. No reports can be generated from the Business data - I get Report Error with no more information. There are other problems in the Business module but those are replicated on my Debian system too. I'm continuing to test - especially as there have been recent changes in that section. I've documented some other stuff in doc/build-osx.txt relating to automake1.4 conflicts. It seems that other applications in Fink require automake1.4 and fink replaces automake1.9 with 1.4 every time one of these applications is upgraded (because each is compiled from source using hints from package data) but then does not reinstate 1.9. This can probably be sorted for the packaged releases to OSX via Fink because the package can expressly conflict with automake1.4. When compiling from svn, it's yet another addition to the script to run 'sudo fink install automake1.9' before anything else can happen. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpgEuzhgcVUZ.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r12999 - gnucash/trunk/lib/libqof/qof - Re-enable logging for GnuCash modules that haven't explicitly set their
On Sunday 29 January 2006 2:07 am, Chris Shoemaker wrote:
> On Sun, Jan 29, 2006 at 12:16:23AM +0000, Neil Williams wrote:
> > If the module runs it's own init it can read the existing config for that
> > value and set that. This is a process value, not a library value. It has
> > no business being a static in the qof library.
>
> Um, you _do_ realize that libraries are mapped into the process's
> memory space, right?
Yes, but that's no reason to have a default value in the library that enables
logging where the module has NOT explicitly done so.
> > Modules that are not meant to be logged in user-land in
> > pilot-qof are now logged when the output is completely meaningless to a
> > user.
>
> Complete B.S. Either:
No - modules that have not explicitly set their log level are NOT to be
logged, anyway, anyhow. Set the explicit log level and THEN work on them.
> A) you don't realize that because the variable is initialized to zero,
> NOT A SINGLE message will get logged that wasn't logged before in ANY
> program ANYWHERE, _or_
Wrong. Your modification to qof_log_check means that even if a module is NOT
listed in the hashtable, the check returns TRUE even if loglevel is zero.
That's plain wrong. Only modules in the hashtable should be logged. There can
be no else{} statement. Zero is not "do not log", zero is GNC_LOG_FATAL which
still results in some logging.
Your modification means that qof_log_check returns true every time for
GNC_LOG_FATAL and that simply isn't acceptable.
If log_string = (gchar*)g_hash_table_lookup(log_table, log_module);
returns non-NULL, then we can test if the loglevel is sufficient. When it
returns NULL, log_check MUST return FALSE.
I cannot accept this modification:
/* if log_module not found, use default. */
it is simply wrong. There can be no default in the library, only in the
application, if you want it.
> B) you _do_ realize this and you're just making a big stink because
> you don't want people modifying qof.
Not true. I didn't appreciate your last change that happened days after the
release, despite me highlighting the imminent release here a few days before.
I have nothing against modification of qof - those changes will be in the
next release - I DO have a problem with patches that override the API for the
sole benefit of one program.
> ?!?! Fact: Logging for all testing functions now works with my patch.
test code can simply call qof_log_set_level for whichever modules it needs -
the macros can be copied if you'd rather not include the remote header file.
> Fact: Before my patch, almost none of the logging in test functions
> worked. We _are_ talking about the 'make check' tests, right?
You tell me, that's the first you've mentioned about WHICH modules you wanted
to actually enable.
> B.S. Unless you use negative loglevels, this is mathematically
> impossible.
Not true. I'd prefer if a log level of zero HAD been defined as a no-op but it
isn't and until libqof2 I can't change that. So the way to prevent logging of
certain "developer-only" or "testing" modules is simply to NOT have that
module name in the hash table. You've broken that. If your global variable is
allowed to remain, then every module is log enabled whether or not it is
listed in the hashtable - I simply cannot accept that.
It's fine for gnucash to have the attitude that everything should be logged
but other applications do NOT require such treatment and only ever want to
log when explicitly requested to do so by the user.
To achieve this, the code must include the ENTER(" ") etc. macros and have a
QofLogModule but NOT have a log level explicitly set, i.e. no entry in the
hashtable. Your patch enables logging for precisely these modules when they
should be silent.
It's fine that --debug enables logging for some modules and not for others -
that is the API and - despite what you may think - has always been the API
because the old enum was gnucash-specific and other applications HAD to use
their own methods.
> Just drop the charade and get back to the _real_ reason
> you're complaining: You forked QOF
I did not fork QOF, QOF has not been forked. It's a spin-out, not a fork.
> , and the original maintainers won't
> stop developing (and fixing) it like you told 'em to.
Not true. Please see a world beyond the narrow confines of gnucash where
modules are logged only if explicitly requested and where the "log
everything" mentality is simply unacceptable.
This is especially true in embedded systems where the logs should only ever be
created when absolutely necessary due to the tiny resource limits.
You may think diskspace is cheap and infinite but QOF has to be able to t
Re: [Gnucash-changes] r12999 - gnucash/trunk/lib/libqof/qof - Re-enable logging for GnuCash modules that haven't explicitly set their
On Saturday 28 January 2006 11:31 pm, Chris Shoemaker wrote: > *sigh* And _how_ exactly is the global loglevel supposed to effect the > loaded module? Am I supposed to re-call qof_log_set_level_global > after every time that new code might have been loaded? If the module runs it's own init it can read the existing config for that value and set that. This is a process value, not a library value. It has no business being a static in the qof library. It is part of the gnucash session context (which is woefully incomplete so far but will have to be completed before libqof2 when current_session is removed). pilot-qof does this. Works fine. > > If you replicate the intentions of that list in gnucash (only), then they > > will continue to work. What QOF cannot do is assume that such a list > > exists. > > Umm. There is no list. There is no such assumption. Precisely - there was and it was removed because assumptions are bad ideas. The intentions behind the list now need to be fully expanded within gnucash, not libqof. > It's easy for you to break the API I have not broken the API. > and then say, "well, it _would_ > work if you'd only do such-and-such", (which it _wouldn't_ by the > way Yes it will. It does. Modules that are not meant to be logged in user-land in pilot-qof are now logged when the output is completely meaningless to a user. These modules only have log macros for my benefit and for others packaging the program. > > > There is _no_ > > > other way to globally control the logging level in the presence of > > > dynamically loaded code. > > > > Read the code again. Dynamically loaded code (like a module) can > > initialise it's own logging - you don't need global control except to > > control the AMOUNT of logging, not the LIST of log modules. > > Why do you think every introduction of a logging module comes with an init? So init the log and control the amount of logging by that module later. Or if global has already been called, reference your context values (outside libqof) and set the level in the new init. > > You can even call qof_log_set_level from within a test function - you > > lose that ability if the list is hardcoded OR assumed. > > WHAT ARE YOU TALKING ABOUT?!?! Eeeets BARROOOKE! I'm FIXED it. You broke it, not me. > Show me ONE thing that my change broke - just one. Enabling logging for modules that have not explicitly initialised their own logging. It breaks pilot-qof and it breaks the API which specifically states that ONLY modules that initialise their own log levels will ever be logged. > > OK - then help me see how it should be expressed in the docs and REVERT > > your broken patch, please. > > I think you misunderstand. Please try again. This is getting nowhere. The patch is broken, please revert it. If there is any misunderstanding it is in the premise behind your patch. There is nothing in lib/libqof to fix to enable logging of these gnucash modules - the solution lies ONLY within the code below src/ -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpuv69MpznLm.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: www.gnucash.org simplification proposal
On Thursday 26 January 2006 10:38 pm, Josh Sled wrote: > On Thu, 2006-01-26 at 15:32 -0500, Chris Shoemaker wrote: > > One thing that might be missing is 'About', but maybe that can be on > > the home page. > > Yeah, or replace "Home" with "About", which is somewhat more meaningful > than "Home" anyways. > > > Also, I think I'd rather see the NEWS history pushed > > off onto it's own page -- leaving the home page relatively clean, or > > maybe with just the most recent announcements. That makes sense - there's little point having the old news dynamic, except when new news (!) is demoted to old. > On a related note, what about replacing the 3 paragraphs we have on the > front page with: > > "GnuCash is personal and small-business financial-accounting > software, freely licensed under the GNU GPL and available > for GNU/Linux, *BSD, Solaris and Mac OSX." Sounds OK. (Personally, I dislike the potential for confusion when the page title uses Open Source and the body talks about the GPL and free software so a new title would be useful too - "GnuCash - free software accounting" ?) > Maybe followed by brief hilights of the major features (a-la > http://www.gnome.org/projects/evolution/)? > >* Double-Entry Accounting >* Stock/Bond/Mutual Fund Accounts >* Small-Business Accounting > * Customers, Vendors, Jobs, Invoices, A/P, A/R >* QIF/OFX/HBCI Import, Transaction Matching >* Reports, Graphs >* Scheduled Transactions >* Budgeting > > (probably split across two columns ...) Followed by the News/Updates. If you use two columns, PLEASE do so using CSS not tables. This list is not tabular data. > I think between the "what we are" sentence, the features hilights and > news, we have a good About page as the primary thing people see when > they hit the site. Please don't feel that I want to be the sole developer committing to htdocs! :-) As long as the site remains HTML 4.01 Strict compliant and it can still be translated, I'm happy to just be in the background tweaking the structure and such. I was going to bring sizing.phtml up to strict validity but if it's being ditched then I'll just continue converting more strings to gettext. If anyone wants to help with that, feel free. I did just jump in but then I'd been waiting to implement the structure used by mail-search since before I had cvs write access to HEAD! I concentrated on the structure and deliberately left the content for later. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpGI1i2Lue1K.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [Gnucash-changes] r12999 - gnucash/trunk/lib/libqof/qof - Re-enable logging for GnuCash modules that haven't explicitly set their
modules. You can call qof_log_set_level anywhere you like. Feel free to move all those to more relevant places if you need to do so. The shorthand was a temporary measure that was useful during the transition. You can even call qof_log_set_level from within a test function - you lose that ability if the list is hardcoded OR assumed. > If anything should be reverted it's the commit that originally broke > the logging. If you want to try to drastically change the way > gnucash's logging system works I suggest that you make your proposal > to gnucash-devel, build some consensus, and respond to constructive > criticism. I am responding - but the problem is that you're stuck on this false assumption that will bite. > Your breaking things by making major changes with no approval is bad > enough. Complaining when people fix things is BAD FORM. You haven't fixed it, you've broken it. It was fine before your patch - any lack of logging in gnucash was down to: a) my lack of time to revisit the shorthand list b) your misunderstanding of the API, without the assumption. > > If there are issues you want clarified in the docs, I'll gladly do that, > > but this patch is just plain wrong. > > The docs do need to be updated - to reflect this change. OK - then help me see how it should be expressed in the docs and REVERT your broken patch, please. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpbFGig4hrEM.pgp Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
