Re: gnucash unstable: Multiple changes pushed

[Aaron Laws]

On Fri, Dec 29, 2017 at 12:06 PM, Aaron Laws <dartm...@gmail.com> wrote:

> Ok, that's a good motivation. Just to be clear for me, having a function
>> static is different from having a static variable, right ? As I
>> understand it
>> the latter is bad for thread safety, the former only ensures its local
>> scope.
>
>
> There two "static"s to keep in mind: static storage duration, and members
> not bound to instances. Static functions are functions that can't be used
> outside the current code file:
>
> static void func () { printf ("can't be used outside " __FILE__); }
> (or something like that.)
>
> I should have also said that this first type of static can be applied to
variables, too!

static int my_int; // can only be used in this translation unit: __FILE__.

I hope I answered your question and didn't add confusion!
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash unstable: Multiple changes pushed

[Aaron Laws]

>
> Ok, that's a good motivation. Just to be clear for me, having a function
> static is different from having a static variable, right ? As I understand
> it
> the latter is bad for thread safety, the former only ensures its local
> scope.


There two "static"s to keep in mind: static storage duration, and members
not bound to instances. Static functions are functions that can't be used
outside the current code file:

static void func () { printf ("can't be used outside " __FILE__); }
(or something like that.)

But very different is:

struct A { int a;  static int s_a; };
int A::s_a = 0;
int main () {
   printf ("%d is accessible.\n", A::s_a);
   //printf ("%d\n", A::a); this is illegal
   return 0;
}

Here, A::s_a can be accessed without ever creating an instance of "A".
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash unstable: Multiple changes pushed

[Aaron Laws]

On Fri, Dec 29, 2017 at 11:22 AM, John Ralls  wrote:

>
>
> I think that we should remove -Wno-unused from CXXFLAGS in general and
> only use it where needed on external sources. GnuCash C++ code is all new
> and it should all compile clean. For that code the more warnings the
> better: It gets the compiler to help us write better code.


I agree. I use '-Wall -Wextra -Wpedantic -Wconversion -Werrro' in my
projects (because -Wall is really -Wsome), but adding them to old code can
result in quite a mess.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Beyond 2.8 - versioning

[Aaron Laws]

On Wed, Dec 27, 2017 at 12:19 PM, Geert Janssens <geert.gnuc...@kobaltwit.be
> wrote:

> Op dinsdag 26 december 2017 00:36:04 CET schreef Aaron Laws:
> > Concerning the versioning scheme: I agree that the leading "2" is rather
> > superfluous at this point; if we're not going to use it, get rid of it. I
> > *do* appreciate the even/odd versioning scheme. It has a few strong
> points:
> > 1) it's easy at a glance to tell which version is stable and 2) it's easy
> > to explain and use.
>
> Thanks for your feedback Aaron.
>
> We are used to the even/odd scheme. There are other projects that have
> always
> used the "unstable=.99" scheme. Once you know it it's equally easy to
> explain,
> no ?
> If we would go to a two-number scheme for stable it would feel weird to me
> if
> the first number would distinguish between even and odd, like
> 3.0 is unstable and 4.0 is stable. For me that doesn't work very well.
>
> Geert
>

I re-read your version numbering proposals and on second thought, I agree
that they are simple and effective enough. Again, thanks for your proactive
thoughtfulness.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Beyond 2.8 - namespaces

[Aaron Laws]

On Mon, Dec 25, 2017 at 6:26 PM, John Ralls  wrote:

>
>
> > On Dec 25, 2017, at 1:01 PM, Lincoln A Baxter 
> wrote:
> >
> > On Mon, 2017-12-25 at 17:34 +0100, Geert Janssens wrote:
> >> Agreed indeed. For example in my work on the importers I have
> >> introduced a
> >> strict separation of import functionality and gui. So the non-gui
> >> parts of the
> >> importer should move to libgnucash eventually as I want them to
> >> bepart of the
> >> api. That way they can be used by other applications (mobile apps,
> >> web
> >> app,...) and would be available to the bindings as well.
> >
> > First, let me say, I have been using GC since at least 2005, and I've
> > only recently begun following the dev list.That said, I have a lot
> > of experience in application/solution and n-tier client/server
> > architectures at the corporate level... so please take this as just
> > something to consider...
> >
> > As I was reading this thread, and thinking about this C++ refactoring,
> > a question occurred to me, which a little bit relates to Geert's above
> > quoted paragraph.
> >
> > Has anyone thought about separating the UI functionality from
> > application functionality using a (restful) services interface between
> > the GUI and the "library" (application logic)?
> >
> > The interface to the library would not have to be implemented as
> > services (initially), but if it were thought of this way, one might be
> > able to separate out UI functionality from application functionality
> > pretty completely... eventually anyway.
> >
> > Might this be a way to eventually move to a multiuser environment,
> > which comes up not infrequently on the user list?  With this approach,
> > the "server side" could still keep the entire model in memory.  If so,
> > I would think this might influence what goes into libgnucash?
> >
> > I suspect this approach could eventually help facilitating multiple
> > front-side UI's but common logic on the back-side  I think this would
> > allow one to eventually move to a browser based UI.
> >
> > One would not have to go "all the way" initially, but if this were a
> > paradigm for choosing what goes where, GC would be able to migrate to
> > such an architecture over time.
> >
> > Just a thought, FWIW.
>
> Except for the RESTful part, yes. MVC separation has been one of the
> development goals for years. We're severely constrained in developer hours
> so unfortunately it's likely to be a goal for many years to come.
>
> Regards,
> John Ralls
>

I've always assumed (and I think I'm with the development team in this
pattern of thought) that the mechanism of connecting the front and back
ends together would be same-process function calls. That means that if a
"desktop" user and web user both want to interact with gnucash data, there
would be two separate processes involved either both able to see the
database file (in the case of sqlite) or both connecting to the database
(mysql, postgres, etc.), and using synchronization mechanisms at the
database level.

I hadn't thought about creating a client/sever model within gnucash: having
a gnucash server process connected to the data store exposing its own REST
endpoints and clients (web, desktop, mobile, etc.) communicating with that
server process via REST. I don't think it's a good idea, but it's worth
thinking about. It would, of course, require a casual user (single desktop
user with one data file) to have to have a server and client process
running. In general, I think it would be a needless source of complexity
since the earlier approach I mentioned (single-processes communicating with
the database directly) works just fine.

Of course, other problem spaces benefit greatly from this sort of
client/server divide, but that tends to be the case when the client code is
unknown and wildly variable. Think Google maps API where any Joe can write
up a client and needs a generic way to interact with the maps API. I don't
think it's too much burden to expect someone writing a gnucash front end to
have to link to the gnucash engine, and I think this level of flexibility
is not valuable to Gnucash.

That said, as Mr. Ralls mentioned, separation of business logic and GUI
logic is a high-priority development goal, but happens to be a colossal
task in Gnucash.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Difficulty with apps-utils

[Aaron Laws]

On Wed, Nov 8, 2017 at 4:26 PM, Aaron Laws <dartm...@gmail.com> wrote:

>
> Hi Aaron,
>>
>> Since test-app-utils uses guile, you can't execute that test from the
>> build/bin directory without setting up the Guile environment. Look into
>> the Testing/Temporary/LastTest.log file to retreive the command
>> you need. For me, this command is
>>
>> cmake "-E" "env" "GNC_BUILDDIR=$GNUCASH_BUILD" "GNC_UNINSTALLED=yes" \
>>   "GNC_BUILDDIR=$GNUCASH_BUILD" "GUILE_WARN_DEPRECATED=no" \
>>   "LD_LIBRARY_PATH=$GNUCASH_BUILD/lib:$GNUCASH_BUILD/lib/gnucash" \
>>   "GNC_MODULE_PATH=$GNUCASH_BUILD/lib:$GNUCASH_BUILD/lib/gnucash" \
>>   "GUILE=/usr/bin/guile" "GUILE_LOAD_COMPILED_PATH=$GNU
>> CASH_BUILD/lib/gnucash/scm/ccache/2.0" \
>>   "GUILE_LOAD_PATH=$GNUCASH_SRC/libgnucash/app-utils/test/mod-
>> foo:$GNUCASH_SRC/libgnucash/app-utils/test/mod-bar:$GNUCASH_
>> SRC/libgnucash/app-utils/test/mod-baz" \
>>   "$GNUCASH_BUILD/bin/test-app-utils"
>>
>> where I have substituted $GNUCASH_BUILD and $GNUCASH_SRC for my
>> directory details.  But you can just cut-n-paste whatever command
>> is in LastTest.log to run the test.
>>
>> When I clone and build your branch on Fedora 26 (gcc 7.1.1), I
>> get this message in my LastTest.log and when running the above
>> cmake command by hand:
>>
>> Output:
>> --
>> /app-utils/option-util/Option DB Load: **
>> ERROR:/home/robg/gnucash/libgnucash/app-utils/test/test-option-util.cpp:98:void
>> test_option_load(Fixture*, gconstpointer): assertion failed
>> (gnc_option_db_lookup_string_option (odb, "Business", "Company Name",
>> FALSE) == "Bogus Company"): ("" == "Bogus Company")
>> Child aborted
>>
>> I also get a segfault in test-engine after gnc-budget_set_account_period_
>> value()
>>
>> What do you see in your Testing/Temporary/LastTest.log?
>>
>> Regards,
>>
>> Rob
>>
>
> Excellent suggestion; thanks! I'm not in a position to run it now and give
> feedback, but I should tomorrow.
>

With your suggestion, I was able to find the incorrect kvp invocation, and
it's running now. Thanks again!
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Difficulty with apps-utils

[Aaron Laws]

> Hi Aaron,
>
> Since test-app-utils uses guile, you can't execute that test from the
> build/bin directory without setting up the Guile environment. Look into
> the Testing/Temporary/LastTest.log file to retreive the command
> you need. For me, this command is
>
> cmake "-E" "env" "GNC_BUILDDIR=$GNUCASH_BUILD" "GNC_UNINSTALLED=yes" \
>   "GNC_BUILDDIR=$GNUCASH_BUILD" "GUILE_WARN_DEPRECATED=no" \
>   "LD_LIBRARY_PATH=$GNUCASH_BUILD/lib:$GNUCASH_BUILD/lib/gnucash" \
>   "GNC_MODULE_PATH=$GNUCASH_BUILD/lib:$GNUCASH_BUILD/lib/gnucash" \
>   "GUILE=/usr/bin/guile" "GUILE_LOAD_COMPILED_PATH=$
> GNUCASH_BUILD/lib/gnucash/scm/ccache/2.0" \
>   "GUILE_LOAD_PATH=$GNUCASH_SRC/libgnucash/app-utils/test/mod-
> foo:$GNUCASH_SRC/libgnucash/app-utils/test/mod-bar:$
> GNUCASH_SRC/libgnucash/app-utils/test/mod-baz" \
>   "$GNUCASH_BUILD/bin/test-app-utils"
>
> where I have substituted $GNUCASH_BUILD and $GNUCASH_SRC for my
> directory details.  But you can just cut-n-paste whatever command
> is in LastTest.log to run the test.
>
> When I clone and build your branch on Fedora 26 (gcc 7.1.1), I
> get this message in my LastTest.log and when running the above
> cmake command by hand:
>
> Output:
> --
> /app-utils/option-util/Option DB Load: **
> ERROR:/home/robg/gnucash/libgnucash/app-utils/test/test-option-util.cpp:98:void
> test_option_load(Fixture*, gconstpointer): assertion failed
> (gnc_option_db_lookup_string_option (odb, "Business", "Company Name",
> FALSE) == "Bogus Company"): ("" == "Bogus Company")
> Child aborted
>
> I also get a segfault in test-engine after gnc-budget_set_account_period_
> value()
>
> What do you see in your Testing/Temporary/LastTest.log?
>
> Regards,
>
> Rob
>

