WeBWorK Resources

Problem Library

Preliminary versions of the WeBWorK problem library is available here. The version people have been using until 7/26/05 is now dubbed version 1. By now everyone should be using version 2, so information on version 1 has been removed.

Version 2

The problems themselves are now kept in the cvs at Rochester. You should be able to get the files with:
```
  cvs -d :pserver:anoncvs@cvs.webwork.rochester.edu:/webwork/cvs/asu checkout database_problems
```
We recommend putting them someplace list /opt/ProblemLibrary.
Instructions

Dvipng infrastructure

This requires two things: the dvipng binary compiled for your system and preview.sty, a LaTeX style file. They can be downloaded from http://sourceforge.net/projects/preview-latex and http://sourceforge.net/projects/dvipng. Preview.sty is part of preview-latex. Both have configure scripts to ease installation.

If configure for preview-latex fails, you should be able to complete the process as follows.

Start in the main directory created by unpacking preview-latex. Then give the commands

  cd latex
  tex bootstrap.ins
  tex preview-mk.ins

That creates all of the files you need. Next you need to know where the texmf directory is on your system. I will assume it is /usr/share/texmf (since that is where it is on mine). Then as root,

  mkdir /usr/share/texmf/tex/latex/preview
  cp *.sty *.cfg *.def /usr/share/texmf/tex/latex/preview
  texhash

If texhash is not in root's path, find it and give the command with its full path.

Everything else you need is in the current version of WeBWorK. Just customize values in Global.pm.

WeBWorK Scripts

Here are a variety of scripts I use in administering our system.

clean-tmp: this is for deleting images, and any other temporary files, created by WeBWorK. It needs to know a top directory to start looking in, and a "delay time" in seconds. It then recursively searches down from the top directory looking for paths .../html/tmp. Each file below that combination is checked for the last time it was accessed. If the time is more than the preset "delay time", the file is deleted. The delay time and top directory can be set near the top of the file. I run this as a daily cron job. Under slackware, this requires putting the file in /etc/cron.daily.
log-loads: this logs the system load to a file. The path to the file is set inside the script. We run this as an hourly cron job. It makes it easier to monitor the system, and to answer questions like "was webwork slow or down at 3am last night?". Under slackware, I put it in /etc/cron.hourly.
parse-log: this is a companion to log-loads. Run it with one argument, namely the path to the log file, and it prints only the lines with "high" loads (greater than 2.1 for us).
buildProbSet: build a problem set from the command line. This is a slightly modified version of Bill Ziemer's script. You can give it two arguments, the course and the name of the set definition file, or just the set definition file. In the latter case it will try to deduce the right course based on the current directory. This works best from a templates directory. Then the script can guess the course and you can use tab-completion to get the spelling right of the set definition file. The location of cgi/cgi-scripts needs to be set at the top to match your system.
dandrprobset: analogous to the previous script, but it does a destroy and rebuild. It ignores course settings which don't "allow" destroy-and-rebuild. The location of cgi/cgi-scripts needs to be set at the top to match your system.
ins-string: this takes the name of a set definition file and a string as input. It then inserts the string at the beginning of the path for each problem file. Useful when moving from problem files which are "local" to a course, to ones which are in a common library.
cnt: there must be a basic utility for this, but I couldn't find it. It outputs positive integers, in order, with one per line. In other words, it counts. cnt 5 counts from 1 to 5. With two arguments, such as cnt 3 7, it counts from 3 to 7. I use it in shell loops. For example, to make 100 copies of a skeleton problem file for someone called p1.pg, p2.pg, etc., I use
```
  for j in `cnt 100` ; do cp skeleton.pg p${j}.pg ; done
```
Then, I make a set definition file, build the set, and the person has a big work area for writing problems.
getfilename: if someone says they like problem 37 of setManyProblems.def and you want to know the path to that file, you can get it with getfilename setManyProblems.def 37. In giving the name of the problem set, the initial "set" and the ending ".def" are optional.
showActive: adaptation of a standard WeBWorK script to show currently logged in users to run on the command line. The first argument is the name of the course. The second argument, if present, signals that it should only report the number of active users. The path to WeBWorK has to be set near the top of the script.
allShowActive: wrapper for calling the previous scripts on lots of courses. The course names are given on the command line. The output is the name of each course with the number of current users. As a bonus, it adds these numbers up for you. If all of your current courses are in the current directory, use allShowActive * to get an overview of system activity.
checktrees: do you have two copies of the same sets of problem files. Are you sure they are the same? Now you can check with checktrees path/to/first path/to/second. It will ignore set definition files, emacs backup files, and backup files of problems created by WeBWorK. It reports when files in the two trees differ, telling you which one is the newer one.

WeBWorK Library and Browser

This has been superceeded by the problem browser built into WeBWorK 2, and the problem library above.

Local Documentation

Anyone is welcome to read our local documentation for WeBWorK. Keep in mind that it is tuned to local needs in a few ways. It assumes one has local customizations discussed below, and it focuses on the things of particular interest to our effort.