Re: gnucash master: Multiple changes pushed

[John Ralls]

> On Feb 21, 2017, at 9:16 AM, David T.  wrote:
> 
> 
>> On Feb 21, 2017, at 10:06 PM, John Ralls  wrote:
>> 
>> 
>>> On Feb 21, 2017, at 8:43 AM, Derek Atkins  wrote:
>>> 
>>> It's weird that this isn't caught by the *compiler* -- isn't an unused
>>> parameter a warning/error?
>> 
>> It is by default, but we turn it off in configure.ac lines 1570 (C++) and 
>> 1581 (C) because we have so many unused variables littering our code.
>> 
>> Regards,
>> John Ralls
> 
> John,
> 
> I’m not going to add much to this discussion, except to ask if the removal of 
> unused variables is: a) something worthy of doing, and b) something that 
> could be delegated to a non-programmer in such a way that they would not 
> *ahem* fuck things up worse? Iff both are true, then I would be willing to 
> take a stab in some way. But only if that actually helps with Real 
> Development, and doesn’t hurt the cause.

David,

Yes, cleanup would be worthwhile. It's time-consuming grunt-work.

I don't know if it's something that a non-programmer could do. It should be 
within the ability of a beginning programmer... The catch for a non-programmer 
is that there are cases where an unused variable is a function argument. Some 
functions have required argument lists even when those arguments aren't needed 
in the code at hand. In that case instead of deleting the argument you'd 
precede it with G_GNUC_UNUSED(). The difficulty for a non-programmer is in 
recognizing when to do that instead of removing the argument.

Regards,
John Ralls

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

Re: Missing Guile Bindings and False Positive Unit tests

[Ted Creedon]

FYI there is a swig problem in OpenSuse leap 4.2.

Its not the latest version.

Tedc

From: gnucash-devel  
on behalf of Derek Atkins 
Sent: Tuesday, February 21, 2017 8:59:27 AM
To: Chad Albers
Cc: gnucash-devel@gnucash.org
Subject: Re: Missing Guile Bindings and False Positive Unit tests

Hi Chad,

Please remember to CC gnucash-user on all replies so that everyone can
remain "in the loop".

Also, the gnc-modules should properly export swig-exported functions
without a re-export.  If it stopped doing that, that would be a bug
IMHO.

Note that these unit tests are probably 18 years old.


A long long time ago (well, around GnuCash 1.6 or so), /usr/bin/gnucash
was a guile script.  It loaded everything in as guile modules
(technically it loaded GncModules) and then jumped back and forth
between C and Scheme.  Still, not everything was available from Scheme,
but I don't believe anything has been *removed* from the guile
bindings.

Anyways, this structure was very hard to debug.  You couldn't
run it under gdb; you needed to "attach" gdb to the running process,
which made it nearly impossible to debug issues during application
loading.  Eventually the Schemer developers left the project to pursue
other endeavors, and those that remained eventually switched back to the
"main() in C" structure that we have today.

Of course a bunch of the functionality is still in GncModules.


Having said all that, you shouldn't need to export or re-export a
wrapped API.  It should "just work".  And the unit tests should be
properly failing when there are missing or broken APIs.

-derek

Chad Albers  writes:

> I'll file a bug report.
>
> But, for the record, swig isn't exporting.  That's not what swig does.
>   Function exports are done by using 2 APIs - the Guile define-modules
> API or Guiles' C API.
>
> For example,
>
> - Some guile functions are defined here:  src/engine/swig-engine.c.
> This is where qof-session-new is defined.
> - swig-engine.c uses Guile's C API to create a module called sw_engine
> - swig-engine.c exports the functions - including qof-session-new -
> using scm_c_export(...)
> - Several Guile scm files use this module: (use-modules (sw_engine)).
> None of these scm files either (export...) or (re-export...) functions
> from the sw_engine module.
>
> Therefore, none of the Guile  defined modules expose sw_engine functions.
>
> There may be, though, one exception, but even that isn't exposing
> anything from sw_engine.  The following is speculation...
>
> - GnuCash seems to include, what I suspect, is another module system.
> I think it's in the module (gnucash gnc-module).  Calls such as these
> -   (gnc:module-system-init) - may be a part that system.
> - Included in that system may be code from: src/engine/gncmod-engine.c
> - This C code has a C function  called 'libgncmod_engine_gnc_module_init(...)
> - This includes the sw_engine module.  It calls
> scm_c_eval_string("(use-modules (sw_engine))");
> - This scm_c_eval_string does not include any (exports...) or
> (re-exports...) in the gncmode-engine.c file.
>
> Therefore, the sw_engine functions are not available in this other
> module system.
>
> To make the sw_engine functions available (which is what I would
> like),  this may have been how it was once accomplished. The units
> test that pass when they shouldn't include this line:
>
>  (gnc:module-load "gnucash/engine" 0)
>
> Maybe, at one time gnc:module-load exported functions from
> "gnucash/engine" modules.  Or something like that.  I'm still
> investigating the what/why/how of the other module system.
>
> In the meantime, one solution is just to re-export sw_engine functions
> from (gnucash engine) or engine.scm.  That's what I'm doing for my
> experiments, and it works.  Perhaps I will submit a patch for that,
> but I'm thinking that that's a hack. I'm opening up the discussion
> here for a better solution, if exposing more of the Guile API is a)
> fixing a bug and/or b) adding a new feature.  Since much of GnuCash
> was written in Guile, I thought I would use that instead of Python.
> As is, though, there doesn't seem to be a way to even source a GnuCash
> using its Guile bindings.  It can be done using Python.
>
> Chad
>
> --
>
> On Sun, Feb 19, 2017 at 5:34 PM, Derek Atkins  wrote:
>> That srfi didn't exist when the tests were written, which was probably
>> around 18 years ago.  The fact the tests don't fail just means nobody tested
>> the tests for false positives.  Please file a bug report?
>>
>> There isn't a need to be-export.  Swig exports do that automatically.
>>
>> -derek
>>
>> Sent from my mobile device. Please excuse any typos.
>>
>> - Reply message -
>> From: "Chad Albers" 
>> To: "Derek Atkins" 
>> Subject: Missing Guile Bindings and False Positive Unit tests
>> Date: Sun, Feb 

Re: Eclipse CDT IDE

[Ted Creedon]

Derick

No I just thought you might be interested.

I use my own builder shell script, not the built ins for heimdal + oafs.

That solved many problems.

The FIXME suggestions are a great help in cleaning up old code.

ted

From: Geert Janssens 
Sent: Tuesday, February 21, 2017 9:14:59 AM
To: gnucash-devel@gnucash.org
Cc: Ted Creedon
Subject: Re: Eclipse CDT IDE

Op dinsdag 21 februari 2017 16:38:10 CET schreef Ted Creedon:
> Just a suggestion,
>
> I've finally succeeded in  getting openafs up under the IBM eclipse IDE.
>
> Its my opinion that the task/team/remote debugging  feature would reduce
> support effort considerably.
>
> I encourage experimenting with it.
>
> Tedc

Heh, I've been using Eclipse for a couple of years now. For me it's a mixed
success.

It's pretty convenient when it works as intended. Then I found it slow for
certain things so I learned the command line equivalents and ended up using
the IDE as an intelligent text editor. "Intelligent" because it does real time
code analysis and comes with pop-up help while moving the mouse over words.

However it happened more than once that an Eclipse update breaks my complete
setup and I have to spend hours getting it working properly again. And that's
getting tiresome.

This week still an update suddenly lost the complete index of all referenced
functions and variables. So all my code was full of red markers, suggestions
and inline help stopped working. Most of it was fixed by restoring the search
path for includes. But this shouldn't have happened in the first place.

And what's worse, Eclipse still refuses to include one of my own (gnucash)
header files in its index, so each parameter I'm using from that file is
unknown. I've already spent a couple of hours -again- to try and resolve this.

And so this week I finally gave up on Eclipse. I'm currently experimenting
with KDevelop which has similar features. I'll see how it will go.

Regardless, I'm glad Eclipse is improving your life!

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

Re: gnucash master: Multiple changes pushed

[David T. via gnucash-devel]

> On Feb 21, 2017, at 10:06 PM, John Ralls  wrote:
> 
> 
>> On Feb 21, 2017, at 8:43 AM, Derek Atkins  wrote:
>> 
>> It's weird that this isn't caught by the *compiler* -- isn't an unused
>> parameter a warning/error?
> 
> It is by default, but we turn it off in configure.ac lines 1570 (C++) and 
> 1581 (C) because we have so many unused variables littering our code.
> 
> Regards,
> John Ralls

John,

I’m not going to add much to this discussion, except to ask if the removal of 
unused variables is: a) something worthy of doing, and b) something that could 
be delegated to a non-programmer in such a way that they would not *ahem* fuck 
things up worse? Iff both are true, then I would be willing to take a stab in 
some way. But only if that actually helps with Real Development, and doesn’t 
hurt the cause.

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

Re: Eclipse CDT IDE

[Geert Janssens]

Op dinsdag 21 februari 2017 16:38:10 CET schreef Ted Creedon:
> Just a suggestion,
> 
> I've finally succeeded in  getting openafs up under the IBM eclipse IDE.
> 
> Its my opinion that the task/team/remote debugging  feature would reduce
> support effort considerably.
> 
> I encourage experimenting with it.
> 
> Tedc

Heh, I've been using Eclipse for a couple of years now. For me it's a mixed 
success.

It's pretty convenient when it works as intended. Then I found it slow for 
certain things so I learned the command line equivalents and ended up using 
the IDE as an intelligent text editor. "Intelligent" because it does real time 
code analysis and comes with pop-up help while moving the mouse over words.

However it happened more than once that an Eclipse update breaks my complete 
setup and I have to spend hours getting it working properly again. And that's 
getting tiresome.

This week still an update suddenly lost the complete index of all referenced 
functions and variables. So all my code was full of red markers, suggestions 
and inline help stopped working. Most of it was fixed by restoring the search 
path for includes. But this shouldn't have happened in the first place.

And what's worse, Eclipse still refuses to include one of my own (gnucash) 
header files in its index, so each parameter I'm using from that file is 
unknown. I've already spent a couple of hours -again- to try and resolve this.

And so this week I finally gave up on Eclipse. I'm currently experimenting 
with KDevelop which has similar features. I'll see how it will go.

Regardless, I'm glad Eclipse is improving your life!

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

Re: gnucash master: Multiple changes pushed

[John Ralls]

> On Feb 21, 2017, at 8:43 AM, Derek Atkins  wrote:
> 
> Geert Janssens  > writes:
> 
>> Hi John,
>> 
>> Op maandag 20 februari 2017 19:06:19 CET schreef John Ralls:
>> 
>>> @@ -246,7 +246,7 @@ inline GncRational operator+(GncRational a, GncInt128 b)
>>> }
>>> inline GncRational operator+(GncInt128 a, GncRational b)
>>> {
>>> -return b + GncRational(a, 1);
>>> +return GncRational(a, 1) + a;
>>> }
>> 
>> Looks like one more copy/paste error or typo...
>> return GncRational(a, 1) + *b*;
>> 
>> It's weird this isn't caught in our unit tests (unless this is not
>> specifically tested for yet).
> 
> It's weird that this isn't caught by the *compiler* -- isn't an unused
> parameter a warning/error?

It is by default, but we turn it off in configure.ac lines 1570 (C++) and 1581 
(C) because we have so many unused variables littering our code.

Regards,
John Ralls

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

Re: gnucash master: Multiple changes pushed

[Geert Janssens]

Op dinsdag 21 februari 2017 11:43:35 CET schreef Derek Atkins:
> Geert Janssens  writes:
> > Hi John,
> > 
> > Op maandag 20 februari 2017 19:06:19 CET schreef John Ralls:
> >> @@ -246,7 +246,7 @@ inline GncRational operator+(GncRational a, GncInt128
> >> b) }
> >> 
> >>  inline GncRational operator+(GncInt128 a, GncRational b)
> >>  {
> >> 
> >> -return b + GncRational(a, 1);
> >> +return GncRational(a, 1) + a;
> >> 
> >>  }
> > 
> > Looks like one more copy/paste error or typo...
> > return GncRational(a, 1) + *b*;
> > 
> > It's weird this isn't caught in our unit tests (unless this is not
> > specifically tested for yet).
> 
> It's weird that this isn't caught by the *compiler* -- isn't an unused
> parameter a warning/error?
> 
> -derek

Good point. I went back to the ubuntu build of which I still had the build 
log. There was no warning for this.

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

Re: Missing Guile Bindings and False Positive Unit tests

[Derek Atkins]

Hi Chad,

Please remember to CC gnucash-user on all replies so that everyone can
remain "in the loop".

Also, the gnc-modules should properly export swig-exported functions
without a re-export.  If it stopped doing that, that would be a bug
IMHO.

Note that these unit tests are probably 18 years old.


A long long time ago (well, around GnuCash 1.6 or so), /usr/bin/gnucash
was a guile script.  It loaded everything in as guile modules
(technically it loaded GncModules) and then jumped back and forth
between C and Scheme.  Still, not everything was available from Scheme,
but I don't believe anything has been *removed* from the guile
bindings.

Anyways, this structure was very hard to debug.  You couldn't
run it under gdb; you needed to "attach" gdb to the running process,
which made it nearly impossible to debug issues during application
loading.  Eventually the Schemer developers left the project to pursue
other endeavors, and those that remained eventually switched back to the
"main() in C" structure that we have today.

Of course a bunch of the functionality is still in GncModules.


Having said all that, you shouldn't need to export or re-export a
wrapped API.  It should "just work".  And the unit tests should be
properly failing when there are missing or broken APIs.

-derek

Chad Albers  writes:

> I'll file a bug report.
>
> But, for the record, swig isn't exporting.  That's not what swig does.
>   Function exports are done by using 2 APIs - the Guile define-modules
> API or Guiles' C API.
>
> For example,
>
> - Some guile functions are defined here:  src/engine/swig-engine.c.
> This is where qof-session-new is defined.
> - swig-engine.c uses Guile's C API to create a module called sw_engine
> - swig-engine.c exports the functions - including qof-session-new -
> using scm_c_export(...)
> - Several Guile scm files use this module: (use-modules (sw_engine)).
> None of these scm files either (export...) or (re-export...) functions
> from the sw_engine module.
>
> Therefore, none of the Guile  defined modules expose sw_engine functions.
>
> There may be, though, one exception, but even that isn't exposing
> anything from sw_engine.  The following is speculation...
>
> - GnuCash seems to include, what I suspect, is another module system.
> I think it's in the module (gnucash gnc-module).  Calls such as these
> -   (gnc:module-system-init) - may be a part that system.
> - Included in that system may be code from: src/engine/gncmod-engine.c
> - This C code has a C function  called 'libgncmod_engine_gnc_module_init(...)
> - This includes the sw_engine module.  It calls
> scm_c_eval_string("(use-modules (sw_engine))");
> - This scm_c_eval_string does not include any (exports...) or
> (re-exports...) in the gncmode-engine.c file.
>
> Therefore, the sw_engine functions are not available in this other
> module system.
>
> To make the sw_engine functions available (which is what I would
> like),  this may have been how it was once accomplished. The units
> test that pass when they shouldn't include this line:
>
>  (gnc:module-load "gnucash/engine" 0)
>
> Maybe, at one time gnc:module-load exported functions from
> "gnucash/engine" modules.  Or something like that.  I'm still
> investigating the what/why/how of the other module system.
>
> In the meantime, one solution is just to re-export sw_engine functions
> from (gnucash engine) or engine.scm.  That's what I'm doing for my
> experiments, and it works.  Perhaps I will submit a patch for that,
> but I'm thinking that that's a hack. I'm opening up the discussion
> here for a better solution, if exposing more of the Guile API is a)
> fixing a bug and/or b) adding a new feature.  Since much of GnuCash
> was written in Guile, I thought I would use that instead of Python.
> As is, though, there doesn't seem to be a way to even source a GnuCash
> using its Guile bindings.  It can be done using Python.
>
> Chad
>
> --
>
> On Sun, Feb 19, 2017 at 5:34 PM, Derek Atkins  wrote:
>> That srfi didn't exist when the tests were written, which was probably
>> around 18 years ago.  The fact the tests don't fail just means nobody tested
>> the tests for false positives.  Please file a bug report?
>>
>> There isn't a need to be-export.  Swig exports do that automatically.
>>
>> -derek
>>
>> Sent from my mobile device. Please excuse any typos.
>>
>> - Reply message -
>> From: "Chad Albers" 
>> To: "Derek Atkins" 
>> Subject: Missing Guile Bindings and False Positive Unit tests
>> Date: Sun, Feb 19, 2017 5:23 PM
>>
>> Definitely, though, the unit tests it is checking is
>> 'qof-session-new'.  It passes, but it hasn't been exported in the
>> Guile code.
>>
>> At one time, I think it was exported from this file:
>> 'src/mine/gnucash/src/engine/engine.scm'  This file includes the
>> (sw_engine) module (defined in Guile C API), but it does not "(export
>> qof-session-new)" or "(re-export 

Re: Eclipse CDT IDE

[Derek Atkins]

Ted,

Ted Creedon  writes:

> Just a suggestion,
>
> I've finally succeeded in  getting openafs up under the IBM eclipse IDE.
>
> Its my opinion that the task/team/remote debugging feature would
> reduce support effort considerably.
>
> I encourage experimenting with it.

I think you mixed OpenAFS and GnuCash projects??

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

-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

Re: gnucash master: Multiple changes pushed

[Derek Atkins]

Geert Janssens  writes:

> Hi John,
>
> Op maandag 20 februari 2017 19:06:19 CET schreef John Ralls:
>
>> @@ -246,7 +246,7 @@ inline GncRational operator+(GncRational a, GncInt128 b)
>> }
>>  inline GncRational operator+(GncInt128 a, GncRational b)
>>  {
>> -return b + GncRational(a, 1);
>> +return GncRational(a, 1) + a;
>>  }
>
> Looks like one more copy/paste error or typo...
> return GncRational(a, 1) + *b*;
>
> It's weird this isn't caught in our unit tests (unless this is not
> specifically tested for yet).

It's weird that this isn't caught by the *compiler* -- isn't an unused
parameter a warning/error?

-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

Eclipse CDT IDE

[Ted Creedon]

Just a suggestion,

I've finally succeeded in  getting openafs up under the IBM eclipse IDE.

Its my opinion that the task/team/remote debugging  feature would reduce 
support effort considerably.

I encourage experimenting with it.

Tedc

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

Re: gnucash master: Multiple changes pushed

[Geert Janssens]

Op dinsdag 21 februari 2017 07:07:58 CET schreef John Ralls:
> Interesting. I didn't get that particular failure on Travis; I got it on my
> local Ubuntu 14.04 VM which I use to debug Travis failures. It didn't even
> occur to me that the exception (which isn't the one the standard requires
> and which it doesn't throw when one compiles with -O0 -g) was caused by an
> uninstalled language.
> 
> Yes, please do push it.

Done. I learned from this the C++ locale code is pickier about locale names 
than the C code is. "fr_FR" doesn't exist as a locale on travis and my Ubuntu 
14.04 VM, but "fr_FR.utf8" does. The C++ code only accepted the latter, where 
our C tests were equally happy with the former.

I've also pushed a followup commit for the operator typo.

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

Re: cpp branch

[Geert Janssens]

Op dinsdag 21 februari 2017 11:33:08 CET schreef Robert Fewell:
> Geert,
> 
> Just an observation, when I do an import and select the date column first
> with an invalid default format, the view goes red and the error message
> tells me what is wrong. At the same time I ended up with 20 WARN messages,
> one for each line in the trace file. I was wondering if
> gnc_dmy2timespec_neutral should have an extra parameter to suppress the
> WARN messages in this use. I can not really decide whether this is
> worthwhile or not.
> 
> Bob

Bob,

Yes, I have seen those warnings also. They have started when John fixed the c 
interface to no longer throw exceptions.

I don't think we should add an extra parameter to gnc_dmy2timespec_neutral 
though.

IMO the fix is to integrate the functionality of that function directly into 
GncDateTime in a way that does throw exceptions on failure. I haven't 
investigated the best way to do this yet. An initial idea is to add a 
constructor to GncDateTime that takes a day, month, year and an extra enum 
argument (START, END, NEUTRAL) and generate the appropriate time depending on 
this. Optionally this constructor could also be overloaded to accept a GncDate 
and the enum for the same result.

Then we can make gnc_dmy2timespec_neutral just call into GncDateTime and 
handle the exceptions for the c code.

C++ code on the other hand should use the appropriate GncDateTime constructor 
and handle any exception thrown.

I didn't say it with so many words in bug 778982 [1], but it was and still is 
my intention to do this as part of solving this bug.

Geert

[1] https://bugzilla.gnome.org/show_bug.cgi?id=778982
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnc-numeric

[Geert Janssens]

Op dinsdag 21 februari 2017 11:18:38 CET schreef Robert Fewell:
> Hi,
> 
> Just built from master with all the new changes but had to change
> gnc-numeric.cpp line 86 from isnan(d)  to std::isnan(d), gcc version 4.9.4
> 
> After change all built successfully.

Interestingly, I don't need to do this on neither of my Fedora 25 machine (gcc 
6.3.1) nor on travis (gcc 4.8.x)

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

Re: gnucash master: Multiple changes pushed

[Geert Janssens]

Hi John,

Op maandag 20 februari 2017 19:06:19 CET schreef John Ralls:

> @@ -246,7 +246,7 @@ inline GncRational operator+(GncRational a, GncInt128 b)
> }
>  inline GncRational operator+(GncInt128 a, GncRational b)
>  {
> -return b + GncRational(a, 1);
> +return GncRational(a, 1) + a;
>  }

Looks like one more copy/paste error or typo...
return GncRational(a, 1) + *b*;

It's weird this isn't caught in our unit tests (unless this is not specifically 
tested for yet).


> diff --git a/src/libqof/qof/test/gtest-gnc-numeric.cpp
> b/src/libqof/qof/test/gtest-gnc-numeric.cpp index 9ba7a68..34f56b1 100644
> --- a/src/libqof/qof/test/gtest-gnc-numeric.cpp
> +++ b/src/libqof/qof/test/gtest-gnc-numeric.cpp
> @@ -211,6 +211,16 @@ TEST(gncnumeric_stream, output_stream)
>  GncNumeric rational_string(123, 456);
>  output << rational_string;
>  EXPECT_EQ("123/456", output.str());
> +output.imbue(std::locale("de_DE"));

I was going to suggest using fr_FR here instead of de_DE, because the latter is 
not installed by 
default on travis and we explicitly install the former. However  I also see you 
are excluding this 
test from travis due to bugs in gcc 4.8 in your followup commit.

I was curious enough to run a couple of tests on this and these are my findings:
- I had to include the typeinfo header in gnc-numeric.hpp or it wouldn't 
compile due to 
std::bad_cast not being defined. With the typeinfo header included it builds, 
however tests still 
fail
- Using "fr_FR" instead of de_DE also fails with "invalid locale name", however 
the function does 
accept "fr_FR.utf8"

> +output.str("");
> +output << simple_int;
> +EXPECT_EQ("123456", output.str());

- Finally the French locale uses a thousands separator, so the expected output 
for a simple 
integer should have one as well

I have pushed these changes to my personal github repo [1] (after reverting 
your last commit) 
and with this travis completes all tests without error [2]

I'm holding off to pushing the same to the gnucash repo until you had a chance 
to provide your 
thoughts on this.

Regards,

Geert

