[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pan-devel] Re: Ping khaley, commit 9924d08ef, missed subject_to_path up
From: |
Duncan |
Subject: |
[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 |
Date: |
Wed, 9 Feb 2011 02:40:29 +0000 (UTC) |
User-agent: |
Pan/0.133 (House of Butterflies; GIT 25ed40d branch-testing) |
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] Ping khaley, commit 9924d08ef, missed subject_to_path updates in text_massager_test.cc after updating the header in text_massager.h, Duncan, 2011/02/08
- [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, walt, 2011/02/08
- [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 <=
- [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, 2011/02/25