Re: install_problem_grader redefined

by Dick Lane -
Number of replies: 0
I think Brian has identified an important culprit.

For my classes, problemRandomize is invoked via my which offers a "Get new version" button only after either (a) complete success before due-date or (b) after due-date [and never changes scoring for a student's performance which is always based on their original version].

About 40% of my recent server errors, e.g., 406 items reported by 
        tail -1000 error.log | fgrep install_problem | wc
(done in /var/log/apache2) may be attributable to this.

Is some change needed so that problemRandomize will "play nicely with friends"?

It might be useful to augment existing documentation to clarify the scope of problemRandomize.  E.g., it's fairly clear that it will not modify custom error-checking, but which standard checkers are also immune to being re-randomized?  More subtly, are there standard checkers which can be re-randomized but with non-obvious side-effects?