Re: Gnucash c++
On Thursday 14 August 2014 10:04:55 Gour wrote: > On Wed, 13 Aug 2014 17:20:51 -0700 > > John Ralls wrote: > > Then I can make a C++ class and move the functionality into > > it one function at a time, converting the C function to a wrapper > > with C linkage. I can test that against the existing C tests, add > > C++ > > tests, and move on to the next function. The rest of GnuCash can't > > tell anything's changed; new work now has two versions of the API to > > use depending on whether it's completely new or a modification of > > existing. If it comes time to start the release cycle and the > > conversion isn't complete, we can ship it as-is because nothing's > > broken. > > It sounds good *in theory*, but I'm not so sure you're going to > rewrite engine and get rid of cruft this way. > > Still, as a happy GC user, I wish you all success. > > For the sake of experiment I briefly tried KMyMoney anticipating that > (maybe) KDE could fill the need, but *very* quickly I was back to > xfce/i3/Gnucash. :-) > Off topic for this thread - I'd love to hear what were the things you liked about KMyMoney and what you found missing. Can I ask you to share your experience in another e-mail thread on gnucash-user ? It would IMO be very valuable feedback for gnucash to learn about it's strengths and weaknesses. Feel free to mention I asked about this if you start such a topic. Thanks, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Wed, 13 Aug 2014 17:20:51 -0700 John Ralls wrote: > Then I can make a C++ class and move the functionality into > it one function at a time, converting the C function to a wrapper > with C linkage. I can test that against the existing C tests, add C++ > tests, and move on to the next function. The rest of GnuCash can't > tell anything's changed; new work now has two versions of the API to > use depending on whether it's completely new or a modification of > existing. If it comes time to start the release cycle and the > conversion isn't complete, we can ship it as-is because nothing's > broken. It sounds good *in theory*, but I'm not so sure you're going to rewrite engine and get rid of cruft this way. Still, as a happy GC user, I wish you all success. For the sake of experiment I briefly tried KMyMoney anticipating that (maybe) KDE could fill the need, but *very* quickly I was back to xfce/i3/Gnucash. :-) Sincerely, Gour -- An intelligent person does not take part in the sources of misery, which are due to contact with the material senses. O son of Kuntī, such pleasures have a beginning and an end, and so the wise man does not delight in them. signature.asc Description: PGP signature ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
Its very possible to begin he transition to C++ by writing C++ header files. The real advantage of C++ is the ability to take a specification (in my case the Intel IBIS electronic buffer modeling specification http://www.eigroup.org/ibis/ibis.htm) and modelling it with C++ header files that compile. This provides an unambiguous representation of a specification allowing multiple vendors to create data structures that always run correctly. In addition, the early on representation (i.e is this an iterator or whatever) and class definition really tie the code writers down. The particular project I mentioned took a summer grad student 3 months to create the header files from a complicated spec. Then the project was cancelled (because it worked)! As a result vendor A's models might not work with vendor B's simulator... As difficult as I find C++ to understand I highly recommend its use. Tedc On Wed, Aug 13, 2014 at 5:20 PM, John Ralls wrote: > > On Aug 13, 2014, at 3:42 PM, Gour wrote: > > > On Wed, 13 Aug 2014 11:21:59 -0400 > > Derek Atkins wrote: > > > >> Ummm.. No. > > > > OK. > > > >> The benefit of C -> C++ is that except for a few minor issues with > >> keywords you can *generally* compile C code using the C++ compiler and > >> it will *just work*. > > > > That's clear. > > > >> The same cannot be said for Go or any other language. > > > > Btw, Go team converts Go compiler from C to Go. ;) > > > >> Please read the FAQ entry on "Why don't you (re)write GnuCash in >> favorite language>" at http://wiki.gnucash.org/wiki/FAQ > > > > Well, being in #gnucash I got the feeling that there is plan to abandon > > glib, rewrite the engine and possibly even to consider Qt 'cause > > without glib, one is not tied so much to GTK any longer. > > > > Considering that C --> C++ (and taking advantage of it) might be more > > strange than C --> Go which is created to be picked easily by C devs, I > > did throw my suggestion. > > > > Otoh, I believe that C --> C++ is not to be done in order to just > > increase build time.* :-) > > > > * Rob Bike from the Go team says that long build times (~45mins) for C++ > > * projects was the time when Go was conceived. ;) > > > > I'm aware of FAQ entry, but was thinking that GC is on the verge of > > possible (partial) rewrite. > > All true, but you missed Derek's point. The advantage of C++ is that one > can use it with C *in the same file*. That means I can take a C file, tell > the compiler it's really a C++ file, and compile it almost as-is (that's > what Aaron's change is about, cleaning up all of the almosts). Then I can > make a C++ class and move the functionality into it one function at a time, > converting the C function to a wrapper with C linkage. I can test that > against the existing C tests, add C++ tests, and move on to the next > function. The rest of GnuCash can't tell anything's changed; new work now > has two versions of the API to use depending on whether it's completely new > or a modification of existing. If it comes time to start the release cycle > and the conversion isn't complete, we can ship it as-is because nothing's > broken. > > There other languages like that, but they're all AFAIK tied to particular > proprietary platforms to some extent: Objective C and Apple, C# and > Microsoft, Vala and Gtk+. C++ is ISO-standard with an extremely active > committee. > > 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
Re: Gnucash c++
On Aug 13, 2014, at 3:42 PM, Gour wrote: > On Wed, 13 Aug 2014 11:21:59 -0400 > Derek Atkins wrote: > >> Ummm.. No. > > OK. > >> The benefit of C -> C++ is that except for a few minor issues with >> keywords you can *generally* compile C code using the C++ compiler and >> it will *just work*. > > That's clear. > >> The same cannot be said for Go or any other language. > > Btw, Go team converts Go compiler from C to Go. ;) > >> Please read the FAQ entry on "Why don't you (re)write GnuCash in > favorite language>" at http://wiki.gnucash.org/wiki/FAQ > > Well, being in #gnucash I got the feeling that there is plan to abandon > glib, rewrite the engine and possibly even to consider Qt 'cause > without glib, one is not tied so much to GTK any longer. > > Considering that C --> C++ (and taking advantage of it) might be more > strange than C --> Go which is created to be picked easily by C devs, I > did throw my suggestion. > > Otoh, I believe that C --> C++ is not to be done in order to just > increase build time.* :-) > > * Rob Bike from the Go team says that long build times (~45mins) for C++ > * projects was the time when Go was conceived. ;) > > I'm aware of FAQ entry, but was thinking that GC is on the verge of > possible (partial) rewrite. All true, but you missed Derek's point. The advantage of C++ is that one can use it with C *in the same file*. That means I can take a C file, tell the compiler it's really a C++ file, and compile it almost as-is (that's what Aaron's change is about, cleaning up all of the almosts). Then I can make a C++ class and move the functionality into it one function at a time, converting the C function to a wrapper with C linkage. I can test that against the existing C tests, add C++ tests, and move on to the next function. The rest of GnuCash can't tell anything's changed; new work now has two versions of the API to use depending on whether it's completely new or a modification of existing. If it comes time to start the release cycle and the conversion isn't complete, we can ship it as-is because nothing's broken. There other languages like that, but they're all AFAIK tied to particular proprietary platforms to some extent: Objective C and Apple, C# and Microsoft, Vala and Gtk+. C++ is ISO-standard with an extremely active committee. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Wed, 13 Aug 2014 11:21:59 -0400 Derek Atkins wrote: > Ummm.. No. OK. > The benefit of C -> C++ is that except for a few minor issues with > keywords you can *generally* compile C code using the C++ compiler and > it will *just work*. That's clear. > The same cannot be said for Go or any other language. Btw, Go team converts Go compiler from C to Go. ;) > Please read the FAQ entry on "Why don't you (re)write GnuCash in favorite language>" at http://wiki.gnucash.org/wiki/FAQ Well, being in #gnucash I got the feeling that there is plan to abandon glib, rewrite the engine and possibly even to consider Qt 'cause without glib, one is not tied so much to GTK any longer. Considering that C --> C++ (and taking advantage of it) might be more strange than C --> Go which is created to be picked easily by C devs, I did throw my suggestion. Otoh, I believe that C --> C++ is not to be done in order to just increase build time.* :-) * Rob Bike from the Go team says that long build times (~45mins) for C++ * projects was the time when Go was conceived. ;) I'm aware of FAQ entry, but was thinking that GC is on the verge of possible (partial) rewrite. All the best! Sincerely, Gour -- One who sees inaction in action, and action in inaction, is intelligent among men, and he is in the transcendental position, although engaged in all sorts of activities. -- An intelligent person does not take part in the sources of misery, which are due to contact with the material senses. O son of Kuntī, such pleasures have a beginning and an end, and so the wise man does not delight in them. 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: Gnucash c++
Gour writes: > 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. Ummm.. No. The benefit of C -> C++ is that except for a few minor issues with keywords you can *generally* compile C code using the C++ compiler and it will *just work*. The same cannot be said for Go or any other language. Please read the FAQ entry on "Why don't you (re)write GnuCash in " at http://wiki.gnucash.org/wiki/FAQ -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++
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: Gnucash c++
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++
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: Gnucash c++
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: Gnucash c++
Hi Aaron, 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? Regards, Christian Am Mittwoch, 6. August 2014, 13:26:14 schrieb Aaron Laws: > 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. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash c++
On Wednesday 06 August 2014 19:15:35 John Ralls wrote: > On Aug 6, 2014, at 2:16 PM, Geert Janssens wrote: > > On Wednesday 06 August 2014 16:16:17 Aaron Laws wrote: > >> 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, > > > > Hi Aaron, > > > > Thank you for your patch. I haven't tested it yet but IMO the > > intention is correct. > > > > As for bugzilla: you can create a new bugreport and attach your > > patch there. Attaching it to a mailing list message risks that it > > gets lost in the midst of the ongoing discussions. 'git format- > > patch' is perfectly fine as format. > > > > As for the "All development should target the *master* branch", we > > should change this. That's advice from the svn era. In git bugfixes > > should target the *maint* branch. New features and enhancements > > should target *master*. > > I clarified > http://wiki.gnucash.org/wiki/Development_Process#Developing_New_Featu > res a bit and cleared out all of the old stuff about backports and > audits. I'm not quite satisfied with it, so I'll let it percolate in > my head for a day or two and have another go. If someone else has > some thoughts, by all means dive in. > I altered some more parts that still wrongly suggested all bugfix development should go on master. But I still welcome more improvements and clarifications. > Let's not have a generic "Convert GnuCash to C++" bug that will > accumulate a zillion patches and a zillion comments. That will just > become a headache. If you (Aaron) would rather attach the patch to a > bug, make it "Remove C++11/14 Keywords"or something, but I'm > perfectly happy using Github pull requests for C++ if that's more > convenient. I don't really see that patch as a bug-fix; it's not a > problem with maint that it doesn't compile in C++. OTOH, *not* > applying it to maint will make it harder to merge into master sooner > than otherwise, so I'm not opposed to it either as long as it passes > `make distcheck`. > Fully agreed. It may be better to apply this one against maint in the hopes it will result in simple merges for a while longer. It has to pass make distcheck of course. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash c++
On Aug 6, 2014, at 2:16 PM, Geert Janssens wrote: > On Wednesday 06 August 2014 16:16:17 Aaron Laws wrote: >> 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, > > > Hi Aaron, > > Thank you for your patch. I haven't tested it yet but IMO the intention is > correct. > > As for bugzilla: you can create a new bugreport and attach your patch there. > Attaching it to a > mailing list message risks that it gets lost in the midst of the ongoing > discussions. 'git format- > patch' is perfectly fine as format. > > As for the "All development should target the *master* branch", we should > change this. > That's advice from the svn era. In git bugfixes should target the *maint* > branch. New > features and enhancements should target *master*. I clarified http://wiki.gnucash.org/wiki/Development_Process#Developing_New_Features a bit and cleared out all of the old stuff about backports and audits. I'm not quite satisfied with it, so I'll let it percolate in my head for a day or two and have another go. If someone else has some thoughts, by all means dive in. Let's not have a generic "Convert GnuCash to C++" bug that will accumulate a zillion patches and a zillion comments. That will just become a headache. If you (Aaron) would rather attach the patch to a bug, make it "Remove C++11/14 Keywords"or something, but I'm perfectly happy using Github pull requests for C++ if that's more convenient. I don't really see that patch as a bug-fix; it's not a problem with maint that it doesn't compile in C++. OTOH, *not* applying it to maint will make it harder to merge into master sooner than otherwise, so I'm not opposed to it either as long as it passes `make distcheck`. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: gnucash c++
On Wednesday 06 August 2014 16:16:17 Aaron Laws wrote: > 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, Hi Aaron, Thank you for your patch. I haven't tested it yet but IMO the intention is correct. As for bugzilla: you can create a new bugreport and attach your patch there. Attaching it to a mailing list message risks that it gets lost in the midst of the ongoing discussions. 'git format- patch' is perfectly fine as format. As for the "All development should target the *master* branch", we should change this. That's advice from the svn era. In git bugfixes should target the *maint* branch. New features and enhancements should target *master*. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Gnucash c++
On Tue, Aug 5, 2014 at 2:04 PM, John Ralls 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 "C"s 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
Re: Gnucash c++
On Aug 5, 2014, at 8:05 AM, Aaron Laws wrote: > 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! Aaron, I've pulled and begun testing your guidcpp branch. It looks good, and I expect to merge it to master today or Thursday. 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++? Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel