Concept of counters(part2)

Asynchronous counters

In the previous section, we saw a circuit using one J-K flip-flop that counted backward in a two-bit binary sequence, from 11 to 10 to 01 to 00. Since it would be desirable to have a circuit that could count forward and not just backward, it would be worthwhile to examine a forward count sequence again and look for more patterns that might indicate how to build such a circuit.

Since we know that binary count sequences follow a pattern of octave (factor of 2) frequency division, and that J-K flip-flop multivibrators set up for the "toggle" mode are capable of performing this type of frequency division, we can envision a circuit made up of several J-K flip-flops, cascaded to produce four bits of output. The main problem facing us is to determine how to connect these flip-flops together so that they toggle at the right times to produce the proper binary sequence. Examine the following binary count sequence, paying attention to patterns preceding the "toggling" of a bit between 0 and 1:

Note that each bit in this four-bit sequence toggles when the bit before it (the bit having a lesser significance, or place-weight), toggles in a particular direction: from 1 to 0. Small arrows indicate those points in the sequence where a bit toggles, the head of the arrow pointing to the previous bit transitioning from a "high" (1) state to a "low" (0) state:

Starting with four J-K flip-flops connected in such a way to always be in the "toggle" mode, we need to determine how to connect the clock inputs in such a way so that each succeeding bit toggles when the bit before it transitions from 1 to 0. The Q outputs of each flip-flop will serve as the respective binary bits of the final, four-bit count:

If we used flip-flops with negative-edge triggering (bubble symbols on the clock inputs), we could simply connect the clock input of each flip-flop to the Q output of the flip-flop before it, so that when the bit before it changes from a 1 to a 0, the "falling edge" of that signal would "clock" the next flip-flop to toggle the next bit:

This circuit would yield the following output waveforms, when "clocked" by a repetitive source of pulses from an oscillator:

The first flip-flop (the one with the Q0 output), has a positive-edge triggered clock input, so it toggles with each rising edge of the clock signal. Notice how the clock signal in this example has a duty cycle less than 50%. I've shown the signal in this manner for the purpose of demonstrating how the clock signal need not be symmetrical to obtain reliable, "clean" output bits in our four-bit binary sequence. In the very first flip-flop circuit shown in this chapter, I used the clock signal itself as one of the output bits. This is a bad practice in counter design, though, because it necessitates the use of a square wave signal with a 50% duty cycle ("high" time = "low" time) in order to obtain a count sequence where each and every step pauses for the same amount of time. Using one J-K flip-flop for each output bit, however, relieves us of the necessity of having a symmetrical clock signal, allowing the use of practically any variety of high/low waveform to increment the count sequence.

As indicated by all the other arrows in the pulse diagram, each succeeding output bit is toggled by the action of the preceding bit transitioning from "high" (1) to "low" (0). This is the pattern necessary to generate an "up" count sequence.

A less obvious solution for generating an "up" sequence using positive-edge triggered flip-flops is to "clock" each flip-flop using the Q' output of the preceding flip-flop rather than the Q output. Since the Q' output will always be the exact opposite state of the Q output on a J-K flip-flop (no invalid states with this type of flip-flop), a high-to-low transition on the Q output will be accompanied by a low-to-high transition on the Q' output. In other words, each time the Q output of a flip-flop transitions from 1 to 0, the Q' output of the same flip-flop will transition from 0 to 1, providing the positive-going clock pulse we would need to toggle a positive-edge triggered flip-flop at the right moment:

One way we could expand the capabilities of either of these two counter circuits is to regard the Q' outputs as another set of four binary bits. If we examine the pulse diagram for such a circuit, we see that the Q' outputs generate a down-counting sequence, while the Q outputs generate an up-counting sequence:

Unfortunately, all of the counter circuits shown thusfar share a common problem: the ripple effect. This effect is seen in certain types of binary adder and data conversion circuits, and is due to accumulative propagation delays between cascaded gates. When the Q output of a flip-flop transitions from 1 to 0, it commands the next flip-flop to toggle. If the next flip-flop toggle is a transition from 1 to 0, it will command the flip-flop after it to toggle as well, and so on. However, since there is always some small amount of propagation delay between the command to toggle (the clock pulse) and the actual toggle response (Q and Q' outputs changing states), any subsequent flip-flops to be toggled will toggle some time after the first flip-flop has toggled. Thus, when multiple bits toggle in a binary count sequence, they will not all toggle at exactly the same time:

As you can see, the more bits that toggle with a given clock pulse, the more severe the accumulated delay time from LSB to MSB. When a clock pulse occurs at such a transition point (say, on the transition from 0111 to 1000), the output bits will "ripple" in sequence from LSB to MSB, as each succeeding bit toggles and commands the next bit to toggle as well, with a small amount of propagation delay between each bit toggle. If we take a close-up look at this effect during the transition from 0111 to 1000, we can see that there will be false output counts generated in the brief time period that the "ripple" effect takes place:

Instead of cleanly transitioning from a "0111" output to a "1000" output, the counter circuit will very quickly ripple from 0111 to 0110 to 0100 to 0000 to 1000, or from 7 to 6 to 4 to 0 and then to 8. This behavior earns the counter circuit the name of ripple counter, or asynchronous counter.

In many applications, this effect is tolerable, since the ripple happens very, very quickly (the width of the delays has been exaggerated here as an aid to understanding the effects). If all we wanted to do was drive a set of light-emitting diodes (LEDs) with the counter's outputs, for example, this brief ripple would be of no consequence at all. However, if we wished to use this counter to drive the "select" inputs of a multiplexer, index a memory pointer in a microprocessor (computer) circuit, or perform some other task where false outputs could cause spurious errors, it would not be acceptable. There is a way to use this type of counter circuit in applications sensitive to false, ripple-generated outputs, and it involves a principle known as strobing.

Most decoder and multiplexer circuits are equipped with at least one input called the "enable." The output(s) of such a circuit will be active only when the enable input is made active. We can use this enable input to strobe the circuit receiving the ripple counter's output so that it is disabled (and thus not responding to the counter output) during the brief period of time in which the counter outputs might be rippling, and enabled only when sufficient time has passed since the last clock pulse that all rippling will have ceased. In most cases, the strobing signal can be the same clock pulse that drives the counter circuit:

With an active-low Enable input, the receiving circuit will respond to the binary count of the four-bit counter circuit only when the clock signal is "low." As soon as the clock pulse goes "high," the receiving circuit stops responding to the counter circuit's output. Since the counter circuit is positive-edge triggered (as determined by the first flip-flop clock input), all the counting action takes place on the low-to-high transition of the clock signal, meaning that the receiving circuit will become disabled just before any toggling occurs on the counter circuit's four output bits. The receiving circuit will not become enabled until the clock signal returns to a low state, which should be a long enough time after all rippling has ceased to be "safe" to allow the new count to have effect on the receiving circuit. The crucial parameter here is the clock signal's "high" time: it must be at least as long as the maximum expected ripple period of the counter circuit. If not, the clock signal will prematurely enable the receiving circuit, while some rippling is still taking place.

Another disadvantage of the asynchronous, or ripple, counter circuit is limited speed. While all gate circuits are limited in terms of maximum signal frequency, the design of asynchronous counter circuits compounds this problem by making propagation delays additive. Thus, even if strobing is used in the receiving circuit, an asynchronous counter circuit cannot be clocked at any frequency higher than that which allows the greatest possible accumulated propagation delay to elapse well before the next pulse.

The solution to this problem is a counter circuit that avoids ripple altogether. Such a counter circuit would eliminate the need to design a "strobing" feature into whatever digital circuits use the counter output as an input, and would also enjoy a much greater operating speed than its asynchronous equivalent. This design of counter circuit is the subject of the next section.

summary:

* An "up" counter may be made by connecting the clock inputs of positive-edge triggered J-K flip-flops to the Q' outputs of the preceding flip-flops. Another way is to use negative-edge triggered flip-flops, connecting the clock inputs to the Q outputs of the preceding flip-flops. In either case, the J and K inputs of all flip-flops are connected to Vcc or Vdd so as to always be "high."

* Counter circuits made from cascaded J-K flip-flops where each clock input receives its pulses from the output of the previous flip-flop invariably exhibit a ripple effect, where false output counts are generated between some steps of the count sequence. These types of counter circuits are called asynchronous counters, or ripple counters.

* Strobing is a technique applied to circuits receiving the output of an asynchronous (ripple) counter, so that the false counts generated during the ripple time will have no ill effect. Essentially, the enable input of such a circuit is connected to the counter's clock pulse in such a way that it is enabled only when the counter outputs are not changing, and will be disabled during those periods of changing counter outputs where ripple occurs

Concept of Counters(Part1)

Binary count sequence

If we examine a four-bit binary count sequence from 0000 to 1111, a definite pattern will be evident in the "oscillations" of the bits between 0 and 1:

Note how the least significant bit (LSB) toggles between 0 and 1 for every step in the count sequence, while each succeeding bit toggles at one-half the frequency of the one before it. The most significant bit (MSB) only toggles once during the entire sixteen-step count sequence: at the transition between 7 (0111) and 8 (1000).

If we wanted to design a digital circuit to "count" in four-bit binary, all we would have to do is design a series of frequency divider circuits, each circuit dividing the frequency of a square-wave pulse by a factor of 2:

J-K flip-flops are ideally suited for this task, because they have the ability to "toggle" their output state at the command of a clock pulse when both J and K inputs are made "high" (1):

If we consider the two signals (A and B) in this circuit to represent two bits of a binary number, signal A being the LSB and signal B being the MSB, we see that the count sequence is backward: from 11 to 10 to 01 to 00 and back again to 11. Although it might not be counting in the direction we might have assumed, at least it counts!

The following sections explore different types of counter circuits, all made with J-K flip-flops, and all based on the exploitation of that flip-flop's toggle mode of operation.

* Points:

* Binary count sequences follow a pattern of octave frequency division: the frequency of oscillation for each bit, from LSB to MSB, follows a divide-by-two pattern. In other words, the LSB will oscillate at the highest frequency, followed by the next bit at one-half the LSB's frequency, and the next bit at one-half the frequency of the bit before it, etc.

* Circuits may be built that "count" in a binary sequence, using J-K flip-flops set up in the "toggle" mode.

LEX

The lex utility shall generate C programs to be used in lexical processing of character input, and that can be used as an interface to yacc. The C programs shall be generated from lex source code and conform to the ISO C standard. Usually, the lex utility shall write the program it generates to the file lex.yy.c; the state of this file is unspecified if lex exits with a non-zero exit status.

The general format of lex source shall be:

Definitions

%%

Rules

%%

UserSubroutines

The first "%%" is required to mark the beginning of the rules (regular expressions and actions); the second "%%" is required only if user subroutines follow.

Actions in lex

The action to be taken when an ERE is matched can be a C program fragment or the special actions described below; the program fragment can contain one or more C statements, and can also include special actions. The empty C statement ';' shall be a valid action; any string in the lex.yy.c input that matches the pattern portion of such a rule is effectively ignored or skipped. However, the absence of an action shall not be valid, and the action lex takes in such a condition is undefined.

The specification for an action, including C statements and special actions, can extend across several lines if enclosed in braces:

ERE <one or more blanks> { program statement

program statement }

The default action when a string in the input to a lex.yy.c program is not matched by any expression shall be to copy the string to the output. Because the default behavior of a program generated by lex is to read the input and copy it to the output, a minimal lex source program that has just "%%" shall generate a C program that simply copies the input to the output unchanged.

Four special actions shall be available:

| ECHO; REJECT; BEGIN

|

The action '|' means that the action for the next rule is the action for this rule. Unlike the other three actions, '|' cannot be enclosed in braces or be semicolon-terminated; the application shall ensure that it is specified alone, with no other actions.

ECHO;

Write the contents of the string yytext on the output.

REJECT;

Usually only a single expression is matched by a given string in the input. REJECT means "continue to the next expression that matches the current input", and shall cause whatever rule was the second choice after the current rule to be executed for the same input. Thus, multiple rules can be matched and executed for one input string or overlapping input strings. For example, given the regular expressions "xyz" and "xy" and the input "xyz", usually only the regular expression "xyz" would match. The next attempted match would start after z. If the last action in the "xyz" rule is REJECT, both this rule and the "xy" rule would be executed. The REJECT action may be implemented in such a fashion that flow of control does not continue after it, as if it were equivalent to a goto to another part of yylex(). The use of REJECT may result in somewhat larger and slower scanners.

BEGIN

The action:

BEGIN newstate;

switches the state (start condition) to newstate. If the string newstate has not been declared previously as a start condition in the Definitions section, the results are unspecified. The initial state is indicated by the digit '0' or the token INITIAL.

The functions or macros described below are accessible to user code included in the lex input. It is unspecified whether they appear in the C code output of lex, or are accessible only through the -l l operand to c99 (the lex library).

int yylex(void)

Performs lexical analysis on the input; this is the primary function generated by the lex utility. The function shall return zero when the end of input is reached; otherwise, it shall return non-zero values (tokens) determined by the actions that are selected.

int yymore(void)

When called, indicates that when the next input string is recognized, it is to be appended to the current value of yytext rather than replacing it; the value in yyleng shall be adjusted accordingly.

int yyless(int n)

Retains n initial characters in yytext, NUL-terminated, and treats the remaining characters as if they had not been read; the value in yyleng shall be adjusted accordingly.

int input(void)

Returns the next character from the input, or zero on end-of-file. It shall obtain input from the stream pointer yyin, although possibly via an intermediate buffer. Thus, once scanning has begun, the effect of altering the value of yyin is undefined. The character read shall be removed from the input stream of the scanner without any processing by the scanner.

int unput(int c)

Returns the character 'c' to the input; yytext and yyleng are undefined until the next expression is matched. The result of using unput() for more characters than have been input is unspecified.

The following functions shall appear only in the lex library accessible through the -l l operand; they can therefore be redefined by a conforming application:

int yywrap(void)

Called by yylex() at end-of-file; the default yywrap() shall always return 1. If the application requires yylex() to continue processing with another source of input, then the application can include a function yywrap(), which associates another file with the external variable FILE * yyin and shall return a value of zero.

int main(int argc, char *argv[])

Calls yylex() to perform lexical analysis, then exits. The user code can contain main() to perform application-specific operations, calling yylex() as applicable.

Except for input(), unput(), and main(), all external and static names generated by lex shall begin with the prefix yy or YY.

You will require FLEX to form lex.yy.c file,you can download it easily on ubuntu by going to synaptic manager.

PerL

What Is Perl?

Perl is an acronym, short for Practical Extraction and Report Language. It was designed by Larry Wall as a tool for writing programs in the UNIX environment and is continually being updated and maintained by him. For its many fans,

* Perl provides the best of several worlds. For instance: Perl has the power and flexibility of a high-level programming language such as C. In fact, as you will see, many of the features of the language are borrowed from C.

* Like shell script languages, Perl does not require a special compiler and linker to turn the programs you write into working code. Instead, all you have to do is write the program and tell Perl to run it. This means that Perl is ideal for producing quick solutions to small programming problems, or for creating prototypes to test potential solutions to larger problems.

* Perl provides all the features of the script languages sed and awk, plus features not found in either of these two languages. Perl also supports a sed-to-Perl translator and an awk-to-Perl translator.

In short, Perl is as powerful as C but as convenient as awk, sed, and shell scripts.

Writing your first perl program

1.#!/usr/bin/perl

2.# A simple perl program to print the user input

3.print ("Hello, type in something\n");

4.$inputline=;

5.print ($inputline);

Lets split up the code and see what each line does..

#!/usr/bin/perl

# Says this line is a comment and there are no executable instructions on this line

! Says this is a perl script

/usr/bin/perl give the location of the perl interpreter, many programing books mention the location as usr/local/bin/perl, but this is not correct in ubuntu. In ubuntu Perl interpreter is located at usr/bin/perl.

print “Hello, type in something\n”;

This line just prompts to user to type something, similar to printf statement in C.

$inputline=<stdin>

Here we are setting a variable named inputline, and storing the input from the keyboard into that variable. <stdin> takes the input from the keyboard.

print ($inputline);

This line echoes the typed in message

RUNNING IN UBUNTU

open terminal and give following command

perl hello.pl

here hello is the name of above file which contain code in perl language

FTP CoMmAnDs For LinuX

Linux / Unix Command: ftp

DESCRIPTION

Ftp is the user interface to the Internet standard File Transfer Protocol. The program allows a user to transfer files to and from a remote network site.

Options may be specified at the command line, or to the command interpreter.

-p

Use passive mode for data transfers. Allows use of ftp in environments where a firewall prevents connections from the outside world back to the client machine. Requires that the ftp server support the PASV command. This is the default now for all clients (ftp and pftp) due to security concerns using the PORT transfer mode. The flag is kept for compatibility only and has no effect anymore.

-i

Turns off interactive prompting during multiple file transfers.

-n

Restrains ftp from attempting auto-login upon initial connection. If auto-login is enabled, ftp will check the .netrc (see netrc(5)) file in the user's home directory for an entry describing an account on the remote machine. If no entry exists, ftp will prompt for the remote machine login name (default is the user identity on the local machine), and, if necessary, prompt for a password and an account with which to login.

-e

Disables command editing and history support, if it was compiled into the ftp executable. Otherwise, does nothing.

-g

Disables file name globbing.

-v

Verbose option forces ftp to show all responses from the remote server, as well as report on data transfer statistics.

-d

Enables debugging.

The client host with which ftp is to communicate may be specified on the command line. If this is done, ftp will immediately attempt to establish a connection to an FTP server on that host; otherwise, ftp will enter its command interpreter and await instructions from the user. When ftp is awaiting commands from the user the prompt `ftp>' is provided to the user. The following commands are recognized by ftp

! [command [args ] ]

Invoke an interactive shell on the local machine. If there are arguments, the first is taken to be a command to execute directly, with the rest of the arguments as its arguments.

$ macro-name [args ]

Execute the macro macro-name that was defined with the macdef command. Arguments are passed to the macro unglobbed.

account [passwd ]

Supply a supplemental password required by a remote system for access to resources once a login has been successfully completed. If no argument is included, the user will be prompted for an account password in a non-echoing input mode.

append local-file [remote-file ]

Append a local file to a file on the remote machine. If remote-file is left unspecified, the local file name is used in naming the remote file after being altered by any ntrans or nmap setting. File transfer uses the current settings for type format mode and structure

ascii

Set the file transfer type to network ASCII This is the default type.

bell

Arrange that a bell be sounded after each file transfer command is completed.

binary

Set the file transfer type to support binary image transfer.

bye

Terminate the FTP session with the remote server and exit ftp An end of file will also terminate the session and exit.

case

Toggle remote computer file name case mapping during mget commands. When case is on (default is off), remote computer file names with all letters in upper case are written in the local directory with the letters mapped to lower case.

cd remote-directory

Change the working directory on the remote machine to remote-directory

cdup

Change the remote machine working directory to the parent of the current remote machine working directory.

chmod mode file-name

Change the permission modes of the file file-name on the remote sytem to mode

close

Terminate the FTP session with the remote server, and return to the command interpreter. Any defined macros are erased.

cr

Toggle carriage return stripping during ascii type file retrieval. Records are denoted by a carriage return/linefeed sequence during ascii type file transfer. When cr is on (the default), carriage returns are stripped from this sequence to conform with the UNIX single linefeed record delimiter. Records on non- UNIX remote systems may contain single linefeeds; when an ascii type transfer is made, these linefeeds may be distinguished from a record delimiter only when cr is off.

delete remote-file

Delete the file remote-file on the remote machine.

debug [debug-value ]

Toggle debugging mode. If an optional debug-value is specified it is used to set the debugging level. When debugging is on, ftp prints each command sent to the remote machine, preceded by the string `-->'

dir [remote-directory ] [local-file ]

Print a listing of the directory contents in the directory, remote-directory and, optionally, placing the output in local-file If interactive prompting is on,

ftp will prompt the user to verify that the last argument is indeed the target local file for receiving dir output. If no directory is specified, the current working directory on the remote machine is used. If no local file is specified, or local-file is -, output comes to the terminal.

disconnect

A synonym for close

form format

Set the file transfer form to format The default format is file.

get remote-file [local-file ]

Retrieve the remote-file and store it on the local machine. If the local file name is not specified, it is given the same name it has on the remote machine, subject to alteration by the current case ntrans and nmap settings. The current settings for type form mode and structure are used while transferring the file.

glob

Toggle filename expansion for mdelete mget and mput If globbing is turned off with glob the file name arguments are taken literally and not expanded. Globbing for mput is done as in csh(1). For mdelete and mget each remote file name is expanded separately on the remote machine and the lists are not merged. Expansion of a directory name is likely to be different from expansion of the name of an ordinary file: the exact result depends on the foreign operating system and ftp server, and can be previewed by doing `mls' remote-files - Note: mget and mput are not meant to transfer entire directory subtrees of files. That can be done by transferring a tar(1) archive of the subtree (in binary mode).

hash

Toggle hash-sign (``#'') printing for each data block transferred. The size of a data block is 1024 bytes.

help [command ]

Print an informative message about the meaning of command If no argument is given, ftp prints a list of the known commands.

idle [seconds ]

Set the inactivity timer on the remote server to seconds seconds. If seconds is ommitted, the current inactivity timer is printed.

lcd [directory ]

Change the working directory on the local machine. If no directory is specified, the user's home directory is used.

ls [remote-directory ] [local-file ]

Print a listing of the contents of a directory on the remote machine. The listing includes any system-dependent information that the server chooses to include; for example, most UNIX systems will produce output from the command `ls' -l . (See also nlist . If remote-directory is left unspecified, the current working directory is used. If interactive prompting is on, ftp will prompt the user to verify that the last argument is indeed the target local file for receiving ls output. If no local file is specified, or if local-file is `- ' the output is sent to the terminal.

macdef macro-name

Define a macro. Subsequent lines are stored as the macro macro-name a null line (consecutive newline characters in a file or carriage returns from the terminal) terminates macro input mode. There is a limit of 16 macros and 4096 total characters in all defined macros. Macros remain defined until a close command is executed. The macro processor interprets `$' and `\' as special characters. A `$' followed by a number (or numbers) is replaced by the corresponding argument on the macro invocation command line. A `$' followed by an `i' signals that macro processor that the executing macro is to be looped. On the first pass `$i' is replaced by the first argument on the macro invocation command line, on the second pass it is replaced by the second argument, and so on. A `\' followed by any character is replaced by that character. Use the `\' to prevent special treatment of the `$'.

mdelete [remote-files ]

Delete the remote-files on the remote machine.

mdir remote-files local-file

Like dir except multiple remote files may be specified. If interactive prompting is on, ftp will prompt the user to verify that the last argument is indeed the target local file for receiving mdir output.

mget remote-files

Expand the remote-files on the remote machine and do a get for each file name thus produced. See glob for details on the filename expansion. Resulting file names will then be processed according to case ntrans and nmap settings. Files are transferred into the local working directory, which can be changed with `lcd' directory ; new local directories can be created with `!' mkdir directory .

mkdir directory-name

Make a directory on the remote machine.

mls remote-files local-file

Like nlist except multiple remote files may be specified, and the local-file must be specified. If interactive prompting is on, ftp will prompt the user to verify that the last argument is indeed the target local file for receiving mls output.

mode [mode-name ]

Set the file transfer mode to mode-name The default mode is stream mode.

modtime file-name

Show the last modification time of the file on the remote machine.

mput local-files

Expand wild cards in the list of local files given as arguments and do a put for each file in the resulting list. See glob for details of filename expansion. Resulting file names will then be processed according to ntrans and nmap settings.

newer file-name [local-file ]

Get the file only if the modification time of the remote file is more recent that the file on the current system. If the file does not exist on the current system, the remote file is considered newer Otherwise, this command is identical to get

nlist [remote-directory ] [local-file ]

Print a list of the files in a directory on the remote machine. If remote-directory is left unspecified, the current working directory is used. If interactive prompting is on, ftp will prompt the user to verify that the last argument is indeed the target local file for receiving nlist output. If no local file is specified, or if local-file is -, the output is sent to the terminal.

nmap [inpattern outpattern ]

Set or unset the filename mapping mechanism. If no arguments are specified, the filename mapping mechanism is unset. If arguments are specified, remote filenames are mapped during mput commands and put commands issued without a specified remote target filename. If arguments are specified, local filenames are mapped during mget commands and get commands issued without a specified local target filename. This command is useful when connecting to a non- UNIX remote computer with different file naming conventions or practices. The mapping follows the pattern set by inpattern and outpattern [Inpattern ] is a template for incoming filenames (which may have already been processed according to the ntrans and case settings). Variable templating is accomplished by including the sequences `$1', `$2', ..., `$9' in inpattern Use `\' to prevent this special treatment of the `$' character. All other characters are treated literally, and are used to determine the nmap [inpattern ] variable values. For example, given inpattern $1.$2 and the remote file name "mydata.data", $1 would have the value "mydata", and $2 would have the value "data". The outpattern determines the resulting mapped filename. The sequences `$1', `$2', ...., `$9' are replaced by any value resulting from the inpattern template. The sequence `$0' is replace by the original filename. Additionally, the sequence `[seq1 ] ' , Ar seq2 is replaced by [seq1 ] if seq1 is not a null string; otherwise it is replaced by seq2 For example, the command

nmap $1.$2.$3 [$1,$2].[$2,file]

would yield the output filename "myfile.data" for input filenames "myfile.data" and "myfile.data.old", "myfile.file" for the input filename "myfile", and "myfile.myfile" for the input filename ".myfile". Spaces may be included in outpattern as in the example: `nmap $1 sed "s/ *$//" > $1' . Use the `\' character to prevent special treatment of the `$','[','[', and `,' characters.

ntrans [inchars [outchars ] ]

Set or unset the filename character translation mechanism. If no arguments are specified, the filename character translation mechanism is unset. If arguments are specified, characters in remote filenames are translated during mput commands and put commands issued without a specified remote target filename. If arguments are specified, characters in local filenames are translated during mget commands and get commands issued without a specified local target filename. This command is useful when connecting to a non- UNIX remote computer with different file naming conventions or practices. Characters in a filename matching a character in inchars are replaced with the corresponding character in outchars If the character's position in inchars is longer than the length of outchars the character is deleted from the file name.

open host [port ]

Establish a connection to the specified host FTP server. An optional port number may be supplied, in which case, ftp will attempt to contact an FTP server at that port. If the auto-login option is on (default), ftp will also attempt to automatically log the user in to the FTP server (see below).

prompt

Toggle interactive prompting. Interactive prompting occurs during multiple file transfers to allow the user to selectively retrieve or store files. If prompting is turned off (default is on), any mget or mput will transfer all files, and any mdelete will delete all files.

proxy ftp-command

Execute an ftp command on a secondary control connection. This command allows simultaneous connection to two remote ftp servers for transferring files between the two servers. The first proxy command should be an open to establish the secondary control connection. Enter the command "proxy ?" to see other ftp commands executable on the secondary connection. The following commands behave differently when prefaced by proxy open will not define new macros during the auto-login process, close will not erase existing macro definitions, get and mget transfer files from the host on the primary control connection to the host on the secondary control connection, and put mput and append transfer files from the host on the secondary control connection to the host on the primary control connection. Third party file transfers depend upon support of the ftp protocol PASV command by the server on the secondary control connection.

put local-file [remote-file ]

Store a local file on the remote machine. If remote-file is left unspecified, the local file name is used after processing according to any ntrans or nmap settings in naming the remote file. File transfer uses the current settings for type format mode and structure

pwd

Print the name of the current working directory on the remote machine.

quit

A synonym for bye

quote arg1 arg2 ...

The arguments specified are sent, verbatim, to the remote FTP server.

recv remote-file [local-file ]

A synonym for get.

reget remote-file [local-file ]

Reget acts like get, except that if local-file exists and is smaller than remote-file local-file is presumed to be a partially transferred copy of remote-file and the transfer is continued from the apparent point of failure. This command is useful when transferring very large files over networks that are prone to dropping connections.

remotehelp [command-name ]

Request help from the remote FTP server. If a command-name is specified it is supplied to the server as well.

remotestatus [file-name ]

With no arguments, show status of remote machine. If file-name is specified, show status of file-name on remote machine.

rename [from ] [to ]

Rename the file from on the remote machine, to the file to

reset

Clear reply queue. This command re-synchronizes command/reply sequencing with the remote ftp server. Resynchronization may be necessary following a violation of the ftp protocol by the remote server.

restart marker

Restart the immediately following get or put at the indicated marker On UNIX systems, marker is usually a byte offset into the file.

rmdir directory-name

Delete a directory on the remote machine.

runique

Toggle storing of files on the local system with unique filenames. If a file already exists with a name equal to the target local filename for a get or mget command, a ".1" is appended to the name. If the resulting name matches another existing file, a ".2" is appended to the original name. If this process continues up to ".99", an error message is printed, and the transfer does not take place. The generated unique filename will be reported. Note that runique will not affect local files generated from a shell command (see below). The default value is off.

send local-file [remote-file ]

A synonym for put.

sendport

Toggle the use of PORT commands. By default, ftp will attempt to use a PORT command when establishing a connection for each data transfer. The use of PORT commands can prevent delays when performing multiple file transfers. If the PORT command fails, ftp will use the default data port. When the use of PORT commands is disabled, no attempt will be made to use PORT commands for each data transfer. This is useful for certain FTP implementations which do ignore PORT commands but, incorrectly, indicate they've been accepted.

site arg1 arg2 ...

The arguments specified are sent, verbatim, to the remote FTP server as a SITE command.

size file-name

Return size of file-name on remote machine.

status

Show the current status of ftp

struct [struct-name ]

Set the file transfer structure to struct-name By default stream structure is used.

sunique

Toggle storing of files on remote machine under unique file names. Remote ftp server must support ftp protocol STOU command for successful completion. The remote server will report unique name. Default value is off.

system

Show the type of operating system running on the remote machine.

tenex

Set the file transfer type to that needed to talk to TENEX machines.

trace

Toggle packet tracing.

type [type-name ]

Set the file transfer type to type-name If no type is specified, the current type is printed. The default type is network ASCII

umask [newmask ]

Set the default umask on the remote server to newmask If newmask is ommitted, the current umask is printed.

user user-name [password ] [account ]

Identify yourself to the remote FTP server. If the password is not specified and the server requires it, ftp will prompt the user for it (after disabling local echo). If an account field is not specified, and the FTP server requires it, the user will be prompted for it. If an account field is specified, an account command will be relayed to the remote server after the login sequence is completed if the remote server did not require it for logging in. Unless ftp is invoked with auto-login disabled, this process is done automatically on initial connection to the FTP server.

verbose

Toggle verbose mode. In verbose mode, all responses from the FTP server are displayed to the user. In addition, if verbose is on, when a file transfer completes, statistics regarding the efficiency of the transfer are reported. By default, verbose is on.

? [command ]

A synonym for help.

Command arguments which have embedded spaces may be quoted with quote `"' marks.

ABORTING A FILE TRANSFER

To abort a file transfer, use the terminal interrupt key (usually Ctrl-C). Sending transfers will be immediately halted. Receiving transfers will be halted by sending a ftp protocol ABOR command to the remote server, and discarding any further data received. The speed at which this is accomplished depends upon the remote server's support for ABOR processing. If the remote server does not support the ABOR command, an `ftp>' prompt will not appear until the remote server has completed sending the requested file.

The terminal interrupt key sequence will be ignored when ftp has completed any local processing and is awaiting a reply from the remote server. A long delay in this mode may result from the ABOR processing described above, or from unexpected behavior by the remote server, including violations of the ftp protocol. If the delay results from unexpected remote server behavior, the local ftp program must be killed by hand.

FILE NAMING CONVENTIONS

Files specified as arguments to ftp commands are processed according to the following rules.

1. If the file name `- ' is specified, the stdin (for reading) or stdout (for writing) is used.

2. If the first character of the file name is `|' the remainder of the argument is interpreted as a shell command. Ftp then forks a shell, using popen(3) with the argument supplied, and reads (writes) from the stdout (stdin). If the shell command includes spaces, the argument must be quoted; e.g. " ls -lt". A particularly useful example of this mechanism is: dir more.

3. Failing the above checks, if ``globbing'' is enabled, local file names are expanded according to the rules used in the csh(1); c.f. the glob command. If the ftp command expects a single local file (.e.g. put ) only the first filename generated by the "globbing" operation is used.

4. For mget commands and get commands with unspecified local file names, the local filename is the remote filename, which may be altered by a case ntrans or nmap setting. The resulting filename may then be altered if runique is on.

5. For mput commands and put commands with unspecified remote file names, the remote filename is the local filename, which may be altered by a ntrans or nmap setting. The resulting filename may then be altered by the remote server if sunique is on.

FILE TRANSFER PARAMETERS

The FTP specification specifies many parameters which may affect a file transfer. The type may be one of ascii, image (binary), ebcdic, and local byte size (for PDP -10's and PDP -20's mostly). Ftp supports the ascii and image types of file transfer, plus local byte size 8 for tenex mode transfers.

Ftp supports only the default values for the remaining file transfer parameters: mode form and struct

EXAMPLES

ftp abc.xyz.edu

This command will attempt to connect to the ftp server at abc.xyz.edu. If it succeeds, it will ask you to log in using a username and password. Public ftp servers often allow you to log in using the username "anonymous" and your email address as password. Once you are logged in you can get a list of the available ftp commands using the help function:

ftp> help

This lists the commands that you can use to show the directory contents, transfer files, and delete files.

ftp> ls

This command prints the names of the files and subdirectories in the current directory on the remote computer.

ftp> cd customers

This command changes the current directory to the subdirecotry "customers", if it exists.

ftp> cd ..

Changes the current directory to the parent direcotry.

ftp> lcd images

Changes the current directory on the local computer to "images", if it exists.

ftp> ascii

Changes to "ascii" mode for transferring text files.

ftp> binary

Changes to "binary" mode for transferring all files that are not text files.

ftp> get image1.jpg

Downloads the file image1.jpg from the remote computer to the local computer. Warning: If there already is file with the same name it will be overwritten.

ftp> put image2.jpg

Uploads the file image2.jpg from the local computer to the remote computer. Warning: If there already is file with the same name it will be overwritten.

ftp> !ls

A '!' in front will execute the specified command on the local computer. So '!ls' lists the file names and directory names of the current directory on the local computer.

ftp> mget *.jpg

With mget you can download multiple images. This command downloads all files that end with ".jgp".

ftp> mput *.jpg

Uploads all files that end with ".jgp".

ftp> mdelete *.jpg

Deletes all files that end with ".jgp".

ftp> prompt

Turns iteractive mode on or off so that commands on multiple files are executed without user confirmation.

ftp> quit

Exits the ftp program.

DanGling PointErs

Dangling pointers and wild pointers in computer programming are pointers that do not point to a valid object of the appropriate type.

Dangling pointers arise when an object is deleted or deallocated, without modifying the value of the pointer, so that the pointer still points to the memory location of the deallocated memory. As the system may reallocate the previously freed memory to another process, if the original program then dereferences the (now) dangling pointer, unpredictable behavior may result, as the memory may now contain completely different data. This is especially the case if the program writes data to memory pointed by a dangling pointer, a silent corruption of unrelated data may result, leading to subtle bugs that can be extremely difficult to find, or cause segmentation faults (*NIX) or general protection faults (Windows). If the overwritten data is bookkeeping data used by the system's memory allocator, the corruption can cause system instabilities.

Wild pointers arise when a pointer is used prior to initialization to some known state, which is possible in some programming languages. They show the same erratic behavior as dangling pointers, though they are less likely to stay undetected

Cause of Dangling Pointer

In many languages (e.g., the C programming language) deleting an object from memory explicitly or by destroying the stack frame on return does not alter associated pointers. The pointer still points to the same location in memory even though the reference has since been deleted and may now be used for other purposes.

A straightforward example is shown below:

{

char *dp = NULL;

/* ... */

{

char c;

dp = &c;

} /* c falls out of scope */

/* dp is now a dangling pointer */

}

If the operating system is able to detect run-time references to null pointers, a solution to the above is to assign 0 (null) to dp immediately before the inner block is exited. Another solution would be to somehow guarantee dp is not used again without further initialization.

Another frequent source of dangling pointers is a jumbled combination of malloc() and free() library calls: a pointer becomes dangling when the block of memory it points to is freed. As with the previous example one way to avoid this is to make sure to reset the pointer to null after freeing its reference—as demonstrated below.

#include <stdlib.h>

void func()

{

char *dp = malloc(A_CONST);

/* ... */

free(dp); /* dp now becomes a dangling pointer */

dp = NULL; /* dp is no longer dangling */

/* ... */

}

An all too common misstep is returning addresses of a stack-allocated local variable: once a called function returns, the space for these variables gets deallocated and technically they have "garbage values".

int *func(void)

{

int num = 1234;

/* ... */

return &num;

}

Attempts to read from the pointer may still return the correct value (1234) for a while after calling func, but any functions called thereafter will overwrite the stack storage allocated for num with other values and the pointer would no longer work correctly. If a pointer to num must be returned, num must have scope beyond the function—it might be declared as static.

Cause of wild pointers

Wild pointers are created by omitting necessary initialization prior to first use. Thus, strictly speaking, every pointer in programming languages which do not enforce initialization begins as a wild pointer.

This most often occurs due to jumping over the initialization, not by omitting it. Most compilers are able to warn about this.

int f(int i)

{

char *dp; /* dp is a wild pointer */

static char *scp; /* scp is not a wild pointer:

* static variables are initialized to 0

* at start and retain their values from

* the last call afterwards.

* Using this feature may be considered bad

* style if not commented */

}

Understanding Run-time Environment Representation and Control

In Algol-like languages like Pascal, Algol W, and C/C++, all of the environments that exist at any point during a computation can be collectively represented using a stack. This representation for environments is particularly advantageous because the environment stack can be implemented as an elaboration of the control stack included in the architecture of a modern computer to support procedure calls.

Algol-like languages are almost always compiled to machine code instead of interpreted like LC and Jam. Nevertheless, during program execution, the compiled machine code must perform all of the same operations on program data structures as interpreted code. The major difference between the two approaches is that a compiler typically has the opportunity to perform far more program analysis enabling it to precompute quantities that are computed by an interpreter during program execution.

Almost all modern machines provide a control stack to store the return addresses of procedure calls. In addition, other context information (such as the contents of registers that must be restored by the called procedure) is typically saved with the return address in a frame on the control stack. To return, the called procedure pops the current ("top") frame off the stack, restores the saved context information (typically the contents of registers that by convention must be preserved across procedure calls) and jumps to the specified return address. The popping of the "top" stack frame off the stack restores the stack to the form it had before the call (although some of the bindings for local variables stored in the stack may have changed).

Some machines also pass argument values to procedures in the stack. The argument values are pushed on the stack along with the return address and the saved context information. Another common convention is to pass arguments (assuming the number is small) in registers. The result returned by a procedure is typically returned in a register because the stack frame associated with the call is deallocated on return. (Another possible convention is to store the return value in a designated location in the calling stack frame.)

Now let us relate the stack representation of environments to our understanding of the evaluation of programming languages with lexical scoping, i.e., the (recursive) let and lambda constructs. We have discussed lexical scope in the context of mostly functional languages based on the lambda-calculus, but exactly the same lexical constructs are present in Algol-like languages. In Algol-like language, a rec-let is called a block and a lambda (which must occur as a rhs of a definition introduced in a block [rec-let definition]) is called a procedure declaration.

In a stack-based implementation of a lexically-scoped language, a new environment is constructed (the extend-env process in our LC interpreter) to evaluate the body of a let or a lambda application by allocating a new frame called an activation record on the control stack. The activation record contains:

* the new variable bindings introduced by the let or lambda,

* a pointer called the static link pointing back to the rest of the environment (a linked list of activation records),

* a pointer called the dynamic link to the preceding activation record,

* the return address (address of the next instruction in the code block that invoked the let or lambda application, and

* any register values that need to be saved for restoration on return from the let or lambda.

In this representation, an environment consists of a linked list of activation records; the link field connecting this list static link in each record. The first record in the sequence gives the local bindings (static distance 0), the second record gives the bindings at static distance 1, and so forth. The length of this list is simply the lexical nesting level of the body of the let form or lambda application being evaluated.

For let invocations (regardless of whether let is recursive)

(let ([x1 e1] ... [xn en]) E)

and raw lambda applications

((lambda (x1 ... xn) E) e1 ... en),

the static link and dynamic link in the new activation record both point to the same place, namely the preceding activation record on the stack (the activation record for the enclosing let form or lambda application.

For a function application

(f e1 ... en)

the static link in the new activation points to the activation record in the static chain corresponding the static distance between the application site and the definition of f. For a simple recursive function call (e.g., the recursive call in the usual definition of factorial), this static link is identical to the static link in the calling activation record (the preceding activation record on the stack).

In Algol-like languages, the only closures are functions that are passed as arguments to other functions. These closures are represented by a pair of pointers. One pointer points to a representation of the the function consisting of a record with the code for the function (or a pointer it) and a template describing the format of its activation record. The other pointer is the static link to be stored in the activation record for the closure when it is invoked (the saved environment for the closure).

In Algol-like languages, closures can only be passed as function arguments. As a result, the activation record identified by the static link stored in the closure is always available on the stack when the closure in invoked. When that activation is finally freed, the corresponding closure is guaranteed to be inaccessible. (Since C/C++ has no nested blocks or procedure definitions, closures degenerate to function pointers.)

The stack representation of environments breaks if a closure can be invoked after the activation record to which it points (through its static link) is deallocated ("popped"). The activation record no longer exists and the storage it occupied may have been reused. If the closure code tries to refer to a variable in the deallocated record, it retrieves corrupt data. Algol-like languages restrict the usage of closures to prevent this problem from occurring. (In C/C++ the same problem can arise if a data structure points to an object on the stack. Unfortunately, C/C++ does nothing to prevent the catastrophe that occurs if the activation record containing the object is deallocated while the reference still exists.)

In the absence of tail-call optimization which converts procedure calls to jumps, every procedure call allocates a new stack frame. Hence, a recursive procedure may allocate a large number of stack frames. The standard definition of the factorial function, for example, allocates 1001 frames to evaluate 1000! In this case, all of the activation records for invocations of factorial have the same static link.

Programs written in "advanced" languages like Scheme, ML, Jam, and LC can obviously be restricted to accommodate the stack representation of environments by prohibiting closures from being returned as values or stored in data structures. But this restriction reduces these advanced language to Algol with a garbage-collected heap. To accommodate general closures, two implementation strategies are widely used.

The first strategy is to abandon the stack discipline for managing activation records by allocating activation records in the heap and relying on garbage collection to reclaim the storage occupied by activation records. This approach does not use the control stack mechanism provided by the underlying computer architecture.

The second strategy uses a hybrid representation scheme for environments that supplements the stack representation with information stored in the heap. The critical flaw in the stack implementation is that it destroys variables when the evaluation of the corresponding lambda returns. If such variables are stored in the heap and the closure knows how to find them, then the static link stored in the closure representation is unnecessary: all lookups that would have followed the static chain simply access the appropriate variables in the heap. Such an implementation must identify the set of variables that occur free in each lambda-expression and force them to be allocated on the heap (adding a level of indirection to the access protocol). The activation records that would have contained these variables now contain pointers to them (located in the heap) instead. Fortunately, the "closure analysis" required to determine which variables must be heap allocated is easy for a compiler to do.

In the hybrid strategy for supporting closures, the activation record template used to represent a closure must include a pointer field for each free variable in the closure. When a lambda-expression is evaluated, an activation record template is allocated and the values of the pointers to free variables are copied from the relevant activation records on stack.

It is possible to build a good language implementation using either strategy. The hybrid scheme adds a level of indirection to some variable accesses (ordinary lookups of heap allocated variables) but reduces it in others (free variable lookups from within closure bodies). Overall, the hybrid scheme has a modest advantage because it manages memory allocation for activation records more efficiently (through memory reuse and less fragmentation). In addition, the hybrid scheme tends to recover more free memory during garbage collection because it only retains the variable bindings that actually appear in closure bodies, while the brute force heap allocation scheme retains all bindings in the activation records accessible to closures.

In the course of an computation, an exceptional condition may be encountered that requires abandoning a subcomputation. If that subcomputation has a large number of associated stack frames, the "bubbling" action require to pass a special value back up the call chain is time-consuming and awkward to program. What we want is a construct that lets us label a selected stack frame as a recovery point and return a value directly to that frame (just as if the next stack frame had returned normally). The "direct return" operation deallocates all of the stack frames from the current frame back to the recovery frame; this can be done simply by changing the contents of the register serving as the stack pointer. In addition, it places the return value in the standard place (usually a register) in determined by the procedure calling conventions.

The Scope of Variables

The Scope of Variables

Almost every programming language has:

1. constructs for introducing a new variable x, and

2. scoping rules for determining which uses of the variable name x in the rest of the program refer to this variable.

If the same name x is used for several different variables, a programmer can resolve which variable is really meant by a particular use of the name x.

For example, in Java a loop header may introduce a new loop variable and its scope:

for (int i = 0; i < NumOfElements; i++) ... ;

The scope of the variable i is the program text following the = all the way to the end of the loop body. If the loop contains a break construct and if the loop is followed by some statement like

System.out.println("the index where we stopped searching is " + i);

then we know from the scoping rules for Java that the program is almost certainly erroneous. Since the use of i in the invocation of println does not refer to the variable i that was introduced as the loop variable, the reference to variable i in the print statement either is illegal or refers to a variable with a scope that encloses the loop and the subsequent print statement.

Note: We analyzed the preceding program fragment with a rough understanding of its execution semantics but with a precise understanding of the scoping rules. These scoping rules are crucial for building a good mental execution model.

Other examples of scoping constructs in Java and C++ include

* class definitions,

* method definitions,

* parameter declarations, and

* sequences of statements (tails of blocks)

Hyperbolic functions - sinh, cosh, tanh, coth, sech, csch

DEFINITION OF HYPERBOLIC FUNCTIONS

Hyperbolic sine of x = sinh x = (e^x - e^-x)/2

Hyperbolic cosine of x = cosh x = (e^x + e^-x)/2

Hyperbolic tangent of x = tanh x = (e^x - e^-x)/(e^x + e^-x)

Hyperbolic cotangent of x = coth x = (e^x + e^-x)/(e^x - e^-x)

Hyperbolic secant of x = sech x = 2/(e^x + e^-x)

Hyperbolic cosecant of x = csch x = 2/(e^x - e^-x)

RELATIONSHIPS AMONG HYPERBOLIC FUNCTIONS

tanh x = sinh x/cosh x

coth x = 1/tanh x = cosh x/sinh x

sech x = 1/cosh x

csch x = 1/sinh x

cosh2x - sinh2x = 1

sech2x + tanh2x = 1

coth2x - csch2x = 1

Student GaLLery Password

if u want password then just mail me at kissmeoon@gmail.com

or leave comment below

note:Password will be issued to only iet students .

/* please dont forget to mention your year,branch */

Bubble Sort (Working in Best Case)

Do U really know How Bubble Sort Work ???

Well in most of the books algorithm given for bubble sort is wrong

because it dont work for best case of bubble sort

Here i am providing you correct one:

Points to remember:

1:after every iteration in bubble sort highest value element get sorted(if we are sorting in ascending order otherwise vise-versa)

2:That means after first iteration we compare only n-1 element if we started with n elements.

3:We compare adjacent elements(do rememberSort element sorted are not compared ),if order is wrong then we swap them.

3:best case complexity of bubble sort is O(n),that if we give already sorted element as input then bubble sort will take only O(n)

4:Average case and Worst case Complexity O(n^2).

void bubble(int a[],int n)

{

int temp,j,pass;

int s=1;

for(pass=0;pass<n-1 && s=1;pass++)

/* outer loop control no. of pass */

{

s=0; /* initially no interchange had been made */

for(j=0;j<n-pass-1;j++)

{

if(a[j]>a[j+1])

{

/* element not in order need to be interchange to achieve our goal of sorting */

s=1;

temp=a[j];

a[j]=a[j+1];

a[j+1]=temp;

}/* end of if */

}/* end of inner loop for */

}/* end of outer loop */

}/*end of bubble */

/* have any problem feel free 2 ask*/

Password Protect Your HTML Page

Put this code on your page:

<HEAD>

<SCRIPT language="JavaScript">

<!--hide

var password;

var pass1="cool";

password=prompt('Please enter your password to view this page!',' ');

if (password==pass1)

alert('Password Correct! Click OK to enter!');

else

{

window.location="http://vishallovesualot.blogspot.com/";

}

//-->

</SCRIPT>

</HEAD>

NOw in place of "cool" you can put any password of your choice.

/* have any problem? ..just Ask For help here :) */

Bresenham's Line Drawing Algorithm

Now For m>1

Exchange dy(x) and dy(y)

and follow the same procedure as given above.

Facebook Hacker Cup

Game on

The 2011 Facebook Hacker Cup is the first annual Facebook programming contest where hackers compete against each other for fame, fortune, glory and a shot at the coveted Hacker Cup.

There can only be one...

Many will enter, but only one will claim title as champion and take home the $5,000 USD cash prize and be immortalized on the Hacker Cup.

Free Gate preparation Tutorial and e-books

GATE-2011

here am providing some ebooks to especially gate aspirant ,which i found while surfing web

hope it will be usefull for you guys.if you have any problem related to gate-2011

let me known i'll be glad to answer your questions

Click here

Super Mario in ubuntu(SuperTux)

What is SuperTux?

SuperTux is a classic 2D jump'n run sidescroller game in a style similar to the original Super Mario games

covered under the GPL. The Milestone 1 release of SuperTux features:

* 9 enemies

* 26 playable levels

* Software and OpenGL rendering modes

* configurable joystick and keyboard input

* new music

* completely redone graphics

SuperTux is available for Windows, Linux, MacOSX as well as numerous other more exotic systems.

To install in ubuntu go to software center and search.

or give following command in terminal:

sudo apt-get install supertux

First 4G Mobile Phone

DID YOU KNOW THAT "HTC EVO" IS WORLD'S FIRST 4G MOBILE!!

HTML TAGS

HTML 4.01 / XHTML 1.0 Reference Ordered Alphabetically DTD: indicates in which HTML 4.01 / XHTML 1.0 DTD the tag is allowed. S=Strict, T=Transitional, and F=Frameset Tag Description DTD <!--...--> Defines a comment STF <!DOCTYPE>  Defines the document type STF <a> Defines an anchor STF <abbr> Defines an abbreviation STF <acronym> Defines an acronym STF <address> Defines contact information for the author/owner of a document STF <applet> Deprecated. Defines an embedded applet TF <area /> Defines an area inside an image-map STF <b> Defines bold text STF <base /> Defines a default address or a default target for all links on a page STF <basefont /> Deprecated. Defines a default font, color, or size for the text in a page TF <bdo> Defines the text direction STF <big> Defines big text STF <blockquote> Defines a long quotation STF <body> Defines the document's body STF <br /> Defines a single line break STF <button> Defines a push button STF <caption> Defines a table caption STF <center> Deprecated. Defines centered text TF <cite> Defines a citation STF <code> Defines computer code text STF <col /> Defines attribute values for one or more columns in a table  STF <colgroup> Defines a group of columns in a table for formatting STF <dd> Defines a description of a term in a definition list STF <del> Defines deleted text STF <dfn> Defines a definition term STF <dir> Deprecated. Defines a directory list TF <div> Defines a section in a document STF <dl> Defines a definition list STF <dt> Defines a term (an item) in a definition list STF <em> Defines emphasized text  STF <fieldset> Defines a border around elements in a form STF <font> Deprecated. Defines font, color, and size for text TF <form> Defines an HTML form for user input STF <frame /> Defines a window (a frame) in a frameset F <frameset> Defines a set of frames F <h1> to <h6> Defines HTML headings STF <head> Defines information about the document STF <hr /> Defines a horizontal line STF <html> Defines an HTML document STF <i> Defines italic text STF <iframe> Defines an inline frame TF <img /> Defines an image STF <input /> Defines an input control STF <ins> Defines inserted text STF <isindex> Deprecated. Defines a searchable index related to a document TF <kbd> Defines keyboard text STF <label> Defines a label for an input element STF <legend> Defines a caption for a fieldset element STF <li> Defines a list item STF <link /> Defines the relationship between a document and an external resource STF <map> Defines an image-map  STF <menu> Deprecated. Defines a menu list TF <meta /> Defines metadata about an HTML document STF <noframes> Defines an alternate content for users that do not support frames TF <noscript> Defines an alternate content for users that do not support client-side scripts STF <object> Defines an embedded object STF <ol> Defines an ordered list STF <optgroup> Defines a group of related options in a select list STF <option> Defines an option in a select list STF <p> Defines a paragraph STF <param /> Defines a parameter for an object STF <pre> Defines preformatted text STF <q> Defines a short quotation STF <s> Deprecated. Defines strikethrough text TF <samp> Defines sample computer code STF <script> Defines a client-side script STF <select> Defines a select list (drop-down list) STF <small> Defines small text STF <span> Defines a section in a document STF <strike> Deprecated. Defines strikethrough text TF <strong> Defines strong text STF <style> Defines style information for a document STF <sub> Defines subscripted text STF <sup> Defines superscripted text STF <table> Defines a table STF <tbody> Groups the body content in a table STF <td> Defines a cell in a table STF <textarea> Defines a multi-line text input control STF <tfoot> Groups the footer content in a table STF <th> Defines a header cell in a table STF <thead> Groups the header content in a table STF <title> Defines the title of a document STF <tr> Defines a row in a table STF <tt> Defines teletype text STF <u> Deprecated. Defines underlined text TF <ul> Defines an unordered list STF <var> Defines a variable part of a text STF <xmp> Deprecated. Defines preformatted text