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

[John Ralls]

On Nov 18, 2013, at 5:07 PM, Alex Kempster <alkempster.cu at gmail.com> wrote:

> At least I tried. You seem to be very negative about that. I thought that I was clear that I am new to open source development, I expected to make mistakes. I have spent hours on attempting to get familiar with a project and help the best way I can. I tried several bugs to no avail. I went through many source files which contain little documentation, some bugs date back to 2007. I am not sure what you expected but thats no reason to be so negative, especially on a project that is short on developers. I will undo the wiki changes first thing tommorow and leave it at that. I want to help, im not going to get everythimg right first time. That being said, why should I try and make an effort when I get a response that is so negative?

I’m negative about this attempt because you so clearly took on something way beyond your ability to execute and beyond Gnucash’s ability to accept. If you’ve looked through the sources you can’t escape noticing all of the static variables and the total absence of any sort of locking; if you’re experienced in multi-threaded development that would have raised a huge red flag. It didn’t. But in my reply to your introductory letter I pointed it out:
"As for MP, we need to get to multi-user access to the database backend first. This will unfortunately require a major rewrite, for which we're planning to use C++. Thread safety should certainly be a design consideration in that new implementation; the current one is stuffed with statics and utterly thread unsafe.”

You ignored me and jumped in with an incompetent attempt, going so far as to announce “a new feature” in the Wiki. Why did you think you’d get anything but a negative response?

> 
> The documentation for patches is unclear, and, unless I attempted to make a patch how could I know if its the correct way for certain? Do you have a beginners wiki page that I missed? Perhaps one should be created so that new developers have a decent chance at submitting patches correctly and knowing that config.h should be the first include. I put omp.h first so that any duplicate definitions would get overwritten by the original set of definitions.

The documentation on patches is geared to someone who already knows how to use git and what a patch is. 
Knowing about config.h requires knowing about auto tools. That’s a prerequisite for contributing to any project in the Gnome universe.
It’s well documented on the web. Gnucash can’t provide its own documentation of every tool we use. It’s incumbent upon potential contributors to get up to speed on them on their own.


> 
> I would argue that open mp inclusion at this stage wouldnt cause any problems as without the compiler flag all the changes would be ignored. But it is a moot point.

No, without the -fopenmp flag it won’t compile at all, because the compiler can’t find <omp.h> without the flag. How can someone with years of experience not know that?

> Your thoughts on the above begginer developer wiki page?

For what value of “beginner”? Beginning programmer? We don’t have time to teach. First time working in open source? Maybe, but there’s probably other material out there that’s better than what we’d be likely to write. It might be worthwhile adding pointers to some of that material on http://wiki.gnucash.org/wiki/Development .

> 
> As per a week ago I suggested making magic number replacement definitions as I thought it would be a small work... you said it was pointless. I shall ask again, is it worth me doing, that way I can get familiar with creating patches and I know it is something you would appreciate even if it would be depricated soon. Please bear in mind I know C, not guile or many of the libraries used . Perhaps it would be best for me to play to my strengths rather than try to triage bugs relating to libraries that I have never used.

I said *that particular file* wasn’t a good candidate.

OK. What are your actual strengths? Can you refactor? Write unit tests? Consolidate API? (Not until January, though, we’re not committing anything that doesn’t directly fix bugs until we release 2.6.0 at the end of next month.)

> Perhaps you could set up a wiki change pre approval system so mistakes like that dont occur in the future. I made that change as the wiki said to make documentation changes before changing code.

That wasn’t a documentation change, it was an announcement of something I explicitly told you we weren’t ready to do.

Regards,
John Ralls