** Using WeBWorK **

1) I have created my problem sets using the web interface with problems from the Rochester library. However, I cannot locate the set definition files at the command line. They are not in the templates directory. I have tried using eg "locate set7.def" but it doesn't show up anywhere. Any ideas? I would eventually like to be able to reuse the sets from semester to semester without recreating them every time.

2) Some of the displayed formulas appear in a gigantic font. This happens irregularly, but consistently, eg. the third formula on problem 3 will appear gigantic for all students. I don't see any flags in the code to predict when it will happen. (Not a big deal, but if there's an easy fix....)

3) None of my students is able to generate pdfs of the assignments. They get a message "you are not allowed to generate pdfs for others" or something. However with instructor permissions, I have no trouble getting the pdfs. Our system admin fellow posted recently about this problem- I guess it has to do with the apache installation? (I don't know anything about the guts of this stuff) Here's the link to his post: http://webhost.math.rochester.edu/webworkdocs/discuss/msgReader$3786

We are hoping to have a couple hundred students using webwork next semester.

Thanks a lot,

Andrew Knightly

<| Post or View Comments |>

I'm glad things are almost set up with your WeBWorK installation. I think I can help with a couple of your questions:

I have tried using eg "locate set7.def" but it doesn't show up anywhere.

The set definitions are now stored internally in the WeBWorK database and don't show up in files anywhere UNLESS you export them. To explicitly export a set you choose "Export selected sets" in the "Hmwk Sets Editor" -- you will be asked to define file names for the exported sets -- usually I use names such as set7.def, but you don't have to. This operation creates an ordinary text file (a "set definition file")of the kind familiar to those who used webwork 1.9. You can "import" this set definition file back into the WeBWorK database using the import function on the "Hmwk sets editor" page. The export/import feature is intended to allow you to transfer sets from one course to another, or to backup or archive a course.

Some of the displayed formulas appear in a gigantic font.

Chances are you have a few equations which were created while you were setting up the system -- and they were gigantic because you were still adjusting the dvipng parameters.

You need to flush the cache that saves these equations. You can do this by running the script ..../webwork2/bin/remove_stale_images. There are directions at the top of the script or type remove_stale_images --help

I'm not sure that I can help more with the last problem. It seems that match in AliasMatch is not matching, hence $1 and $2 are not defined. This has been reported before -- for example in

http://webhost.math.rochester.edu/webworkdocs/discuss/msgReader$2592#2595

The solution there required recompiling mod_perl. You can use the search function on this page with AliasMatch to get more help.

Hope this helps.

Take care,

Mike

<| Post or View Comments |>

Have you ruled out the possibility of #3 being a case problem? That bug apparently still exists in WeBWorK (or at least in ours, which was updated from CVS in late September) and causes these symptoms. That is, WeBWorK cheerfully and incorrectly allows user JoeCool to log in as joecool, and the only apparent symptom is that the user gets the message " You are not permitted to generate hardcopy for other users." Since some OS's don't enforce case distinctions, many students aren't sensitive to it. (They use x and X interchangeably on written work too!)

We're not getting any error messages about AliasMatch. Is this a separate bug from the one Mike alludes to, or am I looking for the wrong thing? I'm not getting any error messages when I provoke this problem.

Our solution BTW was just to make sure all user names were uniformly lower case. It still hits the occasional user who likes to keep the caps lock on, but since other things in WeBWorK won't work then, that problem is self-correcting.

Bob Byerly

<| Post or View Comments |>

Bob, I will look into it. In fact, my roster file has all user names in CAPS, so your solution sounds plausible. I will email the students and have them try it.

<EDIT: This worked! Thanks a lot! >

Mike, thanks for the info about exporting etc. I'll ask our tech guy to try flushing the old fonts.

I'll report back in case anyone cares what happens.

Much obliged, Andy

<| Post or View Comments |>

Regarding the font sizes, we flushed the cache but it didn't fix the problem. About 1/3 of the equations are still supersized. I created some new courses with the Rochester problem library stored locally in each one. The same equations are huge in each course. For example in setVectorCalculus3, every problem is huge- taking several screen widths. (This is the extreme case. Many sets just have an odd huge font here and there.)

Thanks a lot, Andrew

<| Post or View Comments |>

Does the jsMath display mode work correctly? If so I recommend that you keep digging away at the dvipng settings in WeBWorK/Constants.pm.

Don't forget to flush the cache frequently and also to use Shift Reload on your browser to make sure that you are getting the latest information.

Good luck. Let us know what happens.

-- Mike

<| Post or View Comments |>

Be sure to restart apache after changing settings in Constants.pm. Otherwise, some apache processes will still be using the old settings which can be very confusing for debugging.

After restarting apache, do the remove_stale_images --remove --days=0, and issue the command as superuser (so that you have permission to actually remove the files.

I hope that helps.

John

<| Post or View Comments |>

In regards to problem #3, record IDs (including user IDs) are case sensitive in HEAD since the middle of June. See webwork2/lib/WeBWorK/Utils/CourseManagement/sql.pm - view - 1.3.

However, the modifications only affect new courses with sql_single or sql databases, because it involves a change to the column types. Specifically, the types of the ID columns was changed from TEXT to BLOB.

If you have courses from before June, you can convert them to use BLOBs using MySQL ALTER TABLE statements. Given a course named COURSENAME using the sql_single database layout, the changes would go something like this:

ALTER TABLE `COURSENAME_key` CHANGE user_id user_id BLOB;
ALTER TABLE `COURSENAME_password` CHANGE user_id user_id BLOB;
ALTER TABLE `COURSENAME_permission` CHANGE user_id user_id BLOB;
ALTER TABLE `COURSENAME_problem` CHANGE set_id set_id BLOB, CHANGE problem_id problem_id INT;
ALTER TABLE `COURSENAME_set` CHANGE set_id set_id BLOB;
ALTER TABLE `COURSENAME_user` CHANGE user_id user_id BLOB;
ALTER TABLE `COURSENAME_problem_user` CHANGE user_id user_id BLOB, CHANGE set_id set_id BLOB, CHANGE problem_id problem_id INT;
ALTER TABLE `COURSENAME_set_user` CHANGE user_id user_id BLOB, CHANGE set_id set_id BLOB;

You might want to use a MySQL GUI like phpMyAdmin to make this change if you have one installed.

<| Post or View Comments |>