Source code is available from SVN: http://vero-layout.googlecode.com/svn/trunk/background/svg_cairo_example

Step 1: Download librsvgmm (C++ bindings for librsvg) from http://ftp.gnome.org/pub/GNOME/sources/librsvgmm/2.26/

Step 2: Unarchive the files and run “sudo ./configure && make && make install” to install the libraries.

Step 3: Run “sudo ldconfig” to update your shared library linking.

Step 4: Download the source code and run “make all” to build the projects. The source is small and self explanatory – a quick read through will be enough to show you how to use the bindings.

Step 5: Run the program (“./svg”). The program will load the tux.svg file and display it in a GTK window. Too easy!

Marking requirements 

• Test cases and meta data are explicitely registered. A hash? of the file is taken. If the file changes between now and when other tests are run then notify the user so that they can re-register it. Once registered, all test case info is retrieved from database rather than files, so that accidently modified files do not harm future marking.
• If test cases are re-registered then any marking that has already been done must be redone. Penalties must be preserved. Only the most recent submission within each resubmission category is marked. Multiple resubmissions are marked and the highest result is associated with the student. Files must be archived in order to ensure that the correct copy of the students code is marked. 
  (This has to be super easy. Changing a test case and ensuring good update results is critical).
• Marking can be haph-hazard 

1. Mark bulk of submissions when they arrive. 
2. Mark some other students code when he hands it in late without penalty. Mark the late submissions with penalties. 
3. Mark resubmissions (again in several batches).
4.  Remark a file for ONE STUDENT who has ALREADY SUBMITTED (but perhaps submitted the wrong copy) and CONFIRM before replacing their result. 
5. Do not let a student submit multiple times without confirmation from a tutor. 

• A system for  applying penalties for late submission and resubmission so that those penalties can be lifted by tutors. The penalty state must somehow? be mirrored on the live server without being killed by the development server.
• Mark assignments without any danger of hurting previous ones.
• Automatic database backup so I can stop using a development and live server. If assignments are re-marked several times due to faulty test cases it should be OK.

Graph of compilation times for 25 test cases per student, 200 students. First bar shows compilation against Boost Library which was an interesting experiment, and will be used in part in Automarker v3, but which I would never use again as the core testing method because exporting certain things (i.e. pass by pointer) is impossible.

Second option is compilation of the same code without boost. This still takes 1.2 hours which just isn’t practicle if you need to be able to remark an entire class often.

Third option is time taken if each file needs only be compiled once (3 minutes). This is a huge speed increase (25 x vs 5x for not using boost) so I’ll be concentrating my efforts on working on an efficient and automated way of determining code dependencies and compiling a file a minimum number of times.

One idea is to automatically decorate all the functions and classes in a file with dllspec instructions and then dynamically call them. If an error occurs then the student did not provide the method. This will obviously only work on windows. Unfortunately this won’t work with templates.

In fact, the only thing that will work with templates is injecting code directly into the students code before compiling.

Another idea is to start by compiling against all test cases and then if the students code does not compile, try compiling all 25 test cases seperately. To fit in a coherent system this would end with a single compilation against the N test cases which succesfully compiled before.  On average I would exepect 30% of students to submit incomplete solutions which would give a runtime of 25 minutes. Closer to acceptable but still not fantastic.

An ideal solution would identify exactly which test cases each student could compile against and only compile these ones. This would require:

1.  A way to identify what a given test method depends upon – this can get tricky for things like templates
2. A way to identify what the student has implemented. Could use regex but this almost requires implementing an entire C++ parser because of the huge number of ways there are to implement a function etc. For example, given a constructor, they may have declared it inline or outline. If the latter, you have to find both a prototype and implementation. I’m sure there are worse scenarios.

Untested.

int answer = 0;

for (int i = 0; i != 1000000000; ) {
    answer = ((answer + i++) * 10);
    //answer += i
    //answer *= 2;
    //answer = answer % 65535;
}

Beware memory allocation:

• delete takes longer than new.
• BUT memory leaks slow your program execution exponentially as your memory becomes fragmented

Beware non-trivial operators:

• Using modulo slowed execution by an ENTIRE ORDER OF MAGNITUDE.

Beware data types:

• I used long long for answer instead of int because some of my code demands the use of large integers. This also slowed execution by an order of magnitude, presumably because it was compiled in 32 bit mode and had to do multiple register copies for every operation.
• I’ll be reviewing my requirements to try and remove dependency on long long in time critical code!