代写COMP30023、C++编程设计代写

日期：2023-04-13 10:27

COMP30023: Introduction to projects

COMP30023 Head Tutors

March 24, 2023

1 Introduction

In this document, we will introduce how COMP30023 projects are structured, and outline how

you can make the most from the infrastructure which we provide.

Firstly, some attributes and expectations:

As per the handbook, there will be 2 projects weighted 15% each

Projects are to be completed individually

Submissions must be in written in C

Submissions must compile and run on COMP30023-provided VMs, and should produce

deterministic output

Submissions will be checked for plagiarism

2 Submission

The submission process may be slightly different to what you were used to. We expect:

Code to be submitted to your assigned Gitlab repository named comp30023-2023-project-

x in the subgroup with your username of the group comp30023-2023-projects on git-

lab.eng.unimelb.edu.au.

AND The full-40 digit SHA1 hash of your chosen commit to the relevant Project Assign-

ment on the LMS.

Failure to complete both successfully will result in mark deductions.

Upon submitting the hash, you should receive an automated comment indicating whether

your submission is valid/reachable on Gitlab. An example success message is: Taking commit

2e24d35658d1b552952d226f5362fa5863d09a3c from 2021-05-19T10:21:49Z, day 0.

Note that it acknowledges the hash which you submitted and the time of submission (given to

us by Canvas). From this, we calculate the day number: day 0 means that the submission is

on-time, day 1 means that it’s 1 day after the deadline, and so on.

We do not perform calculations on fractional days, and thus, it is up to you to consider whether

it’s worthwhile to make further submissions (if submitting late).

If you have an extension, please note that we will subtract your extension from this day number

when calculating your project mark.

1

3 Compilation

Unlike COMP20003 and COMP20007, we do not impose the usage of skeleton files or a particular

project structure (in terms of files/directories). You’re welcome to use either gcc or clang, and

anything in the C standard library (libc), and POSIX, provided it works on the VM, but

excluding calls to other libraries/services.

To ensure that your projects can be successfully tested, please make sure that there is a Makefile

at the root of your repository, which compiles the executable(s) defined in the specification to

the root of the repository also.

You’re welcome to write test cases and scripts (possibly in other languages) and use other build

systems during implementation. Feel free to keep these files for the final submission.

You can, but do not have to include copies of input files in your repository, as they will be

provided by the CI/marking environment.

Do not hard code file paths for test cases or files, or make assumptions about where your

executable will be launched from.

4 Testing

A breakdown of visible and hidden marks will be provided in project specifications.

We will endeavour to set up Gitlab Pipelines before the release of each project. The CI (Contin-

uous Integration) will allow you to test your code against visible cases and receive some limited

feedback before the submission deadline.

You can access the results of automated tests by following these steps:

1. Ensure that .gitlab-ci.yml is at the root of your repository.

After placing .gitlab-ci.yml at the root of your repository, every pushed commit should

trigger automated tests against your code.

2. After pushing a commit, you should see either a green tick mark, a blue pending progress

2

indicator, or a red cross to the right of the commit information.

Click this icon.

3. On the next screen, click the icon again, and access the test pipeline stage.

4. This will bring you to the very bottom of the test transcript for the latest commit.

Note that the marks shown in the results table of the transcript is indicative of marks you

will receive for visible test cases (and tasks). Please compare it with the number of possible

marks indicated in the specification.

The CI will fail (with a red cross) when any visible test case fails, and you may receive an email

about a failing pipeline from Gitlab.

We do not care about whether you use the CI when implementing your projects. However,

3

CI usage may be taken into account when considering extensions, plagiarism, and submission-

related issues.

Unless an error or alternative solution has been identified, in which case marks will be retroac-

tively awarded by re-testing all submissions, marks for automated components are final. There

will be no partial marks given for uncompilable or incorrect programs, nor ‘implementation

effort’.

Please note that when your submission fails in CI, it will likely fail the same way in the marking

environment. Debug your program on your VM in this case. Make sure that you’re happy

with what the CI reports.

5 Reading the Transcript

Here is an example transcript.

As it’s pretty straightforward, you may want to skip this section.

5.1 Header

The header should show that the test was executed on a COMP30023 runner, and the version

of the test script.

Running with gitlab-runner 15.9.1 (d540b510)

on admin-registry 2K4zH4xy, system ID: s_18ccc91b5924

...

$ /test.sh

COMP30023 2023 Project 1 Before Deadline Tests

v1, last modified 23/03/23

5.2 Commit Log

Next is the commit log. The top commit is the one that’s being tested.

Commit log:

8ec56c2f8ced6bbcabb6a946a24ef50d3f9d9278: Remove strip.

9544fc6320a3c26672147d31f8112c8e1315b90c: feat: -e optional parameter

5.3 Compilation

The compilation process will then be shown. If you’re missing marks for build quality, please

look to this section.

Common issues:

make clean is not implemented, or fails with non-zero status code

There are dirty files committed to the repository, or make clean is non-functional

Running make does not produce the required executable

Code files were marked with executable bit, use chmod -x to remove

4

make -B && make clean (output suppressed)

make clean

rm -f allocate process

make

gcc -c allocate.c -Wall -O2

gcc -c util.c -Wall -O2

gcc -o allocate allocate.o util.o -O2

OK -- ./allocate found. Copying to clean working directory.

5.4 Test case execution

Task 1 simple (0.5): Passed

Task 2 two processes (0.5): Passed

Each test will:

Come under a task in the marking criteria

Have a unique name (this will be reflect the names of sample test cases, if given)

Have a weight

Pass or fail

(Possibly) have diffs or error messages

5.5 Results table

Finally, there is the results table.

=============== START RESULTS TABLE ====================

Task 1: Shortest Job First 1.0

Task 2: Round Robin 1.5

Task 3: Best Fit Memory Allocation 1.5

Task 4: Controlling Real processes 1.5

Task 5: Performance statistics computation 1.0

Task 6: Build quality 1

Task 7: Quality of software practices #CODE_QUALITY#

Project 1 (Total): #TOTAL_MARKS#

================ END RESULTS TABLE =====================

Rows with ## are manually marked or excluded from CI.

This may include reports, challenge tasks, code quality etc.

Additionally, note that hidden cases are not included in the CI. Marks indicated are for visible

cases only.

6 Conclusion

This concludes our brief introductory guide to COMP30023 projects.

Please let us know if you find any issues with our infrastructure and feel free to ask for clarifi-

cation on any confusing aspects.