Exam help - Revision history

Aapara: /* Write 0xDEADBEEF in decimal? */

2018-01-03T16:50:22Z

Write 0xDEADBEEF in decimal?

← Older revision		Revision as of 19:50, 3 January 2018
Line 521:		Line 521:

	===Write 0xDEADBEEF in decimal?===		===Write 0xDEADBEEF in decimal?===
	Following the table above we calculate, 13x16^8 + 14x16^7 + 10x16^6 + 13x16^5 + 11x16^4 + 14x16^3 + 14x16^2 + 15x16^1 = A BIG NUMBER!		Following the table above we calculate, 13x16^7 + 14x16^6 + 10x16^5 + 13x16^4 + 11x16^3 + 14x16^2 + 14x16^1 + 15x16^0 = A BIG NUMBER! (3735928559)

	===What is [https://en.wikipedia.org/wiki/Quantization_%28signal_processing%29 quantization] in terms of signal processing?===		===What is [https://en.wikipedia.org/wiki/Quantization_%28signal_processing%29 quantization] in terms of signal processing?===

Mdhasan: /* basic git command */

2016-01-27T11:31:24Z

basic git command

Show changes

Mdhasan: /* Publishing work */

2016-01-27T11:24:58Z

Publishing work

← Older revision		Revision as of 14:24, 27 January 2016
Line 959:		Line 959:
	===What would you store in a version control system?===		===What would you store in a version control system?===

			===basic git command===
			Basic Git commands
			Here is a list of some basic Git commands to get you going with Git.
			For more detail, check out the Atlassian Git Tutorials for a visual introduction to Git commands and workflows, including examples.
			Git task Notes Git commands
			Tell Git who you are
			Configure the author name and email address to be used with your commits.
			Note that Git strips some characters (for example trailing periods) from user.name.
			git config --global user.name "Sam Smith"
			git config --global user.email sam@example.com
			Create a new local repository

			git init
			Check out a repository
			Create a working copy of a local repository:
			git clone /path/to/repository
			For a remote server, use:
			git clone username@host:/path/to/repository
			Add files
			Add one or more files to staging (index):
			git add <filename>

			git add *
			Commit
			Commit changes to head (but not yet to the remote repository):
			git commit -m "Commit message"
			Commit any files you've added with git add, and also commit any files you've changed since then:
			git commit -a
			Push
			Send changes to the master branch of your remote repository:
			git push origin master
			Status List the files you've changed and those you still need to add or commit:
			git status
			Connect to a remote repository
			If you haven't connected your local repository to a remote server, add the server to be able to push to it:
			git remote add origin <server>
			List all currently configured remote repositories: git remote -v
			Branches
			Create a new branch and switch to it:
			git checkout -b <branchname>
			Switch from one branch to another:
			git checkout <branchname>
			List all the branches in your repo, and also tell you what branch you're currently in:
			git branch
			Delete the feature branch:
			git branch -d <branchname>
			Push the branch to your remote repository, so others can use it:
			git push origin <branchname>
			Push all branches to your remote repository:
			git push --all origin
			Delete a branch on your remote repository:
			git push origin :<branchname>
			Update from the remote repository
			Fetch and merge changes on the remote server to your working directory:
			git pull
			To merge a different branch into your active branch:
			git merge <branchname>
			View all the merge conflicts:
			View the conflicts against the base file:
			Preview changes, before merging:
			git diff
			git diff --base <filename>
			git diff <sourcebranch> <targetbranch>
			After you have manually resolved any conflicts, you mark the changed file:
			git add <filename>
			Tags
			You can use tagging to mark a significant changeset, such as a release:
			git tag 1.0.0 <commitID>
			CommitId is the leading characters of the changeset ID, up to 10, but must be unique. Get the ID using:
			git log
			Push all tags to remote repository:
			git push --tags origin
			Undo local changes
			If you mess up, you can replace the changes in your working tree with the last content in head:
			Changes already added to the index, as well as new files, will be kept.
			git checkout -- <filename>
			Instead, to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it, do this:
			git fetch origin

			git reset --hard origin/master
			Search
			Search the working directory for foo(): git grep "foo()"

	==Algorithms and data structures==		==Algorithms and data structures==

Smets: /* What are the major steps of compilation? */

2016-01-13T11:44:25Z

What are the major steps of compilation?

← Older revision		Revision as of 14:44, 13 January 2016
Line 348:		Line 348:

	In this phase, the code generator takes the optimized representation of the intermediate code and maps it to the target machine language. The code generator translates the intermediate code into a sequence of (generally) re-locatable machine code. Sequence of instructions of machine code performs the task as the intermediate code would do.		In this phase, the code generator takes the optimized representation of the intermediate code and maps it to the target machine language. The code generator translates the intermediate code into a sequence of (generally) re-locatable machine code. Sequence of instructions of machine code performs the task as the intermediate code would do.

			nmap 192.168.12.1-254 -p22,80

	===What are the differences between [https://en.wikipedia.org/wiki/Interpreted_language interpreted], [https://en.wikipedia.org/wiki/Just-in-time_compilation JIT-compilation] and [https://en.wikipedia.org/wiki/Compiler traditional compiling]?===		===What are the differences between [https://en.wikipedia.org/wiki/Interpreted_language interpreted], [https://en.wikipedia.org/wiki/Just-in-time_compilation JIT-compilation] and [https://en.wikipedia.org/wiki/Compiler traditional compiling]?===

Ssumathi: /* What is the purpose of a version control system? */

2016-01-13T10:15:32Z

What is the purpose of a version control system?

Ssumathi: /* What is the purpose of a version control system? */

2016-01-13T10:13:51Z

What is the purpose of a version control system?

← Older revision		Revision as of 13:13, 13 January 2016
Line 921:		Line 921:

	===What is the purpose of a version control system?===		===What is the purpose of a version control system?===

			Why Use a Version Control System?

			There are many benefits of using a version control system for your projects. This chapter explains some of them in detail.

			Collaboration

			Without a VCS in place, you're probably working together in a shared folder on the same set of files. Shouting through the office that you are currently working on file "xyz" and that, meanwhile, your teammates should keep their fingers off is not an acceptable workflow. It's extremely error-prone as you're essentially doing open-heart surgery all the time: sooner or later, someone will overwrite someone else's changes.

			With a VCS, everybody on the team is able to work absolutely freely - on any file at any time. The VCS will later allow you to merge all the changes into a common version. There's no question where the latest version of a file or the whole project is. It's in a common, central place: your version control system.

			Other benefits of using a VCS are even independent of working in a team or on your own.

			Storing Versions (Properly)

			Saving a version of your project after making changes is an essential habit. But without a VCS, this becomes tedious and confusing very quickly:

			How much do you save? Only the changed files or the complete project? In the first case, you'll have a hard time viewing the complete project at any point in time - in the latter case, you'll have huge amounts of unnecessary data lying on your hard drive.
			How do you name these versions? If you're a very organized person, you might be able to stick to an actually comprehensible naming scheme (if you're happy with "acme-inc-redesign-2013-11-12-v23"). However, as soon as it comes to variants (say, you need to prepare one version with the header area and one without it), chances are good you'll eventually lose track.
			The most important question, however, is probably this one: How do you know what exactly is different in these versions? Very few people actually take the time to carefully document each important change and include this in a README file in the project folder.
			A version control system acknowledges that there is only one project. Therefore, there's only the one version on your disk that you're currently working on. Everything else - all the past versions and variants - are neatly packed up inside the VCS. When you need it, you can request any version at any time and you'll have a snapshot of the complete project right at hand.

			Restoring Previous Versions

			Being able to restore older versions of a file (or even the whole project) effectively means one thing: you can't mess up! If the changes you've made lately prove to be garbage, you can simply undo them in a few clicks. Knowing this should make you a lot more relaxed when working on important bits of a project.

			Understanding What Happened

			Every time you save a new version of your project, your VCS requires you to provide a short description of what was changed. Additionally (if it's a code / text file), you can see what exactly was changed in the file's content. This helps you understand how your project evolved between versions.

			Backup

			A side-effect of using a distributed VCS like Git is that it can act as a backup; every team member has a full-blown version of the project on his disk - including the project's complete history. Should your beloved central server break down (and your backup drives fail), all you need for recovery is one of your teammates' local Git repository.

	===What would you store in a version control system?===		===What would you store in a version control system?===

Ssumathi: /* Show the truth table for ? */

2016-01-13T10:09:27Z

Show the truth table for ?

← Older revision		Revision as of 13:09, 13 January 2016
Line 804:		Line 804:


	Logical Disjunction(OR)		Logical Disjunction(OR)

	{\| class="wikitable"		{\| class="wikitable"
Line 831:		Line 831:


	Logical NAND		Logical NAND

	{\| class="wikitable"		{\| class="wikitable"

Ssumathi: /* Show the truth table for ? */

2016-01-13T10:07:59Z

Show the truth table for ?

@@ Line 851: / Line 851: @@
 |T
 |T
 |-
 |F

Ssumathi: /* Show the truth table for ? */

2016-01-13T10:05:24Z

Show the truth table for ?

@@ Line 828: / Line 828: @@
 |F
 |F
 |}

Ssumathi: /* Show the truth table for ? */

2016-01-13T10:02:56Z

Show the truth table for ?

← Older revision		Revision as of 13:02, 13 January 2016
Line 811:		Line 811:
	\|p		\|p
	\|q		\|q
	\|p ∧ q		\|p ∨ q
	\|-		\|-
	\|T		\|T

← Older revision		Revision as of 13:15, 13 January 2016
Line 924:		Line 924:
	Why Use a Version Control System?		Why Use a Version Control System?

	There are many benefits of using a version control system for your projects. This chapter explains some of them in detail.		There are many benefits of using a version control system for your projects. This chapter explains some of them in detail.

	Collaboration		Collaboration

	Without a VCS in place, you're probably working together in a shared folder on the same set of files. Shouting through the office that you are currently working on file "xyz" and that, meanwhile, your teammates should keep their fingers off is not an acceptable workflow. It's extremely error-prone as you're essentially doing open-heart surgery all the time: sooner or later, someone will overwrite someone else's changes.		Without a VCS in place, you're probably working together in a shared folder on the same set of files. Shouting through the office that you are currently working on file "xyz" and that, meanwhile, your teammates should keep their fingers off is not an acceptable workflow. It's extremely error-prone as you're essentially doing open-heart surgery all the time: sooner or later, someone will overwrite someone else's changes.

	With a VCS, everybody on the team is able to work absolutely freely - on any file at any time. The VCS will later allow you to merge all the changes into a common version. There's no question where the latest version of a file or the whole project is. It's in a common, central place: your version control system.		With a VCS, everybody on the team is able to work absolutely freely - on any file at any time. The VCS will later allow you to merge all the changes into a common version. There's no question where the latest version of a file or the whole project is. It's in a common, central place: your version control system.

	Other benefits of using a VCS are even independent of working in a team or on your own.		Other benefits of using a VCS are even independent of working in a team or on your own.

	Storing Versions (Properly)		Storing Versions (Properly)

	Saving a version of your project after making changes is an essential habit. But without a VCS, this becomes tedious and confusing very quickly:		Saving a version of your project after making changes is an essential habit. But without a VCS, this becomes tedious and confusing very quickly:

	How much do you save? Only the changed files or the complete project? In the first case, you'll have a hard time viewing the complete project at any point in time - in the latter case, you'll have huge amounts of unnecessary data lying on your hard drive.		How much do you save? Only the changed files or the complete project? In the first case, you'll have a hard time viewing the complete project at any point in time - in the latter case, you'll have huge amounts of unnecessary data lying on your hard drive.
	How do you name these versions? If you're a very organized person, you might be able to stick to an actually comprehensible naming scheme (if you're happy with "acme-inc-redesign-2013-11-12-v23"). However, as soon as it comes to variants (say, you need to prepare one version with the header area and one without it), chances are good you'll eventually lose track.		How do you name these versions? If you're a very organized person, you might be able to stick to an actually comprehensible naming scheme (if you're happy with "acme-inc-redesign-2013-11-12-v23"). However, as soon as it comes to variants (say, you need to prepare one version with the header area and one without it), chances are good you'll eventually lose track.
	The most important question, however, is probably this one: How do you know what exactly is different in these versions? Very few people actually take the time to carefully document each important change and include this in a README file in the project folder.		The most important question, however, is probably this one: How do you know what exactly is different in these versions? Very few people actually take the time to carefully document each important change and include this in a README file in the project folder.
Line 945:		Line 945:
	Restoring Previous Versions		Restoring Previous Versions

	Being able to restore older versions of a file (or even the whole project) effectively means one thing: you can't mess up! If the changes you've made lately prove to be garbage, you can simply undo them in a few clicks. Knowing this should make you a lot more relaxed when working on important bits of a project.		Being able to restore older versions of a file (or even the whole project) effectively means one thing: you can't mess up! If the changes you've made lately prove to be garbage, you can simply undo them in a few clicks. Knowing this should make you a lot more relaxed when working on important bits of a project.

	Understanding What Happened		Understanding What Happened

	Every time you save a new version of your project, your VCS requires you to provide a short description of what was changed. Additionally (if it's a code / text file), you can see what exactly was changed in the file's content. This helps you understand how your project evolved between versions.		Every time you save a new version of your project, your VCS requires you to provide a short description of what was changed. Additionally (if it's a code / text file), you can see what exactly was changed in the file's content. This helps you understand how your project evolved between versions.

	Backup		Backup

	A side-effect of using a distributed VCS like Git is that it can act as a backup; every team member has a full-blown version of the project on his disk - including the project's complete history. Should your beloved central server break down (and your backup drives fail), all you need for recovery is one of your teammates' local Git repository.		A side-effect of using a distributed VCS like Git is that it can act as a backup; every team member has a full-blown version of the project on his disk - including the project's complete history. Should your beloved central server break down (and your backup drives fail), all you need for recovery is one of your teammates' local Git repository.

	===What would you store in a version control system?===		===What would you store in a version control system?===