Excellent suggestion; thanks! I'm not in a position to run it now and give
feedback, but I should tomorrow.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Difficulty with apps-utils

[Aaron Laws]

On Tue, Nov 7, 2017 at 10:24 AM, John Ralls <jra...@ceridwen.us> wrote:
>
> > On Nov 7, 2017, at 5:49 AM, Aaron Laws <dartm...@gmail.com> wrote:
> >
> > I have made several changes on my branch to avoid kvp parsing keys. The
> > last change I made removes the functions that take char*, but the unit
> test
> > suite does not pass. All tests pass except app-utils which fails with the
> > strange error:
> >
> > (./test-app-utils:6860): gnc.module-WARNING **: Could not locate module
> > gnucash/app-utils interface v.0
> >
> > You can see my code at
> >
> > https://github.com/limitedatonement/gnucash/tree/fix_bayes
> >
> > Can anyone reproduce the problem? Any suggestions?
>
> I dunno if it’s strange. It means that it can’t find
> libgncmod-app-utils.so either because the path isn’t included in
> GNC_MODULE_PATH or because it’s not built yet.
>
> Regards,
> John Ralls
>

The reason it's strange is because the last commit (without which this
problem is not manifest) doesn't seem to have anything to do with this
library. The file you mentioned is still at build/lib/gnucash as it is in
the last known working commit (HEAD^)...none of the other configuration is
different? I'm at a loss.

I'm heading away for a day, but I'll continue to experiment when I get back.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Difficulty with apps-utils

[Aaron Laws]

I have made several changes on my branch to avoid kvp parsing keys. The
last change I made removes the functions that take char*, but the unit test
suite does not pass. All tests pass except app-utils which fails with the
strange error:

(./test-app-utils:6860): gnc.module-WARNING **: Could not locate module
gnucash/app-utils interface v.0

You can see my code at

https://github.com/limitedatonement/gnucash/tree/fix_bayes

Can anyone reproduce the problem? Any suggestions?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3 master

[Aaron Laws]

On Thu, Aug 31, 2017 at 9:51 AM, Geert Janssens 
wrote:

> I meant to add still, if we want to keep guile 1.8 support, the
> FIND_PACKAGE(GUILE_EXECUTABLE...) rules should move up inside the
> branches of
> the GUILE2 vs GUILE1 test.
> For GUILE2 it can remain
> FIND_PROGRAM (GUILE_EXECUTABLE guile2.0 guile)
> IF (NOT GUILE_EXECUTABLE)
>   MESSAGE (SEND_ERROR "The guile executable was not found, but is required.
> Please set GUILE_EXECUTABLE.")
> ENDIF (NOT GUILE_EXECUTABLE)
>
> For guile 1.8 it should become
> FIND_PROGRAM (GUILE_EXECUTABLE guile1.8 guile)
> IF (NOT GUILE_EXECUTABLE)
>   MESSAGE (SEND_ERROR "The guile executable was not found, but is required.
> Please set GUILE_EXECUTABLE.")
> ENDIF (NOT GUILE_EXECUTABLE)
>
> Regards,
>
> Geert


I don't have guile 1. guile --version; returns "2.2.2" and guile2.0
--version; returns "2.0.14".
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3 master

[Aaron Laws]

On Thu, Aug 31, 2017 at 8:44 AM, Aaron Laws <dartm...@gmail.com> wrote:

> On Thu, Aug 31, 2017 at 8:28 AM, Robert Fewell <14ubo...@gmail.com> wrote:
>
>> Just tried to build from master after all the recent changes and it failed
>> on guile, currently I am running 1.8 and in the log file I see "Using
>> guile-1.8.x" but it then logs "The guile executable was not found, but is
>> required. Please set GUILE_EXECUTABLE." Looking at CMakeLists.txt, I can
>> build if I comment out the four lines starting at 283. Not sure if they
>> are
>> required or should be moved so will leave for some one who knows what they
>> are doing.
>>
>> On a similar note, I still do a build on my Gtk3.10 VM but have to change
>> line 195 as it states the version should be greater or equal to 3.14, is
>> this just a typo or have I got the minimum version wrong ?
>>
>> Bob
>>
>
> If you remove "guile2.0" from line 283, does it work?
>

Oh, and another question. Would you post the output from   which guile;
and   which guile2.0; ?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gtk3 master

[Aaron Laws]

On Thu, Aug 31, 2017 at 8:28 AM, Robert Fewell <14ubo...@gmail.com> wrote:

> Just tried to build from master after all the recent changes and it failed
> on guile, currently I am running 1.8 and in the log file I see "Using
> guile-1.8.x" but it then logs "The guile executable was not found, but is
> required. Please set GUILE_EXECUTABLE." Looking at CMakeLists.txt, I can
> build if I comment out the four lines starting at 283. Not sure if they are
> required or should be moved so will leave for some one who knows what they
> are doing.
>
> On a similar note, I still do a build on my Gtk3.10 VM but have to change
> line 195 as it states the version should be greater or equal to 3.14, is
> this just a typo or have I got the minimum version wrong ?
>
> Bob
>

If you remove "guile2.0" from line 283, does it work?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Branching proposal for 2.7.x

[Aaron Laws]

On Sat, Aug 26, 2017 at 5:02 PM, John Ralls <jra...@ceridwen.us> wrote:

> We're almost ready to release 2.7.0, I just need to figure out why the
> build script locks up the Win10 VM build server.
>
> I propose to create an "unstable" branch and release the 2.7.x series from
> that, so all 2.7.x bug fixes and any remaining work for the 2.8.x would go
> to that branch; long-term development could continue in master (e.g. Aaron
> Laws has started converting Account.c to Account.cpp).
>
> Periodic merges would be maint->unstable and unstable->master with
> "periodic" meaning at least immediately before each 2.7.x release.
>
> When we release 2.8.0, we'll also release 2.6.20, do a final merge
> maint->unstable, delete maint and rename unstable to maint. At that point
> we'll be back to two active branches until we start the 2.9 alpha releases
> around 4 years from now.
>
> Any objections or concerns?
>
> Regards,
> John Ralls


This sounds fine to me, but I am hardly qualified to answer: not knowing
much about the intricacies of the project nor all the changes that we're
planning, etc.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Source directory restructuring complete

[Aaron Laws]

On Wed, Aug 16, 2017 at 4:52 PM, John Ralls 
wrote:

> Later, when trying to run GnuCash I found that libgncmod-backend-dbi.dylib
> didn't load because the directory being passed in was "dbi" instead of
> "gnucash".
> --- a/libgnucash/engine/gnc-engine.c
> +++ b/libgnucash/engine/gnc-engine.c
> @@ -74,9 +74,9 @@ gnc_engine_init_part2()
>  } libs[] =
>  {
>  #if defined( HAVE_DBI_DBI_H )
> -{ "dbi", "gncmod-backend-dbi", TRUE },
> +{ "gnucash", "gncmod-backend-dbi", TRUE },
>  #endif
> -{ "xml", "gncmod-backend-xml", TRUE },
> +{ "gnucash", "gncmod-backend-xml", TRUE },
>  { NULL, FALSE }
>  }, *lib;
>
> fixes the problem and I think it will affect only Mac builds, but can
> someone check it on Linux to make sure before I commit it?
>
> Regards,
> John Ralls



This looks fine on Arch Linux building from scratch using cmake and ninja
check.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: please delete me from mail list

[Aaron Laws]

Having subscribed yourself to the mailing list, you now need to unsubscribe
yourself from it. The link is below.

On Tue, Aug 15, 2017 at 5:21 AM, Carlos Molinelli via gnucash-devel <
gnucash-devel@gnucash.org> wrote:

> Thanks
>
> Sent from Yahoo Mail on Android
> ___
> 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: cmake failure (was:Re: Source directory restructuring)

[Aaron Laws]

On Thu, Aug 10, 2017 at 3:13 AM, Geert Janssens 
wrote:

> On donderdag 10 augustus 2017 07:08:38 CEST Sumit Bhardwaj wrote:
> > John and Geert,
> >
> > As I remembered, I am still having problem with cmake. I have pasted the
> > error message below. Is this a known problem? If not, will it be better
> to
> > wait for Geert's restructuring and then try to fix it? For reference,
> > autotools work.
> >
> > Thanks,
> > Sumit
> >
> > ​[3/942] cd /home/bhardwajs/ac/devel/gnucash/po && /usr/bin/cmake ...e
> -D
> > PO_DIR=/home/bhardwajs/ac/devel/gnucash/po -P check-po.cmake
> > FAILED: po/CMakeFiles/check-po
> > cd /home/bhardwajs/ac/devel/gnucash/po && /usr/bin/cmake -D
> > INTLTOOL_UPDATE=/usr/bin/intltool-update -D
> PO_DIR=/home/bhardwajs/ac/deve
> > l/gnucash/po -P check-po.cmake
> > The usage of POTFILES.ignore is deprecated. Please consider moving the
> > content of this file to POTFILES.skip.
> > The following files contain translations and are currently not in use.
> > Please
> > consider adding these to the POTFILES.in file, located in the po/
> directory
> >
> > If some of these files are left out on purpose then please add them to
> > POTFILES.skip instead of POTFILES.in. A file 'missing' containing this
> list
> > of left out files has been written in the current directory.
> > Please report to gnucash-devel@gnucash.org
> > CMake Error at check-po.cmake:22 (MESSAGE):
> >  POTFILES.in is missing files.  See 'missing' in
> >  /home/bhardwajs/ac/devel/gnucash/po
>
> That's a weird error and I can't reproduce.
>
> What platform/os are you on ?
> What are the exact commands you are using to get here ?
> What's the contents of /home/bhardwajs/ac/devel/gnucash/po/missing ?
>
> Geert


I remember getting that error a long time ago, but I don't remember how to
fix it. I think it has something to do with deleting a generated file and
having make re-generate it? It seems like we have a generated file in
version control? Is POTFILES.in generated and version controlled for
example?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

guile

[Aaron Laws]

I'm using archlinux (https://distrowatch.com/table.php?distribution=arch).
It supplies guile 2.0 and guile 2.2 at the same time as /usr/bin/guile2.0
and /usr/bin/guile, respectively. When I build gnucash, I get errors since
I'm using guile2.2. Perhaps the fix is as simple as:

FIND_PROGRAM (GUILE_EXECUTABLE guile2.0 guile)

(and an analogous change for guild) in CMakeLists.txt ? If someone else
would make this change and confirm that the system can find "guile" as
well, that would be helpful.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Source directory restructuring

[Aaron Laws]

On Mon, Aug 7, 2017 at 7:56 AM, Geert Janssens 
wrote:

> So after my houskeeping message in which I have announced the changes to
> src/
> business and src/libqof, I'd like to bring up my eventual goal for the
> source
> tree.
>
> My main motivation to do all this restructuring is to simplify. There are
> currently plenty of directories and I often have to guess where to expect a
> file. The qof vs engine story was one example. Is gnc-date something for
> qof
> or for engine ? I find myself regularly searching for a file in the wrong
> directory.
>
> So here follows a first proposal for the directory structure I'm
> targetting:
>
> * data (for things like art, checks, account hierarchy templates,...)
> * doc (for all documenation)
> * lib (for all source required to build "libgnucash", see below)
> * ui (for all the user interfaces the project currently supports)
>
> I am omitting some smaller directories here, such as util and macros. They
> will probably stay on the current top level for now.
>
> I'm envisioning "libgnucash" as the core library that encapsulates all
> gnucash
> related concepts (the accounting concepts such as transaction, split, as
> well
> as the data backends). This library is what all applications in the gnucash
> sphere should depend on to implement the "gnucash" experience. The most
> obvious is of course the current gnucash as we know it. However at some
> point
> this library should ideally also become the core of the Android app and
> *who
> knows* one day an IOS app. And closer to the current state, it should also
> be
> the library that the guile and python bindings depend on. So all
> functionality
> encapsulated in one single library, the API. In practice I think the
> following
> directories belong in this libgnucash: core-utils, gnc-module, engine, the
> backends, app-utils. (Note I would like to get rid of gnc-module still, but
> that's a whole other discussion and task).
>
> The ui directory will have a subdirectory for each user interface we
> support.
> This is not necessarily a *graphical* user interface though. At this point
> there are already a number of them:
> gnucash
> cutecash
> bindings (with subdirectories for python and guile)
>
> The bulk of the other directories are support directories for one of the
> ui's
> and I propose to make them subdirectories of each respective ui.
>
> For example gtkmm is only used by cutecash, so let's store it there (until
> another ui would also require it, which I consider unlikely to happen
> still).
>
> The other directories (gnome-utils, gnome-search, gnome, register, html,
> report, import-export,...) are all used only in the gnucash application and
> hence should be moved there. In the move I'd like to try and reduce the 3
> gnome* directories to one and call it gtk as we're not using any gnome
> specific technology any more.
>
> In a later phase I think it would be nice if the core libgnucash could also
> spit out html reports, but that would require us to refactor the report
> modules, which I consider too much work to be done at the same time. When
> this
> eventually gets done the non-ui part of the report system can then be
> added in
> libgnucash to the benefit of all consumers (gnucash/cutecash/Gnc4Android/
> ...).
>
> Feedback or questions ?
>
> Geert
>

I echo the other sentiments: This will make it much easier to grok and
contribute to gnucash.

Concerning cutecash, "It's not maintained" may be the case now, but I
remember working on some libqof changes before and having to "maintain"
cutecash since it was breaking because of the changes. It was a bit
irritating. If it's a difficult thing to bring yourself to, perhaps you
could have a friend pull the trigger? ;-)

