gnupic: Re: [gnupic] Re: debugging gpasm


Previous by date: 21 Mar 2007 14:24:40 +0000 Re: [gnupic] Re: debugging gpasm, David Barnett
Next by date: 21 Mar 2007 14:24:40 +0000 Re: [gnupic] Re: debugging gpasm, Ralph Corderoy
Previous in thread: 21 Mar 2007 14:24:40 +0000 Re: [gnupic] Re: debugging gpasm, David Barnett
Next in thread: 21 Mar 2007 14:24:40 +0000 Re: [gnupic] Re: debugging gpasm, Ralph Corderoy

Subject: Re: [gnupic] Re: debugging gpasm
From: Marco Pantaleoni ####@####.####
Date: 21 Mar 2007 14:24:40 +0000
Message-Id: <200703211524.08650.panta@elasticworld.org>

On Wednesday 21 March 2007 14:59, David Barnett wrote:
> ----- 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

Two tools you'll find invaluable:

  * RedHat's Source Navigator (http://sourcenav.sourceforge.net/)
  * GNU's ID Utils (http://www.gnu.org/software/idutils/)

ID Utils is especially useful when used with emacs.

Make a wiki, documenting what you discover and understand about the code (I 
suggest "trac", as it integrates version control, wiki, ticketing, ...).
Possible, when not already there, add documentation to the code, using a tool 
like doxygen (it can be integrated with trac too).

Understanding code written by others is hard. Use your brain.

Ciao,
Marco

-- 
Marco Pantaleoni

elastiC language developer
http://www.elasticworld.org

[Content type application/pgp-signature not shown. Download]

Previous by date: 21 Mar 2007 14:24:40 +0000 Re: [gnupic] Re: debugging gpasm, David Barnett
Next by date: 21 Mar 2007 14:24:40 +0000 Re: [gnupic] Re: debugging gpasm, Ralph Corderoy
Previous in thread: 21 Mar 2007 14:24:40 +0000 Re: [gnupic] Re: debugging gpasm, David Barnett
Next in thread: 21 Mar 2007 14:24:40 +0000 Re: [gnupic] Re: debugging gpasm, Ralph Corderoy


Powered by ezmlm-browse 0.20.