It's All about Professional work ... Some tips and tricks.. Feel free to Share !!!
While updating if you will get message like bellow, then check,
This will list:
* "A filename" for files that you added
* "M filename" for files that you modified
* "C filename" for files that have conflicts
Conflicts are files that you modified and that were modified on the head revision as well.
@ If u ll get C or conflict then go to that file and remove that lines and duplicate line then it will recover, it because, if more than two developer working on same file and comming on same time then conflict occures,
Files with conflicts will have conflict markers in them. Conflict markers look like:
<<<<<<< filename
your lines
=======
other person's lines
>>>>>>> current version
If you are using your colleague's checked out code for some changes, after that If you made any changes in code and then if you will try to check-in the code in CVS from your machine,after that if it will ask your colleague's password for checking-in. So How will we resolve this one ?
Soln:-
You deleted from CVS or local server ? if u deleted from both server then i have to see, else if u deleted from either local server or CVS server then do "cvs -q up -Pd "
else do " cvs -q up -Pd -r " .
When I view the "cvs log", the log report is fetching the file but says
"date: 2008/12/31 06:00:51; author: amareshcd; state: Exp; lines: +0 -0"
But I have added with 130 lines. Why the log is not showing "+130 -0" in its report. ?
Soln:-
Use ,"cvs log -d date1 logfile.log"
I have files that went into the Attic. How do I restore them back? Viewing the files revealed that they're in DEAD State. Someone has 'cvs remove'd the files. Just restore them with 'cvs add'. How ?
Soln:-
Step1:-
cvs log
Step2:-
Find til newest non-dead version
step 3:-
cvs update -r
step4:-
mv foo
step 5:-
cvs update -A
step 6:-
mv foo
step 7:-
cvs add
step 8:-
cvs commit -m "bring out your dead"
=====================================
Wish you all a Happy International Water Day. Drink plenty of water to fight SunRays n also at the same time conserve for others.
With ref. to your Cv in monster.com, plz. find job opening for one of our reputed client below.
Company : Tata Communication
Position : Executive-Field Operations(MAN-INFRA)
Location:Pune
Responsibilities
1. Project manage Service Assurance (SA) related OSS/BSS projects with IT organisation
2. Work with Service Assurance internal teams to identify and analyze automation requirements
3. Develop automation tools using Unix shell scripts, PHP, Perl, Apache, Mysql, and Java. Knowlege of other development tools is an added advantage.
4. Development of webbased management dashboards
Requirements
Candidate should be a Engineering graduate or diploma holder in Engg
Candidate should have atleast 3 years of experience in development of web based tools
Expertise in SQL is a must
Familiarity with IP and/or Transmission network technology will be an added advantage
Candidate should be able work in a fast paced telecom environment and should be open to learning new technologies with/without formal training
Candidate should be able a team player and should have good interpersonal skills
Excellent spoken and written skills in English is a must
TECHNICAL SKILLS:
Work with SA operations internal teams to analyze automation requirements
Develop automation tools using Unix shell scripts, PHP, Perl, Apache, Mysql, and Java
Project manage SA related IT projects with IT organisation
Development of webbased management dashboards
Candidate should have atleast 3 years of experience in development of tools
Familiarity with MySQL is needed
Familiarity with IP and/or Transmission network technology will be an added advantage
Candidate should be willing to travel to Mumbai on short term assignments
Kindly revert back if interested ,by mailing in your updated CV with ur
current & expected CTC.
Notice period.
Kavita - Mangalam Placement Pvt. Ltd."
Skills required:
Hands-on experience in C++/ Java
Strong CS fundamentals
Expertise in data Structure & Algorithms
Education: BE/Btech/ ME / Mtech - Computer Science - From premier institutes
Please share your profiles with ankita@wengerwatson.com
I am forwarding you the JDs as per our telecom. Kindly revert with some reference if any
· 1 - 6 yrs. Experience in software development in embedded/real- time platforms
· Responsible for development and integration of SW for GSM, GPRS and EDGE mobile handsets.
· Knowledge and expertise in the following areas GSM, GPRS, EDGE protocols (esp. in Layer 1).
· Software Engineering, RTOS, Embedded SW development using C and assembly (TI DSP).
· Programming language :C or C++ OS:RTOS or Linux environment
· You should hold a Bachelors or Masters Degree in Electrical/Electron ics/Computer Engineering
Send Resume to :- meenakshi.wizlead@ gmail.com
Regards,
Meenakshi
Genero victor consulting services
Exp : 2-4 yrs
Refer your friends , Send me the resume to this ID.
GDB is the GNU debugger, which is a terminal-based debugger. DDD is a graphical (GUI) front end to GDB.
The simplest way to run an application under GDB is like so:
$ gdb /usr/local/sbin/snmpd
(gdb) run -f -Lo
The '-f' is necessary to prevent snmpd from forking into the background, and '-Lo' tells snmpd to send log messages to STDOUT (i.e. print them in the GDB console window).
Net-SNMP uses libtool while building it's applications. This means that sometimes the applications in the source/build directory are not actually binaries, but shell scripts. The libtool script does some magic so that the applications will run using the shared libraries in the build directory, instead of any libraries installed on the system. To run an application with GDB, you have to run GDB through libtool, like so:
$ ./libtool gdb agent/snmpd
(gdb) run -f -Lo
Once you have got an application running under GDB, you can easily get a backtrace, which will display the sequence of functions that were called to arrive at the point where the debugger is currently stopped.
(gdb) btIf an application has crashed, often it will leave a core file. This core file can usually be loaded into GDB to get debugging information after the fact. Simply add the path to the core file after the path to the application when starting GDB.
#0 0x10153d78 in init_snmp(type=0x101bb140 "snmp") at snmp_api.c:854
#1 0x1000524c in main(argc=3, argv=0x7fe04636) at snmpd.c:910
$ gdb /usr/local/sbin/snmpd /tmp/core.70816
Often this will tell you why the application crashed (e.g. SIGSEGV, aka signal 11). You can then get a backtrace to send to one of the mailing lists for interpretation.
If testing snmpd (or another application) from within the source tree, you'll need to run gdb via libtool:
$ ./libtool gdb agent/snmpd /tmp/core.70816
This is a very short introduction into using gdb. Target audience is a unix user which has a serious problem with some application and wants to help fixing the issue by giving detailed informations to the developer or maintainer of the application.
Unix binaries can have debug informations attached. gdb can use the debug informations to provide more detailed informations (like function prototypes, source file names and line numbers, ...), thus it is generally a good idea to use a binary which has debug informations.
gcc has a command line switch (-g) which will make gcc write debug informations into object files and executables. It is common practice in the free software community to compile projects with debug info, but strip it off when installing with "make install". Thus you'll usually see a big file size difference between the executables within the source tree and the installed ones, and using the executables from the source tree with gdb gives better results.
The linux kernel is able to write a so called core dump if some application crashes. This core dump records the state of the process at the time of the crash. gdb can read such a core dump and get informations out of it.
Most distributions have core dumps disabled by default, thus you'll have to reenable them first. "ulimit -c unlimited" will do that for the current shell and all processes started from it. Check the bash manpage if you want to know more about the ulimit command.
The next time some application crashes with a segfault you'll see that the message "Segmentation fault" changed to "Segmentation fault (core dumped)" and you'll find a file named "core" or "core.pid" in the current directory. Note: You need also write access for the current directory, otherwise that isn't going to happen.
Now it is time to start gdb to see what exactly happened. The first argument for gdb should be the executable of the crashed application, the second the core dump written due to the crash. gdb will read alot of informations and will great you with a "(gdb)" prompt when it is done. The most useful piece of information for a developer is a so called stacktrace. Typing "bt" at the prompt asks gdb to print one (which you can mail to the developer). With "quit" you'll leave gdb.
You can start a application completely under gdb's control. To do that just type "gdb executable". At the gdb prompt type "run arguments" to start the application. If the application receives some signal gdb will give you a prompt asking for commands. You can also type Ctrl-C at any time to get a gdb prompt. The most useful gdb commands are:
It is also possibel to attach gdb to a already running process. This can be done with "gdb executable pid". gdb will attach to the process specified by the process id. That might be useful it some application seems to be stuck in a endless loop and you want to figure where exactly it hangs.
If you start to do more things with gdb than just printing a stacktrace you likely notice some odd effects like not being able to inspect certain variables. That may happen due to compiler optimizations. If gcc decides to make a variable a register variable (i.e. never store it somewhere in memory) gdb will not see it. To avoid that rebuild the application you are going to debug without optimizations.
More common gdb commands are:
int main()
{
char *s = "int main() { char *s = %c%s%c; printf(s,34, s, 34); ";
printf(s,34, s, 34);
}
Thanks,
-Amaresh
If you are using Linux and you need to resize a hundred images or so, you can certainly use Gimp, but that would be too much work. Consider ImageMagick set of graphic tools. You can install ImageMagick on Ubuntu by going to the Terminal and typing: “sudo apt-get install imagemagick.” Once the application is installed, all you need to do is go to your image directory and execute the following command:
mogrify -resize 900×600 *.jpg
This command will resize any image with a .jpg extension to a size of 900×600 pixels.
PS:- do backup before doing it.
Kindness is the golden key that unlocks the hearts of others." -- Henry Drummond