Re: [GNC-dev] msg "Open" in gnucash/gnome/dialog-lot-viewer.c:829

[Christian Stimming]

Ok, I appreciate your intention to re-use the existing string. In that case my 
statement is different: As I wondered why the string "Open" was marked as fuzzy 
in the PO files, I checked its usage and found this severe ambiguity here. 
Could you extend your usage of that string with a context marker please? 
Otherwise the translations will all get it wrong in either this or the other 
meaning.

And different to Frank's proposal I would rather suggest to add a context with 
an explanation from the functional domain, not just "adjective", rather 
something like "Status of a not-yet-closed lot" or similar.

Thanks!
Christian 

Am 12. September 2022 06:20:13 MESZ schrieb Christopher Lam 
:
>My change was merely to reuse an existing string in the lot viewer, for its
>exact same purpose.
>
>Perhaps the original committer [1] needs to be informed?
>
>[1]
>https://github.com/Gnucash/gnucash/commit/0b37c913f053f86196f6cd6689fcaba2e08b387e
>
>On Mon, 12 Sept 2022 at 04:53, Frank H. Ellenberger <
>frank.h.ellenber...@gmail.com> wrote:
>
>> Christian,
>>
>> idid you check all other occurrences. If yes, I would like to add the
>> MsgContext "Adjective" to dialog-lot-viewer.c and run a msgmerge.
>>
>> Regards
>> Frank
>>
>> Am 11.09.22 um 22:05 schrieb Christian Stimming:
>> > Hi Christopher,
>> >
>> > in gnucash/gnome/dialog-lot-viewer.c you recently added the function
>> > lot_get_closing_date() which might return the translated string "Open"
>> if there is no such
>> > closing date because the lot is still in the status "opened".
>> >
>> > There's an issue with this translation string: It is super-ambiguous. In
>> most contexts, a
>> > translation string "Open" is used in the sense "to open [something]" but
>> the string is just
>> > "Open" ie the verb. Contrary to this, in this particular place the
>> string should mean
>> > "[something is in state] Open" but the string is also just "Open", ie
>> the adjective. This won't
>> > work for translators, because in almost all other languages, the verb
>> and the adjective will be
>> > two vastly different strings.
>> >
>> > The solution is to use the C_( ) macro instead of _( ) which is where
>> the additional context
>> > string is used.
>> > https://www.gnu.org/software/gettext/manual/html_node/Contexts.html[1]
>> > https://wiki.gnucash.org/wiki/Translation#Message_Context[2]
>> >
>> > This way, the string "Open" with no context should be used only when
>> this is the verb
>> > meaning ie "to open", but not for the status as it is in this file here.
>> >
>> > Thanks a lot!
>> >
>> > Regards,
>> > Christian
>> >
>> > 
>> > [1] https://www.gnu.org/software/gettext/manual/html_node/Contexts.html
>> > [2] https://wiki.gnucash.org/wiki/Translation#Message_Context
>> > ___
>> > gnucash-devel mailing list
>> > gnucash-devel@gnucash.org
>> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] msg "Open" in gnucash/gnome/dialog-lot-viewer.c:829

[Christian Stimming]

Hi Christopher,

in gnucash/gnome/dialog-lot-viewer.c you recently added the function 
lot_get_closing_date() which might return the translated string "Open" if there 
is no such 
closing date because the lot is still in the status "opened".

There's an issue with this translation string: It is super-ambiguous. In most 
contexts, a 
translation string "Open" is used in the sense "to open [something]" but the 
string is just 
"Open" ie the verb. Contrary to this, in this particular place the string 
should mean 
"[something is in state] Open" but the string is also just "Open", ie the 
adjective. This won't 
work for translators, because in almost all other languages, the verb and the 
adjective will be 
two vastly different strings.

The solution is to use the C_( ) macro instead of _( ) which is where the 
additional context 
string is used. 
https://www.gnu.org/software/gettext/manual/html_node/Contexts.html[1] 
https://wiki.gnucash.org/wiki/Translation#Message_Context[2] 

This way, the string "Open" with no context should be used only when this is 
the verb 
meaning ie "to open", but not for the status as it is in this file here.

Thanks a lot!

Regards,
Christian


[1] https://www.gnu.org/software/gettext/manual/html_node/Contexts.html
[2] https://wiki.gnucash.org/wiki/Translation#Message_Context
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Report with Fiscal Year

[Christian Stimming]

Am 6. September 2021 16:46:25 MESZ schrieb john :
>https://wiki.gnucash.org/wiki/Roadmap#Reports 
><https://wiki.gnucash.org/wiki/Roadmap#Reports> Christian Stimming wrote the 
>last paragraph about replacing Scheme in 2011.
>

Oh, did I? The Internet never forgets...

Anyone, feel free to edit that paragraph into today's point of view, probably 
replacing the mention of python by what seems more suitable today. Have fun 
everyone!

Regards, Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Online ID matching for OFX import

[Christian Stimming]

Am Sonntag, 5. Januar 2020, 22:39:58 CET schrieb Mike Alexander:
> I agree that running the search twice is probably ok.  However, John
> raises another point which seems relevant.  What if there is more than
> one partial match?  Right now it returns the first one.  It would seem
> better to punt if there is no full match and more than one partial
> match.

Oh well. I don't think we should complicate this a lot more. If there is a 
wrong match, currently we don't have any GUI possibility for the user to fix 
this anyway. We point the user to editing the XML file, unfortunately.

Hence, the case with multiple matches, either by complete match or by partial, 
is unsolved anyway currently. Just take the first and that's it... The real 
solution would be to have a dialog window showing all online_ids, with 
sorting, searching, editing and so on. As long as nobody volunteers to add 
such a thing, just use the first match.

Regards,

Christian


> 
>Mike
> 
> On 5 Jan 2020, at 15:47, Christian Stimming wrote:
> > I think two passes is fine. We have a O(n) complexity anyway, and
> > O(2n) is not
> > worse than that. So I think running one pass looking for exact match,
> > then (if
> > none was found) looking for the partial match, is fine overall.
> > 
> > Caching partial matches in an extra list with element creation and
> > such IMHO
> > introduces a whole lot of extra complexity that isn't really needed.
> > Just
> > running the search twice should be fine.




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Enabling github branch protection rules? Re: [Gnucash/gnucash] po/de.po: fix translation bug (#627)

[Christian Stimming]

Am Freitag, 3. Januar 2020, 23:19:13 CET schrieb John Ralls:
> Christian,
> 
> Well, it does disable the merge button. "applies to administrators" has to
> be checked too for it to apply to you, me, and Geert. Unfortunately it also
> applies to pushes from code:

Oh well. Ok, thanks for testing. I was just wondering whether all these fancy 
new workflow enforcements would allow us to enforce our particular workflow, 
but apparently this is not supported. After this discussion I am now fully 
aware of not using the github website merge button again, so I think we can 
safely leave things as it is. Thanks!

Regards,
Christian

> 
> Counting objects: 16, done.
> Delta compression using up to 16 threads.
> Compressing objects: 100% (16/16), done.
> Writing objects: 100% (16/16), 1.58 KiB | 0 bytes/s, done.
> Total 16 (delta 12), reused 0 (delta 0)
> remote: *** Mirror changes to origin (usually github)...
> remote: remote: error: GH006: Protected branch update failed for
> refs/heads/maint. remote: remote: error: At least 2 approving reviews are
> required by reviewers with write access. remote: To
> ssh://github.com/Gnucash/gnucash.git
> remote:d409d009f..b5fdcfcb5  origin/maint -> origin/maint
> remote:  ! [remote rejected] maint -> maint (protected branch hook
> declined) remote: error: failed to push some refs to
> 'ssh://g...@github.com/Gnucash/gnucash.git' To
> ssh://code.gnucash.org/gnucash
>b5fdcfc..c9998a8  maint -> maint
> 
> That could probably be worked around by making code a maintainer and
> reducing your privs to regular developer. Geert and I would still get the
> merge button but we know better than to use it.
> 
> Regards,
> John Ralls
> 
> > On Jan 3, 2020, at 12:57 PM, Christian Stimming 
> > wrote:
> > 
> > John,
> > 
> > thanks a lot for testing. Well, that's unfortunate. However, maybe some of
> > the other rules would help us to avoid this better?
> > https://github.com/Gnucash/gnucash/settings/branch_protection_rules/new
> > How about activating "Require pull request reviews before merging" with
> > maybe "2"? Again, I'm not sure whether code-gnucash-user can still push
> > the commits. Could you give it a try? Thanks a lot.
> > 
> > Regards,
> > Christian
> > 
> > Am Freitag, 3. Januar 2020, 00:15:02 CET schrieb John Ralls:
> >> Christian,
> >> 
> >> Just tried it as a test (the user id is code-gnucash-user). It doesn't
> >> prevent merging from the web page.
> >> 
> >> Regards,
> >> John Ralls
> >> 
> >>> On Jan 2, 2020, at 1:11 PM, Christian Stimming 
> >>> wrote:
> >>> 
> >>> Dear developers,
> >>> 
> >>> yesterday I accidentally used the web interface of github to merge a
> >>> pull
> >>> request, but we don't want this, because the merge (or any other commit)
> >>> on
> >>> github is going to be overwritten by the next push from
> >>> code.gnucash.org.
> >>> 
> >>> I was wondering whether we could enable the github "Protect matching
> >>> branches" rules
> >>> https://github.com/Gnucash/gnucash/settings/branch_protection_rules/new
> >>> There's a rule "Restrict who can push to matching branches", which we
> >>> could
> >>> restrict to the user that pushes from code.gnucash.org. This should
> >>> prevent
> >>> any such accidental merges from github's web interface, shouldn't it?
> >>> However, this needs to be enabled by somebody who immediately can check
> >>> that the push from code still works. Anybody there care to take a look?
> >>> Thanks a lot!
> >>> 
> >>> Regards,
> >>> 
> >>> Christian
> >>> 
> >>> Am Donnerstag, 2. Januar 2020, 11:42:12 CET schrieb Frank H. 
Ellenberger:
> >>>> Never use githubs webinterface for merging for any gnucash project!
> >>>> Because code.gnucash.org is canonical, the merge got overwritten by the
> >>>> next push.
> >>> 
> >>> ___
> >>> gnucash-devel mailing list
> >>> gnucash-devel@gnucash.org
> >>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Online ID matching for OFX import

[Christian Stimming]

John,

I think two passes is fine. We have a O(n) complexity anyway, and O(2n) is not 
worse than that. So I think running one pass looking for exact match, then (if 
none was found) looking for the partial match, is fine overall.

Caching partial matches in an extra list with element creation and such IMHO 
introduces a whole lot of extra complexity that isn't really needed. Just 
running the search twice should be fine.

Regards,
Christian

Am Sonntag, 5. Januar 2020, 21:09:57 CET schrieb John Ralls:
> Mike,
> 
> Two passes would be slow for users with large account trees. Collecting all
> of the partial matches would require a full traversal every time and that
> wouldn't be much better--and worse in the common case where there's only
> one match.
> 
> How about returning immediately on an exact match and stuffing partial
> matches onto a list and carrying on until there's an exact match? If
> there's no exact match and only one item in the list of partials, return
> that, otherwise signal an error somehow.
> 
> Too bad there's no reliable way to traverse just the asset and liability
> accounts.
> 
> Regards,
> John Ralls
> 
> > On Jan 5, 2020, at 11:20 AM, Mike Alexander  wrote:
> > 
> > Ok, how about changing it to try an exact match first and only try the
> > partial match if that fails. If that makes sense I'll fix it tonight. One
> > question I have is whether this will do the right thing if I add a new
> > security so the parent account exists but the security account doesn't. I
> > think it will since the accounts commodity will be wrong.
> > 
> > Mike
> > 
> > On Sun, Jan 5, 2020, 10:01 AM John Ralls  wrote:
> > > On Jan 5, 2020, at 12:40 AM, Mike Alexander  wrote:
> > > 
> > > When I tried to do my monthly import of an OFX file containing my
> > > TIAA/CREF transactions it failed miserably.  I tracked it down to
> > > commit 7853f5a2 which changed the matching of online IDs for accounts
> > > to only match an initial substring of the required ID.  My accounts are
> > > structured with a parent account in USD corresponding to a TIAA/CREF
> > > account and a sub-account under it for each asset in that account.  The
> > > online ID for the parent account is something like "TIAA-CREF.ORG
> > > C8304GY8 RAM001 101011".  The online ID for a sub-account storing an
> > > asset is created by appending the asset ID to the parent accounts
> > > online ID giving something like "TIAA-CREF.ORG C8304GY8 RAM001
> > > 101011878094101".  gnc_import_select_account does a linear search of
> > > all accounts in no particular order looking for one where the online ID
> > > matches in initial substring of the ID it wants.  If it finds the
> > > parent account before the sub account it returns that and the process
> > > fails since it's the wrong currency.
>  I don't understand enough about the problem that commit is fixing to know
> how to fix it without breaking things.
> > Mike,
> > 
> > Rats.
> > 
> > The problem the commit was trying to fix is that AQB 5.99 for FinTS uses a
> > raw SWIFT account code that for many German banks includes extra
> > characters--often a currency code--on the end. Some banks also pad the
> > code with leading zeros and a subsequent commit attempts to resolve that.
> > This is https://bugs.gnucash.org/show_bug.cgi?id=797432.
> > 
> > Regards,
> > John Ralls
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] gnucash git: please as little merge commit as possible

[Christian Stimming]

Dear Daniel,

thanks a lot for your contributions to gnucash.

Concerning the git commits I have a small wish: Could you try to send as 
little merge commits as possible in your pull requests? In particular, your 
recent test_gnc_setlocale patch branch contains a merge commit merging 
upstream/maint. This shouldn't go into the gnucash git. Instead, please rebase 
your contribution branch on top of most recent master, so that your change is 
only exactly one commit (or multiple linear commits for complex contributions) 
but does not contain extra merges. The extra merges are IMHO super confusing 
in the git history but bring completely zero knowledge gain. 

Contributions which consist of exactly one commit IMHO should always be merged 
as fast-forward (or rebase) and not as merge commits, but that's the 
responsibility of the gnucash maintainers. Your responsibility would be to 
send in pull requests which don't contain unneeded merge commits. Thanks a 
lot!

And thanks again for your contribution.

Best Regards,
Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Enabling github branch protection rules? Re: [Gnucash/gnucash] po/de.po: fix translation bug (#627)

[Christian Stimming]

John,

thanks a lot for testing. Well, that's unfortunate. However, maybe some of the 
other rules would help us to avoid this better? 
https://github.com/Gnucash/gnucash/settings/branch_protection_rules/new
How about activating "Require pull request reviews before merging" with maybe 
"2"? Again, I'm not sure whether code-gnucash-user can still push the commits. 
Could you give it a try? Thanks a lot.

Regards,
Christian



Am Freitag, 3. Januar 2020, 00:15:02 CET schrieb John Ralls:
> Christian,
> 
> Just tried it as a test (the user id is code-gnucash-user). It doesn't
> prevent merging from the web page.
> 
> Regards,
> John Ralls
> 
> > On Jan 2, 2020, at 1:11 PM, Christian Stimming 
> > wrote:
> > 
> > Dear developers,
> > 
> > yesterday I accidentally used the web interface of github to merge a pull
> > request, but we don't want this, because the merge (or any other commit)
> > on
> > github is going to be overwritten by the next push from code.gnucash.org.
> > 
> > I was wondering whether we could enable the github "Protect matching
> > branches" rules
> > https://github.com/Gnucash/gnucash/settings/branch_protection_rules/new
> > There's a rule "Restrict who can push to matching branches", which we
> > could
> > restrict to the user that pushes from code.gnucash.org. This should
> > prevent
> > any such accidental merges from github's web interface, shouldn't it?
> > However, this needs to be enabled by somebody who immediately can check
> > that the push from code still works. Anybody there care to take a look?
> > Thanks a lot!
> > 
> > Regards,
> > 
> > Christian
> > 
> > Am Donnerstag, 2. Januar 2020, 11:42:12 CET schrieb Frank H. Ellenberger:
> >> Never use githubs webinterface for merging for any gnucash project!
> >> Because code.gnucash.org is canonical, the merge got overwritten by the
> >> next push.
> > 
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Enabling github branch protection rules? Re: [Gnucash/gnucash] po/de.po: fix translation bug (#627)

[Christian Stimming]

Dear developers,

yesterday I accidentally used the web interface of github to merge a pull 
request, but we don't want this, because the merge (or any other commit) on 
github is going to be overwritten by the next push from code.gnucash.org. 

I was wondering whether we could enable the github "Protect matching branches" 
rules 
https://github.com/Gnucash/gnucash/settings/branch_protection_rules/new
There's a rule "Restrict who can push to matching branches", which we could 
restrict to the user that pushes from code.gnucash.org. This should prevent 
any such accidental merges from github's web interface, shouldn't it? However, 
this needs to be enabled by somebody who immediately can check that the push 
from code still works. Anybody there care to take a look? Thanks a lot!

Regards,

Christian

Am Donnerstag, 2. Januar 2020, 11:42:12 CET schrieb Frank H. Ellenberger:
> Never use githubs webinterface for merging for any gnucash project!
> Because code.gnucash.org is canonical, the merge got overwritten by the next
> push.




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] commit 67b508babecd12b8f16eda5abf8d5d5b16402c21

[Christian Stimming]

Am Sonntag, 29. Dezember 2019, 21:57:14 CET schrieb John Ralls:
> > Anyway, I don't think it's a large problem. The commit still contributed
> > an
> > improvement to many other languages, which is just fine.
> 
> Christian,
> 
> Thanks. I've retagged the release and re-spun the tarballs so that the TP
> will have the changes on all of the files. Without that we run the risk
> that the problem will repeat next time and I'll have forgotten about it.
> That would lose the changes forever.
> 
> Besides, it turned out that there was a problem in the tarballs:
> https://bugs.gnucash.org/show_bug.cgi?id=797536.

Ok. Turns out I got a bit more ambitious later this evening and I fixed some 
more translations. These just barely missed our release deadline, sorry for 
that. But they will appear there in the future, so that's probably just fine.

Regards,

Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] commit 67b508babecd12b8f16eda5abf8d5d5b16402c21

[Christian Stimming]

Am Samstag, 28. Dezember 2019, 01:49:09 CET schrieb John Ralls:
> > commit 67b508babecd12b8f16eda5abf8d5d5b16402c21
> > Author: Christian Stimming 
> > Date:   Thu Dec 26 17:46:15 2019 +0100
> > 
> >Improve translations by scriptedly removing the removed colon suffix.
> >
> >The trailing colons have been removed in the source e.g.
> >here 6897f13e ff, but this created a lot of fuzzy translations.
> >With the po/remove-suffix.sh script, those changes are
> >adapted in all po files in order to make translators' life
> >easier.
> >  (...)
> > 56 files changed, 1009363 insertions(+), 905064 deletions(-)
> 
> Christian,
> 
> Unfortunately you neglected to pull in the latest translations from the
> translation project before undertaking this. There are two translations
> there, uk.po and zh_CN.po. 

Dear John,

I'm sorry. When I edited all those other languages as well, I was well aware 
that my changes might get overwritten by other contributions from translation 
project or yet other channels. My rationale was rather this: I had to do the 
work for my own language (de.po) anyway. It was only little additional work to 
extend it to all available languages, which would then benefit from my work. 
If it's not all 50 languages which benefit but "only" 48, very well, we still 
have enough benefit for all of us.

> I tried reverting these commits, installing the
> new translations, and reapplying these commits but that introduced too many
> conflicts that to be resolved by hand so I resorted to just installing the
> new translations on top of these commits instead. 

I'm sorry to hear about the extra work. Turned out that the trick here is to 
run msgmerge first on both before merging (so that the TP version and our git 
version originate from the same gnucash.pot template), and then merging went 
surprisingly smooth.

> Since your changes were
> scripted perhaps you can re-run the scripts on those two translations
> before the release on Sunday.

I was kept AFK until Sunday morning Berlin time and contributed the merge 
then, but seems like I missed your tagging time somewhat earlier. 

Anyway, I don't think it's a large problem. The commit still contributed an 
improvement to many other languages, which is just fine.

Regards,

Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] segmentation fault / gnucash crashing upon using online banking actions

[Christian Stimming]

As derek already said: you are using a system-installed gwenhywfar. You need to 
check at aqbanking configure time that it really chose the correct 
libgwenhywfar, and gnucash subsequently too.

Thanks!

Christian 

> Am 15.10.2019 um 12:00 schrieb Alex :
> 
> First of all, I forgot to say I'm on Linux Debian, sorry @Martin for not 
> mentioning!
> 
> Dear Christian,
> 
> I'm not sure if the "--enable-debug" flag changed the output of the first 
> lines of the gdb backtrace in any way, please see below, to me they seem just 
> the same...
> 
> Here's what I dit:
> 
> recompiled gwenhywfar:
> I did not git pull, so we are as of Oct 14th.
> $ export LANG="C"
> $ ./configure --with-guis="gtk3" --enable-debug
> 
> also recompiled aqb and gnucash.
> 
> Then ran:
> $ gdb gnucash
> (gdb) run --debug --extra
> Starting program: /usr/local/bin/gnucash --debug --extra
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [ … here's some various gnucash startup debugging outputs … ]
> 
> Gnucash is open. Empty file. I enter the aqbanking wizard straight away, 
> "edit" the only existing user, "get certificate", OK, "Get Bank Info", Crash.
> 
> Here's the first lines of the backtrace:
> 
> Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault.
> 0x7fffd6283989 in GWEN_Text_EscapeToBuffer ()
>   from /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60
> (gdb) bt full
> #0  0x7fffd6283989 in GWEN_Text_EscapeToBuffer ()
>at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60
> #1  0x7fffba4325a3 in GWEN_ConfigMgrDir_AddGroupFileName ()
>at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so
> #2  0x7fffba43318e in GWEN_ConfigMgrDir_DeleteGroup ()
>at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so
> #3  0x7fffd6539e8c in AB_Banking_ReadConfigGroup (ab=0x57dda620, 
> groupName=groupName@entry=0x7fffd66b8393 "users", uniqueId=uniqueId@entry=1, 
> doLock=doLock@entry=1, doUnlock=doUnlock@entry=0, 
> pDb=pDb@entry=0x7fff70c8) at banking_cfg.c:413
>rv = 
>idBuf = 
> "\230'\aXUU\000\000\002\000\000\000\000\000\000\000\000(\aXUU", '\000' 
> , 
> "Q\303\312\352\377\177\000\000\000\000\000\000\000\000\000\000\020%\217UUU\000\000
>  
> \217\225UUU\000\000\300m\377\377\377\177\000\000\377\377\377\377\377\377\377\377\357\252\312\352\377\177\000\000\000\000\000\000\000\000\000\000\030\275\024\367\377\177\000\000\377\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000@\257\225UUU\000\000pn\377\377\377\177\000\000c\276\024\367\377\177\000\000pn\377\377\377\177\000\000\277\276\024\367\377\177\000\000\v\272\336\352\377\177\000\000\200\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\000"...
>__PRETTY_FUNCTION__ = "AB_Banking_ReadConfigGroup"
> #4  0x7fffd653d9a1 in AB_Banking_Read_UserConfig (ab=, 
> uid=uid@entry=1, doLock=doLock@entry=1, doUnlock=doUnlock@entry=0, 
> pDb=pDb@entry=0x7fff70c8)
>at banking_user.c:20
>rv = 
> #5  0x7fffd6552110 in AB_Provider_ReadUser (pro=pro@entry=0x57b0a2f0, 
> uid=uid@entry=1, doLock=doLock@entry=1, doUnlock=doUnlock@entry=0, 
> user=user@entry=0x57b0b900)
>at provider_user.c:24
>rv = 
>    db = 0x0
>    uidInDb = 
> #6  0x7fffd6552b77 in AB_Provider_BeginExclUseUser (pro=0x57b0a2f0, 
> u=0x57b0b900) at provider_user.c:226
>rv = 
>uid = 1
> [ … and so on … ]
> 
> Please let me know if I can do anything else.
> 
> Kindly
> Alex
> 
> On Mon, 14 Oct 2019 21:51:41 +0200
> Christian Stimming  wrote:
> 
>> Dear Alex,
>> 
>> we're getting closer... the libaqbanking lines already have full
>> debug info, but only the libgwenhywfar do not have it. Can you
>> compile again gwenhywfar, this time with --enable-debug, so that
>> the first few lines from the backtrace (only those are important)
>> contain some more information such as the function arguments? This
>> would be a big help. Thanks!
>> 
>> Regards,
>> Christian
>> 
>> Am Montag, 14. Oktober 2019, 18:15:00 CEST schrieb Alex:
>>> Here is a backtrace of Gnucash when crashing upon clicking on
>>> "Get Bank Info" in the aqbanking wizard. Let me know if I can do
>>> anything else.
>>> 
>>> -- GDB BACKTRACE START ---
>>> 
>>> Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault.
>>> 0x7fffd6075989 in GWEN_Text_EscapeToBuffer ()
&g

Re: [GNC-dev] segmentation fault / gnucash crashing upon using online banking actions

[Christian Stimming]

Dear Alex,

we're getting closer... the libaqbanking lines already have full debug info, 
but only the libgwenhywfar do not have it. Can you compile again gwenhywfar, 
this time with --enable-debug, so that the first few lines from the backtrace 
(only those are important) contain some more information such as the function 
arguments? This would be a big help. Thanks!

Regards,
Christian

Am Montag, 14. Oktober 2019, 18:15:00 CEST schrieb Alex:
> Here is a backtrace of Gnucash when crashing upon clicking on "Get Bank
> Info" in the aqbanking wizard. Let me know if I can do anything else.
> 
> -- GDB BACKTRACE START ---
> 
> Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault.
> 0x7fffd6075989 in GWEN_Text_EscapeToBuffer ()
>from /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60
> (gdb) bt full
> #0  0x7fffd6075989 in GWEN_Text_EscapeToBuffer ()
> at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60
> #1  0x7fffbe22d5a3 in GWEN_ConfigMgrDir_AddGroupFileName ()
> at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so
> #2  0x7fffbe22e18e in GWEN_ConfigMgrDir_DeleteGroup ()
> at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so
> #3  0x7fffd632be8c in AB_Banking_ReadConfigGroup (ab=0x582f8820,
> groupName=groupName@entry=0x7fffd64aa393 "users",
> uniqueId=uniqueId@entry=1, doLock=doLock@entry=1,
> doUnlock=doUnlock@entry=0, pDb=pDb@entry=0x7fff71b8) at
> banking_cfg.c:413 rv = 
> idBuf = "\005", '\000' ,
> "\001\000\000\000\000\000\000\000\000\210\221UUU\000\000\005\000\000\000\00
> 0\000\000\000V@\323\352\377\177\000\000\000\000\000\000\000\000\000\000X\213
> \221UUU\000\000pn\377\377\377\177\000\000\340!\336\367\377\177\000\000\000\2
> 10\221UUU\000\000\374\b\000\000\000\000\000\000\000\000\250UUU\000\000H\367\
> 374\325\377\177\000\000\200\033\376\325\377\177\000\000\363*\336\367\377\177
> \000\000\374\b\000\000\000\000\000\000\200\033\376\325\377\177\000\000\000\0
> 00\250UUU\000\000\030o\377\377\377\177\000\000\024o\377\377\377\177\000\000H
> \367\374\325\377\177\000\000=\223\060\326\377\177\000\000\360\020\060\326\37
> 7\177\000\000\030o\377\377\377\177\000\000"... __PRETTY_FUNCTION__ =
> "AB_Banking_ReadConfigGroup"
> #4  0x7fffd632f9a1 in AB_Banking_Read_UserConfig (ab=,
> uid=uid@entry=1, doLock=doLock@entry=1, doUnlock=doUnlock@entry=0,
> pDb=pDb@entry=0x7fff71b8) at banking_user.c:20
> rv = 
> #5  0x7fffd6344110 in AB_Provider_ReadUser
> (pro=pro@entry=0x559d8d20, uid=uid@entry=1, doLock=doLock@entry=1,
> doUnlock=doUnlock@entry=0, user=user@entry=0x585e9720) at
> provider_user.c:24
> rv = 
> db = 0x0
> uidInDb = 



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Status of German online banking (aqbanking, HBCI, FinTS)

[Christian Stimming]

Dear developers,

just a quick status report of what is going on with German online banking 
these days: There were reports of major bank server changes on approx. 
September 14th, caused by new EU banking regulations called PSD2. This caused 
some changes in the online banking standard FinTS (formerly called HBCI), but 
there was only rudimentary documentation of what the protocol changes will 
actually be, at least according to what was known to the aqbanking library 
developers (mainly Martin). 

In the end, it turns out pretty much all bank servers have significantly 
changed their behaviour into something different than before. The previous 
stable library series (aqbanking 5.8.2) does not support those required newest 
changes anymore. Martin managed to get the communication to the various 
servers working again one by one, working on the most recent master branch of 
aqbanking (5.99.x, will be 6.x soon). The first reports about successful 
online banking have been flowing in, on the gnucash-de or aqbanking-user. Once 
this has stabilized some more, there will also be stable releases of aqbanking
+gwenhywfar which will give German online banking users a new series of stable 
packages. However, right now this is still somewhat in stabilization phase. If 
bugreports or questions occur for German online banking users, please ask them 
for some more patience unless they are willing and able to compile from source 
tarballs. Thanks!

Regards,

Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] gnucash maint: I18n fix: Trim user-visible strings from unneeded whitespace.

[Christian Stimming]

Am Dienstag, 3. September 2019, 08:36:20 CEST schrieb Geert Janssens:
> Op maandag 2 september 2019 22:27:02 CEST schreef Christian Stimming:
> > Updated  via  https://github.com/Gnucash/gnucash/commit/16a69e2a 
> > (commit)
> > 
> > from  https://github.com/Gnucash/gnucash/commit/abc0964c (commit)
> > 
> > commit 16a69e2a63f462346f498918eee738e5443bea58
> > Author: Christian Stimming 
> > Date:   Mon Sep 2 22:25:39 2019 +0200
> > 
> > I18n fix: Trim user-visible strings from unneeded whitespace.
> > 
> > This makes translations unnecessarily confusing. If the layout
> > needs some space, feel free to add padding and such.
> 
> Isn't this kind of empty space introduced by the glade tool automatically if
> strings become too long ?

I don't think so. In this particular case the space and line breaks showed up 
in gnucash.pot and the translations, but in all other cases it does not. I 
think this is just a misformatting from the previous editor of this glade file 
who didn't check the effects of this formatting on the translation strings, so 
I fixed this at least for the future.

Regards,
Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] German online banking users would need a 3.7 release before mid-September...

[Christian Stimming]

John,

today we finally got note from some users that bank servers which used to 
complain without the patch from 39cfcb30f939ca3c413350c8262ceea69085fb6b are 
now satisfied and all works fine. Hence, the next release 3.7, now scheduled 
for Sept 7th, would indeed be great.

Thanks a lot!
Regards,
Christian

Am Samstag, 24. August 2019, 18:26:05 CEST schrieb John Ralls:
> Christian,
> 
> Not *quite* so fast: That's contingent on you confirming that you've gotten
> that positive feedback by then.
> 
> Regards,
> John Ralls
> 
> > On Aug 24, 2019, at 2:27 AM, Christian Stimming 
> > wrote:
> > 
> > Dear John, that sounds definitely good. So the Release of end of September
> > will be scheduled earlier for Sept 7th and that’s it. Thanks a lot!
> > 
> > Regards, Christian
> > 
> >> Am 23.08.2019 um 23:42 schrieb John Ralls :
> >>> On Aug 23, 2019, at 2:33 PM, Christian Stimming 
> >>> wrote:>>> 
> >>> Am Donnerstag, 22. August 2019, 21:57:30 CEST schrieb John Ralls:
> >>>>> On Aug 11, 2019, at 11:43 AM, Christian Stimming
> >>>>> 
> >>>>> wrote:>
> >>>>> 
> >>>>> Am Samstag, 10. August 2019, 20:32:00 CEST schrieb John Ralls:
> >>>>>> Regardless, we can do a snap release as soon as we can get the
> >>>>>> registration
> >>>>>> number issue sorted and I can make time to do the release.
> >>>>> 
> >>>>> The windows nightly has built last night. On gnucash-de I asked
> >>>>> windows-users to start testing it. Let's see whether this is indeed
> >>>>> sufficiently implemented. Once some positive feedback has arrived, a
> >>>>> 3.7
> >>>>> release sometime in August would indeed be great - as it fits best for
> >>>>> you.
> >>>> 
> >>>> Christian,
> >>>> 
> >>>> Has there been sufficient testing to proceed with a release this
> >>>> weekend?
> >>> 
> >>> Dear John,
> >>> 
> >>> to be honest, I still haven't received the definitive feedback that the
> >>> current git/maint code has fixed the various bank server complaints.
> >>> Hence, I think a release is not really suited for this weekend. Maybe
> >>> next weekend, but as I said, there hasn't been the really clear
> >>> feedback that current maint really fixes all issues there.
> >>> 
> >>> Current maint already contains a number of improvements over the last
> >>> release for sure, but this is fortunately true for almost all points in
> >>> time. But for the online banking things we are not yet sure that this
> >>> really fixes the most important issue. I'll keep you posted. Thanks!
> >> 
> >> Christian,
> >> 
> >> Since the whole point of the snap release is to get the FinTS product
> >> registration feature to German users we should indeed make sure that it
> >> works before releasing it.
> >> 
> >> Unfortunately I'm fully engaged next weekend so the release may have to
> >> wait until the following weekend, September 7. I don't think there's
> >> much point in doing another release 3 weeks later so we'll just call it
> >> the regular release and delivered early.
> >> 
> >> Regards,
> >> John Ralls




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] German online banking users would need a 3.7 release before mid-September...

[Christian Stimming]

Dear John, that sounds definitely good. So the Release of end of September will 
be scheduled earlier for Sept 7th and that’s it. Thanks a lot!

Regards, Christian 

> Am 23.08.2019 um 23:42 schrieb John Ralls :
> 
> 
> 
>> On Aug 23, 2019, at 2:33 PM, Christian Stimming  
>> wrote:
>> 
>> Am Donnerstag, 22. August 2019, 21:57:30 CEST schrieb John Ralls:
>>>> On Aug 11, 2019, at 11:43 AM, Christian Stimming 
>>>> wrote:> 
>>>> Am Samstag, 10. August 2019, 20:32:00 CEST schrieb John Ralls:
>>>>> Regardless, we can do a snap release as soon as we can get the
>>>>> registration
>>>>> number issue sorted and I can make time to do the release.
>>>> 
>>>> The windows nightly has built last night. On gnucash-de I asked
>>>> windows-users to start testing it. Let's see whether this is indeed
>>>> sufficiently implemented. Once some positive feedback has arrived, a 3.7
>>>> release sometime in August would indeed be great - as it fits best for
>>>> you.
>>> 
>>> Christian,
>>> 
>>> Has there been sufficient testing to proceed with a release this weekend?
>> 
>> Dear John,
>> 
>> to be honest, I still haven't received the definitive feedback that the 
>> current git/maint code has fixed the various bank server complaints. Hence, 
>> I 
>> think a release is not really suited for this weekend. Maybe next weekend, 
>> but 
>> as I said, there hasn't been the really clear feedback that current maint 
>> really fixes all issues there.
>> 
>> Current maint already contains a number of improvements over the last 
>> release 
>> for sure, but this is fortunately true for almost all points in time. But 
>> for 
>> the online banking things we are not yet sure that this really fixes the 
>> most 
>> important issue. I'll keep you posted. Thanks!
> 
> Christian,
> 
> Since the whole point of the snap release is to get the FinTS product 
> registration feature to German users we should indeed make sure that it works 
> before releasing it.
> 
> Unfortunately I'm fully engaged next weekend so the release may have to wait 
> until the following weekend, September 7. I don't think there's much point in 
> doing another release 3 weeks later so we'll just call it the regular release 
> and delivered early.
> 
> Regards,
> John Ralls
> 

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] German online banking users would need a 3.7 release before mid-September...

[Christian Stimming]

Am Donnerstag, 22. August 2019, 21:57:30 CEST schrieb John Ralls:
> > On Aug 11, 2019, at 11:43 AM, Christian Stimming 
> > wrote:> 
> > Am Samstag, 10. August 2019, 20:32:00 CEST schrieb John Ralls:
> >> Regardless, we can do a snap release as soon as we can get the
> >> registration
> >> number issue sorted and I can make time to do the release.
> > 
> > The windows nightly has built last night. On gnucash-de I asked
> > windows-users to start testing it. Let's see whether this is indeed
> > sufficiently implemented. Once some positive feedback has arrived, a 3.7
> > release sometime in August would indeed be great - as it fits best for
> > you.
> 
> Christian,
> 
> Has there been sufficient testing to proceed with a release this weekend?

Dear John,

to be honest, I still haven't received the definitive feedback that the 
current git/maint code has fixed the various bank server complaints. Hence, I 
think a release is not really suited for this weekend. Maybe next weekend, but 
as I said, there hasn't been the really clear feedback that current maint 
really fixes all issues there.

Current maint already contains a number of improvements over the last release 
for sure, but this is fortunately true for almost all points in time. But for 
the online banking things we are not yet sure that this really fixes the most 
important issue. I'll keep you posted. Thanks!

Regards,
Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] German online banking users would need a 3.7 release before mid-September...

[Christian Stimming]

Am Samstag, 10. August 2019, 20:32:00 CEST schrieb John Ralls:
> > the German online banking users have received notice from their banks that
> > due to EU regulations, from mid-September onwards (Sept 14th) the banking
> > client software has to use a registered product key, otherwise the bank
> > server connection will be refused.
> > 
> > (In German: https://www.hbci-zka.de/register/prod_register.htm )
> > 
> > For gnucash, I have registered and received such a product key, and in the
> > communication to me there haven't been any restrictions that would pose
> > problems for open source software. Hence, as long as gnucash will stick to
> > this procedure and send the product key, the users (and we) should be
> > fine.
> 
> Apparently the bank servers were supposed to have switched over last week,
> see https://www.hbci-zka.de/register/register_faq.htm. The 14 September
> deadline seems to have something to do with using FinTS bank interfaces via
> third party services, see https://subsembly.com/apidoc/fints/index.html
> under "PSD2 Client Registration". I suppose some users may have configured
> GnuCash to do that and now will have to reconfigure to talk to their banks
> instead. There's nothing we can do about that.

The information on the zka.de  website about the dates is (no pun intended) 
outdated and the information is also unchanged for many months there. The date 
of Sept. 14th is what various users received as notification from their banks 
quite recently, that's where this date is from. 

> Regardless, we can do a snap release as soon as we can get the registration
> number issue sorted and I can make time to do the release.

The windows nightly has built last night. On gnucash-de I asked windows-users 
to start testing it. Let's see whether this is indeed sufficiently 
implemented. Once some positive feedback has arrived, a 3.7 release sometime 
in August would indeed be great - as it fits best for you.

> I am a bit concerned about the registration number being published. What's
> to prevent a bad actor from taking it and using it in a different,
> malicious, application? What might be the consequences? Would DK revoke
> GnuCash's registration? I think it more likely that the folks at DK didn't
> even consider the possibility that there might be an open source financial
> application than that it doesn't matter to them.

I totally understand these concerns, and it holds for any open source project 
here, not only ours. Such as: KMyMoney, Hibiscus, aqbanking, but there are 
surely more. As it turns out, we've discussed those very same points on 
gnucash-de several months ago (in German) because the various people there 
came up with the same questions. Some people have asked at the ZKA for a 
statement regarding their view on open source software. Eventually we got a 
reply which is in our favor: This registration number has no legal obligations 
behind it. It is merely a tool for guiding the user support into better suited 
answers.  There's no security level introduced by this here, and it is known 
to the ZKA that open source software will have this number observable in the 
public source code. Yes, this in turn questions the whole point of this 
fuzz... on the other hand, if the bank server will otherwise refuse the whole 
online connection in the first place, we also have to do something about it.

Regards,

Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] German online banking users would need a 3.7 release before mid-September...

[Christian Stimming]

Dear developers,

the German online banking users have received notice from their banks that due 
to EU regulations, from mid-September onwards (Sept 14th) the banking client 
software has to use a registered product key, otherwise the bank server 
connection will be refused.

(In German: https://www.hbci-zka.de/register/prod_register.htm )

For gnucash, I have registered and received such a product key, and in the 
communication to me there haven't been any restrictions that would pose 
problems for open source software. Hence, as long as gnucash will stick to 
this procedure and send the product key, the users (and we) should be fine.

However, as our banking library aqbanking only recently introduced the 
necessary API for this, it was not before July 7th that this code has been 
introduced into gnucash, which means our last stable version gnucash-3.6 does 
not yet contain this.

My question is: Can we schedule the 3.7 release somewhat earlier than our 
normal 3-month schedule, so that this release is available before the bank 
server change in mid-September? Normal schedule for 3.7 is End of September, 
but this is too late for users of this feature.

In theory, any release date between now and Sept 14th would be fine, although 
the earlier we do this, the earlier the respective updates can be tested by 
the users. Maybe around August 20th?

Thanks for your consideration!

Regards,

Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Building gnucash (maint) with aqbanking6 (master)?

[Christian Stimming]

Dear John, thanks for explaining the part with the patches some months ago. 
Indeed they didn’t build and required 2h of work from my side, but with today’s 
commit it now at least builds again.

There is some talk about new regulation for banks in Europe with respect to 
online banking. It could be that Martin needs to quickly implement some new 
protocol parts in aqbanking, just in case some old protocol parts unexpectedly 
stop working. So I thought I better get gnucash ready to switch to most recent 
aqbanking, in case it is needed.

Regards,
Christian 

> Am 30.06.2019 um 17:49 schrieb John Ralls :
> 
> 
> 
>> On Jun 30, 2019, at 1:55 AM, Christian Stimming  
>> wrote:
>> 
>> Dear John,
>> 
>> I'm using gnucash with aqbanking on a daily basis, but have been lagging 
>> behing in the versions that I'm running. Recently I reserved some time again 
>> to update my compiled versions. However, I was unable to compile gnucash 
>> with 
>> aqbanking's master version from git. I keep running into errors that seem 
>> like 
>> nobody has recently tried to actually compile this (such as, wrong function 
>> spellings like AV_AccountSpec_List_GetCount instead of 
>> AB_AccountSpec_List_GetCount in assistant-ab-initial.c:355).
>> 
>> Have you been able to compile gnucash with aqbanking master recently? If 
>> yes, 
>> how did you do this? Thanks for any hint!
> 
> Christian,
> 
> No, why would I? Master branches are for people developing the library, and I 
> have my hands more than full without adding AQBanking to my list of projects.
> 
> However, Martin provided a patch a couple of months ago that's supposed to 
> get GnuCash ready for AQB6. If he fired it off blind and it's no good, well I 
> guess shame on me for trusting him.
> 
> I see that you pushed a couple of commits in the last couple of hours fixing 
> some of it. Does it now build and work?
> 
> Regards,
> John Ralls
> 

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Building gnucash (maint) with aqbanking6 (master)?

[Christian Stimming]

Dear John,

I'm using gnucash with aqbanking on a daily basis, but have been lagging 
behing in the versions that I'm running. Recently I reserved some time again 
to update my compiled versions. However, I was unable to compile gnucash with 
aqbanking's master version from git. I keep running into errors that seem like 
nobody has recently tried to actually compile this (such as, wrong function 
spellings like AV_AccountSpec_List_GetCount instead of 
AB_AccountSpec_List_GetCount in assistant-ab-initial.c:355).

Have you been able to compile gnucash with aqbanking master recently? If yes, 
how did you do this? Thanks for any hint!

Regards,
Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] obfuscation script, windows/Perl SheBang

[Christian Stimming]

Am Montag, 4. Februar 2019, 16:32:38 CET schrieb John Ralls:
> >>> Thanks for the pointer. I've copied this script into our git at
> >>> 
> >>>  ./util/obfuscate.pl
> >> 
> >> While for most gnc-fq-* scripts we us
> >> #!@-PERL-@
> >> and adjust them while building.
> >> 
> >> In utils all perl scripts are hardcoded to
> >> #! /usr/bin/perl
> >> Wouldn't it make sense to have them also configurable?
> 
> No, because gnc-fq-* are build products and util/*.pl are build tools. Since
> obfuscate.pl isn't a build tool it doesn't belong in util; if we're going
> to distribute it for users (and if we're not why put it in the repo at
> all?) then it needs to go somewhere Cmake can find it and install it to
> $CMAKE_INSTALL_PREFIX/bin or libexec and it needs to be renamed to
> "gnc-xml-obfuscate".

Sure. Since it's code and I wanted to edit it, I wanted to put it somewhere in 
git. If there is a better place for it, please anyone feel free to move it 
there.

> > How about going:
> > 
> > #! /usr/bin/env perl
> 
> That's widely regarded as a security hole, though it's also widely used.
> Since it's trivial to override the shebang by calling the perl of your
> choice and passing the script as $1 it's kind of pointless.
> 
> While we're on the topic of shebangs remember that they don't work on
> Windows. Remember too that running this obfuscate script on Windows will
> require the user to install perl. They might already have done so for
> Finance::Quote, but lots of users don't use F::Q.

The script won't work on Windows anyway, at least not out of the box, because 
it not only needs a Perl installation including XML::DOM, but also some word 
list. On Linux this is available under /usr/share/dict/words (symlink to the 
default language's word list), but for windows some other choice has to be 
written into the obfuscate.pl script. Currently this isn't the case, so it 
will just complain about the missing word list.

Regards,
Christian



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Normalizing/obfuscating live data

[Christian Stimming]

Am Sonntag, 3. Februar 2019, 17:03:06 CET schrieb John Ralls:
> > On Feb 2, 2019, at 8:10 PM, David Carlson 
> > wrote:
> > 
> > OK, I want to try https://wiki.gnucash.org/wiki/ObfuscateScript but I am
> > not a computer programmer.  I have no clue how to use it.  Can someone
> > help me?

Thanks for the pointer. I've copied this script into our git at 
  ./util/obfuscate.pl
The script manages to process my 50MB file in approx. 30 seconds. The account 
and txn texts are all nicely obfuscated. 

The script also contains a random obfuscation for the amounts, which will 
simply cause lots of transactions to the equity account upon loading, but this 
could be enabled as well.

In a real data file there are still more places with text that need to be 
modified, e.g. the scheduled transaction templates, bayes import matching, and 
such. Also, the dates are left unmodified which may or may not be a problem. 

Anyone please feel free to check with this script and add more obfuscation 
steps. I would like to achieve a state where the script will obfuscate my 
personal data file enough so that I feel I can make it available as a test 
file.

Usage of the script: Save your normal file in uncompressed form to XML file. 
Then,

   ./obfuscate.pl  inputfile.gnucash > outputfile.gnucash

(Contrary to the comments, the output is just written to stdout, not in-place 
into the file.)

Thanks for the idea here!

Regards,
Christian

 
> Run it from a command line using perl, assuming here that you have
> Strawberry installed on C:
> 
>   c:\strawberry\perl\bin\perl.exe ObfuscateScript path/to/myfile.gnucash
> 
> Note that it rewrites the file in place, so make a copy and run it on that.
> The file needs to be uncompressed.
> 
> Regards,
> John Ralls
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Static locale commit unfortunately buggy

[Christian Stimming]

Am Samstag, 19. Januar 2019, 23:21:58 CET schrieb John Ralls:
> Christian,
> 
> Thanks for noticing. It seems that the std::locale objects created by
> boost::locale aren't quite compatible. I've resolved the problem, at least
> for maint, by using boost::locale to format date-times instead of
> boost::date_time.

Dear John,

thanks for working on this. Now it is fine again and all fixed. Thank you very 
much.

Regards,
Christian

> 
> For the future we can consider another reimplementation of GncDateTime.
> boost::date_time is an oldish library and hasn't been improved much since
> it was accepted into boost. It's a bit quirky and doesn't perform very
> well. std::chrono in C++20 has calendar and timezone functions, so that's
> one possible replacement, though not until at least llvm and gcc implement
> the expanded std::chrono and those implementations are widely available.
> There's also ICU as wrapped by boost::locale. I demurred from that when I
> picked boost::date_time because it's huge, but if we're pulling it in
> anyway it's worth reconsidering.
> 
> Regards,
> John Ralls




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] [6f3499590 Usability improvements for Bayes editor window] (was: gnucash maint: Multiple changes pushed

[Christian Stimming]

Zitat von Geert Janssens :


Op vrijdag 18 januari 2019 23:54:07 CET schreef Christian Stimming:

commit 6f34995901dcfc999c675e5a4bc095eaf52a2d6f
Author: Christian Stimming 
Date:   Fri Jan 18 23:32:31 2019 +0100

Usability improvements for Bayes editor window

Remove the "Are you sure" question as it is simply annoying but does
not help.


Christian,

In what way does it not help or is it annoying ?


Dear Geert, in this particular case it just doesn't make any sense to  
add another are-you-sure question before the actual deletion.


First, the to-be-deleted data itself is not any user-entered data, but  
only indirectly the user decision on previous imports that will guide  
suggestions in future imports, but no actual decisions right now and  
only suggestions for future imports. In other words, there is only  
very little to use here.


Secondly, there is no ambiguity in the potential buttons that a user  
could press. Contrast this to the register's "delete" buttons, where  
either a full txn or a split of a txn could be deleted, and the  
"delete" buttons in the register are one among a long toolbar list.  
Instead, here in the imap-editor-window, there is only exactly one  
button "delete", and it deleted exactly the selected line.  Also, the  
are-you-sure question does not add any information at all. In the  
register, the question highlights the fact if there are already  
reconciled splits and such, but in this case, the question is only   
the kind of "you pressed this button; did you really want to press  
this button?"




I don't use bayes data so I don't know the specifics of how this works.
However in general when gnucash is about to delete data we ask the user
whether that's what s/he really wants to do. In many cases we also  
provide the

option to remember the answer.

Is there an undo feature (other than restoring from backup) if the user
deleted these bayes entries by accident ?


I did use this feature a little bit more. Sure, in an ideal world,  
there would be an undo button, but here and as long as we are in C  
this is not achievable. So we make our own assessment on how painful  
an accidental deletion of the wrong data would be. In this bayes  
editor window, as I said above, the data isn't any directly  
user-entered data, and its accidental deletion also doesn't change any  
user-entered data directly. It would add a little bit of extra clicks  
upon the next import, but then the data is there again. Because of  
this I decided this question is not needed here.


Regards,
Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Static locale commit unfortunately buggy

[Christian Stimming]

Dear John,

unfortunately your commit b4fedff9 of last weekend breaks the correct locale 
treatment. I didn't investigate this in detail, but the date status bar 
message changed to english with this commit instead of sticking to my local 
language. This is with LANG=de_DE.UTF-8 
Could you have a look into this? Thanks a lot!

Regards,
Christian



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] More need for speed improvement around XML

[Christian Stimming]

Am Sonntag, 30. Dezember 2018, 00:44:40 CET schrieb John Ralls:
> > On Dec 29, 2018, at 2:16 PM, Christian Stimming 
> > wrote:> 
> > Am Samstag, 29. Dezember 2018, 01:45:32 CET schrieb John Ralls:
> >>> When saving to XML file, for each transaction the call stack with the
> >>> expensive code walks down like this:
> >>> 
> >>> gnc_transaction_dom_tree_create
> >>> add_time64
> >>> time64_to_dom_tree
> >>> gnc_print_time64
> >>> GncDateTime::format
> >>> GncDateTimeImpl::format
> >> 
> >> Christian,
> >> 
> >> I don't have time to fully test it out right now, but give
> >> https://github.com/jralls/gnucash/tree/maint a go.
> >> 
> >> As noted in the HEAD commit it has a side effect of recording times in
> >> XML
> >> files in UTC, no timezones. Users who want to keep their files in version
> >> control will like that, but it needs to be checked for backward
> >> compatibility with 2.6 before it can be merged into maint.
> > 
> > Thanks for working at this. Indeed the main issue is that we don't need a
> > user-visible format conversion (which must respect the locale) but instead
> > a serialization to a fixed iso8601 format. Fixing this issue also means
> > that the XML files will no longer depend on the local timezone, which is
> > an issue that has been asked for a long time.
> > 
> > Thanks for your patch - this fixes performance issues with
> > gnc_time64_to_iso8601_buff() and all of its callers. However, the
> > Save-to-XML function calls gnc_print_time64() instead (from
> > time64_to_dom_tree), which is a different code path. Consequently, your
> > patch alone does not modify the saved XML (just verified). Your call to
> > GncDateTime::format_iso8601 needs to be used in gnc_print_time64, too,
> > like so:
> > 
> > xmlNodePtr
> > time64_to_dom_tree (const char* tag, const time64 time)
> > {
> > 
> > xmlNodePtr ret;
> > g_return_val_if_fail (time != INT64_MAX, NULL);
> > 
> > -auto date_str = gnc_print_time64 (time, "%Y-%m-%d %H:%M:%S %q");
> > -if (!date_str)
> > -return NULL;
> > +GncDateTime gncdt(time);
> > +auto sstr = gncdt.format_iso8601();
> > +gchar* date_str = g_strdup(sstr.c_str());
> > 
> > 
> > However, with this patch, all time64 timestamps in the XML file will then
> > change from time+timezone to UTC time only. To my surprise, although we
> > knew about this issue for such a long time and changed most timestamps
> > appropriately, there are still timestamps that will change date due to
> > this
> > change. With a quick glance, the "reconciled-date" timestamp contains
> > beginning-of-day in a local timezone. Also maybe user-entered commodity
> > prices. Others might still show up, oh well.
> > 
> > I haven't checked for backward compatibility with 2.6, but will do during
> > the next days.
> 
> Rats, I got the two functions scrambled.
> 
> Geert and I discussed a month or two ago expanding the use of time-neutral
> to everywhere that we currently use day-begin and day-end except searches,
> but neither of us has gotten to it yet.

For completeness: I checked loading such a file with gnucash-2.6, and as far 
as I can tell, this runs just fine. All transactions and their dates show up 
as usual even though the timestamps are now read as UTC instead of localtime.

Regards,
Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] More need for speed improvement around XML

[Christian Stimming]

Am Samstag, 29. Dezember 2018, 01:45:32 CET schrieb John Ralls:
> > When saving to XML file, for each transaction the call stack with the
> > expensive code walks down like this:
> > 
> > gnc_transaction_dom_tree_create
> > add_time64
> > time64_to_dom_tree
> > gnc_print_time64
> > GncDateTime::format
> > GncDateTimeImpl::format
> 
> Christian,
> 
> I don't have time to fully test it out right now, but give
> https://github.com/jralls/gnucash/tree/maint a go.
> 
> As noted in the HEAD commit it has a side effect of recording times in XML
> files in UTC, no timezones. Users who want to keep their files in version
> control will like that, but it needs to be checked for backward
> compatibility with 2.6 before it can be merged into maint.

Thanks for working at this. Indeed the main issue is that we don't need a 
user-visible format conversion (which must respect the locale) but instead a 
serialization to a fixed iso8601 format. Fixing this issue also means that the 
XML files will no longer depend on the local timezone, which is an issue that 
has been asked for a long time.

Thanks for your patch - this fixes performance issues with 
gnc_time64_to_iso8601_buff() and all of its callers. However, the Save-to-XML 
function calls gnc_print_time64() instead (from time64_to_dom_tree), which is 
a different code path. Consequently, your patch alone does not modify the 
saved XML (just verified). Your call to GncDateTime::format_iso8601 needs to 
be used in gnc_print_time64, too, like so:

 xmlNodePtr
 time64_to_dom_tree (const char* tag, const time64 time)
 {
 xmlNodePtr ret;
 g_return_val_if_fail (time != INT64_MAX, NULL);
-auto date_str = gnc_print_time64 (time, "%Y-%m-%d %H:%M:%S %q");
-if (!date_str)
-return NULL;
+GncDateTime gncdt(time);
+auto sstr = gncdt.format_iso8601();
+gchar* date_str = g_strdup(sstr.c_str());


However, with this patch, all time64 timestamps in the XML file will then 
change from time+timezone to UTC time only. To my surprise, although we knew 
about this issue for such a long time and changed most timestamps 
appropriately, there are still timestamps that will change date due to this 
change. With a quick glance, the "reconciled-date" timestamp contains 
beginning-of-day in a local timezone. Also maybe user-entered commodity 
prices. Others might still show up, oh well.

I haven't checked for backward compatibility with 2.6, but will do during the 
next days.

Regards,

Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] More need for speed improvement around XML (Re: Introduction, a story, and 50% improvement in XML loading speed)

[Christian Stimming]

Am Montag, 24. Dezember 2018, 13:38:27 CET schrieb Chris Carson:
> TL;DR:  hi!  I'm a programmer!  The attached patch to one line of code
> gives a 50% reduction in XML load CPU use!  Skeptical?  I was.

Dear Chris,

thanks a lot for this patch! I'm using gnucash since many years, too, and I'm 
still somewhat unhappy with some of the reaction times in the 3.x series of 
gnucash. 

Now that you got a good catch on the XML loading time, maybe you are up for 
some improvements on the XML saving time...? :-)  I ran some valgrind where I 
could locate an expensive code section, but I'm a bit out of practice to know 
the C++11 way of writing that code in a more efficient way. Here's what I 
found:

When saving to XML file, for each transaction the call stack with the 
expensive code walks down like this:

gnc_transaction_dom_tree_create
add_time64
time64_to_dom_tree
gnc_print_time64
GncDateTime::format
GncDateTimeImpl::format

and this very last function seems significantly more expensive than needed, 
slowing down saving considerably:

std::string
GncDateTimeImpl::format(const char* format) const
{
using Facet = boost::local_time::local_time_facet;
std::stringstream ss;
//The stream destructor frees the facet, so it must be heap-allocated.
auto output_facet(new Facet(normalize_format(format).c_str()));
// FIXME Rather than imbueing a locale below we probably should set 
std::locale::global appropriately somewhere.
ss.imbue(std::locale(std::locale(""), output_facet));
ss << m_time;
return ss.str();
}

Both the operator<< and the constructor std::locale(const char*) seem to be 
quite costly operations. To me, it seems there is way too much construction/
destruction going on for options that are constant during each saving 
operation. Maybe even the recent commit 7f1a7115 (Frank?) has slowed down 
things here even more. Maybe this could be checked in some of the unittests 
more easily, but I'm a bit out of practice there, too. Maybe someone is up for 
some performance boosting here...? Thanks a lot in advance!

Best Regards,

Christian



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Slow user interface in 3.x gnucash: Online transaction import painfully slow - with workaround

[Christian Stimming]

Dear developers,

as I'm still in the process of migrating my everyday work from 2.6.x gnucash 
to 3.x gnucash, I enountered some places where the user interface is still 
quite slow in current 3.x gnucash compared to the old one. I've fixed on such 
issue in the last days, but other remain.

One such place that seems painfully slow is the online transaction import 
(using aqbanking with a German HBCI bank account). After the connection log 
window closes, it took literally minutes until the transaction-matching window 
appeared. During this step, the imported transactions should be matched 
against potentially existing ones with the identical online_id, and suggested 
matches for all the non-matching ones are being calculated. (After editing 
normally there, clicking "Ok" was additionally very slow, but let's focus on 
the first step.)

By looking into this with valgrind/callgrind, it turns out that the register 
windows keep getting refreshed a lot, i.e. gtk_widget_draw is called several 
ten thousands times during this phase. This is quite weird. Of course the UI 
shouldn't get updated during the calculation step, and only after this is 
finished the UI update should be activated again.

Here's the workaround: I closed all account register windows, and select the 
online actions by selecting my online account in the account tree widget as 
selected item. When calling the online transaction download now, there is no 
large delay anymore! (i.e. the behaviour is practically identical to 2.6 
gnucash)

This seems quite weird to me. It seems there is no gnc_suspend_gui_refresh / 
gnc_resume_gui_refresh pair for this first step before the matcher window 
opens, so maybe this needs to be inserted in the correct place. However, in 
2.6 gnucash this was missing, too, and it didn't seem to be a problem.

Also, on clicking "Ok" there is such a suspend/resume pair (in import-main-
matcher.c lines 160ff), unchanged from 2.6 to now, but in my first tests when 
the register windows are open, this step has just as well a minute-long delay 
similar to the first step.

Anyone an idea on what might be missing? Thanks for pointers. 

Unfortunately I didn't find an easy method to reproduce this without online 
account. Maybe some of the file imports show this as well, but so far I didn't 
encounter it except with the online account.

Regards,

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Minor coding style discussion: C++ and comments

[Christian Stimming]

Dear developers,

some years ago we had a longer discussion about our coding style guide, 
especially as we started with more C++ parts in the project. Last time we 
discussed this a bit more was in 2014 [1], and the result was summarized in 
the wiki page  https://wiki.gnucash.org/wiki/CodingStandard

However, as C++ becomes more common for the actual work throughout gnucash, we 
might need to add or clarify a few points there. In my opinion this is really 
a minor issue, as everyone of us will be able to read and write any coding 
style, regardless which one we prefer. It is just nicer to read if there is a 
larger level of consistency. Having said that, one such thing is the way of 
writing multi-line comments in C++ code. Should this be:

// This is
// a multi-line comment (C++ style)

or rather in C style

/* This is
   a multi-line comment (C style) */

with additionaly variants of those? John and I discussed this question 
shortly. There used to be an advice on the wiki page but different from the 
other points this hasn't been discussed here on the mailing list [2]. Hence 
John and I agreed it should be raised on the mailing list.

My proposal is to use the C++ style option in the source code. In any case the 
style should be consistent throughout the source files, i.e. someone would 
need to transform the style that is different from the agreed one.

Also, the doxygen comments in the headers, should those stick to the doxygen 
proposal

/** Some doxygen
multi-line comment (C style, doxygen) */

or should we switch to something different? There are multiple options 
possible, including 

/// Some doxygen multi-line
/// comment (C++ style, doxygen)

but on the other hand we don't have many C++-only headers so far. I'd rather 
stick with the old style as long as we usually have headers used by the C code 
as well.

More ideas and voices?

Regards,

Christian


[1] 
https://lists.gnucash.org/pipermail/gnucash-devel/2014-September/038027.html 
[2] John said: The only discussion about commenting style I found was 
https://lists.gnucash.org/pipermail/gnucash-devel/2008-January/thread.html#22321
 (the thread finishes in February, 
https://lists.gnucash.org/pipermail/gnucash-devel/2008-February/022375.html); 
before we considered C++; another discussion about C++ style begins at 
https://lists.gnucash.org/pipermail/gnucash-devel/2014-September/038027.html 
but doesn’t mention comments
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Next shot at "Slow user interface in 3.x gnucash (for large files)"

[Christian Stimming]

Am Mittwoch, 20. Juni 2018, 17:45:42 schrieb John Ralls:
> > On Jun 20, 2018, at 2:29 PM, Christian Stimming 
> >>>> The less involved approaches would be to cache the value or to make KVP
> >>>> retrieval more efficient. I suspect in this case that caching will be
> >>>> the easiest.
> > 
> > Changing the option in the UI is done inside the Scheme option system.
> > This
> > particular option is defined in business-prefs.scm. Maybe the changed
> > value of the book's property in this case does not trigger the "notify"
> > signal of the GObject type system, but all the calls to qof_instance_set
> > in the unittests do trigger that signal?
> > 
> > In any case the pattern for the performance speed-up should be rather
> > clear: Define a cached value of the KVP, register a callback on each
> > write access, and have each write access invalidate the previously cached
> > value so that it is retrieved again and stored as valid cached value. The
> > open question here seems to be where to find the correct callbacks on
> > write access.
> 
> Christian,
> 
> Yeah, the Scheme option code calls  qof_book_set_option and that sets the
> slot directly with KvpFrame::set_path instead of calling qof_instance_set
> (which calls g_object_set) so it won’t emit the
> notify::spilt_action_num_field signal when you change the setting in
> File>Options. Are you sure that’s working? The unit test on the other hand
> uses qof_instance_set which wraps g_obect_set_valist and that does fire the
> notify signal.

Thanks, this was the missing hint: To cover the value setting of 
qof_book_set_option, I added the cache invalidation in that very function, 
regardless of the actual option that is being set. This seems to be the 
easiest way to ensure a valid cache value, or a suitable lookup on invalid 
cache at the next call of the respective getter.

> qof_book_set_option, being defined in qofbook.cpp, offers a simpler
> approach: Instead of dealing with callbacks just set the cached value along
> with the slot. You can fix qof_book_set_property:PROP_OPT_NUM_FIELD_SOURCE
> to call qof_book_set_option instead of qof_instance_set_path_kvp. You’ll
> still need qof_book_use_split_action_for_num to read the slot on its first
> call because qof_book_init can’t set cached_num_field_source from KVP
> because at least in the SQL backend the book is constructed before the
> slots are loaded.

I thought redirecting qof_book_set_property into qof_book_set_option doesn't 
really help here, because the GObject property system could have been used 
somewhere else to access the GObject's property directly. (This is not the 
case, though [1].) The callback of the GObject property covers that case, and 
also the qof_instance_set calls, so I just left it there.

For qof_book_set_option the easiest solution is to make this setter invalidate 
the cached value on each call. Next time the getter is called, the potentially 
changed value is then looked up and cached again. This seems to have covered 
all cases, and now works fine.

Using qof_book_set_option in qof_book_set_property would require to convert 
the std::vector Path to GSList, which seems to be the type that comes from 
Scheme. To be more precise, qof_book_set_option would need to be refactored so 
that the interface from Scheme is kept available, but the C++ interface with 
the std::vector Path must be added in some efficient way. As my original 
problem was solved as outlined above, I though I'd rather stay away from this 
additional refactoring, sorry...

https://github.com/cstim/gnucash/commit/92ea3ba8a60bf4eb19d9b6932fb3ed8b582551a5
and I'll push to code.gnucash.org's maint once I can connect to it again.

Thanks for the reviews and ideas!

Regards,

Christian

[1] (Although this would require to use the property's GParam name, "split-
action-num-field", and we can globally search for this string inside gnucash's 
source code. It appears in qofbook.cpp and in the unittests, but nowhere else, 
so we can rule out this 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Next shot at "Slow user interface in 3.x gnucash (for large files)"

[Christian Stimming]

Am Mittwoch, 20. Juni 2018, 09:59:52 schrieb John Ralls:
> >> It’s all about file compatibility, remember? As it stands, if you make
> >> something a regular member variable then you have to change the schema to
> >> add the element/column, and write a scrub to update older data. We
> >> strongly
> >> prefer not to do that during a stable release cycle and generally require
> >> that the last version of the previous stable series be able to read both
> >> formats.
> > 
> > Yes. Although what I'm concerned with is only the lookup performance, not
> > the serialization place of that option. The serialization may be kept
> > unchanged completely.
> 
> Right. So thinking about that some more, persistence (I think that’s a
> better description of this than serialization) is driven by the backends
> rather than the objects, so you can create a member variable and as long as
> you don’t tell the backends about it it won’t be a problem. That seems to
> be what you’ve tried to do in your patch.

Yes, exactly. This can be applied in this case, and maybe others, if there are 
more data fields that turn out to be a performance bottleneck.

> >> The less involved approaches would be to cache the value or to make KVP
> >> retrieval more efficient. I suspect in this case that caching will be the
> >> easiest.
> > 
> > Yes. I've introduced some caching of this value here, but I still need a
> > little bit of help: 
> > ...
> > 
> > However, I broke the original feature in that change. To reproduce: Open
> > some register where there is some text in the "Num" field, say "".
> > Switch on the "Double Line" view mode. Then open File -> Properties, and
> > on the first tab, activate the option "Use Split Action Field for
> > Number". Press Ok. Before my commit, in the opened register the ""
> > now moved from the first line of the txn to the second line, and vice
> > versa after changing that option again. Unfortunately my commit broke
> > that feature. Maybe someone has a good idea why? Thanks for some
> > pointers.
> 
> As a first guess I’d look at the hook list execution to make sure that your
> adding qof_book_option_num_field_source_changed_cb isn’t somehow preventing
> gnc_plugin_page_register_sort_book_option_changed (in
> gnucash/gnome/gnc-plugin-page-register.c) from running.

I've gotten rid of that weird function from engine-helpers.[hc] and used the 
plan GObject's "notify" signal [1]. Also, the first implementation broke the 
respective unittests. I've got another try, this time with the unittests ok 
again:
https://github.com/cstim/gnucash/commit/c915ec0954c49ecdd65af84680354c38fe192614
Unfortunately, the UI feature still seems to be broken as described above, 
which is somewhat weird since this is what the unittests should have caught.

Changing the option in the UI is done inside the Scheme option system. This 
particular option is defined in business-prefs.scm. Maybe the changed value of 
the book's property in this case does not trigger the "notify" signal of the 
GObject type system, but all the calls to qof_instance_set in the unittests do 
trigger that signal?

In any case the pattern for the performance speed-up should be rather clear: 
Define a cached value of the KVP, register a callback on each write access, 
and have each write access invalidate the previously cached value so that it 
is retrieved again and stored as valid cached value. The open question here 
seems to be where to find the correct callbacks on write access.

Regards,
Christian

[1] 
https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#GObject-notify

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Next shot at "Slow user interface in 3.x gnucash (for large files)"

[Christian Stimming]

Am Sonntag, 17. Juni 2018, 20:09:24 schrieb John Ralls:
> > I.e. the function qof_book_use_split_action_for_num_field is very very
> > expensive. Currently it does a KVP lookup on each call. What keeps us from
> > turning this KVP value into a normal gboolean value in the struct
> > _QofBook?
> 
> Christian,
> 
> It’s all about file compatibility, remember? As it stands, if you make
> something a regular member variable then you have to change the schema to
> add the element/column, and write a scrub to update older data. We strongly
> prefer not to do that during a stable release cycle and generally require
> that the last version of the previous stable series be able to read both
> formats.

Yes. Although what I'm concerned with is only the lookup performance, not the 
serialization place of that option. The serialization may be kept unchanged 
completely.

> One alternative would be to redo the backends so that member variables can
> be designated as stored in KVP, effectively moving KVP out of engine. That
> would be a bit of work but it’s an alternative to changing the schemas.
> It’s a route we’ve discussed before but nobody’s been inclined yet to take
> it on.
> 
> The less involved approaches would be to cache the value or to make KVP
> retrieval more efficient. I suspect in this case that caching will be the
> easiest.

Yes. I've introduced some caching of this value here, but I still need a 
little bit of help: 
https://github.com/cstim/gnucash/commit/376cc19b7143983ce297f2272abf1a44e72fd851
This change gets the register UI back to the old speed again. No more 1 second 
delay after hitting enter. (I wonder why I seem to be the only one who got 
bugged by this, but whatever.)

However, I broke the original feature in that change. To reproduce: Open some 
register where there is some text in the "Num" field, say "". Switch on 
the "Double Line" view mode. Then open File -> Properties, and on the first 
tab, activate the option "Use Split Action Field for Number". Press Ok. Before 
my commit, in the opened register the "" now moved from the first line of 
the txn to the second line, and vice versa after changing that option again. 
Unfortunately my commit broke that feature. Maybe someone has a good idea why? 
Thanks for some pointers.

Regards,

Christian



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Next shot at "Slow user interface in 3.x gnucash (for large files)"

[Christian Stimming]

Dear all,

after the initial success in resolving some of the malloc/free calls due to 
vector allocation for speeding up the user interface for large files, 
I looked into some more causes of slower reaction time in the user interface.

The function xaccSplitOrder is one that is called quite often. This may or not 
may not be ok, but there's a huge performance hit of that function:

80% of its runtime instructions are needed for the following line 
(Split.c:1479 in maint):

  action_for_num = qof_book_use_split_action_for_num_field
(xaccSplitGetBook (sa));

I.e. the function qof_book_use_split_action_for_num_field is very very 
expensive. Currently it does a KVP lookup on each call. What keeps us from 
turning this KVP value into a normal gboolean value in the struct _QofBook? 
What steps are needed to turn a KVP value into a normal data member? (We don't 
happen to have a short todo list for that case, do we :) Does anyone happen to 
know the necessary steps from memory? This would help a lot here. Thank you 
very much.

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Slow user interface in 3.x gnucash (for large files), and potential optimization

[Christian Stimming]

Am Freitag, 15. Juni 2018, 10:05:09 schrieb John Ralls:
> >> A very good catch indeed. But pre-constructing the string in
> >> qofbook.cpp only saves two string constructions per invocation as the
> >> vector still has to make its own copies. I guess that its much worse
> >> for you because the ancient gcc on Ubuntu 14.04 (gcc4.8) doesn't do
> >> small-string optimization.
> > 
> > Is there any reason we cant use std::string& in the vector?  Or do we
> > think that we might lose references there?
> 
> In this instance the string is static so it would be safe to use const
> std::string&, but while there's an is_volatile type trait there's no
> is_static so we can't insert a static assert to catch cases where the
> actual std::string is on the stack. That could lead to some ugly bugs.

The std containers are specified in a way so that they make only sense to 
contain the values by-value (ok, this might be formulated a bit too short, but 
not too long ago this was a good rule of thumb). It is up to the 
implementation to make optimizations (copy-on-write and such), but the 
interface requires the programmer to think of the stored type as "by-value".

Nevertheless I think my change made good use of the std::string's already 
existing optimizations. In particular, the saving was so surprisingly large 
here that I think gcc's std::string itself implements some sort of copy-on-
write optimization, and this means its content isn't deep-copied in these 
calls. 

Some numbers from the valgrind/callgrind evaluation. I got the following 
number of calls, starting from qof_query_run and skipping some uninterestings 
calls in between:

- 6 qof_query_run
- 6 g_list_sort_with_data
- 360,000 (approx.) sort_func - due to the number of splits and txn in my file 
- 360,000 xaccSplitOrder
The most expensive part in this function is this next callee:
- 360,000 qof_book_use_split_action_for_num_field
- 360,000 (approx.) qof_book_get_property

This function in turn has approx. 1,100,000 calls to std::basic_string 
constructor and destructor. The change in my commit is this:
Before my commit, these calls also caused 1,100,000 calls to 
std::string::_S_create and std::string::_M_destroy i.e. the by-value 
constructor and destructor. After my commit, I see a mere 22,000 calls to 
std::string::_S_create and std::string::_M_destroy. 

> Besides, using strings is still leaving performance on the table: A string
> comparison is n times longer than an int comparison where n is the number
> of consecutive leading characters that are the same in the two strings. I
> got a huge speedup on loading a few months ago because GncGUID's
> operator==() was doing a character-wise comparison of the ascii
> representation instead of comparing the two int64_ts of the actual GUID.

Sounds good. The above numbers seem to indicate that std::string already 
optimizes away a long comparison as long as the string memory itself is 
identical. In my opinion this is good enough of an optimization.

> KVP paths aren't really a good use for std::string anyway: It's a lot of
> weight for something that's used as a human-readable index. Even static
> char[] is heavy for this purpose. We could get a huge boost if we use
> something like Glib's quarks [1].
> Want to have a go at that?

Err... this would mean a major refactoring of any access to the KVP system. 
No, I don't feel motivated to work into that direction. Also, if I understnad 
the above valgrind evaluation correctly, we can already achieve almost optimum 
(i.e. pointer comparison) by ensuring a set of std::string constants to be 
used. I think this is the most efficient way to proceed here, and I would just 
push this commit after some more cleanup.

Regards,
Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Slow user interface in 3.x gnucash (for large files), and potential optimization

[Christian Stimming]

Dear all,

as discussed before, I am only recently starting to use the 3.x series of 
gnucash in daily production work. However, there are still some issues that 
keep bugging me, compared to the 2.6.x version of gnucash.

One of the issues is that the user interface in the register is surprisingly 
slower compared to 2.6.x. I have a somewhat large data file [1], so I saw some 
behaviour that is probably not the usual case. The slowness is that when 
activating the auto-complete by typing the first letter in the txn 
description, then pressing , there is a delay of approx. 1.5 seconds with 
100% CPU until the cursor appears in the next field and the data is filled in. 
This delay is quite recognizable and it is annoying. In previous gnucash 
versions, it was not there.

Hence I tried to narrow down the cause of this slowness using 
valgrind/callgrind with switching on and off the instrumentation just around 
this very keypress using callgrind_control. In the result, I recognized a 
surprising high number of std::string constructor calls and similarly 
destructor calls - which, for this single lookup operation, looked suspicious 
to me.

Turns out that the std::string constructor and destructor is used a lot when 
calling qof_instance_get_path_kvp() with a std::vector, but the 
std::vector is created on-the-fly using the { } syntax, AND (this is the 
expensive part) all the std::string's inside that vector are also created on-
the-fly from string literals that are expanded from #defines. It occurred to 
me that this last construction/destruction can be avoided rather easily: Why 
don't we declare std::string constants and use those, instead of the const 
char* literals expanded from the #defines? I implemented a very simple test of 
this idea, see
https://github.com/cstim/gnucash/commit/99c97736dda4afb615aad4b70bd5b7bd761af459

Testing this change with callgrind again brought down the instruction count of 
the described operation in the user interface from 3.2e9 to 2.6e9, which in my 
opinion is a significant optimization. What do you think - would it be a good 
idea to use kind of construct (no pun intended) in this and other places? Or 
did I miss something here?

Regards,

Christian


[1] Some numbers about my data file: 4MB compressed XML, 30,000 transactions, 
200 accounts, 30,000 kvp slots.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

[Christian Stimming]

Am Samstag, 2. Juni 2018, 17:28:27 schrieb John Ralls:
> > there is already a private fork, just as everyone else
> > around here is free to privately fork anything that he/she wants.
> > https://github.com/cstim/gnucash/tree/branch-2.6
> 
> BTW, there's already a 2.6.21 because the MySQL backend was broken on
> 2.6.20. It was released April 10.

Dear John,

yes I confused the numbers here. There was a 2.6.21 in April. I would happily 
switch to the 3.0 branch (git-maint) on my system, as soon as I see for myself 
that it is up and running on my (still old) ubuntu 14.04 system.

However, after I eventually was able to build and run the newer branch [1], it 
turns out to crash in the register on every normal usage. Of course I've filed 
a bug on that one [2] (with gtk-3.10.8 that is), and I will continue looking 
into resolving this problem myself, too. However, until we are able to resolve 
this problem, my guess is that on ubuntu 14.04, there is no 3.0.x version that 
is usable. Can someone report otherwise? If yes, I would happily discuss in 
detail the steps that I'm missing.

Until then, I would again propose to keep a 2.6 branch alive for a few more 
months, so that a potential 2.6.22 release with minor bugfixes might be 
released as well for systems on the age of ubuntu 14.04.

Best Regards,

Christian

[1] For several days, I was stuck at the error at start-up "Undefined 
variable: gnc-build-userdata-path" that got reported also by e.g. Herbert 
Thoma here. For future reference: The solution was to remove any instance of 
an old (2.6) gnucash from the library path both at build time and at run time.

[2] https://bugzilla.gnome.org/show_bug.cgi?id=796556

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

[Christian Stimming]

Am Samstag, 2. Juni 2018, 08:16:35 schrieb John Ralls:
> >> But why do we keep a "gnucash" repo at all and not only everyone's
> >> personal
> >> repository? Of course there is some sort of project belonging. My
> >> proposal
> >> is to still keep the 2.6 branch a little bit more alive, and one or two
> >> maintenance releases might be spun off from there. I'd be the one who
> >> does
> >> the housekeeping there, as discussed already.
> > 
> > Considering you do offer to take care of that 2.6 branch I can live with
> > having one. If John disagrees you may need to make it a core policy
> > decision request and check for a broader opinion there.
> 
> I disagree for the user and contributor confusion reasons already stated,
> because I think that the old Windows build system should be retired, and
> because I think Christian has forgotten how much work goes into support and
> won’t have time to devote to it.
> 
> If Christian wants to fork GnuCash to maintain 2.6.x, he’s free to do so,
> but it should be clear to all that it’s Christian’s fork and not “Official"
> GnuCash. It’s much clearer and cleaner if the fork lives in Christian’s own
> public repository with its own bug tracker and its own support mailing
> list. It’s 10 minutes work to set all of that up on Github, so what’s the
> point of keeping it in the Github repository?

*sigh* Of course there is already a private fork, just as everyone else around 
here is free to privately fork anything that he/she wants. 
https://github.com/cstim/gnucash/tree/branch-2.6
However, that's not the point of our common project gnucash. "Official", as 
you call it.

Talking of core policy decision: Ultimately the decision is about whether 
there might be another 2.6.x release after the 2.6.20 in April, which in turn 
is the reason for the existence of any 2.6 branch. John, it seems you decided 
that there should not be any such release anymore under any circumstances. Had 
this been a decision following our decision process,
https://wiki.gnucash.org/wiki/Decision_process
, I would have been the voice that raises a objection to that decision.

From my point of view, April isn't too far away and there might indeed be a 
2.6.21 with some bugfixes. This is not a long-term commitment, just for maybe 
another few months after the 2.6.20 release. How big is the risk in accepting 
this objection and allow a potential 2.6.21 release to show up in the near 
future? I'm surprised to see that prohibited from your side to begin with.

Regards,

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

[Christian Stimming]

Am Dienstag, 29. Mai 2018, 06:56:44 schrieb John Ralls:
> > On May 29, 2018, at 5:04 AM, Geert Janssens 
> > wrote:
> > 
> > or at best on a branch that clearly shows it's not maintained by the
> > currently active gnucash community (like a cstim-2.6 branch or something
> > similar).
>
> Git != SVN. There is *no reason* for personal branches in a git repository.
> Everyone has their own repository and can easily publish it on Github or
> similar services. That’s where personal branches belong.

But why do we keep a "gnucash" repo at all and not only everyone's personal 
repository? Of course there is some sort of project belonging. My proposal is 
to still keep the 2.6 branch a little bit more alive, and one or two 
maintenance releases might be spun off from there. I'd be the one who does the 
housekeeping there, as discussed already.

Nevertheless thanks for the pointers about building on Ubuntu 14.04, I'll look 
into this for the time being. I'd still like to have the 2.6 branch slightly 
longer alive, though.

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

[GNC-dev] Request of keeping a 2.6 branch still alive (Re: branch-2.6)

[Christian Stimming]

Dear John,

I did notice that the 2.6 branch was deleted (meaning: "maint" is now the 3.x 
branch), but I didn't understand the reasons and didn't see any discussion of 
this decision. I have some requirements which I can meet most easily by just 
continuing the 2.6 version of gnucash, but this in turn needed some occasional 
commits there. For example, I'm still running Ubuntu 14.04 for reasons beyond 
the scope of gnucash, and I haven't been able to build the 3.x branch on that 
machine because of missing packages. At the same time the 2.6 branch met all 
that I needed for everyday work, so I just stick to this.

Hence, I don't quite understand why there is such a strong requirement to 
prohibit specifically any further existence of a 2.6 branch, and why you use 
strong language to underline your point of view here. Also, it's a bit 
puzzeling to me why you suggest me of all people to "change the name and 
artwork" in case of a 2.6 branch - what have I missed here?? Where was the 
discussion that led to this decision? Where was the decision process, if this 
were the project's decision? Maybe some more liberality for other people and 
their different requirements might be more suitable on your side, before 
calling other people's requirements a "fantasy".

This particular pull request for the 2.6 branch showed up only one week after 
I created that branch. To me, this looks like there are still more people 
interested in such a branch. Of course, nothing new will happen there, but the 
interest still exists.

For this reason I propose to keep some old 2.6 branch still up and running in 
the gnucash repository. I would volunteer to act as an owner of that branch, 
in case this is needed, but on the other hand we didn't need any such 
designated branch maintainers for the most part. Further voices? objections? 
ideas? Thanks.

Regards,

Christian


Am Samstag, 26. Mai 2018, 10:50:32 schrieb John Ralls:
> Christian,
> 
> Your "branch-2.6" drew its first PR today, so I've deleted it to avoid any
> further confusion. Please consult with the rest of the team before you do
> anything like that again. If you'd like to maintain a 2.6 branch yourself
> you are of course free to fork GnuCash, though you should change the name
> and artwork to avoid confusion with the main project.
> 
> Regards,
> John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Windows build failed to build new aqbanking 5.7.8

[Christian Stimming]

I've committed this patch to aqbanking, so that it will appear in a 
aqbanking-5.7.9 version when it comes out sometime in the future.

Regards,
Christian

Am Freitag, 30. März 2018, 06:53:32 schrieb John Ralls:
> There’s a type error in AQBanking on windows that stops the AQB build and I
> haven’t yet added the patch to the build, though I did report it to Martin.
> 
> The patch is attached.
> 
> Regards,
> John Ralls
> 
> > On Mar 30, 2018, at 5:13 AM, Robert Fewell <14ubo...@gmail.com> wrote:
> > 
> > Was looking to see if the new version of aqbabking 5.7.8 fixes combobox
> > issue but it fails to build. The new Gwenhywfar 4.20 builds OK and this
> > has
> > the gtk3 stuff in it.
> > There were some errors about creating symlinks due to the files already
> > being there which I suppose one can ignore but later it fails.
> > Looked at the build server logs and it has the same failure.
> > 
> > Bob
> > ___
> > gnucash-devel mailing list
> > gnucash-devel@gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: AqBanking mt940 import: Incomplete Account numbers

[Christian Stimming]

Hi Ueli,

if I understand correctly this question was about the Windows build, right? 
I've just updated the windows build to the latest released versions of 
gwen/aqbanking. However, your bugfix last week in aqbanking has so far not 
been released in an aqbanking version. You need to convince Martin to make an 
aqbanking release with your bugfix in. Otherwise gnucash won't pick this up 
and you can only build yourself new versions directly from git. Thanks!

Regards,
Christian

Am Sonntag, 7. Januar 2018, 14:24:35 schrieb gnuc...@junix.ch:
> Hi everyone
> 
> 
> 
> I sent in a patch for AqBanking last week, that has been adopted by Martin
> Preuss meanwhile, fixing a problem where AqBanking truncates non-numeric
> account numbers, leading to problems with the account selection of GnuCash
> (see below for more details).
> 
> 
> 
> My question to the GnuCash developers is:  Do you guys update AqBanking with
> every release or do I have to file a bug in order to have the changes in
> AqBanking adopted for GnuCash?
> 
> 
> 
> Thank you in advance for your help.
> 
> 
> 
> Regards
> 
> Ueli
> 
> 
> 
> **More details**
> 
> After using GnuCash for circa an year now, I frequently had issues importing
> SWIFT exports from my bank (Raiffeisen Schweiz) into GnuCash:
> 
> During an initial import for a given account, GnuCash asked me correctly to
> select the proper account for the mt940 file. However after doing so, some
> (not all) SWIFT exports for other accounts have been automatically assigned
> to this GnuCash account too.
> 
> 
> 
> As a work around I started to create a new account and delete the offending
> one while assigning the transactions to the one just created.
> 
> 
> 
> Now I finally found the time to dig into this problem and realized that
> AQBanking does not always extract the complete account number from the
> mt940-file.
> My mt940 files started with the following sequence of records:
> :20:STARTUMS
> :
> :25:123456.78
> :
> :28:1
> 
> Where the line beginning with :25: denotes the account number. As my bank’s
> account numbers are composed in a style like ., I had
> multiple accounts starting with “123456” but different digits after the
> period.
> 
> 
> 
> I found that the account number is truncated by AqBanking at the first
> occurrence of a non-numeric character. Hence it whenever GnuCash queried
> the account number, it only got the “customer ID” part, that collides of
> course with multiple accounts.
> 
> 
> 
> Martin Preuss added my patch to the master branch of the git repository.
> However I don’t know yet what Martin’s release plan is.
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Beyond 2.8 - some design thoughts

[Christian Stimming]

Hi Geert,

just two bits of thoughts from my side:

Am Sonntag, 24. Dezember 2017, 17:34:51 schrieb Geert Janssens:
> 1. Use of namespaces.
> ... nested namespaces ...

Yes, absolutely. I have quite some experience with C++ libraries and 
applications and I made very positive experience with this scheme. In our case 
this means we put all of our code in a "gnc::" namespace (at least). 

For me, the nicest way to write this was indeed to wrap the content of every 
file by "namespace gnc {" and "}" (except for the #include directives and 
such). There are some examples - but very few - where some other code requires 
us to put code from us in other namespaces, such as some io modifiers, or 
operators for std classes, but this is then clearly visible. 

Nevertheless "using namespace gnc" should rather not be used, as it makes the 
point of namespaces quite moot, as John already said.

Also, if there is some sort of "modules" that are used in some places but not 
everywhere, it is also useful to add another level of sub-namespace. Such as 
"gnc::import::", but maybe not quite the "engine", as it is used throughout 
everywhere of our code anyway.

If there are any nested namespaces, I would strongly recommend to match the 
namespace structure also in the directory names, at least the topmost ones. In 
our case this implies to match this also in the gnc-modules structure.

Apart from this, and for the project of our size, we might very well not need 
more than two levels of namespaces.

As for the namespace aliases such as "namespace gia = gnc::import::aqbanking", 
those must not appear in header files, but may appear in cpp files. However, I 
didn't like those in general, as it makes readability for other people much 
harder. In terms of mutual readability of code, I would rather stick to the 
plain namespace names and that's it.

> 2. Versioning.
> Here's my proposal:
> After the 2.8 lifecycle let's drop one number and stick with major.minor[-
> build] instead.
> Major releases would increment the first number. Bugfix releases the second.

+1 from me.

Regards,

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GnuCash Draft Concept Guide, or, Whose WIki Is This, Anyway?

[Christian Stimming]

Dear all,

last time this issue was discussed, the majority of replies agreed to have 
those pages removed and that's it. Hence, I now put this into action and 
deleted those pages from the wiki. Thanks a lot!

Regards,

Christian

Am Freitag, 1. Dezember 2017, 16:22:19 schrieb Geert Janssens:
> David,
> 
> I agree this wasn't handled as it should have been. My apologies for that
> even though I'm not directly responsible for it.
> 
> I was and still am in favor of removing these pages and I appreciate the
> creative solution you applied as a compromise.
> 
> I don't know why Frank decided to revert your changes without any prior
> discussion or why he insists on keeping those pages around. I'll let him
> clarify that part.
> 
> I understand your desire for more clear procedures. I don't know what to
> propose unfortunately. On my own here I have been considering what kind of
> policy could work for a group of volunteers who choose to spend their free
> time on the project.
> 
> What we have now (a weak consensus based policy) has worked most of the
> time. But it falls flat as soon as a conflict arises. Is this out of fear
> of losing a precious volunteer or rather because the other volunteers
> prefer to focus on things they enjoy doing rather than resolving conflicts
> ? Perhaps a bit of both.
> 
> So what could work in a volunteer based community ? It should be something
> that takes little time and effort in general of all parties involved
> (volunteers don't have much time or energy to spare aside from the real
> contributions they want to make).
> 
> I'm open to suggestions at this point.
> 
> Regards,
> 
> Geert
> 
> Op vrijdag 1 december 2017 04:57:38 CET schreef David T. via gnucash-devel:
> > Frank,
> > 
> > I am struggling right now to find the right way to bring up the issue of
> > the Gnucash Draft Concept Guide, which still resides on the wiki.
> > 
> > As you know, I have proposed on numerous occasions (most recently, two and
> > a half weeks ago) to have these pages removed from the wiki, since they
> > are out of date, inaccurate, poorly written, superceded, and can turn up
> > in search results, giving users incorrect information about Gnucash and
> > its features and functions.
> > 
> > In that recent thread, four people responded to my request to remove the
> > Draft Concept Guide. Only you appeared to support retaining these pages,
> > although your primary concern was with the mechanical aspects of Google’s
> > search algorithm, upon which I have no expertise to comment. (I will note
> > that fixing one search engine result set does not preclude some OTHER
> > search engine now or in the future from finding and returning these pages
> > despite your best intentions).
> > 
> > You actually offered to move these pages to your own user area, but John
> > noted that might not actually hide the results.
> > 
> > Two days ago, I went to the wiki to search for information about creating
> > reconciliation reports in response to a question on the user list, and
> > when
> > I entered “reconciliation” into the wiki’s OWN search box, 4 of the first
> > 5
> > hits were for the Draft Concept Guide.
> > 
> > Since there had been no support for your position to keep the pages, and
> > since you had had two and a half weeks to take whatever action you had
> > proposed to do (and not taken any), I felt it was time to address the
> > Draft
> > Concept Guide issue directly.
> > 
> > I did not delete the pages outright (since I do not have the rights to do
> > that), but I did what I considered to be the next best thing, which was to
> > replace all the text in those pages with the latin nonsense that printers
> > have used for hundreds of years to mock up page layouts (“Lorem ipsum”). I
> > even made sure to retain the various structural elements in the pages,
> > going so far as to replace headings and bullet points with latin phrases
> > of
> > similar length.
> > 
> > Since, as far as I understand, your only reason for retaining these pages
> > is to serve as some sort of model for the Gnucash community to use for
> > wiki pages, my technique allowed these model pages to be retained
> > *without* their turning up in any search results, anywhere. So, that’s
> > the best of both worlds, right?
> > 
> > Apparently not, as within hours, you had gone and reverted all my changes.
> > 
> > So, I have a few questions to ask of you, Frank, and of the community.
> > 
> > 1) First, Frank: What exactly is so special to you about these pages? Why
> > do you insist that they remain forever on the wiki? The only reason I
> > have heard from you is this idea that the pages could provide wiki page
> > template examples. But, my most recent changes preserved the template
> > aspect without retaining the problematic language—and you still reverted
> > the changes. So, there seems to be something *else* with these pages that
> > makes you feel so protective. What is it? My recent changes seem to prove
> > that there 

Gnucash bitcoin donations: I'd like to disable this bitcoin address

[Christian Stimming]

Dear developers,

some time ago I've set up a bitcoin wallet to be used for gnucash donations in 
bitcoin. Although there has been some considerable income in 2014/2015, 
recently there are only very small amounts coming in on that channel. To be 
precise, in the last 12 months there have been 8 payments received summing up 
to 0.04 btc (approx. 44 EUR right now). 

As I don't use bitcoins for any other purposes right now, I'd like to stop 
this bitcoin address before I forget my password or lose the private key. My 
suggestion is that we simply remove the mention of the bitcoin address from 
the website and that's it. Alternatively, someone else could set up a bitcoin 
address and continue to offer the tip jar collection for gnucash, but given 
the low volume, I'd rather suggest against that.

What do you think?

Regards,
Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash maint: Online banking: Add output of bank messages that might occasionally be received.

[Christian Stimming]

Am Freitag, 17. März 2017, 16:52:21 schrieb Geert Janssens:
> On maandag 13 maart 2017 21:33:15 CET Christian Stimming wrote:
> > Updated  via  https://github.com/Gnucash/gnucash/commit/9144edb4 
> > (commit)
> > 
> > from  https://github.com/Gnucash/gnucash/commit/4949499b (commit)
> > 
> > commit 9144edb464e10cc2809935e135d3e1499c5c841d
> > Author: Christian Stimming <christ...@cstimming.de>
> > Date:   Mon Mar 13 21:31:16 2017 +0100
> > 
> > Online banking: Add output of bank messages that might occasionally be
> > received.
> 
> Christian,
> 
> Would this also handle the use case of
> https://bugzilla.gnome.org/show_bug.cgi?id=711363
> " in SEPA transfers gnucash silently ignores error messages in the banks
> reply" ?
> 
> Or are bank error messages still hidden somewhere in the logs ?

Hi Geert,

unfortunately no, the commit concerns a different issue than the bug. The bug 
probably still exists and needs work. Sorry for that.

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Recommended Change to Author LIsting in Documentation

[Christian Stimming]

Am Samstag, 10. Dezember 2016, 22:48:48 schrieb Geert Janssens:
> Op zaterdag 10 december 2016 23:49:38 CET schreef David T. via gnucash-
devel:
> > Hi,
> > 
> > In response to seeing yet another new user sending a support request
> > directly to one of the people mentioned in the documentation, I created
> > Bug
> > 775919 (https://bugzilla.gnome.org/show_bug.cgi?id=775919
> > ) as a proposed change
> > to the way that the docs present the author attributions. In that bug, I
> > state:
> > 
> > I recommend the following:
> > 
> > 1) Remove all individual names and email addresses from the documentation
> > title page, and replace them with a general attribution to "The GnuCash
> > Documentation Team." Since the current copyright is to this entity, I
> > think
> > this is not only convenient, but also more accurate than the current list.
> > 
> > 2) Place a large note on the title page identifying gnucash-users as the
> > proper location to which to direct help requests. Section 2.4.2 is clearly
> > not prominent enough for new users.
> > 
> > 3) Retain the list of contributors that show on the title page verso. I
> > will note that this list omits email addresses. In addition, add a note
> > there about who and what the GnuCash Documentation Team is.
> > 
> > I propose: "The GnuCash Documentation Team is a self-designated group of
> > GnuCash users and developers who have volunteered to write this
> > documentation for the benefit of the broader user base. People who are
> > interested in joining this group are encouraged to express their interest
> > on the GnuCash lists (gnucash-users and gnucash-devel) for further
> > direction.” John Ralls thought that this change should be run past the
> > Devel list, and so here I am, giving it a run. As one of the named
> > contributors, I personally would prefer that my email not be included in
> > the documentation, but I defer to the general interest of the group.
> > 
> > Cheers,
> > David T.
> 
> Good idea! I agree to all your proposals.

Yes, I agree, too. Thanks for changing this!

Regards

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New Masked Calender for GnuCash

[Christian Stimming]

Dear Amin,

can you put your current code online somewhere, such as in some github fork? I 
would be interested to see which parts of gnucash you actually changed. Maybe 
in "our world-view" the change seems too incomplete, but if you say your 
change would already be an improvement for users with Jalali calendar, we 
might consider this again. But we would have to see your code for that.

Thanks!

Christian


Am Dienstag, 1. November 2016, 12:49:40 schrieb Amin Aghabeiki:
> > Right, you're overriding the display methods.  You didn't mention setting
> 
> up a preference, did you do that or are you assuming everyone in the fa_IR
> locale will want to use your Jalali calendar?
> 
> yes I add a setting in preference.
> 
> >Not that comes to mind, and besides anything more hackish isn't likely to
> 
> get merged.
> 
> Noted !
> 
> Is it true I flow the implementation of * gnucash-date-picker* and change
> to Jalalian Calender ?
> 
> Regards
> Amin
> 
> On Tue, Nov 1, 2016 at 11:54 AM, John Ralls  wrote:
> > > On Oct 31, 2016, at 8:27 PM, Amin Aghabeiki 
> > 
> > wrote:
> > > I use Mask instead of Override because I just show Jalalian Date to user
> > 
> > and rest of back-end function ( event current Gregorian Date-Picker ) work
> > with Gregorian Date ( when user select an date in Gregorian Date-Picker
> > automatically convert to Jalalian Date in cell ) . may be in technical the
> > Override is true word for this kind of  implementation.
> > 
> > Right, you're overriding the display methods.  You didn't mention setting
> > up a preference, did you do that or are you assuming everyone in the fa_IR
> > locale will want to use your Jalali calendar?
> > 
> > > About date picker , there is not any easier way ?
> > 
> > Not that comes to mind, and besides anything more hackish isn't likely to
> > get merged.
> > 
> > Regards,
> > John Ralls
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Are There Plans For A GUI Overhaul?

[Christian Stimming]

On Dienstag, 4. Oktober 2016 21:34:51 CEST Dave wrote:
> Thanks for the great responses! It does clarify quite a bit.
> 
> 
> From the looks of things, it seems that the C -- C++ port would have the
> most impact right now. It would take me awhile to get my C/C++ abilities
> ramped up again. Where's the best place to start learning about gnucash
> code? I don't know when I'd be able to start helping, but I'd at least want
> to learn what I could.

Some more pointers for learning about the internal C API: I wrote this wiki 
page http://wiki.gnucash.org/wiki/C_API in 2011 as a Summe of Code student had 
the same question. To me the explanation still seems valid. Maybe this is of 
some help here.

Regards,
Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Are There Plans For A GUI Overhaul?

[Christian Stimming]

Dear Dave,

some additional voice on this topic: I'm the author who wrote the alternative 
C++/Qt GUI program "cutecash" on top of the internal gnucash "engine" code. 
That was in 2010. To my surprise, the code (with some minor fixes that I 
committed today) still compiles, links, and runs. Just use cmake, set 
WITH_CUTECASH=on (requires libglibmm-dev ), and make. One can open a gnucash 
data file, browse through the accounts, edit a transaction and even undo the 
edit (heh!). It will crash sooner or later due to various code changes in the 
underlying object ownerships, but IMHO it might again be worth a look.

My take on the long term plans is that there are multiple plans around here. 
Even a "migration to C++" can be done on various different levels, with 
different strategies. For the cutecash experiment, I tested using the glibmm 
wrappers, which map the glib stuff to C++ sufficiently well. If asked, I would 
suggest to prefer glibmm usage over complete rewriting, and replacing glibmm-
wrapped objects by std c++ as a subsequent step. This would enable a switch to 
C++ on the GUI side somewhat earlier than requiring a complete C++ rewrite 
first. Then again, I probably won't be doing any of these work as I spend only 
very little time on gnucash currently, and those decisions typically are done 
by those people who actually invest their time in coding here. So don't take 
my advice too seriously :-)

However, a new GUI layer will for sure have to start with a very small subset 
of features. It might be a good path into more future-proof coding technology, 
but it will for sure have only a small part of the current gnucash's features. 
Maybe one can find a set of features with some small new additions that 
attracts enough attention... but I don't know how this set of features would 
have to look like.

If some people around here are looking into further GUI coding in C++, 
preferrably using Qt toolkit, I would be interested to help out every now and 
then. Feel free to contact me directly if interested.

Regards,

Christian






On Mittwoch, 5. Oktober 2016 08:44:44 CEST Dave wrote:
> Thanks, Jon and Ted.
> 
> John, you inspired my optimism. Ted, you gave me a healthy dose of caution.
> 
> :)
> 
> So, I've done SysAdmin work for a living. In this field, lines of code are
> thought of as liabilities. If I can get something done with 10 lines of
> BASH code, I'll probably do it. Almost always, there needs to be a tangible
> result to efforts within 1-2 weeks of starting. So I'm used to being ruled
> more by economy and less by elegance. If I have an elegant solution, but it
> will take time to write, I have to essentially work in secret, burning the
> midnight oil. And even then, the idea may have actually been a bad one and
> I just wasted all that time that I didn't get paid or praised for. :(
> 
> This is why I've by a Pythonista for some time. I use OOP when it makes
> sense, and don't when it doesn't. I write a working solution today, and can
> easily come back tomorrow to abstract this or that and make it maintainable
> for my future self and others. So I've learned a little about evolving a
> project, but only really in Python.
> 
> I've wanted to get back to C/C++ for some time. My main motivation was AVR
> programming, which I've done a little bit of recently. However, none of my
> background has been in larger application design and programming. It seems
> that C++ has matured quite a bit since I touched it almost a decade ago.
> When I learned it, I got as far as the STL, which seemed very advanced to
> me at the time, but very interesting at the same time as I was finishing up
> a mathematics degree and the STL seemed like a great way to create the sort
> of abstractions that would help me begin writing programs to do
> computational analysis. I probably would have gone that direction too, but
> life took a turn for me and I got into managing Linux systems and hardware
> and data centers.
> 
> 
> Ted, I promise I'll give it some time. :)  I'm not in any particular rush.
> I learn best by doing and it would be a pleasure if I could get up to speed
> in C++ again and help out GnuCash at the same time. I really just need to
> dive into C++ again. If I can't swim, then I can't swim and I'll have to
> move on. From what I've read about it, though, things like "shallow
> hierarchies" are practices I've already conceptually learned in the Python
> world. When I learned Python, I began writing it like a Java programmer. I
> have since been coaches completely away from that and classes are mostly
> used for a type of namespacing, easier testing or the like. I've also found
> that more and more, my programs are made up of generic computation over
> data. So most of what's happening is that the application gets directed by
> dictionaries that get processed to produce results. Basically, the Python
> becomes more akin to a scheme program. I've found that this produces a
> great amount of flexibility.

Re: LibOFX

[Christian Stimming]

Dear Thomas, how do you currently do the ofx import in kmymoney? Do you still 
use libofx as it is on source forge (or now GitHub) or do you have your own 
fork?

If there is any alternative available, it would be better to switch, because 
libofx has an extremely bad architecture. However, aqbanking will also cause 
significant work because it squeezes all the data through its common interface 
that was designed primarily for online banking, and it uses several pieces that 
are unnecessarily different from how the rest of the world does their coding. 
Isn't there any third alternative? After all, it is "only" about parsing an xml 
file...

No additional ideas here, sorry.

Regards, Christian 

> Am 23.09.2016 um 08:04 schrieb Thomas Baumgart :
> 
> John et al.
> 
>> On Friday 23 September 2016 06:17:04 John Ralls wrote:
>> 
>> Devs,
>> 
>> LibOFX seems to be no longer actively developed. This is a problem because
>> the OFX specification is approaching the second minor release (2.2) after
>> LibOFX's target version as well as because there is at least one bug
>> (relating to date handling) that affects GnuCash.
>> 
>> There is also a parsing problem with Chase Bank downloads because (in spite
>> of being on the OFX committee) they've chosen to make their QFX downloads
>> non-compliant.  This appears to cause LibOFX to get confused about what
>> data belongs in what struct member.
>> 
>> Martin Preuss has suggested a couple of times that we drop LibOFX and use
>> AQBanking for OFX/QFX processing. It would seem that the only viable
>> alternative would be to fork LibOFX and maintain our own version, but we're
>> already strapped for development resources so while that might allow us to
>> put out a fire now and then we're not going to be able to keep up with spec
>> changes any better than what's already happening.
>> 
>> Any other ideas?
> 
> In fact, GnuCash is not alone out there. KMyMoney is facing the same problems 
> and it makes much sense in my/our eyes to work with joint efforts in this 
> matter.
> 
> Background information: today, KMyMoney has its own implementation of the OFX 
> interface being based on LibOFX and an online interface to www.ofxhome.com 
> for 
> setup purposes. Besides that, we do support AqBanking as well, since we use 
> it 
> for HBCI interfacing. So we can switch already today, but I suspect most 
> users 
> use the former version as it is a bit more intuitive and nicer on the UI 
> front 
> compared to the AqBanking way.
> 
> Regarding development resources, the KMyMoney project is facing similar 
> problems, so simply forking LibOFX is not a real option either.
> 
> Just my 0.02 (currency less).
> 
> -- 
> 
> Regards
> 
> Thomas Baumgart
> 
> GPG-FP: E55E D592 F45F 116B 8429   4F99 9C59 DB40 B75D D3BA
> -
> There are two rules for success in life:
> Rule 1: Don't tell people everything you know.
> -
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: qof_instance_set/get_kvp cannot handle boolean?

[Christian Stimming]

Am Mittwoch, 21. September 2016, 15:35:36 schrieb Carsten Rinke:
> the information is lost that the origin is boolean. After this point I
> get lost.
> 
> What to do? Open a bug report?

I haven't worked with the kvp code in a while. As you're asking what to do, 
here's my suggestion: Try to put together some unittest code that exihibit the 
unexpected (or: erroneous) behaviour. Once you are able to put this together, 
it should become clear whether this is a bug in the kvp code and/or in your 
usage of it, possibly caused by erroneous documentation. Either way, once you 
have the unittest code that demonstrates the problematic behaviour, you can 
either open a bug report or ask here for getting this fixed.

Regards,
Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Backport proposal for "Attached file indicator"

[Christian Stimming]

Good idea. No objections. Feel free to go ahead with useful back ports. Thanks!

Christian 

> Am 13.09.2016 um 12:30 schrieb Geert Janssens :
> 
> Robert Fewell recently contributed work to the master branch to add a 
> visual indicator to transactions when a file/uri is attached, and some 
> further refinements in that area.
> 
> There is an enhancement request for this in bugzilla as well [1]
> 
> While our policy states new features should be added on the master 
> branch only, I'm considering backporting a minimal base part of Roberts 
> work to maint anyway. That is the indicator itself only. This is a 
> relatively well contained bit of gui code that's not too complicated to 
> review. I'm talking about commits 5bb53c044..5f75f106ee here. Robert 
> made more improvements, but this minimal set would greatly increase the 
> usefulness of the file association feature.
> 
> Any objections ?
> 
> Regards,
> 
> Geert
> 
> P.S. I asked for this on the bugreport as well, but didn't see any 
> responses. Probably my request got lost in the noise.
> 
> 
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=744790
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Possible way forward for Gnucash bug 721822

[Christian Stimming]

Dear Paul,

in addition to the other reply for this idea, I'd like to add some more 
thoughts from myself.

I think it is a good proposal to ask what it would take to have some specific 
bug worked on. I've reacted on such requests earlier and successfully solved 
somebody's issues as contract work. In this case I might be interested too, 
except that the bug report at hand seems to be a hard one and it might take a 
few investigations until one could state whether there is a possibility for 
improvement at all.

However, this developer list has grown more quiet over the years. Hence, even 
if that request had been sent to the list initially, there might have been 
very little reaction, too. Feel free to contact me personally if you still 
would like to follow on about this issue. Other people might have contacted 
you, too, but on the list there doesn't seem to be much additional interest. 
Sorry for that.

Best Regards,

Christian Stimming

Am Donnerstag, 1. September 2016, 07:19:17 schrieb John Ralls:
> > I'm writing to ask whether either or both of you (or perhaps other members
> > of the team) might be interested in digging deeper into this performance
> > issue <https://bugzilla.gnome.org/show_bug.cgi?id=721822> in exchange for
> > cash?  There are so far two candidates who've indicated this is causing
> > them continued frustration and might be willing to contribute something. 
> > I'm hoping there are others.
> > 
> > I believe that others might come out of the woodwork if there was a target
> > figure to aim for.  Is this something you (or other maintainers) might be
> > willing to quote on? Coming from a software background myself, I
> > understand that this can be a "how long is a piece of string" question.
> > But perhaps you could provide an initial quote which is simply to spend
> > some limited time period on further analysis - to confirm the problem for
> > yourself and then determine a solution?  A separate quote could be done
> > on the actual implementation.
> Dear Mr. Phillips,
> 
> First of all, it is considered rude in the open source community to send
> mail directly to developers rather than communicating via the mailing list.
> We have one and I've copied it on this reply for your convenience. You'll
> need to subscribe in order to post. I've already gotten spam caused by you
> in the form of two bug comments on Bugzilla promoting your company. That's
> a violation of Gnome policy. Since you're promoting your company this
> letter is spam, too.
> 
> We have tried bounty programs in the past without success, as have many
> other open source projects. Per-item payments do not seem to attract
> developers to projects. The only successful approach in that regard seems
> to be for corporations to hire developers and assign them to open-source
> work; the best known examples would be Red Hat, which pays for most of the
> development on the Gnome Desktop and its infrastructure, and Canonical,
> which publishes Ubuntu.
> 
> Aside from that, the GnuCash team has set goals for future development.
> Performance is on the list, but not in the context of the bug you're
> referring to. I don't appreciate at all your attempts to override those
> goals by attempting to bribe me.
> 
> Regards,
> John Ralls
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: SourceForge Project of the Month

[Christian Stimming]

Thanks, John, for providing answers to the sourceforge questions. Looks good to 
me!

Christian 

> Am 19.08.2016 um 19:05 schrieb John Ralls :
> 
> Here we go again. I propose the answers below to the "interview" questions. 
> Any additions or corrections?
> 
> Regards,
> John Ralls
> 
>> On Aug 18, 2016, at 3:58 PM, Joan Uy Ang  
>> wrote:
>> 
>> Hi,
>> 
>> Congratulations! You’ve been voted as the SourceForge Community Choice 
>> Project of the Month for September. Normally we do an exclusive interview 
>> with the winning project but since you already have one from last year 
>> (https://sourceforge.net/blog/march-2015-community-choice-project-of-the-month-gnucash/),
>>  we will simply release a feature of GnuCash on our blog which will link to 
>> your previous interview.
>> 
>> If however you'd like to give us any updates on the current status of your 
>> project, it would be most welcome. 
>> 
>> Some questions you could answer:
>> 
>>• What significant changes have occurred with your project since you were 
>> voted Project of the Month in March last year?
> 
> Lots of bug fixes. We're in the middle of our 3-year development cycle.
> 
>>• Have any of your project goals changed since then?
> 
> No. 
> 
>>• What project goals for the year have you achieved so far?
> 
> We have a somewhat longer horizon, two development cycles or 8 years from the 
> last release, for our current goals. To recap, those are to rewrite the core 
> library in modern C++, to better enforce the MVC pattern, and to make GnuCash 
> a database application rather than an application that can use a database as 
> an object store. The eventual user benefits will be multi-user operation over 
> the net and the ability to support more platforms--in particular mobile and 
> Chrome.
> 
>>• What can we look forward to with GnuCash?
> 
> We've already got some new features ready for the next stable series expected 
> in December of next year, and we expect that 2.8 will be a substantial 
> stability improvement thanks to the C++ rewrite.
> 
>>• Is there anything else we should know?
> 
> No, I think that's it.
>> If you could respond with answers to these questions within 7 days, that 
>> would be great.
>> 
>> 
>> Thanks,and we look forward to your response!
>> 
>> Joan Nadene
>> SourceForge Community Coordinator
> 
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Suggestions for multi-user / multi-device finance manager software?

[Christian Stimming]

Dear all,

here's a somewhat heretical question from me as a long-term gnucash  
user and developer: Gnucash no longer fulfils my requirements as a  
personal finance manager, and I was wondering whether anyone here has  
other suggestions I should try.


Here are my requirements: (1) I want to track my daily cash expenses  
of my spouse and me, using our mobile devices (two Android phones).  
(2) Additionally I want to keep track of our bank account by using the  
transaction download function of the German online banking protocol  
HBCI, so that every few days I can check the bank account balance and  
transactions. I used to do this on my desktop PC, but it doesn't  
really matter whether I do this on the desktop PC or on some mobile  
device. (3) Additionally every few weeks I want to check the cash  
flow, balances, and expense statement in detail to have an overview of  
where the money goes.


Unfortunately gnucash doesn't fit for tracking expenses on multiple  
mobile devices, let alone for checking the current balances from  
multiple devices. The gnucash data model is great, but our  
implementation of the "engine" code everywhere assumes that all data  
is held in the current device's memory. This is an obstacle against  
implementing a multi-user or multi-device editing possibility of the  
data. I tried our SQL database backend, so that the SQL database could  
be accessed remotely from multiple places. Alas, on start-up of  
gnucash, all data from the SQL database needs to be read into memory,  
effectively making it impossible to run gnucash from anywhere else  
except localhost of the SQL database host (otherwise it takes simply  
forever). My conclusion here is that unfortunately the existing  
implementation of gnucash's data access layer makes it impossible to  
run a multi-device / multi-user service on top of the data. Hence I  
will have to switch to some different software implementation.


I tried gnucash-on-android for quite some time, using this App as  
data-entering app and importing the data into desktop gnucash  
regularly. However, this extra step of importing a file into gnucash  
sucks. Theoretically, this might work if at least the  
gnucash-on-android app has the identical account frame so that the  
entered transactions can be imported without any extra double-checking  
on the gnucash side. But to my knowledge this is not implemented and I  
will always have to run the import-dialog on the gnucash side to  
ensure the correct other accounts are chosen, but this dialog sucks.


To summarize, my requirement #1 cannot be met by gnucash, even though  
the requirement #2 and #3 are still great in gnucash. What I would  
need for the multi-user / multi-device expense tracking is some sort  
of cloud service with access from multiple locations. I'm also willing  
to pay for this, but would also be interested to invest some work into  
Open Source solutions. Maybe there is some Open Source software for  
this, and the actual data hosting service is sold for some reasonable  
subscription fee. Ideas, anyone? Thanks a lot in advance.


Regards, Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Transaction Posted Time

[Christian Stimming]

Am Sonntag, 19. Juni 2016, 11:31:39 schrieb John Ralls:
> Bug 767824[1] has me thinking about this again. As I think everyone knows I
> want to change it from midnight local to 11:00AM UTC for the next version,
> but since fixing this bug also requires a scrub function at file read time
> to correct the (probably few) files with borked timestamps I'm thinking of
> doing it now.

Thanks for the info. In fact I didn't recognize your idea to change the posted 
date's time-of-day. 

Did you review bug https://bugzilla.gnome.org/show_bug.cgi?id=137017 for this? 
My take is that the "posted date" should be changed into a data type that 
doesn't have any time-of-day anymore. As long as this is not the case, we will 
IMHO always run into troubles. 

At the time bug 137017 was discussed in 2010, I decided to add the additional 
KVP slot for posted date with data type GDate. Hence, since 2010 every 
transaction has the regular posted-date timestamp (date plus time-of-day) plus 
additionally a KVP slot with the posted-date (date only), where the kvp slot's 
value will for sure contain the date value that was entered by the user, 
regardless of the time zone the program was in at the time of entering.

When you have to think about a scrub function, this additional data field 
might become handy.

However, some cases where the posted-date's time-of-day is chosen differently 
are known: 
- imported transactions that contained a time-of-day will have that time 
written in here, such as those transactions that came from an OFX file that 
was created by gnucash-on-android.
- book closing transactions contain some other time-of-day here
- other cases might exist, too.

Hence, unfortunately there are still multiple use cases of the time-of-day 
part of the posted-date. Any scrub functions that tries to map this time-of-
day to another one, or also a final scrub function that tries to map this to a 
fixed day-only data type, will have to take all those special cases into 
account. Unfortunately.

Again, I would suggest to switch the posted-date data type to a date-only 
(without time) as soon as possible, as discussed in bug 137017 and various 
discussions throughout the years.

Regards,

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: cutecash ([RFC] GTK+ 3 Migration - Alpha-grade Patchset)

[Christian Stimming]

Am Montag, 22. Februar 2016, 21:03:30 schrieb John Ralls:
> Cutecash is a demo. It implements only part of GnuCash and while Christian
> tidies things up periodically to keep it working it has never become a
> serious alternative to Gtk. I think that that's because of the MVC
> violations I mentioned earlier, but only Christian really knows. When
> Christian wrote it we were still using subversion and it wasn't feasible
> for him to put it anywhere but in the main tree. Now with Git he'd probably
> have it on his personal Github repo.

Yes, cutecash was "just" a demo. For me, it was a test case in 2010 whether 
Qt/C++ would have been a viable alternative for further UI programming. The 
result of the test case after a few weeks was that this is indeed possible. 
However, unfortunately there was zero interest around here in using Qt/C++ as 
a UI programming language (except for the single GSoC project) , and thus I 
abandoned that experiment, too. To my surprise the application still compiled 
until recently. The cutecash compile targets were silently dropped last 
december in favor of building gnucash itself by cmake, which in turn is surely 
a good step.

But no, the Qt frontend did not have problems because of MVC violations 
primarely. Instead, the main problem is that we have just such an insanely 
large set of various features which all need their little UI here and there, 
which would have to be ported one by one by one into a new UI toolkit iff one 
wants to keep each and every of them in a new version of the program. The Qt 
frontend could have been used right away if there were a demand for a faster 
UI or somebody would have implemented some cool new requested feature only in 
the Qt frontend, so that the benefit of switching would have outweighed the 
drop in feature number. But this didn't happen... even though the Qt frontend 
immediately had a full Undo/Redo feature with history, something we still 
don't have in the C register because C sucks so much. Oh well.

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

[Christian Stimming]

Am Montag, 22. Februar 2016, 23:42:24 schrieb Geert Janssens:
> > The reason why I suggested Vala instead of C++/gtkmm is that Vala is a
> > 1:1 match to the GObject system, and while gtkmm code is certainly
> > easier to write that pure GTK+/C code, they aren't really a perfect
> > match.
> 
> That does make sense indeed. On the other hand the current objective is the
> slowly migrate away from the GObject system, replacing it with true C++ OO.
> 
> One important reason for that is portability to mobile platforms (think IOS,
> Android). Some time back it looked like glib/GObject was a major roadblock
> in that direction. I don't know whether it still is, but at the time that
> was one major driving factor to switch to C++. The future GUI toolkit will
> also be evaluated in that context.

I agree that porting from GObject to C++ is a step forward. However, by now I 
have my doubts whether that effort is actually well invested anymore. Geert, 
are you sure we said C++ would help in "portability to mobile platforms"? For 
an android app, it is useless to have "the engine" in C - one needs it in Java 
anyway, and that's why Ngewi wrote a re-implementation of our data structures 
in Java for his gnucash-on-android app. I don't think a plain C++(11) plus 
some boost dependencies would actually help anything when moving the app to a 
mobile OS. Instead, C++ just tries to make the further development of the 
desktop application somewhat more realistic. But there is just such a large 
amount of code...

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [RFC] GTK+ 3 Migration - Alpha-grade Patchset

[Christian Stimming]

Hi Tobias,

thanks for the interesting work on the gnucash application! I've seen the 
other replies here, but I would like to add some remarks to your proposals 
with a somewhat different direction:

Am Sonntag, 21. Februar 2016, 20:12:58 schrieb Tobias Markus:
> While I got GnuCash pretty much working under GTK+ 3, a lot of further
> (fundamental and architectural) changes are required before even
> thinking about a release. Simply spoken, we now have GnuCash working in
> GTK+ 3, but using GTK+/Gnome 2 patterns. While it is possible to go
> down this path, the user experience will be substandard, especially
> compared to the current releases.

I think it is great to get some sort of gnucash to run under a more up-to-date 
UI toolkit. I think gtk2 is very much a dead-end, let alone those various 
custom widgets inside gnucash that are even older. However, only very little 
effort is being spent here to switch to a different toolkit. My guess is that 
UI developers who work with modern UI toolkits have long abandoned on gnucash 
development anyway... but that's just my opinion.

> A quick word on dependencies: I set the minimum GTK+ version to be 3.18
> because I didn't try to compile it with any earlier versions, but
> backporting probably isn't too hard.

In my opinion a switch to a new toolkit will be a radical step anyway, so feel 
free to pick as new a version as is convenient to the developers involved.

> Major stuff not yet migrated:
> * AqBanking uses the gwenhywfar UI library, which in turn uses GTK+ 2.
>   I have not yet looked into this.

Yes, that would need some additional effort, because the UI calls that are 
needed in the online banking code (of aqbanking) need some UI abstraction and 
its author decided to implement his own abstraction, resulting in the 
gwenhywfar UI structures. The gwenhywfar UI abstraction has implementations 
for gtk2, qt4, qt5. For gtk3 "somebody" will have to port the existing code 
there to gtk3, too... I can't tell whether any developer here will volunteer 
for this.

> Things that I recommend be dropped/removed for GnuCash 3.0:
> * Maintaining both the CMake and autotools-based build system does not
>   seem like a good idea, so drop autotools.

Yes, absolutely. Autotools has been a pain in the neck for everyone here way 
too long. I'm all for dropping it altogether, the sooner the better.

> * Rewriting the old register is not really viable or useful,
>   so drop it. Currently, either the old or the new register is compiled
>   to ease transition. (Right now, the new register can be enabled in
>   addition to the old register.)

Yes, switching to register2 or whatever the more up-to-date version is called 
should also happen better sooner than later. However, this will mean a new 
version will not be as feature-complete as the previous version. I doubt 
whether this is a good goal in any case. Maybe we should be courageous enough 
to just call the old gtk2 code a dead end, including all of its beloved 
features here and there, and just say we will spend our development time only 
in new modern code.

> * The dynamic module system (based on GModule) is a nice idea, but the
>   benefits are dubious at the moment. While the dynamic loading of all
>   the standard modules incurs a heavy startup delay, there is no
>   reason why a user would not want to load all the built-in modules.

Although most of the current modules are used always and hence better linked 
in statically, there is still some benefit from the module system: Parts of 
our features imply an additional large dependency tree, e.g. aqbanking, or 
postgresql. Making them a module will enable distributions to package them in 
separate packages, so that users will need the aqbanking dependencies only if 
they install the gnucash-aqbanking module, or for postgresql the same. Hence, 
I think gnucash should keep some sort of plugin system in any case.

However, currently due to guile's module loading we have additional 
requirements on the way modules are used. Others here can explain this better 
for sure.

> Major Changes that I highly recommend for a GnuCash 3.0 release:
> * Writing GObject-based code (i.e. GTK+ code) in C is a very cumbersome
>   and boilerplate-ish process. Vala makes it possible to write GObject
>   code in a very concise way

I agree whole-heartedly that writing UI code in C sucks, royally. For me this 
has been the major reason to keep away from further gnucash development, 
unless I needed some feature myself really badly. I mean, we have 2016. UI 
programming should be done in some programming language that is good for this 
job. C is not. Pretty much any other high-level programming language will do a 
better job here. I don't know Vala so far and I can't judge whether the 
benefits will outweigh enough the (presumed) rather small user base. C++, 
C#/Mono, or Java are known to me and would do the job well enough, but other 
languages are fine, too. Just get away from C w.r.t. UI 

Re: HBCI banking test

[Christian Stimming (mobil)]

I don't the test servers from the 2005 instructions are still operating. Sorry.

Regards, Christian

Am 10. Dezember 2015 19:23:12 MEZ, schrieb Per Johansson :
>Hello all.
>
>I was trying to test HBCI with the instructions found here:
>https://lists.gnucash.org/pipermail/gnucash-devel/2005-January/012520.html
>
>But after entering the PIN I get in the log (copy from it does not work
>
>for me so I have to type)
>
>Waiting for response
>...and then immediately...
>Error receiving response (503)
>AqHBCI finished.
>Operation finished, you can now close this window.
>
>Is this service still working?
>
>
>
>
>-- 
>Per Johansson
>Skrakvägen 1 C 20
>AX-22100 Mariehamn
>ÅLAND ISLANDS
>___
>gnucash-devel mailing list
>gnucash-devel@gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel

--
Sent from mobile.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: UserVoice integration in GnuCash Android

[Christian Stimming (mobil)]

Hi ngewi, sure,  this can of course be done. I will give you admin rights so 
that you can add them yourself.

Regards, Christian

Am 4. November 2015 09:56:39 MEZ, schrieb Ngewi Fet <nge...@gmail.com>:
>Hi Christian,
>Would it be possible to add some of the other Android app core devs to
>UserVoice.
>It would be of great help to have them contributing there too with
>responses, triaging etc.
>Let me know and I can send you the email addresses.
>
>Regards,
>Ngewi
>
>On Wed, Sep 16, 2015 at 10:27 AM, Christian Stimming (mobil) <
>christ...@cstimming.de> wrote:
>
>> Oh, and the "article" feature is not used at all, too. Some work was
>> started, but nothing was ever published. Feel free to experiment with
>that
>> feature for your app, too.
>>
>> Regards, Christian
>>
>> Am 16. September 2015 10:15:39 MESZ, schrieb Ngewi Fet
><nge...@gmail.com>:
>>>
>>> Hi all,
>>> I have had a quick look at the UserVoice setup.
>>>
>>> @John, I think it is possible to manage both GnuCash and GncA under
>the
>>> same account with the use of Forums.
>>>
>>> Right now there is just one default forum, but we could easily add
>another
>>> for GnuCash Android (and rename the existing one to be specific to
>desktop).
>>> There are also separate article/knowledge base topics and we could
>add one
>>> for GnuCash Android.
>>>
>>> Another point is that I expect most of the GnuCash Android UV
>interaction
>>> to come through the app itself (not the website).
>>> The SDK integration allows to already specify which forum and topic
>it
>>> should default to, so feedback would come in already properly
>categorized.
>>>
>>> So if we are in agreement, I will go ahead and integrate it in the
>app and
>>> create the new forum and topic category on the UV site.
>>>
>>> Regards,
>>> Ngewi
>>>
>>> On Wed, Sep 16, 2015 at !
>>>  9:39 AM,
>>> Ngewi Fet <nge...@gmail.com> wrote:
>>>
>>>  Thanks Christian!
>>>>
>>>>  On Wed, Sep 16, 2015 at 8:10 AM, Christian Stimming (mobil) <
>>>>  christ...@cstimming.de> wrote:
>>>>
>>>>  Hi Ngewi, indeed I have the admin rights for the uservoice
>presence. We
>>>>>  don't have to pay - at the time, I asked for an upgrade and they
>granted it
>>>>>  to us as free software for free.
>>>>>
>>>>>  I think uservoice is a very good service if you (or gnucash)
>really wants
>>>>>  to be more user accessible . The presentation of information is
>much more
>>>>>  user suited, unlike traditional mailing lists or such. Hence, I
>would
>>>>>  greatly appreciate if you can make good use of this, too. I'll
>add you with
>>>>>  admin rights as soon as I get!
>>>>>   around
>>>>> some PC, which might take another day
>>>>>
>>>>>  or so.
>>>>>
>>>>>  Best regards, Christian
>>>>>
>>>>>  Am 14. September 2015 19:30:22 MESZ, schrieb Ngewi Fet
><nge...@gmail.com
>>>>>
>>>>>> :
>>>>>>
>>>>>
>>>>>  Hello all,
>>>>>>  I would like to integrate UserVoice for support and feedback
>into the
>>>>>>  GnuCash Android app. UserVoice has an SDK for integration into
>apps and it
>>>>>>  would greatly benefit the provision of support and feedback in
>the app.
>>>>>>
>>>>>>  I read on some old mailing list emails that GnuCash has a full
>subscription
>>>>>>  for UserVoice.
>>>>>>
>>>>>>  Can we integrate it into the Android app, and who can provide me
>access to
>>>>>>  UserVoice?
>>>>>>
>>>>>>  Regards,
>>>>>>  Ngewi F.
>>>>>> --
>>>>>>
>>>>>>
>>>>>>  gnucash-devel mailing listgnucash-de...@gnucash.org
>>>>>>  https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>>>>
>>>>>
>>>>>
>>>>>  --
>>>>>  Sent from mobile.
>>>>>
>>>>
>>>>
>>> --
>>>
>>> gnucash-devel mailing list
>>> gnucash-devel@gnucash.org
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>>
>>>
>> --
>> Sent from mobile.
>>

--
Sent from mobile.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Recommendations on Coding programs

[Christian Stimming (mobil)]

I like QtCreator a lot. For gnucash this requires to create a list of all files 
that belong to the project, such as
  find . -name *.[hc] > .files
I'm not completely sure about the file name for the list, though.

Regards, Christian

Am 18. Oktober 2015 09:44:27 MESZ, schrieb Colin Law :
>On 18 October 2015 at 00:06, Matt Graham 
>wrote:
>> G’day all,
>>
>> Now that I finally have myself set up to be able to view, edit and
>test the gnucash sources, I have come across the limitation of using
>text editors (using nano at the moment...) to code. Can anyone
>recommend a good program for doing coding for Gnucash? I’m mainly
>looking at the C side of things rather than guile, but a program that
>can do multiple types of code would be useful. Preferably ones that are
>supported on both windows and linux.
>
>I like jEdit which is available on Win and Linux.
>
>Colin
>
>___
>gnucash-devel mailing list
>gnucash-devel@gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Online banking

[Christian Stimming]

Dear Paul,

I don't think it is possible or useful to think of "yet another generic API". 
Instead, I would suggest the API of aqbanking is indeed the 4th or 5th 
iteration on building an API from the application to online banking functions. 
Also, I would strongly suggest against programming a website scraper - it will 
give you very little gain for very large effort. If your bank doesn't have 
anything else besides a website, in fact the easiest solution is to find a 
different bank that has some standard protocol such as OFX. Sorry for that.

Regards,

Christian

Am Montag, 28. September 2015, 00:24:02 schrieb Paul Tirk:
> Hi,
> 
> no, I know that it's not a website scraper but in fact I want to program
> one ;) And I assume the developer of AqBanking will not just add any set
> of api-calls/https-requests for every other bank to his library.
> 
> So I was thinking about a generic interface in Gnucash to simplify
> things because I also think it would be beneficial for future
> development to not depend completely and only on AqBanking like it is
> now because it seems that (at least in Europe) the trend is going away
> from standards (except HBCI in Germany) towards bank-specific APIs (most
> of them are https-requests sent).
> 
> Regards,
> 
> Paul
> 
> Am 27.09.2015 20:55, schrieb Derek Atkins:
> > Hi,
> > 
> > Yes, the GnuCash AqB backend is tied to AqB.  However...
> > 
> > AqBanking is licensed under the GPL, and already has multiple modules
> > that
> > implement HBCI, OFX, OFX-DC, MT940, CSV, ...
> > 
> > So, why do you feel that you couldn't add a new module to that?
> > 
> > Do you know what online banking protocol your bank supports?  Or do you
> > have the mistaken impression that it's a website scraper?
> > 
> > -derek
> > 
> > On Sun, September 27, 2015 2:23 pm, Paul Tirk wrote:
> >> Hello!
> >> 
> >> I was thinking about adding online banking support for a bank which
> >> has
> >> no HBCI (and is not supported by AqBanking). After some time browsing
> >> the source of gnucash and AqBanking I realized that the online banking
> >> functionality of gnucash is tightly coupled to AqBanking which in turn
> >> has a restricted license and it actually doesn't look easy to add
> >> different banks.
> >> 
> >> Are there plans on a clean online banking API in gnucash which could
> >> enable developers to include different banking protocols? If not I
> >> would
> >> be interested in contributing but I have no idea where to start. Could
> >> somebody maybe give me a hint about this?
> >> 
> >> My idea would be: the current menu entries for online banking are
> >> fine,
> >> it would just need a general user/account setup which could allow the
> >> current AqBanking accounts as well as other "plugins/modules" which
> >> can
> >> then be triggered as it is working right now with only AqBanking.
> >> 
> >> I hope I made myself clear and thanks in advance,
> >> 
> >> Paul
> >> ___
> >> gnucash-devel mailing list
> >> gnucash-devel@gnucash.org
> >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> 
> ___
> gnucash-devel mailing list
> gnucash-devel@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: UserVoice integration in GnuCash Android

[Christian Stimming (mobil)]

Hi Ngewi, indeed I have the admin rights for the uservoice presence. We don't 
have to pay - at the time, I asked for an upgrade and they granted it to us as 
free software for free. 

I think uservoice is a very good service if you (or gnucash) really wants to be 
more user accessible . The presentation of information is much more user 
suited, unlike traditional mailing lists or such. Hence, I would greatly 
appreciate if you can make good use of this, too. I'll add you with admin 
rights as soon as I get around some PC, which might take another day or so.

Best regards, Christian

Am 14. September 2015 19:30:22 MESZ, schrieb Ngewi Fet :
>Hello all,
>I would like to integrate UserVoice for support and feedback into the
>GnuCash Android app. UserVoice has an SDK for integration into apps and
>it
>would greatly benefit the provision of support and feedback in the app.
>
>I read on some old mailing list emails that GnuCash has a full
>subscription
>for UserVoice.
>
>Can we integrate it into the Android app, and who can provide me access
>to
>UserVoice?
>
>Regards,
>Ngewi F.
>___
>gnucash-devel mailing list
>gnucash-devel@gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel

--
Sent from mobile.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: UserVoice integration in GnuCash Android

[Christian Stimming (mobil)]

Oh, and the "article" feature is not used at all, too. Some work was started, 
but nothing was ever published. Feel free to experiment with that feature for 
your app, too.

Regards, Christian

Am 16. September 2015 10:15:39 MESZ, schrieb Ngewi Fet <nge...@gmail.com>:
>Hi all,
>I have had a quick look at the UserVoice setup.
>
>@John, I think it is possible to manage both GnuCash and GncA under the
>same account with the use of Forums.
>
>Right now there is just one default forum, but we could easily add
>another
>for GnuCash Android (and rename the existing one to be specific to
>desktop).
>There are also separate article/knowledge base topics and we could add
>one
>for GnuCash Android.
>
>Another point is that I expect most of the GnuCash Android UV
>interaction
>to come through the app itself (not the website).
>The SDK integration allows to already specify which forum and topic it
>should default to, so feedback would come in already properly
>categorized.
>
>So if we are in agreement, I will go ahead and integrate it in the app
>and
>create the new forum and topic category on the UV site.
>
>Regards,
>Ngewi
>
>On Wed, Sep 16, 2015 at 9:39 AM, Ngewi Fet <nge...@gmail.com> wrote:
>
>> Thanks Christian!
>>
>> On Wed, Sep 16, 2015 at 8:10 AM, Christian Stimming (mobil) <
>> christ...@cstimming.de> wrote:
>>
>>> Hi Ngewi, indeed I have the admin rights for the uservoice presence.
>We
>>> don't have to pay - at the time, I asked for an upgrade and they
>granted it
>>> to us as free software for free.
>>>
>>> I think uservoice is a very good service if you (or gnucash) really
>wants
>>> to be more user accessible . The presentation of information is much
>more
>>> user suited, unlike traditional mailing lists or such. Hence, I
>would
>>> greatly appreciate if you can make good use of this, too. I'll add
>you with
>>> admin rights as soon as I get around some PC, which might take
>another day
>>> or so.
>>>
>>> Best regards, Christian
>>>
>>> Am 14. September 2015 19:30:22 MESZ, schrieb Ngewi Fet
><nge...@gmail.com
>>> >:
>>>
>>>> Hello all,
>>>> I would like to integrate UserVoice for support and feedback into
>the
>>>> GnuCash Android app. UserVoice has an SDK for integration into apps
>and it
>>>> would greatly benefit the provision of support and feedback in the
>app.
>>>>
>>>> I read on some old mailing list emails that GnuCash has a full
>subscription
>>>> for UserVoice.
>>>>
>>>> Can we integrate it into the Android app, and who can provide me
>access to
>>>> UserVoice?
>>>>
>>>> Regards,
>>>> Ngewi F.
>>>> --
>>>>
>>>> gnucash-devel mailing list
>>>> gnucash-devel@gnucash.org
>>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>>>
>>>>
>>> --
>>> Sent from mobile.
>>>
>>
>>
>___
>gnucash-devel mailing list
>gnucash-devel@gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel

--
Sent from mobile.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: UserVoice integration in GnuCash Android

[Christian Stimming (mobil)]

Hi Ngewi, yes, you can use additional forums for the android version and that 
should be sufficiently separate from desktop gnucash.

Additionally, feel free to experiment with the "ticket" feature there. We don't 
use that so far, but maybe it is useful for you. 

Regards, Christian

Am 16. September 2015 10:15:39 MESZ, schrieb Ngewi Fet <nge...@gmail.com>:
>Hi all,
>I have had a quick look at the UserVoice setup.
>
>@John, I think it is possible to manage both GnuCash and GncA under the
>same account with the use of Forums.
>
>Right now there is just one default forum, but we could easily add
>another
>for GnuCash Android (and rename the existing one to be specific to
>desktop).
>There are also separate article/knowledge base topics and we could add
>one
>for GnuCash Android.
>
>Another point is that I expect most of the GnuCash Android UV
>interaction
>to come through the app itself (not the website).
>The SDK integration allows to already specify which forum and topic it
>should default to, so feedback would come in already properly
>categorized.
>
>So if we are in agreement, I will go ahead and integrate it in the app
>and
>create the new forum and topic category on the UV site.
>
>Regards,
>Ngewi
>
>On Wed, Sep 16, 2015 at 9:39 AM, Ngewi Fet <nge...@gmail.com> wrote:
>
>> Thanks Christian!
>>
>> On Wed, Sep 16, 2015 at 8:10 AM, Christian Stimming (mobil) <
>> christ...@cstimming.de> wrote:
>>
>>> Hi Ngewi, indeed I have the admin rights for the uservoice presence.
>We
>>> don't have to pay - at the time, I asked for an upgrade and they
>granted it
>>> to us as free software for free.
>>>
>>> I think uservoice is a very good service if you (or gnucash) really
>wants
>>> to be more user accessible . The presentation of information is much
>more
>>> user suited, unlike traditional mailing lists or such. Hence, I
>would
>>> greatly appreciate if you can make good use of this, too. I'll add
>you with
>>> admin rights as soon as I get around some PC, which might take
>another day
>>> or so.
>>>
>>> Best regards, Christian
>>>
>>> Am 14. September 2015 19:30:22 MESZ, schrieb Ngewi Fet
><nge...@gmail.com
>>> >:
>>>
>>>> Hello all,
>>>> I would like to integrate UserVoice for support and feedback into
>the
>>>> GnuCash Android app. UserVoice has an SDK for integration into apps
>and it
>>>> would greatly benefit the provision of support and feedback in the
>app.
>>>>
>>>> I read on some old mailing list emails that GnuCash has a full
>subscription
>>>> for UserVoice.
>>>>
>>>> Can we integrate it into the Android app, and who can provide me
>access to
>>>> UserVoice?
>>>>
>>>> Regards,
>>>> Ngewi F.
>>>> --
>>>>
>>>> gnucash-devel mailing list
>>>> gnucash-devel@gnucash.org
>>>> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>>>>
>>>>
>>> --
>>> Sent from mobile.
>>>
>>
>>
>___
>gnucash-devel mailing list
>gnucash-devel@gnucash.org
>https://lists.gnucash.org/mailman/listinfo/gnucash-devel

--
Sent from mobile.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: make fails on master

[Christian Stimming]

Aren't you just missing an #include string.h which is needed for strdup() 
... ?

Regards,

Christian

Am Sonntag, 14. Juni 2015, 19:42:55 schrieb John Ralls:
  On Jun 14, 2015, at 6:44 PM, Alex Aycinena alex.aycin...@gmail.com
  wrote:
  
  John,
  
  On Sun, Jun 7, 2015 at 1:34 PM, John Ralls jra...@ceridwen.us 
mailto:jra...@ceridwen.us wrote:
   On Jun 7, 2015, at 12:38 PM, Derek Atkins de...@ihtfp.com
   mailto:de...@ihtfp.com wrote:  
   On Sun, June 7, 2015 3:02 pm, John Ralls wrote:
   Alex,
   
   Turns out that for some flavors of GCC -std=gnu99 is required for
   strdup
   to be provided. I’d made the default c99, which in those cases doesn’t
   support it, hence the error.
   
   Fixed and pushed.
   
   Why are we using strdup() and not g_strdup()?
  
  Oversight? It’s used in several places. The earliest I found was a5d4c7cf
  from 2004.
  
  Regards,
  John Ralls
  
  
  I upgraded My Fedora 20 machine to Fedora 22, which came out a few weeks
  ago, and got the same problem again. In order to make sure it was not my
  new build environment, I cloned a new gnucash, checked out maint, and was
  able to make, make-clean, and make-install OK. So the new F22 build
  environment is OK. But when I checked out master on the new clone and
  wiped out my build directory and tried make again, I got the same error,
  as follows:
  
  /home/gnucash-dev/gitcheckouts/gnucash-new/src/app-utils/gfec.c: In
  function 'gfec_catcher':
  /home/gnucash-dev/gitcheckouts/gnucash-new/src/app-utils/gfec.c:60:25:
  error: implicit declaration of function 'strdup'
  [-Werror=implicit-function-declaration] 
   *(char**)data = strdup(Guile error: Too many recursions in error
   catch handler.);  
   ^


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: CuteCash build errors -no rule to make target... iso-currencies-to-c.in

[Christian Stimming]

Hi Mark,

thanks for the feedback about the cutecash build system. In fact, this build 
error was introduced this January as the auto-generation of some files was 
changed on the Makefile.am side, but not on the cmake side. This isn't much of 
a big problem. I've just committed the fix and you should be able to build 
cutecash again. Have fun with this!

Contrary to what other voices here said, the cutecash experiment is still 
able to compile and also run. To my surprise, it takes only very little effort 
to keep it up to date in terms of the build system. It still serves to show 
various things:

- The cmake build system could be used to build gnucash as well. For cutecash, 
it builds the first 20% of gnucash, but it could be extended to build all of 
gnucash just as well. Cmake has some advantages over automake such as it 
configures way faster; however, migrating the existing build system is a lot 
of work for little benefit, so we don't discuss this so far.

- Cutecash shows it is possible to run a C++ GUI toolkit on top of the C code 
of the gnucash engine, using some of the glibmm/gtkmm wrappers

- Cutecash shows that some new features such as Undo/Redo can be implemented 
rather easily once we get away from C

- Cutecash shows that another GUI on top of the gnucash engine is possible, so 
that some new features are available (Undo) while the minimal subset of 
existing features can be maintained. Of course, 95% of the features in main 
gnucash cannot be found in a new GUI, as each feature requires a lot of GUI 
code implementation, which nobody will want to do.

That's why I still keep the cutecash experiment in a state where it can be 
compiled and run. Except for the rare occasions when the build system changes, 
which is what you ran into.

Regards,

Christian


Am Montag, 20. April 2015, 14:24:19 schrieb Mark Murray:
 Hi,
 
 I am trying to build cuteCash, but get the following make errors:
 
 make[2]: *** No rule to make target
 `../src/engine/iso-currencies-to-c.in', needed by
 `src/engine/iso-4217-currencies.c'.  Stop.
 make[1]: *** [src/engine/CMakeFiles/engine.dir/all] Error 2
 make: *** [all] Error 2
 
 CMakeList.txt for src/engine has the following
 
 # Command to generate the iso-4217-currencies.c file
 SET (ISO_4217_C ${CMAKE_CURRENT_BINARY_DIR}/iso-4217-currencies.c)
 ADD_CUSTOM_COMMAND (
   OUTPUT ${ISO_4217_C}
   DEPENDS iso-4217-currencies.scm iso-currencies-to-c.in
   COMMAND
 ${GUILE_EXECUTABLE} -s
 ${CMAKE_CURRENT_SOURCE_DIR}/iso-currencies-to-c.in
 ${CMAKE_CURRENT_SOURCE_DIR}
 )
 # Add dependency on iso-4217-currencies.c
 SET_SOURCE_FILES_PROPERTIES (gnc-commodity.c PROPERTIES OBJECT_DEPENDS
 ${ISO_4217_C})
 
 However, the only currency files in the directory are:
 iso-4217-currencies.xml, and
 iso-currencies-to-c.xsl
 
 I'm new to CMake, so would appreciate any guidance to solve this
 problem.
 I'm working on a Linux box (Linux Mint 17).
 git pull is up-to-date.
 
 Thanks
 Mark
 
 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Version Numbering

[Christian Stimming]

Am Montag, 23. März 2015, 09:20:56 schrieb John Ralls:
  Instead,
  from my point of view we should consider incrementing our first version
  number from 2 to 3 at some not-too-distant point in the future, as soon
  as this number change would represent something useful for the user. For
  example, a gnucash version that is multi-user-enabled would be enough of
  a reason to call that version 3.something. Note that I don't care at
  all which technology was used to achieve this feature.
 
 Good point, but where do we draw the line? Do we follow Firefox and use only
 two numbers, so we have a new first-digit release every 3 years?

John,

I also don't have a final answer to this question. The important point from me 
is that we shouldn't be more shy than necessary w.r.t. increasing the first-
digit number. My criterion would be the vague If something important changes 
that is important to many users, and indeed that's rather vague and needs to 
be revisited each time we start the next stable series.

In case of 2.4 - 2.6: From what I recall there were no real important change 
for many users, so in that case increasing only the second digit was just 
fine. 

If next time we have the same situation - fine, let's go to 2.8. 

But after that, I would suggest to be somewhat more reluctant to go to a two-
digit minor number, i.e. before switching to 2.10 we should rather switch to 
3.0 even if the set of new feature is again in a similar range as it was in 
the 2.4-2.6 switch. A two-digit minor number makes things more confusing than 
necessary and I would rather like to avoid that. But that's a future 
discussion and not today's topic.

Maybe the 2.2-2.4 switch had enough changes so that we could have gone to 3.0 
instead. But that's long ago and just hypothetical.

Yes, the points you raise can give valid arguments: multi-user; file 
compatibility; script API. To summarize, I think we do not have to draw clear 
lines right now, but can live with a rather vague description of our policy, 
and make the actual decisions about the numbering of the next stable series 
right at the point when we know what will be in there.

Regards,

