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 <p...@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 <jra...@ceridwen.us> > Sent: July 15, 2022 7:04 PM > To: Paul Kroitor <p...@kroitor.ca> > Cc: gnucash-devel@gnucash.org > Subject: Re: [GNC-dev] Simple Start to Contributing > > > >> On Jul 15, 2022, at 10:58 AM, Paul Kroitor <p...@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 > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
