"What's New" for 3.0

2018-01-21 Thread John Ralls
It's about time to think about the side stuff that goes with a major release. 
Chris Lam has offered a PR (https://github.com/Gnucash/gnucash-docs/pull/106) 
documenting his substantial enhancements to the Transaction Report and included 
a bunch of "NEW! in 3.0" bullets. Given the way documentation is(n't) 
maintained I think it wise not to bury something like that in a chapter, and 
besides we need a summary document explaining everything that's changed between 
2.6 and 3.0.

We had until the 2.6.14 docs a "What's New section in the Guide's overview 
chapter that had last been updated for Version 2.2. It obviously turned into an 
embarrassing example of how we keep such things up-to-date. I don't think we 
should do it again.

How about a "What's New in 3.0" page on the website? If we go with that, what's 
the best way to collaborate in building it?

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


Re: SIGSEGV in deleting transactions (2.7.3)

2018-01-21 Thread John Ralls
I sure hope it's deleting all of the splits in a transaction. Be sure to 
mention that in your bug report.

Regards,
John Ralls

> On Jan 21, 2018, at 1:03 PM, Fabio Coatti  wrote:
> 
> Sry, the dialog option I was referring to is the one that appears when you 
> delete a transaction, asking if you want to delete, delete and don't be asked 
> again or deleted and don't asked again in the current session. Anyway, this 
> proved to be wrong, I simply deleted transactions that were  ok (no bug 
> triggering) for three times in a row and when I selected "don't remind me 
> again" I was working on a "bad" transaction. A unlucky pick.
> I'm going to open a bug, thanks for the hint. Maybe this situation could be 
> caused by having deleted one account with all his transactions. I was 
> assuming that both splits were going to be deleted but I get that my 
> assumption was wrong.
> 
> Il giorno dom 21 gen 2018 alle ore 21:37 John Ralls  ha 
> scritto:
> Don't remind me of *what*?
> 
> Anyway, the problem is obvious from the first tow stack frames: You've 
> deleted the transaction out from under one of the business pages (can't tell 
> from the backtrace which one and it probably doesn't matter) and so there's 
> no primary transaction. xaccTransCountSplits doesn't protect itself from 
> being called with a null transaction (it should) and 
> gnc_plugin_business_update_menus doesn't check that it got a transaction 
> before calling it (it should), so boom.
> 
> Please file a bug report so that we don't forget. Thanks.
> 
> Regards,
> John Ralls
> 
> > On Jan 21, 2018, at 12:16 PM, Fabio Coatti  wrote:
> >
> > Another bit of information: I can see this issue when I tick "don't remind
> > me again in this session" option. If I leave it unticked, the crash does
> > not happen.
> >
> > Il giorno dom 21 gen 2018 alle ore 20:16 Fabio Coatti <
> > fabio.coa...@gmail.com> ha scritto:
> >
> >> Hi All,
> >> I'm testing out gnucash 2.7.3 (nice step from 2.6.x, BTW, thanks) and I
> >> very often get a SIGSEGV when deleting transaction, albeit not all the
> >> times.
> >> I tried to get a core and a backtrack, but probably I still have too many
> >> optimizations active.
> >> In any case, this is what I got; if you want a specific
> >> testing/compilation option just let me know, I'll try to do what I can.
> >>
> >> Program terminated with signal SIGSEGV, Segmentation fault.
> >> #0  xaccTransCountSplits (trans=trans@entry=0x0) at Transaction.c:2318
> >> 2318FOR_EACH_SPLIT(trans, i++);
> >> [Current thread is 1 (LWP 15888)]
> >>
> >> (gdb) bt
> >> #0  xaccTransCountSplits (trans=trans@entry=0x0) at Transaction.c:2318
> >> #1  0x7ea1fbf46473 in gnc_plugin_business_update_menus
> >> (plugin_page=) at gnc-plugin-business.c:926
> >> #2  0x7ea1fbf466bc in gnc_plugin_business_main_window_page_changed
> >> (window=, page=0x57bb548b19e0, user_data=) at
> >> gnc-plugin-business.c:946
> >> #3  0x7ea1f9f71555 in g_closure_invoke () from
> >> /usr/lib64/libgobject-2.0.so.0
> >> #4  0x7ea1f9f5de43 in ?? () from /usr/lib64/libgobject-2.0.so.0
> >> #5  0x7ea1f9f61f55 in g_signal_emit_valist () from
> >> /usr/lib64/libgobject-2.0.so.0
> >> #6  0x7ea1f9f62eb8 in g_signal_emit_by_name () from
> >> /usr/lib64/libgobject-2.0.so.0
> >> #7  0x7ea1fbc28656 in gnc_main_window_generate_title
> >> (window=window@entry=0x57bb507d43a0) at gnc-main-window.c:1536
> >> #8  0x7ea1fbc287ae in gnc_main_window_update_title
> >> (window=0x57bb507d43a0) at gnc-main-window.c:1558
> >> #9  0x7ea1f9c93add in g_list_foreach () from
> >> /usr/lib64/libglib-2.0.so.0
> >> #10 0x7ea1fbc277c0 in gnc_main_window_update_all_titles () at
> >> gnc-main-window.c:1566
> >> #11 gnc_main_window_book_dirty_cb (book=0x57bb525f0c80, dirty=1,
> >> user_data=) at gnc-main-window.c:1576
> >> #12 0x7ea1fb6dd752 in qof_commit_edit_part2 (inst=0x57bb54071a70,
> >> on_error=on_error@entry=0x7ea1fb60c0a0 , 
> >> on_done=on_done@entry=0x0,
> >> on_free=on_free@entry=0x7ea1fb60bed0 ) at
> >> qofinstance.cpp:1011
> >> #13 0x7ea1fb60e13a in xaccSplitCommitEdit (s=0x57bb54071a70) at
> >> Split.c:1004
> >> #14 0x7ea1fb614645 in do_destroy (trans=0x57bb52c4b700) at
> >> Transaction.c:1531
> >> #15 0x7ea1fb6dd6ef in qof_commit_edit_part2 (inst=0x57bb52c4b700,
> >> on_error=on_error@entry=0x7ea1fb614c10 ,
> >> on_done=on_done@entry=0x7ea1fb611b60 ,
> >> on_free=on_free@entry=0x7ea1fb6145a0 )
> >>   at qofinstance.cpp:1048
> >> #16 0x7ea1fb613e9a in xaccTransCommitEdit (trans=0x57bb52c4b700) at
> >> Transaction.c:1692
> >> #17 0x7ea1f942ae87 in gnc_split_register_delete_current_trans
> >> (reg=) at split-register.c:1140
> >> #18 0x7ea1fbf58922 in gnc_plugin_page_register_cmd_delete_transaction
> >> (action=0x57bb54b03630, plugin_page=0x57bb548b19e0) at
> >> gnc-plugin-page-register.c:3575
> >> #19 0x7ea1f9f71555 in g_closure_invoke () from
> >> 

Re: SIGSEGV in deleting transactions (2.7.3)

2018-01-21 Thread Fabio Coatti
Sry, the dialog option I was referring to is the one that appears when you
delete a transaction, asking if you want to delete, delete and don't be
asked again or deleted and don't asked again in the current session.
Anyway, this proved to be wrong, I simply deleted transactions that were
ok (no bug triggering) for three times in a row and when I selected "don't
remind me again" I was working on a "bad" transaction. A unlucky pick.
I'm going to open a bug, thanks for the hint. Maybe this situation could be
caused by having deleted one account with all his transactions. I was
assuming that both splits were going to be deleted but I get that my
assumption was wrong.

Il giorno dom 21 gen 2018 alle ore 21:37 John Ralls  ha
scritto:

> Don't remind me of *what*?
>
> Anyway, the problem is obvious from the first tow stack frames: You've
> deleted the transaction out from under one of the business pages (can't
> tell from the backtrace which one and it probably doesn't matter) and so
> there's no primary transaction. xaccTransCountSplits doesn't protect itself
> from being called with a null transaction (it should) and
> gnc_plugin_business_update_menus doesn't check that it got a transaction
> before calling it (it should), so boom.
>
> Please file a bug report so that we don't forget. Thanks.
>
> Regards,
> John Ralls
>
> > On Jan 21, 2018, at 12:16 PM, Fabio Coatti 
> wrote:
> >
> > Another bit of information: I can see this issue when I tick "don't
> remind
> > me again in this session" option. If I leave it unticked, the crash does
> > not happen.
> >
> > Il giorno dom 21 gen 2018 alle ore 20:16 Fabio Coatti <
> > fabio.coa...@gmail.com> ha scritto:
> >
> >> Hi All,
> >> I'm testing out gnucash 2.7.3 (nice step from 2.6.x, BTW, thanks) and I
> >> very often get a SIGSEGV when deleting transaction, albeit not all the
> >> times.
> >> I tried to get a core and a backtrack, but probably I still have too
> many
> >> optimizations active.
> >> In any case, this is what I got; if you want a specific
> >> testing/compilation option just let me know, I'll try to do what I can.
> >>
> >> Program terminated with signal SIGSEGV, Segmentation fault.
> >> #0  xaccTransCountSplits (trans=trans@entry=0x0) at Transaction.c:2318
> >> 2318FOR_EACH_SPLIT(trans, i++);
> >> [Current thread is 1 (LWP 15888)]
> >>
> >> (gdb) bt
> >> #0  xaccTransCountSplits (trans=trans@entry=0x0) at Transaction.c:2318
> >> #1  0x7ea1fbf46473 in gnc_plugin_business_update_menus
> >> (plugin_page=) at gnc-plugin-business.c:926
> >> #2  0x7ea1fbf466bc in gnc_plugin_business_main_window_page_changed
> >> (window=, page=0x57bb548b19e0, user_data= out>) at
> >> gnc-plugin-business.c:946
> >> #3  0x7ea1f9f71555 in g_closure_invoke () from
> >> /usr/lib64/libgobject-2.0.so.0
> >> #4  0x7ea1f9f5de43 in ?? () from /usr/lib64/libgobject-2.0.so.0
> >> #5  0x7ea1f9f61f55 in g_signal_emit_valist () from
> >> /usr/lib64/libgobject-2.0.so.0
> >> #6  0x7ea1f9f62eb8 in g_signal_emit_by_name () from
> >> /usr/lib64/libgobject-2.0.so.0
> >> #7  0x7ea1fbc28656 in gnc_main_window_generate_title
> >> (window=window@entry=0x57bb507d43a0) at gnc-main-window.c:1536
> >> #8  0x7ea1fbc287ae in gnc_main_window_update_title
> >> (window=0x57bb507d43a0) at gnc-main-window.c:1558
> >> #9  0x7ea1f9c93add in g_list_foreach () from
> >> /usr/lib64/libglib-2.0.so.0
> >> #10 0x7ea1fbc277c0 in gnc_main_window_update_all_titles () at
> >> gnc-main-window.c:1566
> >> #11 gnc_main_window_book_dirty_cb (book=0x57bb525f0c80, dirty=1,
> >> user_data=) at gnc-main-window.c:1576
> >> #12 0x7ea1fb6dd752 in qof_commit_edit_part2 (inst=0x57bb54071a70,
> >> on_error=on_error@entry=0x7ea1fb60c0a0 ,
> on_done=on_done@entry=0x0,
> >> on_free=on_free@entry=0x7ea1fb60bed0 ) at
> >> qofinstance.cpp:1011
> >> #13 0x7ea1fb60e13a in xaccSplitCommitEdit (s=0x57bb54071a70) at
> >> Split.c:1004
> >> #14 0x7ea1fb614645 in do_destroy (trans=0x57bb52c4b700) at
> >> Transaction.c:1531
> >> #15 0x7ea1fb6dd6ef in qof_commit_edit_part2 (inst=0x57bb52c4b700,
> >> on_error=on_error@entry=0x7ea1fb614c10 ,
> >> on_done=on_done@entry=0x7ea1fb611b60 ,
> >> on_free=on_free@entry=0x7ea1fb6145a0 )
> >>   at qofinstance.cpp:1048
> >> #16 0x7ea1fb613e9a in xaccTransCommitEdit (trans=0x57bb52c4b700) at
> >> Transaction.c:1692
> >> #17 0x7ea1f942ae87 in gnc_split_register_delete_current_trans
> >> (reg=) at split-register.c:1140
> >> #18 0x7ea1fbf58922 in
> gnc_plugin_page_register_cmd_delete_transaction
> >> (action=0x57bb54b03630, plugin_page=0x57bb548b19e0) at
> >> gnc-plugin-page-register.c:3575
> >> #19 0x7ea1f9f71555 in g_closure_invoke () from
> >> /usr/lib64/libgobject-2.0.so.0
> >> #20 0x7ea1f9f5de43 in ?? () from /usr/lib64/libgobject-2.0.so.0
> >> #21 0x7ea1f9f61f55 in g_signal_emit_valist () from
> >> /usr/lib64/libgobject-2.0.so.0
> >> #22 0x7ea1f9f631a7 in g_signal_emit () from

Re: SIGSEGV in deleting transactions (2.7.3)

2018-01-21 Thread John Ralls
Don't remind me of *what*?

Anyway, the problem is obvious from the first tow stack frames: You've deleted 
the transaction out from under one of the business pages (can't tell from the 
backtrace which one and it probably doesn't matter) and so there's no primary 
transaction. xaccTransCountSplits doesn't protect itself from being called with 
a null transaction (it should) and gnc_plugin_business_update_menus doesn't 
check that it got a transaction before calling it (it should), so boom.

Please file a bug report so that we don't forget. Thanks.

Regards,
John Ralls

> On Jan 21, 2018, at 12:16 PM, Fabio Coatti  wrote:
> 
> Another bit of information: I can see this issue when I tick "don't remind
> me again in this session" option. If I leave it unticked, the crash does
> not happen.
> 
> Il giorno dom 21 gen 2018 alle ore 20:16 Fabio Coatti <
> fabio.coa...@gmail.com> ha scritto:
> 
>> Hi All,
>> I'm testing out gnucash 2.7.3 (nice step from 2.6.x, BTW, thanks) and I
>> very often get a SIGSEGV when deleting transaction, albeit not all the
>> times.
>> I tried to get a core and a backtrack, but probably I still have too many
>> optimizations active.
>> In any case, this is what I got; if you want a specific
>> testing/compilation option just let me know, I'll try to do what I can.
>> 
>> Program terminated with signal SIGSEGV, Segmentation fault.
>> #0  xaccTransCountSplits (trans=trans@entry=0x0) at Transaction.c:2318
>> 2318FOR_EACH_SPLIT(trans, i++);
>> [Current thread is 1 (LWP 15888)]
>> 
>> (gdb) bt
>> #0  xaccTransCountSplits (trans=trans@entry=0x0) at Transaction.c:2318
>> #1  0x7ea1fbf46473 in gnc_plugin_business_update_menus
>> (plugin_page=) at gnc-plugin-business.c:926
>> #2  0x7ea1fbf466bc in gnc_plugin_business_main_window_page_changed
>> (window=, page=0x57bb548b19e0, user_data=) at
>> gnc-plugin-business.c:946
>> #3  0x7ea1f9f71555 in g_closure_invoke () from
>> /usr/lib64/libgobject-2.0.so.0
>> #4  0x7ea1f9f5de43 in ?? () from /usr/lib64/libgobject-2.0.so.0
>> #5  0x7ea1f9f61f55 in g_signal_emit_valist () from
>> /usr/lib64/libgobject-2.0.so.0
>> #6  0x7ea1f9f62eb8 in g_signal_emit_by_name () from
>> /usr/lib64/libgobject-2.0.so.0
>> #7  0x7ea1fbc28656 in gnc_main_window_generate_title
>> (window=window@entry=0x57bb507d43a0) at gnc-main-window.c:1536
>> #8  0x7ea1fbc287ae in gnc_main_window_update_title
>> (window=0x57bb507d43a0) at gnc-main-window.c:1558
>> #9  0x7ea1f9c93add in g_list_foreach () from
>> /usr/lib64/libglib-2.0.so.0
>> #10 0x7ea1fbc277c0 in gnc_main_window_update_all_titles () at
>> gnc-main-window.c:1566
>> #11 gnc_main_window_book_dirty_cb (book=0x57bb525f0c80, dirty=1,
>> user_data=) at gnc-main-window.c:1576
>> #12 0x7ea1fb6dd752 in qof_commit_edit_part2 (inst=0x57bb54071a70,
>> on_error=on_error@entry=0x7ea1fb60c0a0 , 
>> on_done=on_done@entry=0x0,
>> on_free=on_free@entry=0x7ea1fb60bed0 ) at
>> qofinstance.cpp:1011
>> #13 0x7ea1fb60e13a in xaccSplitCommitEdit (s=0x57bb54071a70) at
>> Split.c:1004
>> #14 0x7ea1fb614645 in do_destroy (trans=0x57bb52c4b700) at
>> Transaction.c:1531
>> #15 0x7ea1fb6dd6ef in qof_commit_edit_part2 (inst=0x57bb52c4b700,
>> on_error=on_error@entry=0x7ea1fb614c10 ,
>> on_done=on_done@entry=0x7ea1fb611b60 ,
>> on_free=on_free@entry=0x7ea1fb6145a0 )
>>   at qofinstance.cpp:1048
>> #16 0x7ea1fb613e9a in xaccTransCommitEdit (trans=0x57bb52c4b700) at
>> Transaction.c:1692
>> #17 0x7ea1f942ae87 in gnc_split_register_delete_current_trans
>> (reg=) at split-register.c:1140
>> #18 0x7ea1fbf58922 in gnc_plugin_page_register_cmd_delete_transaction
>> (action=0x57bb54b03630, plugin_page=0x57bb548b19e0) at
>> gnc-plugin-page-register.c:3575
>> #19 0x7ea1f9f71555 in g_closure_invoke () from
>> /usr/lib64/libgobject-2.0.so.0
>> #20 0x7ea1f9f5de43 in ?? () from /usr/lib64/libgobject-2.0.so.0
>> #21 0x7ea1f9f61f55 in g_signal_emit_valist () from
>> /usr/lib64/libgobject-2.0.so.0
>> #22 0x7ea1f9f631a7 in g_signal_emit () from
>> /usr/lib64/libgobject-2.0.so.0
>> #23 0x7ea1fa8a905a in ?? () from /usr/lib64/libgtk-3.so.0
>> #24 0x7ea1fa662789 in ?? () from /usr/lib64/libgtk-3.so.0
>> #25 0x7ea1f9f624bd in g_signal_emit_valist () from
>> /usr/lib64/libgobject-2.0.so.0
>> #26 0x7ea1f9f631a7 in g_signal_emit () from
>> /usr/lib64/libgobject-2.0.so.0
>> #27 0x7ea1fa7f8d75 in ?? () from /usr/lib64/libgtk-3.so.0
>> #28 0x7ea1fa7f8e45 in ?? () from /usr/lib64/libgtk-3.so.0
>> #29 0x7ea1f9f71555 in g_closure_invoke () from
>> /usr/lib64/libgobject-2.0.so.0
>> #30 0x7ea1f9f5df1b in ?? () from /usr/lib64/libgobject-2.0.so.0
>> #31 0x7ea1f9f61f55 in g_signal_emit_valist () from
>> /usr/lib64/libgobject-2.0.so.0
>> #32 0x7ea1f9f631a7 in g_signal_emit () from
>> /usr/lib64/libgobject-2.0.so.0
>> #33 0x7ea1fa7f7360 in ?? () from /usr/lib64/libgtk-3.so.0
>> #34 0x7ea1f5e670e2 in ffi_call_unix64 () from 

Re: SIGSEGV in deleting transactions (2.7.3)

2018-01-21 Thread Fabio Coatti
Another bit of information: I can see this issue when I tick "don't remind
me again in this session" option. If I leave it unticked, the crash does
not happen.

Il giorno dom 21 gen 2018 alle ore 20:16 Fabio Coatti <
fabio.coa...@gmail.com> ha scritto:

> Hi All,
> I'm testing out gnucash 2.7.3 (nice step from 2.6.x, BTW, thanks) and I
> very often get a SIGSEGV when deleting transaction, albeit not all the
> times.
> I tried to get a core and a backtrack, but probably I still have too many
> optimizations active.
> In any case, this is what I got; if you want a specific
> testing/compilation option just let me know, I'll try to do what I can.
>
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  xaccTransCountSplits (trans=trans@entry=0x0) at Transaction.c:2318
> 2318FOR_EACH_SPLIT(trans, i++);
> [Current thread is 1 (LWP 15888)]
>
> (gdb) bt
> #0  xaccTransCountSplits (trans=trans@entry=0x0) at Transaction.c:2318
> #1  0x7ea1fbf46473 in gnc_plugin_business_update_menus
> (plugin_page=) at gnc-plugin-business.c:926
> #2  0x7ea1fbf466bc in gnc_plugin_business_main_window_page_changed
> (window=, page=0x57bb548b19e0, user_data=) at
> gnc-plugin-business.c:946
> #3  0x7ea1f9f71555 in g_closure_invoke () from
> /usr/lib64/libgobject-2.0.so.0
> #4  0x7ea1f9f5de43 in ?? () from /usr/lib64/libgobject-2.0.so.0
> #5  0x7ea1f9f61f55 in g_signal_emit_valist () from
> /usr/lib64/libgobject-2.0.so.0
> #6  0x7ea1f9f62eb8 in g_signal_emit_by_name () from
> /usr/lib64/libgobject-2.0.so.0
> #7  0x7ea1fbc28656 in gnc_main_window_generate_title
> (window=window@entry=0x57bb507d43a0) at gnc-main-window.c:1536
> #8  0x7ea1fbc287ae in gnc_main_window_update_title
> (window=0x57bb507d43a0) at gnc-main-window.c:1558
> #9  0x7ea1f9c93add in g_list_foreach () from
> /usr/lib64/libglib-2.0.so.0
> #10 0x7ea1fbc277c0 in gnc_main_window_update_all_titles () at
> gnc-main-window.c:1566
> #11 gnc_main_window_book_dirty_cb (book=0x57bb525f0c80, dirty=1,
> user_data=) at gnc-main-window.c:1576
> #12 0x7ea1fb6dd752 in qof_commit_edit_part2 (inst=0x57bb54071a70,
> on_error=on_error@entry=0x7ea1fb60c0a0 , 
> on_done=on_done@entry=0x0,
> on_free=on_free@entry=0x7ea1fb60bed0 ) at
> qofinstance.cpp:1011
> #13 0x7ea1fb60e13a in xaccSplitCommitEdit (s=0x57bb54071a70) at
> Split.c:1004
> #14 0x7ea1fb614645 in do_destroy (trans=0x57bb52c4b700) at
> Transaction.c:1531
> #15 0x7ea1fb6dd6ef in qof_commit_edit_part2 (inst=0x57bb52c4b700,
> on_error=on_error@entry=0x7ea1fb614c10 ,
> on_done=on_done@entry=0x7ea1fb611b60 ,
> on_free=on_free@entry=0x7ea1fb6145a0 )
>at qofinstance.cpp:1048
> #16 0x7ea1fb613e9a in xaccTransCommitEdit (trans=0x57bb52c4b700) at
> Transaction.c:1692
> #17 0x7ea1f942ae87 in gnc_split_register_delete_current_trans
> (reg=) at split-register.c:1140
> #18 0x7ea1fbf58922 in gnc_plugin_page_register_cmd_delete_transaction
> (action=0x57bb54b03630, plugin_page=0x57bb548b19e0) at
> gnc-plugin-page-register.c:3575
> #19 0x7ea1f9f71555 in g_closure_invoke () from
> /usr/lib64/libgobject-2.0.so.0
> #20 0x7ea1f9f5de43 in ?? () from /usr/lib64/libgobject-2.0.so.0
> #21 0x7ea1f9f61f55 in g_signal_emit_valist () from
> /usr/lib64/libgobject-2.0.so.0
> #22 0x7ea1f9f631a7 in g_signal_emit () from
> /usr/lib64/libgobject-2.0.so.0
> #23 0x7ea1fa8a905a in ?? () from /usr/lib64/libgtk-3.so.0
> #24 0x7ea1fa662789 in ?? () from /usr/lib64/libgtk-3.so.0
> #25 0x7ea1f9f624bd in g_signal_emit_valist () from
> /usr/lib64/libgobject-2.0.so.0
> #26 0x7ea1f9f631a7 in g_signal_emit () from
> /usr/lib64/libgobject-2.0.so.0
> #27 0x7ea1fa7f8d75 in ?? () from /usr/lib64/libgtk-3.so.0
> #28 0x7ea1fa7f8e45 in ?? () from /usr/lib64/libgtk-3.so.0
> #29 0x7ea1f9f71555 in g_closure_invoke () from
> /usr/lib64/libgobject-2.0.so.0
> #30 0x7ea1f9f5df1b in ?? () from /usr/lib64/libgobject-2.0.so.0
> #31 0x7ea1f9f61f55 in g_signal_emit_valist () from
> /usr/lib64/libgobject-2.0.so.0
> #32 0x7ea1f9f631a7 in g_signal_emit () from
> /usr/lib64/libgobject-2.0.so.0
> #33 0x7ea1fa7f7360 in ?? () from /usr/lib64/libgtk-3.so.0
> #34 0x7ea1f5e670e2 in ffi_call_unix64 () from /usr/lib64/libffi.so.6
> #35 0x7ea1f5e63e8c in ffi_call () from /usr/lib64/libffi.so.6
> #36 0x7ea1f9f7a35d in g_cclosure_marshal_generic_va () from
> /usr/lib64/libgobject-2.0.so.0
> #37 0x7ea1f9f624bd in g_signal_emit_valist () from
> /usr/lib64/libgobject-2.0.so.0
> #38 0x7ea1f9f631a7 in g_signal_emit () from
> /usr/lib64/libgobject-2.0.so.0
> #39 0x7ea1fa7a42b1 in ?? () from /usr/lib64/libgtk-3.so.0
> #40 0x7ea1f9f7a019 in g_cclosure_marshal_VOID__BOXEDv () from
> /usr/lib64/libgobject-2.0.so.0
> #41 0x7ea1f9f624bd in g_signal_emit_valist () from
> /usr/lib64/libgobject-2.0.so.0
> #42 0x7ea1f9f631a7 in g_signal_emit () from
> /usr/lib64/libgobject-2.0.so.0
> #43 0x7ea1fa79ae4e in ?? () from 

Capital Gains FAQ entry

2018-01-21 Thread David T. via gnucash-devel
Cicko,

I see that you have gotten involved in working on the wiki; fabulous! 

I recently received a notice that you had edited the FAQ on handling capital 
gains, by adding a reference to the wiki page “Concept of Lots”. 

Naturally, having received the announcement of the page change, I took a look 
at both the FAQ section and the Concept of Lots page, and found a number of 
problems.

First, the FAQ itself is quite dated, mentioning the status of gains as of 
version 1.8. Since the Tutorial & Concept Guide represents the most complete 
and up-to-date version of the documentation, I have added these references and 
removed the original paragraph.

Next, it goes into quite a bit of detail on how to enter gains—topics that are 
now covered in quite some detail in the Tutorial & Concepts Guide. SInce "9.7. 
Selling Shares” is so thorough, the examples given in the FAQ are both 
incomplete and redundant. Consequently, I am removing the example in the FAQ, 
and pointing to the Tutorial a second time, since it has so many detailed 
examples.

Finally, I wonder whether it is wise to link to the “Concept of Lots” page, as 
it appears to be a description of how the implementer of the Lots feature went 
about it. Some of this information does appear to be unique, however, so I 
didn’t touch your reference to it. Long term, I think the information on this 
page should be separated so that the technical, development, information was 
placed on a technical page, and the user-focused information placed in the 
documentation set.

Anyhow, I just wanted to let you know why I went into this section and changed 
it just after you had.

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


Re: Wrong link in docs

2018-01-21 Thread David T. via gnucash-devel
As that is part of the Help manual, a bug would be appropriate. I have 
submitted one: Bug 792756 (https://bugzilla.gnome.org/show_bug.cgi?id=792756 
)

Thanks!

David T.

> On Jan 21, 2018, at 9:16 PM, cicko  wrote:
> 
> In the documentation, page  Lots in Account
>   , the link
> in the following sentence:
> 
> "See Tutorial and Concepts Guide, Automatic Calculation of Capital Gain or
> Loss Using Lots for more details. "
> 
> points to a non-existing page. Is this something that should go to bugs or
> is a notification here enough?
> Cheers 
> 
> 
> 
> --
> Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
> ___
> 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


Wrong link in docs

2018-01-21 Thread cicko
In the documentation, page  Lots in Account
  , the link
in the following sentence:

"See Tutorial and Concepts Guide, Automatic Calculation of Capital Gain or
Loss Using Lots for more details. "

points to a non-existing page. Is this something that should go to bugs or
is a notification here enough?
Cheers 



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Captcha error on wiki

2018-01-21 Thread John Ralls


> On Jan 21, 2018, at 1:34 AM, cicko  wrote:
> 
> I can confirm that editing URLs works now.
> 
> @John, BTW, I'm not sure that the content of the linked txt file always
> matches the message of the sentence in which it is referenced. At the top of
> the page, I added the new link to the architecture article which explains
> the concept and the reasoning behind the current implementation of the Lots.
> It has more narrative than the first text file, which is more the API-style
> documentation. 

Yes, your change to the overview page is better. It’s quite possible that 
that’s the content the original author meant to point at but it got moved in 
the Doxygen documentation but never updated in the wiki.

Regards,
John Ralls

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


Re: Wiki down?

2018-01-21 Thread Derek Atkins

No. Was not planned.  Code lost its IP address.  It's been fixed.

-derek
Sent using my mobile device. Please excuse any typos.



On January 21, 2018 10:23:57 AM cicko  wrote:


Hi,

The wiki site seems to be down and there is no related announcement. Is it a
planned downtime?

Alen



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
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: [MAINT] Network/Server downtime TODAY at 1500-1600 US/EST

2018-01-21 Thread Derek Atkins

Thanks. I'll take a look.
Amusingly your email came around the same time I saw an ovirt engine 
restart implying a network blip.


-derek
Sent using my mobile device. Please excuse any typos.



On January 21, 2018 1:36:29 AM "David T."  wrote:


Derek,

The wiki doesn’t seem to be operational at this time.

David



On Jan 21, 2018, at 2:37 AM, Derek Atkins  wrote:

And now everything is back online.
Please let me know if you see any issues.

-derek


On Sat, January 20, 2018 2:08 pm, Derek Atkins wrote:

Hi,

I'm going to be taking my network down (including code, wiki, lists) at
around 12n today in order to relocate the equipment.  I suspect the
downtime will be a couple hours or so, assuming everything goes
smoothly.

I will be taking the server down around 2:30pm, give or take.

I'll email again when it's back online.

Sorry for the short notice for this move; I have to coordinate with
someone else and I got a short-term window from them.

Thanks!

-derek
--
  Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
  Member, MIT Student Information Processing Board  (SIPB)
  URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
  warl...@mit.eduPGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel




--
  Derek Atkins 617-623-3745
  de...@ihtfp.com www.ihtfp.com
  Computer and Internet Security Consultant

___
gnucash-user mailing list
gnucash-u...@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.





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


Re: Captcha error on wiki

2018-01-21 Thread cicko
I can confirm that editing URLs works now.

@John, BTW, I'm not sure that the content of the linked txt file always
matches the message of the sentence in which it is referenced. At the top of
the page, I added the new link to the architecture article which explains
the concept and the reasoning behind the current implementation of the Lots.
It has more narrative than the first text file, which is more the API-style
documentation. 



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Wiki down?

2018-01-21 Thread cicko
Hi,

The wiki site seems to be down and there is no related announcement. Is it a
planned downtime?

Alen



--
Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel