This is most simplest approach to come up with patches for source codes on Unix/Linux based systems.
First, how to create patch file?
Patch file is a readable file that created by diff with -c (context output format). It doesn’t matter and if you wanna know more, man diff. To patch the entire folder of source codes(as usually people do)I do as bellow:
Assume Original source code at folder Tb01, and latest source code at folder Tb02. And there have multiple sub directories at Tb01 and Tb02 too.
diff -crB Tb01 Tb02 > Tb02.patch
-c context, -r recursive (multiple levels dir), -B is to ignore Blank Lines.
I put -B because blank lines is really useless for patching, sometimes I need to manually read the patch file to track the changes, without -B is really headache.
How to patch?
First of all, please do a dry-run before really patch it. Bare in mind, patch will be working very specifically. Let say the version 3 Tb03.patch is use to patch from Tb02, if you apply patch on Tb01, sometimes it will corrupt your source code. So, to make sure it works, do a dry run. Dry-run means a fake-test, do it at the directory of the source code targeted to patch.
Doing dry-run like this:
patch --dry-run -p1 -i Tb02.patch
The success output looks like this:
patching file TbApi.c
patching file TbApi.h
patching file TbCard.c
...
At last, if the dry-run is giving good result, do this and enjoy the compilation.
patch -p1 -i Tb02.patch
Monday, December 11, 2006
Wednesday, December 06, 2006
A peep into a good mail...
From: scs@eskimo.com (Steve Summit)
Newsgroups: comp.lang.c, comp.lang.c.moderated
Subject: comp.lang.c Answers to Frequently Asked Questions (FAQ list)
URL: http://www.eskimo.com/~scs/C-faq/top.html
20.13: What's the best way of making my program efficient?
A: By picking good algorithms, implementing them carefully, and
making sure that your program isn't doing any extra work. For
example, the most microoptimized character-copying loop in the
world will be beat by code which avoids having to copy
characters at all.
When worrying about efficiency, it's important to keep several
things in perspective. First of all, although efficiency is an
enormously popular topic, it is not always as important as
people tend to think it is. Most of the code in most programs
is not time-critical. When code is not time-critical, it is
usually more important that it be written clearly and portably
than that it be written maximally efficiently. (Remember that
computers are very, very fast, and that seemingly "inefficient"
code may be quite efficiently compilable, and run without
apparent delay.)
It is notoriously difficult to predict what the "hot spots" in a
program will be. When efficiency is a concern, it is important
to use profiling software to determine which parts of the
program deserve attention. Often, actual computation time is
swamped by peripheral tasks such as I/O and memory allocation,
which can be sped up by using buffering and caching techniques.
Even for code that *is* time-critical, one of the least
effective optimization techniques is to fuss with the coding
details. Many of the "efficient coding tricks" which are
frequently suggested (e.g. substituting shift operators for
multiplication by powers of two) are performed automatically by
even simpleminded compilers. Heavyhanded optimization attempts
can make code so bulky that performance is actually degraded,
and are rarely portable (i.e. they may speed things up on one
machine but slow them down on another). In any case, tweaking
the coding usually results in at best linear performance
improvements; the big payoffs are in better algorithms.
For more discussion of efficiency tradeoffs, as well as good
advice on how to improve efficiency when it is important, see
chapter 7 of Kernighan and Plauger's _The Elements of
Programming Style_, and Jon Bentley's _Writing Efficient
Programs_.
Newsgroups: comp.lang.c, comp.lang.c.moderated
Subject: comp.lang.c Answers to Frequently Asked Questions (FAQ list)
URL: http://www.eskimo.com/~scs/C-faq/top.html
20.13: What's the best way of making my program efficient?
A: By picking good algorithms, implementing them carefully, and
making sure that your program isn't doing any extra work. For
example, the most microoptimized character-copying loop in the
world will be beat by code which avoids having to copy
characters at all.
When worrying about efficiency, it's important to keep several
things in perspective. First of all, although efficiency is an
enormously popular topic, it is not always as important as
people tend to think it is. Most of the code in most programs
is not time-critical. When code is not time-critical, it is
usually more important that it be written clearly and portably
than that it be written maximally efficiently. (Remember that
computers are very, very fast, and that seemingly "inefficient"
code may be quite efficiently compilable, and run without
apparent delay.)
It is notoriously difficult to predict what the "hot spots" in a
program will be. When efficiency is a concern, it is important
to use profiling software to determine which parts of the
program deserve attention. Often, actual computation time is
swamped by peripheral tasks such as I/O and memory allocation,
which can be sped up by using buffering and caching techniques.
Even for code that *is* time-critical, one of the least
effective optimization techniques is to fuss with the coding
details. Many of the "efficient coding tricks" which are
frequently suggested (e.g. substituting shift operators for
multiplication by powers of two) are performed automatically by
even simpleminded compilers. Heavyhanded optimization attempts
can make code so bulky that performance is actually degraded,
and are rarely portable (i.e. they may speed things up on one
machine but slow them down on another). In any case, tweaking
the coding usually results in at best linear performance
improvements; the big payoffs are in better algorithms.
For more discussion of efficiency tradeoffs, as well as good
advice on how to improve efficiency when it is important, see
chapter 7 of Kernighan and Plauger's _The Elements of
Programming Style_, and Jon Bentley's _Writing Efficient
Programs_.
Brian Kernighan's Programming Style Tips
Here is a summary of the very important programming style tips from Brian Kernighan's 1994 guest CS50 lecture.
1. Say what you mean, simply and directly.
2. Use the ``telephone test'' for readability.
3. Write clearly - don't be too clever.
4. Don't use conditional expressions as a substitute for a logical expression.
5. Parenthesize to avoid ambiguity.
6. Each time you make a test, do something.
7. Follow each decision as closely as possible with its associated action.
8. Use the good features of a language; avoid the bad ones.
9. Capture regularity in control flow, irregularity in data.
10. Each module should do one thing well.
11. Make sure comments and code agree.
12. Don't just echo the code with comments - make every comment count.
13. Don't comment bad code - rewrite it.
14. Use symbolic constants for magic numbers.
15. Watch out for side effects and order of evaluation.
16. Macros are not functions.
17. Watch out for off-by-one errors.
18. Test programs at their boundaries.
19. Program defensively.
20. Make sure input cannot violate the limits of the program.
21. Make it right before you make it faster.
22. Keep it right when you make it faster.
23. Don't sacrifice clarity for small gains in ``efficiency.''
24. Don't stop with your first draft.
[From The Elements of Programming Style, Kernighan & Plauger, McGraw-Hill, 1978]
1. Say what you mean, simply and directly.
2. Use the ``telephone test'' for readability.
3. Write clearly - don't be too clever.
4. Don't use conditional expressions as a substitute for a logical expression.
5. Parenthesize to avoid ambiguity.
6. Each time you make a test, do something.
7. Follow each decision as closely as possible with its associated action.
8. Use the good features of a language; avoid the bad ones.
9. Capture regularity in control flow, irregularity in data.
10. Each module should do one thing well.
11. Make sure comments and code agree.
12. Don't just echo the code with comments - make every comment count.
13. Don't comment bad code - rewrite it.
14. Use symbolic constants for magic numbers.
15. Watch out for side effects and order of evaluation.
16. Macros are not functions.
17. Watch out for off-by-one errors.
18. Test programs at their boundaries.
19. Program defensively.
20. Make sure input cannot violate the limits of the program.
21. Make it right before you make it faster.
22. Keep it right when you make it faster.
23. Don't sacrifice clarity for small gains in ``efficiency.''
24. Don't stop with your first draft.
[From The Elements of Programming Style, Kernighan & Plauger, McGraw-Hill, 1978]
Subscribe to:
Posts (Atom)