Thanks for thinking through this and putting it on paper. I look forward to
seeing the fruit of this labour.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Timezone problem with make check?

[Aaron Laws]

I am running ninja check on master and two tests fail, both having to do
with time. One is test-gnc-date.c, and I drilled down. The line that fails
is 721:

g_assert_cmpint (na.tv_sec, ==, ra.tv_sec);

na is 739299600, and ra is 739296000. na - ra = 3600 which is one hour.

I'm hoping someone already knows what's going on. I'll look at the other
test, too.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [Gnucash/gnucash] Guid header (#109)

[Aaron Laws]

I created a docker container that may immitate the build situation on
travis. It is based on ubuntu 14.04 and has the same gcc version:
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
Copyright 2013

It does reproduce the problem I was having with pull request 109, but it
doesn't complete the build when that problem is solved. Several tests pass,
but there is some problem with po files; here is the build output at the
end:



if [ -r missing -o -r notexist ]; then \
  exit 1; \
fi
make[1]: *** [check] Error 1
make[1]: Leaving directory `/repos/gnucash/build/po'
make: *** [check-recursive] Error 1



You can use the image here: https://hub.docker.com/r/lmat/gnucash-build/.
The description talks about how to use it, but let me know if you have any
questions. It is my first docker image.

On Tue, Oct 25, 2016 at 12:21 PM, John Ralls 
wrote:

> The problem Travis found is that brace-initializer-list initialization
>  is
> handled differently in C++11 and C++14. For this cycle we need to stick to
> C++11, so you need to be careful about using initializer lists. Gcc should
> warn about that if you've got -std=c++11 set.
>
> While you're at it, could you elaborate the last commit message to say
> that you've replaced inheritance from boost::guid::guid with composition?
>
> Otherwise very nice. Composition is clearly a better choice here.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> , or mute
> the thread
> 
> .
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Developer Referral

[Aaron Laws]

On Thu, Sep 1, 2016 at 11:16 AM, YMX  wrote:

> Dear List,
>
> I am a user of an agency m management software package (Saas) that
> utilizes OFX credit card download functionality. I am not the developer,
> just a user of this specific SaaS.
>
> Until last year the software was able to download Chase credit card
> transactions. As many of you know, Chase changed how the handle this around
> November 2015.
>
> Given what I’ve read on the GnuCash postings, and how GnuCash has solved
> for this, I’m wondering if there is a developer that I could refer to the
> software developer to help them resolve this for their software?
>
> Thanks so much for your help.
>
> YM


It looks like you didn't get an answer to this, so I'll wager something.

I think the best way to proceed in this case is to tell the developer about
this list. Tell him that there likely are individuals on this list that can
help him, and they may even be willing to help, too.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash master: Fix wrong PWARN calling signature.

[Aaron Laws]

On Tue, Jul 12, 2016 at 2:13 PM, Aaron Laws <dartm...@gmail.com> wrote:

>
> On Tue, Jul 12, 2016 at 12:57 PM, John Ralls <jra...@code.gnucash.org>
> wrote:
>
>> Updated  via  https://github.com/Gnucash/gnucash/commit/01c21da3 (commit)
>> from  https://github.com/Gnucash/gnucash/commit/c11185e9 (commit)
>>
>>
>>
>> commit 01c21da3234ba637f57cc4b18eb069ef2bcc7aa9
>> Author: John Ralls <jra...@ceridwen.us>
>> Date:   Tue Jul 12 16:57:01 2016 +
>>
>> Fix wrong PWARN calling signature.
>>
>>
>>
>> Summary of changes:
>>  src/libqof/qof/gnc-timezone.cpp | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> ___
>> gnucash-patches mailing list
>> gnucash-patc...@gnucash.org
>> https://lists.gnucash.org/mailman/listinfo/gnucash-patches
>>
>
> - PWARN(str.str().c_str());
> + PWARN("%s", str.str().c_str());
> What's the difference here?
>
>

I mean, I see that if the string is, for instance, "%s", nothing is output.
But did this come up, or did you catch it visually while looking through
the code.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash master: Fix wrong PWARN calling signature.

[Aaron Laws]

On Tue, Jul 12, 2016 at 12:57 PM, John Ralls 
wrote:

> Updated  via  https://github.com/Gnucash/gnucash/commit/01c21da3 (commit)
> from  https://github.com/Gnucash/gnucash/commit/c11185e9 (commit)
>
>
>
> commit 01c21da3234ba637f57cc4b18eb069ef2bcc7aa9
> Author: John Ralls 
> Date:   Tue Jul 12 16:57:01 2016 +
>
> Fix wrong PWARN calling signature.
>
>
>
> Summary of changes:
>  src/libqof/qof/gnc-timezone.cpp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> ___
> gnucash-patches mailing list
> gnucash-patc...@gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-patches
>

- PWARN(str.str().c_str());
+ PWARN("%s", str.str().c_str());
What's the difference here?
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Authorization for commercial derivative work of GnuCash Tutorial and Concepts Guide

[Aaron Laws]

On Wed, Jul 6, 2016 at 10:22 AM, Ted Creedon 
wrote:

> Submit to the previous authors.
>
> Consensus.
>

Ah yes, I think if you were able to get ahold of every author of the work,
they could collectively decide to license it under different terms. I
wouldn't inspire hope in that direction.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Authorization for commercial derivative work of GnuCash Tutorial and Concepts Guide

[Aaron Laws]

On Tue, Jul 5, 2016 at 8:54 PM, Ted Creedon  wrote:

> best thing to do is to prototype a sample & submit for approval.
>
>
Submit to whom for approval? By what authority can anyone approve anything
that might be submitted? If you said "submit for comments", I would not
object.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Authorization for commercial derivative work of GnuCash Tutorial and Concepts Guide

[Aaron Laws]

On Sat, Jul 2, 2016 at 5:29 PM, Fabio Benevenuti 
wrote:

> Dear GnuCash developers,
>
> Pleae let me know if there is a main “GnuCash Documentation Team”
> coordinator or legal advisor to which I should address this question.
>
> Thanks in advance,
>
> Fabio Benevenuti
>

We're unable to give permission for you to violate the terms of the
license. Whether what you're doing conforms to the terms of the license is
a question for your lawyer. As you have seen, there are opinions available,
but none of them are legally binding.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Transaction Posted Time

[Aaron Laws]

On Sun, Jun 19, 2016 at 11:12 PM, John Ralls  wrote:

> Aaron,
>
> Actually it's worse than that. Store a transaction in the summer, then
> look at it in the winter and it's the day before.
>
> The reason for not changing it to date-only now is file compatibility. A
> newly stored file would have no time part, and that would fail to load in
> 2.6.12. If we change it now to scrub to 1100Z (sailor/flyer/military for
> 11:00AM UTC) then it will continue to load on older versions and will
> magically not flip dates even on those older versions for all but the few
> users in the time zones I mentioned at the start of the thread. This would
> also be a good time to change the input code to not blow up if there's no
> time part, but instead to set a timespec at 1100Z on the date indicated.
>
> Regards,
> John Ralls
>

All that sounds good to me; in particular, the backwards compatibility
story seems well-developed here.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Transaction Posted Time

[Aaron Laws]

On Sun, Jun 19, 2016 at 6:15 PM, John Ralls  wrote:

>
> > On Jun 19, 2016, at 1:07 PM, Christian Stimming 
> wrote:
> >
> > Again, I would suggest to switch the posted-date data type to a date-only
> > (without time) as soon as possible, as discussed in bug 137017 and
> various
> > discussions throughout the years.
>
> Christian,
>
> You and I both agree that a date-only posted date field is the best
> solution, but we've always gotten substantial push-back from users so we've
> never changed it. Even the ability to edit the time, mentioned in comment
> 28, comes up from time to time. So if we set that aside for now, what do
> you think of using 11:00AM UTC instead of 00:00 Local, in particular
> changing in the middle of a release series?
>

Since there is no time-of-day reported, and it's not editable, no
time-of-day seems like the right representation. If we're dedicated to
storing time-of-day, we should be showing it and allowing it to be
editable. I'm guessing the argument for storing time of day, but not
showing it or allowing it to be edited is because 1) many users want time
of day, 2) no developers care enough to do the work to show and edit the
time of day, right?

Concerning changing to 1100 UTC, I take it that the current system has the
following flaw:
1) user A stores his file in Eastern Time (so that the transactions happen
at midnight in the morning of the transaction date), then later opens the
file in Central time and finds that the posting dates are off by one hour,
which is 2300 the previous day, so they appear to be off by a whole day?
In that case, moving to 1100 UTC (or anything UTC), and showing the date
UTC on the register has the effect of using a date-only representation.
Storing in 1100 UTC, and showing in local time on the register has the
problems you mentioned, but it seems a good deal better than having
problems between, e.g., EST and CST.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Importing QDF files

[Aaron Laws]

On Sun, Jun 12, 2016 at 5:32 PM, Phern Ballard 
wrote:

> Well, it seems I did not need to contact you regarding importing my quicken
> data. I found an export qif function in quicken and all is well now.
>
> Thanks!
>
> On Sun, Jun 12, 2016 at 5:17 PM, Phern Ballard 
> wrote:
>
> > Greetings;
> >
> > I am a frustrated Quicken user. After reviewing possible alternatives I
> > have decided upon Gnucash. However, it seems my Quicken 2016 file is a
> qdf
> > rather qif or qfx. Can Gnucash import this file type?
> >
> > ​Thank you,
> > Phern
> >
>
>
>
> --
>
> *Phern*
>

Welcome to gnucash; enjoy!
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash master: Multiple changes pushed

[Aaron Laws]

On Sun, Jun 12, 2016 at 11:48 AM, John Ralls  wrote:
>
> >
> >
> > I'm not using guid's in my code. These errors are pulled in because of
> the Account.h header
> > that gets included somewhere.
> >
> > I saw one commit on the guid_header branch is including guid.hpp
> everywhere. Is that what I
> > now have to do in my sources even if I'm not using a guid directly ? Or
> what is the correct
> > approach here ?
> >
>
> Yes, I had a similar problem in the backend work after I merged, though
> the backend code obviously does use GncGUID so it didn't seem quite as
> weird. Try including guid.hpp before gnc-csv-account-map.h in
> gnc-csv-imp-trans.cpp.
>
> It might work to conditionally include guid.hpp inside of guid.h and wrap
> guid.hpp's declarations in extern "C"
> to avoid linkage problems. If so that would allow us to remove all of the
> sxplicit include guid.hpp from .cpp files.
>
> Aaron, any thoughts on this?
>
> Regards,
> John Ralls


tl;dr: This can be made better by making a small change in guid.h which I
will Pull Request within the next day or so. With this change, any .cpp
file that doesn't need the definition of GncGUID doesn't have to include
guid.hpp at the top.

Long version:

The problem here is that there is one definition of GncGUID for C code and
one for C++ code (this is in the commit message). I was unable to do
something like

#ifdef __cplusplus
struct GncGUID : public boost::uuids::uuid...
#else
typedef struct _gncGuid {
unsigned char.
#endif

because rather than trusting C headers to use extern "C" when they need it,
we use extern "C" around C headers "for" them. This means that, even when
compiling c++, the linkage could be "C". For example: kvp-value.cpp
includes kvp-value.hpp which uses extern "C" to include qof.h which
includes guid.h. Although a c++ compiler is being invoked, the linkage is
"C", so a c++ definition can't be conditionally included here.

For the same reason, we can't
#ifdef __cplusplus
#include "guid.hpp"
#endif
etc.

Also, GncGUID must be defined before it's used! This means that the best
place to put it is first in a .cpp file (perhaps after config.h is more
correct), and of course, not within an extern "C" block.

The solution I have is that I can simply forward declare the struct in the
#ifdef __cplusplus. I can't put the definition in there because of the "C"
linkage problem, but I forgot that I *can* forward declare, and that's what
I plan to do. I just did a test run in libqof, and it allowed me to remove
a guid.hpp include is almost 20 files.

Thanks for bringing this to my attention; please let me know if you have
any more thoughts!
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New Report to End All Reports

[Aaron Laws]

Thank you for your response; my responses are inline.

On Wed, Jun 1, 2016 at 4:09 PM, Wm <tcn...@tarrcity.demon.co.uk> wrote:

> In article <
> cadu-kvf_qyg5vntvh4ddjkezevgxy2hx_yjarl5houezzeo...@mail.gmail.com>
> Aaron Laws <dartm...@gmail.com> wrote:
> >
> > >
> > > > On May 18, 2016, at 6:19 PM, Stephen Torri <sto...@torri.org> wrote:
> > > >
> > > > How is the data stored presently? If it is already in a database we
> > > should be able to query things. The only part I an intimated by is how
> to
> > > present it. A.k.a make the data look pretty.
> > >
> >
> > Strategies for getting data from the "book" are well in place, and a
> report
> > like this would be pretty similar to other reports. The report builder
> > would be a bit more elaborate and flexible than existing reports, but
> > getting data from the application would be done in the same way.
>
> Not quite.  There are any number of generalist SQL report writing
> tools available for those interested.
>
> I have done the SQL homework that means that anyone that wants a
> Trial Balance, Income Statement or Balance Sheet can get them in
> pretty much any form they want if they have sufficient clue to play
> SQL and given the level of query I've used a text or csv file after
> that.  Here in the UK we expect (many not all) school children in
> their early teen years to be able to do stuff with a text or csv
> file in a spreadsheet.  Do you have a problem with doing your
> specific asset de-allocation in a spreadsheet?
>

I give my full assurance that I, not unlike those early-teen UK scholars,
am able to work with CSV files and spreadsheets. I think I'm also capable
of preparing all the reports offered in gnucash using a spreadsheet. The
complete workflow for getting the report I'm describing into a spreadsheet
involves quite a few steps; it would be much tidier within gnucash. Other
users requesting odd reports come to mind as well. While it is certainly
accurate to tell users that they can generate their reports with whatever
SQL reporting tools they like, it is nice to be able to ask gnucash itself
about its own data.


>
> The basi gnc data structures mainly work, I've kicked the tyres and
> not found anything obviously wrong yet (there are edge bits but you
> haven't addressed one of them).
>
> The presentation and interpretation are up to you.
>
> Other people have done interesting work too, look up
> Gregory Gincley rollenwiese at fastmail.net
> and his more personal work with Jasper.  Superb but probably more
> than most people need.
>
> Given that ... I don't get to read everything on the user list
> (which is where this should be) and have probably missed the best
> solution of all as people do offer *their* solutions over time.
>
> More practically, I agree with MikeN up thread that you may have
> misunderstood what you were asking for, it looks to me like a limit
> on the stuff you report on when doing asset (i.e. point in time)
> reports is approprite advice.
>
> I find a report as follows useful
>
> Reports / A & L / Net worth bar / then use the unfortunately fiddly
> but still useable accounts tab to exclude non current stuff (in my
> case assets of pension and government owing me money not expected
> soon, etc and liabilities of some money I owe my father payable
> when I can, etc; I don't have a mortgage but that would be the sort
> of obvious liability to exclude if you have one of them) and you
> should have a nice view.


Yes, this is exactly the sort of information I'm seeking. I accidentally
looked over that report in my search because I'm looking for a text-based
report rather than a graph, but the information is certainly there.


> I add two graphs below that for Assets
> Over Time and Liabilities Over Time so I can see my position
> exactly, that involves Custom Multicolumn Reports ... but I can
> assure you that the fiddling involved is way simpler than getting
> everyone to agree on a new generic report model (I hope sql based)
> and then there is the effort of translating the existing reports to
> any ne model coz everyone wants continuity, after all?  Thought
> about that?
>

I don't have any design to remove or replace existing reports, and I
wouldn't suggest anything like that without being quite confident that a
new solution would be not just equally good, but better than the existing
solution.

>
> May I gently suggest you have requested a reporting mechanism
> without a full eploration of those extant?
>

This is why I have posted here. I don't trust that I'm fully familiar with
the reporting capabilities of gnucash, and I'm looking for the community's
response to the suggestion. It 

Re: New Report to End All Reports

[Aaron Laws]

On Thu, May 19, 2016 at 5:59 PM, Mike or Penny Novack <mpnov...@mtdata.com>
wrote:

> On 5/18/2016 8:51 PM, John Ralls wrote:
>
>> On May 18, 2016, at 7:03 AM, Aaron Laws <dartm...@gmail.com> wrote:
>>>
>>> On Tue, May 17, 2016 at 5:22 PM, John Ralls <jra...@ceridwen.us >> jra...@ceridwen.us>> wrote:
>>> The Balance Sheet report shows you net worth. You probably didn't
>>> recognize it because the accounting word for it is "equity". Recall that
>>> the accounting equation is Assets = Liabilities + Equity*, so by
>>> associativity Equity = Assets - Liabilities.
>>>
>>>
>>> When we say Assets = Liabilities + Equity, it means All Assets = All
>>> Liabilities + All Equity. This works if I include all (non-$0) assets,
>>> liabilities and equity, and do so when there are no revenues nor expenses
>>> (just after closing the books). At any other time, or in any other way,
>>> that equation doesn't hold, and even in that specific case, it's not the
>>> information I'm seeking.
>>>
>> ]
> b) Take closer look at the balance sheet under equity. Do you not see
> there a line for which you do not have an actual account? One that has the
> amount of the net of all income and expense accounts << it will either be a
> gain or a loss >>
>
> The equation is always valid. The accounts of type income and expense are
> part of the equity side.
>
> Michael D Novack
>

Thank you for your input. Your expertise is highly valued. You're right; I
forgot that net gain/loss from the profit & loss is carried to the balance
sheet as equity because I had only selected current assets and liabilities.
The balance sheet was prepared with only those asset and liability accounts
and no income and expense accounts. The image I posted online appears to
have expired, so I attached it to this message. When I select all accounts
(including expense and income), on the balance sheet I see "Retained
Earnings", and all numbers make sense.

I think this doesn't change the original request which is to find net
current assets, but thank you for pointing this out.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New Report to End All Reports

[Aaron Laws]

>
> > On May 18, 2016, at 6:19 PM, Stephen Torri  wrote:
> >
> > How is the data stored presently? If it is already in a database we
> should be able to query things. The only part I an intimated by is how to
> present it. A.k.a make the data look pretty.
>

Strategies for getting data from the "book" are well in place, and a report
like this would be pretty similar to other reports. The report builder
would be a bit more elaborate and flexible than existing reports, but
getting data from the application would be done in the same way.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: New Report to End All Reports

[Aaron Laws]

On Tue, May 17, 2016 at 5:22 PM, John Ralls  wrote:
>
> The Balance Sheet report shows you net worth. You probably didn't
> recognize it because the accounting word for it is "equity". Recall that
> the accounting equation is Assets = Liabilities + Equity*, so by
> associativity Equity = Assets - Liabilities.
>
>
When we say Assets = Liabilities + Equity, it means All Assets = All
Liabilities + All Equity. This works if I include all (non-$0) assets,
liabilities and equity, and do so when there are no revenues nor expenses
(just after closing the books). At any other time, or in any other way,
that equation doesn't hold, and even in that specific case, it's not the
information I'm seeking.

Attached is a small sample (hopefully it comes through okay). When I get a
balance sheet only selecting the current assets and liabilities, the
resulting report looks like this: http://i.imgur.com/uW0uE5R.png which
shows $0 for equity (because I didn't select any equity accounts).

In this case, since my checking account has $15, and credit card has $12, I
would like to see that my net current assets are $3. This purposefully
leaves out the fixed asset which makes the net worth much higher.

I'm not convinced that this should be a separate report in gnucash; it
seems like an ad-hoc, one-off report to satisfy a curiosity of mine, much
like report requests from other users. How is the suggestion for a
flexible, general report taken? Maybe it should be called a report builder?


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

New Report to End All Reports

[Aaron Laws]

I have a need for a report that I don't see in GNUCash: Net Current Assets.
Show all current assets and current liabilities (selected by user), and
subtract them. (If this exists, please show me.) I think I could hobble
something together by (ab)using the profit & loss report on assets and
liabilities.

When I was considering what would be required to create this report in
code, being a programmer, I thought of the problem abstractly. Abstractly,
the report I want resembles a syntax tree. I simply want to be able to take
values, perform operations on them, and add labels. The syntax tree for my
report would look like this: http://i.imgur.com/9hyMHfx.png. Headings are
automatically generated from account names, and the user must give headings
to the aggregators to signify their meaning. One can image what the balance
sheet and Profit & Loss reports might look like from this perspective.

I've seen a number of requests for this report or that, and the outlook
isn't usually positive. With general functionality such as that described
above, it would be at least technically possible to create many of the
reports requested.

Anyway, I post here to find out if there is functionality like this
anywhere in GNUCash, or if it would be appreciated as a contribution.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: GnuCash Development Visualization - 2015 edition

[Aaron Laws]

On Sat, Sep 26, 2015 at 11:17 AM, Geert Janssens <geert.gnuc...@kobaltwit.be
> wrote:

> ...

The video takes about 9 minutes. Feel free to skip parts if it becomes too
> long :)
>
> Other than that: enjoy !
>
> Geert
>

Thanks for sharing; this is really cool!

It took me a while, but I've decided that this must just be tracking
development on the Maint branch? Or at least it's only one branch, and each
dot is a file. Perhaps the color of the file correlates to how many times
it was touched? So those radioactive ones on the lower right at the end are
QOF? ^_^

I watched the whole video thinking that maybe each dot was a commit and
each clump of dots was a branch.


In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Aaron Laws]

On Thu, Sep 3, 2015 at 2:03 PM, David Carlson 
wrote:

> I should split this off from the price rounding thread, but I don't know
> how to do that in GMail when I am replying from inside the thread.
>
>
It's a rather hard-to-find feature. To the left of the "to" field, there is
a little icon with a triangle arrow down. Click that, then "Edit Subject",
and it pops the message out and lets you edit the subject.

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

Re: How are Budgets Implemented in GNU Cash

[Aaron Laws]

On Thu, Jul 16, 2015 at 6:38 AM, Mike Evans mi...@saxicola.co.uk wrote:


 Have look in:
 http://svn.gnucash.org/docs/HEAD/group__budget.html
 src/engine/gnc-budget.c
 src/doc/budget.txt


Hopefully this doesn't need to be said, but to my knowledge, development
 isn't happening in SVN. Although that site is very helpful, be sure to use
the appropriate git repository to do your development!

In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Compile test-core in C++

[Aaron Laws]

On Sat, Nov 22, 2014 at 10:02 AM, Chenxiong Qi qcxh...@gmail.com wrote:

 I converted QofCollection_s to a C++ class named QofCollection placed
 in same header file src/libqof/qof/qofid.h,


I would advise against putting the class declaration into this file. It can
certainly be done by following Mr. Rall's suggestion of #ifdef __cplusplus,
but it seems cleaner to me to have a separate .hpp file for several reasons.


 and the original
 QofCollection_s is replaced with this new class. Module src/libqof/qof
 is compiled successfully, but failed to compile src/test-core due to C
 compiler is the one used to compile, and
 src/test-core/unittest-support.h includes qof.h, then *includes
 qofid.h*. This is why I considered to compile src/unit-core to solve
 the problem. After guidance in previous mails from both of you, I
 realizd that's not a good idea.


Right. The C tests (using the gtest framework) shouldn't see any C++.
Actually, the C tests shouldn't change at all (ideally) in response to your
work. It sounds like your understanding is correct.


 Then, by seeing KvpFrameImpl, I was thinking to keep QofCollection's C
 and C++ implementation existing at the same time. Because

 1. reach the very first step of the goal to implement a C++ version of
 QofCollection
 2. new C++ class is just used in the scope of src/libqof/qof, whereas
 the original C version can still be used by the features outside of
 src/libqof/qof. In this case, my problem mentioned above disappears.
 3. unit tests and all test works can be done within src/libqof/qof
 only. No any side-effects to outside.
 4. When migrate to C++ compiler to build the whole GnuCash
 application, it's the time to make features outside of src/libqof/qof
 make use of QofCollection class.


Exactly. You're on the path to victory :-)

In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Compile test-core in C++

[Aaron Laws]

On Thu, Nov 20, 2014 at 9:58 AM, Chenxiong Qi qcxh...@gmail.com wrote:

 Is it acceptable that I rename the new class to
 another name temporarily, such as QofCollectionClass, and keep the new
 class implementation and original one's existing simultaneously. I
 know this looks strange, but the change only affects in src/libqof/qof


That doesn't sound acceptable, but I don't see the situation. Why would you
do that? Do take a look at the kvp-frame stuff? The cpp declaration is in
kvp_frame.hpp, and the C interface is in kvp_frame.h. For instance, take a
look at the .cpp file at kvp_frame_copy. This function used to have all the
logic for copying all the contents of the provided KvpFrame *, but now, a
new struct, KvpFrameImpl with a copy constructor is used from the C
implementation. This means that C code can use this copy constructor
through this thin interface, and cpp code can directly include the .hpp and
create a copy more directly.

As recently as commit 8a7f426, there was struct _KvpFrame { GHashTable *
hash; };. That was removed and struct KvpFrameImpl was introduced in commit
076f1fb25.

Trying to keep them both around at the same time doesn't sound like a good
idea. Which one will be pointed to by qof_collection_new? What happens if
the wrong one is sent to qof_collection_destroy?

I am interested in finding out why you would want to have both existing at
the same time if you feel up to explaining :-).

I'm heading out of town, so I might not be terribly responsive for the next
week and an half.



 Regards,
 Chenxiong Qi
 ___
 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: Compile test-core in C++

[Aaron Laws]

On Tue, Nov 18, 2014 at 10:10 AM, Chenxiong Qi qcxh...@gmail.com wrote:

 Hi,

 I've converted QofCollection to a C++ class. A side-effect is that I
 have to make src/test-core be able to compile in C++.


Although QofCollection will be a C++ class, you should be retaining the C
interface! The existing tests (src/libqof/qof/test/*.c) should be working
with the C interface, and you should write up new gtests
(src/libqof/qof/test/*.cpp) to test the C++ object that you created.

This has been done on the master branch in kvp-value. See kvp-value.cpp,
kvp-value.hpp, test/test-kvp-value.cpp, and the C interface in kvp_frame.h,
and implementations of the C interface in kvp_frame.cpp.

I hope that makes sense?

I'm an absolute
 newbie to autotools, still not get a workable solution so far after
 doing some research on this. Could you give some guide how to
 accomplish this conversion. Conversion only involves the compiler
 changed to a C++ compiler, and the file's extension changed to cpp if
 necessary. Nothing else if src/test-core/* are compiled in C++ without
 errors.


There are more subtle errors that can occur when changing the compiler and
extension of code files. Since c++ introduces the idea of function
overloading, it can be that an external entry point of a library will have
an unexpected name. Our build process creates a good deal of intermediate
libraries and actually ships modules as dynamic libraries. If those
dynamic libraries are compiled in c++, the function name can be mangled
beyond C recognition. So, although compilation will succeed, and perhaps
even launching the application will succeed, when that function is called
from C (but can't be found because its name has been mangled), an error can
occur.



 BTW, besides the conversion to C++ class, I will write unit tests to
 ensure new QofCollection class works as expected.

 Thanks!

 Regards,
 Chenxiong Qi


Thanks and good luck!

In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Would like to convert provider_list to std::list

[Aaron Laws]

On Thu, Nov 13, 2014 at 9:46 AM, Chenxiong Qi qcxh...@gmail.com wrote:

 Hi all,

 I would like to convert provider_list in qofsession.cpp to std::list.
 Make a small change (step) to C++. What do you say? :)


Is this your first forray into contributing to gnucash (C or C++)? I think
the hope is that qofsession will become 'class QofSessionImpl' or something
like that, but I don't know that part of the code yet. It is probably a
useful exercise for yourself to go ahead and do what you propose even if
you're not interested in going whole-hog yet. I wouldn't hold your breath
that this would be accepted, though (I don't do the accepting, by the way),
because a global std::list may not be seen as an improvement in itself ^_^ .

You asked What do you say?, and this is what I say. Do keep in mind that
I don't make any decisions like this for GnuCash development :-)

In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: building master with boost

[Aaron Laws]

On Sat, Nov 1, 2014 at 2:42 PM, Carsten Rinke carsten.ri...@gmx.de wrote:

 Hi,

 to check if some front-porting is working, I tried to compile on the
 master branch - for the first time.

 It told me that boost is missing:

 checking for boostlib = 1.48.0... configure: We could not detect the
 boost libraries (version 1.48 or higher). If you have a staged boost
 library (still not installed) please specify $BOOST_ROOT in your
 environment and do not give a PATH to --with-boost option.  If you are sure
 you have boost installed, then check your version number looking in
 boost/version.hpp. See http://randspringer.de/boost for more
 documentation.
 configure: error: Boost 1.48.0 or later was not found and is required to
 build GnuCash

 So I downloaded Boost 1.56.0 into /opt/lib/boost/boost_1_56_0.

 Running configure with an environment variable
 echo $BOOST_ROOT - /opt/lib/boost/boost_1_56_0
 does not change anything.

 Running configure with
 --with-boost /opt/lib/boost/boost_1_56_0
 results in:
 checking build system type... Invalid configuration
 `/opt/lib/boost/boost_1_56_0': machine `/opt/lib/boost/boost_1_56_0' not
 recognized
 configure: error: /bin/bash ../config.sub /opt/lib/boost/boost_1_56_0
 failed

 What can I do?

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



I do a similar thing, and here is what I pass to configure:

./configure --with-boost=/home/lmat/builds/development

(I trimmed out a dozen lines, but this should get to the gist of the
matter.)

I built boost with

#!/bin/bash
cd boostsvn
./bootstrap.sh --prefix=/home/lmat/builds/development
./b2 install

I don't set BOOST_ROOT. Hopefully this helps?

In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Boost compilation problem

[Aaron Laws]

On Fri, Oct 24, 2014 at 11:10 AM, Derek Atkins warl...@mit.edu wrote:


 As for compiling boost from source, the question isn't whether they can,
 but whether they can make it co-exist with the distributions' version.


Just to be clear, if I'm understanding correctly, this is done by building
boost with ./bootstrap --prefix=/home/derek/boostbuild; , and when building
gnucash, ./configure --with-booth=/home/derek/boostbuild; I hope that
clears up that point sufficiently.

In Christ,
Aaron
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Boost compilation problem

[Aaron Laws]

I asked on IRC and was told that our targeted boost version is 1.48. There
had been some minor dificulties with some of my commits recently because I
was using boost 1.56, so I thought it would be best to use the officially
targeted version. Now I'm using boost version 1.48 (from boost version
control), and the project doesn't compile using it due to a bug in boost
that produces a narrowing warning. We treat that warning as an error.

