7 Additional Utilities
These are additional utilities that are useful in the context of a homework submission system.
7.1 Multiple-File Submissions
By default, the system is set up for submissions of single a single file, straight fom DrRacket using the handin-client. There is some limited support for multi-file submissions in handin-server/checker and in the handin-client. It is possible to submit multiple files, and have the system generate a single file that is the concatenation of all submission files (used only with text files). To set up multi-file submissions, do the following:
Add a :multi-file keyword in check:, and as a value, use the suffix that should be used for the single concatenated output file.
You can also add a :names-checker keyword–the value can be a regexp that all submitted files must follow (e.g., ".*[.]rkt$"), or a list of expected file names. Alternatively, it can be a 1-argument procedure that will receive the (sorted) list of submitted files and can throw an error if some files are missing or some files are forbidden.
Make sure that :create-text? is on if you want the contents of a multi-file submission to be unpacked and filenames checked.
In the "info.rkt" file of the handin-client you need to set enable-multifile-handin to #t, and adjust selection-default to patterns that are common to your course. (It can be a single pattern, or a list of them.)
On the server side, each submission is saved in a file called "raw", which contains all submitted files. In the "grading" directory, you will get a "text.<sfx>" file ("<sfx>" is the suffix that is used as a value for :multi-file) that contains all submitted files with clear separators. A possible confusion is that every submission is a complete set of files that overwrites any existing submission, whereas students may think that the server accumulates incoming files. To avoid such confusion, when a submission arrives an there is already an existing previous submission, the contents is compared, and if there are files that existed in the old submission but not in the new ones, the student will see a warning pop-up that allows aborting the submission.
On the client side, students will have an additional file-menu entry
for submitting multiple files, which pops up a dialog that can be used
to submit multiple files. In this dialog, students choose their
working directory, and the selection-default entry from the
"handin-client/info.rkt" file specifies a few patterns that
can be used to automatically select files. The dialog provides all
handin-related functionality that is available in DrRacket. For
further convenience, it can be used as a standalone application: in
the account management dialog, the Un/Install tab has a
button that will ask for a directory where it will create an
executable for the multi-file submission utility—
7.2 Auto-Updater
The handin-client has code that can be used for automatic updating of clients. This can be useful for courses where you distribute some additional functionality (collections, teachpacks, language-levels etc), and this functionality can change (or expected to change, for example, distributing per-homework teachpacks).
To enable this, uncomment the relevant part of the "info.rkt" file in the client code. It has the following three keys: enable-auto-update that turns this facility on, and version-filename and package-filename which are the expected file names of the version file and the ".plt" file relative to the course web address (the value of the web-address key). Also, include in your client collection a "version" file that contains a single number that is its version. Use a big integer that holds the time of this collection in a YYYYMMDDHHMM format.
When students install the client, every time DrRacket starts, it will automatically check the version from the web page (as specified by the web-address and version-filename keys), and if that contains a bigger number, it will offer the students to download and install the new version. So, every time you want to distribute a new version, you build a new ".plt" file that contains a new version file, then copy these version and ".plt" files to your web page, and students will be notified automatically. Note: to get this to work, you need to create your ".plt" file using mzc’s --replace flag, so it will be possible to overwrite existing files. (Also note that there is no way to delete files when a new ".plt" is installed.)
Another key, version-check-frequency, when set to a number N, will make the version check happen continuously in the background, once every N hours.