cs241e
course account.
Note: you'll primarily be accessing the account via SSH during the term.
sbt
) in order to run. These prerequisite installations should already be on the school's Linux environment. However, it is unlikely you will need to run these scripts yourself, so it may be more convenient to have the repository stored locally.
To clone the course Git repository: ~/.ssh/authorized_keys
in the course account.
git clone cs241e@linux.student.cs.uwaterloo.ca:private/cs241e.git
moss241e.sh
in the ~/moss/Scripts/
directory which is used to run MOSS on student submissions.
Read the documentation for the TERM#NUM
variables within the script and update them accordingly.
~/web/
directory of the course Git repository. Pushed changes will get copied automatically to the ~/public_html/
directory in the course account, where the website is built from. Note: do not edit website files in the course account directly – they will get overwritten after a Git push.
Things to update on the course website: personnel.shtml
. Leave office hours as “TBA” if not yet known.
exam.shtml
. Leave final exam information as “TBA.” Comment out extraneous information (e.g., past exam review sessions).
tutorialNotes.shtml
.
assignmentpost.shtml
and update their due dates.
idea.shtml
. Check the required JDK version, latest IDEA version, and update the pictures if the IDEA interface has changed a lot.
assignment.shtml
. Check all information mentioned above and the path for Marmoset submissions (will change if Scala version has changed).
~/README.txt
in the course account. Do not post the password on the TWiki.
sbt clean problems
./mkcodehtml
moss+archive+update
is doing.
Note: the script does not update $moss_folder_paths
in check_auth.php
, so that will still need to be done manually, as described in the next section.
The script is located at ~/bin/moss+archive+update
. To use it, run the following command:
moss+archive+update assignment# [-v] Options: -v: Enables verbose mode
~/handin/
. Run the following command to download student submissions from Marmoset for the given assignment. marm_sql -d Ax(This will download submissions to
~/handin/Ax/
.)~/moss/Scripts
and run the following command. ./moss241e.sh AxWhen the command finishes, the MOSS results will be in
~/moss/Ax/
and there will be a subdirectory for each of the previous terms that were compared against.$moss_folder_paths
in check_auth.php
(located in ~/web/moss/
on the course Git repository) to add the necessary redirection paths. The lines should follow the form:
'Ax' => '/u/cs241e/moss/Ax/html_sc', 'Ax_[term#1]' => '/u/cs241e/moss/Ax/html_sc_[term#1]', 'Ax_[term#2] => '/u/cs241e/moss/Ax/html_sc_[term#2]', 'Ax_[term#3]' => '/u/cs241e/moss/Ax/html_sc_[term#3]',
~/marks/public-marks.txt
, stored on the course account.
There is a relatively new script (Fall 2020) called update.sh
located in ~/marks/scratch/
which automates the process of updating the official marks.
To update the unofficial marks using update.sh
: ~/marks/scratch/
. Run the following command, where X
is a number rather than an assignment name (e.g., 1 vs A1). All marks from assignment 1 to X
will be updated. Midterm marks will be updated if the midterm-crowdmark.csv
file is present in ~/marks/scratch/
. ./update.sh X
update.sh
: ~/marks/scratch/
and run the following command. marm_sql -v -m AX
~/marks/scratch/
as midterm-crowdmark.csv
. Then run the following command. ./crowdmark.sh midterm-crowdmark.csv > midterm.csv
./combine.sh > public-marks.txt
cp public-marks.txt ..
~/bin/marm_sql
will need to be updated to reflect the changes in how grades are computed.
Note: if the assignments change and/or the number of marks per question have changed for the current term, ~/marks/scratch/combine.sh
and ~/marks/scratch/base.txt
will probably need to be updated.
Note: CS 241E typically uses only public tests on Marmoset. If release tests or secret tests are ever used, be careful to wait after the late deadline to update the unofficial marks, as updating the unofficial marks prematurely can leak the results of the release/secret tests to students. (It is good practice to wait until after the deadline to update unofficial marks even without release/secret tests anyway.)
~/archives/
. A single term's archive contains: ~/moss/
to ~/archives/[CURRENT_TERM]/moss/
.
~/archives/[CURRENT_TERM]/handin/
.
marm_sql -d Ax
assignments/
in ~/archives/[CURRENT_TERM]/
, navigate to it, and run the following command. cp ~/public_html/current/a*.html .
git clone
command allows you to create a local copy of the repository on your computer. You can then freely edit the files. The original repository, as well as other people's local copies, will not be affected. When you are satisfied with your changes, the git push
command allows you to upload your changes to the original repository. This uploading process doesn't permanently overwrite the files ? a history of versions is maintained using the aforementioned change-tracking metadata. Other users of the repository can use the git pull
command to download your changes to their local copy. Because a version history is maintained, if your changes are terrible, people can revert to an earlier version without your changes.
The above paragraph leaves out some steps. Git's change-tracking metadata isn't magic ? you need to tell Git which files it should care about. This is done using the git add
command. For example, git add important.txt
will tell Git that it should care about the file called important.txt
. Often you make changes to a lot of files at once, and using git add =on each one individually would be tedious. In this case, you can use the command =git add -A
to add all changed files. There are other options for git add
that may be useful in scenarios where you want to add some changed files, but leave others out. You may also find it useful to use a graphical user interface for Git such as SourceTree, which lets you choose which files to add visually.
Once you have added the changed files, you are still not done. You need to tell Git to finalize or "commit" the changes, so that the changes officially get recorded in the version history. This is done with the git commit
command. A commit generally includes a short but informative message describing what was changed. The git commit
command will open up a text editor in which you can write your commit message. After the commit is finished, you can finally use git push
to push your changes to the original repository.
A problem can occur if two people try to make different changes to the same file. A merge conflict occurs if you try to pull changes from the original repository that conflict with the changes in your local copy. Merge conflicts are less scary than many Git beginners think they are, but too scary to explain how to resolve in this little guide. Try to coordinate with other course staff to avoid merge conflicts altogether. If they occur, look for a tutorial on resolving them, or ask for help from someone more experienced with Git.
public_html
directory on the course account and made immediately visible to students!
assignments
– contains the base source code for both assignment problems and instructor's solutions. The problems and solutions are combined in a single file, and a build script is used to generate separate "problem source code" and "solution source code". The Marmoset tests for each assignment are also stored here under the test
subdirectory.
problems
– the "problem source code" generated by the build script is stored here. When you first clone the repository, this will be empty, and you must run the build script.
solutions
– the "solution source code" generated by the build script is stored here. When you first clone the repository, this will be empty, and you must run the build script.
library
– contains the source code for the libraries that are distributed to students as part of the handout code.
testutil
– contains some utility code used by the Marmoset tests.
documents
– the assignment specifications and questions are stored here as Markdown files. Past tutorials are also stored here.
lectures
– contains lecture notes.
marmoset
– contains scripts for constructing the Marmoset test setup and canonical solution files.
scripts
– likely intended to hold general scripts for use in the course, but currently just contains one script (which generates the HTML viewer for the handout code on the course website).
web
– contains the HTML source for the course website. Modifications made on your local copy of the repository will not be reflected on the course website. However, once you push your modifications to the original repository, the course website will be immediately updated with them!
web
folder. However, the other folders will certainly be useful to look at. You might want to peek at the solutions to get a better understanding of something, you might want to look at what certain Marmoset tests actually do, or you might want to look at the lecture notes to remind yourself of course concepts.
doall.sh
. This shell script runs a number of sbt
tasks (sbt
is a build tool for Scala) to generate the "problem" and "solution" source code, compile the handout code, run the Marmoset tests against the solutions to check them for correctness, and package the handout code. It also copies the current version of the handout code to the course website's HTML viewer.
You will need to have sbt
installed to use the script. If you are working on the school's Linux environment, it should be installed there, but if you are working from your own computer you might have to install it yourself.
The doall.sh
script will take a very long time to run because of the fact that it runs all the Marmoset tests. If you just want to generate the "problem" and "solution" source code, you can just run sbt clean problems solutions.
If doall.sh
fails, the problem might be differences in the version of Java or the version of some required dependency between your computer and the instructor's computer. Report the problem to the instructor.
src
directory from the ZIP file to the assignment directory of the copied repository. This will overwrite the assignment code with the student's solutions (which is why we make a copy of the repository). Then, you can run the Marmoset tests (under assignments/test
) and they will run against the student's code. When another student asks for help, just replace the previous student's code with the new student's code.
/u/cs241e/u
, using your UW userid as the directory name, and then clone a copy of the course repository underneath.
marmoset/
subdirectory. In there, there is a shell script mktests.sh
that creates the ZIP files (as .jar
files) to upload to Marmoset, using the testing .scala
files in assignments/test/src/cs241e/
.
mktests.sh
. Note that the line for assign in `seq 11` 6A 6B; do
in mktests.sh
is used to create tests for all 11 assignments thanks to the seq
command, and then splits the tests for assignment 6 into a 6A and a 6B (assignment was split due to the size for the online offerings of the course).
marmoset/target
. For example, the file name will look something like: test-a1-2009.01-1831856a5f2ecf19d20130e9c84ef88ed739ab3c.jar
solutions/src/cs241e/
. There is a .scala
file for each assignment, and you'll need to check the assignment to see which other files will also need modification. Replace all occurrences of "???" with the necessary code fragments.
sbt
to create the appropriate ZIP file. It's probably a good idea to rename it to include the assignment name in case you need to go back.
assignments/test/src/cs241e/
, run/debug/test them in IntelliJ, then when you're happy with them, run the mktests.sh
script and upload the .jar
file for the relevant assignment to Marmoset.
marm_why
is a modified version of the marm_why
script from CS 246. It basically mimics the instructor view on Marmoset, minus the web interface.
Given a student ID and assignment name, marm_why
creates a directory ~/localtest/[STUDENT_ID].[ASSIGNMENT_NAME]/
containing the test results from each Marmoset test as well as the submitted source code.
marm_why
is located at ~/bin/marm_why
. To use it, run the following command:
marm_why student_id assignment [-s sub_num] [-t test name] [-v] [-h] Options: -s sub_num: This allows the testing of specific submissions. sub_num should be the submission number seen on Marmoset. -t test: When testing marmoset submission, will only check the specified test instead of checking all of the tests for the submission. -v: Outputs details as the script runs. This can be useful if the script is slow. -h: Display long-form help message
filter_archived_files
will "filter" the files of archived student submissions for a given assignment, isolating the specific files that get modified in the course of completing that assignment. The purpose of this is to reduce the total number of files that MOSS checks, since students resubmit their whole codebase for each assignment.
More specifically, for a given assignment, the script will copy over the necessary files for each student from ~/archives/[TERM#]/handin/
to ~/archives/[TERM#]/moss/[ASSIGNMENT]/sc/
.
Note: there should typically be no need to run filter_archived_files
as, going forward, the archives will be filtered in this manner already. You should only need to run this script if the archives are somehow missing the filtered files or if assignment specifications have changed in your term.
filter_archived_files
is located at ~/bin/filter_archived_files
. To use it:
PAST_TERMS
variable within the script.
~/archives/
and run the following command. (Ax
refers to the name of the directory you want to create in ~/archives/[TERM#]/moss/
, while archived_assignment
refers to the directory name in ~/archives/[TERM#]/handin/
where the student source code is stored.) filter_archived_files Ax [archived_assignment]
filter_moss_files
is located at ~/bin/filter_moss_files
. It is used in moss241e.sh
to do the file-filtering process on student submissions from the current term. You should not need to run this script directly. I | Attachment | History | Action | Size | Date | Who | Comment |
---|---|---|---|---|---|---|---|
png | calendar.png | r1 | manage | 4.0 K | 2019-09-04 - 10:42 | SylvieDavies |