The fact that our gnucash/trunk doesn't compile under the targeted boost
version suggests that nobody's using that version. The reason I've heard
for why we target an old version is because Debian stable has this version
in their repo. I surmise that the thought process is something like: most
people who might want to compile gnucash will use Debian to do so, or
something along those lines. I also surmise, since the project doesn't work
with boost 1.48, that nobody's doing that.

I have two concerns: 1) We should seriously consider what version of boost
we target, and 2) I would like to be able to compile the project again :-)

1) doesn't mean that we should change our boost target, but that we should
*use* it for development and production! If we target version 1.48, and I
develop with 1.56 and commit, and we ship based on 1.52, we're asking for
trouble.

Personally, I recommend targetting 1.56 for the following reasons: It is
the most mature, it is the first version of boost using their git repo,
people familiar with cutting-edge Boost will be at home, you won't find
yourself reading too modern documentation when researchng Boost.
Answering objections: it's *dead* simple to build...like two commands! It
takes a bit, but very, very simple.

I don't really care which version we use, but I am quite convinced about
picking some version and *using* it.

2) I'm not good enough with autotools to figure out how to add
-Wno-error=narrowing (or whatever needs to happen here) to my particular TU
(src/lib-qof/qof/guid.cpp), any suggestions?

Thanks!

In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Boost Version Required ?

[Aaron Laws]

On Thu, Oct 9, 2014 at 8:11 AM, Geert Janssens geert.gnuc...@kobaltwit.be
wrote:

 Oops.

 Officially we target 1.48, but apparently some more recent features
 got used in the last commits.

 John, Aaron: how do we deal with this ?


Good question. Something like the full story can be found at
https://bugzilla.gnome.org/show_bug.cgi?id=736687 . In short, that include
was added because of a bug identified in jralls's build environment: his
boost/variant.hpp didn't include the file, so there was a compilation issue
which was fixed by including it ourselves. My version built properly
without the include, and we're using the same boost version: 1.56.0. Since
we target 1.48, perhaps I should get that version of boost to make sure to
avoid this type of thing. Of course, boost 1.56.0 *is* freely available :-).


 Geert

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

Re: About the process of migration to C++

[Aaron Laws]

On Thu, Oct 2, 2014 at 2:29 AM, Chenxiong Qi qcxh...@hotmail.com wrote:

 Hi all,

 In the past several days, I've read mails and wiki pages about the
 migration to C++. A quick question is that, is there any place, a wiki page
 or others, to record the process of migration, the todo list, and what is
 being done?

 Regards,
 Chenxiong Qi


http://wiki.gnucash.org/wiki/C%2B%2B under The Plan should answer your
question. I believe Mr. Ralls is working on gnc_numeric. GUID is in
progress, and I've been working on kvpvalue and kvpframe (under Other QOF
Utility Classes). If you would like to get your hands dirty, feel free to
pick one of the others and begin? Perhaps others have a good feel for where
is a good place to start (an independent class that won't require gutting
gnucash, etc.).

In Christ,
Aaron
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: libmpdecimal

[Aaron Laws]

Dear Mr. Ralls,

Excellent work! I'm happy to hear the results, although with you I'm
disappointed that boost::rational didn't bring something valuable to the
table. I look forward to getting to know that code some day...on an
as-needed basis!


In Christ,
Aaron Laws

On Sat, Sep 20, 2014 at 9:21 PM, John Ralls jra...@ceridwen.us wrote:


 On Aug 27, 2014, at 10:31 PM, John Ralls jra...@ceridwen.us wrote:

 
  On Aug 27, 2014, at 8:32 AM, Geert Janssens janssens-ge...@telenet.be
 wrote:
 
  On Saturday 23 August 2014 18:01:15 John Ralls wrote:
  So, having gotten test-lots and all of the other tests working* with
  libmpdecimal, I studied the Intel library for several days and
  couldn't figure out how to make it work, so I decided to try the GCC
  implementation, which offers a 128-bit IEEE 754 format that's fixed
  size. Since it doesn't ever call malloc, I thought it might prove
  faster, and indeed it is. I haven't finished integrating it -- the
  library doesn't provide formatted printing -- but it's far enough
  along that it passes all of the engine and backend tests. Some
  results:
 
  test-numeric, with NREPS increased to 2 to get a reasonable
  execution time for profiling: master 9645ms
 mpDecimal 21410ms
 decNumber 12985ms
 
  test-lots:
 master  16300ms
 mpDecimal   20203ms
 decNumber   19044ms
 
 
  The first shows the relative speed in more or less pure computation,
  the latter shows the overall impact on one of the longer-running
  tests that does a lot of other stuff.
  John,
 
  Thanks for implementing this and running the tests. The topic was last
 touched before my holidays so it took me a while to refresh my memory...
 
  decNumber clearly performs better, although both implementations lag on
 our current gnc_numeric performance.
 
 
  I haven't investigated Christian's other suggestion of aggressive
  rounding to eliminate the overflow issue to make room for larger
  denominators, nor my original idea of replacing gnc_numeric with
  boost::rational atop a multi-precision class (either boost::mp or
  gmp).
  Do you still have plans for either ?
 
  I suppose aggressive rounding is orthogonal to the choice of data type.
 Christian's argument that we should round as is expected in the financial
 world makes sense to me but that argument does not imply any underlying
 data type.
 
  How about the boost::rational option ?
 
  I have noticed that we're doing some dumb things with Scheme,
  like using double as an intermediate when converting from Scheme
  numbers to gnc_numeric (Scheme numbers are also rational, so the
  conversion should be direct) and representing gnc_numerics as a tuple
  (num, denom) instead of just using Scheme rationals.
  Does this mean you see potential performance gains in this as we clean
 up the C-Scheme number conversions ?
 
  Neither will
  work for decimal floats, of course; the whole class will have to be
  wrapped so that computation takes place in C++.
  Which means some performance drop again...
 
  Storage in SQL is
  also an issue,
  From the previous conversation I recall sqlite doesn't have a decimal
 type so we can't run calculating queries on it directly.
 
  But how about the other two: mysql and postsgresql. Is the decimal type
 you're using in your tests directly compatible with the decimal data types
 in mysql and postgresql, or compatible enough to convert automatically
 between them ?
 
  as is maintaining backward file compatibility.
 
  Another issue is equality: In order to get tests to pass I've had to
  implement a fuzzy comparison where both numbers are first rounded to
  the smaller number of decimal places -- 2 fewer if there are 12 or
  more -- and compared with two roundings, first truncation and second
  bankers, and declared unequal only if they're unequal in both. I
  hate this, but it seems to be necessary to obtain equality when
  dealing with large divisors (as when computing prices or interest
  rates). I suspect that we'd have to do something similar if we pursue
  aggressive rounding to avoid overflows, but the only way to know for
  certain is to try.
  Ugh. :(
 
  So what's the current balance ?
 
  I see following pros and cons of your tests so far:
 
  Pro:
  - using a decimal type gives us more precision
 
  Con:
  - sqlite doesn't have a decimal data type, so as it currently stands we
 can't run calculations in queries in that database type
  - we loose backward/forward compatibility with earlier versions of
 GnuCash
  - decNumber or mpDecimal are new dependencies
  - their performance is currently less than the original gnc_numeric
  - guile doesn't know of a decimal data type so we may need some
 conversion glue
  - equality is fuzzy
 
  Please add if I forgot arguments on either side.
 
  Arguably many of the con arguments can be solved. That will effort
 however. And I consider the first two more important than the others.
 
  So do you think the benefits (I assume

Re: C++ work

[Aaron Laws]

Thank you all for your responses. I agree that it's prohibitively difficult
(between all the re-writing and dealing with the current state of business
logic) to act on my suggestion. This conversation also helps solidify my
grasp of the current strategy.


In Christ,
Aaron Laws

On Tue, Sep 9, 2014 at 5:50 PM, John Ralls jra...@ceridwen.us wrote:


 On Sep 9, 2014, at 2:24 PM, Geert Janssens janssens-ge...@telenet.be
 wrote:

  On Tuesday 09 September 2014 15:12:33 Aaron Laws wrote:
  The short question is: What GUI framework is gnucash likely to target
  in c++?
 
  Equally short answer: likely Qt or WxWidgets. But we never did a
 detailed evaluation yet.
 
  I've heard it mentioned that the current framework (GTK?) doesn't make
  sense in c++ because it's so gobject-oriented, but I didn't hear
  anything else suggested. I know there's a QT effort which seems like
  a reasonable way to go, but haven't heard it actually endorsed
  anywhere.
 
  Exactly
 
  Currently, c++ work is starting at the deepest point (the part of the
  code that is relied on by everything), qof, so that a C api has to be
  maintained until everything that relies on QOF has a way of accessing
  the c++ interfaces. This means that c++ and C interfaces need to be
  created and maintained in parallel until everything's ready to
  switch. This has grated on me for quite a while, but I see it as a
  very difficult problem. I don't see a quick way to fix it. I've tried
  (and technically succeeded ^_^) compiling the whole project as c++,
  but that's not so great because the dynamic linking doesn't work
  because of mangling. Repairing this solution doesn't seem like a
  profitable way forward. It's sort of like throwing all your
  belongings into a river, then swimming across yourself, and trying to
  collect everything on the other side, making sure you didn't lose
  anything.
 
  Another way that I've been trying to consider is to start on the part
  of project upon which nothing relies. That way, that part of the
  project can be completely C++. Then, take the next thing which
  doesn't expose a *used* C api. Rinse and repeat. This way, there will
  never (?) have to be a duplicated API in any system.
 
  Sounds nice in theory. I fear it will be equally if not more difficult
 than the current approach
  though.
 
  Taking your example of first replacing the gui.
 
  As you bring up yourself it is heavily gobject based. And in addition
 the controller, model and
  view code are mixed up. Rewriting it in (say) Qt, means it will now use
 Qt objects. But the
  business logic (our engine code) is still gobject based.
 
  So now in order for the gui to talk to the business logic you have to
 create an interface layer
  between the engine and the gui that will do the proper translations
 between the two object
  models. That is probably more work than maintaining the existing C api
 in the path currently
  chosen.
 
  In addition logically it doesn't make sense to start from the gui and
 drill down to the model.
  Your gui should be based on the model and controller logic so it only
 makes sense to start there.
  Going the other way around as a sure way to make wrong assumptions about
 how the lower
  layers will be implemented and in the best case mean several revisions
 to the higher layers or
  having to start over in the worst case.
 
  Another way to think about this is as a tree structure. I'll throw
  something up, and I'll eagerly await corrections! Read - as relies
  on:
 
  GUI (GTK?) - Business Logic
  So rewrite the gui and an interface layer between the two
  Alternate gui (WEB?) - Business Logic
  Same here.
  GUI (GTK?) - Reporting Infrastructure
  Same here.
  Business Logic - QOF
  Rewrite the business logic and write an interface layer between the two.
  Oops, the way we write the business logic now means we need to change
 the gui layer, because
  it made some invalid assumptions on what the business logic would be.
  So rewrite the gui here as well
  Reporting Infrastructure - QOF
  Rewrite the reporting infrastructure and write an interface layer
 between the two.
  Oops, the way we write the reporting infrastructure now means we need to
 change the gui
  layer, because it made some invalid assumptions on what the business
 logic would be.
  So rewrite the gui here as well
 
  QOF - libdrm, etc.
  Rewrite qof and realize we end up with a different implementation that
 we thought we would.
  So rewrite the business logic and the reporting infrastructure once
 more. And bollocks, that kills
  our gui design again. Rewrite the gui...
 
 
  So, if QOF is changed, it still needs to support Business Logic with a
  C api until Business Logic is changed which can't happen until all
  GUIs that rely on it are changed. If, however, a gui layer is
  changed, that's all there is to it; there are no dependencies (if
  there are, we should have started at the dependency!). Once all GUIs
  (I know there's only one, but I'm trying

C++ work

[Aaron Laws]

The short question is: What GUI framework is gnucash likely to target in
c++?

I've heard it mentioned that the current framework (GTK?) doesn't make
sense in c++ because it's so gobject-oriented, but I didn't hear anything
else suggested. I know there's a QT effort which seems like a reasonable
way to go, but haven't heard it actually endorsed anywhere.

Currently, c++ work is starting at the deepest point (the part of the code
that is relied on by everything), qof, so that a C api has to be maintained
until everything that relies on QOF has a way of accessing the c++
interfaces. This means that c++ and C interfaces need to be created and
maintained in parallel until everything's ready to switch. This has grated
on me for quite a while, but I see it as a very difficult problem. I don't
see a quick way to fix it. I've tried (and technically succeeded ^_^)
compiling the whole project as c++, but that's not so great because the
dynamic linking doesn't work because of mangling. Repairing this solution
doesn't seem like a profitable way forward. It's sort of like throwing all
your belongings into a river, then swimming across yourself, and trying to
collect everything on the other side, making sure you didn't lose anything.

Another way that I've been trying to consider is to start on the part of
project upon which nothing relies. That way, that part of the project can
be completely C++. Then, take the next thing which doesn't expose a *used*
C api. Rinse and repeat. This way, there will never (?) have to be a
duplicated API in any system.

Another way to think about this is as a tree structure. I'll throw
something up, and I'll eagerly await corrections! Read - as relies on:

GUI (GTK?) - Business Logic
Alternate gui (WEB?) - Business Logic
GUI (GTK?) - Reporting Infrastructure
Business Logic - QOF
Reporting Infrastructure - QOF
QOF - libdrm, etc.

So, if QOF is changed, it still needs to support Business Logic with a C
api until Business Logic is changed which can't happen until all GUIs that
rely on it are changed. If, however, a gui layer is changed, that's all
there is to it; there are no dependencies (if there are, we should have
started at the dependency!). Once all GUIs (I know there's only one, but
I'm trying to create a sufficiently complicated example!) are c++-ready,
the Business Logic can be converted. No redundant API is necessary.

I'm having trouble even evaluating what I'm talking about because I don't
know any details. Knowing which GUI framework development efforts have in
mind would help a ton :-).

In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gnucash c++

[Aaron Laws]

On Mon, Aug 11, 2014 at 4:52 PM, Christian Stimming christ...@cstimming.de
wrote:

 Hi Aaron,

 thanks for investing time in Gnucash and also in its development towards
 more
 future-proof programming technologies.


The pleasure is mine.


 I was a bit puzzled about the benefit
 of switching the normal compiling from C to C++, just by itself. IMHO,
 there
 is of course an immediate benefit if the data structures move from plain C
 structs to C++ classes, with constructor/destructor and such. If you plan
 to
 do such a transition with any of gnucash's data structures, of course every
 code using those will have to be C++. However, just changing this into C++
 doesn't also solve the problem here: The usage of the C structs in the
 code is
 just that: C structs, with foo_new() and foo_delete() functions and maybe
 even
 glib's reference counting. To really use C++ classes instead, every single
 usage of those old C idioms will have to be replaced by proper C++
 constructs.
 IMHO, just switching the C compiling to C++ doesn't quite bring you much
 gain here. Do you think it helps you much?


Thanks for asking! You're right, changing the compiler from gcc to g++ does
nothing to directly improve maintainability or performance of the code in
question. As I see it, the gains come after that painful process. I'll go
ahead and repeat the strategy I'm investigating for reference:

1) Make all code compile as c++ code
2) Add poison to make it idiomatic c++ code
3) Make higher level changes