Christian

 
 I don't think that there's any argument that multi-user justifies a new
 first-digit number, but I also think it's pretty optimistic to plan for it
 in the next major release. Unless you're advocating for the Firefox model
 (minus the every-few-months bit, we don't have the resources for that),
 what else do you think might justify a first-number change? Do you think
 that 2.6 should have been 3.0?
 
 What about API breaks in the Scheme and Python bindings? Not something most
 users care about, but folks with custom scripts sure do. We've always said
 that we don't guarantee API stability between major versions, but we also
 promote the bindings pretty heavily.
 
 I suspect that users care most about file compatibility. We've done pretty
 well on that through the 2.x series, but along with multi-user will come a
 shift from default XML to default SQL, and going forward from that we'll
 want to normalize the schema, especially to move stuff out of slots.
 
 The two combined would be a useful guideline: first-number changes mean that
 you'll have to revisit your scripts or your database will be upgraded so
 that it's not readable by the previous version except the closeout release.
 
 Regards,
 John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Version Numbering

[Christian Stimming]

Dear Chris,

thanks for bringing up this question. In fact there are different views on 
this topic around. I consider the version number as part of our marketing 
communication to potential users. As such, the first-most number of our 
software should represent something that is meaningful to the users. And it 
should change as soon as something major that is meaningful to the users is 
changed.

I've simply seen enough users who can't tell whether there is a version 2.2 or 
2.4 or 22 or 24 or whatever of gnucash on their computer. They could for sure 
tell whether they have version 2-something or 3-something. But the next number 
is just magnitudes less important. Hence, we should use the important part of 
the version number as our product marketing in a useful way.

Because of this, I am against the idea that we have to stick to the first 
number 2 unless we have a major architectural change or some other whatever 
major technological yadda yadda change inside gnucash. Instead, from my point 
of view we should consider incrementing our first version number from 2 to 3 
at some not-too-distant point in the future, as soon as this number change 
would represent something useful for the user. For example, a gnucash version 
that is multi-user-enabled would be enough of a reason to call that version 
3.something. Note that I don't care at all which technology was used to 
achieve this feature.

Thing is, we can expect all users to tell whether their gnucash version number 
starts with 2 or 3. But the number after that is already something that can be 
remembered by only a minority of the users. Why should we easily let go of the 
powerful communication tool to tell whether someone has a newer or older 
version of the software? Instead, IMHO we should keep in mind to switch to 
version 3.x within the next 1-3 years, as soon as we have enough user-visible 
to justify this change.

Regards,

Christian

Am Sonntag, 22. März 2015, 11:51:57 schrieb Chris Good:
  we want to project for user recruitment. Enormous, Earth-shaking, and
  so on sound silly. How about !
  
   Global or Fundamental to indicate that the way the program works is
  
  different from before?
  
  Regards,
  John Ralls
 
 Thanks for picking up my 'faux pas' re odd/even numbering (temporary brain
 fade I hope).
 
 I've done a little research on version numbering best practices.
 http://en.wikipedia.org/wiki/Software_versioning is quite interesting.
 
 Some of the commonly used version numbering schemes include:
 
 Major.Minor.[buildno|bugfix|revision|patch]
 Framework.Major.Minor
 
 I totally agree with Geert that the 2nd level should be Major, not Minor.
 John mentioned 'architectural changes' and I quite like
 Architecture.Major.Minor although I prefer Framework.Major.Minor.
 
 What does everybody think?


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Bug in master: Income statement report crash?

[Christian Stimming]

Just a plain ol' bugreport:

Running the income statement report in current master (d4e5bdc3) does not 
bring up the report, but instead the scheme error Wrong number of arguments 
to xaccQueryAddDescriptionMatch, trace below. Has anyone observed this 
before? Thanks for any pointer.

Regards,

Christian


727: 18* (set! doc (if template (let* (# # # ...) (if # # ...) ...) ...))
 727: 19* (if template (let* (# # # ...) (if # # ...) ...) ...)
 728: 20  (let* (# # # #) (if # # #) (gnc:report-set-ctext! report html) ...)
 730: 21* [profit-and-loss-renderer #]
In /home/cs/usr/share/gnucash/scm/gnucash/report/standard-reports/income-
statement.scm:
 729: 22  [income-statement-renderer-internal # Profit  Loss]
In unknown file:
...
   ?: 23  (letrec (# #) (gnc:html-document-set-title! doc #) (if # # #) ...)
In /home/cs/usr/share/gnucash/scm/gnucash/report/standard-reports/income-
statement.scm:
 439: 24* (if (null? accounts) (gnc:html-document-add-object! doc #) (let* # 
#))
 451: 25  (let* (# # # # ...) (letrec # # # ...))
In unknown file:
   ?: 26  (letrec (#) (set! revenue-closing #) (set! expense-closing #) ...)
In /home/cs/usr/share/gnucash/scm/gnucash/report/standard-reports/income-
statement.scm:
 517: 27* (set! revenue-closing #)
 518: 28* [gnc:account-get-trans-type-balance-interval-with-closing # # # ...]
In /home/cs/usr/share/gnucash/scm/report-utilities.scm:
 747: 29  (let* (#) (map # #) total)
 748: 30* [map #procedure #f (split) ...
 756: 31*  [gnc:account-get-trans-type-splits-interval (# # # ...) (# # # ...) 
...]
 902: 32   (if (null? account-list) (quote ()) ...)
 906: 33   (let* (# # # ...) (qof-query-set-book query #) ...)
 924: 34*  (if (or matchstr closing) (begin (set! query2 #) (if matchstr #) 
...))
 925: 35   (begin (set! query2 #) (if matchstr #) (if closing #) ...)
 927: 36*  (if matchstr (xaccQueryAddDescriptionMatch query2 matchstr ...))
 927: 37   [xaccQueryAddDescriptionMatch # Abschlussbuchungen #f ...]
/home/cs/usr/share/gnucash/scm/report-utilities.scm:927:25: In procedure 
xaccQueryAddDescriptionMatch in expression (xaccQueryAddDescriptionMatch 
query2 matchstr ...):
/home/cs/usr/share/gnucash/scm/report-utilities.scm:927:25: Wrong number of 
arguments to xaccQueryAddDescriptionMatch

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

What are our canonical git repository addresses?

[Christian Stimming]

I just found out that I've accidentally pushed some gnucash-on-windows commit 
to the wrong remote repository, namely the github one instead of the one on 
gnucash.org. Subsequently, my change seems to be dropped the next time someone 
committed to gnucash.org.

Now I wanted to check whether I'm really using the correct git repo addresses, 
both for read-only access and of course also for write access. However, I 
didn't find any place in the wiki that clearly lists the various repositories 
that exist. In particular, I didn't see any mention of the gnucash-on-windows 
repo in any wiki page. Did I miss this? Can please someone add a short 
directory of our actual upstream repos somewhere in the wiki? Thanks a lot.

By the way, in case of gnucash-on-windows, how do we distinguish the windows 
build instructions for gnucash's maint and master branch? Or does the 
install-script work for both? This I can't quite believe, as maint and master 
have already diverged in the requirements and their versions as set in the 
file defaults.sh. But how is this handled? Thanks for some explanation here.

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: git always make some files modified

[Christian Stimming]

Am Samstag, 27. Dezember 2014, 09:22:12 schrieb John Ralls:
  Following files are always marked as modified in my repos when swtich
  between maint and master back and forth, sometimes these modified
  files prevent git from git-checkout, meanwhile they cannot be stashed
  or checked out with `checkout --`.
  
  modified:   doc/README-de.win32-bin.txt
  modified:   doc/README-fr.win32-bin.txt
  modified:   doc/README-it.win32-bin.txt
  modified:   doc/README-nl.win32-bin.txt
  modified:   doc/README-zh_CN.win32-bin.txt
  modified:   doc/README-zh_TW.win32-bin.txt
  modified:   doc/README.win32-bin.txt
  modified:   doc/examples/downloaded.mt940
  
  I searched archived mails in gnucash-devel, set `git config --global
  core.autocrlf input`. However, this only affects the first time when
  checkout branch from master to maint. Above issue happens again when
  checkout back to master from maint. Really confused, have no idea why
  this happens and not sure whether it's an CRLF-related issue.
 
 Those files' line endings are supposed to be controlled by .gitattributes,
 which overrides the core.autocrlf setting. 

Yes, the .gitattributes file is the other source of CRLF-related settings. I 
think 1-2 years ago it took me a while to discover how to get rid of this same 
modified: doc/README...txt message. I got stuck in those message when 
switching between master and some older branch such as maint or even older.

My solution is as follows:

- Remove the .gitattributes file
- Commit this removal into git (which makes the modified-message go away),
- And reset the master branch back to the original master.

It still sounds a bit funny to me, but this somehow works to get rid of those 
error message.

 README.win32-bin.txt and downloaded.mt940 don't have BOMs.

Yes, byte order mark (BOM) is the wrong keyword here - we are only talking 
about line endings, not byte order.

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

gnucash will be Project of the Week on SourceForge

[Christian Stimming]

Dear all,

Sourceforge notified us that gnucash is going to be featured as one out of 
several projects of the week next week, see below.

In case anyone is up to add some friendly welcome text on our own websites, 
feel free to do so...

Regards,

Christian

--  Weitergeleitete Nachricht  --

Betreff: Congratulations! Your project is a Project of the Week on 
SourceForge!
Datum: Freitag, 14. November 2014, 15:12:40
Von: Elizabeth Daniels edani...@slashdotmedia.com
An: Community Team communityt...@slashdotmedia.com

Hello,

My name is Elizabeth Daniels and I am the senior content editor for
SourceForge. I am writing to inform you that your project is a featured
Project of the Week and will be listed on the front page of our site next
week. This means your project may be included in this month's Community
Project of the Month vote, depending on the number of downloads it gets.

Projects are chosen based on a variety of considerations, such as recent
releases, interesting blog activity, or other related things. Front page
features tend to result in increased traffic to your project page so you
may want to take this opportunity to make sure you have the latest project
description, screenshots, and project logo.

And, here is the link (*that will go live Monday*) to the blog post
notifying the community of your accomplishment:

http://sourceforge.net/blog/projects-of-the-week-november-17-2014

Here are all of the Projects of the Week for November 17, 2014:

simutrans
gnucash
roundcubemail
gnuplot
cyberfox
winpenpack
osxportableapps
clamav
filebot
Thanks for being part of the SourceForge community! And best of luck.

-- 
Elizabeth Daniels
Senior Content Editor
SourceForge.net http://sourceforge.net | 415.713.0229
-
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: python GnuCash interface to SQL backend

[Christian Stimming]

Dear Sébastien,

I really try not to be rude, but a little bit it seems to me as if you don't 
accept no as an answer here. You asked whether the gnucash developers 
support an alternative SQL access layer written in python from scratch, and 
John's and other answers clearly said no. What else are you looking for?

John as already outlined many important aspects about our object model. In 
case you haven't see this so far, some current documentation is also here 
http://wiki.gnucash.org/wiki/C_API and the linked Entity-Relationship 
Diagram there, http://wiki.gnucash.org/wiki/images/8/86/Gnucash_erd.png . 

But let's just make this clear: You asked whether your idea would be endorsed 
and supported by us, and the answer was clearly a no. If you like to 
continue your idea, feel free to do so. But just don't repeatedly discuss here 
whether we want to change our answer (at this point in time). Thanks!

Regards,

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Working example of kvp acess in Python

[Christian Stimming (mobil)]

From my understanding, there are two separate issues here:

1. You are proposing a new object Company because you have reasons for 
needing new data fields. I think that's a good idea. Why don't you prepare a 
patch to extend the existing objects?

2. You ask for kvp access from python. No, we prefer not to have kvp accessed 
from python. Instead, either use gobject properties (on master), or add a new 
object on the C side as mentioned above and add python wrappers for this.

Regards, Christian
--
Sent from mobile.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Boost compilation problem

[Christian Stimming]

Zitat von Derek Atkins warl...@mit.edu:

This works well because generally code that targets an older version of
a dependency will usually still work when compiled against a newer
version of that dependency.  So if we target version 1.48 of libFoo it
will generally still work with version 1.50 of libFoo that another user
has.

Doing it this way makes it easy for users to build gnucash; they don't
have to figure out how to install newer dependencies on their systems.


That's the correct explanation of the thought process of how we chose  
boost-1.48 as target. However, I see two issues here: Firstly, as  
Aaron figured out, newer distros (with newer gcc's which have newer  
warnings) won't even build with the old target boost anymore.  
Secondly, I think we're overrating the fact that *users* might want to  
*compile* gnucash for themselves and need to have it easy to do so. I  
mean, this small minority of people who compile gnucash from source  
can also be asked to compile boost from source. IMHO there's almost no  
difference between the set of people who can compile gnucash from  
source, and those who can compile both boost and gnucash from source.


I think we should still take the distro issue into consideration, but  
can decide on a compromise between our developers' convenience (it's  
us who do the work, anyway) and the dependency restrictions. In case  
of boost, IMHO as Aaron told us, 1.48 doesn't even compile anymore  
with current gcc and is therefore a nuisance to be used by us  
developers. We should lift this up to some newer version, such as 1.52  
or 1.56, whatever will be out on the market for 6-12 months at the  
targeted stable release date. But I think any extra effort to get  
boost-1.48 compile with our up-to-date build systems is rather wasted  
and should better be invested somewhere else. Boost-1.52 plus/minus  
one is my proposal.


Regards,

Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash won't build

[Christian Stimming]

Am Donnerstag, 9. Oktober 2014, 09:47:50 schrieb John Ralls:
 On Oct 9, 2014, at 8:49 AM, Alex Aycinena alex.aycin...@gmail.com wrote:
  When I try to build gnucash, I get:
  
  /home/gnucash-dev/gitcheckouts/gnucash/src/libqof/qof/kvp-value.cpp: In
  member function 'int compare_visitor::operator()(T, U) const':
  /home/gnucash-dev/gitcheckouts/gnucash/src/libqof/qof/kvp-value.cpp:219:15
  :
  error: 'invalid_argument' is not a member of 'std'
  
  throw std::invalid_argument{You may not compare objects of
  
  different type.};
  
^
  
  /home/gnucash-dev/gitcheckouts/gnucash/src/libqof/qof/kvp-value.cpp:219:36
  :
  error: expected ';' before '{' token
  
  throw std::invalid_argument{You may not compare objects of
  
  different type.};
  
 ^
  
  /home/gnucash-dev/gitcheckouts/gnucash/src/libqof/qof/kvp-value.cpp:220:5:
  error: no return statement in function returning non-void
  [-Werror=return-type]
  
  }
  ^
  
  At global scope:
  cc1plus: error: unrecognized command line option
  -Wno-deprecated-register
  [-Werror]
  cc1plus: all warnings being treated as errors
  make[5]: *** [kvp-value.lo] Error 1
  make[5]: Leaving directory
  `/home/gnucash-dev/gitcheckouts/gnucash-build/src/libqof/qof'
  
  Can someone give me some advice?
 
 See if adding
 
 #include stdexcept
 
 to kvp-value.cpp fixes the error.

Yes, this fixes it.

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: design directory, ERM; was: Doxygen - is there a status?

[Christian Stimming]

Am Samstag, 13. September 2014, 10:45:51 schrieb Carsten Rinke:
 Hi,
 
 sorry for the delay, but last weekend my computer broke down while I was
 on travel.
 So I had to arrange for a replacement first.
 
 Trying to avoid a detailed discussion, let me try to summarize what I
 understand up to here
 - there is a difference of higher level design documentation and
 lower level design documentation, and the lower level part is
 currently in Doxygen/Git, the higher level part is available in bits
 and peaces in several places (Doxygen, texinfo files, Wiki, emails, etc.)
 - a decision is needed whether to go for Wiki or Doxygen including the
 points
 -- only Wiki for everything (meaning, move the lower level part to Wiki,
 too)
 -- only Doxygen/Git for everything
 -- Doxygen/Git for Lower level, Wiki for higher level
 
 We have had quite different opinions so far about where and how the docu
 maintenance seems to be better. My impression is that no-one will
 convince no-one, no matter how long the discussion will be.
 
 How do you usually take decisions?
 Voting?

Oh well, we never have decided one some formal and/or clear decision process. 
For things like those: Well, just make up your mind. I personally look for the 
voiced opinions from the currently actice core developers. Namely: Derek, 
John, Geert, myself, and maybe I've forgotten one or two. Out of the 
statements from those people we make up the decision.

In this particular case: 
- John said very clear that the higher level documentation used to be put in 
texinfo or doxygen and it didn't work, so we should put it in the wiki. Nobody 
from the core developers objected, so please take this as a decision and 
continue to work on higher level design documentation only in the wiki. The 
texinfo files should be deleted as soon as the last remaining useful bits are 
copied into the wiki.
- The lower level i.e. the function-level documentation is in doxygen and 
should stay there.

In case I've misunderstood any of the previous discussion, feel free to 
comment or propose alternative solutions.

Regards,

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Namespaces, file names,...

[Christian Stimming]

Zitat von Derek Atkins warl...@mit.edu:

I agree that filenames should reflect the class that they implement,
when they do so, and I’ll add that in general a file should implement
only one class. Capitalization is OK as long as one keeps in mind that
the Mac file system is normally case-preserving but case-insensitive,
so e.g. Account.h and account.h will map to the same file.

I don’t think we want to give each directory its own namespace. I’m
not even sure that we want any namespaces inside ‘gnucash’.


I kind of like the Ruby on Rails method, where the file name is the
lower-case snake form of the class name.  E.g., a class Account would be
in a source file account.[ch], a class ScheduledTransaction would be in
a file scheduled_transaction.[ch], etc.


Glib/gtk has a scheme similar to what you mentioned from ruby, just  
with one extra third variation: The typedefs are CamelCase, the file  
names are with the same spelling but all-lowercase, and the function  
names are in snake form.


And: Sorry to object, but I particularly dislike this scheme - it  
means the file names are always different from the class names. Why  
not making them completely identical? In that case, zero thoughts have  
to be spent on how to guess the correct file name for a given class.



I agree that we don't need to have a directory for the namespace, and I
also don't think we need to have namespaces for each module/library.
E.g., I don't think we need GnuCash::Engine::Account.  I suspect doing
so would just add complexity where it might not be warranted.


I don't want to vote for extra namespaces, but I'd like to point out  
one technical reason for someone's preferences here: If the preferred  
tool of coding is something cmdline-based or emacs, chances are that  
extra directories mean extra typing work and are rather avoided. If  
the tool of coding is an IDE such as eclipse, qtcreator, or Visual  
Studio, the directories play only a minor role anymore (if visible at  
all in the project view) and chances are that they get to be used more  
often, for grouping of similar things and such. And in C++ (just as in  
java), adding extra namespaces for extra directories can be seen as  
the mapping between the file system and the compiler. In such a  
context, one wants to use gnc::engine::Account, knowing that it  
resides in the header file gnc/engine/Account.h on the disk, or  
gnc::backend::xml::XmlFile, knowing that it resides in  
gnc/backend/xml/XmlFile.h. You can always get rid of the namespace  
qualifications by using (no pun intended) using namespace, but I  
know from my own learning curve that multiple namespaces seem rather  
smelly when coming from a C background. After years of C++ I got to  
like them, especially if they are implemented as a direct mapping from  
the directory structure on disk to the class structure in the  
namespaces. But that's just my personal take on this.


Regards,

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash master: Add failing unittest for aqbanking lookup of trans_retrieval date.

[Christian Stimming]

Zitat von John Ralls jra...@ceridwen.us:
recently I noticed the trans-retrieval slot in the aqbanking  
account doesn't

remember its value.


Christian,

Yeah, fixed and pushed, e210f8c.

The difference was that your test used the defective accessor  
function and mine used qof_instance_get directly with the right  
parameter type (Timespec ** instead of Timespec *).


Ah, the wonders of zero compile-time checks of variable argument lists in C...

Thanks a lot for fixing this!

Regards,

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash master: Add failing unittest for aqbanking lookup of trans_retrieval date.

[Christian Stimming]

Am Montag, 8. September 2014, 07:17:47 schrieb John Ralls:
 On Sep 8, 2014, at 5:31 AM, Christian Stimming christ...@cstimming.de 
wrote:
  Zitat von John Ralls jra...@ceridwen.us:
  recently I noticed the trans-retrieval slot in the aqbanking account
  doesn't remember its value.
  
  Christian,
  
  Yeah, fixed and pushed, e210f8c.
  
  The difference was that your test used the defective accessor function
  and mine used qof_instance_get directly with the right parameter type
  (Timespec ** instead of Timespec *). 
  Ah, the wonders of zero compile-time checks of variable argument lists in
  C...
  
  Thanks a lot for fixing this!
 
 It's not C's fault; C compiler's know the difference between pointers and
 pointers-to-pointers and how to raise type errors. It's GValue's conversion
 of everything to void* that defeats the type checking.

Err... no, it is indeed C's fault: The function in question, qof_instance_get 
and set, uses a variable argument list (variadic arguments), terminated by the 
NULL pointer in the call, and this variable arguments are not at all compile-
time checked. Using qof_instance_get is what you inserted here in 
272655b60c0e30726, including the bug you fortunately now fixed. If there is 
another interface that gives us some more compile time checking, feel free to 
propose it here and/or in the docs of qof_instance_get. Or is this just a 
fundamental (bad) property of g_object's property system that we can't avoid?

Best Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Namespaces, file names,...

[Christian Stimming]

Am Sonntag, 7. September 2014, 15:10:13 schrieb John Ralls:
  I strongly prefer namespaces in all-lowercase. I have somewhat a
  preference
  for gnc as namespace name, but we are an application anyway and not a
  library, so we're basically free to choose whatever we want as interface
  naming schemes.
 
 Any particular reason for the all lowercase preference? Not that it matters,
 gnucash and GnuCash are equally unique.

I think one relationship wasn't mentioned so far: The filenames and the 
corresponding namespace and class names. I think both should be as identical 
as possible - similar to Qt, different from glib.

Namespaces in lowercase gives also directory names in lowercase. Class names, 
well, should appear in the file names IMHO as unchanged as possible. I prefer 
both with the first letter in capital, but I know this causes occasionally 
some hassles on windows systems, as those colleagues notoriously forget to add 
their include directives with the correct case sensitivity. Other people argue 
that file names should be all lowercase in general. Both views exist.

 I don't mind tagging member variables, and I find m_varName to be clearer
 than just sticking an underscore at the end. One can go one step further
 and tag static members with a c_ or an s_, while being aware that static
 members, just like any other static or global variable, require extra
 synchronization and so should be avoided as much as possible.

Ok for the prefix. However, static class members are not at all evil. 
They're a normal part of the language and needed for modelling certain aspects 
of a program. What is evil are global variables. But static class variables 
are just fine - they are fixed into their scope and have access rules. They 
are simply needed occasionally. Nothing that necessarily has to be avoided.

 Only Mike has expressed a strong preference for camel, with everyone else
 not seeming to care much. So let's go with camel, with Typenames (classes,
 structs, enums, and POD aliases) having the first word capitalized and
 function and variable names having the first word lower case. Functions
 with 'C' linkage (i.e. legacy wrappers for keeping the rest of GnuCash
 working) will be snake or start with xacc.
 
 Macros, and only macros, will be all caps.
 
 Let's also have the following conventions for special variable names:
 * Member variables begin with m_
 * Static member variables begin with c_ (for class)
 * static constants begin with k_ (and should always be used instead of
 macros) * static variables in the anonymous namespace (a.k.a. file scope)
 begin with s_ and require a detailed comment about why such a thing is the
 only feasible way to implement whatever-it-is.

Ok with me.

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Namespaces, file names,...

[Christian Stimming]

Just for there record, here's my take on potential coding conventions:

Am Samstag, 6. September 2014, 11:06:13 schrieb Geert Janssens:
  Yes, using GnuCash is less ambiguous that Gnc. Sold. For the record I
  don’t care about snake vs. camel as long as we pick one.
 
 John, thanks for elaborating on the differences between c and c++ concerning
 namespaces.
 
 I also prefer the namespace name to be GnuCash in full. I don't have a
 strong preference regarding snake vs. camel either.

I strongly prefer namespaces in all-lowercase. I have somewhat a preference 
for gnc as namespace name, but we are an application anyway and not a 
library, so we're basically free to choose whatever we want as interface 
naming schemes.

 Apparently lots of schemes exist.
 boost uses underscores.

Yes, boost and also the STL (std::...) uses underscores. For things that we 
define in analogy to STL, we will probably re-use their underscore scheme also 
regularly (such as typedef Xyz base_class; and typedef Xyz value_type;) in 
case we define things that are commonly defined in STL as well.

 I also found the naming rules for Google which is a mixture of both:
 http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#General_Namin
 g_Rules
 
 The latter takes more discipline while coding. On the other hand it helps
 distinguish what a word means. Is it a variable, a type a function ? The
 style it's written in helps distinguish in this case.
 
 Personally I like such a scheme.

I also like the convention of type/class names starting with a capital. Other 
than that, I have no strong preference between Camel and snake. Yes, in 
general I would consider snake slighly easier to read for me as a non-English 
native speaker, but I've worked with both and the difference is rather a 
matter of taste.

I see some interesting part of a C++ coding convention, besides the general 
naming scheme of types and varianles:
- Class member variables? From other projects I would propose a prefix such as 
m_, google has a _ suffix. 
- Member getters and setters (accessor and mutator methods)? From other 
projects (and also Java) I would propose a prefix get and prefix set, i.e. 
getSomeVariable, setSomeVariable; Qt uses no prefix for the getter and set 
for the setter: someVariable, setSomeVariable; google has no prefix for the 
getter and set_ for the setter: some_variable, set_some_variable.

 It's also the case that the longer and more complicated the style guide the
 less likely it is that it will be followed. That's partly down to self
 discipline but more to the volunteer nature of open source projects. We
 don't want to chase away contributors by making them read and follow a
 100-page style document.

That's correct. However, as we (read: you) will create the C++ classes of the 
gnucash engine types in the near future, we better decide up front whether we 
want to have those types named with some consistency. In src/optional/gtkmm I 
used my own preferred convention for the C++ wrapper classes, but when we 
really define our core types, we probably better decide on our common 
preferences. Hence, this discussion is not so much for a large style guide of 
the majority of our future code, but rather for good standarization elements 
when defining those commonly used types for ourselves.

Regards,

Christian

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Fwd: gnucash master: Add failing unittest for aqbanking lookup of trans_retrieval date.

[Christian Stimming]

Hi John,

recently I noticed the trans-retrieval slot in the aqbanking account doesn't 
remember its value. 

I now added a unittest that indeed shows that the getter function from import-
export/aqb/gnc-ab-kvp.h doesn't return the same value that I've inserted in 
the setter. However, your unittest in test-engine-kvp-properties.c indicated 
that the ab-trans-retrieval property with the GNC_TYPE_TIMESPEC type works 
fine. 

Do you happen to have any idea why it doesn't work fine when called by the 
gnc-ab-kvp.[hc] functions, even though your test in test-engine-kvp-properties 
seemed to work? Thanks a lot in advance!

Best Regards,

Christian


--  Weitergeleitete Nachricht  --

Betreff: gnucash master: Add failing unittest for aqbanking lookup of 
trans_retrieval date.
Datum: Sonntag, 7. September 2014, 17:03:13
Von: Christian Stimming cs...@code.gnucash.org
An: gnucash-patc...@gnucash.org

Updated  via  https://github.com/Gnucash/gnucash/commit/67155158 (commit)
from  https://github.com/Gnucash/gnucash/commit/80aa327a (commit)



commit 671551585eb636554f955f4ed095d5d8106bdd8d
Author: Christian Stimming christ...@cstimming.de
Date:   Sun Sep 7 22:58:07 2014 +0200

Add failing unittest for aqbanking lookup of trans_retrieval date.

The lookup of the ab-trans-retrieval property somehow fails to
return the correct value. This is somewhat surprising as this
property is already checked in the test-engine-kvp-properties.c and
there it works fine. What's the problem here...?



Summary of changes:
 .../aqb/test/file-book-hbcislot.gnucash| 39 +
 src/import-export/aqb/test/test-kvp.c  | 49 
++
 2 files changed, 88 insertions(+)

___
gnucash-patches mailing list
gnucash-patc...@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-patches
-
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Doxygen - is there a status?

[Christian Stimming (mobil)]

Hi Carsten, which questions do you want to get answered? If you have a few, I'd 
like to try to write up something.

Also, our wiki contains some text about the c API. Maybe this is of some help.

Regards, Christian

On 2. September 2014 17:10:00 MESZ, Carsten Rinke carsten.ri...@gmx.de wrote:
Hi,

Lately I was working on a bug (which I did not manage yet to fix).
During the investigations I noticed that I am still running around like

a blind chicken when starting out with a new bug.
And the reason is simple: Even though I have worked and programmed
quite 
a bit for GnuCash already, I still don't understand the architecture of
it.

So I decided to try a top down approach instead of the buttom up in 
order to learn a bit more about the 'big picture'.
And that is how I (once again) came across Doxygen.

While my first Doxygen attempts as a reader where ending up in
confusion 
and even more questions, I think I have now understood the idea. Still 
my impression is that some high level and introducing paragraphs might 
be helpful.
Currently it tells you more on how to make use of it as an author than 
to actually use it as a reader.

I could start looking into ways how to improve it - but that implies 
that stuff that I have in mind is really an improvement.

Therefore my first careful question:
What is the current status? Is there active work ongoing? Is it in 
general agreed that additinional (even basic) work is needed in this 
area? Or is everything (i.e. also conceptionally) in place as it
should?

Kind regards,
Carsten
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

--
Sent from mobile.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gnucash c++

[Christian Stimming]

Hi Aaron,

thanks for investing time in Gnucash and also in its development towards more 
future-proof programming technologies. I was a bit puzzled about the benefit 
of switching the normal compiling from C to C++, just by itself. IMHO, there 
is of course an immediate benefit if the data structures move from plain C 
structs to C++ classes, with constructor/destructor and such. If you plan to 
do such a transition with any of gnucash's data structures, of course every 
code using those will have to be C++. However, just changing this into C++ 
doesn't also solve the problem here: The usage of the C structs in the code is 
just that: C structs, with foo_new() and foo_delete() functions and maybe even 
glib's reference counting. To really use C++ classes instead, every single 
usage of those old C idioms will have to be replaced by proper C++ constructs. 
IMHO, just switching the C compiling to C++ doesn't quite bring you much 
gain here. Do you think it helps you much? I have some doubts. I see some more 
benefit when changing individual data structures to C++, then switching the 
old C functions into wrappers that make the new C++ behaviour available to the 
C side. This means the existing C code can continue to compile in C, and the 
next steps would rather be to open the possibility for new C++ code such as 
unittests and maybe new GUI code in C++ (or python or something similar). IMHO 
this would be more benefitial. What do others think?

Regards,

Christian

Am Mittwoch, 6. August 2014, 13:26:14 schrieb Aaron Laws:
 The motivation is to investigate a different strategy for migrating to C++.
 I was skeptical that it would work at all, but, through argument, I
 couldn't come up with any solid reasons why it couldn't work, so I decided
 to give it a go. The strategy is:
 Step 1) Get the project to compile as C++. Step 2) add poison to remove non
 c++ idioms, etc. Step 3) Make higher level changes.
 And the strategy entails that these steps are followed quite strictly. So
 far, I don't consider Step 1 complete, because although the project
 compiles and links, it's not shippable ... perhaps not even close :-).
 Like... nothing works.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Crash in hbci online transfer in master due to GList of kvp_frame

[Christian Stimming]

Dear John,

thanks for the pointers. It seems like the import-export/aqb use case of kvp 
was the only place in the code that used them this way, so this is probably 
why neither you nor anyone else so far has stumbled over this problem.

I can't even easily send you a gnucash file for reproducing this problem, 
because this very menu item can be called only if libaqbanking can already 
verify an existing configured online banking setup for this gnucash account. 
That means even if I send you my gnucash file, the menu items in question 
won't be active on your machine because you don't have my libaqbanking setup.

The immediate error is that the book's kvp slot hbci/template-list (see 
below for an example section of that slot from my data file) contains a value 
that is a GList, and those list elements are again kvp slots. When those list 
elements are asked to be converted from the kvp_value to GList elements in 
gvalue_list_from_kvp_value(), it calls gvalue_from_kvp_value() but there the 
kval argument is of type KVP_TYPE_FRAME that runs in the PWARN(Error! 
Attempt to transfer KvpFrame!) and returns NULL, which in turn crashes in 
kvp_frame.cpp:1677.

I think I was the only one who used this possibility to put a GList of 
kvp_frames in the data file. At the time in 2003, I needed a GList of 
GncABTransTempl objects (see src/import-export/aqb/gnc-ab-trans-templ.h and 
.c) to be stored in the data file. The solution at the time was to put the 
GncABTransTempl fields into the slots of a kvp_frame (see 
gnc_ab_trans_templ_to_kvp and gnc_ab_trans_templ_new_from_kvp in that file), 
and then putting those kvp_frames into a GList and this one in turn in a kvp 
slot. Yes, I know it was against any form of data hiding, but that's what was 
there at the time. 

However, the data fields don't have to be touched often: This list of 
GncABTransTempl must be read once when calling the online transfer menu 
item, to populate the list of templates that can be used for the online 
transfer. (i.e. the bank details for the transfer to Some Recipient should 
be auto-filled when clicking on the item in the template list.) This list is 
written again when closing the online transfer window, in gnc-ab-
transfer.c:65 and :66, if and only if the list of available templates has been 
modified. Which is seldomly the case. Hence, no optimization whatsoever needs 
to be in place.

How should I access a GList of a structured data type after your kvp changes, 
when I shouldn't make this a glist of kvp_frames anymore? What would be a good 
alternative? Thanks a lot in advance!

Regards,

Christian


Am Donnerstag, 26. Juni 2014, 16:15:02 schrieb John Ralls:
 On Jun 24, 2014, at 1:19 PM, Christian Stimming christ...@cstimming.de 
wrote:
  Due to some messed-up set up of my local git clone I apparently haven't
  updated my local working copy to our common master for several months. Now
  that I did that, I discovered that the online transfer menu item (send
  online transfer) will crash in master but not in maint.
  ...
  To reproduce: If you have a working online banking setup and also some
  stored transaction templates, clicking Actions - Online Actions -
  Online Transfer will now immediately crash as shown below:
  
  
  Program received signal SIGSEGV, Segmentation fault.
  gvalue_list_from_kvp_value (kval=optimized out, pList=0x7fffbcf0)
 at ../../../../src/libqof/qof/kvp_frame.cpp:1677
  
  1677if (G_VALUE_TYPE (gval))
  (gdb) bt
  #0  gvalue_list_from_kvp_value (kval=optimized out,
  pList=0x7fffbcf0)
 at ../../../../src/libqof/qof/kvp_frame.cpp:1677
  
  #1  0x7608b648 in g_list_foreach (list=optimized out,
 func=0x76ca1590 gvalue_list_from_kvp_value(KvpValue*, gpointer),
 user_data=0x7fffbcf0)
 at /build/buildd/glib2.0-2.40.0/./glib/glist.c:993


gnc:book version=2.0.0
book:id type=guid0e823542dec06f29e58d8f1c086223e0/book:id
book:slots
  !--   ...   --
  slot
slot:keyhbci/slot:key
slot:value type=frame
  slot
slot:keytemplate-list/slot:key
slot:value type=list
  slot:value type=frame
slot
  slot:keyamou/slot:key
  slot:value type=numeric0/1/slot:value
/slot
slot
  slot:keyname/slot:key
  slot:value type=stringSome Recipient/slot:value
/slot
slot
  slot:keypurc/slot:key
  slot:value type=string/slot:value
/slot
slot
  slot:keypurp/slot:key
  slot:value type=stringmy purpose lime/slot:value
/slot
slot
  slot:keyracc/slot:key
  slot:value type=string0519763065/slot:value
/slot
slot
  slot:keyrbcd/slot:key
  slot:value type=string50010517/slot:value
/slot
slot
  slot:keyrnam/slot:key
  slot:value type=stringstimming

Re: Rethinking Numeric: Decimal floats, or Rounding?

[Christian Stimming]

Am Sonntag, 22. Juni 2014, 13:47:49 schrieb John Ralls:
 If we’re going to fix that by rounding, we have to round to a power-of-ten
 denominator, but we have to do it in the right places to avoid accumulating
 errors; for a complex multi-currency transaction that might be to round
 each exchange to the target’s SCU before performing the next exchange;
 interest calculations might be a bit harder. In either case, that won’t
 necessarily prevent a GCD overflow in the presence of a large, weird,
 denominator.
 
 So you proposed digital floats as a way around that problem. I think it’s a
 good alternative, and I pursued it. Why are you now having second thoughts?

Hi John,

I'm not at all against the decimal floating point types. The implementation 
looks nice.

However, I probably still didn't get the original problem. It occurred to me 
as if some general overflow situation was detected in our 16 byte rational 
numbers - which is completely normal for any finite-precision number. But if 
such overflow happens during gnucash, it just means that the usual financial 
rounding procedures must be applied. As long as we don't round with less 
precision that what normal financial procedures are doing, we are fine. With 
the exception that sometime we are even fine only if we do exactly the 
necessary rounding and don't keep more precision than what the currency or 
security in question should hold. We've gone through the discussion at length 
so far. This question isn't related to the data type but rather asks whether 
our rounding strategy in general needs some changes towards accepted financial 
rounding rules. From my understanding, calculations with normal financial 
rounding rules can be achieved both with any of the decimal float types in 
question, but probably just as well with our existing 16-byte rational number 
type.

In other words, from my understanding, switching from 16 byte rationals to 8 
byte decimal floats does not make the original problem any worse, but also not 
really any better. What did I miss?

Regards,

Christian


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Crash in hbci online transfer in master but not in maint

[Christian Stimming]

Due to some messed-up set up of my local git clone I apparently haven't 
updated my local working copy to our common master for several months. Now 
that I did that, I discovered that the online transfer menu item (send online 
transfer) will crash in master but not in maint. 

The crash is most likely a side-effect of some changes in the KVP treatment in 
master, but I don't immediately recall the commits in question. Backtrace is 
below. Can someone point me to the commits in master that might have affected 
the behaviour of KVP, especially of kvp that contains lists of kvp frames? 
Thanks!

Regards,

Christian



To reproduce: If you have a working online banking setup and also some stored 
transaction templates, clicking Actions - Online Actions - Online Transfer 
will now immediately crash as shown below:


Program received signal SIGSEGV, Segmentation fault.
gvalue_list_from_kvp_value (kval=optimized out, pList=0x7fffbcf0)
at ../../../../src/libqof/qof/kvp_frame.cpp:1677
1677if (G_VALUE_TYPE (gval))
(gdb) bt
#0  gvalue_list_from_kvp_value (kval=optimized out, pList=0x7fffbcf0)
at ../../../../src/libqof/qof/kvp_frame.cpp:1677
#1  0x7608b648 in g_list_foreach (list=optimized out, 
func=0x76ca1590 gvalue_list_from_kvp_value(KvpValue*, gpointer), 
user_data=0x7fffbcf0)
at /build/buildd/glib2.0-2.40.0/./glib/glist.c:993
#2  0x76ca14e2 in gvalue_from_kvp_value (kval=0xd9f190)
at ../../../../src/libqof/qof/kvp_frame.cpp:1745
#3  0x76ca714c in qof_instance_get_kvp (inst=optimized out, 
key=0x76cb3068 hbci/template-list, value=0x7fffbd50)
at ../../../../src/libqof/qof/qofinstance.cpp:1082
#4  0x73b0b005 in object_get_property (value=0x7fffbd50, 
pspec=optimized out, object=0x79d260)
at /build/buildd/glib2.0-2.40.0/./gobject/gobject.c:1315
#5  g_object_get_valist (object=0x79d260, first_property_name=optimized out, 
var_args=0x7fffbdf8)
at /build/buildd/glib2.0-2.40.0/./gobject/gobject.c:2171
#6  0x76ca6dc4 in qof_instance_get (inst=0x79d260, 
first_prop=first_prop@entry=0x7fffdaf749fd ab-templates)
at ../../../../src/libqof/qof/qofinstance.cpp:949
#7  0x7fffdaf6aa59 in gnc_ab_get_book_template_list (b=0x79d260)
at ../../../../src/import-export/aqb/gnc-ab-kvp.c:124
#8  0x7fffdaf6b3d5 in gnc_ab_maketrans (parent=0x6e8a00, 
gnc_acc=gnc_acc@entry=0xe297b0, 
trans_type=trans_type@entry=SINGLE_TRANSFER)
at ../../../../src/import-export/aqb/gnc-ab-transfer.c:122
#9  0x7fffdaf72b80 in gnc_plugin_ab_cmd_issue_transaction (
---Type return to continue, or q return to quit---q

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rethinking Numeric

[Christian Stimming]

Am Samstag, 21. Juni 2014, 16:24:21 schrieb John Ralls:
 I’ve got the start of the trial implementation pushed to
 https://github.com/jralls/gnucash/tree/libmpdecimal. It builds, but it
 doesn’t pass all of the tests yet. I think it’s quite promising and I’ll
 keep working on it, but I wanted to give everyone a chance to see what it
 looks like. So far I’m leaving the existing API in place to simplify
 getting it working, but you’ll notice that the guts of the implementation
 is in a C++ wrapper to make it easy to use directly as the C++ rewrite
 progresses.

Hi John,

well, the new code and gnc_numeric implementation looks very interesting. 
However, I still do not quite understand what you are trying to fix here. You 
said overflows, but I argued earlier in this discussion that the existence 
of overflows in itself is most probably not a problem because our business 
logic requirements will most probably require rounding anyway much earlier 
before we run into overflows. If the problem is in this direction, shouldn't 
we rather try to clarify the rounding requirements and implement those 
correctly, rather than adding more significant digits to our number data type?

Regards,

Christian

 
 For those who don’t already know, I’m leaving Thursday for a month's
 vacation in Brussels and London. I expect I’ll check in here daily and may
 pop up on IRC from time to time, but I’m not planning to do a lot of
 GnuCash work.
 
 Regards,
 John Ralls
 
 
 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rethinking Numeric and rounding

[Christian Stimming]

Am Samstag, 31. Mai 2014, 15:29:12 schrieb John Ralls:
  Is this http://en.wikipedia.org/wiki/Decimal_floating_point what you're
  talking about? 
  
  But back to your initial question: You said we occasionally encounter
  overflow errors. I don't understand (yet) what the actual problem is.
  With
  our current rational numbers and int64_t numerator we have approx. 19
  decimal digits of precision (see [2] for the digits of a 64 bit signed
  integer), if I consider the numerator as fully used.
 
 The core of the problem is that 2^63 (remember the sign bit!) is 9.2E18 and
 some of that range is consumed in the fractional value so with our current
 6-digit max fraction for securities the largest number of units
 representable is 9E12, a pretty big number. There have been numerous
 requests over the years, principally from the Bitcoin community, that we
 increase the max fraction to 8 or 10. That would reduce the max number to
 9E10 or 9E8, which is starting to get uncomfortable in some currencies;

Yes, you're right with the numbers: An int64 can represent numbers with 19 
significant digits, that's what I wrote above (or maybe 18). As we have 
decided to do the rounding with 6 digits after the decimal point, this leaves 
us 12 digits in front of the decimal point, which is sufficient for our 
application domain. Decreasing this to 10 or 8 is not sufficient anymore, I 
agree on that. 

However, this always refers to a rounding mode with a fixed number of digits 
after the decimal point. On the other hand, floating-point arithmetic by 
definition has the decimal point moving, hence the number of significant 
digits can be moved from before to after the decimal point and vice versa. We 
don't have this flexibility here so far. But maybe even that isn't a problem.

 I don’t see rounding as an issue with rational numbers. It’s used only for
 display, and the internal representation is always exact. This sometimes
 trips me up when I’m doing taxes because my balance sheet will have a $.01
 discrepancy between Assets and Liabilities + Equity because I have to take
 the representations and transfer them to my tax software which then adds
 the rounded values instead of the exact ones. That would change in the face
 of a decimal internal representation, whether it’s binary or BCD. We’d need
 to allow for spare digits so that the rounding could be made insignificant
 at the maximum fraction level, hence my suggestion for a 12-decimal
 fixed-point on two uint64s.

From my point of view the problem is still not yet understood completely here. 
IMHO the problem is not too much rounding -- the problem instead is too little 
rounding. What are the exact requirements on the handling of rounding and 
overflow from our application domain? My argument is that our application 
domain of *managing finances* will give us the requirement to do the rounding 
according to normal currency numbers! Instead, our implementation using 
rational numbers tries to be more precise than rounding to currency numbers. 

In effect, this is not more precise but rather more wrong. We must not pretend 
to be more clever than the calculations that happen in reality. Speaking of 
finance calculations, we must not do the calculations with lesser rounding 
than what IFRS or similar authorities will clearly specify. Hence, your 
statement that our internal representation is always exact is correct from 
our programmer's point of view, but IMHO it is not true from the application 
requirement point of view (due to missing financial rounding). Your $0.01 
discrepancy is a symptom of exactly that. This doesn't mean our calculation is 
more correct, it unfortunately just means our calculation is wrong.

Here's an example where the missing rounding will lead to wrong results: Let's 
do some currency exchange, say between USD and EUR. Let's assume an exchange 
rate of 1.50 USD = 1.00 EUR (given with normal currency SCU [1] i.e. 2 digits 
after the decimal point here) or almost equivalently an exchange rate of 
0.6667 EUR/USD (given with more digits after the point). Let's say the user 
wants to enter some transactions where she sold 1 USD with the given rate 
0.6667. She enters those numbers in the txn dialog: 1.00 USD, rate 0.6667, and 
gnucash will calculate the resulting third number: 0.6667 EUR, but the display 
will show 0.67 EUR due to the currency's SCU. The user presses Ok because the 
resulting 0.67 EUR will match the number on the receipt, i.e. the 0.67 EUR 
were the amount that resulted in reality. However, if the gnucash account 
contains the exact value 0.6667 [2] and we don't do the correct rounding of 
this exchange transaction to the currency's SCU, the gnucash account shows 
0.67 EUR but internally contains a little bit less. Now the user enters a 
second identical transaction: 1.00 USD, rate 0.6667, the displayed EUR value 
is 0.67 which is the amount from reality. The user presses Ok again and she 
has 2 * 0.67 EUR in reality = 1.34 EUR. 

Re: Rethinking Numeric

[Christian Stimming]

Am Sonntag, 25. Mai 2014, 07:34:14 schrieb John Ralls:
  If we've reached the point where our int64 rational numbers do not fit
  our problem requirements anymore, I'd rather look for a different number
  representation that fits our application domain better. I'm thinking
  about replacing rational numbers by decimal floating point numbers. That
  is, a number is represented by m * 10^e with the mantissa m and exponent
  e as signed integers. This is different from our normal *binary*
  floating point in that we use the exponent with base 10. However, all
  common rules for floating point can be applied just as normal. By the
  way, maybe there is even a standard comparable to IEEE 754 available?
  
  Just another possible way to proceed for solving this problem...
  
  Is this http://en.wikipedia.org/wiki/Decimal_floating_point what you're
  talking about? If so, it says that the IEEE spec is 854, and answers some
  of my questions, but leaves out database support.

 A different spec: http://speleotrove.com/decimal/decarith.html
 And an implementation, which is used in CPython:
 http://www.bytereef.org/mpdecimal/index.html

Thanks for the pointers: Yes, that was exactly what I was talking about. Turns 
out the 2008 version of IEEE 754 [1] now also has this included (as 
decimal64 etc), but the implementations in everyday compilers and/or 
hardware come along rather slowly. There are well-established library 
implementations available, though, such as the one on speleotrove you 
mentioned, called decNumber, but others just as well. If we want to, we can 
very well include a library such as that one into gnucash and start using 
that.

But back to your initial question: You said we occasionally encounter 
overflow errors. I don't understand (yet) what the actual problem is. With 
our current rational numbers and int64_t numerator we have approx. 19 decimal 
digits of precision (see [2] for the digits of a 64 bit signed integer), if I 
consider the numerator as fully used. 

Are 19 significant decimal digits not enough? Are there thinkable cases when 
they are not enough? I tend to think the problem is rather found in our 
rational number's rounding, which is not the suitable rounding method for our 
financial application domain. If this is the problem, a different data type 
that does the rounding always according to decimal numbers, and not according 
to (in normal float/double calculations) binary floating point numbers, or (in 
gnc_numeric) according to rational numbers with some potentially unknown 
denominator. 

If this is indeed the problem, switching to a data type with strict decimal 
number behaviour might be the solution. And the IEEE 754-2008 decimal64 type 
might be one of the possible implementations, available in one of the 
mentioned libraries. For the record, decimal64 has 16 digits precision [1], 
i.e. it won't give us more digits in its 8 bytes compared to our 16 bytes so 
far. Maybe we want decimal128, which has 34 digits precision [1]. My gut 
feeling says the digits are not the problem and 16 digits are sufficient, but 
the rounding behaviour is indeed the problem.

As for database implementations: The speleotrove site [3] says something about 
some data bases that directly have a DECFLOAT type (such as ABAP) but 
apparently this is not the case for the databases we're looking at. Hence the 
storage would have to be done manually, maybe in two integers (significant and 
exponent), or in a string, but both would require further calculations before 
they can be used in a query directly.

Maybe not yet an easy solution available? But what again was the core of the 
problem?

Regards,

Christian

[1] http://en.wikipedia.org/wiki/IEEE_754-2008
[2] http://en.wikipedia.org/wiki/Integer_(computer_science)
[3] http://speleotrove.com/decimal/
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rethinking Numeric

[Christian Stimming (mobil)]

Thanks for starting the discussion. 

If we've reached the point where our int64 rational numbers do not fit our 
problem requirements anymore, I'd rather look for a different number 
representation that fits our application domain better. I'm thinking about 
replacing rational numbers by decimal floating point numbers. That is, a number 
is represented by m * 10^e with the mantissa m and exponent e as signed 
integers. This is different from our normal *binary* floating point in that we 
use the exponent with base 10. However, all common rules for floating point can 
be applied just as normal. By the way, maybe there is even a standard 
comparable to IEEE 754 available? 

Just another possible way to proceed for solving this problem...

- Christian
--
Sent from mobile.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: private-kvp merge reverted other changes since November.

[Christian Stimming]

Am Mittwoch, 14. Mai 2014, 10:10:18 schrieb Geert Janssens:
 On Tuesday 13 May 2014 21:35:58 John Ralls wrote:
  On May 13, 2014, at 9:01 PM, Mike Alexander m...@umich.edu wrote:
   That's what I do.  I rebase my branches onto master each time it is
   updated.  This seems to work well and keeps the tree much simpler.
  
  That's the SVN way. We discussed this back in March [1] and decided
  that we're not going to do that anymore. If you want to revisit that
  you need a better argument than that's the way I've always done it,
  considering that the Git community at large doesn't seem to consider
  it a best practice.
 
 It seems to me the git community is not against rebasing private
 branches before pushing them to a public repository (provided their
 branch point was never pushed earlier). Whether we should mandate this
 for gnucash is debatable.
 
 I have seen suggestions to prefer short-lived topic branches. So I'm
 going to think out loud here. If a topic asks for a long term topic
 branch, perhaps the topic is not well chosen or could be split in
 smaller sub topics which each go on their own branch.

If we discuss the personal preferences again: My preference clearly is for 
shortly lived branches and frequent rebasing of private branches. The ladder 
history looks magnitudes harder to read to me, compared to a linear history of 
rebased commits. (Not to mention the railway merger, but that's probably a 
different topic.) 

I'm convinced by the arguments to have two long lived branches, maint and 
master, but I'm not convinced to allow more than those branches for longer 
times. I'd expect people to rebase their private and/or feature branches 
frequently. For me, it would make it much easier to understand what the new 
features really are and what the relation to the master branch are.

Regards,

Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: backend encryption / security

[Christian Stimming]

Hi Michalis,

thanks a lot for your offer for help, and thanks for explaining your idea.

Contrary to what some other developers replied, the feature is indeed welcomed 
by at least part of the developers and surely by many users. I've discussed 
this previously, see (as you have probably seen already)
http://gnucash.uservoice.com/suggestions/1547269
and the thread following of 
https://lists.gnucash.org/pipermail/gnucash-devel/2013-June/035754.html

From the user's point of view, having the possibility for an access protection 
password does make some sense and to my understanding this particular user-
level feature would also be welcomed for inside gnucash.

The picture may be different, though, when talking about an integrated 
encryption feature in gnucash. I, for one, would welcome that feature as well, 
so to provide some more access protection against casual access by someone 
unauthorized (e.g. shared user account as explained in the uservoice 
comments). It remains an open question on how to explain the limits of this 
feature clearly enough to the user. I.e., facts such as encrypting the data 
file doesn't make the log files disappear and so on. If you can explain how 
your solution solves the user feature request of casual access protection, but 
without tricking users into a too self-confident feeling of security, I think 
this is a worthwhile feature.

Best Regards,

Christian


Am Dienstag, 6. Mai 2014, 18:40:03 schrieb Michalis Kamprianis:
 Hi,
 I can see in uservoice, and I think frequently asked in lists, the request
 for encryption or password protection of the datafile.
 
 Regarding database backends, I believe that database encryption should be
 used if required, (although I understand that dbi may not be up to the
 task).
 
 Nevertheless, for xml backend, I think that I could try to implement an AES
 based encryption (on saving) and decryption (on opening), based on code
 from aescrypt. Aescrypt is available for unix, windows, mac, so the
 implementation should probably be portable across platforms. The code is
 some gpl and some freeware. Of course such a solution only protects data at
 rest (i.e. when data is read in memory it is not protected. Log files are
 not protected. User configuration files are not protected - at least
 initially, and so on) so it's not transforming gnucash to the most secure
 accounting software out there, but solves the problem with datafile
 misplacement or unwanted access.
 
 The thing is, (a) I don't know if you're interested and / or agree in
 implementing something like that, and (b) although I will probably manage
 to code the open and save routines, I'm not sure I will not get stuck
 somewhere, in which case it will either remain as an unfinished project, or
 I will need some help from somebody more experienced.
 
 Your thoughts?
 
 Regards
 Michalis
 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Building on Windows from scratch - follow up

[Christian Stimming (mobil)]

On 28. April 2014 16:52:03 MESZ, John Ralls jra...@ceridwen.us wrote:

For wild, not even in the oven yet, for the very long term, how about
build GC native in MSVC?

This isn't as weird as it sounds: I've been able to compile and run the 
cutecash experiment in msvc successfully, at the time. Hence, with cmake this 
is possible already today. With autotools, not quite.

Regards , Christian
--
Sent from mobile.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel