Re: [GNC-dev] gnucash maint: Multiple changes pushed

[John Ralls]

> On Jan 9, 2019, at 9:06 AM, Geert Janssens  wrote:
> 
> Op woensdag 9 januari 2019 15:45:31 CET schreef John Ralls:
>>> On Jan 9, 2019, at 6:17 AM, Derek Atkins  wrote:
>>> 
>>> HI,
>>> 
>>> On Wed, January 9, 2019 9:12 am, Geert Janssens wrote:
 I like the idea of caching the system locale for future use. Too bad the
 std::locale is working so poorly on Windows :(
 
 Op zondag 6 januari 2019 19:13:28 CET schreef John Ralls:
> +const std::locale&
> +gnc_get_locale()
> +{
> +  static std::locale cached;
> +  static bool tried_already = false;
 
 If I understand it correctly using static variables makes the function
 unsuitable for multi-threading, right ?
>>> 
>>> Not necessarily.  There is a race condition on first-use, but beyond that
>>> I don't see a MT issue here.  The data is read-only, right?  Multiple
>>> threads could read from the same read-only data simultaneously, so that
>>> should be fine.
>>> 
> 
> It was this first-use race condition I was referring to.
> 
> Particularly, for thread safety I think setting tried_already = true should 
> happen at the very end of the function, after we're sure cached has a proper 
> value. Otherwise a competing thread could try to get the uninitialized cached 
> value if thread execution of the first thread is interrupted right after 
> tried_already is set true.
> 
>>> Static data is ont MT-unsafe if it's being changed on a per-call basis
>>> (e.g. a time_t -> string API returning a static string buffer).
>>> 
 Any idea how difficult would it be to fix that ?
>>> 
>>> You could add a mutex around the initialization.  That's all I think you
>>> would need here.
>>> 
 I know GnuCash is not thread-safe by a long shot and gtk itself is single
 threaded so it doesn't matter that much.
 
 However I silently set a personal goal of changing that sometime. The C
 code
 is a lost cause IMO, but it might be worth to keep multi-threading in
 mind
 as
 we gradually convert to c++. In my basic understanding of threading this
 particular function should not be too hard to make tread safe.
>> 
>> Right, and I decided against making this the first introduction of mutex
>> into GnuCash. I think std::atomic
>> (https://en.cppreference.com/w/cpp/atomic/atomic
>> ) is the correct modern
>> C++ way for a simple case like this.
> 
> I was hoping indeed modern C++ has some answer to this. This is my first 
> foray 
> into multi-threading by the way so I'm pretty green in this area and wishing 
> to learn more about it.
> 
> In this particular case would declaring the cached and tried_already as 
> atomic 
> be sufficient to make this thread safe ?
> 
> It seems to me this would still allow multiple threads to go in and run the 
> initialization code for setting cached. Given they all should end up setting 
> cached to the same locale it's probably not dangerous to the application, 
> only 
> potentially running the same code multiple times where only once would be 
> sufficient.

My knowledge of concurrency is pretty dated. I had an operating system course 
30 years ago that included a discussion of concurrency, and some parts of Glib 
are thread-safe, so I’ve bounced up against it doing maintenance a few times. 
Just mutex and semaphore stuff. 

I haven’t even yet read the concurrency chapter in Josuttis, but my 
understanding of std::atomic is that a std::atomic variable magically 
eliminates races and has certain operations (construction and operator= among 
them) that are guaranteed to be, well, atomic: The compiler will always create 
a contiguous uninterruptible sequence of machine instructions for atomic 
operations. There are also ways to order execution of some functions with 
std::memory_model that can make locks (i.e. mutexes and semaphores) 
unnecessary, and the compiler is able to figure out when that’s true and when 
it isn’t and to take care of the locking without the programmer needing to 
explicitly code it.

It’s not something I think worth worrying about now. GnuCash is very far away 
from being multi-threaded. Besides, the natural home for the instantiation of 
the cached C++ local is in main(), after all of the environment options are 
parsed but before the GUI is loaded or the first session started. This isn’t 
the function to worry about concurrent access.

Regards,
John Ralls

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

Re: [GNC-dev] Reports -- Cleanup

[D via gnucash-devel]

If the reports are getting some attention now, I'll note that there are a 
number of minor bugs in Bugzilla regarding reports that could use attention. I 
put in 773168, 773169, 773198, 773199, and 773200, which are all pretty 
superficial, IMHO, and might be despatched by someone with any skill set all (I 
am unfortunately not that person).

David

On January 10, 2019, at 7:33 AM, Christopher Lam  
wrote:

Thanks for the interest in reports.

I'd like to take opportunity to explain current state of code.

Examples of duplication:
- html-barchart, html-linechart, html-scatter, html-pie have a lot of
duplicated code; there's a pending work for merging the charting
infrastructure into a universal one, and also upgrading from jqplot to
chartjs (responsive and animated). this is not frozen yet.

Pending work
- transaction.scm may receive a CSV export function. see last commit at
https://github.com/christopherlam/gnucash/commits/maint-export-csv/gnucash/report/standard-reports/transaction.scm
for anyone wishing to experiment.
- multicolumn balsheet is still pending and requires cleanup

Future work
- if reconciliation report gets a lot of attention and refinements it may
be spun off into a separate file like income-gst-statement.scm.
- a header for reconciliation report is not difficult, but the
determination of 'starting and ending balance' for the header is
*difficult* - I'd like to mimic the formal reconciliation tool but I'm not
sure how it calculates the balances.
- organising removal of unused old code

On Thu, 10 Jan 2019 at 05:53, David Cousens 
wrote:

> Steve,
>
> I would like to add to Adrien's concerns. The reports are for more than an
> accountant or a bookkeeper. Many people using GnuCash are managing personal
> finances, investments, not for profits, small businesses etc and while they
> may need the basic standard accounting reports (balance sheet, income
> statement, transaction, cash flow etc.), they also need to have reports
> which give them information which is more related to managing those
> activities and sometimes they also need to dig deeper into the information.
>
> We need to remember that the options that are there have grown out of user
> requests for reports outside the basic reports and/or the need for more or
> different information.
>
> An additional concern is perhaps that many users have produced customized
> reports based on the standardized reports. I don't know to what extent
> these
> are standalone, but if changes in the underlying report affect the derived
> reports then we will hear screams and gnashing of teeth from the user base.
>
> GnuCash is also widely used in many jurisdictions and reporting
> requirements
> and standards and practice can vary in more than just language and date
> formats. Fortunately there is a strong international push for financial
> reporting standards (IFRS) led by the IASB. The FASB in the US is moving
> the
> GAAP towards agreement/compliance with the IFRS, and is a major participant
> in the IASB, but has not yet adopted the IFRS as the basis of its internal
> standards. Many European countries and others adopt the IFRS standards with
> local variation on top to meet legislative requirements in corporate law,
> consumer legislation etc as well as local practices.
>
> https://www.ifrs.org/use-around-the-world/use-of-ifrs-standards-by-jurisdiction/#analysis
> has a comlete breakdown of the current position.
>
> David Cousens
>
>
>
> -
> David Cousens
> --
> 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
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [GNC-dev] Reports -- Cleanup

[Stephen M. Butler]

I appreciate all the responses.  The general consensus is to keep the
existing options and build more specific reports on top of it's
capabilities.

From the comments, it appears a coder could hide many of the options in
order to produce a targeted report that an end-user would find easier to
use and configure.

--Steve

On 1/9/19 1:50 PM, David Cousens wrote:
> Steve,
>
> I would like to add to Adrien's concerns. The reports are for more than an
> accountant or a bookkeeper. Many people using GnuCash are managing personal
> finances, investments, not for profits, small businesses etc and while they
> may need the basic standard accounting reports (balance sheet, income 
> statement, transaction, cash flow etc.), they also need to have reports
> which give them information which is more related to managing those
> activities and sometimes they also need to dig deeper into the information.
>
> We need to remember that the options that are there have grown out of user
> requests for reports outside the basic reports and/or the need for more or
> different information.
>
> An additional concern is perhaps that many users have produced customized
> reports based on the standardized reports. I don't know to what extent these
> are standalone, but if changes in the underlying report affect the derived
> reports then we will hear screams and gnashing of teeth from the user base.
>
> GnuCash is also widely used in many jurisdictions and reporting requirements
> and standards and practice can vary in more than just language and date
> formats. Fortunately there is a strong international push for financial
> reporting standards (IFRS) led by the IASB. The FASB in the US is moving the
> GAAP towards agreement/compliance with the IFRS, and is a major participant
> in the IASB, but has not yet adopted the IFRS as the basis of its internal
> standards. Many European countries and others adopt the IFRS standards with
> local variation on top to meet legislative requirements in corporate law,
> consumer legislation etc as well as local practices.
> https://www.ifrs.org/use-around-the-world/use-of-ifrs-standards-by-jurisdiction/#analysis
> has a comlete breakdown of the current position.
>
> David Cousens
>
>
>
> -
> David Cousens
> --
> 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
>

-- 
Stephen M Butler, PMP, PSM
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

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

Re: [GNC-dev] Reports -- Cleanup

[Christopher Lam]

Thanks for the interest in reports.

I'd like to take opportunity to explain current state of code.

Examples of duplication:
- html-barchart, html-linechart, html-scatter, html-pie have a lot of
duplicated code; there's a pending work for merging the charting
infrastructure into a universal one, and also upgrading from jqplot to
chartjs (responsive and animated). this is not frozen yet.

Pending work
- transaction.scm may receive a CSV export function. see last commit at
https://github.com/christopherlam/gnucash/commits/maint-export-csv/gnucash/report/standard-reports/transaction.scm
for anyone wishing to experiment.
- multicolumn balsheet is still pending and requires cleanup

Future work
- if reconciliation report gets a lot of attention and refinements it may
be spun off into a separate file like income-gst-statement.scm.
- a header for reconciliation report is not difficult, but the
determination of 'starting and ending balance' for the header is
*difficult* - I'd like to mimic the formal reconciliation tool but I'm not
sure how it calculates the balances.
- organising removal of unused old code

On Thu, 10 Jan 2019 at 05:53, David Cousens 
wrote:

> Steve,
>
> I would like to add to Adrien's concerns. The reports are for more than an
> accountant or a bookkeeper. Many people using GnuCash are managing personal
> finances, investments, not for profits, small businesses etc and while they
> may need the basic standard accounting reports (balance sheet, income
> statement, transaction, cash flow etc.), they also need to have reports
> which give them information which is more related to managing those
> activities and sometimes they also need to dig deeper into the information.
>
> We need to remember that the options that are there have grown out of user
> requests for reports outside the basic reports and/or the need for more or
> different information.
>
> An additional concern is perhaps that many users have produced customized
> reports based on the standardized reports. I don't know to what extent
> these
> are standalone, but if changes in the underlying report affect the derived
> reports then we will hear screams and gnashing of teeth from the user base.
>
> GnuCash is also widely used in many jurisdictions and reporting
> requirements
> and standards and practice can vary in more than just language and date
> formats. Fortunately there is a strong international push for financial
> reporting standards (IFRS) led by the IASB. The FASB in the US is moving
> the
> GAAP towards agreement/compliance with the IFRS, and is a major participant
> in the IASB, but has not yet adopted the IFRS as the basis of its internal
> standards. Many European countries and others adopt the IFRS standards with
> local variation on top to meet legislative requirements in corporate law,
> consumer legislation etc as well as local practices.
>
> https://www.ifrs.org/use-around-the-world/use-of-ifrs-standards-by-jurisdiction/#analysis
> has a comlete breakdown of the current position.
>
> David Cousens
>
>
>
> -
> David Cousens
> --
> 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: [GNC-dev] gnucash maint: Multiple changes pushed

[John Ralls]

> On Jan 9, 2019, at 11:52 AM, Geert Janssens  
> wrote:
> 
> Op woensdag 9 januari 2019 18:06:49 CET schreef Geert Janssens:
>> Op woensdag 9 januari 2019 15:57:07 CET schreef John Ralls:
 On Jan 9, 2019, at 4:24 AM, Geert Janssens 
 wrote:>
 
 Op dinsdag 1 januari 2019 22:14:16 CET schreef John Ralls:
> Updatedvia  https://github.com/Gnucash/gnucash/commit/3a105f07
>> 
>> (commit)
>> 
>via  https://github.com/Gnucash/gnucash/commit/95bee405 (commit)
>via  https://github.com/Gnucash/gnucash/commit/cc3bb4ef (commit)
>   
>   from  https://github.com/Gnucash/gnucash/commit/0f53b6c8 (commit)
> 
> commit 3a105f0728984df7f063110acc8390c93722d581
> Author: John Ralls 
> Date:   Tue Jan 1 13:12:39 2019 -0800
> 
>   Catch boost::locale character-conversion exceptions.
> 
>   Partial cause of the crash reported in Bug 797002.
 
 I suppose you meant 796996 ?
 
 Also it looks like you're really only catching the errors. The source of
 the conversion issue itself is not really determined yet ?
>>> 
>>> Yes, wrong bug.
>>> 
>>> Yes, in this one I’m only catching the exceptions because uncaught
>>> exceptions cause crashes. The root cause was libc’s not-quite-right
>>> creation of e.g. “Spanish_Spain.1252” locale strings, the .1252 part
>>> choking gen(“”) (and even Spanish_Spain chokes std::locale(“”). That’s
>>> addressed with the more thorough error handling and use of gen(“”) in
>>> b4fedff90e.
>>> 
>>> Regards,
>>> John Ralls
>> 
>> Oh right. I saw that commit later on, but didn't make the connection.
>> Thanks.
> 
> Returning to this: it occurred to me bug 796996 is about a crash on MacOS, 
> though the example you give looks like a Windows locale name.
> 
> Does libc MacOS also create improper locale names and does b4fedff90e fix 
> this 
> as well ?

Yes, and so do some Linux distros. What chokes gen(“”) is the appended 
encoding.  That’s why b4fedff90e strips everything after ‘.’ in the locale 
string and tries again.

The wider Windows case came up on IRC: 
https://wiki.gnucash.org/logs/2019/01/04.html#T15:58:41 
. That fail was from 
std::locale and is what led me to use gen(“”) for all C++ locale retrievals.

Regards,
John Ralls

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

Re: [GNC-dev] gnucash maint: Multiple changes pushed

[Geert Janssens]

Op woensdag 9 januari 2019 18:06:49 CET schreef Geert Janssens:
> Op woensdag 9 januari 2019 15:57:07 CET schreef John Ralls:
> > > On Jan 9, 2019, at 4:24 AM, Geert Janssens 
> > > wrote:>
> > > 
> > > Op dinsdag 1 januari 2019 22:14:16 CET schreef John Ralls:
> > >> Updated   via  https://github.com/Gnucash/gnucash/commit/3a105f07
> 
> (commit)
> 
> > >>   via  https://github.com/Gnucash/gnucash/commit/95bee405 (commit)
> > >>   via  https://github.com/Gnucash/gnucash/commit/cc3bb4ef (commit)
> > >>  
> > >>  from  https://github.com/Gnucash/gnucash/commit/0f53b6c8 (commit)
> > >> 
> > >> commit 3a105f0728984df7f063110acc8390c93722d581
> > >> Author: John Ralls 
> > >> Date:   Tue Jan 1 13:12:39 2019 -0800
> > >> 
> > >>Catch boost::locale character-conversion exceptions.
> > >>
> > >>Partial cause of the crash reported in Bug 797002.
> > > 
> > > I suppose you meant 796996 ?
> > > 
> > > Also it looks like you're really only catching the errors. The source of
> > > the conversion issue itself is not really determined yet ?
> > 
> > Yes, wrong bug.
> > 
> > Yes, in this one I’m only catching the exceptions because uncaught
> > exceptions cause crashes. The root cause was libc’s not-quite-right
> > creation of e.g. “Spanish_Spain.1252” locale strings, the .1252 part
> > choking gen(“”) (and even Spanish_Spain chokes std::locale(“”). That’s
> > addressed with the more thorough error handling and use of gen(“”) in
> > b4fedff90e.
> > 
> > Regards,
> > John Ralls
> 
> Oh right. I saw that commit later on, but didn't make the connection.
> Thanks.

Returning to this: it occurred to me bug 796996 is about a crash on MacOS, 
though the example you give looks like a Windows locale name.

Does libc MacOS also create improper locale names and does b4fedff90e fix this 
as well ?

Geert


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

Re: [GNC-dev] gnucash maint: Multiple changes pushed

[Geert Janssens]

Op woensdag 9 januari 2019 15:45:31 CET schreef John Ralls:
> > On Jan 9, 2019, at 6:17 AM, Derek Atkins  wrote:
> > 
> > HI,
> > 
> > On Wed, January 9, 2019 9:12 am, Geert Janssens wrote:
> >> I like the idea of caching the system locale for future use. Too bad the
> >> std::locale is working so poorly on Windows :(
> >> 
> >> Op zondag 6 januari 2019 19:13:28 CET schreef John Ralls:
> >>> +const std::locale&
> >>> +gnc_get_locale()
> >>> +{
> >>> +  static std::locale cached;
> >>> +  static bool tried_already = false;
> >> 
> >> If I understand it correctly using static variables makes the function
> >> unsuitable for multi-threading, right ?
> > 
> > Not necessarily.  There is a race condition on first-use, but beyond that
> > I don't see a MT issue here.  The data is read-only, right?  Multiple
> > threads could read from the same read-only data simultaneously, so that
> > should be fine.
> > 

It was this first-use race condition I was referring to.

Particularly, for thread safety I think setting tried_already = true should 
happen at the very end of the function, after we're sure cached has a proper 
value. Otherwise a competing thread could try to get the uninitialized cached 
value if thread execution of the first thread is interrupted right after 
tried_already is set true.

> > Static data is ont MT-unsafe if it's being changed on a per-call basis
> > (e.g. a time_t -> string API returning a static string buffer).
> > 
> >> Any idea how difficult would it be to fix that ?
> > 
> > You could add a mutex around the initialization.  That's all I think you
> > would need here.
> > 
> >> I know GnuCash is not thread-safe by a long shot and gtk itself is single
> >> threaded so it doesn't matter that much.
> >> 
> >> However I silently set a personal goal of changing that sometime. The C
> >> code
> >> is a lost cause IMO, but it might be worth to keep multi-threading in
> >> mind
> >> as
> >> we gradually convert to c++. In my basic understanding of threading this
> >> particular function should not be too hard to make tread safe.
> 
> Right, and I decided against making this the first introduction of mutex
> into GnuCash. I think std::atomic
> (https://en.cppreference.com/w/cpp/atomic/atomic
> ) is the correct modern
> C++ way for a simple case like this.

I was hoping indeed modern C++ has some answer to this. This is my first foray 
into multi-threading by the way so I'm pretty green in this area and wishing 
to learn more about it.

In this particular case would declaring the cached and tried_already as atomic 
be sufficient to make this thread safe ?

It seems to me this would still allow multiple threads to go in and run the 
initialization code for setting cached. Given they all should end up setting 
cached to the same locale it's probably not dangerous to the application, only 
potentially running the same code multiple times where only once would be 
sufficient.

Geert


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

Re: [GNC-dev] gnucash maint: Multiple changes pushed

[John Ralls]

> On Jan 9, 2019, at 4:24 AM, Geert Janssens  wrote:
> 
> Op dinsdag 1 januari 2019 22:14:16 CET schreef John Ralls:
>> Updated   via  https://github.com/Gnucash/gnucash/commit/3a105f07 
>> (commit)
>>   via  https://github.com/Gnucash/gnucash/commit/95bee405 (commit)
>>   via  https://github.com/Gnucash/gnucash/commit/cc3bb4ef (commit)
>>  from  https://github.com/Gnucash/gnucash/commit/0f53b6c8 (commit)
>> 
>> 
>> 
>> commit 3a105f0728984df7f063110acc8390c93722d581
>> Author: John Ralls 
>> Date:   Tue Jan 1 13:12:39 2019 -0800
>> 
>>Catch boost::locale character-conversion exceptions.
>> 
>>Partial cause of the crash reported in Bug 797002.
>> 
> I suppose you meant 796996 ?
> 
> Also it looks like you're really only catching the errors. The source of the 
> conversion issue itself is not really determined yet ?

Yes, wrong bug.

Yes, in this one I’m only catching the exceptions because uncaught exceptions 
cause crashes. The root cause was libc’s not-quite-right creation of e.g. 
“Spanish_Spain.1252” locale strings, the .1252 part choking gen(“”) (and even 
Spanish_Spain chokes std::locale(“”). That’s addressed with the more thorough 
error handling and use of gen(“”) in b4fedff90e.

Regards,
John Ralls

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

Re: [GNC-dev] gnucash maint: Multiple changes pushed

[John Ralls]

> On Jan 9, 2019, at 6:17 AM, Derek Atkins  wrote:
> 
> HI,
> 
> On Wed, January 9, 2019 9:12 am, Geert Janssens wrote:
>> I like the idea of caching the system locale for future use. Too bad the
>> std::locale is working so poorly on Windows :(
>> 
>> Op zondag 6 januari 2019 19:13:28 CET schreef John Ralls:
>>> +const std::locale&
>>> +gnc_get_locale()
>>> +{
>>> +  static std::locale cached;
>>> +  static bool tried_already = false;
>> 
>> If I understand it correctly using static variables makes the function
>> unsuitable for multi-threading, right ?
> 
> Not necessarily.  There is a race condition on first-use, but beyond that
> I don't see a MT issue here.  The data is read-only, right?  Multiple
> threads could read from the same read-only data simultaneously, so that
> should be fine.
> 
> Static data is ont MT-unsafe if it's being changed on a per-call basis
> (e.g. a time_t -> string API returning a static string buffer).
> 
>> Any idea how difficult would it be to fix that ?
> 
> You could add a mutex around the initialization.  That's all I think you
> would need here.
> 
>> I know GnuCash is not thread-safe by a long shot and gtk itself is single
>> threaded so it doesn't matter that much.
>> 
>> However I silently set a personal goal of changing that sometime. The C
>> code
>> is a lost cause IMO, but it might be worth to keep multi-threading in mind
>> as
>> we gradually convert to c++. In my basic understanding of threading this
>> particular function should not be too hard to make tread safe.

Right, and I decided against making this the first introduction of mutex into 
GnuCash.
I think std::atomic (https://en.cppreference.com/w/cpp/atomic/atomic 
) is the correct 
modern C++ way for a simple case like this. 

Regards,
John Ralls

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

Re: [GNC-dev] I'd like to contribute to the GnuCash project, starting with the documentation - now also development

[Geert Janssens]

Op maandag 7 januari 2019 18:28:20 CET schreef rob.l...@chello.nl:
> Hi,
> 
> In addition to the message below, after investigating and testing the import
> business data functionality, reading the code, and registering a number of
> bugs, I decided to try and fix the bugs myself. So I assigned the bugs to
> myself, and have started fixing them locally. I have also started updating
> the doxygen information in the code. And I have created new user
> documentation for import bills & invoices. I am now in the process of
> investigating the import customers & vendors functionality, and updating
> documentation for the same.
> 
> It is my intention to submit patches for code and user documentation once I
> have completed the work on both import bills & invoices and import
> customers and vendors.
> 
> On my development skills, I’ve had formal development training, using Pascal
> and Modula 2, and used C to create an application on my Macintosh+, but
> that was about 30 years ago.

Interesting. My first coding experiments were in Pascal as well and at around 
the same time *and* on my father's Mac SE :)

> My job was first in accounting, and later in
> IT (SAP). I did development in ABAP (the SAP programming language), but
> that was about 20 years ago. Since then, I have often done some programming
> for work or fun (in Visual Basic, PHP), but never in depth.

Have been superficially in Visual Basic (by necessity) and php as well.

> All in all, I
> think I have the skills to tackle bugs in the functional domain, and the
> common sense to stay away from stuff I don’t understand.

Sure. I'm interested to see your patches.

However I would like you to submit your work for review *before* you believe 
it's completely finished. That way you can have feedback earlier on whether 
the direction you're going in fits the project and potentially save you time.

I read you have already fixed a few bugs. By all means create a PR for those 
fixes. You can always add more later.

Enjoy!

Geert


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

Re: [GNC-dev] Reports -- Cleanup

[Geert Janssens]

Op dinsdag 8 januari 2019 18:25:33 CET schreef Stephen M. Butler:
> On 1/7/19 8:42 PM, Adrien Monteleone wrote:
> > I do agree however that the Transaction report is really more of a ‘master
> > report’ of sorts. The multi-column is another. There might be others.
> > 
> > Those should probably be either in their own sub-menu, or the only ones in
> > the main Reports menu. Then the various useful reports one routinely
> > needs that are based off of those masters can be in the topic specific
> > sub-menus.
> > 
> > I don’t see the myriad of options as ‘gold plating’ I see them as making
> > the report more useful. (though obtuse as well)
> I apologize as I was using a very specific meaning from project
> management theory.  "*Gold plating* refers to the addition of any
> feature not considered in the original scope plan (PMBoK) or business
> case (Prince2) at any point of the *project* since it introduces a new
> source of risks to the original planning i.e. additional testing,
> documentation, costs, timelines, etc."
> 
> > Perhaps if some more routine and useful reports were created from this and
> > added to the relevant sub-menus, less people would need the ‘master
> > report’ though it can still be there for those who know how to wield its
> > power.
> Interesting thoughts.  Some of which have flowed past me in the last 24
> hours also.  My question is how you would limit the options for a
> Reconciliation Report for the user to configure while turning around and
> invoking the main report module?  I am not that savvy in Scheme to know
> how to do that.
> 
> The one thing we need to avoid is having the same code spread around in
> 4-5 different areas and having to update all when a fundamental bug or
> enhancement has to be made that affects all reports. 

I have a view similar to Adrien's. To me the code behind the current 
transaction report can be viewed as a fairly generic (transaction) reporting 
engine. I also think that was the intention of the developers that worked on 
it. GnuCash can't possibly provide specific reports for all use cases all 
around the world. So if none of the reports available gives the required 
result, the transaction report allows you to extract most (transaction) data 
in some form or another close to what you need.

As it's so generic in nature it can be used (by a coder) as a basis to build 
other reports on top off. The Income & GST report is currently such an 
example. It has removed a number of options compared to the transaction report 
(or more precisely it uses hardcoded defaults for these options).

I agree with Adrien it could be worth looking for common use cases that could 
be coded as simplified versions of the transaction report and add them as 
separate reports in the menus. From other discussions I take away a 
reconciliation report could be a potential candidate for example.

Regards,

Geert


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

Re: [GNC-dev] gnucash maint: Multiple changes pushed

[Derek Atkins]

HI,

On Wed, January 9, 2019 9:12 am, Geert Janssens wrote:
> I like the idea of caching the system locale for future use. Too bad the
> std::locale is working so poorly on Windows :(
>
> Op zondag 6 januari 2019 19:13:28 CET schreef John Ralls:
>> +const std::locale&
>> +gnc_get_locale()
>> +{
>> +  static std::locale cached;
>> +  static bool tried_already = false;
>
> If I understand it correctly using static variables makes the function
> unsuitable for multi-threading, right ?

Not necessarily.  There is a race condition on first-use, but beyond that
I don't see a MT issue here.  The data is read-only, right?  Multiple
threads could read from the same read-only data simultaneously, so that
should be fine.

Static data is ont MT-unsafe if it's being changed on a per-call basis
(e.g. a time_t -> string API returning a static string buffer).

> Any idea how difficult would it be to fix that ?

You could add a mutex around the initialization.  That's all I think you
would need here.

> I know GnuCash is not thread-safe by a long shot and gtk itself is single
> threaded so it doesn't matter that much.
>
> However I silently set a personal goal of changing that sometime. The C
> code
> is a lost cause IMO, but it might be worth to keep multi-threading in mind
> as
> we gradually convert to c++. In my basic understanding of threading this
> particular function should not be too hard to make tread safe.

-derek

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

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

Re: [GNC-dev] gnucash maint: Multiple changes pushed

[Geert Janssens]

I like the idea of caching the system locale for future use. Too bad the 
std::locale is working so poorly on Windows :(

Op zondag 6 januari 2019 19:13:28 CET schreef John Ralls:
> +const std::locale&
> +gnc_get_locale()
> +{
> +  static std::locale cached;
> +  static bool tried_already = false;

If I understand it correctly using static variables makes the function 
unsuitable for multi-threading, right ?

Any idea how difficult would it be to fix that ?

I know GnuCash is not thread-safe by a long shot and gtk itself is single 
threaded so it doesn't matter that much.

However I silently set a personal goal of changing that sometime. The C code 
is a lost cause IMO, but it might be worth to keep multi-threading in mind as 
we gradually convert to c++. In my basic understanding of threading this 
particular function should not be too hard to make tread safe.

Geert


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

Re: [GNC-dev] gnucash maint: Multiple changes pushed

[Geert Janssens]

Op dinsdag 1 januari 2019 22:14:16 CET schreef John Ralls:
> Updatedvia  https://github.com/Gnucash/gnucash/commit/3a105f07 
> (commit)
>via  https://github.com/Gnucash/gnucash/commit/95bee405 (commit)
>via  https://github.com/Gnucash/gnucash/commit/cc3bb4ef (commit)
>   from  https://github.com/Gnucash/gnucash/commit/0f53b6c8 (commit)
> 
> 
> 
> commit 3a105f0728984df7f063110acc8390c93722d581
> Author: John Ralls 
> Date:   Tue Jan 1 13:12:39 2019 -0800
> 
> Catch boost::locale character-conversion exceptions.
> 
> Partial cause of the crash reported in Bug 797002.
> 
I suppose you meant 796996 ?

Also it looks like you're really only catching the errors. The source of the 
conversion issue itself is not really determined yet ?

Geert


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