Re: Bug 612214 and Bug 726674 - duplicates?
On Sunday 10 August 2014 19:39:26 Carsten Rinke wrote: Hi Geert, do you agree that Bug 726674 https://bugzilla.gnome.org/show_bug.cgi?id=726674 - Budget Report always shows some inconsistent signs is a duplicate of *Bug 612214* https://bugzilla.gnome.org/show_bug.cgi?id=612214 -Budgets are not aware of UI sign-reversals ? Hi Carsten, These look like duplicate to me. I have marked them as such. Thanks for triaging! Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Bug 612214 and Bug 726674 - duplicates?
Hi Please take me off this mailing list. It is too complicated for me - way over my head. Thanks, John ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Aug 11, 2014, at 4:52 PM, Christian Stimming christ...@cstimming.de wrote: thanks for investing time in Gnucash and also in its development towards more future-proof programming technologies. I was a bit puzzled about the benefit of switching the normal compiling from C to C++, just by itself. IMHO, there is of course an immediate benefit if the data structures move from plain C structs to C++ classes, with constructor/destructor and such. If you plan to do such a transition with any of gnucash's data structures, of course every code using those will have to be C++. However, just changing this into C++ doesn't also solve the problem here: The usage of the C structs in the code is just that: C structs, with foo_new() and foo_delete() functions and maybe even glib's reference counting. To really use C++ classes instead, every single usage of those old C idioms will have to be replaced by proper C++ constructs. IMHO, just switching the C compiling to C++ doesn't quite bring you much gain here. Do you think it helps you much? I have some doubts. I see some more benefit when changing individual data structures to C++, then switching the old C functions into wrappers that make the new C++ behaviour available to the C side. This means the existing C code can continue to compile in C, and the next steps would rather be to open the possibility for new C++ code such as unittests and maybe new GUI code in C++ (or python or something similar). IMHO this would be more benefitial. What do others think? What you say is correct, of course, but I don’t think it’s a complete waste of time to switch over to C++ for most compiles. It has a few advantages I can think of: 1. C++ compilers enforce more strict standards for C code and will catch problems the C compiler may not catch. 2. When some data structure is converted to a C++ class then there’s a good chance that any code that uses it will already be C++ code. 3. Header files won’t have to have as many #ifdef __cplusplus ... endif constructs. These are all pretty minor, but they are useful, I think. There are probably other advantages too. On the other hand it will be a lot of work to get everything to work in C++. I think only the easy part has been done so far. The last time I worked on something like this we did what you suggest, Christian, and it worked well. Whether it’s worth doing this is not obvious to me. Mike ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
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 c++
On Aug 12, 2014, at 7:22 AM, Aaron Laws dartm...@gmail.com wrote:
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!
When you compile a struct in C++, it gets a set of constructors and a
destructor regardless of whether you write them or not.
The GUI API that we're currently using is in C, as are all of the container
classes (GList mostly) and the GValue data-passing mechanism that's for the
moment central to KVP and the SQL backend. Quite a lot of those APIs work with
callbacks that must be in C linkage, and those callbacks are typically static
functions. Few of them are pre-declared, so it will be a tedious job to find
each one and create an extern C declaration for it. In the container case
it's wasted work: It gets thrown away when the using class is rewritten in C++
with std containers.
Take a look at the way I've wrapped GncNumeric with gnc_numeric in
https://github.com/jralls/gnucash/blob/libmpdecimal/src/libqof/qof/gnc-numeric.h
C++ code can use class GncNumeric directly (once the operator overloads are
added) while C code continues to use the gnc_numeric API.
I'm in favor of cleaning out the C++ reserved words (looks like namespace and
class are the primary offenders; the Gnome rubric is to use klass, so let's do
that instead of clas). Doing so will speed up the file-by-file conversion when
the time comes. I don't think that trying to make everything C++ linkage is a
good use of time because most of the work will be
Re: Apportioning GST in the account register
Hi, Mark Sutton m...@lazo.ca writes: Hi,I guess I should comment about a solution I have imagined for some time. It has been suggested before that formula can be entered into the amount fields of the ledger. For an item with tax included, such as a bank import. I would enter something like $amount - ($amount * 5 / 105) this leaves the amount before tax in the account entry and generates an IMBALANCE-CAD entry for the input tax credit amount. For me this happens to be one or two account entries away from GST-ITC. It only does this if you commit the transaction then. If you don't commit it, and instead tab or arrow out of the line, then you'll get a new split with the tax amount and you can assign the account. This works fine, but it seems just wrong to be entering the same formula over and over again into a programmable device. One possibility would be to have this formula available from the ALT menu. Ideal would be a group a user defined formula, and the ability to place products into specific accounts. Not automated, but a step in the right direction. At this point the ALT menu has the ability to delete a transaction or the splits from a transaction . It also seems to have a the ability to create new entries other accounts. How possible is it to add the other functionality? SMOP. Patches always welcome. Cheers. Mark -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Manual in French
Dear Team, Is it possible to get a manual in French or Draft ? Many thanks Best regards Nicolas KERSPERN Ce message et toutes les pièces jointes (ci-après le message) sont établis à l’intention exclusive des destinataires désignés. Il contient des informations confidentielles et pouvant être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de détruire le message. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse de l’émetteur. L'internet ne garantissant pas l'intégrité de ce message lors de son acheminement, Atos (et ses filiales) décline(nt) toute responsabilité au titre de son contenu. Bien que ce message ait fait l’objet d’un traitement anti-virus lors de son envoi, l’émetteur ne peut garantir l’absence totale de logiciels malveillants dans son contenu et ne pourrait être tenu pour responsable des dommages engendrés par la transmission de l’un d’eux. This message and any attachments (the message) are intended solely for the addressee(s). It contains confidential information, that may be privileged. If you receive this message in error, please notify the sender immediately and delete the message. Any use of the message in violation of its purpose, any dissemination or disclosure, either wholly or partially is strictly prohibited, unless it has been explicitly authorized by the sender. As its integrity cannot be secured on the internet, Atos and its subsidiaries decline any liability for the content of this message. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: question about compiling
John Ralls jra...@ceridwen.us writes: On Aug 10, 2014, at 7:48 PM, Andrew Schein and...@andrewschein.com wrote: Hi all - I have been toying around with gnucash sources for the first time, and was interested to know if there are existing practices for fast compilation? For example, make install takes 30 seconds even if nothing has changed. Is there a fast way to iterate code changes and test? You can cd to the subdirectory where you're working and run make make check. That's way faster than building all of GnuCash and installing it, but it depends on there being good test coverage. Unfortunately for most of GnuCash that means you need to write tests before you start changing things. GnuCash is huge and doesn't run from the build directory, so if you need to test the whole application you're pretty much stuck with a rather long edit-build-install-test cycle. Moreover, if you're only changing C files (and not header files), then you can often just make make check make install from the specific directory you're working in. I.e., you don't necessarily need to rebuild/install the entire project. (I'll also add that 30s for make install is pretty darn fast. On Win32 it can take minutes, or more). Regards, John Ralls -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH warl...@mit.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Manual in French
On Aug 11, 2014, at 7:09 PM, KERSPERN, NICOLAS nicolas.kersp...@atos.net wrote: Dear Team, Is it possible to get a manual in French or Draft ? That's a user question, so in future please use gnucash-us...@gnucash.org. Sadly, no, no one has provided a French translation for either the Help or the Tutorial and Concepts Guide. Either or both would be greatly appreciated... Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
