Forum archive 2000-2006

Zbigniew Fiedorowicz - Bug(s) in version 1.9

by Arnold Pizer -
Number of replies: 0
 Bug(s) in version 1.9 topic started 8/9/2003; 9:22:09 AMlast post 9/8/2003; 10:46:45 AM
 Zbigniew Fiedorowicz - Bug(s) in version 1.9  8/9/2003; 9:22:09 AM (reads: 2005, responses: 6) I have confirmed that install_problem_grader() is broken in version 1.9. Here is a quick and dirty fix. Replace the linePG_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 |>

 Zbigniew Fiedorowicz - Re: Bug(s) in version 1.9  8/9/2003; 10:02:39 AM (reads: 2330, responses: 0) It seems that PG_restricted_eval() (in PGtranslator.pm) is seriously broken. Here's what a few experiments reveal:  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 |>  Zbigniew Fiedorowicz - Re: Bug(s) in version 1.9 8/9/2003; 11:33:06 AM (reads: 2333, responses: 1) Here's a further update. Fortunately PG_restricted_eval() seems not to be the culprit. Rather the problem seems to be due to the misuse of this routine in install_problem_grader(). PG_restricted_eval() requires that all variables mentioned in its argument be defined in the package "main". In the case of install_problem_grader(), a local pointer (not defined in main) to executable code is being passed to PG_restricted_eval(), so it doesn't work. It looks like the other calls to PG_restricted_eval() are probably OK, so the fix I posted in the first message should fix the problem for now. Zig <| Post or View Comments |>  Zbigniew Fiedorowicz - Re: Bug(s) in version 1.9 8/9/2003; 2:08:38 PM (reads: 2338, responses: 0) There seem to be some other suspicious calls of PG_restricted_eval() in PGbasicmacros.pl, for instance in NAMED_ANS_RULE:  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 |>  Michael Gage - Re: Bug(s) in version 1.9 8/11/2003; 12:11:21 AM (reads: 2689, responses: 0) Literal strings passed to PG_restricted_eval() which contain locally defined constants will have trouble: my$foo=1;PG_restricted_eval(q!$foo == 0!); will not be able to evaluate$foo inside the PG_restricted_eval subroutine, since there is no local variable named foo there. 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 |>

 Zbigniew Fiedorowicz - Re: Bug(s) in version 1.9  8/11/2003; 7:21:25 AM (reads: 2331, responses: 0) Hi Mike, 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 |>

 Zbigniew Fiedorowicz - Re: Bug(s) in version 1.9  9/8/2003; 10:46:45 AM (reads: 2256, responses: 0) Hi Mike, I've noticed you have made some fixes to these problems in PGanswermacros.pl in the CVS. However one of these fixes involves changing the definition of the function call of mail_answers_to2(), and you haven't made the corresponding changes in the problem set SampleQuestionnaires which uses this routine. Could you please document how to properly call the new version of mail_answers_to2()? BTW here are some additional small bug fixes: In profBuildProblemSetPage.pl, the regular expression: my @setHeaderFiles = grep /header.*.pg$/i, recursiveFindFiles($templateDirectory); selects header files with ".PG" suffix as well as ".pg". Change this to my @setHeaderFiles = grep /.pg$/,grep /header/i, recursiveFindFiles($templateDirectory); In profEditCourseFiles.pl the regular expression is garbled: @filenames = grep /.*header.*.pg$/i, recursiveFindFiles($currentDir); Change this to: @filenames = grep /.pg$/,grep /header/i, recursiveFindFiles($currentDir); Regards, Zig <| Post or View Comments |>