[Pan-devel] Re: Ping khaley, commit 9924d08ef, missed subject_to_path updates in text_massager_test.cc after updating the header in text_massager.h

[Duncan]

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