[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-libc-dev] [RFC] signal dox updates

From: Theodore A. Roth
Subject: Re: [avr-libc-dev] [RFC] signal dox updates
Date: Thu, 8 Aug 2002 21:56:30 -0700 (PDT)

On Thu, 8 Aug 2002, Joerg Wunsch wrote:

>As Theodore A. Roth wrote:
>> Can someone look out the part about __vector_default and comment on it's 
>> correctness? Rich's doc was out of date on that.
>I've verified that it works the way you are describing it.
>I've changed a few other things as well.  doxygen mess^H^H^Hixes
>all the declarations within one page by sorting them alphabetically,
>thus i've introduced some additional grouping so things like sei
>and cli, or SIGNAL and INTERRUPT are grouped together.
>I've also found the time to write up some documentation for <io.h>.
>Btw., i think we should prefer the new location of the include
>files over the historic places, so write <avr/signal.h> instead
>of <avr-sig.h>, and <avr/interrupt.h> instead of <intterupt.h>.
>Just MHO.
>I'm including a complete diff against CVS.

Your diff wasn't complete. :-\
Missing the doc/api/interrupts.dox file.

Joerg, can you just handle the io dox as a separate patch from the signal 
patch I'm working on? I will merge your signal changes with my diff before 
I commit. I can pull those out of the diff you already sent.

This take me way too long to figure out for myself, so I'll pass on the 
knowledge for those who don't know.

If you create new files in a cvs sandbox and then use `cvs diff` to get
your mods, you won't get the new files unless you do this:

  $ cvs add <new_files>
  $ cvs diff -N > foo.diff

This is safe in your sandbox since it won't propagate to the repository 
until you do a commit. If you find the new file is a bad idea, just do:

  $ rm <new_file> && cvs remove <new_file>

and it will be as if cvs never knew about it. ;-)

Ted Roth

reply via email to

[Prev in Thread] Current Thread [Next in Thread]