Re: [GNC-dev] Simple Start to Contributing

2022-07-16 Thread 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  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  
> Sent: July 15, 2022 7:04 PM
> To: Paul Kroitor 
> Cc: gnucash-devel@gnucash.org
> Subject: Re: [GNC-dev] Simple Start to Contributing
> 
> 
> 
>> On Jul 15, 2022, at 10:58 AM, Paul Kroitor  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 hom

Re: [GNC-dev] Simple Start to Contributing

2022-07-16 Thread Geert Janssens
Op zaterdag 16 juli 2022 14:44:06 CEST schreef Paul Kroitor:
> 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.
> 

Hi Paul,

Welcome to gnucash indeed.

That's an interesting analysis of the cash flow report and at the same time 
that could be an 
opportunity for your next contribution (if you feel so inclined of course)  :)

Regards,

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


Re: [GNC-dev] Simple Start to Contributing

2022-07-16 Thread Paul Kroitor
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  
Sent: July 15, 2022 7:04 PM
To: Paul Kroitor 
Cc: gnucash-devel@gnucash.org
Subject: Re: [GNC-dev] Simple Start to Contributing



> On Jul 15, 2022, at 10:58 AM, Paul Kroitor  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&quo

Re: [GNC-dev] Simple Start to Contributing; Message Recycling

2022-07-15 Thread Frank H. Ellenberger
Hi Paul,

welcome!

Am 16.07.22 um 01:03 schrieb John Ralls:
> 
> 
>> On Jul 15, 2022, at 10:58 AM, Paul Kroitor  wrote:
:
>> 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.
:
Instructions and tips are in https://wiki.gnucash.org/wiki/I18N. In
General Thoughts:Conventions:Recycle already existing strings are also
instrutions to get a dictionary of already used messages.

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


Re: [GNC-dev] Simple Start to Contributing

2022-07-15 Thread John Ralls



> On Jul 15, 2022, at 10:58 AM, Paul Kroitor  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


[GNC-dev] Simple Start to Contributing

2022-07-15 Thread Paul Kroitor
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.

 

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)? 
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?
3.  Do a make a "feature branch" for this very localized change? It's
about 10 lines in a single file.
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)?
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)?  
6.  How / who do I tell that it's new and should be tested before
release?

 

Thanks for all help as always,

Paul 

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