Resources and Information for CS 241e ISAs

This TWiki is for technical details only. Any other duty information can be found in Waterloo LEARN (D2L): CS Instructional Support Group -> Course Admin & Duties for ISAs.


Introduction

General Notes and Warnings

CS241e is an enriched version of CS241, but it's quite different from the standard version of the course. This TWiki focuses on the technical side of being an ISA, but if you haven't taken CS241e before, be sure to keep up with the material and stay ahead of students.

Since 2015, CS241e has been consistently taught by one instructor, Ondřej Lhoták. Much of the infrastructure for the course was created by Ondřej and he is always updating and improving it between terms. As such, the information on this TWiki can easily become outdated! Before running any of the scripts described on this TWiki page, you should read the source code and check that they actually do what you expect. If you notice any incorrect information on the TWiki, please update it.

Ondřej is familiar with Marmoset, and usually he will be the one responsible for creating and maintaining the Marmoset test setups, canonical solutions, and libraries. The ISA will generally not need to do much Marmoset setup. This TWiki page attempts to document all aspects of Marmoset setup for completeness, but this documentation could quickly become incorrect if Ondřej changes his workflow. In general, if there is an issue with the Marmoset scripts, notify Ondřej about it rather than trying to follow the methods on this page.

The Course Git Repository

In what follows, familiarity with the Git version control system is assumed. There is a brief introduction to Git in the Appendix.

CS241e currently uses a Git repository to store course material. The term "course material" encompasses:

  • All assignment-related code: the "handout code" given to students, the instructor's solutions, the Marmoset test cases, and the private libraries distributed with the handout code.
  • The course website. The repository is set up so that changes made to the course website in the repository, once pushed will be copied to the public_html directory on the course account and made immediately visible to students!
  • Lecture notes and past tutorial material.
The Git repository has a lot of folders. Here are the most important ones:
  • 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!
As an ISA, you'll probably only be modifying the contents of the 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.

Repository Build Script

In the root of the repository, there is a shell script called 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.

The Git Repository and IntelliJ

An interesting aspect of the course Git repository is that it actually doubles as an IntelliJ project! It works similarly to opening the handout code. Follow the instructions on https://www.student.cs.uwaterloo.ca/~cs241e/current/idea.shtml for opening the handout code in IntelliJ, but instead select the folder containing the Git repository. IntelliJ will create some project metadata files in the Git repository directory, but the repository is actually set up to ignore these extra files, so it shouldn't cause any problems.

This is mostly useful to the instructor for developing the handout code, but it can be a nice way to browse the repository as an ISA. Also, there is one great benefit of this functionality for ISAs: you can use it to run the Marmoset tests directly against student code! This is useful when a student complains about failing a test and has no idea why – you can narrow down the possible reasons by actually running the test case yourself, and give more pointed help.

The idea is to create a second copy of the repository. To test a student's code, download it as a ZIP file from Marmoset, then extract the 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.

Beginning of Term Tasks

Updating the Course Website

The course website is stored on the course account under the public_html directory. However, you should never edit this directory manually. Instead, you should modify the files under the web directory of the course Git repository. When you push your changes, the changes will automatically be copied above to the public_html directory. This means if you edit public_html manually, your changes will be overwritten next time someone pushes changes using Git!

At the start of the term, you should go through each page of the course website and update the pages as necessary. Some of the steps below might be already done for you by the instructor, the ISC, or the previous term's ISA.

  • Update any places where the term and year appears (e.g. "Fall 2019") to reflect the current term and year.
  • Update the "Piazza Link" on the sidebar to the one for the current term, after Piazza has been set up.
  • Update the “Assignment Info” page. There are a several things to look at here:
    • If the minimum version of Java required has changed, update the version number in the Java JDK link.
    • Update the version number in the IntelliJ link to the latest version.
    • Make sure the Java JDK link and IntelliJ link still point to the correct places (Oracle or Jetbrains might have changed their websites around).
    • Update the assignment skeleton code link once the instructor has prepared the skeleton code for the term.
    • Look over the Marmoset submission guide. If IntelliJ’s interface has significantly changed and the guide is no longer correct, update the guide.
    • At the bottom there is a mention of the version number of Scala in a file path. If a newer version of Scala is being used, update this number.
  • Look at the "!IntelliJ IDEA Setup" page. If IntelliJ’s interface has significantly changed since this page was written, you may need to update the setup guide.
  • Remove all links from the “Assignments” page and update the assignment deadlines to reflect the ones for the current term.
  • If this offering of the course has exams, update the “Exam Information” page with information about the current term’s midterm exam. Leave the section about the final exam on the page, but put “TBA” (To Be Announced) for the date, time and location. Comment out any irrelevant information (e.g., information about midterm remarking or midterm and final review sessions). If there are no exams, the "Exam Information" page can be removed.
  • Remove all links from the “Tutorials” page.
  • Update the “Personnel” page with information about the current term’s course staff. Update the page again once everyone’s office hours are determined (you can write “TBA” if they are not yet known).
  • On the “Resources” page, comment out the “Code from Lectures” section and anything else similar that shouldn't be there at the start of the term.

Course Email

The course email account is a Connect email account, cs241e@uwaterloo.ca. It does not have a password associated with it. In order to obtain access, the course ISC will ask the CSCF point-of-contact for the course to add the necessary course staff.

In some terms, the course instructor has asked to have the course ISA and IAs added to it, as well having an inbox rule set to forward all email to that account to everybody to ensure that nothing gets missed.

Updating the Google Calendar

The course website contains an embedded Google Calendar. The calendar needs to be updated to contain:

  • Lecture times
  • Tutorial times
  • Office hours
  • Assignment deadlines
  • Exam times
Furthermore, the calendar should be maintained throughout the term to reflect any changes to the above.

To update the calendar:

  1. Visit the course website and click the Google Calendar logo in the bottom right of the calendar.
    calendar.png
  2. Log into the course Google account.
    • Use the course email address cs241e@uwaterloo.ca to log in. (Even though it's a Google account, it's associated with the course email rather than a Gmail address.)
    • Ask the ISC if you don't know what the Google account password is. If the password doesn't work, use the "Forgot Your Password" option to reset it, and tell the ISC you have changed the password. Do not post the password on the TWiki.
  3. Add all the events to the Google Calendar.
    • If you aren't familiar with using Google Calendar, view the help page here. The main thing to know is that you can create "repeating events" that reoccur every week, which will be helpful for adding lectures, tutorials, and office hours to the calendar. Make sure that the "end date" is set appropriately when using repeating events.

Updating the Assignment Code HTML Viewer

The handout code can be viewed online at the following page: https://www.student.cs.uwaterloo.ca/~cs241e/current/scalasrc/A1.html.

Whenever the handout code is updated, the HTML version of the code needs to be updated accordingly. This is done using the mkcodehtml script under the scripts directory of the course Git repository.

Be careful with this script. In one past term, an ISA accidentally uploaded all the assignment solutions to the course website due to incorrect use of the script. The script has been updated since then to make this harder to accidentally do. Nonetheless, before running the script, you should look at the source code and make sure you understand exactly what files are going to be copied over to the course website. You might want to just leave this task up the instructor to be safe.

That being said, the script is straightforward to use. Make sure you have generated the "problem source code" by running sbt clean problems. Then change to the script directory and run ./mkcodehtml, and this will generate HTML files for the most recent versions of the problem source code and library source code and put them under the web directory. The script is written in Lisp, so you will probably need to run it on the Linux environment, unless you happen to have a Lisp interpreter installed or feel like installing one. Once the script finishes, you can push the changes to the course website.

Setting Up Piazza

The instructions under the "Set Up Piazza" header on the CompSci241ISADuties page should work for CS241e as well.

Setting Up Marmoset

Before you can begin setting up Marmoset, CSCF must create a Marmoset instance for your course, and you must be added with instructor privileges. Once this is done, when you log in to Marmoset, you should be presented with a screen where you can select from three accounts: "userid", "userid-canonical", and "userid-student". The first one, "userid", is the main account you will be using with instructor privileges. The second, "userid-canonical", is used internally by Marmoset, but there's basically no reason to ever log on to it. The third, "userid-student", is an account with the exact same privileges as a student. Instructor accounts can switch between "instructor view" and "student view", so this is not very useful, but there may be some times where you want to see exactly what a student sees.

After logging in with your "userid" account, you will need to click the "Instructor View" link on the top bar to get access to most instructor privileges.

Adding Students and Staff

Follow the instructions on MarmosetSummary under the "Adding users" header to batch-add students and to add other members of course staff. If asked whether or not to limit user ID length, you should choose to limit it to 8 characters in length.

Early on in the term, new students will be adding and dropping the course every day. You will need to keep adding students to Marmoset until the class roster stabilizes, or else newly added students will not be able to access Marmoset. The easiest way to do this is probably to just repeat the batch-add process once a day. The batch-add feature is smart enough to not create duplicate students. If a student contacts you saying they can't access Marmoset, you can use the feature for adding a single student to make sure they get added immediately.

Creating Marmoset Projects

A "project" on Marmoset refers to a dropbox of sorts where students can submit their code and have it automatically run against a set of test scripts. In CS241e, there is one project for each assignment (unlike ordinary CS241, which has one project for each assignment question).

Creating projects is pretty straightforward. At the bottom of the "Projects" table (which will be empty at the start of the term), click the "create new project" link and fill out the fields.

  • By convention, the "Project Number" and "Project Title" are set to be the exact same string. This allow scripts that work with Marmoset projects to refer to either one interchangeably. In CS241e, this string is usually just "AN" where N is the assignment number ("A1" for Assignment 1, "A2" for Assignment 2, "A11" for Assignment 11, etc.)
  • Fill in the on-time deadline and late deadline according to the late policy for the current term.
  • For "URL" you can put a link to the assignment page, but it's not really necessary.
  • The "description" is usually left blank.
  • Important! Change the "stack trace policy" to "the entire stack trace for Java or full output printed to stdout for C". With the default setting, tests will not show any output.
  • Everything else can be left as the default. The stuff related to "late penalties" can be ignored because late penalties are applied by a separate script.
  • This is not essential, but you might want to change the "canonical class account" to your account, to indicate that you are the one who set up the project.
  • Note that all of the Marmoset tests for all of the assignments are public tests.
This is all you should need to know about setting up Marmoset as an ISA. The Appendix of this TWiki page covers some of the finer details of how the Marmoset test scripts for CS241e are actually created, uploaded and executed.

Setting Up The Course Staff File

There is a special file in the course account that some scripts use to determine which user IDs are members of course staff. If this has not been set up for you by someone else, you should set it up. Follow the instructions on CompSci241ISADuties under the "Create Course Staff File For Current Term" header.

"During The Term" Tasks

Updating The Unofficial Marks

There is a page on the course website where students can check their "unofficial marks" for the course: https://www.student.cs.uwaterloo.ca/~cs241e/cgi-bin/displayMarks.py

The marks shown on this page are read from the file ~/marks/public-marks.txt stored on the course account. You will have to update this file throughout the term.

Some helpful scripts for this are stored under ~/marks/scratch. You will also make use of MarmSql for downloading the marks. Here is the process for updating the marks:

  1. Navigate to the ~/marks/scratch directory and run the following command:
    marm_sql -v -m AX
    Where X is the assignment number. The -v is optional; it makes marm_sql display a progress counter. If you just want to run it in the background with nothing printed to the screen, you can do:
    marm_sql -m AX &
    The & is Bash syntax for creating a job that runs in the background. You can do other things in the shell while the marks download, and you will get a message when the job finishes.
    Note that if the late policy for the course has changed in your term, you will need to modify marm_sql. Computation of late marks is done in marm_sql, not on Marmoset. The script is stored at ~/bin/marm_sql if you need to edit it.
  2. If there has been a midterm, and the grades are on Crowdmark, download the CSV file from Crowdmark and save it as midterm-crowdmark.csv. Then run:
    ./crowdmark.sh midterm-crowdmark.csv > midterm.csv
    This processes the Crowdmark file into an easier-to-handle format. If the midterm results aren't out yet or there is no midterm for the course, you can ignore this step.
  3. Run the command:
    ./combine.sh > public-marks.txt
    This will combine the files downloaded in Step 1, and the midterm marks from Step 2 (if applicable) into a single file formatted for use on the "unofficial marks" page. Look at the file and mark sure the marks look correct.
  4. When you're confident and ready to post the marks, run the command:
    cp public-marks.t ..
    Now the marks will be visible on the webpage!
There is a script in ~/marks/scratch called update.sh that does all of the above steps in sequence, including copying the final marks to the main marks directory so they will appear on the webpage. Run ./update.sh Number, where Number is a number like 1, 2, 10, etc. rather than an assignment name like A1, A2 or A10. This will update the marks for Assignments 1 through Number, so for example, ./update.sh 5 will update the marks for Assignments 1 through 5. It will also update the midterm marks if the midterm-crowdmark.csv file is present.

At the time of writing, CS241e only uses public tests on Marmoset. If the course ever starts using release or secret tests, be careful when updating the marks. Updating the marks for an assignment that is currently running can "leak" the results of release and secret tests to students. Wait until after the deadline to update the marks. Even if the course only uses public tests, it's probably good practice to wait until after the deadline to post marks for an assignment, rather than letting students see their "marks so far" on the unofficial marks page.

Running Moss To Check For Plagiarism

In Fall 2020 the instructor communicated that he wants to run MOSS more frequently on student submissions and as a result, several scripts were added to the course account. These scripts aim to filter out unnecessary files to reduce the number of files that are sent to MOSS and to try and reduce the number of matches to previous cases since students resubmit their entire code base each time.

Note that the previous archive files have been filtered already, so you shouldn't need to do this unless you need to download past Marmoset submissions again for some reason.

In preparation to run MOSS, we first filter the archives for each assignment and to simplify this, there is a script in /u/cs241e/bin called filter_archived_files (Note that once the filtered set of files is created, it should not need to be re-done each term unless the list of files required for the assignment change). The script copies over only the files that need to be modified for the given assignment for each student from the /u/cs241e/archives/[term#]/handin directory to a /u/cs241e/archives/[term#]/moss/[assignment]/sc directory for each of the specified terms. To run the script make sure the PAST_TERMS variable in filter_archived_files is updated, then:

  1. Navigate to /u/cs241e/archives in the course account.

  2. Run the following command:

    filter_archived_files Ax [archived_assignment]

    where "Ax" is the assignment that you are filtering for and the archived assignment is the archived assignment you wish to filter from.
    (Past term submissions will have the letter 'p' added to the project code name, so for example, A11 would be downloaded as pA11.zip. You'll need to create a handin directory in the archives directory under the appropriate term code with the name pA11, move the ZIP file there, and unzip it before running the script. Since you don't need to filter past term submissions, edit the PAST_TERMS variable to just contain the necessary term.

    Example usage: filter_archived_files A1 pa11)

This creates a directory for the given assignment in the /u/cs241e/archives/[term#]/moss directory. Now we are ready to run MOSS on the student submissions. In preparation to run MOSS, make sure the term 1,2 and 3 variables in moss241e.sh are updated, then:

  1. Navigate to /u/cs241e/handin in the course account.

  2. Download the submissions for the assignment that you want to check in this directory. Use MarmSql to do this easily
    (i.e. to download submissions to /u/cs241e/handin/A1, type: marm_sql -d A1).
    Make sure the assignment name that you pass to marm_sql matches a directory in /u/cs241e/archives/[term#]/moss otherwise moss241e.sh will not be able to find submissions from previous terms to compare with.

  3. Navigate to /u/cs241e/moss/Scripts and run the following command:

    ./moss241e.sh Ax

    Where "Ax" is the name of the folder storing the assignment submissions that you created in the previous step.

  4. When the script finishes, the results will be available in the /u/cs241/moss/Ax directory and there will be a subdirectory for each of the previous terms that the submissions were compared to. To view the results in a web browser you must edit the check_auth.php file located in /u/cs241e/public_html/moss to add the necessary redirection paths. The lines you should add to the moss_folder_paths array should follow the form of:

    ‘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]',

    For example, for A1 you would add:

    'A1' => '/u/cs241e/moss/A1/html_sc',
    'A1_1709' => '/u/cs241e/moss/A1/html_sc_1709',
    'A1_1809' => '/u/cs241e/moss/A1/html_sc_1809',
    'A1_1909' => '/u/cs241e/moss/A1/html_sc_1909',

Another script that was added in Fall 2020 was filter_moss_files located in /u/cs241e/bin. Although you may not need to directly use the script, it might be useful to know about it. The script filters out the submitted files for each student so that the number of files sent to Moss is reduced (Example usage: filter_moss_files A1-filter.txt A1). You will not need to directly call it as moss241e.sh has been updated to use it already. That is all for running MOSS on student assignment submissions.

Additional Scripts

There are two scripts that were added in Fall 2020 that you might find useful: marm_why and moss+archive+update (located in /u/cs241e/bin).

The first script is the same marm_why script from CS 246 but modified to work for this course. How it works is that given a student_id as well as the assignment, marm_why will create a directory called [student_id].[assignment] in /u/cs241e/localtest containing the test results from each Marmoset test as well as the submitted source code. The script basically mimics the instructor view on the Marmoset website minus the web interface. To run marm_why, 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

The second script is a script that runs several of the scripts mentioned above as well as some other things. This script was made purely to automate all the tasks that need to be done when we want to run MOSS and update marks on the course website. Like what the name of the script suggests, given an assignment number, moss+archive+update will do the following four things:

  1. Downloads the most recent assignment submissions from Marmoset
    (marm_sql -d Ax)

  2. Run MOSS on the submissions using moss241e.sh.

  3. Copy the MOSS results to the archives
    (from /u/cs241e/moss/Ax to /u/cs241e/archives/[CURRENT_TERM_#]/moss)

  4. Download the original assignment submissions from Marmoset into /u/cs241e/archives/[CURRENT_TERM_#]/handin

To run moss+archive+update, run the following command:

moss+archive+update assignment# [-v]
Options:
-v: Enables verbose mode

Remember to edit the check_auth.php file located in /u/cs241e/public_html/moss to add the necessary redirection paths to view the MOSS results in a web browser.
Please check the documentation on the script itself prior to using any of these.

"End Of Term" Tasks

Archiving Course Material

There is a directory that contains the archives for every term in /u/cs241e/archives. In CS 241e, each terms' archives consists of three things: the MOSS results for each assignment, the original student submissions for each assignment and the assignment pages for that term. The MOSS results can be found at /u/cs241e/moss and the assignment pages can be found at /u/cs241e/public_html/current but the original student submissions for each assignment must be downloaded again from Marmoset (using marm_sql -d). The reason why we redownload the submissions from Marmoset is that we want the entire student submission and not the ones in /u/cs241e/handin because those are now filtered and do not contain all the files.

To avoid copying all these files at the end of the term, it is best to copy the MOSS results from /u/cs241e/moss to /u/cs241e/archives/[CURRENT_TERM_#]/moss and also download the original submissions from Marmoset into /u/cs241e/archives/[CURRENT_TERM_#]/handin right after we run MOSS for each assignment. That way the archives are always up to date and at the end of the term, you only need to archive the assignment pages. To do this, make a directory called assignments in /u/cs241e/archives/[CURRENT_TERM_#] and copy all the assignment pages from /u/cs241e/public_html/current to your new assignments directory by running the following command in the assignments directory:

cp /u/cs241e/public_html/current/a*.html .

Updating The TWiki

  • If any information you read on the TWiki during this term was inaccurate or out of date, please update it.
  • If any of the explanations of how to do certain tasks were unclear, please rewrite them.
  • If there are any tasks requiring technical knowledge that you had to do throughout the term, and they aren't documented on this page, please add them.
  • If you think of a better way to organize the CS 241E section of the TWiki than having most of the information on this giant page, feel free to reorganize it.
  • If the assignments change and/or the number of marks per question change since the previous term you will probably need to update the scripts combine.sh as well as base.txt in /u/cs241e/marks/scratch.
  • If you made any modifications to any of the existing scripts documented on this page, please update the documentation on this page.
  • If you wrote any new scripts or tools for future ISAs to use, please add documentation for it on the TWiki explaining what they are and how to use them.
  • If you think of anything else that should be on this list of things to update, please add it.

Appendix

A Brief Overview Of Git

You will need a small amount of familiarity with the Git version control system to work as a CS241e ISA. Many Git tutorials jump quickly into subjects like branching, which are extremely important but not really necessary for CS241e. For this reason, we cover a small fragment of Git that should be sufficient for basic tasks like updating the course website.

A Git repository is a collection of files, together with metadata that tracks changes between different versions of the files. The 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.

Setting up Marmoset tests

Initial set-up steps, which only need to be done once.

  1. If you haven't previously set up a copy of the repository for yourself, create a sub-directory for yourself under /u/cs241e/u, using your UW userid as the directory name, and then clone a copy of the course repository underneath.
  2. Go to the 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/.
  3. Run 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).
For each project:
  1. Create the Marmoset project in Marmoset. See the previous section on creating a Marmoset project.
  2. Upload the test cases ZIP file for that particular assignment. You can find the test cases ZIP file in the sub-directory marmoset/target. For example, the file name will look something like: test-a1-2009.01-1831856a5f2ecf19d20130e9c84ef88ed739ab3c.jar
  3. Upload the "canonical" solution for that assignment as a ZIP file. You will need to create a ZIP file for this. There may be easier ways, but the simplest approach is to:
    1. Start with the provided student base case. Download it, and set up IntelliJ as described on the course website.
    2. Add in the solution code for that particular assignment. You can find the solutions in your copy of the repository under 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.
    3. Use 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.
    4. Upload that ZIP file to Marmoset as the "canonical" solution. Note that tests cannot be run until the solution is set up.
  4. Check with the instructor when the project should be made visible to the students, and when the results should be made available.
  5. The tests will need to be made active. To do this, click on the "assign points" link found in the "activate/inactivate" column of the "Testing setups" section of the project in Marmoset. Ensure that marks are assigned to each test (defaults to 1 point per test, which is what we want) and click the button labelled "Assign points, edit test-setup comment and activate test setup.

The workflow is to tweak the tests within IntelliJ IDEA in 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.

Topic attachments
I Attachment History Action Size Date Who Comment
PNGpng calendar.png r1 manage 4.0 K 2019-09-04 - 10:42 SylvieDavies  
Edit | Attach | Watch | Print version | History: r25 < r24 < r23 < r22 < r21 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r25 - 2022-09-23 - ClaraXi
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2022 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback