Re: Gnucash c++

[Gour]

On Tue, 5 Aug 2014 11:04:00 -0700
John Ralls  wrote:

Hello all,

> 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++?

when I visited #gnucash the other day I heard about the plan to (slowly) move
to C++.

Although I'm aware that I do not have 'currency' to influence the switch, I'd
just like to give my 0.02hrk (1$ ~ 5.8hrk) and propose to (just) consider using
Go language instead.

Here is nice article http://talks.golang.org/2012/splash.article explaining
about the reason to conceive the language which is solving some of the
performance problems encounted when building large C++ apps.

Moreover, it is meant to be easily approachable for the developers being
familiar with C (which is not really the case with C++) and we could say that
Go is kind of 'modern C'.

Not wanting to go deeper into any sort of argumentation being more than happy
that Gnucash is givne to me for free this is just attempt to my side in order
to provide some feedback to make GC even better developer-wise.


Sincerely,
Gour

-- 
The work of a man who is unattached to the modes of material 
nature and who is fully situated in transcendental knowledge 
merges entirely into transcendence.

http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


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

Re: Manual in French

[John Ralls]

On Aug 11, 2014, at 7:09 PM, KERSPERN, NICOLAS  
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

Re: question about compiling

[Derek Atkins]

John Ralls  writes:

> On Aug 10, 2014, at 7:48 PM, Andrew Schein  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

Manual in French

[KERSPERN, NICOLAS]

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: Apportioning GST in the account register

[Derek Atkins]

Hi,

Mark Sutton  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

Re: Gnucash c++

[John Ralls]

On Aug 12, 2014, at 7:22 AM, Aaron Laws  wrote:

> On Mon, Aug 11, 2014 at 4:52 PM, Christian Stimming 
> 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 

Re: Gnucash c++

[Aaron Laws]

On Mon, Aug 11, 2014 at 4:52 PM, Christian Stimming 
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: Bug 612214 and Bug 726674 - duplicates?

[Mike Evans]

On Tue, 12 Aug 2014 22:32:40 +1000
John Mamutil  wrote:

> 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

Just follow the link at the bottom of this mail and hit the unsubscribe button 
near the bottom of the page.

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: Gnucash c++

[Mike Alexander]

On Aug 11, 2014, at 4:52 PM, Christian Stimming  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: Bug 612214 and Bug 726674 - duplicates?

[John Mamutil]

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: Bug 612214 and Bug 726674 - duplicates?

[Geert Janssens]

On Sunday 10 August 2014 19:39:26 Carsten Rinke wrote:
> Hi Geert,
> 
> do you agree that
> Bug 726674  -
> Budget Report always shows some inconsistent signs
> 
> is a duplicate of
> *Bug 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