Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit

Important note

Programming in C is a very precise operation. A single typo can cause lots of issues that are hard to spot. Imagine dialling a phone number, if you get a single digit wrong, you won't get through to the right person. Think of C like that. One small mistake means it won't work. Make sure you follow all of the steps listed here, carefully. Skipping a step can easily mean your code doesn't work and you need to spend time figuring out what went wrong.

Introduction

The aim of Lab A is to get up and running with a C programming environment. This includes having version control on your code, and using the debugger. We won't be using a large number of programming concepts yet. Rather, the aim is to make sure that you have the tools up and running, whether using a personal device or a University computer, so that you can then move on to writing more C programs in future labs.

In general, we don't use a single tool, we use multiple ones (e.g. VSCode, gcc, git), which have to talk to one another. This means there are quite a lot of things to get set up. It also means that settings can be quite important, and if these aren't correct your programming environment may not work even if everything is installed. It's not uncommon that they don't work first time. In the lab session, you can use the demonstrators to help identify and fix any issues in your personal set up. Once the tools are correctly configured for your computer and/or account, they should then be fairly robust.

The following pages give you a number of exercises to work through. Some of these are tutorial style, showing you what to do, step-by-step, to build familiarity with the tools and processes. Others are problem style, where you need to figure out the solution. This may involve experimenting with a few options, going back to read the main notes or doing wider reading, or otherwise being creative to devise a working solution. They are deliberately more open-ended, rather than prescribing exactly what to do.

At the end there is a task which asks you to upload some code. We will compile and run this code, and give feedback if it doesn't work. There is one 'mark' associated with this lab for uploading suitable code. See the unit delivery plan for deadlines.

There's quite a lot to do in Lab A, to get everything set up an running. Following the unit delivery plan, you should anticipate doing some of the tasks as independent work rather than in the timetabled lab session. You can always keep going into the second timetabled lab session (i.e. the one for Lab B) if you'd like to.

1. Compiling Hello World

