[GNC-dev] Simple Start to Contributing

[john]

Paul,

Sounds like you'll fit right in. ;-)

Git is an amazing improvement over CVS and subversion. I highly recommend at least skimming Pro Git (https://git-scm.com/book/en/v2, free to read online) to get an idea of how it can help you keep your coding work organized.

Regards,
John Ralls


> On Jul 16, 2022, at 5:44 AM, Paul Kroitor <paul at kroitor.ca> wrote:
> 
> Thanks for your kind welcome, John.
> 
> Well, my first real language was Fortran in the early 70s, but my first love
> was 360/ASM. I knew (at least some of) 14 languages when I graduated in 1976
> but you won't have heard of many of them. My first job was
> maintaining/extending the (assembly-language, on punch card) mainframe
> operating system at a big pharma firm, although everyone else there was
> strictly COBOL. I still recall one of my peers trying to persuade the rest
> of us that you could write programs without Go-Tos with a new-fangled thing
> called Structured Programming. Of course, this wasn't any of my business as
> 360/ASM doesn't have the instructions for it. Then, as a young IT department
> manager in the early 80s, I can still vividly recall two young
> whippersnappers (they were 20; I was 25) in my office trying to persuade me
> that COBOL was out of date, and we would all be using C soon.
> 
> In later years I spent most of my time in C, Pascal, and C++, but as Project
> Manager or Director of Development. That said, I was always the type to get
> my hands dirty, and whenever there was a requirement for low-level stuff
> (like x86 Assembler), I always wound up assigning it to myself (it's still
> my favourite part). I've written hundreds of things in C++ and other
> object-oriented languages. These days the first thing I reach for -- given
> the simple things that come my way -- is Python, Powershell, or Javascript.
> 
> The source control I've used is almost exclusively CVS and Subversion, but I
> do understand what git is and why it's better. My question about making a
> feature branch was a response to an instruction in the Wiki about when to do
> so -- this little project seemed to be just on the borderline. Based on your
> comments, I'll play it safe and do so.
> 
> I have no trouble following the Guile/Scheme -- Lisp was one of the original
> 14 languages I studied in college -- and many reports date back 20 years or
> more anyway. The difficulties come more with the layers of approaches /
> authors you get in such mature systems. For example, the balance sheet and
> income statement use common support modules that enable certain standard
> optional behaviours, but the cash flow wasn't written to use said modules,
> so one has to duplicate the functionality but really should toss half the
> cash-flow and use the (better) common support modules.
> 
> I've built a Rocky 9 (just released, and I want to start testing it anyway)
> VM for this and will set up the GnuCash build environment on it next (I did
> a similar thing a couple of years ago, it went fine). Then I will move on to
> integrating the changes.
> 
> You should know that although I'm retired, I'm very overcommitted, and I
> only get to a small percentage of what I hope to achieve. But I will do what
> I have time for, with your valuable help.
> 
> Paul
> 
> 
> -----Original Message-----
> From: John Ralls <jralls at ceridwen.us> 
> Sent: July 15, 2022 7:04 PM
> To: Paul Kroitor <paul at kroitor.ca>
> Cc: gnucash-devel at gnucash.org
> Subject: Re: [GNC-dev] Simple Start to Contributing
> 
> 
> 
>> On Jul 15, 2022, at 10:58 AM, Paul Kroitor <paul at kroitor.ca> wrote:
>> 
>> Hi, my apologies for asking such basic questions, but I'm new to 
>> GnuCash contributions - although not to coding - and want to try a 
>> simple (useful) change to get my feet wet. So I've "fixed" the 
>> cash-flow.scm module (the Cash Flow report) locally to adjust a minor 
>> annoyance (I added a "Show Accounts as Hyperlinks" checkbox so it can 
>> match the other two standard financial statements). It works the way 
>> it should now, but needs testing against a broader set of inputs, and the
> localizations must get queued.
>> 
>> 
> 
> Welcome to GnuCash!
> 
> What languages and programming styles (I mean what are sometimes rather
> grandly called paradigms, like object-oriented or functional) do you like?
> 
> Your question about feature branches suggests that you may not be familiar
> with git. What source control systems have you used?
> 
>> 
>> Some questions arise:
>> 
>> 1.	Do I have to post anywhere / get agreement before embarking on such
>> a contribution (I have 30+ years of experience managing programmers 
>> and do know I must keep the changes homogenous in style and approach 
>> to the existing codebase)?
> 
> For simple changes like this, no. For more substantial changes or new
> features it's wise to discuss here starting with whether the proposed change
> is even something that we'll accept and once that's settled working out the
> design.
> 
>> 2.	Must I checkout and build the entire project if I am only going to
>> be working in Guile/Scheme for the moment, or is there a simple way to 
>> do a subset?
> 
> GnuCash doesn't have any subprojects so you have to clone the whole thing.
> If you don't want to build yourself you can enable CI on your personal
> GitHub repo and let Github actions run the building and testing part for
> you.
> 
>> 3.	Do a make a "feature branch" for this very localized change? It's
>> about 10 lines in a single file.
> 
> Unless you're planning to have only one open pull request at a time you'll
> make your life much simpler with feature branches. Branching in git is not
> only utterly painless it's a great way to organize your work. I often create
> multiple branches to try out different approaches to solving a problem or
> implementing something, flipping back and forth between the branches as my
> thinking and the code evolves. Commit often, it's a lot easier to squash a
> bunch of commits together than it is to pick apart a pile of changes into
> separate commits.
> 
>> 4.	I have about 10 sets of production books here, but I use no business
>> or shareholding features. The changes shouldn't interact with these, 
>> but they should be checked anyway. Are there test .gnucash databases 
>> with "one of everything" than can be used to test against (I do use 
>> multiple currencies, and have tested that)?
> 
> Unfortunately there isn't. It would be great to have one or more.
> 
>> 5.	I understand that the localizations will happen semi-automatically
>> by a different team, but is there a way to use a common instance of 
>> the base
>> (English) text constant so they don't have to re-translate strings 
>> that are already there (e.g. the "Show Accounts as Hyperlinks" string 
>> is already in a half-dozen other scheme files, and thus will have 
>> already been translated into many languages)?
> 
> Nothing automatic. You can look at and search the existing translation files
> in po/ to find existing strings that might work for you.
> 
>> 
>> 6.	How / who do I tell that it's new and should be tested before
>> release?
> 
> You can try pleading on gnucash-user for people to try out your feature in
> the nightly builds once it's been merged, but we haven't had a lot of
> success with that except when fixing something that someone has complained
> about.
> 
> Regards,
> John Ralls
> 
>