Part of the strategy includes this plan being followed rather strictly.
Using this plan, step 3 brings with it the possibility of converting
interfaces to c++ (giving classes constructors and destructors, making
templated algorithms, etc.). Currently, for instance, the guid object is
not usable as proper c++ code even if there were a client code file that
could take advantage of it, because there is no c++ interface in the header
file; if there were, all the C code would barf at compile-time.


 [...snip...] I see some more
 benefit when changing individual data structures to C++, then switching the
 old C functions into wrappers that make the new C++ behaviour available to
 the
 C side.


In a way, that's just what I'm going for. The only way to make typedef
struct _gncGuid {...} GncGUID; into class GncGUID; is to make sure that
every compilation unit (which uses GUID) knows what class GncGUID; means!
At that point, it would be no problem to make GncGUID a class (or a typedef
for a boost class), and even manage it with smart pointers or whatever.
This can be done right alongside (for example) the existing glib date
interface. With this kind of change, we're freed from the requirement that
each code file communicates with the other code files in C. We are now
free to speak a different language as we desire, as we are able, and,
importantly, at our liesure.


 This means the existing C code can continue to compile in C, and the
 next steps would rather be to open the possibility for new C++ code such as
 unittests and maybe new GUI code in C++ (or python or something similar).


So it sounds like you're talking about introducing new c++ code that uses
the existing C interfaces, which I think is an obvious win. The next win
that I'm striving to see is the existing C code start to use C++ idioms,
data structures, etc.

It would be nice if all that makes sense, but I know better than to even
hope for that :-).  Thanks again for asking, and please help me clarify by
asking more questions!

In Christ,
Aaron
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: gnucash master: Multiple changes pushed

[Aaron Laws]

Jralls,

Thanks, these will be very helpful! I'm sure I wouldn't have come up with
that perl replacement for grep.


In Christ,
Aaron Laws


On Fri, Aug 8, 2014 at 6:15 PM, John Ralls jra...@code.gnucash.org wrote:

 Updated  via  https://github.com/Gnucash/gnucash/commit/e25c2a34 (commit)
  via  https://github.com/Gnucash/gnucash/commit/063b9c57 (commit)
  via  https://github.com/Gnucash/gnucash/commit/10cd33f9 (commit)
  via  https://github.com/Gnucash/gnucash/commit/0ddd9db0 (commit)
 from  https://github.com/Gnucash/gnucash/commit/367b608f (commit)



 commit e25c2a34b9e9995936010d5577aa588165d1a61c
 Author: John Ralls jra...@ceridwen.us
 Date:   Fri Aug 8 15:15:23 2014 -0700

 POTFILES.in resulting from previous make-gnucash-potfiles changes.

 commit 063b9c57f4ed9cfe9edb8150c1161ac479003174
 Author: John Ralls jra...@ceridwen.us
 Date:   Fri Aug 8 13:43:43 2014 -0700

 Remove a bunch of no-longer-existing files from POTFILES.skip.

 commit 10cd33f9f584f74fe2c2ac1a827d3c8c4ac06d09
 Author: John Ralls jra...@ceridwen.us
 Date:   Fri Aug 8 13:37:38 2014 -0700

 Add *.cpp to the search pattern for files to translate.

 Exclude the files in src/gnc and src/optional/gtkmm; they shouldn't
 have
 any user-visible strings.

 commit 0ddd9db0a213ef24186df4353aa6ae9fd26d6939
 Author: John Ralls jra...@ceridwen.us
 Date:   Fri Aug 8 13:31:29 2014 -0700

 Use perl instead of grep to scan POTFILES.ignore and POTFILES.skip

 No point in shelling out of perl to do what perl does best; besides,
 grep
 has environment settings that can break our parsing of the result.



 Summary of changes:
  make-gnucash-potfiles.in | 19 +++
  po/POTFILES.in   | 22 +-
  po/POTFILES.skip | 21 +
  3 files changed, 41 insertions(+), 21 deletions(-)

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

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

make-gnucash-potfiles

[Aaron Laws]

I have GREP_OPTIONS=--color=always -n --directories=skip, so when I run
make distcheck, it fails. make-gnucash-potfiles is expecting grep to *not*
put out line numbers nor colors. If the response to this is don't do
that, then you can stop reading. However, if we're wanting this script to
run reliably in the face of a customized environment, the following patch
works:


From 0a150b770f895df9420bd5133bc8ba3960580a28 Mon Sep 17 00:00:00 2001
From: lmat dartm...@gmail.com
Date: Thu, 7 Aug 2014 13:35:17 -0400
Subject: [PATCH] make-gnucash-potfiles is now more reliable

make-gnucash-potfiles relies on certain behaviour from grep. This patch
helps ensure that grep behaves in the way we expect.
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 35f4771..4a2e285 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -185,7 +185,7 @@ pot: Makefile po/POTFILES.in


 $(srcdir)/po/POTFILES.in: make-gnucash-potfiles .potfiles
-if test -w $(srcdir)/po/POTFILES.in ; then ./make-gnucash-potfiles 
$(srcdir)/po/POTFILES.in ; fi
+if test -w $(srcdir)/po/POTFILES.in ; then GREP_OPTIONS=-o
--color=auto ./make-gnucash-potfiles  $(srcdir)/po/POTFILES.in ; fi

 # Creation rules so that po/gnucash.pot can always be created for
 # make dist.
-- 
1.9.1




It's also possible to similarly patch make-gnucash-potfiles itself. If
that's desired, I'll be happy to come up with a patch like that.

In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Gnucash c++

[Aaron Laws]

On Tue, Aug 5, 2014 at 2:04 PM, John Ralls jra...@ceridwen.us wrote:

 Aaron,

 I've pulled and begun testing your guidcpp branch. It looks good, and I
 expect to merge it to master today or Thursday.


Excellent! :-)


 What is the motivation for compiling everything as C++ if it's still
 really C and you have to wrap everything in extern C {} to get it to
 link, especially in gnome and register directories, which can't be
 converted to C++?


The only extern Cs in c++-debug branch are for SCM and module entry
points, and only the latter is for more than one declaration. That comes up
to 13 functions that are declared extern C ?

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

To be clear, I'm just answering your question, not actually proposing this
strategy. If it goes well, it is naturally up to the development team to
adopt such a strategy.

Thanks for the response! I kept my response brief, but anyone feel free to
ask more questions. I spent the last three days or so catching up on
gnucash mailing list items (you've perhaps seen my replies, etc.), and now
I can get back to looking at the code!

In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

gnucash c++

[Aaron Laws]

I tried to follow the directions at
http://wiki.gnucash.org/wiki/Contributing_to_GnuCash, but I couldn't find a
Bugzilla issue encapsulating the Great C++ Refactor. Should I create one so
there is a place to put patches?

I learned on IRC that it is generally a goal not to have C++ keywords in
the Gnucash code base, and this patch is along those ends. I think I got
all the C++11 keywords that would interfere with a C++11 compile. If this
is an inappropriate patch to submit, please let me know. After my
signature, you can find the patch prepared using `git format-patch` (as
specified in http://wiki.gnucash.org/wiki/Git#Patches). Also, I followed
the advice of http://wiki.gnucash.org/wiki/Development_Process (All
development should target the *master* branch.). Please let me know if
anything looks amiss (the amount of context, using unified diff format,
perhaps I should be attaching instead of in-line quotation, etc.). Thanks!

In Christ,
Aaron Laws

From c58457879496a26031e7a412deb429c9ef572fb9 Mon Sep 17 00:00:00 2001
From: lmat dartm...@gmail.com
Date: Wed, 23 Jul 2014 17:47:02 -0400
Subject: [PATCH] Replacing c++ reserved keywords with clean alternatives

---
 src/app-utils/gnc-component-manager.h   |   2 +-
 src/app-utils/test/test-option-util.c   |   2 +-
 src/engine/gnc-commodity.c  | 152

 src/engine/test-core/test-engine-stuff.c|   6 +-
 src/engine/test/utest-Account.c |  22 ++--
 src/engine/test/utest-Transaction.c |  62 +-
 src/gnome-utils/assistant-xml-encoding.c|  10 +-
 src/gnome-utils/dialog-commodity.c  |  96 +++
 src/gnome-utils/dialog-commodity.h  |   4 +-
 src/gnome-utils/dialog-preferences.c|   4 +-
 src/gnome-utils/dialog-reset-warnings.c |   4 +-
 src/gnome-utils/dialog-totd.c   |  14 +--
 src/gnome-utils/gnc-amount-edit.c   |   2 +-
 src/gnome-utils/gnc-cell-renderer-date.c|  12 +-
 src/gnome-utils/gnc-cell-renderer-popup-entry.c |   2 +-
 src/gnome-utils/gnc-cell-renderer-popup.c   |  16 +--
 src/gnome-utils/gnc-combott.c   |  14 +--
 src/gnome-utils/gnc-currency-edit.c |   2 +-
 src/gnome-utils/gnc-date-delta.c|   2 +-
 src/gnome-utils/gnc-date-format.c   |   2 +-
 src/gnome-utils/gnc-dense-cal.c |   2 +-
 src/gnome-utils/gnc-general-select.c|   2 +-
 src/gnome-utils/gnc-period-select.c |   2 +-
 src/gnome-utils/gnc-plugin.c|  32 ++---
 src/gnome-utils/gnc-tree-model-commodity.c  |  92 +++---
 src/gnome-utils/gnc-tree-model-commodity.h  |   2 +-
 src/gnome-utils/gnc-tree-model-price.c  | 102 
 src/gnome-utils/gnc-tree-model-price.h  |   2 +-
 src/gnome-utils/gnc-tree-view-commodity.c   |   6 +-
 src/gnome-utils/gnc-tree-view-price.c   |   6 +-
 src/gnome-utils/search-param.c  |   2 +-
 31 files changed, 340 insertions(+), 340 deletions(-)

diff --git a/src/app-utils/gnc-component-manager.h
b/src/app-utils/gnc-component-manager.h
index 7de280f..45fc187 100644
--- a/src/app-utils/gnc-component-manager.h
+++ b/src/app-utils/gnc-component-manager.h
@@ -104,7 +104,7 @@ typedef gboolean (*GNCComponentFindHandler) (gpointer
find_data,
  *
  * Return: TRUE if the callback did something
  */
-typedef gboolean (*GNCComponentHandler) (const char *class,
+typedef gboolean (*GNCComponentHandler) (const char *component_class,
 gint component_id,
 gpointer user_data,
 gpointer iter_data);
diff --git a/src/app-utils/test/test-option-util.c
b/src/app-utils/test/test-option-util.c
index dc99f32..8fef4c0 100644
--- a/src/app-utils/test/test-option-util.c
+++ b/src/app-utils/test/test-option-util.c
@@ -41,7 +41,7 @@ typedef struct
 /* Expose a mostly-private QofInstance function to load options into
  * the Book.
  */
-extern KvpFrame *qof_instance_get_slots (QofInstance*);
+extern KvpFrame *qof_instance_get_slots (const QofInstance*);

 static void
 setup (Fixture *fixture, gconstpointer pData)
diff --git a/src/engine/gnc-commodity.c b/src/engine/gnc-commodity.c
index d5f6eb0..554cbf6 100644
--- a/src/engine/gnc-commodity.c
+++ b/src/engine/gnc-commodity.c
@@ -68,7 +68,7 @@ struct gnc_commodity_s

 typedef struct CommodityPrivate
 {
-gnc_commodity_namespace *namespace;
+gnc_commodity_namespace *nmspace;

 char* fullname;
 char* mnemonic;
@@ -592,7 +592,7 @@ reset_unique_name(CommodityPrivate *priv)
 gnc_commodity_namespace *ns;

 g_free(priv-unique_name);
-ns = priv-namespace;
+ns = priv-nmspace;
 priv-unique_name = g_strdup_printf(%s::%s,
 ns ? ns-name : ,
 priv-mnemonic ? priv-mnemonic :
);
@@ -608,7 +608,7 @@ gnc_commodity_init(gnc_commodity* com)

 priv

Gnucash c++

[Aaron Laws]

I've been doing some work on gnucash with relation to c++. I'm LMAT on
IRC. I got the project to compile, link, and run as c++ (no .c files I'm
pretty sure). I think it doesn't load any backends, and there are other
problems. I had to solve a problem with the module loading because c++
mangles names (if you don't know what this is, it's much better than it
sounds!). I added extern C to those entry points so that they could be
found (in their unmangled form). I'm assuming the backend loading is
similar, but having taken a look, I don't think it works in the same way.

https://github.com/limitedAtonement/gnucash/tree/c++-debug is my debug
tree. Don't count on it for anything, I may be doing force-pushing now
and then. Currently, this is the version that runs if you want to take a
look. (I think I'll put a tag here soon.)

https://github.com/limitedAtonement/gnucash/tree/c++-work is where I plan
on putting something that may e.g. actually be pullable into gnucash. For
instance, the first commits I plan to put here are updates to names to
remove c++ keywords, and changing c signatures to be c++ compatible (none
of this   func (one, two) char one; char * two; {} stuff).

And, https://github.com/limitedAtonement/gnucash/tree/guidcpp is the boost
guid branch on which I currently have issued a pull request.

I've been learning a lot about the code base by doing this work, and I'm
sure it would be *much* faster if I knew more about how certain things were
configured. Let me know what you think if you get a chance to take a look
around!

In Christ,
Aaron Laws
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: switching to C++ compiling by -xc++ (was: gnucash master: Multiple changes pushed)

[Aaron Laws]

I just updated guid.cpp to use boost, and I was very pleased at the
lack of explosions :-)  I issued a pull request to jralls, but for
general perusal, you can see it here:
https://github.com/limitedAtonement/gnucash/commit/3dc5159cb57f25dc606416263bee8b23da3e6ffe

In Christ,
Aaron Laws


On Mon, Apr 28, 2014 at 2:06 PM, John Ralls jra...@ceridwen.us wrote:

 On Apr 28, 2014, at 10:55 AM, Mike Alexander m...@umich.edu wrote:

 --On April 28, 2014 9:04:06 AM -0700 John Ralls jra...@ceridwen.us wrote:


 On Apr 28, 2014, at 8:51 AM, Mike Alexander m...@umich.edu wrote:

 --On April 28, 2014 7:47:07 AM -0700 John Ralls jra...@ceridwen.us
 wrote:

 I'll make gnucash-bin.cpp after that.

 Why not do it first?  It needs to be done sooner or later and that
 might avoid some of the explosions.

 I *want* the explosions. Think of it as test-driven development on a
 larger scale: You can't see what effect a fix has if you don't break
 it first. OTOH, if it breaks and you fix it, then the next time you
 see similar symptoms you already know how to deal with it.

 If that's what you want, that's ok with me.  Having lived through that 
 particular set of explosions once I'm not particularly interested in doing 
 it again, so I'll wait for the dust to settle.

 And I’ll try to keep the dust to myself, unlike last weekend.

 Regards,
 John Ralls


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

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