1.First, decide whether you will complete the labs using a personal device or a University computer. We will support either. (It should be possible to successfully complete the labs on the vast majority of personal laptop-type devices, although there may be the rare instance where we can't get this to work.)

Next, install or setup VSCode following the instructions below.

i. If using a personal device, follow the instructions given in Topic 2 on how to install the VSCode environment and associated tools. Then skip to Step 2 below. Make sure you follow all of the steps given on the websites in Topic 2. In our experience, it's common that people forget the step adding gcc to the Windows path. If you have any issues or your setup doesn't work, ask a demonstrator to help you.

Important note 0: If using a mac, make sure you have the Code Runner extension installed.

·On a mac, once Code Runner is installed, open "File" / "Settings" and search for setting "Code-runner: Run code in terminal". Make sure this is ticked.

·Without this setting, when you press the "Run" button in VSCode, your code will be compiled, but not actually run. You thus won't see any output from your code, as it hasn't been executed. The code-runner extension should make the code automatically run after it has been compiled, so that you don't need to run the code by hand.

·Ask a demonstrator if you'd like to know how to manually get your code to run.

ii. If using a University computer, log in, and start VSCode from the Start menu.

Important note 1: On a University computer you must start VSCode via the Start menu. This runs some customisations when VSCode starts in order to get things to work correctly. If you double click on a file to open it, and this launches VSCode for you, the University customisations may not have run and VSCode may not work correctly. On a University computer, you need to use the Start menu every time you start VSCode.

Important note 2: When VSCode starts, or possibly when you add a folder/file for the first time, you may get a warning message like the below. There are two variants, and you may get one or both:

(The location given, nask.man.ac.uk or C:\ will vary depending on where your files are located.) These are security warnings. By default, VSCode doesn't trust the University fileservers. Programming in C allows to you write arbitrary code. That is, you can ask the computer to do anything (within reason, and the permissions you have). You, and VSCode, thus need to be very careful about which files and folders are trusted and allowed to run code, as malicious files/folders may contain viruses or similar. Files on P:\, or nask.man.ac.uk, or on the University of Manchester provided Onedrive should be OK to trust, but always use suitable due diligence and think about which locations you are trusting.

Select "Yes" and/or "Yes, I trust the authors".

Important note 3: In Step 2 below you are asked to open the folder where your code is kept, or is to be kept. You must select this folder via "This PC" and then the P drive, as shown in the figure below. Inside the P drive, you can put your code files wherever you would like. (On a University computer, don't store your files on the C drive, or elsewhere.) On a University computer, for technical reasons, VSCode won't work if you select the P drive via a different route. This includes, for example, selecting "Documents" in the figure below. This icon is actually a shortcut to the Documents folder on your P drive, but the setup doesn't detect this. Remember that your P drive is a network drive, and so is automatically backed up and will be available on all University computers when you log in. You can access your P drive outside of the University at https://pdrives.manchester.ac.uk/horde/login.php.

Important note 4: On a University computer, you may find that cmd is selected as the terminal by default. This is an older command prompt in Windows. It can be made to work, but has some issues when accessing network drives. We'll use the more modern PowerShell, which may necessitate changing a setting in the University setup. Whether this needs doing varies on a computer-by-computer basis, so it's best to check each time.

In VSCode, to go: "File" / "Preferences" / "Settings" in the top menu bar. In the settings window, search for "terminal" (without the quotes). There is a setting "Terminal Integrated Default Profile: Windows". Change this to be PowerShell or Windows PowerShell. Either is fine. See below for a picture.

If all of the above steps have been done correctly, the terminal in VSCode should read:

PS P:\Desktop\lab_a>

(Assuming this is where you chose to put your files.) PS shows that this is a PowerShell terminal. P:\ shows that VSCode is correctly storing files on the P drive.

2. Start VSCode. You should have the VSCode welcome screen displayed, as shown below. Select "Open Folder…" and select the folder where you would like to store your files. (If the Welcome screen is not displayed, or you have closed it, you can also select "Open Folder…" under the "File" menu.)

·On a University computer: You should store your files on your P:\ drive. See the notes in Step 1 above.

·On a personal computer: You should store your files in your University provided Onedrive, so that the files are backed up, and can be accessed from anywhere.

We suggesting putting the lab A files in a folder called "lab_a", but you can use another name if you wish.

VSCode will then put all of the files, and some settings, associated with your program in this folder. (In turn, we can then have different settings for different folders.)

3.To start coding, select "New File…". (You can do this from the "File" menu if you prefer, or if the Welcome screen is no longer displayed).

Enter a filename "hello_world.c". You don't need to include the "". Make sure you do include the .c. VSCode won't pick up the correct settings without the .c being present. Press enter to save the file.

4.You will now have a code editor tab open, which will let you enter code into your hello_world.c file. This is shown below.

Use the code from the Topic 2 Hello World example to write a program which displays "Hello World" (without the quotes) to the VSCode terminal. You can just copy and paste the code from that example, no modifications are required. That said, to help you get familiar with VSCode, we suggest that you re-type in the code rather than actually copy and pasting. This will help you get used to entering C code, and seeing the auto-complete, and other helper functions built-in to VSCode in action.

Your file will look something like that shown below.

5. Press the "Run" button, which looks like a play icon. This will both compile and execute your code. You can have a number of different configurations set up within one VSCode environment, so your code can be compiled with different settings. Thus, when you press the run button the first time it will ask you to select a configuration to use. Select "C/C++: gcc.exe …" and it will select suitable default settings for you. You only need to select this once, and then it will keep it as the default choice until you change it.

Once you've selected a configuration, the compile will start. You may get some popups asking if you would like to change the settings/configuration for how the compiler runs. You can ignore these for now. You'll notice that a folder called .vscode has been created, with a file tasks.json. This is where VSCode keeps the compiler settings to use. Have a brief look at this file and the settings. You can edit these later on if you want more control over how the compiler runs.

If everything has worked, in the terminal you should see "Hello World" displayed, as shown below. Well done! Your code is now working. Regardless of whether your code works first time or not, keep reading below to see what to do when it doesn't work.

6. If your code hasn't compiled successfully, for whatever reason, you'll get a message like the below.

If your code above is working, try breaking it so that you get this message. For example delete the ; at the end of the printf line. That is, rather than

printf("Hello World");

have

printf("Hello World")

Statements in C have to terminate with a semicolon (;) and so deleting this means the code isn't valid and can't compile.

If you click "Show Errors", the "Problems" pane will be displayed and will give messages to help you fix your code. Follow these to fix your code. If you get stuck and can't make your code work, ask a demonstrator for help.

7. Once your code is working, and displaying "Hello World" to the terminal you've completed this part of the lab. Spend a little time exploring the VSCode interface to see the different options that are present. For example, see what is displayed in the terminal as your code is compiled. Or, explore the settings under "File" / "Preferences" / "Settings" that can be changed. Also, try modifying your code to display different things, such as your name.

8. When you're happy your code is displaying "Hello World", and you've got a basic familiarity with the VSCode interface and compiling a simple program, move on to Part 2 of the lab.

2. Version control in git

1.

Now that you have working code, it is time to check it in to our version control software. We're going to use software called git for this.

In VSCode, click on "Source Control" in the left hand menu bar, and then click on "Initialize Repository", as shown below.

This will make a local repository. This is a repository, only on the computer you're currently working on. A repository is where the multiple copies of your files are kept; different versions as you make edits, and add/remove features.

Don't confuse version control with automated backups. If your repository is only on your computer, and something happens to your computer (e.g. you lose your laptop) then all of your files and the version control will be gone too. In addition to having a local repository, we usually also have a remote repository, where the files are stored on a second computer somewhere. We'll see this in Part 3 of the lab.

Regardless of any version control considerations, in general, it is bad practice to store files only on your local hard drive or USB stick/hard drive where they can be easily lost. Use the University provided Onedrive, or the University's P drive, which automatically back up files.

2. At the moment (unless you've made more beyond the instructions given here) you should have 3 files in your code folder:

·hello_world.c which is the code you've written.

·hello_world.exe which is your executable code to actually run the program.

·tasks.json which was automatically generated to store your compiler settings.

Once a repository has been initialised, git will display a U for "Untracked" next to these 3 files. This means that you've done the initialization to turn git on, but you've not yet put a version of these files into the repository for them to be version controlled.

To ask git to track the files, right click on each file and select "Stage Changes". When done, rather than having a "U" next to them, there will be an "A". This shows that the files have been added to git for tracking. (Note that you also have the option to "Add to .gitignore". This lets you have files that git doesn't add to the version control, and also doesn't keep telling you that they're untracked. It can be useful for keeping confidential files in your local repository which you don't want pushed to a remote repository.)

Stage the changes for all 3 files.

3. Press the "Commit" button to add the files to your version control. This will be your first formally tracked version. It will give a base version which can then be edited.

If you've not done so already, git will ask you to set your name and email before it will let you do the commit. You do this in the terminal with the two commands:

> git config --global user.name "Alex Casson"

> git config --global user.email "[email protected]"

(First changing the details to your name and email!) Once you've entered these commands, press the Commit button again.

Git tries to force you to add a comment, explaining what the commit is. Add a useful comment in the file which gets displayed, or in the message box shown in the figure below. (Either is fine.) In large projects you may have many different versions that get committed, and the comment will help you tell them apart. Also, remember it may be other people who are using your code, and who need to tell which version is which, so make the comment meaningful. If entering your comments into a file (see below), once you've entered something, save the file and press the tick icon to complete the commit.

4.The commit is then complete. Various Git functions are then available in the VSCode interface, under the "…" in the "Source Control" pane. We won't explore all of these in this lab. Again, feel free to explore the options available, such as adding a "Tag" to your code.

5.Now let's modify your code. We're simulating continuing to work on a code file, after we've got an initial part of it working. We want to keep working on the same file, not having to manually make a copy of it.

Delete the current contents of your hello_world.c file so that you have a blank file. Copy and paste the code below in instead.

#include stdio.h>

int main(void

{

printf("Hello World")

return 0;

}

That is, this is the same basic program, but now with some mistakes in it! When you save the file, VSCode will add an "M" to show that the file has been modified, but the changes not yet committed to git.

Press the "Commit" button to add these changes as a new version to the version control system. VSCode may ask you to stage your changes again. You can do this, see Step 2 above, or just select "Always" in the dialogue that appears to have any changes automatically staged. For most projects we probably want all changes to be captured by default, and so it's fine to click "Always".

Complete the commit by adding a comment "Version 2 - not working yet", saving the file, and then pressing the tick button. (See Step 3 for a walkthrough if required.)

6.Try and compile the new code by pressing the "Run" button. The compile will fail, and if you click on "Show Errors" the "Problems" pane will list a number of issues.

7.Rather than fixing the code, we'll roll back to our previous, working, version. In the "Explorer" tab, click on the "Timeline" displayed at the bottom of the screen. This will show you the previous versions of your files (and the importance of giving a meaningful commit message so that you can tell which is which). Click on your first set of committed files. VSCode will display a locked version of these, with colour coding to show what's changed compared to the current version.

To revert the code to the previous commit, in the terminal enter the command:

> git revert HEAD

HEAD moves the code back one version in the version control system. It then triggers a new commit. That is, the previous (broken) code is still there if we wanted to look at it for some reason, but in the timeline there is a newer version, which is in fact a copy of the repository from the commit before last. It can be a little fiddley to get this working. Ask a demonstrator for help if you need it.

If you right click on a commit in the timeline (a circle with a line through it rather than just a circle) you can "Copy Commit ID" and use this ID in place of "HEAD" to move back to any earlier version of the code. This can be a bit painful to get to work in the VSCode GUI, as some changes can't be undone automatically and you have to manually "Merge" them. We'll let you explore this for yourself. You might like to install and explore the "GitLens" extension which provides a much better GUI interface for moving back to earlier versions.