openwebwork-devel — WeBWorK development discussion

Re: [WWdevel] summary of $SIG{__DIE__} and $SIG{__WARN__} usage in Translator.pm

[Michael E. G. <ga...@ma...>]

On Jul 29, 2005, at 1:00 PM, Sam Hathaway wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Mike,
>
> Here is my assessment of what's going on with $SIG{__WARN__} and 
> $SIG{__DIE__} in Translator.pm.
>
> evaluate_modules() uses:
>
>     local $SIG{__DIE__} = "DEFAULT";
>
> to set the default handler for the duration of the subroutine. It then 
> goes onto use eval STRING to read in PG modules, and checks $@ for any 
> error messages. This is not harmful, and it saves us a little time 
> since the handler defined in Apache::WeBWorK would waste time 
> generating a backtrace before calling the default handler. (But see 
> below for why I think we should just let the Apache::WeBWorK handlers 
> run.)
>
> At the beginning of translate(), we see a few things:
>
>     # reset the error detection
>     $SIG{__WARN__} = sub {CORE::warn(@_) } unless ref($SIG{__WARN__}) 
> =~/CODE/;
>     my $save_SIG_warn_trap = $SIG{__WARN__};
>     #FIXME  -- this may not work with the xmlrpc access
>     # this formats the error message within the existing warn message.
>     $SIG{__WARN__} = sub 
> {&$save_SIG_warn_trap(PG_errorMessage('message',@_))};
>     #$SIG{__WARN__} = sub {CORE::warn(PG_errorMessage('message',@_))};
>     my $save_SIG_die_trap = $SIG{__DIE__};
>     $SIG{__DIE__} = sub {CORE::die(PG_errorMessage('traceback',@_))};
>
> This is a trouble spot, since it sets the handlers without using 
> "local". From what I can tell, what we WANT to do here is provide a 
> level of preprocessing to any warning or exception that comes out. We 
> may also want to avoid calling the Apache::WeBWorK warn/die handlers, 
> although I think we should leave them alone and assume our caller has 
> some way they want to collect errors and warnings. (For example, 
> WeBWorK::PG::Local has its own warn handler that accumulates warnings 
> and returns them as part of the WeBWorK::PG object.) It seems to me 
> that the simplest way to accomplish this is:
>
>     # reset the error detection
>     my $outer_sig_warn = $SIG{__WARN__};
>     local $SIG{__WARN__} = sub {
>         my $munged = PG_errorMessage('message', $_[0]);
>         ref $outer_sig_warn eq "CODE" ? &$outer_sig_warn($munged) : 
> warn $munged;
>     };
>     my $outer_sig_die = $SIG{__DIE__};
>     local $SIG{__DIE__} = sub {
>         my $munged = PG_errorMessage('traceback', $_[0]);
>         ref $outer_sig_die eq "CODE" ? &$outer_sig_die($munged) : die 
> $munged;
>     };
>
> This doesn't deal with the case where the handlers are set to string 
> names of subroutines, but that could be added. It also doesn't handle 
> "IGNORE", but that could be added as well.
>
OK.  I'd made this change also, omitting calling the outer DIE and WARN 
handlers.  I think your idea is better.
> in process_answers(), we have:
>
>     local %errorTable;
>     $SIG{__DIE__} = sub {
>         #
>         #  Get full traceback, but save it in local variable so that
>         #  we can add it later.  This is because some evaluators use
>         #  eval to trap errors and then report them in the message
>         #  column of the results table, and we don't want to include
>         #  the traceback there.
>         #
>         my $fullerror = PG_errorMessage('traceback',@_);
>         my ($error,$traceback) = split /\n/, $fullerror, 2;
>         $fullerror =~ s/\n   /<BR>&nbsp;&nbsp;&nbsp;/g; $fullerror =~ 
> s/\n/<BR>/g;
>         $error .= "\n";
>         $errorTable{$error} = $fullerror;
>         CORE::die($error);
>     };
>     # reset the error detection
>     my $save_SIG_warn_trap = $SIG{__WARN__};
>     $save_SIG_warn_trap = sub {CORE::warn @_} unless  
> ref($save_SIG_warn_trap) =~/CODE/;
>     $SIG{__WARN__} = sub 
> {&$save_SIG_warn_trap(PG_errorMessage('message',@_))};
>     my $save_SIG_die_trap = $SIG{__DIE__};
>
> and then later on, after the answers are evaluated:
>
>     $SIG{__DIE__} = $save_SIG_die_trap;
>     $SIG{__WARN__} = $save_SIG_warn_trap;
>
> First of all, restoring the die handler doesn't work at all, since 
> $save_SIG_die_trap is set to the custom die handler we just installed 
> a few lines before. In addition, I think we can do the same thing here 
> that we did up above, inserting the code that accumulates exceptions. 
> Also, I think %errorTable can be a lexical.
>
This is the error that was causing the immediate trouble in Hardcopy.pm 
(the generation of the ARRAY string, but no ARRAY reference).
>     # reset the error detection
>     my $outer_sig_warn = $SIG{__WARN__};
>     local $SIG{__WARN__} = sub {
>         my $munged = PG_errorMessage('message', $_[0]);
>         ref $outer_sig_warn eq "CODE" ? &$outer_sig_warn($munged) : 
> warn $munged;
>     };
>     my %errorTable;
>     my $outer_sig_die = $SIG{__DIE__};
>     local $SIG{__DIE__} = sub {
>         my $fullerror = PG_errorMessage('traceback', $_[0]);
>         my ($error,$traceback) = split /\n/, $fullerror, 2;
>         $fullerror =~ s/\n   /<BR>&nbsp;&nbsp;&nbsp;/g; $fullerror =~ 
> s/\n/<BR>/g;
>         $error .= "\n";
>         $errorTable{$error} = $fullerror;
>         ref $outer_sig_die eq "CODE" ? &$outer_sig_die($error) : die 
> $error;
>     };
>
The other thing I did in my fix was to move the definition of the WARN 
and DIE handlers outside of the for loop.  %errorTable can be
moved outside the loop to.  I think this works ok.  I'm still thinking 
about the role of %errorTable and whether it has to be localize
for each answer.  If necessary it could be emptied out at the top of 
each loop.

> There are three more places where warn/die handlers get messed with - 
> -- PG_restricted_eval(), PG_macro_file_eval(), and PG_answer_eval(). 
> In each case, subroutine begins with:
>
>     my $save_SIG_warn_trap = $SIG{__WARN__};
>     $SIG{__WARN__} = sub { CORE::die @_};
>     my $save_SIG_die_trap = $SIG{__DIE__};
>     $SIG{__DIE__}= sub {CORE::die @_};
>
> then some code gets passed to eval STRING, and then:
>
>     $SIG{__DIE__} = $save_SIG_die_trap;
>     $SIG{__WARN__} = $save_SIG_warn_trap;
>
> We can replace these with the same type of code that's used in 
> evaluate_modules():
>
>     local $SIG{__WARN__} = "DEFAULT";
>     local $SIG{__DIE__} = "DEFAULT";
>
Is there an advantage to calling "DEFAULT" instead of
local $SIG{__WARN__} = sub { CORE::die @_};

One of us should make these changes and check in a new version of 
Translator.pm
Then we can test and refine from there if needed.

Take care,

Mike

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
>
> iD8DBQFC6mDE14CQX+2WvVgRAmifAKCf2Mjte5IUWjE/FVINpt+CMZkeVwCePwGh
> 8EQzltAV6e4ObIZN8iRpLvU=
> =LagG
> -----END PGP SIGNATURE-----
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openwebwork-devel
>

[WWdevel] summary of $SIG{__DIE__} and $SIG{__WARN__} usage in Translator.pm

[Sam H. <sh...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mike,

Here is my assessment of what's going on with $SIG{__WARN__} and $SIG 
{__DIE__} in Translator.pm.

evaluate_modules() uses:

     local $SIG{__DIE__} = "DEFAULT";

to set the default handler for the duration of the subroutine. It  
then goes onto use eval STRING to read in PG modules, and checks $@  
for any error messages. This is not harmful, and it saves us a little  
time since the handler defined in Apache::WeBWorK would waste time  
generating a backtrace before calling the default handler. (But see  
below for why I think we should just let the Apache::WeBWorK handlers  
run.)

At the beginning of translate(), we see a few things:

     # reset the error detection
     $SIG{__WARN__} = sub {CORE::warn(@_) } unless ref($SIG 
{__WARN__}) =~/CODE/;
     my $save_SIG_warn_trap = $SIG{__WARN__};
     #FIXME  -- this may not work with the xmlrpc access
     # this formats the error message within the existing warn message.
     $SIG{__WARN__} = sub {&$save_SIG_warn_trap(PG_errorMessage 
('message',@_))};
     #$SIG{__WARN__} = sub {CORE::warn(PG_errorMessage('message',@_))};
     my $save_SIG_die_trap = $SIG{__DIE__};
     $SIG{__DIE__} = sub {CORE::die(PG_errorMessage('traceback',@_))};

This is a trouble spot, since it sets the handlers without using  
"local". From what I can tell, what we WANT to do here is provide a  
level of preprocessing to any warning or exception that comes out. We  
may also want to avoid calling the Apache::WeBWorK warn/die handlers,  
although I think we should leave them alone and assume our caller has  
some way they want to collect errors and warnings. (For example,  
WeBWorK::PG::Local has its own warn handler that accumulates warnings  
and returns them as part of the WeBWorK::PG object.) It seems to me  
that the simplest way to accomplish this is:

     # reset the error detection
     my $outer_sig_warn = $SIG{__WARN__};
     local $SIG{__WARN__} = sub {
         my $munged = PG_errorMessage('message', $_[0]);
         ref $outer_sig_warn eq "CODE" ? &$outer_sig_warn($munged) :  
warn $munged;
     };
     my $outer_sig_die = $SIG{__DIE__};
     local $SIG{__DIE__} = sub {
         my $munged = PG_errorMessage('traceback', $_[0]);
         ref $outer_sig_die eq "CODE" ? &$outer_sig_die($munged) :  
die $munged;
     };

This doesn't deal with the case where the handlers are set to string  
names of subroutines, but that could be added. It also doesn't handle  
"IGNORE", but that could be added as well.

in process_answers(), we have:

     local %errorTable;
     $SIG{__DIE__} = sub {
         #
         #  Get full traceback, but save it in local variable so that
         #  we can add it later.  This is because some evaluators use
         #  eval to trap errors and then report them in the message
         #  column of the results table, and we don't want to include
         #  the traceback there.
         #
         my $fullerror = PG_errorMessage('traceback',@_);
         my ($error,$traceback) = split /\n/, $fullerror, 2;
         $fullerror =~ s/\n   /<BR>&nbsp;&nbsp;&nbsp;/g; $fullerror  
=~ s/\n/<BR>/g;
         $error .= "\n";
         $errorTable{$error} = $fullerror;
         CORE::die($error);
     };
     # reset the error detection
     my $save_SIG_warn_trap = $SIG{__WARN__};
     $save_SIG_warn_trap = sub {CORE::warn @_} unless  ref 
($save_SIG_warn_trap) =~/CODE/;
     $SIG{__WARN__} = sub {&$save_SIG_warn_trap(PG_errorMessage 
('message',@_))};
     my $save_SIG_die_trap = $SIG{__DIE__};

and then later on, after the answers are evaluated:

     $SIG{__DIE__} = $save_SIG_die_trap;
     $SIG{__WARN__} = $save_SIG_warn_trap;

First of all, restoring the die handler doesn't work at all, since  
$save_SIG_die_trap is set to the custom die handler we just installed  
a few lines before. In addition, I think we can do the same thing  
here that we did up above, inserting the code that accumulates  
exceptions. Also, I think %errorTable can be a lexical.

     # reset the error detection
     my $outer_sig_warn = $SIG{__WARN__};
     local $SIG{__WARN__} = sub {
         my $munged = PG_errorMessage('message', $_[0]);
         ref $outer_sig_warn eq "CODE" ? &$outer_sig_warn($munged) :  
warn $munged;
     };
     my %errorTable;
     my $outer_sig_die = $SIG{__DIE__};
     local $SIG{__DIE__} = sub {
         my $fullerror = PG_errorMessage('traceback', $_[0]);
         my ($error,$traceback) = split /\n/, $fullerror, 2;
         $fullerror =~ s/\n   /<BR>&nbsp;&nbsp;&nbsp;/g; $fullerror  
=~ s/\n/<BR>/g;
         $error .= "\n";
         $errorTable{$error} = $fullerror;
         ref $outer_sig_die eq "CODE" ? &$outer_sig_die($error) : die  
$error;
     };

There are three more places where warn/die handlers get messed with  
- -- PG_restricted_eval(), PG_macro_file_eval(), and PG_answer_eval().  
In each case, subroutine begins with:

     my $save_SIG_warn_trap = $SIG{__WARN__};
     $SIG{__WARN__} = sub { CORE::die @_};
     my $save_SIG_die_trap = $SIG{__DIE__};
     $SIG{__DIE__}= sub {CORE::die @_};

then some code gets passed to eval STRING, and then:

     $SIG{__DIE__} = $save_SIG_die_trap;
     $SIG{__WARN__} = $save_SIG_warn_trap;

We can replace these with the same type of code that's used in  
evaluate_modules():

     local $SIG{__WARN__} = "DEFAULT";
     local $SIG{__DIE__} = "DEFAULT";

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFC6mDE14CQX+2WvVgRAmifAKCf2Mjte5IUWjE/FVINpt+CMZkeVwCePwGh
8EQzltAV6e4ObIZN8iRpLvU=
=LagG
-----END PGP SIGNATURE-----

Re: [WWdevel] Re: [WWcvs] webwork-modperl: New Directory

[Michael E. G. <ga...@ma...>]

OK.  I'll take this one out.  I'm trying to respond to Peter Heins  
problems with setting up
an initial course.  Potentially there is a similar problem with the  
rochesterLibrary link
(which will not be set up automatically).  I think I'll leave it for  
now -- an incorrect link
probably gives one a better hint of what the problem is than no link at  
all.

Take care,

Mike

On Jul 28, 2005, at 1:30 PM, John Jones wrote:

> Mike Gage via activitymail wrote:
>
>> Update of  
>> /webwork/cvs/system/webwork-modperl/courses/modelCourse/templates/ 
>> Library
>> In directory devel.webwork.rochester.edu:/var/webwork/Library
>>
>> Log Message:
>> Directory  
>> /webwork/cvs/system/webwork-modperl/courses/modelCourse/templates/ 
>> Library added to the repository
>>
> I think this will cause problems.  .../coursename/templates/Library is  
> reserved for the database Library.  If it is not there and the library  
> database is turned on, then webwork makes the needed symlink  
> automatically.  If the directory already exists and doesn't contain  
> the right stuff, then webwork will fail to find any of the database  
> library problems.
>
> John
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO  
> September
> 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing  
> & QA
> Security * Process Improvement & Measurement *  
> http://www.sqe.com/bsce5sf
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openwebwork-devel
>

[WWdevel] Re: [WWcvs] webwork-modperl: New Directory

[John J. <jj...@as...>]

Mike Gage via activitymail wrote:

>Update of /webwork/cvs/system/webwork-modperl/courses/modelCourse/templates/Library
>In directory devel.webwork.rochester.edu:/var/webwork/Library
>
>Log Message:
>Directory /webwork/cvs/system/webwork-modperl/courses/modelCourse/templates/Library added to the repository
>
I think this will cause problems.  .../coursename/templates/Library is 
reserved for the database Library.  If it is not there and the library 
database is turned on, then webwork makes the needed symlink 
automatically.  If the directory already exists and doesn't contain the 
right stuff, then webwork will fail to find any of the database library 
problems.

John

Re: [WWdevel] Re: [WWcvs] webwork-modperl: Rearrange top panels (change really from Bill Z.) plus

[Michael E. G. <ga...@ma...>]

On Jul 23, 2005, at 12:56 PM, John Jones wrote:

>
>  To fit what Nandor wanted, he may want more depth in the searching=20
> for the set definition files.=A0 For example, maybe he would want to=20=

> have courses created with a symlink to a directory called Sets, which=20=

> has subdirectories MAT_110, MAT_111, etc., each of which has his=20
> university's standard sets for those courses.
>
>>  I want to be careful not to search too deeply, since if the=20
>> libraries get large this will significantly slow down the creation of=20=

>> the Library browser page.
>>  I don't think this is a concern.=A0 If this is activated by a 4th =
main=20
>> button, then the searching only takes place if you click on that=20
>> button.=A0 If you do, it is no worse than clicking on "Local =
Problems",=20
>> which does a full depth search for .pg files.
>
>>>  In fact, it might be faster since one could easily use the standard=20=

>>> Perl File::Find module for the search.=A0 We don't do that on the =
.pg=20
>>> file searching because it is more complicated by looking if problems=20=

>>> should be treated as part of a parent directory or not.=A0 An=20
>>> advantage of File::Find is that you can easily have it detect=20
>>> circular symlinks.=A0 I have accidentally had some, and it really=20
>>> slows down the loading of the library browser page.
>> I suggest that set definition files can only be used in
>>
>>  the course templates directory and in
>>  any directory referred to in the $courseFiles{problibs} hash (in=20
>> global.conf).
>>
>>  If someone wants to create "libraries" for MAT_110, MAT_111 and so=20=

>> forth
>>  they can add an entry either to global.conf or to course.conf. I=20
>> don't think that is too big a burden for those interested in doing=20
>> fancy
>>  customization of local sites.
>>>  I think having all the .def files seen seems to the behavior of=20
>>> least surprise.=A0 So, if there is some customization - searching =
for=20
>>> all of them should probably be the default.
>

OK.  I've probably been worrying too much about the speed issue.  Just=20=

listing all the .def files seems the way to go.
If we're forced to it won't be difficult to restrict things later.

Take care,

Mike


>  John
>

Re: [WWdevel] Re: [WWcvs] webwork-modperl: Rearrange top panels (change really from Bill Z.) plus

[John J. <jj...@as...>]

Michael E. Gage wrote:

>     Files at the top of directories like rochesterLibrary,
>     unionLibrary, etc. might need special treatment.  If your name to
>     the Rochester Library is called rochesterLibrary, then all of the
>     paths accessing those files will start with rochesterLibrary.  If
>     another person names the link Rochester, then none of those set
>     definition files will work.  So, by special treatment, I mean some
>     sort of munging of the paths to account for this.
>
> What we might do is this: if the file is rochesterLibrary/setFoo.def 
> the entries would be relative to the directory the set definition file 
> is in:
> hence an entry of set0/prob1.pg would be come 
> rochesterLibrary/set0/prob1.pg. would that work?

I'll have to think about it.  I can think of problems, but I haven't 
thought enough be know if I think they are serious.

>
>     To fit what Nandor wanted, he may want more depth in the searching
>     for the set definition files.  For example, maybe he would want to
>     have courses created with a symlink to a directory called Sets,
>     which has subdirectories MAT_110, MAT_111, etc., each of which has
>     his university's standard sets for those courses.
>
> I want to be careful not to search too deeply, since if the libraries 
> get large this will significantly slow down the creation of the 
> Library browser page.

I don't think this is a concern.  If this is activated by a 4th main 
button, then the searching only takes place if you click on that 
button.  If you do, it is no worse than clicking on "Local Problems", 
which does a full depth search for .pg files.

In fact, it might be faster since one could easily use the standard Perl 
File::Find module for the search.  We don't do that on the .pg file 
searching because it is more complicated by looking if problems should 
be treated as part of a parent directory or not.  An advantage of 
File::Find is that you can easily have it detect circular symlinks.  I 
have accidentally had some, and it really slows down the loading of the 
library browser page.

> I suggest that set definition files can only be used in
>
> the course templates directory and in
> any directory referred to in the $courseFiles{problibs} hash (in 
> global.conf).
>
> If someone wants to create "libraries" for MAT_110, MAT_111 and so forth
> they can add an entry either to global.conf or to course.conf. I don't 
> think that is too big a burden for those interested in doing fancy
> customization of local sites.

I think having all the .def files seen seems to the behavior of least 
surprise.  So, if there is some customization - searching for all of 
them should probably be the default.

John

Re: [WWdevel] Re: [WWcvs] webwork-modperl: Rearrange top panels (change really from Bill Z.) plus

[Michael E. G. <ga...@ma...>]

On Jul 22, 2005, at 11:26 PM, John Jones wrote:

>
>  If you have a non-trivial selection from the Problem Collection=20
> popup=A0 you get the current behavior when you select view problems
>  If you select a non-trivial set definition file you get a list of=A0=20=

> problems found in the set definition file
>  If you select non-trivial things from both menus you get the problem=A0=
=20
> collection.
>
>  The only set definition files you can see would be the ones at the=20
> top=A0 level of a directory, e.g. rochesterLibrary, unionLibrary,
>  or the courseTemplate,=A0=A0 etc.
>
>  Any thoughts?
>  A couple.=A0 It seems that looking in set definition files is closer =
to=20
> "=46rom this Course" than to "Local Problems" since it is essentially=20=

> non-imported set definition files.=A0 But, I wouldn't put it with any =
of=20
> the existing parts and instead make it a fourth standard option along=20=

> with "Problem Library", "Local Problems", and "=46rom this Course".=A0=20=

> Most people probably use a window which can fit 4 wide buttons, right?
>
This seems ok to me.  I was trying to save vertical space by avoiding=20
another panel.  However what you propose is a more intuitive
interface.
>  A natural name might be "=46rom Set Definition Files", but knowing =
what=20
> a set definition file means may not be clear to someone not familiar=20=

> with webwork 1.
>
"Predefined sets" might be another name.  It's hard to tell what will=20
be most natural.  Those already using WeBWorK are tuned in to the name
set definition files name, but with a bit of time they could adjust. =20
On the whole I think I prefer Set Definition Files since it makes clear=20=

the association
with a file of type .def that they can see in the File Manager.  It=20
also agrees with the language in the Hmwk Sets Editor.

>  Files at the top of directories like rochesterLibrary, unionLibrary,=20=

> etc. might need special treatment.=A0 If your name to the Rochester=20
> Library is called rochesterLibrary, then all of the paths accessing=20
> those files will start with rochesterLibrary.=A0 If another person =
names=20
> the link Rochester, then none of those set definition files will=20
> work.=A0 So, by special treatment, I mean some sort of munging of the=20=

> paths to account for this.
>
What we might do is this:    if the file is  =20
rochesterLibrary/setFoo.def    the entries would be relative to the=20
directory the set definition file is in:
hence an entry   of set0/prob1.pg   would be come   =20
rochesterLibrary/set0/prob1.pg.  would that work?
>  To fit what Nandor wanted, he may want more depth in the searching=20
> for the set definition files.=A0 For example, maybe he would want to=20=

> have courses created with a symlink to a directory called Sets, which=20=

> has subdirectories MAT_110, MAT_111, etc., each of which has his=20
> university's standard sets for those courses.
>
I want to be careful not to search too deeply, since if the libraries=20
get large this will significantly slow down the creation of the Library=20=

browser page.

I suggest that set definition files can only be used in

the course templates directory and in
any directory referred to in the $courseFiles{problibs} hash (in=20
global.conf).

If someone wants to create "libraries" for  MAT_110, MAT_111 and so=20
forth
they can add an entry either to global.conf or to course.conf.  I don't=20=

think that is too big a burden for those interested in doing fancy
customization of local sites.

Take care,

Mike

>  Anyway, those are the thoughts I had off the top of my head.
>
>  John
>

Re: [WWdevel] Re: [WWcvs] webwork-modperl: Rearrange top panels (change really from Bill Z.) plus

[John J. <jj...@as...>]

Michael E. Gage wrote:

>
> ------------------------------------------------------------------------
>
>
>
> If you have a non-trivial selection from the Problem Collection popup  
> you get the current behavior when you select view problems
> If you select a non-trivial set definition file you get a list of  
> problems found in the set definition file
> If you select non-trivial things from both menus you get the problem  
> collection.
>
> The only set definition files you can see would be the ones at the 
> top  level of a directory, e.g. rochesterLibrary, unionLibrary,
> or the courseTemplate,   etc.
>
> Any thoughts?
>
A couple.  It seems that looking in set definition files is closer to 
"From this Course" than to "Local Problems" since it is essentially 
non-imported set definition files.  But, I wouldn't put it with any of 
the existing parts and instead make it a fourth standard option along 
with "Problem Library", "Local Problems", and "From this Course".  Most 
people probably use a window which can fit 4 wide buttons, right?

A natural name might be "From Set Definition Files", but knowing what a 
set definition file means may not be clear to someone not familiar with 
webwork 1.

Files at the top of directories like rochesterLibrary, unionLibrary, 
etc. might need special treatment.  If your name to the Rochester 
Library is called rochesterLibrary, then all of the paths accessing 
those files will start with rochesterLibrary.  If another person names 
the link Rochester, then none of those set definition files will work.  
So, by special treatment, I mean some sort of munging of the paths to 
account for this.

To fit what Nandor wanted, he may want more depth in the searching for 
the set definition files.  For example, maybe he would want to have 
courses created with a symlink to a directory called Sets, which has 
subdirectories MAT_110, MAT_111, etc., each of which has his 
university's standard sets for those courses.

Anyway, those are the thoughts I had off the top of my head.

John

[WWdevel] Re: [WWcvs] webwork-modperl: Rearrange top panels (change really from Bill Z.) plus

[Michael E. G. <ga...@ma...>]

Hi John,

I was wondering about a feature related to something Nandor requested a 
little while ago.
(http://webhost.math.rochester.edu/webworkdocs/discuss/msgReader$3413)

It would be a preview based on set definition files instead of on the 
subdirectory structure.  This would
allow for alternative views of the directory based on choices made by 
hand and entered into the
set definition files.  It seems to me that it would be easy to 
implement, and might even get used.  It would look like this:

[WWdevel] Re: projects for sam

[Sam H. <sh...@ma...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 22, 2005, at 13:22, Hoss Firooznia wrote:

> Michael E. Gage writes:
>
>
>> Once Hoss has the mysql server up and running I would be  
>> interested in
>> timing data which tells us how much of an advantage it is to have  
>> mysql
>> running on a separate machine.
>>
>
> Sorry for the delay on this; I've been caught up in a mammoth software
> upgrade with the faculty workstations along with the usual day-to-day
> stuff.  I'll start bringing the new WeBWorK-related systems up next  
> week.
>
> - Hoss

Sounds good.
- -sam

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFC4S7E14CQX+2WvVgRAhY2AJ9YDI5GJlp8Ji0Q8SlegDk15phADgCfe0tD
LeQU/uFMuMOVeUbFzsfrsGE=
=FvY8
-----END PGP SIGNATURE-----

[WWdevel] Fwd: webwork change

[Michael E. G. <ga...@ma...>]

Begin forwarded message:

> From: Pieter Bowman <bo...@ma...>
> Date: July 20, 2005 12:04:40 PM EDT
> To: sys...@ma..., web...@ma..., 
> ga...@ma..., sh...@ma..., 
> ap...@ma...
> Cc: bo...@ma...
> Subject: webwork change
>
> I have made the following change to the feedback.pl script on the Utah
> webwork systems.  This change was prompted because there are people
> using the webwork system to forward spam.  As far as I know, I'm the
> only recipient.  This change should only affect people who take a long
> time to send their feedback.
>
>  # feedback.pl: Mail feedback to a specified user, with the URL of the
>  #              referring page automagically included.  Reject bogus
> @@ -40,6 +40,8 @@
>         foreach  $ADDR (split(/\s*,\s*/, param('To'))) {
>             &check_destination($ADDR);
>
> +           &user_error('Session timed out.')
> +               if (param('ToUt') < time() - (5*60)); # Timeout 5 
> minutes
>             &user_error('You didn\'t enter any comments.')
>                 if (param('comments') eq '');
>             &user_error('You didn\'t enter an e-mail address.')
> @@ -178,6 +180,7 @@
>          hidden('Mode'),
>          hidden('user'),
>          hidden('key'),
> +        hidden('ToUt', time()),
>          strong("To: "), kbd($To), br,
>              strong("From: "), param('name'), br,
>          p,
>
> Pieter
>
> Pieter Bowman                        Voice:                 
> 1-801-581-5252
> University of Utah                   FAX:                   
> 1-801-581-4148
> Department of Mathematics            Email:           
> bo...@ma...
> 155 S 1400 E RM 233                  URL: 
> http://www.math.utah.edu/~bowman
> Salt Lake City, Ut, 84112-0090       Office:                       103 
> LCB
>

Re: [WWdevel] webwork: gateway merge/database

[P G. L. <gl...@um...>]

On Thu, 14 Jul 2005 at 12:11 John Jones wrote:
>
> By the way, I just discovered that the current CVS version of webwork is
> not backward compatible with courses created before the gateway stuff
> was merged in.  Is there a conversion tool yet, or will there be?

Oops.  I'm thinking this is because of the added set and set_user tables
in the database.

No conversion tool yet, but I think all that needs to be done is to add
the additional columns to the tables:

  alter table [classname]_set add column assignment_type text;
  alter table [classname]_set add column attempts_per_version integer;
  alter table [classname]_set add column time_interval integer;
  alter table [classname]_set add column versions_per_interval integer;
  alter table [classname]_set add column version_time_limit integer;
  alter table [classname]_set add column version_creation_time bigint;
  alter table [classname]_set add column problem_randorder integer;
  alter table [classname]_set add column version_last_attempt_time bigint;

and similarly for set_user.

Gavin

-- 
P. Gavin LaRose, Ph.D.  Program Manager (Instructional Tech.)
Math Dept., University of Michigan
gl...@um...                        "There's no use in trying," [Alice]
734.764.6454                             said. "One Can't believe impossible
http://www.math.lsa.umich.edu/~glarose/  things." "I daresay you haven't had
                                         much practice," said the Queen.
                                                              - Lewis Carrol

Re: [WWdevel] webwork: problem values getting set to zero

[John J. <jj...@as...>]

Michael Gage wrote:

> Ok. so for the "value" (amount the problem is worth) variable.
>
> Positive numeric states clearly have meaning.
> the 0 state should have meaning also -- probably indicating that it=
 is=20
> an optional problem -- certainly that it gets no credit.
>
> What is the interpretation of the NULL state or the "" to be? Do we=
=20
> have or can we imagine
> a use for states of "value" that are not numeric?

The "value" of a problem has a value for the whole class (usually 1)=
=20
which can be overridden for an individual student.  You can make a=
=20
problem worth 1 point for almost all of your students but worth 0 poi=
nts=20
(or 2 points) for an individual student.

Like any field which has a global value which can be overridden for=
=20
individuals, NULL or "" means to use the default for the class wherea=
s 0=20
means replace the classwide value with 0.

By the way, I just discovered that the current CVS version of webwork=
 is=20
not backward compatible with courses created before the gateway stuff=
=20
was merged in.  Is there a conversion tool yet, or will there be?

John

> If we are always going to use it as an integer, there is no reason=
=20
> that we can't enforce that it is an integer.
> If we are going to use other states we should try to be clear about=
=20
> how these states should be interpreted.
>
> Take care,
>
> Mike
> On Jul 14, 2005, at 2:03 PM, John Jones wrote:
>
>     This discussion of storing the student's score refers to the
>     student-problem field status.  It was not affected by my change=
s
>     to the types of fields in mysql databases - it is still stored =
as
>     type text rather than type int.  (Maybe it should be stored as =
an
>     int, but that's a different question.)
>
>     The problem Gavin discovered was with value - the number of poi=
nts
>     the problem is worth.  It is one of several fields currently
>     stored as type int, and they probably all will suffer the same
>     difficulty if they are override fields for a more global value.=
=20
>     It is a pretty serious bug, so I will attempt to fix this as so=
on
>     as we know which way we want to go.
>
>     I think our options are:
>     =95 in all cases, when storing "" in the database, store it as
>     NULL.  It will be promoted back when the information is
>     retrieved.  I think this is safe.
>     =95 when storing back to the database, only demote "" to NULL i=
f the
>     field is of integer type.
>     =95 stop using integer types in the database.
>
>     John
>
>
>     Michael Gage wrote:
>
>         On Jul 14, 2005, at 12:45 PM, P Gavin LaRose wrote:
>
>
>             Isn't the distinction between "haven't tried" and "scor=
e
>             of zero" also
>             captured by the attempted field in problem_user?  I thi=
nk
>             if the status
>             codes this also, it's redundant information.
>
>             Am I making sense?
>             Gavin
>
>
>         when extracting scoring data because we were getting a lot
>         spurious
>         "undefined variables" warnings.  We also get a  lot of
>         "non-numeric in comparison" errors
>         when sorting, etc. etc. etc.  In any case I think this is w=
hy
>         most things are promoted
>         from null at least to "" or to 0.
>
>         In light of what you have pointed out I suggest that we
>         "insist" that the student score
>         be a number.  I believe that blanks are automatically
>         converted to 0, so they would be ok in sorts.
>         (I haven't checked this.)  Otherwise we'll need checks in
>         every sort routine as well as other places.
>         Use the "attempts" field to determine if the problem hasn't
>         been tried yet.
>
>         We may need to fix some assumptions in the grading and scor=
ing
>         packages to conform to this.
>         The simplification in sorts that we gain by assuming that
>         score is always a number seems to
>         me to outweigh desires for more, occasionally non-numeric s=
tates.
>
>         Take care,
>
>         Mike
>
>
>             On Thu, 14 Jul 2005 at 12:39 Michael Gage wrote:
>
>                 Could we get a list of what states are needed for t=
he
>                 student score?
>
>                 number     -- means the student has achieved this
>                 score on this problem
>                 0                --  means the student has tried th=
is
>                 problem but
>                 hasn't gotten in correct
>                 null/ blank  -- means that the student hasn't tried
>                 the problem.
>
>                 Are there are other states we need?
>
>                 Do we need the state that distinguishes between
>                 "hasn't tried the
>                 problem" and the one where the score is zero?
>                 I think perhaps we do, so that we can warn the stud=
ent
>                 they haven't yet
>                 completed an assignment while not
>                 bugging them about problems that they haven't
>                 successfully completed.
>
>                 any other thoughts on what is needed?
>
>                 Take care,
>                 Mike
>
>
>             --=20
>             P. Gavin LaRose, Ph.D.  Program Manager (Instructional =
Tech.)
>             Math Dept., University of Michigan
>             gl...@um...                        "There's no us=
e
>             in trying," [Alice]
>             734.764.6454                             said. "One Can=
't
>             believe impossible
>             http://www.math.lsa.umich.edu/~glarose/  things." "I
>             daresay you haven't had
>                                                      much practice,=
"
>             said the Queen.
>                                                                    =
     =20
>             - Lewis Carrol
>
>
>
>
>         -------------------------------------------------------
>         SF.Net email is sponsored by: Discover Easy Linux Migration
>         Strategies
>         from IBM. Find simple to follow Roadmaps, straightforward
>         articles,
>         informative Webcasts and more! Get everything you need to g=
et
>         up to
>         speed, fast.
>         http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcli=
ck
>         _______________________________________________
>         OpenWeBWorK-Devel mailing list
>         Ope...@li...
>         https://lists.sourceforge.net/lists/listinfo/openwebwork-de=
vel
>
>

Re: [WWdevel] webwork: problem values getting set to zero

[P G. L. <gl...@um...>]

Hi Mike,

I think the only interpretation of NULL is in the problem_user table,
where it indicates that the global (problem table) value should be used.

If this is the case, NULL can't be meaningful in the problem table,
because it would be impossible to override a value in the problem table
with 'NULL' from the problem_user table.

Is there ever a case where 0 credit on a problem would mean anything other
than that it was optional?

Gavin

I think that this means

On Thu, 14 Jul 2005 at 14:49 Michael Gage wrote:

> Ok.  so for the "value" (amount the problem is worth) variable.
>
> Positive numeric states clearly have meaning.
> the 0 state should have meaning also -- probably indicating that it is
> an optional problem -- certainly that it gets no credit.
>
> What is the interpretation of the NULL state or the ""  to be?  Do we
> have or can we imagine
>   a use for states of "value" that are not numeric?
>
> If we are always going to use it as an integer, there is no reason that
> we can't enforce that it is an integer.
> If we are going to use other states we should try to be clear about how
> these states should be interpreted.
>
> Take care,
>
> Mike

-- 
P. Gavin LaRose, Ph.D.  Program Manager (Instructional Tech.)
Math Dept., University of Michigan
gl...@um...                        "There's no use in trying," [Alice]
734.764.6454                             said. "One Can't believe impossible
http://www.math.lsa.umich.edu/~glarose/  things." "I daresay you haven't had
                                         much practice," said the Queen.
                                                              - Lewis Carrol

Re: [WWdevel] webwork: problem values getting set to zero

[Michael G. <ga...@ma...>]

Ok.  so for the "value" (amount the problem is worth) variable.

Positive numeric states clearly have meaning.
the 0 state should have meaning also -- probably indicating that it is=20=

an optional problem -- certainly that it gets no credit.

What is the interpretation of the NULL state or the ""  to be?  Do we=20
have or can we imagine
  a use for states of "value" that are not numeric?

If we are always going to use it as an integer, there is no reason that=20=

we can't enforce that it is an integer.
If we are going to use other states we should try to be clear about how=20=

these states should be interpreted.

Take care,

Mike
On Jul 14, 2005, at 2:03 PM, John Jones wrote:

>  This discussion of storing the student's score refers to the=20
> student-problem field status.=A0 It was not affected by my changes to=20=

> the types of fields in mysql databases - it is still stored as type=20
> text rather than type int.=A0 (Maybe it should be stored as an int, =
but=20
> that's a different question.)
>
>  The problem Gavin discovered was with value - the number of points=20
> the problem is worth.=A0 It is one of several fields currently stored =
as=20
> type int, and they probably all will suffer the same difficulty if=20
> they are override fields for a more global value.=A0 It is a pretty=20
> serious bug, so I will attempt to fix this as soon as we know which=20
> way we want to go.
>
>  I think our options are:
> 	=95 	in all cases, when storing "" in the database, store it =
as NULL.=A0=20
> It will be promoted back when the information is retrieved.=A0 I think=20=

> this is safe.
> 	=95 	when storing back to the database, only demote "" to =
NULL if the=20
> field is of integer type.
> 	=95 	stop using integer types in the database.
>
>  John
>
>
>  Michael Gage wrote:
>>  On Jul 14, 2005, at 12:45 PM, P Gavin LaRose wrote:
>>
>>>
>>>  Isn't the distinction between "haven't tried" and "score of zero"=20=

>>> also
>>>  captured by the attempted field in problem_user?=A0 I think if the=20=

>>> status
>>>  codes this also, it's redundant information.
>>>
>>>  Am I making sense?
>>>  Gavin
>>>
>>
>>  when extracting scoring data because we were getting a lot spurious
>>  "undefined variables" warnings.=A0 We also get a=A0 lot of =
"non-numeric=20
>> in comparison" errors
>>  when sorting, etc. etc. etc.=A0 In any case I think this is why most=20=

>> things are promoted
>>  from null at least to "" or to 0.
>>
>>  In light of what you have pointed out I suggest that we "insist"=20
>> that the student score
>>  be a number.=A0 I believe that blanks are automatically converted to=20=

>> 0, so they would be ok in sorts.
>>  (I haven't checked this.)=A0 Otherwise we'll need checks in every =
sort=20
>> routine as well as other places.
>>  Use the "attempts" field to determine if the problem hasn't been=20
>> tried yet.
>>
>>  We may need to fix some assumptions in the grading and scoring=20
>> packages to conform to this.
>>  The simplification in sorts that we gain by assuming that score is=20=

>> always a number seems to
>>  me to outweigh desires for more, occasionally non-numeric states.
>>
>>  Take care,
>>
>>  Mike
>>
>>
>>> On Thu, 14 Jul 2005 at 12:39 Michael Gage wrote:
>>>
>>>> Could we get a list of what states are needed for the student =
score?
>>>>
>>>>  number=A0=A0=A0=A0 -- means the student has achieved this score on =
this=20
>>>> problem
>>>>  0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 --=A0 means the =
student has tried this problem but
>>>>  hasn't gotten in correct
>>>>  null/ blank=A0 -- means that the student hasn't tried the problem.
>>>>
>>>>  Are there are other states we need?
>>>>
>>>>  Do we need the state that distinguishes between "hasn't tried the
>>>>  problem" and the one where the score is zero?
>>>>  I think perhaps we do, so that we can warn the student they=20
>>>> haven't yet
>>>>  completed an assignment while not
>>>>  bugging them about problems that they haven't successfully=20
>>>> completed.
>>>>
>>>>  any other thoughts on what is needed?
>>>>
>>>>  Take care,
>>>>  Mike
>>>
>>>  --=A0
>>>  P. Gavin LaRose, Ph.D.=A0 Program Manager (Instructional Tech.)
>>>  Math Dept., University of Michigan
>>> gl...@um...=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 "There's no use in trying,"=20
>>> [Alice]
>>>  734.764.6454=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 said. "One Can't believe=20
>>> impossible
>>> http://www.math.lsa.umich.edu/~glarose/=A0 things." "I daresay you=20=

>>> haven't had
>>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 much practice," said =
the=20
>>> Queen.
>>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -=20
>>> Lewis Carrol
>>>
>>
>>
>>
>>  -------------------------------------------------------
>>  SF.Net email is sponsored by: Discover Easy Linux Migration=20
>> Strategies
>>  from IBM. Find simple to follow Roadmaps, straightforward articles,
>>  informative Webcasts and more! Get everything you need to get up to
>>  speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dc=
lick
>>  _______________________________________________
>>  OpenWeBWorK-Devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/openwebwork-devel
>

Re: [WWdevel] webwork: problem values getting set to zero

[P G. L. <gl...@um...>]

Hi John,

I think
     * in all cases, when storing "" in the database, store it as NULL.
       It will be promoted back when the information is retrieved.  I
       think this is safe.
is the easiest fix.  Aesthetically I like the idea of calling something
that has integer values an integer when defining the database, so from a
purely artistic viewpoint I'd vote against
     * stop using integer types in the database.

Gavin

On Thu, 14 Jul 2005 at 11:03 John Jones wrote:

> This discussion of storing the student's score refers to the
> student-problem field status.  It was not affected by my changes to the
> types of fields in mysql databases - it is still stored as type text
> rather than type int.  (Maybe it should be stored as an int, but that's
> a different question.)
>
> The problem Gavin discovered was with value - the number of points the
> problem is worth.  It is one of several fields currently stored as type
> int, and they probably all will suffer the same difficulty if they are
> override fields for a more global value.  It is a pretty serious bug, so
> I will attempt to fix this as soon as we know which way we want to go.
>
> I think our options are:
>     * in all cases, when storing "" in the database, store it as NULL.
>       It will be promoted back when the information is retrieved.  I
>       think this is safe.
>     * when storing back to the database, only demote "" to NULL if the
>       field is of integer type.
>     * stop using integer types in the database.
>
>
> John
>
>
> Michael Gage wrote:
>
> >
> > On Jul 14, 2005, at 12:45 PM, P Gavin LaRose wrote:
> >
> >>
> >> Isn't the distinction between "haven't tried" and "score of zero" also
> >> captured by the attempted field in problem_user?  I think if the status
> >> codes this also, it's redundant information.
> >>
> >> Am I making sense?
> >> Gavin
> >>
> > That makes sense to me.  I believe that we tried to eliminate all of
> > the null responses
> > when extracting scoring data because we were getting a lot spurious
> > "undefined variables" warnings.  We also get a  lot of "non-numeric in
> > comparison" errors
> > when sorting, etc. etc. etc.  In any case I think this is why most
> > things are promoted
> > from null at least to "" or to 0.
> >
> > In light of what you have pointed out I suggest that we "insist" that
> > the student score
> > be a number.  I believe that blanks are automatically converted to 0,
> > so they would be ok in sorts.
> > (I haven't checked this.)  Otherwise we'll need checks in every sort
> > routine as well as other places.
> > Use the "attempts" field to determine if the problem hasn't been tried
> > yet.
> >
> > We may need to fix some assumptions in the grading and scoring
> > packages to conform to this.
> > The simplification in sorts that we gain by assuming that score is
> > always a number seems to
> > me to outweigh desires for more, occasionally non-numeric states.
> >
> > Take care,
> >
> > Mike
> >
> >
> >> On Thu, 14 Jul 2005 at 12:39 Michael Gage wrote:
> >>
> >>> Could we get a list of what states are needed for the student score?
> >>>
> >>> number     -- means the student has achieved this score on this problem
> >>> 0                --  means the student has tried this problem but
> >>> hasn't gotten in correct
> >>> null/ blank  -- means that the student hasn't tried the problem.
> >>>
> >>> Are there are other states we need?
> >>>
> >>> Do we need the state that distinguishes between "hasn't tried the
> >>> problem" and the one where the score is zero?
> >>> I think perhaps we do, so that we can warn the student they haven't yet
> >>> completed an assignment while not
> >>> bugging them about problems that they haven't successfully completed.
> >>>
> >>> any other thoughts on what is needed?
> >>>
> >>> Take care,
> >>> Mike
> >>
> >>
> >> --
> >> P. Gavin LaRose, Ph.D.  Program Manager (Instructional Tech.)
> >> Math Dept., University of Michigan
> >> gl...@um...                        "There's no use in trying,"
> >> [Alice]
> >> 734.764.6454                             said. "One Can't believe
> >> impossible
> >> http://www.math.lsa.umich.edu/~glarose/  things." "I daresay you
> >> haven't had
> >>                                          much practice," said the Queen.
> >>                                                               - Lewis
> >> Carrol
> >>
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > OpenWeBWorK-Devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openwebwork-devel
>
>
>

-- 
P. Gavin LaRose, Ph.D.  Program Manager (Instructional Tech.)
Math Dept., University of Michigan
gl...@um...                        "There's no use in trying," [Alice]
734.764.6454                             said. "One Can't believe impossible
http://www.math.lsa.umich.edu/~glarose/  things." "I daresay you haven't had
                                         much practice," said the Queen.
                                                              - Lewis Carrol

Re: [WWdevel] webwork: problem values getting set to zero

[John J. <jj...@as...>]

This discussion of storing the student's score refers to the 
student-problem field status.  It was not affected by my changes to the 
types of fields in mysql databases - it is still stored as type text 
rather than type int.  (Maybe it should be stored as an int, but that's 
a different question.)

The problem Gavin discovered was with value - the number of points the 
problem is worth.  It is one of several fields currently stored as type 
int, and they probably all will suffer the same difficulty if they are 
override fields for a more global value.  It is a pretty serious bug, so 
I will attempt to fix this as soon as we know which way we want to go.

I think our options are:

    * in all cases, when storing "" in the database, store it as NULL. 
      It will be promoted back when the information is retrieved.  I
      think this is safe.
    * when storing back to the database, only demote "" to NULL if the
      field is of integer type.
    * stop using integer types in the database.


John


Michael Gage wrote:

>
> On Jul 14, 2005, at 12:45 PM, P Gavin LaRose wrote:
>
>>
>> Isn't the distinction between "haven't tried" and "score of zero" also
>> captured by the attempted field in problem_user?  I think if the status
>> codes this also, it's redundant information.
>>
>> Am I making sense?
>> Gavin
>>
> That makes sense to me.  I believe that we tried to eliminate all of 
> the null responses
> when extracting scoring data because we were getting a lot spurious
> "undefined variables" warnings.  We also get a  lot of "non-numeric in 
> comparison" errors
> when sorting, etc. etc. etc.  In any case I think this is why most 
> things are promoted
> from null at least to "" or to 0.
>
> In light of what you have pointed out I suggest that we "insist" that 
> the student score
> be a number.  I believe that blanks are automatically converted to 0, 
> so they would be ok in sorts.
> (I haven't checked this.)  Otherwise we'll need checks in every sort 
> routine as well as other places.
> Use the "attempts" field to determine if the problem hasn't been tried 
> yet.
>
> We may need to fix some assumptions in the grading and scoring 
> packages to conform to this.
> The simplification in sorts that we gain by assuming that score is 
> always a number seems to
> me to outweigh desires for more, occasionally non-numeric states.
>
> Take care,
>
> Mike
>
>
>> On Thu, 14 Jul 2005 at 12:39 Michael Gage wrote:
>>
>>> Could we get a list of what states are needed for the student score?
>>>
>>> number     -- means the student has achieved this score on this problem
>>> 0                --  means the student has tried this problem but
>>> hasn't gotten in correct
>>> null/ blank  -- means that the student hasn't tried the problem.
>>>
>>> Are there are other states we need?
>>>
>>> Do we need the state that distinguishes between "hasn't tried the
>>> problem" and the one where the score is zero?
>>> I think perhaps we do, so that we can warn the student they haven't yet
>>> completed an assignment while not
>>> bugging them about problems that they haven't successfully completed.
>>>
>>> any other thoughts on what is needed?
>>>
>>> Take care,
>>> Mike
>>
>>
>> -- 
>> P. Gavin LaRose, Ph.D.  Program Manager (Instructional Tech.)
>> Math Dept., University of Michigan
>> gl...@um...                        "There's no use in trying," 
>> [Alice]
>> 734.764.6454                             said. "One Can't believe 
>> impossible
>> http://www.math.lsa.umich.edu/~glarose/  things." "I daresay you 
>> haven't had
>>                                          much practice," said the Queen.
>>                                                               - Lewis 
>> Carrol
>>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openwebwork-devel

Re: [WWdevel] webwork: problem values getting set to zero

[Michael G. <ga...@ma...>]

On Jul 14, 2005, at 12:45 PM, P Gavin LaRose wrote:

>
> Isn't the distinction between "haven't tried" and "score of zero" also
> captured by the attempted field in problem_user?  I think if the status
> codes this also, it's redundant information.
>
> Am I making sense?
> Gavin
>
That makes sense to me.  I believe that we tried to eliminate all of 
the null responses
when extracting scoring data because we were getting a lot spurious
"undefined variables" warnings.  We also get a  lot of "non-numeric in 
comparison" errors
when sorting, etc. etc. etc.  In any case I think this is why most 
things are promoted
from null at least to "" or to 0.

In light of what you have pointed out I suggest that we "insist" that 
the student score
be a number.  I believe that blanks are automatically converted to 0, 
so they would be ok in sorts.
(I haven't checked this.)  Otherwise we'll need checks in every sort 
routine as well as other places.
Use the "attempts" field to determine if the problem hasn't been tried 
yet.

We may need to fix some assumptions in the grading and scoring packages 
to conform to this.
The simplification in sorts that we gain by assuming that score is 
always a number seems to
me to outweigh desires for more, occasionally non-numeric states.

Take care,

Mike


> On Thu, 14 Jul 2005 at 12:39 Michael Gage wrote:
>
>> Could we get a list of what states are needed for the student score?
>>
>> number     -- means the student has achieved this score on this 
>> problem
>> 0                --  means the student has tried this problem but
>> hasn't gotten in correct
>> null/ blank  -- means that the student hasn't tried the problem.
>>
>> Are there are other states we need?
>>
>> Do we need the state that distinguishes between "hasn't tried the
>> problem" and the one where the score is zero?
>> I think perhaps we do, so that we can warn the student they haven't 
>> yet
>> completed an assignment while not
>> bugging them about problems that they haven't successfully completed.
>>
>> any other thoughts on what is needed?
>>
>> Take care,
>> Mike
>
> -- 
> P. Gavin LaRose, Ph.D.  Program Manager (Instructional Tech.)
> Math Dept., University of Michigan
> gl...@um...                        "There's no use in trying," 
> [Alice]
> 734.764.6454                             said. "One Can't believe 
> impossible
> http://www.math.lsa.umich.edu/~glarose/  things." "I daresay you 
> haven't had
>                                          much practice," said the 
> Queen.
>                                                               - Lewis 
> Carrol
>

Re: [WWdevel] webwork: problem values getting set to zero

[P G. L. <gl...@um...>]

Hi John,

In that get() promotes NULL to "" anyway, it's not clear to me that we can
tell the difference between fields that are "" in the database and those
which are NULL.  Does that make sense?  The only place that I can think
that we grab data out of the database without using get() is with list(),
which I think gets indexed/key fields which can't be null.

So I think from anywhere at the level of DB.pm or above we can't tell if a
field is empty or NULL, in which case it shouldn't matter if all empty
fields are stored as NULL.

Gavin

On Thu, 14 Jul 2005 at 09:26 John Jones wrote:

> This sounds like it is my fault since I changed field types from all
> being strings to being types related to what was being stored.  What you
> suggest is probably the best course of action.  I wonder if all
> instances of "" should be demoted to NULL, or if it should only be done
> for fields with type integer.
>
> Another possibility would be to revert part of my change so that integer
> types would not be used in the future which would avoid the promotion
> problem for courses created after that.
>
> John

-- 
P. Gavin LaRose, Ph.D.  Program Manager (Instructional Tech.)
Math Dept., University of Michigan
gl...@um...                        "There's no use in trying," [Alice]
734.764.6454                             said. "One Can't believe impossible
http://www.math.lsa.umich.edu/~glarose/  things." "I daresay you haven't had
                                         much practice," said the Queen.
                                                              - Lewis Carrol

Re: [WWdevel] webwork: problem values getting set to zero

[Michael G. <ga...@ma...>]

Could we get a list of what states are needed for the student score?

number     -- means the student has achieved this score on this problem
0                --  means the student has tried this problem but 
hasn't gotten in correct
null/ blank  -- means that the student hasn't tried the problem.

Are there are other states we need?

Do we need the state that distinguishes between "hasn't tried the 
problem" and the one where the score is zero?
I think perhaps we do, so that we can warn the student they haven't yet 
completed an assignment while not
bugging them about problems that they haven't successfully completed.

any other thoughts on what is needed?

Take care,

Mike

On Jul 14, 2005, at 12:26 PM, John Jones wrote:

> This sounds like it is my fault since I changed field types from all 
> being strings to being types related to what was being stored.  What 
> you suggest is probably the best course of action.  I wonder if all 
> instances of "" should be demoted to NULL, or if it should only be 
> done for fields with type integer.
>
> Another possibility would be to revert part of my change so that 
> integer types would not be used in the future which would avoid the 
> promotion problem for courses created after that.
>
> John

Re: [WWdevel] webwork: problem values getting set to zero

[John J. <jj...@as...>]

This sounds like it is my fault since I changed field types from all 
being strings to being types related to what was being stored.  What you 
suggest is probably the best course of action.  I wonder if all 
instances of "" should be demoted to NULL, or if it should only be done 
for fields with type integer.

Another possibility would be to revert part of my change so that integer 
types would not be used in the future which would avoid the promotion 
problem for courses created after that.

John


P Gavin LaRose wrote:

>Hi all,
>
>In the course of adding the GatewayQuiz module to the HEAD branch in the
>CVS, I've found that when I look at StudentProgress all student scores are
>being reported as zero (regardless of how many correct problems they have
>in the set).
>
>I think what's happening is that when we get NULL values out of the
>database they are promoted to empty strings, but when we put an empty
>string back into an integer field in the database that gets stored as
>zero.
>
>In particular, when a set is assigned to a student the appropriate entries
>in the problem_user table are created.  For those the value field is set
>to NULL.  When we get() the problems out of the table (with
>$db->{problem_user}->get()), the NULL is promoted to "", so that
>$userProblem->value() is then the empty string.
>
>As the user problem is processed by Problem.pm (or GatewayQuiz.pm),
>$userProblem->value() isn't changed.  Then, when we put the problem back
>into the database after grading (with $db->{problem_user}->put()), we're
>putting an empty string into the integer value field, which is stored as
>zero.
>
>When we then get the merged problem out again, $db->getMergedProblem()
>checks for empty fields to decide whether to use the global problem's
>value.  However the entry in problem_user now has value == 0, so the
>global problem's value (== 1) isn't used.  This means that when
>StudentProgress.pm (et al.) calculate the student's score (by taking
>$userProblem->status() * $userProblem->value()), the score is zero.
>
>Does that sound right?  If so, the work-around/solution may be to make
>$db->{}->put() demote empty strings to NULL.  Comments?
>
>Thanks,
>Gavin
>
>  
>

Re: [WWdevel] webwork: problem values getting set to zero

[Michael G. <ga...@ma...>]

Hi John,

Gavin is in the process of a massive update to HEAD to add all of the=20
Gateway quiz stuff.  Things may be a bit
iffy for 24 hours or so.  I'm at work for the next 3 hours or so, but=20
once I get home I have a copy of the installation
which I can use to get rid of any remaining conflicts.  I put a warning=20=

out a week ago on the home page
to be cautious about updating to HEAD for a little while until we get=20
things under control.

Take care,

Mike

On Jul 14, 2005, at 12:13 PM, John Jones wrote:

>  Hi everyone,
>
>  Are the files ok?=A0
>
>  I just looked at SetMaker.pm through the web-cvs.=A0 The diffs to the=20=

> previous version have lines added like
>
> >>>>>>> 1.20.2.2
>
>  This is a sign that a "cvs update" was done, there were conflicts=20
> which were not fixed, and then a "cvs commit" which would have put all=20=

> of the conflict markers in the files in cvs.
>
>  John
>

Re: [WWdevel] webwork: problem values getting set to zero

[P G. L. <gl...@um...>]

Hi John,

That's my error.  I'll double check the other files that had conflicts.  I
thought I had caught all of them, but obviously missed that one.

Gavin

On Thu, 14 Jul 2005 at 09:13 John Jones wrote:

> Hi everyone,
>
> Are the files ok?
>
> I just looked at SetMaker.pm through the web-cvs.  The diffs to the
> previous version have lines added like
>
>  >>>>>>> 1.20.2.2
>
> This is a sign that a "cvs update" was done, there were conflicts which
> were not fixed, and then a "cvs commit" which would have put all of the
> conflict markers in the files in cvs.
>
> John
>
>

-- 
P. Gavin LaRose, Ph.D.  Program Manager (Instructional Tech.)
Math Dept., University of Michigan
gl...@um...                        "There's no use in trying," [Alice]
734.764.6454                             said. "One Can't believe impossible
http://www.math.lsa.umich.edu/~glarose/  things." "I daresay you haven't had
                                         much practice," said the Queen.
                                                              - Lewis Carrol

Re: [WWdevel] webwork: problem values getting set to zero

[John J. <jj...@as...>]

Hi everyone,

Are the files ok? 

I just looked at SetMaker.pm through the web-cvs.  The diffs to the 
previous version have lines added like

 >>>>>>> 1.20.2.2

This is a sign that a "cvs update" was done, there were conflicts which 
were not fixed, and then a "cvs commit" which would have put all of the 
conflict markers in the files in cvs.

John

[WWdevel] webwork: problem values getting set to zero

[P G. L. <gl...@um...>]

Hi all,

In the course of adding the GatewayQuiz module to the HEAD branch in the
CVS, I've found that when I look at StudentProgress all student scores are
being reported as zero (regardless of how many correct problems they have
in the set).

I think what's happening is that when we get NULL values out of the
database they are promoted to empty strings, but when we put an empty
string back into an integer field in the database that gets stored as
zero.

In particular, when a set is assigned to a student the appropriate entries
in the problem_user table are created.  For those the value field is set
to NULL.  When we get() the problems out of the table (with
$db->{problem_user}->get()), the NULL is promoted to "", so that
$userProblem->value() is then the empty string.

As the user problem is processed by Problem.pm (or GatewayQuiz.pm),
$userProblem->value() isn't changed.  Then, when we put the problem back
into the database after grading (with $db->{problem_user}->put()), we're
putting an empty string into the integer value field, which is stored as
zero.

When we then get the merged problem out again, $db->getMergedProblem()
checks for empty fields to decide whether to use the global problem's
value.  However the entry in problem_user now has value == 0, so the
global problem's value (== 1) isn't used.  This means that when
StudentProgress.pm (et al.) calculate the student's score (by taking
$userProblem->status() * $userProblem->value()), the score is zero.

Does that sound right?  If so, the work-around/solution may be to make
$db->{}->put() demote empty strings to NULL.  Comments?

Thanks,
Gavin

-- 
P. Gavin LaRose, Ph.D.  Program Manager (Instructional Tech.)
Math Dept., University of Michigan
gl...@um...                        "There's no use in trying," [Alice]
734.764.6454                             said. "One Can't believe impossible
http://www.math.lsa.umich.edu/~glarose/  things." "I daresay you haven't had
                                         much practice," said the Queen.
                                                              - Lewis Carrol