** Using WeBWorK **

We just finished our spring semester and are now looking to update our Webwork system. We're currently running Webwork 2.01 + epsilon. I see that Webwork 2.1 is still the newest version. Is there a Webwork 2.2 release date in the near future or should we just update now to Webwork 2.1?

Thanks, Tom

<| Post or View Comments |>

Exams are now over (whew!) so we're ready to start thinking about plans for the summer.

We were not successful in obtaining a National Dissemination grant so activities this summer and next year will be modest. We still have a small amount of money left that will keep Sam Hathway available for programming activities and for consulting, but we don't expect to have any student programmers working for us. In general the WeBWorK improvements this summer will be from volunteer labor.

The current "HEAD" of the cvs at Rochester is quite stable (we've been running it on hosted.webwork.rochester.edu for 4 months now and have just switched our main server over to that code base). I would recommend that you update to that code base by checking it out of the cvs (see http://devel.webwork.rochester.edu/twiki/bin/view/Webwork/WeBWorKCVS for setup directions)

Once set up the cvs provides a very easy means to update to the latest version of webwork and also to backout of recent changes if for some reason they don't work on your system. To get the most current version of the cvs type

wwcvs update -A -d

Most files are update automatically, but the files in the lib/conf directory (which contain configuration data specific to your website) must be updated by hand. A good procedure is the following. Before doing an update make a copy of the distribution version of the config file, for example

cp global.conf.dist   global.conf.dist.save

Now do an update. The file global.conf.dist might be updated but your global.conf file will remain unchanged. Use

diff global.conf.dist global.conf.dist.save | more

to view the changes that have been made in the distribution files. You will want to make these same or similar changes in your global.conf file. Because the directory names may be different on your machine, these changes can't be done automatically.

If you have good editors for detecting differences in files you can also simply review the differences between the new global.conf.dist file and your global.conf in your editor and transfer the appropriate changes.

With the CVS updating to the latest version and backing out becomes a relatively simple operation that can be safely done in half an hour. Unless there has been a really major change -- for example one requiring new CPAN modules in the code base -- I routinely make these upgrades on machines that are running classes. I do keep an eye on the error log when doing so. :-)

For the first few weeks we will be making only minor changes to the code base. Fixing small bugs that have accumulated over the year (see http://bugs.webwork.rochester.edu/) and making minor improvements to the user interface. During this period it should be pretty safe to do an update command every morning as long as you are not actually running classes off webwork.

Once we have the easy changes consolidated we'll stamp the release as version 2.2 and you can check this out as a stable release using:

cvs update -r rel-2-2-patches

If you are running classes, you can get the last stable release as

cvs update -r rel-2-1-patches

Those who are in a position to check out the latest release (using cvs update -A -d ) are encouraged to do so and report any feature requests or bugs using the "report bugs" link in the upper left corner. This is a good time to try to get most of the little things fixed that have been annoying you or your students about WeBWorK.

After the first couple of weeks we'll work on some bigger projects, including

• speeding up the database calls.
• providing RQP compatibility for moodle (http://mantis.york.ac.uk/moodle/mod/forum/view.php?f=15)
• adding in the gateway quiz module that Gavin LaRose has been working on
• significant cleanup of the PG code, including integrating the new "smart objects" introduced by Davide Cervones with the original PG methods and answer evaluators.
• Other requests.

Another important goal for the summer is to collect as many problem sets as possible and make them publically available. This seems to me to be an important first step to providing a useful, searchable and edited database of PG problems. I'm not yet sure what the best way to organize, cleanup, categorize and edit the problems will be, but in order to get started I think it's useful for all involved to be aware of what other institutions have already done in order to avoid, as much as possible, duplication of effort.

We can provide CVS space for you, Tom, and anyone else using WeBWorK who would like to set up their own repository of problems. (see http://devel.webwork.rochester.edu/twiki/bin/view/Webwork/WeBWorKCVSCommitAccess for instructions and write me gage@math.rochester.edu to obtain login information.)

After that I'm open to suggestions as to what is the best way to organize the problem database organization and cleanup effort.

Take care,

Mike

<| Post or View Comments |>

I always found that maintaining global.conf was a bit of a pain, especially migrating changes from one version to the next. But it has been a lot easier since I made the following change. My global.conf is only two lines, which are:

     include "conf/global.conf.dist";
     include "conf/local.conf";

so that global.conf first loads the global.conf.dist file, then loads local.conf, in which I have placed only the changes local to my system. When global.conf.dist changes, I get the new stuff automatically, without having to reapply my local changes. It is also easy to see at a glance what has been changed for the local system. To create local.conf, I simply copied the lines that I was chaning from global.conf.dist, and edited them in local.conf.

Anyway, thought someone else might find it useful.

Davide

<| Post or View Comments |>

I would second you on the need to have a central repository for the Webwork problems to minimize duplication of effort. Beyond simply listing the problems, it would also be good to have some place where people can indicate what areas they are writing problems in. For example, Karen and I are working on Linear Algebra right now and we could indicate which areas of linear algebra we are working in. Anyone else thinking of writing problems could then see both our finished posted problems and what we're currently working on.

Along the same lines, I would think it would be very useful to have a general list of all macro routines written. One can order the list by their type or where they are mostly used (for example: vector rountines, or answer checkers). Up to now, I think it's been pretty easy to guess in which Rochester .pl file where a routine probably lived (if it existed), but now with Davide's Union macros and other macros being written, I think there's more of a need. In fact, today I was going to try to write an answer-evaluator macro to handle lists, but was very happy to see (by chance) that Davide had already written one.

I would be happy to help with both these projects.

Thanks, Tom

<| Post or View Comments |>

See details at List of PG macros

<| Post or View Comments |>

This indeed looks very tempting for handling configuration changes through WW releses, but I can't get this to work with WW 2.1.2 (not that I tried it with any other version). It looks like definitions in the second, reloaded conf file do not take effect. Any tricks here?

Sarunas

<| Post or View Comments |>

For example, my local.conf includes

    $pg_dir = "/WeBWorK/pg";
    $pg{directories}{root}   = "$pg_dir";
    $pg{directories}{lib}    = "$pg{directories}{root}/lib";
    $pg{directories}{macros} = "$pg{directories}{root}/macros";
    $pgRoot = $pg{directories}{root};

$pg{directories}{macrosPath} = [
".", # directory of currently running PG file
$courseDirs{macros},
$pg{directories}{macros},
];

since the last five things rely on the definition of $pg_dir, which I changed. In my case, these were the only dependencies that I had to worry about. Depending on what you changed, you might have to run down some more of them. I suspect (and hope) that this is what might be the problem for you.

Davide

<| Post or View Comments |>