I'm unable to save any problems from the problem library to any homework sets today. In the library itself if I "add" a question it tells me that it has been successfully added but when I return to the homework sets to check they remain empty. I've never had this problem before. I've tried using IE and Chrome and am having the same problem either way.

Changed the behavior of the exists() and delete() schema methods in all
schemas (and updated the docs) s.t. not all elements of @keyparts have
to be defined.

Changed WeBWorK::DB to allow undefined values to be passed instead of
IDs in delete* method calls, but only if the call was made from
WeBWorK::DB itself (to protect you from accidentally passing an
undefined value and clobbering your whole database).

Changed delete functions to be more efficient. For example,
deleteGlobalSet no longer has to say:

Links for other sets is now available. Links to other users is probably a bit
long. You can go back up to the top. Maybe eventually one could add links to
the statistics for the next and previous users.

There is an "edit this problem" link at the bottom of the error message which allows you to fix the
mistake. Perhaps the placement of this link isn't optimal, but it's not that bad. It's right at the end

Modified parseDateTime so that it handles time strings of the form
01/03/03 at 06:00am. The " at " retains compatibility with webwork 1.9
which is important for import and export. This fixes a bug introduced
when changing formatDateTime. #204 and #203 should be fixed by this.

In this file I added warning messages in distGlobalValues() which
check to make sure fields are defined. Hopefyully this is not
a huge time sync, but will help with debugging.

The number of incorrect attempts has to be greater than or equal to the
value of $showHints in order for the show Hints button to be shown.

There is still an opportunity for further cleanup involved in setting the
want/can/will/must values for the various options. (They are set in more than
one place -- perhaps the number of places where these values are modified can be

PG_restricted_eval
PG-answer_eval
PG_macro_file_eval ( a new version of PG_restricted eval I used for testing)

all use eval, but since they are called from within the Safe compartment the evaluations are
screened for forbidden codes. It appears that you can't prepend "use strict"; to these evaluations.

One possible solution for 5.8.0 would be to simply allow 'require' as a legal operator. That seems
rather dangerous to me however.

Only one $safe->reval($string) is used and this evaluates the problem string as well as any macros that
are loaded. We don't want 'use strict;' to apply to the problems themselves, just to the macros that the
problem calls.

This is fixed, but it was a weird problem. (thanks Sam for solving it.)

The permissions for ContentManager.pm made it unavailable to the webserver. As a result
a number of the commands for setting up a course couldn't be completed. The
error messages said nothing at all about not being able to read the ContentManager file.

The system now works on webwork, but we should think about how to make the warning message

clearer if one of the modules can't be included at run time.

P1

RESOLVED

normal

trunk (SVN)

WeBWorK 2

HELP ! -Problems with sql_single? (only occurs on webwork.math.rochester. so far.

This is fixed in ver 1.42 of PGanswermacros.pl and ver 1.72 of AnswerChecker.pm

It is still true that if the answers are exactly the same as strings instead of equivalent
then no warning message is given. This helps keep you from being able to
guess whether the answer is correct using preview. (Warning messages don't occur

for correct answers.)

P1

RESOLVED

normal

develop

PG

Problem in Value::cmp_compare -- no messages indicating a repeat entry show up

This code was badly-written to begin with -- it did work for every NONKEYFIELD in the set record, regardless of whether or not that field was to be shown in the table. As a side effect, even though ProblemSetList.pm doesn't do ANYTHING with problems_per_page, it needed to have a FIELD_PROPERTIES entry for it.

I rearranged the code so that it determines which fields are to be shown FIRST, and then only look at only those fields.

It seems this was fixed in HEAD by Gavin last month. I'm going to to a bunch of backporting today, so I'll make sure to backport this one.

Log Message:

Make sure that something gets passed to renderProblems() for the userSet
even when a global set is being edited and it isn't assigned to any
users. Gets rid of "odd number of elements in hash assignment" errors
in renderProblems. Because renderProblems plugs in a fake set if it
gets a false value in for the userSet, sending in appears to solve
the problem.

Description of Problem:
Webwork will let me log on, but when I click on the problem set it says the website can not display. It did this to me last night as well. I only have one problem left and it's due at 8 AM

Your second comment points out the issue that is actually at hand, here. The string "8.7e-5" is interpreted exactly as you say: the "e" in expressions like this is the number e, not exponential notation. (To get exponentiation, you must use a capital E.)

The reason this is what WeBWorK expects for your answer is because of the line

$ans = Compute("$p");

which first forces $p to be converted to a string, and then Compute() parses is as it would any student answer to obtain the resulting MathObject. Since Perl outputs exponential notation using a lower-case e, the resulting expression does not produce the number you expect it to.

There are two solutions:

1. Use

$ans = Real($p);

rather than Compute() to convert the Perl real $p into a MathObject Real without re-parsing it, or

2. Use

$ans = Compute(uc($p));

which will turn $p into a string and force it to upper case, making the "e" into an "E" that will be parsed as exponential notation.

Your second code segment works because the eval() method returns a math object, and it converts the perl $p to a MathObject Real without re-parsing, so you get the effect of Real($p) with a lot more overhead.

Note that when you use Compute(), the correct answer will be displayed as the string you passed to Compute() without further processing, so in your case, it would be "8.7e-5". If you want it to appear in a particular format, you would need to enter it in that format. Note that this is supposed to represent a valid answer as a student would type it, but "8.7 x 10^-5" is not such an answer. It would have to be "8.7 * 10^-5" for that.

(I think the new output routines for the latest version of WeBWorK uses a formatted correct answer rather than a string that the student could enter, but I'm not sure how that is generated).

I believe this was corrected in the NPL seven weeks ago. Can you check with your system administrator to update the problems on your server? If that doesn't resolve the problem please resubmit it or let me know (at <glarose@umich.edu>).

Thanks,

Gavin

P1

RESOLVED

critical

unspecified

Problem Libraries

Problem will not display to some students. I can reproduce this for these students on my computer.

I finally got the chance to look at it today, and I concur with the changes you have made in lines 403 and 418. Where it was originally:

$control = '&nbsp;';

I replaced with:

$control = $interactive;

$interactive being the value which holds the CGI link. This way, the links should still show up even if no corresponding input elements are generated. I'm not exactly sure how to generate a Gateway Quiz though -- could you email me how so I can test it?

I have svn committed my revisions, which I made on my devel server. Revision 7043.

- The label "incorrect" comes from checking whether value for the score
key for the answer result from the PG object returns 1 or not; here, it
doesn't, so it (correctly) labels the result as "incorrect."
- It looks as if the error in the "this answer is correct" labeling comes
from comparing the number of correct parts in the answer to the number
of answer blanks---incorrectly, of course. The number of correct parts
is obtained by taking $numCorrect = 0 and then incrementing with
$numCorrect += $answerScore > 0
(where $answerScore is the value for the PG object's score key). This
won't work here, as long as my memory that > associates more tightly
than += is correct.

I'm not sure why the > 0 test is in there. If I'm correct that we needn't
test for a positive result, it looks as if the bugfix is line 368 in the
file lib/WeBWorK/ContentGenerator/GatewayQuiz.pm, with the change of

$numCorrect += $answerScore > 0;

to

$numCorrect += $answerScore;

on the other hand, if there is some reason I'm not seeing why we have to
worry about the sign of the score,

2839
Students have the option to set "Show Past Answers" to yes or no. When students click on a homework question, this option appears in the left column on the bottom. Did the default value for this option change from "yes" to either "no" or nothing selected when we went to release/2.8? The default should be "yes" in order to be consistent with previous versions of webwork and with student expectations.

1. created homework set test_local_macros
2. Added one problem (the default blankproblem) which I renamed the path to settest_local_macros/includemacrofiles.pg
3. Added the file templates/macros/local_macros.pl

when creating a new user in WeBWorK from Moodle the email address of the
user is not transferred from Moodle to WeBWorK. This breaks the
"Email instructor" message since that message depends on the email field in
the user record to tell the instructor where to send the reply.

Steps to reproduce the problem:
1. have a new user register for a course in Moodle
2. Have them do the WeBWorK orientation assignment (this forces them to be placed in the WeBWorK user database
3. Observe the WeBWorK class list -- no email address is included in the field

Actual Results:

Expected Results:

How often does this happen?

Always in MTH142 -- I believe this happens in all cases.

Additional Information:

P2

NEW

normal

HEAD

wwassignment

email record is not transferred from Moodle to WeBWorK when creating a new user