Sunday, April 29, 2007

Windows to Ubuntu Transition Guide



Alright, so you have successfully installed Ubuntu Linux, but now what do you do with it? You are in the right place. I am going to get you started with a guide on how to use your new Ubuntu system. This transition guide is targeted at existing Windows users and will show you how to do program installations, a little system configuration, but primarily highlight some Windows "replacement" programs for common applications you can't live without. This guide's intent is to introduce you to equivalent programs to what you are accustomed to and, hopefully, to cover a good amount of what you might want in a new install. I am basing the content on what I have personally experienced, email feedback from my installation article, questions from the PC Mech Forums, and common topics from the Ubuntu Forums. Hopefully this will answer a lot of questions you may have before you ever have them.

There is no prior Linux experience needed to follow anything I will go over, however I am going to make the assumption you have at least played around in Ubuntu for a bit. I am not going to be covering the basics on how to use the interface, as it is quite similar to Windows. Here is a quick breakdown of the topics I will be covering:

  • Configuring and using Synaptic Package Manager to install applications
  • Installing common packages with Automatix
  • Essential desktop, office, and Internet applications
  • Playing movies and music
  • Games
  • Digital cameras, printing, and burning
  • Installing a PHP and MySQL enabled Apache web server
  • Development tools
  • Installing and configuring a firewall
  • Setting up remote desktop connection
  • Setting up a streaming music server

Since this article's intent is to be a beginner's guide to Ubuntu Linux, I am going to be using the graphical interface for pretty much everything. As experienced Linux users may know, and you will soon find out, everything we are going to be doing can be done much quicker through the command line. Of course, this is not very user friendly, and a very un-Windows way to do things, so again, we will be sticking to the Ubuntu GUI (Graphical User Interface).

As you are reading, please bear in mind that Linux is not Windows. At a high level they appear to operate basically the same, but they are fundamentally different. Just keep an open mind and I promise learning Ubuntu Linux will be well worth your time.

Windows and Ubuntu on One PC-By setting up your PC to dual-boot, you can easily take Linux for a test-drive.

"Linux rocks!" "No, it's lame--stick with Windows!" Visit any Web site or online forum where impassioned computer users debate the relative merits of operating systems, and you'll find endless disagreement. The only way to determine which operating system fits your needs is to run both on the same PC, configured for dual-booting. You also need to be able to access your data files from either OS, which is the trickiest part of the process.

Creating a dual-boot setup on a Windows machine is as easy as selecting that option when you install Ubuntu. As you switch between the two operating systems in your day-to-day work, you'll be able to assess for yourself the killer features, incompatibilities, and showstopping flaws that make one a better choice than the other.

On a dual-boot system, Linux and Windows reside on separate disk partitions, each of which is formatted differently. Even though the file systems are incompatible, most recent versions of Linux can at least read files on Windows XP's NTFS partitions, though this may not be enabled by default. Few Linux distributions can write files to an NTFS partition right out of the box, and the reliability of this function hasn't yet been proven, so trust it at your data's peril. In addition, the software required to write files from Linux to NTFS drives is difficult to download and install.

