[Xastir-dev] extern void update_image()

[Jerry Dunmire]

You have a good point Tom. I think that is why I am jittery about
making what to me might seem like 'obvious corrections' without input
at this point. I'm still learning how things work so it would be very
easy to unintentionally break things.

I think we are all in agreement that now is not the time for a
clean-up, and until someone complains I'll ask the list before
intentionally changing code just to 'clean it up' or 'clarify it'.

Thanks,
...jerry


On Thu, Jun 10, 2010 at 2:27 PM, Tom Russo <russo at bogodyn.org> wrote:
> On Thu, Jun 10, 2010 at 12:59:52PM -0700, we recorded a bogon-computron collision of the <curt.we7u at gmail.com> flavor, containing:
>> On Thu, 10 Jun 2010, Jerry Dunmire wrote:
>>
>> > Great. I'll clean this up in a future patch.
>> >
>> > The 'static' qualifier does not seem to be used much in this program.
>> > Is that just historical, or is there something else (perhaps to make
>> > it easier to see the symbols in a debugger)?
>>
>> Just from my perspective, there's precious little time to get done
>> what needs to be done, so coding proceeds at a frantic pace.  Errors
>> and most warnings from the compiler get fixed, some quick testing
>> may reveal bugs that get fixed, then it's committed to CVS.
>> Sometimes(?) the users find more bugs and those are fixed, hopefully
>> before the developer forgets the section of code he was working on.
>> No time/energy is allocated to doing it the "correct" or "more
>> correct" way.  Make sense?
>>
>> I think a lot of open-source projects run in a similar manner.
>> Adding new features is interesting.  Scanning existing code for
>> problems is not.  Guess what gets done more by volunteer coders?
>
> I do have another perspective to add.
>
> Xastir's code, being a hodgepodge of code by many developers, some of it
> cleaner than other parts, is somewhat fragile.  Its multithreadedness can
> be a delicate thing, and in more than one instance a seemingly harmless
> "clean up" of code (done for no other reason than that the code violated
> some textbook version of coding standards) has broken something very subtly.
> So IMHO, doing a frantic scan through the code to make it more "correct"
> can really be a dive into a rat's nest.
>
> One such clean-up that seemed utterly trivial caused a segfault in another
> thread  because there was a bug that depended on some side-effect of the
> unclean code --- this was not really noticed for a while, and when it was it
> was tricky to hunt down.  Terrible that the original code had such a dependence,
> but it wasn't really broken until someone tried to make it prettier.
>
> I am currently trying to work out an extremely annoying problem that showed up
> sometime in the last year or so; after several days or weeks of
> running Just Fine, Xastir starts complaining that it can't write certain
> files --- and the files are various scramblings of "~/.xastir/tmp"  such as
> "~/.xastir/tmp/tmp/snapshot.png" or "~/.xastir/tmp/logs/tnc.log" and nonsense
> like that.  I'm thinking this points to a multithreading issue clobbering a
> variable.  This happens only when I have more than one logging option selected
> (e.g. tnc logging + png snapshots), and is random.  So far I've made no
> progress whatsoever in understanding it, not only because it's random, but also
> because it takes so long to show up that normal debugging techniques (such as
> running in GDB or using a memory checker like Valgrind) are fruitless.
>
> So in general, my attitude with this code is pretty much "if it ain't broke,
> don't fix it."  Only when a supposed clean-up serves a very definite
> development goal is it usually worth the trouble --- such as when something
> very messy interferes with new development.  But doing the necessary testing
> to assure that such things don't break working code is almost as little fun as
> doing the clean-up.
>
> This isn't to say "don't bother cleaning up code" but rather "be careful where
> you step."
>
> --
> Tom Russo    KM5VY   SAR502   DM64ux          http://www.swcp.com/~russo/
> Tijeras, NM  QRPL#1592 K2#398  SOC#236        http://kevan.org/brain.cgi?DDTNM
>  "It is better to live on your feet than to die with your knees."
>  -- Mil Millington on running, in Instructions for Living Someone Else's Life
>
> _______________________________________________
> Xastir-dev mailing list
> Xastir-dev at lists.xastir.org
> http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir-dev
>