[Patch] Bug 712640: gnc-engine.c parallel optimization

[John Ralls]

On Nov 19, 2013, at 9:01 AM, Alex Kempster <alkempster.cu at gmail.com> wrote:

> Hi John,
> 
> "unless you're planning to spend your life using C as a glorified assembler"
> 
> I consider that to be highly rude, there was no need for that. I have shown you respect, please show me the same courtesy. C is by no means a glorified assembler, and you would do well to recognise that everything is built on a system bellow it. C++ is built on C which, in turn is built on assembler, therefore, you could argue C++ is just a glorified version of C. I wonder where you expect gnucash would be without C or assembler...

No rudeness intended, sorry. C is indeed a powerful language that can be used in many ways. I've been writing C code since the mid 1980s and find it very comfortable for a wide variety of purposes, though object oriented programming isn't one of them.

But when you're writing code that is directly manipulating the hardware, as is often the case in embedded systems, you're using C instead of assembler because writing C is easier and faster, but you're still doing things like twiddling bits and specifying which variables are passed in the register just like you would if you were writing assembler. That's the nature of the job; very different from the way one works on the other side of the operating system. Not only is learning that other way sometimes difficult, it can actually get in the way of doing your job well if you're paid to write next to the metal. It's a career question: What do you want to be doing in 10 years? If it's embedded programming, then you'd be better off contributing to a project that extends your experience and skills in that area, including using C as a glorified assembler, than you would be going to the considerable effort of learning OO and highly abstracted design.

> 
> As to my mailers "weird line spacing", what line spacing would you prefer?

This message seems to be OK, as did your first couple. The last one had two lfs between each line and they seemed in Mac Mail to be different sizes. What did you do differently?

> 
> "You've never met a wiki, either? Have you been hiding under a rock for the last 15 years?"
> 
> of course i have used wikis, never added to them, there has never been much point for a wiki in an embedded world, at least the area i am in. I would also point out that 15 years ago i was six, i am sure you are aware that you cannot keep up with and use everything and i have not had the chance to gain as much experience as you might have, wikis were never something i was interested in until this point as  there were many more important things to cover at the time, a problem i am addressing now.

Oh come on. Wikis are a basic part of modern society. Even my history-major daughter knows about editing a wiki. 

So 15 years ago you were 6. Then you just turned 21.  Not exactly what one would expect from someone who claims
> 
> "But you said "I also have a few years experience working on parallelization of programs using OpenMP."
> Shall we charitably call that an exaggeration, then?"
> 
> Can i take that to assume you have never exaggerated?

No, of course not. But consider that if  that was a resume and this was an interview, at this point in the conversation I would walk you out of the building without thanking you or shaking your hand, and send your resume back to HR marked "not to be reconsidered". People who do manage to get past the interview are commonly fired on the spot for exaggerating on resumes. Take that as a valuable life lesson and don't try it again. 

Had you said "I've just graduated from State U with a BSCS, where most of my class projects were in C and where I specialized in embedded systems. One recent class I took involved using OpenMP, and I found that really interesting" I would have had very different expectations about what you should know and how to guide you.

Maybe you should reintroduce yourself. 
> 
> "Look through src/app-utils, src/core-utils"
> 
> will do, any particular type of refactoring you are after? I assume two of the end aims are to make it easier / convert over to C++ and to reduce the use of static variables?

Those are directories that will be converted later or not at all, which is why I suggested them. You can clean up magic numbers, consolidate duplicate functions, extract-function to shorten and make more readable overly-long functions, rearrange blocks to flatten out indentation and nested loops, that sort of thing. Go for simple things first until you get used to making patches. In particular, you should start with something that affects only a single file, then after you've worked out how to do that and make it into a patch, move on to something that affects multiple files in the same directory before attempting something that affects anything outside the directory. That last sort of patch would have to wait until January to be applied anyway, another reason to start with something having small scope.

> 
> I will also be taking Geert 's suggestion of looking into unit testing, would we be best advised to leave each other alone to prevent future arguments?
> 

Add OO and TDD to the study list if you decide to get seriously involved in application programming. Before you start on anything here you'll need to get familiar with GLib, https://developer.gnome.org/glib/stable/index.html -- but be careful of the version, we're only at 2.28. Functions are marked with "since", so avoid anything newer than that.

No, you're not going to be able to contribute without interacting with all of the core devs, including me. None of us have enough time to be the only one to review your submissions or guide you through our spaghetti dinner of a code base.