walt posted on Tue, 08 Feb 2011 17:24:37 -0800 as excerpted: > On 02/08/2011 09:02 AM, Duncan wrote: > >> Specifically, this change to text-massager.h, with no accompanying >> change to the subject_to_path calls in text-massager-test.cc, only in >> text-massager.cc. > > Uh-oh, Duncan, you've let the cat out of the bag now. No more > protesting that you're not a coder. You've just proved to us that you > *do* understand the code, so we will expect more patches and bug fixes > from you in the future. > > Just one little slip is all it takes...
=:^) [Good thing this is a low traffic pan list and people here are rather more tolerant of meanderings of this nature, than some. "Go write it up on your blog if you find it so urgent, don't spam me with this junk!" is something I've seen a number of times, and this'd be a good candidate for it, many places. Just recognizing that fact...] Still can't read code, but when gcc says the number of params are wrong, there's only one commit that touches the files in question, and only one line of difference in only one of those files... that changes something that looks like it could be number of params from two to three, in something called a header file that's supposed to contain the format for calls, without changing the corresponding callers in the file that gcc is protesting that the calls have the wrong number of params... What I suspect happened is that the -test file is/was a test (duh! especially since it happens in the testing branch), perhaps a dead-end one, that substituted the whole file for the original for that test, that khaley then forgot about when updating the header and normal code file. It happened back in mid December, but I'm guessing that most khaley repo users stick with the master or integration branches and don't touch testing, so it wasn't caught until I tried to do a rebuild on the testing branch (which IIRC I picked here for my ebuild to use, back when khaley was testing some new goody on that branch) nearly two months later. I'm a reasonably good Gentoo power user, and also a regular Linus kernel git tester and bug spotter/bisector/reporter/fix-tester. As such, I've picked up "just a bit" about picking my way thru git commits using git whatchanged and git show, and occasionally spotting the bugs, especially after bisecting down to only a handful of potential commits, only one of which touches the files gcc is whining about, even without being able to directly make proper sense out of the code itself. But yeah, I do tend to be dancing ever closer... If I was 20 years younger I expect the pieces might be "magically" assembling themselves right about now. Unfortunately, the occasional "bad brain days" of 20 years ago seem to have turned into occasional "good brain days" today, and "new" stuff just doesn't come as easy as it used to, tho I'm still reasonably good (I like to think decently above average) if the territory I'm treading is familiar enough. But I've pretty much "faced reality" and realized that even if I did actually invest in "learning to code C/C++", unfortunately, chances are that it'd always feel like I was doing it by rote; I'd very likely never get to the place where it was "familiar enough" that stuff would just "magically" fall into place... I'd just "magically" understand it, as it seems I do in the more familiar areas. So now I'm shooting for better sysadmin type skills instead of ever being a coder, as that remains more realistically within my reach, familiar enough territory that I can integrate new data and methods without it feeling, beyond the first day or two, that I'm doing it simply by rote, no matter how much time I spend on it. The good thing is, following git commits and "sort of making sense of the nonsense" enough to spot the occasional problem is reasonably within the good sysadmin (good Gentoo-level sysadmin, anyway) skillset. For many bugs at least, when the commit comments are good enough at least and the gcc errors or kernel bugons are clear enough, It doesn't require having the good coder skillset. And I /do/ still seem to be making reasonable progress over time in that area. (Sometimes somewhat astonishing progress, looking back. This one was child's play now, but a year ago it'd have been very difficult, and two years ago, basically impossible. ... Assuming I've not missed the boat entirely and the problem /is/ as simple as it appears, anyway. Not actually being able to /read/ the code, one can never be /sure/, until actually confirmed by someone who actually groks code well enough to not just read it, but write it, effectively.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-devel mailing list Pan-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/pan-devel
