** Using WeBWorK **

Replace the line

PG_restricted_eval(q!$main::PG_FLAGS{PROBLEM_GRADER_TO_USE} = $rf_problem_grader!);

by

$main::PG_FLAGS{PROBLEM_GRADER_TO_USE} = $rf_problem_grader;

This is probably not a good long term solution, as I presume that the PG_restricted_eval() is there for compatibility with WeBWorK modperl. Also since PG_restricted_eval() is used in many other places, there may be similar bugs elsewhere.

Zig

<| Post or View Comments |>

        my $test0 = 102;
        my $test1 = 1;
        my $test2 = 2;
        $test1 = PG_restricted_eval(q!$test0!);
        PG_restricted_eval(q!$test2 = $test0!);
        warn "test1=$test1   test2=$test2";

This results in $test1 becoming undefined and $test2 continuing to have its previous value 2. This would seem to indicate that WeBWorK 1.9 is seriously broken. I would not recommend using it until this problem is resolved.

This problem may depend on the operating system and/or the version of perl that is being used. For what it's worth, I'm using Redhat Linux 8.0 and perl v. 5.8.

Zig

<| Post or View Comments |>

Zig

<| Post or View Comments |>

      my @answers = @{ $answer_value};
      $answer_value = shift(@answers);  # use up the first answer
      PG_restricted_eval(q!$main::rh_sticky_answers{$name}=@answers;!);

However I haven't been able to trigger these calls from within any of my existing problems.

Zig

<| Post or View Comments |>

my $foo=1;
PG_restricted_eval(q!$foo == 0!);

The reason for requiring PG_restricted_eval() is technical, but important-- I'll try to give a short explanation:

One of the timing savings possible when using mod_perl is to cache compiled code so that it can be used in successive server responses, rather than recompiling the code for each response. In particular we are caching the code for the PGbasicmacros and PGanswermacros. This means that the code is compiled in one Safe compartment at the beginning, but run in a different Safe compartment with each response. Since main:: is an alias to the current Safe compartment, the "value" of main:: has to be calculated at runtime not at compile time in order to point to the right Safe compartment, hence the use of PG_restricted_eval to force runtime calculation. With cached code one can no longer assume that the Safe compartment in which the code is compiled and the Safe compartment in which the code is run will be the same.

There are a number of changes in PGbasicmacros, PGanswermacros and PG.pl which reflect this change. Probably we forgot to make sure that the global variable used in install_problem_grader() was properly defined in install_problem_grader. I'll look into it when I get back. (thanks for the heads up Zig). I think we either define the global variable in PG.pl or use a reference straight from PG_flags or rh_envir. I'm not sure without looking more closely.

Similar issues arise in dealing with the how the answer boxes are named, but I think we have those handled correctly for the most part. If they don't work one notices right away. Not all problems use instal_problem_grader() so it is less surprising that that bug slipped by us.

-- Mike

<| Post or View Comments |>

Here is the code for install_problem_grader():

sub install_problem_grader {
	my $rf_problem_grader =	shift;
	PG_restricted_eval(q!$main::PG_FLAGS{PROBLEM_GRADER_TO_USE} = $rf_problem_grader!);
}

The trouble with this is that $rf_problem_grader is a local variable which is undefined in the context of PG_restricted_eval(). I tried changing the q!....! to qq!...!, but that didn't work either.

The code I referred to in PGbasicmacros.pl, in NAMED_ANS_RULE(), is similar in nature:

      my @answers = @{ $answer_value};
      $answer_value = shift(@answers);  # use up the first answer
      PG_restricted_eval(q!$main::rh_sticky_answers{$name}=@answers;!);

Note that @answers is a local variable which is being passed to PG_restricted_eval(), as in install_problem_grader(). However this particular code occurs in conditional blocks which seem to be triggered only in rare circumstances.

Zig

<| Post or View Comments |>