Windows, conversely, lacks the native ability to read and write files on any of the several Linux file systems. The nifty and free Ext2 Installable File System for Windows permits Windows XP to read and write in the Ext2 and Ext3 file systems many Linux distributions use (it doesn't work with the ReiserFS file system, however). While this is handy, especially if you spend most of your time using Linux and you keep your files there, I recommend another option: creating a separate partition for your data that uses the older FAT32 file system, which both Linux and Windows XP can read from and write to. In fact, FAT32 has been included with every version of Windows since 95's Service Release 2.

FAT32 lacks the user-access security features of Linux's Ext2/3 and Windows' NTFS, but creating a separate FAT32 partition for your data allows you to install or upgrade your operating systems without having to back up or restore your data files. It also lets you read and write that data with minimal add-on downloading and configuration. If you need some assistance in resizing your existing partitions to create a new FAT32 partition, look no further than the free Partition Logic utility.

Saturday, April 28, 2007

Basic vi Commands

Edit Commands
Text Object Change Delete Copy
1 word cw dw yw

2 words, not counting punctuation

2cW or c2W 2dW or d2W 2yW or y2W
3 words back 3cb or c3b 3db or d3b 3yb or y3b
1 line cc dd yy or Y
To end of line c$ or C d$ or D y$
To beginning of line c0 d0 y0
Single character r x or X yl or yh
Five characters 5s 5x 5yl

Movement Commands
<-,-v,-^, " src="../chars/rarr.gif">

h, j, k, l

To first character of next line +
To first character of previous line -
To end of word e or E
Forward by word w or W
Backward by word b or B
To end of line $
To beginning of line 0

Other Operations
Operations Commands
Place text from buffer P or p
Start vi, open file if specified vi file
Save edits, quit file ZZ
No saving of edits, quit file :q!

Text Creation and Manipulation Commands
Editing Action Command
Insert text at current position i
Insert text at beginning of line I
Append text at current position a
Append text at beginning of line A
Open new line below cursor for new text o
Open new line above cursor for new text O
Delete line and substitute text S
Overstrike existing characters with new text R
Join current and next line J
Toggle case ~
Repeat last action .
Undo last change u
Restore line to original state U

Hot Vim Plugins

See for details.

In Chinese!

Vim 实用技术


Vim 实用技术,第 1 部分: 实用技巧

本系列文章分三部分详细阐述了 Vim 的使用技巧、插件、定制。第一部分主要是深入分析了 Vim 的使用。

Vim 实用技术,第 2 部分: 常用插件
第一部分介绍了一些基本的 Vim 使用技巧。掌握这些技巧可以很大地提高编辑效率,但是 Vim 的强大功能并不仅限于此。Vim 还可以通过“插件”来进行功能扩展。精确地说,是通过脚本来进行扩展,脚本类型有插件、语法加亮、配色方案、文件类型检测等多种。大部分的脚本都是由 Vim 的用户写的,解决了用户身边的问题,使 Vim 变得更加有用。本章将介绍最常用的一些脚本,其中除了一个属于“语法加亮”脚本外,其它都属于“插件”类型。关于如何写脚本的一些基础知识将在下一部分进行一些介绍。

Vim 实用技术,第 3 部分: 定制 Vim
前面两部分讲的都是如何使用现有的 Vim 系统,本部分则会通过实例来讲如何定制 Vim 的行为。良好的定制可以让使用 Vim 变得更为得心应手;同时,在掌握了基本的定制之后,也许你就会想进一步写一些自己的 Vim 脚本,从而真正地成为一个 Vim 专家。

[Please Click the links to see the details...]

C++ vs Java vs Python vs Ruby : a first impression


Executive Summary

I am a language agnostic journeyman programmer. I am not a fan of a particular language (I almost said 'fanboy') but thats a bit inflammatory). I just want to write useful programs and have fun doing it. I know C++ and Java pretty well. I did some beginner work in Python and Ruby. I then came up with the following conclusions. But before you flame, read the whole article.

  • C++ vs Java
    Java garbage collection is the big productivity gain
    Java is significantly slower than C++
    C++ is (much) harder to code correctly than any of the others
  • Java vs Python/Ruby
    Python/Ruby interpreted execution and dynamic typing are big productivity gains over Java.
    Python/Ruby are slower than Java
    Python/Ruby programs need less extraneous scaffolding (cleaner code)
    There are two important tradeoffs : [interpreted vs. compiled] and [static vs. dynamic typing]
  • Python vs. Ruby
    nearly equivalent


When running various distributions of Linux, I always ran into the choice of KDE or GNOME. There are plenty of advocates on both sides, but there was no overriding authority. Then recently Linus Torvalds came out with a definitive opinion. He took the unequivocal position that KDE is best. Not that he is necessarily the final arbiter of user interfaces, but at least he provides a strong datapoint, and since he is smarter than me and since all the other opinions seem to come from biased sources, I can now pick KDE and feel better about it. Paraphrasing the old IBM criteria, 'no one was ever fired for following a Linus directive'. Heh, after all that it turned out that I wanted to use Ubuntu which works best with GNOME so I ended up with that for now. So 'most practical' won out over 'best'.

In the meantime I realized I needed to learn a new language and the current buzz is Python and Ruby. Again I couldn't find a definitive answer of which one is best. From all the buzz, I came up with a vague impression that Ruby is more pure and is set to win in the long run, but that Python is currently more practical for now. And Google uses Python, which is a significant datapoint. They aren't idiots over there.

To see what I could figure out myself, I decided to code up something in Java, then port it to Python and Ruby and see how I felt about each, and try to identify where the big wins are for each language.

One caveat. If something significant is missing from a language, like garbage collection, then I don't want to hear a response that says "well, if you use XYZ unsupported library, or you do ABC convoluted technique, then you can do the same thing in [put language name here]". I am trying to evaluate the STANDARD here, since of course you can probably do anything in any language including assembler if you work hard enough. And the problem with using a nonstandard library is not just the extra integration work, it's that you are basing your code on something that may fall by the wayside later on and then you are stuck. Sometimes it's worth it but that has to be proven on a case-by-case basis as far as I am concerned.


I started in C in 1985, learned C++ in 1990 (Zortech C++) and have been using it ever since. I learned Java in the mid-90's when it was first coming out, and found three big win's for Java over C++: Garbage collection, portability and simplicity. Garbage collection and simplicity created big productivity gains, and portability is portability. Not having done a garbage collected language before, the productivity gain was readily apparent. The simplicity of Java over C++ was really nice. When coding C++, I needed Meyer's Effective C++ on my desk at all times to be sure I wasn't invoking some weird type coercion or copy constructor/assignment operator anomaly. And don't even start with templates. With Java I never needed that because it is just simpler. And the Java libraries were more comprehensive and string handling was easier. So in general I was more productive coding away in Java. I still liked C++ but it seems that when programming C++, the fun is in figuring out the language and library , like solving a puzzle. That leaves less time to spend on solving the application domain problem.

the code

The attached code samples are implementations of a Red-Black tree algorithm adapted from descriptions in "Algorithms in C++", Sedgewick and "Introduction To Algorithms",Cormen/Leiserson/Rivest. I picked this because it was short but had some complexity.

code notes and disclaimers:

  • commenting is sparser than usual to avoid obscuring code
  • I probably made some convention errors in Python and Ruby due to ignorance of the proper idioms
  • all these programs compile and/or run without warnings and output the same result
  • I believe the programs to be correct. there may be bugs but if so they are in all 3 versions
  • Java 5.0 SDK,Python 2.4, Ruby 1.8.3, C++ Microsoft Visual C++ 2005


It was surprisingly easy to port the Java code to Python and then port the Python to Ruby. A lot of it was regular expression search and replace, getting some naming conventions right and adapting to a few language differences. During the porting process, the two big gotchas I ran into were Python block indenting errors and Ruby's horrible compiler diagnostics.

Porting the Java code to C++ was much more a hassle. I attempted to make use of as much static type checking mechanisms as I could. In Java I used generics for the tree, and in C++ I used templates for the container and 'const' where appropriate. The big gotchas on porting to C++ were:

  • The dichotomy between primitive types and objects in C++ is much more pronounced even than Java (and Java is worse off than Python or Ruby). This dichotomy makes it hard to write a class that supports both primitives and objects. My implementation might need some fixups to work with objects rather than 'int'.
  • Java,Ruby and Python all use a consistent reference only scheme to refer to objects which are always on the heap or equivalent. In C++, you can have a statically declared objects, a pointer to an object, or a reference to an object, each with features and limitations. A C++ 'reference' is not the same thing as a reference in the other languages. C++ really wants you to use pointers. These alternatives means that when you write something in C++ you have to come up with a consistent strategy for using the 3 types of object access, and your strategy might not be the same as what others prefer. There is 'more than one way to do it'.
  • The lack of built-in mechanisms or even just conventions for operations that should be common across types means you have to make things up. Like converting a type to string representation. All the other languages have support of one kind or another but in C++ you have to make up your own convention
  • Maybe its just me, but C++ always leaves you wondering what you might have done wrong. Its hard to tell. If you read Meyer's Effective C++ you see that there are numerous detailed infrastructure things like constructors and assignment operators that you have to get exactly right or things fail at runtime. C++ is really hard to get right, and I never feel totally secure that I did it properly
In my opinion (and I have written a lot of C++), use C++ only where you have to for compatibility or performance reasons, or where you arbitrarily decide that you would rather use C++ because its more fun because its harder. As Tom Cargill (a noted C++ guy) said, "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?".

python block indenting

It took me a while to get my editor (JEdit) happy with Python and getting to not use tabs. Fortunately I never screwed up the file so bad that the code didn't work but I always had an unpleasant uncertainty about the indentation simmering in the background. Some (or all) of this may be prejudice. I really liked braces better than either Ruby Do-End or Python indenting, at least when I was coding. On the other hand, a properly indented Python file looks much much cleaner and is easier to read than any of the others because you don't need all the block closing symbols. However the explicit 'self' argument makes it look less clean than it could.

ruby syntax errors

Many of the compiler diagnostics I got during the Ruby porting simply said "syntax error" and gave the line number for the last line in the file. Great. I spent a lot of time doing binary searches on my code to find the error source.

The visitor pattern

One thing I did differently in each language was try to adapt a 'Visitor' pattern (for traversing the tree) to the preferred idiom for each language. You could of course simply code up a Visitor class that is nearly identical for each language, but instead I did the following.

  • Java : one scheme : an anonymous class implementing a predefined interface.
  • Python : two schemes : a named class similar to Java and just a named function passed in as a parameter.
  • Ruby : two schemes : a lamba anonymous function, and a Ruby block implementation

The Java and C++ approaches give you static type checking but takes a lot more cruft to get going. I found the Python named function parameter very convenient. But it doesn't carry any state so if you need state then you use a class. Surprisingly, I found the Ruby lambda easier to understand and implement than the Ruby 'block'. That is because my traversal algorithm is recursive, and the lambda just gets passed around as a parameter (like the python named function parameter). I didn't exploit the full potential of a lambda closure.

The Ruby block scheme (pun not intended) requires some tricky syntax in the recursive calls, and I could not find a good explanation of how to handle recursive use of blocks in the Ruby documentation. I found a single web hit with an example and after fiddling with it I got it to work. I think I understand them now but it is still a bit fuzzy. I mean, I know what to do now but it takes some concentration to figure out what exactly is happening and why the code looks like it does. I found that viewing a Ruby block as a co-routine (per the documentation) and not as a subroutine to be the best way to understand the whole thing.

All that said about the Visitors, I am a Python/Ruby novice so possibly I did things the hard way :)

interpreted vs. compiled

There has always been this tradeoff. In fact, the Python/Ruby vs. Java performance controversy sounds a lot like the C/Assembler/Forth discussions in the embedded systems world of the early 1980's. Forth was interpreted, it didn't need a compile cycle and it had (supposedly) productivity enhancing features that C didn't have. Development cycles were much shorter with Forth. Performance was not as fast as C or assembler but was close. The drawback of Forth was the weirdness of the language. C won out and Forth went to the dark corner of mostly forgotten languages.

Interpreted languages give you a much quicker development cycle, especially on big programs. There is no doubting that. Its simply a tradeoff of execution speed vs. productivity. Some applications need the speed. I think it is a premature optimization to say the "I like C/Java better than Python/Ruby because they execute faster". Interpreted is better if you can get it. When I was testing the code I experienced the advantage of interpreted. I didn't really measure performance but other sources show the differences. But since Python/Ruby seem to interface to C/C++ pretty readily, I would be very comfortable working in the interpreted world and descending into the netherworld of compiled C/C++ when required. Yes, Python is actually compiled for a VM but you don't have an explicit compile operation so it acts to the user like an interpreted language.

static vs. dynamic type checking

Ok, I like the productivity increase provided by dynamic typing because it eliminates a lot of scaffolding. I found it quite interesting to see errors pop out at runtime that would normally be compile time in C++/Java. These runtime errors were obviously influenced by the paths taken in the test program (or how far it got before it barfed). For a given run, I clearly wasn't seeing all the instances of this class of errors as I would have with static type checking.

Coming from a statically typed language background, my gut says that dynamic typing creates a risk. The Python/Ruby bloggers say that if you just unit test properly, then there is no problem. Brucke Eckel has a well reasoned essay on the issue. I would argue that expecting unit test to catch typing errors has two issues:

  • in a really big system, its hard to test exhaustively
  • testing for type correctness makes the programmer do the work that a computer could do

We static typers may be wrong. I had a similar experience moving from PVCS to Subversion version control. Oh, My, God, no locking? The code will be completely ruined in a week. But it turned out to be a non-issue and Subversion added so much less friction to the development cycle that productivity was improved maybe 10%. The collective good experience overrode the predjudice based theoretical 'proof'. The same argument can be made for dynamic vs. static typing.

I wouldn't mind a separate 'lint' tool for Python/Ruby (is it possible?). I use lint for C/C++ religiously. The whole compiled language community is moving towards more static type checking (Java Generics, for example) rather than less. Are they all idiots? (don't answer that)

My conclusion is that dynamic 'duck' typing is more productive, more pleasant, gives cleaner looking code but it incurs a risk that you will get a runtime type exception in your application at some later date. The risk is there, quit denying it.

the results

These results are meant to cover issues I noticed in the porting/testing I did. Not an overall evaluation. If I mention stuff that I didn't run into first hand, then throw that out.

C++ vs Java

  1. Garbage collection is THE big win for Java.
  2. Java simplicity over C++ complexity is a big win for Java.
  3. C++ is much harder to write and get right than Java or any of the other choices
  4. C/C++ is way faster than Java
  5. Language scaffolding requirements are similar for both
  6. C/C++ is the only way to go for low level systems programming.

Java vs Python/Ruby

  1. interpreted vs. compiled is a big productivity win for Python/Ruby
  2. dynamic typing is a big productivity win for Python/Ruby
  3. Java is way faster than Python or Ruby
  4. minimal scaffolding is a big productivity win for Python/Ruby. Makes programming more pleasant not to have to build all the infrastructure.
  5. mostly first class functions a big win for Python/Ruby.
  6. built-in lists/arrays and hashes/dictionaries a big win over Java [] and library based collections. Java 5.0 fixes some of this but in Java collections still seem tacked on rather than integrated.
  7. dynamic code loading in Python/Ruby is a big win. Yes you can do it in Java but again, the cruft.
  8. Ruby OO completeness over Java dichotomy between primitive types vs. objects is a big win for Ruby, less so for Python.
  9. There is some weirdness in Python and Ruby lexical scoping of names. The documentation for each has several warnings about edge cases where names don't bind in the expected way. This gives me a queasy feeling although in practice it may not matter. Another win for static type checking.
  10. Java 'Comparable' interface ugly compared to Python/Ruby built in comparison mechanisms that require only that a single function be implemented to get the full set of comparison operators. An example of excess Java scaffolding.
  11. lack of multiline comments in Python/Ruby was annoying
  1. static typing is a correctness win for Java, especially with Generics in 5.0. The C++/Java trend is toward stronger static type checking, not less
  2. dynamic typing is a productivity win for Python/Ruby at the cost of some risk
  3. interpreted vs. compiled trades off execution speed for shorter development cycles.

Python vs Ruby

none of these are that important

  1. Ruby's compiler/runtime error messages were mostly 'syntax error' with no help. in many cases almost useless
  2. Why does Ruby use rescue/ensure when the rest of the world has settled on try/catch/finally? I mean, its an arbitrary choice so why not follow the general convention?
  3. Once the indentation is correct, a Python program is the cleanest looking
  1. somewhat uneasy over Python indenting vs. Ruby explicit 'end'. probably a predjudice.
  2. Python requirement for explicit 'self' parameter to methods and instance variable access is very annoying
  3. Ruby OO completeness is a win over Python.
  1. Ruby blocks/lambda/yield seemed more or less equivalent (to me) to Python's named class or function. Didn't seem a big win to be able to write an anonymous function inline. In fact, one could argue that anonymous classes/functions/lambdas reduce testability because they can't be tested independently of the containing code. But on the other hand I wasn't using lambdas in the most complete sense, in which they can act on the containing environment in a way that a named function can't.

A final thought on C++. To me the C++ Standard Template Library is distinguished from the other language libraries in that it seems to be much more mathematically thought out. The containers and algorithms in the STL all have explicit runtime complexity guarantees. There seems to be much more computer science in the STL than in the other language libraries. Java is sort of like that, whereas Ruby and Python libraries seem much more ad-hoc. That probably has a lot to do with their open community driven approach to libraries. I really like how the STL was thought out and designed.


Java is more productive than C/C++. Use C/C++ only when speed or bare metal access is called for. Python/Ruby is more productive than Java and more pleasant to code in. There is a big question on static vs. dynamic typing. I contend that static typing has to be better for the purposes of program correctness, but the required cruft reduces productivity. If actual practice in large systems shows that in fact runtime typing errors don't occur often and are worth the productivity tradeoff, then I will bow to dynamic typing. I can't come up with a definitive answer to Python vs. Ruby. They seem very equivalent. Would choose based on practicality in a given situation. My general feeling was that Python annoyed me in ways that Ruby didn't, but I think those annoyances would disappear if I was using Python all the time.

Crap, the whole point was to pick Python or Ruby, but I am back where I started.


30+ Basic Linux Commands

Here are some basic Linux commands. Some are well known and some aren't. I am not a Linux
Wizard...far from it...but I am learning some basic linux commands and thought I would
share some with other newbies so they to can get more familiar with the terminal command
line. These work on my Mandrake 8.1 system.

xkill Kills a running program
exit Exits the terminal
reboot Reboots the system
halt Shutsdown the computer
startx Starts xwindows from terminal
man man(command)shows help files
info info(command) shows help files
--help (command)--help shows help files
su Allow you to login as Super User

ls "Lists" the contents of the directory
pwd Displays "present working directory"
cd cd (name) change directory TO:(name)
mkdir mkdir (name) Makes new directory
rmdir rmdir (name) Removes directory
clear Clears the terminal window

date Displays current date and time
cal Displays a calander
uptime Displays time since last reboot
df Displays the disk usage on partitions
du Displays disk usage of directory

id Displays your identification to system
groups Displays groups of current user
ulimit -a Displays users limits
uname Displays name of machine logged into
who Displays "who" is logged on the system
w Similar to "who"

wall Sends message to all logged in users
top Displays cpu processes memory etc
ps Displays current running processes

Tools advice for C and C++ programmers ramping up on XML


Designed for C and C++ programmers who are new to XML development, this article gives an overview of tools to assemble in preparation for XML development. Tool tables outline generic XML tools like IDEs and schema designers, parsers, XSLT tools, SOAP and XML-RPC libraries, and other libraries either usable from or actually written in C and/or C++. The article includes advice for installing open-source libraries on Windows, Unix, and Linux, plus a brief glossary of key XML terms.

see more. please click the link above.


There are certain basic aspects that should be kept in mind; such as the format of the code, indentation, comments, smart variables etc..
As for the basic layout, here is a tip:

1> Documentation:
This should contain the objective of the program, the creator's name and date if neccessary and other details about the program. It should be in the form of a multi-line comment.
Example: /* Program to add two numbers.
created on: 22 sept-2005, by:urjit */

2>Linking of files and Inclusion:
This section should be used to link to all header files, external files and the library functions. Macros could also be placed in this section.
Example: #include
define PI 3.14

3>Main program:
This section should ideally contain the classes (in case of C++), global variables, filestreams, and the body of the main( ) function, containing all the sub-functions, local variables, objects etc..

4>Functions and extra comments:
This section should contain the extra information and notes about debugging if required (untill the code is perfected), other functions that are to be used in the main program (for defining the functions here, they have to be declared above their control entry; i.e., generally above main).

C++ Book Recommendations

Accelerated C++ by Koenig and Moo: Beginners book that teaches C++ style C++, one of if not the most commonly recommended beginner C++ books. Slightly more advanced and/or accelerated than other beginners books.

C++ Primer, Fourth Edition (or later) by Lippman, Lajoie and Moo: Comprehensive guide to C++ language.

Thinking in C++ by Eckel: Freely available online book for beginner/intermediate programmers.

The C++ Programming Language, Third Edition (or Special Edition) by Stroustrup: The definitive language reference by the language creator. Not particularly suitable for beginners.

C++ Coding Standards by Sutter and Alexandrescu: Compilation and guide to C++ best practices. Must have for intermediate C++ programmers.

Anything from Stroustrup's C++ In-Depth series or referenced by C++ Coding Standards, including:

Design Patterns by Gamma, Helm, Johnson and Vlissides
Effective C++, More Effective C++ and Effective STL by Meyers
Exceptional C++ and More Exceptional C++ by Sutter

Tips: Making Vim easy

Vim's flexibility and countless features are a major asset for experienced users, but a challenge for newbies. If you've always wanted to try Vim but were put off by your first attempts, you can start off gradually by getting to know Vim's GUI and easy mode. This article is a primer for those who haven't used Vim much and want to wade in gradually.

If you're new to Vim and vi-like editors, the Vim GUI is probably the best way to get started. You can perform the operations you're familiar with using Vim's keybindings, but when you get stuck, you can use the mouse and the gVim menus to get things done quickly and efficiently.

Even better, when there is a keybinding for a command, it's usually displayed in the gVim menu -- so if you keep performing the same operation, you'll probably pick up the keybinding through repetition and eventually be able to go mouseless -- if that's your goal, of course.

There's little, if anything, you can do using gVim that you can't do in the standard version of Vim, and many operations are easier or more intuitive when you have menus and icons to deal with.

Staring gVim

To start gVim, run gvim or vim -g. If you want to edit a file with gVim right away, you can launch gVim with gvim filename or vim -g filename .

As with Vim, you can also launch gVim with the +n option, where n is the line number you want to start on. So, for instance, gvim +10 filename will bring up gVim with filename loaded and the cursor on line 10.

Another trick is to load gVim at the first instance of a search term. Let's say you want to start editing at the first instance of the word foobar. Use:

gvim +/foobar filename

Once you start gVim, you'll notice that it looks more or less like any other GUI text editor. Like any other editor, it provides several menus, a scrollbar on the right-hand side of the window (which can be moved, or done away with, if desired), and a toolbar at the top of the window for quick access to common functions like Save, Undo, and Search.

Easy Vim

Vim also has an "easy" mode, which isn't touched on too often in Vim tutorials and docs, since it really goes against what most users are looking for from Vim. Vim, as you know if you've used it much, is a "modal" editor, based on Bill Joy's classic vi. Vim has an insert mode, a command mode, a visual mode, and (depending on whom you ask) a few additional modes. Once you get the hang of it, the modal nature of Vim is extremely useful. However, until you get used to it, Vim can be a hassle when trying to figure out simple operations like searching and replacing text.

Easy mode is actually a collection of various Vim options that tell Vim to act like any standard text editor. Instead of using y to "yank" (copy) text, and then pasting text using p or P in normal mode, Vim's easy mode lets you use the standard Ctrl-c to copy text and Ctrl-v to paste text. Anybody who has use Notepad or Microsoft Word for a week or two will be familiar with these shortcuts, and emulating them makes Vim more intuitive for the average user. Check Vim's help for more on easy mode to find out exactly what Vim's doing behind the scenes.

Why would you want to use Vim without access to its modes? Well, Vim still includes a number of spiffy tools and features that aren't dependant on its vi-like modes -- macros, syntax highlighting, sessions, and other Vim goodness that you might not find in an editor like Kate or gedit.

Easy mode also enables a context menu, which isn't present in standard Vim/gVim. When you right-click in the gVim window, you'll see a menu that will allow you to select text by the word, sentence, paragraph, line, or all text in the buffer. You can also use the context menu to copy, cut, delete, and paste text, and to undo operations.

If you like the context menu, but don't want to run Vim in easy mode, you can simply set the mouse behavior using this command:

:behave mswin

Then you'll have the context menu, even when you're not in easy mode.

By default, pressing Esc in easy mode will not put you in command mode. If you decide you want to start using gVim in regular mode, you can go to Edit -> Global Settings -> Toggle Insert Mode, which will put you into command mode. After running this, you'll be able to switch between easy mode and normal gVim/Vim modes. If you want to drop back exclusively to easy mode, toggle it with the menu or run :set im! in command mode.

The rest of this article will assume that you're using gVim in normal mode, but I wanted to point out the easy gVim mode for users who might like to get started with Vim is the friendliest manner possible.

By default, gVim will start with a conservative color scheme of black text on a white background. If you prefer something a bit more interesting, gVim has several color schemes available. Go to the Edit menu and select Color Scheme. You should see about a dozen choices, including blue, darkblue, and peachpuff.

Working in gVim

This probably goes without saying, but since gVim is designed as a GUI text editor, you can select text using the mouse in addition to Vim's usual text selection methods. This means that all you need to do to highlight a letter, word, or sentence is to grab the mouse and highlight the text that you'd like to select. You can also place the cursor anywhere on the screen just by moving the mouse. (You can also enable this in regular Vim running in an xterm or other terminal emulator, but it requires mouse support being built in and is not on by default.)

However, don't forget that the mouse is a clumsy tool compared to Vim's normal selection capabilities. Using v you can start the visual mode for selecting by character, V to select by lines, and Ctrl-v to select text blocks.

It's also worth noting that you have two clipboards in gVim. There's the current selection, which means any text that's highlighted, and there's text copied to the clipboard, which persists after you've selected new text. For example, if you use the mouse to select a sentence and then click the middle button, you'll paste the text that you just selected. But if you select text and use Vim's Edit menu to copy text, it will be stored in the clipboard even when you select new text. This can be useful if you have a string that you'll be pasting several times (say, a letter template) and need to use the standard selection method for other text.

I've written about Vim's viewports before, but viewports are much easier to manage in gVim. You can use the normal Vim keybindings to open a viewport, or you can just go to Window -> New to create a new viewport so you can edit a new file, Window -> Split to split the window using the same file that's already open, or Window -> Split Vertically to divide the viewport vertically instead of horizontally. Using Ctrl-w will move you from viewport to viewport, or you can use the Window menu to move to another viewport, or just click the left mouse button in the viewport you want the cursor to be in.

The really nice thing about viewports in gVim, though, is that you can easily resize them with the mouse. In standard Vim, you need to use Ctrl-w - and Ctrl-w + to resize the windows, but in gVim you can resize them using the mouse or the standard Vim keybindings, depending on which you find easier to use.

Even though gVim is a GUI-based program, the shell is never far away. To get to a shell from a gVim session, just :sh; type exit when you want to get out of the shell. Note that gVim's terminal emulation may leave something to be desired in terms of screen refresh, so you probably want to stick to a regular terminal emulator for most of your work.

gVim's file explorer

You can use gVim to edit remote files almost as easily as using Vim in a remote shell. I usually edit files on my server by using SSH to get a shell on the remote machine and then editing a file, but you can do the equivalent using gVim (or regular Vim) from your local session.

To open a remote file using secure copy (scp), do the following:

:e scp://

This will open a secure connection on the remote machine as the user specified. If you have an SSH key set up, you can log in without a password. If you don't have a key set up, you will be prompted for a password each time you save the file, which can be a bit of an annoyance.

Note that this will work with several protocols, so you could substitute sftp, ftp, rsync, and other methods. See the Vim help guide for the complete list.

What if you don't know the name of a remote file, or the exact path? Leave off the filename and you'll be dropped into Vim's file browser:

:e scp://

You can browse through the directories and find whatever file you need to edit. Press Enter once the file you want is highlighted and start editing.

Finally, I would be remiss if I didn't mention gVim's spelling features. If you turn on behave mswin and turn on spellchecking, you can use the context menu to add a word to the dictionary, accept an alternate spelling, or ignore a word for spellchecking purposes. To turn on the spellcheck feature, go to Tools -> Spelling -> Spell Check On. You'll probably need to turn syntax highlighting off for the spellcheck to work properly; you can do that from the Syntax menu.

