gnupic: Re: [gnupic] Re: debugging gpasm
Subject:
Re: [gnupic] Re: debugging gpasm
From:
"David Barnett" ####@####.####
Date:
21 Mar 2007 14:00:24 +0000
Message-Id: <009501c76bc1$1752a1e0$2001a8c0@barnett2>
----- Original Message -----
From: "Byron A Jeff" ####@####.####
To: ####@####.####
Sent: Monday, March 19, 2007 6:13 AM
Subject: Re: [gnupic] Re: debugging gpasm
> My instant gut thought is first think through what the common usage would
> be
> and figure out if the current infrastructure can support it. A complete
> overhaul would be painful I think.
You are right, "overhaul" may be a bit exaggerated. I thought from looking
at the problem description that it would be a superficial change, and it
turned out to be a little more involved. There may be some pretty
fundamental changes involved, but I'll still have to figure some more of the
architecture out before I can get to it.
BTW, I've found gdb to be pretty useful for making some sense of unfamiliar
code. I'm getting sort of off-topic here, but are there any other tricks
that anyone finds particularly helpful? For instance, I've played with
cscope a little bit. I've heard using an IDE can help, too, but I've always
just programmed in vi. A friend told me that reading through source code
doesn't help much and you just have to dive in and start changing stuff to
see how it changes the program's operation.
I also found a book called "Code Reading" by Diomidis Spinellis that claims
to help with that task, but from reviews and the sample chapter, I gather
that it's just basic programming tips and not worth the read. Sean Egan
also wrote a book about his work on Gaim that got much better reviews and
supposedly talks about general techniques. Can books help that much with
learning to work on other people's code?
I ask all this because I've been trying to get involved in several projects
in the past and always found it too overwhelming. I never wanted to bother
people with the details in the past, but I figured this is as good a place
to ask as any.
David