[1] https://github.com/gjanssens/gnucash/commit/
888cc8dae6492c52c3cdef652138ebcc60af6c3b
[2] https://travis-ci.org/gjanssens/gnucash/builds/203811458
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnc-numeric

[Matthew Forbis via gnucash-devel]

On a similiar but slightly unrelated note, on commit 
https://github.com/Gnucash/gnucash/commit/e322457e , under functioninline 
GncRational operator+(GncInt128 a, GncRational b), I think it possibly should 
be 


| - return b + GncRational(a, 1);  |
|

+ return GncRational(a, 1) + b; 

instead of 


| - return b + GncRational(a, 1);  |
|

+ return GncRational(a, 1) + a;
Matt


  From: Robert Fewell <14ubo...@gmail.com>
 To: "gnucash-devel@gnucash.org"  
 Sent: Tuesday, February 21, 2017 5:18 AM
 Subject: gnc-numeric
   
Hi,

Just built from master with all the new changes but had to change
gnc-numeric.cpp line 86 from isnan(d)  to std::isnan(d), gcc version 4.9.4

After change all built successfully.

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: cpp branch

[Robert Fewell]

Geert,

Just an observation, when I do an import and select the date column first
with an invalid default format, the view goes red and the error message
tells me what is wrong. At the same time I ended up with 20 WARN messages,
one for each line in the trace file. I was wondering if
gnc_dmy2timespec_neutral should have an extra parameter to suppress the
WARN messages in this use. I can not really decide whether this is
worthwhile or not.

Bob

On 20 February 2017 at 19:54, Geert Janssens 
wrote:

> Op vrijdag 17 februari 2017 22:09:00 CET schreef Geert Janssens:
> > Op zondag 12 februari 2017 11:50:35 CET schreef Robert Fewell:
> > > Geert,
> > >
> > > OK I got your latest changes and all built and ran OK. Needed to reread
> > > your comment about dates as I could not see what gnc_numeric had to do
> > > with
> > > it !!
> >
> > Well, they don't. I'm mixing two issues in one...
> >
> > > Some changes I think required.
> > > 1. The initial text on the assistant page.
> >
> > Indeed. Things have changed since you last updated this text.
> >
> > > 2. If you have selected an account in the combo and then choose to
> select
> > > a
> > > column instead, the combo should return back to blank
> > >
> > >  as it does in the opposite direction.
> >
> > Good catch. At some point it did behave like that. It seems one of my
> more
> > recent refactorings broke this.
> >
> > > 3.If you open a csv with a semicolon separator, tick the semicolon
> > > setting,
> > > then the fixed-width setting and now back to separators the preview
> does
> > > not reformat with the semicolon separator.
> > > Not sure if it should or the separator choice should revert back to
> > > default.
> > Another good catch. I think it should reformat using the semicolon
> > separator. I'll add this to my list of things to fix.
> >
> >
> > Meanwhile I have also managed to fix the multi-byte splitting issue in
> the
> > fixed width tokenizer. I can't produce invalid characters any more by
> > splitting in the middle of a multi-byte character.
> >
> > And the newlines are being stripped as well.
> >
> > Left to do are the points you bring up above, catching date parsing
> errors
> > and using GncNumeric instead of gnc_numeric.
> >
> All the points left to do have been dealt with.
>
> - The intro text on the start page has been updated
> - base account is reset when an account is set in the preview data
> - separator settings are restored when switching back from fw to separated
> - date parsing errors are properly caught
> - I have run tests with GncNumeric and provided some feedback on John's
> branch
> thanks to this
>
> While there are still some improvements possible I have decided it's time
> to
> merge this work into master. And that's what I've just done. This work
> moves
> quite some files around so if you pull in these changes you may need to
> clean
> your workspace and build environment and rerun autogen.sh/configure. I
> believe
> cmake properly detects the changes and will rerun automatically.
>
> To all: please do test and report any issues you find!
>
> Geert
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

gnc-numeric

[Robert Fewell]

Hi,

Just built from master with all the new changes but had to change
gnc-numeric.cpp line 86 from isnan(d)  to std::isnan(d), gcc version 4.9.4

After change all built successfully.

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