If you've never used Vim, or if you've used Vim and found it too difficult, try gVim for a few days. It has all of the amenities that you'd want from a boring old text editor, but with all of Vim's features lurking below the surface where you can unleash them at your leisure.

Friday, April 27, 2007

Publications by C++ experts

Articles by experts are saught after the most. Therefore, here are the links to the articles written by some of my favorite authors.

c.vim for VIM : C/C++ -IDE

created by
Fritz Mehner

** Statement oriented editing of C / C++ programs
** Speed up writing new code considerably.
** Write code und comments with a professional appearance from the beginning.
** Use code snippets

- insertion of various types of comments (file prologue, function descriptions, file section headers
keyword comments, date, time, ... )
- insertion of empty control statements (if-else, while, do-while, switch, ... )
- insertion of various preprocessor directives
- insertion of C-idioms (enum+typedef, loops, complete main, empty function, file open dialogs, ... )
- insertion of C++ -idioms ( frames for simple classes and template classes, try-catch blocks, file open dialogs, output manipulators, ios flags, ... )
- use and organize your own collection of code snippets
- compile / link / run support for one-file projects (without a makefile)
- run buffer through splint
- personalization of comments (name, email, ... )
- menus can be switched on and off (Tools menu)

Here are some screen shots :

The help file online :

This plugin comes with a help file (csupport.txt). Read it with

:h csupport

install details
Copy the zip archive to $HOME/.vim/ and run
If you have already an older version of this plugin and you have modified the template files you may want to save your templates first or copy the files from the
archive by hand. See also the file README.csupport within the zip file.

The difference between pointers and arrays

1) A pointer is a place in memory that keeps address of another place inside, while an array is a single, preallocated chunk of contiguous elements (all of the same type), fixed in size and location.

2) Array like pointers can't be initialized at definition like arrays.

3) When we allocate memory for a pointer to use it as a dynamic array. The memory can be resized or freed later. But this is not the case for arrays.

History of C++

During the 60s, while computers were still in an early stage of development, many new programming languages appeared. Among them, ALGOL 60, was developed as an alternative to FORTRAN but taking from it some concepts of structured programming which would later inspire most procedural languages, such as CPL and its succesors (like C++). ALGOL 68 also influenced directly in the development of data types in C. Nevertheless ALGOL was an unspecific language and its abstraction made it little practical to solve most commercial tasks.

In 1963 the CPL (Combined Programming language) appeared with the idea of being more specific for concrete programming tasks of that time than ALGOL or FORTRAN. Nevertheless this same specificity made it a big language and, therefore, difficult to learn and implement.

In 1967, Martin Richards developed the BCPL (Basic Combined Programming Language), that signified a simplification of CPL but kept the most important features the language offered. Although it continued being an abstract and somewhat large language.

In 1970, Ken Thompson, immersed in the development of UNIX at Bell Labs, created the B language. It was a port of BCPL for a specific machine and system (DEC PDP-7 and UNIX), and was adapted to his particular taste and necessities. The final result was an even greater simplification of CPL, although dependent on the system. It had great limitations like it did not compile to executable code but threaded-code, which generates slower code in execution, and therefore was inadequate for the development of an operating system. Reason why from 1971, Denis Ritchie, from the Bell Labs team, began the development of a B compiler which, among other things, was able to generate executable code directly. This "New B", finally called C, introduced in addition, some other new concepts to the language like data types (char).

In 1973, Denis Ritchie, had developed the bases of C. The inclusion of types, its handling, as well as the improvement of arrays and pointers, along with later demonstrated capacity of portability without becoming a high-level language, contributed to the expansion of the C language. It was established with the book "The C Programming Language" by Brian Kernighan and Denis Ritchie, known as the White Book, and that served as de facto standard until the publication of formal ANSI standard (ANSI X3J11 committee) in 1989.

In 1980, Bjarne Stroustrup, from Bell labs, began the development of the C++ language, that would receive formally this name at the end of 1983, when its first manual was going to be published. In October 1985, the first commercial release of the language appeared as well as the first edition of the book "The C++ Programming Language" by Bjarne Stroustrup.

During the 80s the C++ language was being refined until it became a language with its own personality. All that with very few losses of compatibility with the code with C, and without resigning to its most important characteristics. In fact, the ANSI standard for the C language published in 1989 took good part of the contributions of C++ to structured programming.

From 1990 on, ANSI committee X3J16 began the development of a specific standard for C++. In the period elapsed until the publication of the standard in 1998, C++ lived a great expansion in its use and today is the preferred language to develop professional applications on all platforms.

Begin Now!

It is my blog on blogspot!
Begin Now!