Marking of COMP assignments (1 Viewer)

[§eraphim]

I submitted my assignment and I don't understand the error output from the putty window.

It says:

"Running submission through simple test...

Compiling your program...
gcc -g -Wall -c -o rcolour.o rcolour.c
gcc -g -Wall -c -o rescode.o rescode.c
rescode.c: In function `res_show_value_bands':
rescode.c:176: warning: implicit declaration of function `trunc'
gcc -g -Wall -o rcolour rcolour.o rescode.o -lm

Your submission compiled successfully.

Testing your program...
1,3c1,3
< yellow
< black
< green
---
> blue grey yellow
> brown black black
> brown red green

Your submission did not pass a simple test.

If you wish you may proceed to submit but it would be better
if you correct this problem and re-submit in order to receive
marks from the automatic testing.

Submission test failed. Continue with submission (y/n)? "

What do the numbers:
1,3c1,3
< yellow
< black
< green


...mean?

 

[underthesun]

1,3c1,3
< yellow
< black
< green
---
> blue grey yellow
> brown black black
> brown red green

That whole thing is an output from a diff command, which is used to find differences between two files. Most likely one output is yours and the other one is the "expected" output. While I don't use diff much, the 1,3c1,3 I think means lines 1-3 was different with the other version's line 1-3.

http://en.wikipedia.org/wiki/Diff

basically means your output isn't correct, or the auto-tester didnt like it

 

[§eraphim]

THat (the diff shell script) isn't very helpful...anyway after fixing it up it passed the dryrun. Does that mean it works 100% of the time? Does the diff script input randomly generate values and errors to check for all scenarios?

Do you get 100% if it passes the dryrun test? If not, where can i dl a script to test it for all cases?

 

[kucing]

While I don't use diff much, the 1,3c1,3 I think means lines 1-3 was different with the other version's line 1-3.

That's right.

It means line 1-3 of the first file is different from line 1-3 on the second line. In other words, the first three lines are different.

THat (the diff shell script) isn't very helpful...anyway after fixing it up it passed the dryrun. Does that mean it works 100% of the time?

Yes. It will work 100% on that exact test case.

Does the diff script input randomly generate values and errors to check for all scenarios?

Diff is binary. And no, it doesn't generate any random numbers. The purpose of diff is to show the difference between a file and another one. It does not check for all scenarios, meaning that your assignment may still contain errors although the diff test doesn't say anything.

If you want to know how diff works, just create two text files with different content. Then do diff on them: diff [FILE1] [FILE2]

 

[gman03]

There is a script from comp2041 that allows you to automate test.

I have GZIPPED the files that you would needed... To use it:

1. Put that file in your home folder
2. type "tar -zxf checking.tar.zip". This will unzip a folder name "checking"
3. "cd checking"
4. Here should have 6 files: check, testlist, test1.in, test1.out, test2.in, test2.out
5. To check your program, first compile your program into an executable, say "a.out"
6. Copy "a.out" to the "checking" folder
7. run "./check ./a.out <testlist", then you should see a list of tests and in the end telling you how many test passed
8 You can add more tests by:
a) making new input data and put it in a file, e.g. test4.in
b) use the reference program to make the expected output file
e.g. "ass1ref < test4.in > test4.out"
c) edit the "testlist" file and put a new line
"test4: % < test4.in"
d) repeat step 7

Have a look at the files (except for the check program) and you should able to figure out how to use the program in less than 4.3 minutes.

This is a sample "screendump" of what it should look like from putty:


wagner % tar -zxf checking.tar.zip
wagner % cd checking
wagner % cp ~cs1091/bin/ass1ref a.out
wagner % ./check ./a.out <testlist
Executing ... ./a.out < test1.in
=== Passed test "test1" ===
Executing ... ./a.out < test2.in
=== Passed test "test2" ===
=== Passed 2 out of 2 tests ===
wagner %


Have fun..


Disclaimer: the script program can only be used solely for UNSW student blah blah. I take no responsibily blah blah. Backup your code incase the program deletes your files!!!

 

[gman03]

THat (the diff shell script) isn't very helpful...anyway after fixing it up it passed the dryrun. Does that mean it works 100% of the time? Does the diff script input randomly generate values and errors to check for all scenarios?

Do you get 100% if it passes the dryrun test? If not, where can i dl a script to test it for all cases?

A word of advice:

Try to make your code such that gcc doesn't give any warnings or errors.... you might lose a mark there.

Diff don't generate random stuff. It is the job of the course admin that makes a set of inputs so that everyone is tested against the same set.

Passing the dryrun will not guarentee 100% working solution, however with that said, if your program doesn't compile ... oh boy!

 

[§eraphim]

thanks for automating the testing. i already tested it quite a lot for most error cases i could think. just a spelling error in the code produced an infinite loop.

 

[§eraphim]

what are you expected 2 write for the documentation?

Documentation (2 marks): fully identified authorship, usage and reference comment; appropriate description of each function and important variable; relevant statement-level commentary (not "add 1 to i"); clear and correct English.

 

[Affinity]

When you get something like

rescode.c: In function `res_show_value_bands':
rescode.c:176: warning: implicit declaration of function `trunc'

It usually means you actually made a mistake, such as the function you used is not defined at all.

 

[anti]

what are you expected 2 write for the documentation?

Documentation (2 marks): fully identified authorship, usage and reference comment; appropriate description of each function and important variable; relevant statement-level commentary (not "add 1 to i"); clear and correct English.

You don't actually have to write that much for documentation providing your code is clear enough.

Fully identified authorship, usage and reference: if you've used other peoples' code eg. you've googled it
Appropriate description of each function and important variable: explain briefly what the function does (not necessary if it's, say, 'increment from 1 to 10') .. and variables with possibly confusing names (ie. not i, j etc)
Relevant statement-level commentary: again you sometimes need a brief sentence to explain what a particular statement or call does ('call superdooperleetfunction to make the world explode')

 

[Affinity]

Rule of thumb: appropriate means that if you go back to your program one month later, you will be able to read it.