openwebwork-devel — WeBWorK development discussion

[WWdevel] Fwd: cvs commit

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

Begin forwarded message:

> From: Michael Gage <ga...@ma...>
> Date: Wed Jul 13, 2005  3:00:21 PM US/Eastern
> To: P Gavin LaRose <gl...@um...>
> Subject: Re: cvs commit
>
>
> On Wednesday, July 13, 2005, at 02:08 PM, P Gavin LaRose wrote:
>
>>
>> Hmm.  Ok, it committed the file, incremented the version number, and 
>> if
>> I ask for diffs it shows that the file hasn't changed.
>>
>> Do we care if some subset of the files in the CVS get this type 
>> "update"
>> when I commit the full system?
>>
> I don't think we care. At least I can't see any major
> downside to it.
>
> Take care,
>
> Mike
>
>> 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
>>
>

[WWdevel] Re: {WWdev} ww2.1/gateways

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

OK.  Good luck.

Take care,

Mike

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

> Hi Mike,
>
> I think I should be able to port the Gateway stuff across into
> ProblemSetDetail.pm.  At least, I'm making a stab at it now.  I'll let 
> you
> know if I run into trouble.
>
> Gavin
>
> On Tue, 12 Jul 2005 at 12:41 Michael E. Gage wrote:
>
>> That's right:.  Here is the initial note from the CVS
>>
>> Replaces ProblemSetEditor.pm and ProblemList.pm as primary form of
>> editing
>> set/problem information.
>>
>> ProblemSetEditor.pm hasn't been updated since Robert Van Dam
>> started modifying the user interface for editing problems last year.
>> (except by you).
>>
>> If that is the main place you are having problems reconciling things
>> you could check your copy into the CVS and Sam and I can help with the
>> reconciliation.
>>
>> Robert just graduated and is now out at Brigham Young U. in Utah.  He
>> might have time to help, or at least give advice, if I can get hold of
>> him.
>>
>> 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
>

[WWdevel] Re:{WWdev} ww2.1/gateways

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

Hi Mike,

I think I should be able to port the Gateway stuff across into
ProblemSetDetail.pm.  At least, I'm making a stab at it now.  I'll let you
know if I run into trouble.

Gavin

On Tue, 12 Jul 2005 at 12:41 Michael E. Gage wrote:

> That's right:.  Here is the initial note from the CVS
>
> Replaces ProblemSetEditor.pm and ProblemList.pm as primary form of
> editing
> set/problem information.
>
> ProblemSetEditor.pm hasn't been updated since Robert Van Dam
> started modifying the user interface for editing problems last year.
> (except by you).
>
> If that is the main place you are having problems reconciling things
> you could check your copy into the CVS and Sam and I can help with the
> reconciliation.
>
> Robert just graduated and is now out at Brigham Young U. in Utah.  He
> might have time to help, or at least give advice, if I can get hold of
> him.
>
> 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

[WWdevel] Re:{WWdev} ww2.1/gateways

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

That's right:.  Here is the initial note from the CVS

Replaces ProblemSetEditor.pm and ProblemList.pm as primary form of 
editing
set/problem information.

ProblemSetEditor.pm hasn't been updated since Robert Van Dam
started modifying the user interface for editing problems last year. 
(except by you).

If that is the main place you are having problems reconciling things 
you could check your copy into the CVS and Sam and I can help with the 
reconciliation.

Robert just graduated and is now out at Brigham Young U. in Utah.  He 
might have time to help, or at least give advice, if I can get hold of 
him.

Take care,

Mike

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

> Hi Mike and Sam,
>
> Ok, I've finally gotten WeBWorK 2.1 working on my development machine 
> and
> am testing the gateway modifications.  It looks like a significant 
> change
> from 2.0 to 2.1 is that the ProblemSetEditor.pm module is replaced by 
> the
> ProblemSetDetail.pm module.  Please correct me if this is not right.  I
> was having a devil of a time figuring out why the gateway test editing
> features in ProblemSetEditor.pm never showed up, but I think there's an
> obvious reason for that now that I've gone back to look at URLPath.pm.
>
> 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
>

Re: [WWdevel] Backward-compatible Parser-based answer checkers

[Davide P.C. <dp...@un...>]

>  First, a big thanks Davide for doing this.

You're welcome.  I thought it would be an interesting experiment.

>  Has this issue with Matrix been resolved?

Yes and no.  There is not longer an immediate conflict when a problem 
uses the traditional Matrix class.  But if a problem author would want 
to use both the new parser and the old matrix class in the same 
problem, then loading "Parser.pl" would cause a conflict.  But the 
conflict is only with the subroutine called "Matrix()" not with the 
classes themselves.  In that case, you could call Matrix->new() to get 
the matrix rather than "new Matrix()".  So it is not such a serious 
problem as it might have seemed at first.

Davide

Re: [WWdevel] Backward-compatible Parser-based answer checkers

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

First, a big thanks Davide for doing this.

Has this issue with Matrix been resolved?

John


Michael E. Gage wrote:

> Hi Davide,
>
> OK. I have one conflict.
>
> The terms such as $matrix = new Matrix;
>
> (Matrix is the old style matrix) are not working -- probably a
> conflict with the Parser::Matrix objects.
>
> Nearly any example that uses PGmorematricmacros.pl or
> PGdiffeqmacros.pl will give an error about not being able
> to recognize Matrix.
>
> Error detected while loading [PG]/macros/PGmorematrixmacros.pl: 
> Bareword found where operator expected at line 11 of 
> [PG]/macros/PGmorematrixmacros.pl, near "new Matrix" Died within 
> main::compile_file called at line 263 of 
> [PG]/macros/dangerousMacros.pl from within main::loadMacros called at 
> line 8 of [TMPL]/setLinearAlgebra3Matrices/ur_la_3_23.pg
>
>
> I'm starting to look at it, but you may have a better idea
> of where to look.
>
> It's not 100% guaranteed that this is due to your changes.
> I've been making some as well.
>
>
> Take care,
>
> Mike
>

Re: [WWdevel] A table of existing macros

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

>
> 1.  I added "remove_whitespace" to the unordered_* filters, since that 
> seems to be the behavior documented in several locations (even though 
> they are not actually present in the code).
>
> 2.  I added "trim_whitespace" to the std_cs_str* filters, since this 
> is present in the std_str* ones and the implication is that 
> case-sensitivity is the only difference.
>
> You can remove these from the %function hash at the top of the file if 
> you don't want that behavior.
>

I think you made the right choices on this.  I believe both of the 
anomalies are errors
introduced when we converted the macros to use STR_CMP.

Thanks very much for this.

Take care,

Mike

> <convert-functions.pl>

Re: [WWdevel] A table of existing macros

[Davide P.C. <dp...@un...>]

>> I notice in PGanswermacros.pl that in addition to setting the 
>> filters, they also set a type flag.  Do you want that to be included 
>> in the conversion?  That is, should
>>
>> 	strict_str_cmp("foobar")
>>
>> produce
>>
>> 	str_cmp("foobar",filters=>'trim_whitespace')
>> or
>> 	str_cmp("foobar",filters=>'trim_whitespace', type=>'strict_str_cmp')
>>
>> I think it should be the former, but I don't know how the type flag 
>> might be used later on, if at all.  I suspect it is just 
>> informational and can be ignored.
>>
> I think the former is best as well.

OK, that's been added.

>> Also, do you prefer
>>
>> 	str_cmp("foobar",filters=>'trim_whitespace')
>>
>> or just
>>
>> 	str_cmp("foobar",'trim_whitespace')
>>
>> as the result?
>>
> As long as we are converting I think I prefer
>           str_cmp("foobar", filters=>['trim_whitespace'])

OK, no problem.  I've put brackets around singleton lists as you 
requested.

I'm attaching the modified version.  It should do as you asked, but I 
did make two changes that you might or might no like:

1.  I added "remove_whitespace" to the unordered_* filters, since that 
seems to be the behavior documented in several locations (even though 
they are not actually present in the code).

2.  I added "trim_whitespace" to the std_cs_str* filters, since this is 
present in the std_str* ones and the implication is that 
case-sensitivity is the only difference.

You can remove these from the %function hash at the top of the file if 
you don't want that behavior.

Davide

Re: [WWdevel] A table of existing macros

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

Are these a collection of conversion scripts, or one which you are 
successively improving?  In any case, I should get a copy when they are 
done so I can run them on the "database-library" problems.

John


Michael E. Gage wrote:

>
> On Jul 6, 2005, at 11:58 AM, Davide P.Cervone wrote:
>
>>> This script is great.
>>> I've converted the rochester problem library and haven't found
>>> any glitches yet.
>>
>>
>> I'm glad it is working out for you.
>>
>>> I think we should add the string compare functions as well.
>>
>>
>> OK, no problem.  I'll add them to the table of routines to convert.  
>> I notice in PGanswermacros.pl that in addition to setting the 
>> filters, they also set a type flag.  Do you want that to be included 
>> in the conversion?  That is, should
>>
>>     strict_str_cmp("foobar")
>>
>> produce
>>
>>     str_cmp("foobar",filters=>'trim_whitespace')
>> or
>>     str_cmp("foobar",filters=>'trim_whitespace', type=>'strict_str_cmp')
>>
>> I think it should be the former, but I don't know how the type flag 
>> might be used later on, if at all.  I suspect it is just 
>> informational and can be ignored.
>>
> I think the former is best as well.  The type sets a flag in the 
> AnswerHash to 'strict_str_cmp' (the default is 'str_cmp') in case some 
> filter needs to know what kind of answer_evaluator  it is dealing 
> with.  So far it's most useful when trying to debug an answer 
> evaluator.  I think
> we can use 'str_cmp' as the answer evaluator type for all of the 
> special cases.
>
>> Also, do you prefer
>>
>>     str_cmp("foobar",filters=>'trim_whitespace')
>>
>> or just
>>
>>     str_cmp("foobar",'trim_whitespace')
>>
>> as the result?
>>
> As long as we are converting I think I prefer
>           str_cmp("foobar", filters=>['trim_whitespace'])
>
> since there will be examples where more than one filter is needed.  
> The default
> is actually
>
> 'filters'               =>  [qw(trim_whitespace compress_whitespace 
> ignore_case)]
>
> str_cmp will accept a variable as if it were an array with one 
> element, but as a model
> I suggest we use the square brackets.
>
> I do want to use the    filters => .....    however.  I think the 
> model of
>
> ans_evaluator( var or arrayRef,   %options)
>
> is something that we can make fairly universal.  At least I'd like to 
> try.
>
>>> Here are some examples of str_cmp
>>> I found in actual problems:
>>>
>>> ANS( str_cmp( $ml -> ra_correct_ans ) );  # no change needed here
>>
>>
>> right
>>
>>> ANS(std_num_str_cmp($ans, ['N']));         # make sure this is 
>>> handled properly
>>
>>
>> That one should already be handled by the version you have.  It is 
>> converted to
>>
>>     ANS(num_cmp($ans, strings=>['N']));
>>
>> which is what you want, right?
>>
> That's correct.
>
>> I'll send an updated version when I know how to handle the 'type' 
>> flag above.
>>
>> Davide
>>
> Thanks.
>
> Take care,
>
> Mike
>
>
>
> -------------------------------------------------------
> 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] A table of existing macros

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

On Jul 6, 2005, at 11:58 AM, Davide P.Cervone wrote:

>> This script is great.
>> I've converted the rochester problem library and haven't found
>> any glitches yet.
>
> I'm glad it is working out for you.
>
>> I think we should add the string compare functions as well.
>
> OK, no problem.  I'll add them to the table of routines to convert.  I 
> notice in PGanswermacros.pl that in addition to setting the filters, 
> they also set a type flag.  Do you want that to be included in the 
> conversion?  That is, should
>
> 	strict_str_cmp("foobar")
>
> produce
>
> 	str_cmp("foobar",filters=>'trim_whitespace')
> or
> 	str_cmp("foobar",filters=>'trim_whitespace', type=>'strict_str_cmp')
>
> I think it should be the former, but I don't know how the type flag 
> might be used later on, if at all.  I suspect it is just informational 
> and can be ignored.
>
I think the former is best as well.  The type sets a flag in the 
AnswerHash to 'strict_str_cmp' (the default is 'str_cmp') in case some 
filter needs to know what kind of answer_evaluator  it is dealing with. 
  So far it's most useful when trying to debug an answer evaluator.  I 
think
we can use 'str_cmp' as the answer evaluator type for all of the 
special cases.
> Also, do you prefer
>
> 	str_cmp("foobar",filters=>'trim_whitespace')
>
> or just
>
> 	str_cmp("foobar",'trim_whitespace')
>
> as the result?
>
As long as we are converting I think I prefer
           str_cmp("foobar", filters=>['trim_whitespace'])

since there will be examples where more than one filter is needed.  The 
default
is actually

'filters'               =>  [qw(trim_whitespace compress_whitespace 
ignore_case)]

str_cmp will accept a variable as if it were an array with one element, 
but as a model
I suggest we use the square brackets.

I do want to use the    filters => .....    however.  I think the model 
of

ans_evaluator( var or arrayRef,   %options)

is something that we can make fairly universal.  At least I'd like to 
try.

>> Here are some examples of str_cmp
>> I found in actual problems:
>>
>> ANS( str_cmp( $ml -> ra_correct_ans ) );  # no change needed here
>
> right
>
>> ANS(std_num_str_cmp($ans, ['N']));         # make sure this is 
>> handled properly
>
> That one should already be handled by the version you have.  It is 
> converted to
>
> 	ANS(num_cmp($ans, strings=>['N']));
>
> which is what you want, right?
>
That's correct.
> I'll send an updated version when I know how to handle the 'type' flag 
> above.
>
> Davide
>
Thanks.

Take care,

Mike

Re: [WWdevel] A table of existing macros

[Davide P.C. <dp...@un...>]

> This script is great.
> I've converted the rochester problem library and haven't found
> any glitches yet.

I'm glad it is working out for you.

> I think we should add the string compare functions as well.

OK, no problem.  I'll add them to the table of routines to convert.  I 
notice in PGanswermacros.pl that in addition to setting the filters, 
they also set a type flag.  Do you want that to be included in the 
conversion?  That is, should

	strict_str_cmp("foobar")

produce

	str_cmp("foobar",filters=>'trim_whitespace')
or
	str_cmp("foobar",filters=>'trim_whitespace', type=>'strict_str_cmp')

I think it should be the former, but I don't know how the type flag 
might be used later on, if at all.  I suspect it is just informational 
and can be ignored.

Also, do you prefer

	str_cmp("foobar",filters=>'trim_whitespace')

or just

	str_cmp("foobar",'trim_whitespace')

as the result?

> Here are some examples of str_cmp
> I found in actual problems:
>
> ANS( str_cmp( $ml -> ra_correct_ans ) );  # no change needed here

right

> ANS(std_num_str_cmp($ans, ['N']));         # make sure this is handled 
> properly

That one should already be handled by the version you have.  It is 
converted to

	ANS(num_cmp($ans, strings=>['N']));

which is what you want, right?

I'll send an updated version when I know how to handle the 'type' flag 
above.

Davide

[WWdevel] Fwd: tagged CVS at rel-2-1-2-5

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

Begin forwarded message:

> From: "Michael E. Gage" <ga...@ma...>
> Date: July 5, 2005 18:27:01 EDT
> To: "Davide P.Cervone" <dp...@un...>, Gavin LaRose  
> <gl...@um...>, Sam Hathaway <sh...@ma...>
> Cc: Michael Gage <ga...@ma...>, Arnold Pizer  
> <ap...@ma...>
> Subject: tagged CVS at rel-2-1-2-5
>
>
> Hi all,
>
> I've put a safety tag on the CVS so we can back up if something  
> goes wrong with merging
> in the Gateway files from rel-2-1-2-a1.
>
> Gavin if there is a group of files you want to throw to me to  
> resolve conflicts I'll be glad to handle it.  I'll have some time  
> later tonight, but I'll be away for awhile starting on Thursday.
>
> Just send me the file or directory names.
>
> Take care,
>
> Mike
>
>

Re: [WWdevel] A table of existing macros

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

On Jul 5, 2005, at 8:02 AM, Davide P.Cervone wrote:

>> I've made a chart of most of the macros currently available for use in
>> WeBWorK problem  (this includes macros from union_problib/macros, but  
>> not
>> yet the macros from nau_problib/macros)
>
> This looks like a good start, and a useful thing, though it is going  
> to be a pain to maintain.  I wonder if we should institute some kind  
> of coding convention to help automatically separate the internal  
> routines from the public ones.  (Or do you envision maintaining this  
> by hand from now on?)
>
I can recreate it by hand if need be.  It's a pain and takes an hour or  
so to clean it up using BBedit. Eventually I could automate it if it  
proves useful.  It will be even more of pain to maintain the comments.   
For the moment I view it as a transitional document, to see where we  
are and what needs to be done.

> I'm not quite sure I think the last column is necessary, as it is  
> usually incomplete.
>
The third column is really for comments.  For those items that haven't  
been commented on it
just contains "{ " and sometimes a little code or a comment.  I was too  
lazy to clean the code, even though it's not hard to do.  Sometimes the  
comment is useful.

>> There are over 900 macros -- way too many -- so some consolidation is  
>> in order and the place to start would be to try to get a handle on  
>> what has already been produced and how they overlap.
>
> In addition to the suggestions that you recommend concerning the older  
> anser macros, quite a few of the parser-based routines are internal  
> and shouldn't be listed.  For example, pretty much everything in  
> context*.pl is internal.  You might even consider not including any of  
> the parser stuff here, as that is a whole other ball of wax, and only  
> a portion of its routines are in .pl files.
>
> This brings up the point that there are many important macros that are  
> part of the .pm files in pg/lib rather than .pl files in pg/macros.   
> The various list macros come to mind, and so on.  Should they be  
> included here?
>
The list is still incomplete.  It does not include the .pm files or any  
of the NAU files.  Most of the .pm methods  are either internal
or high-level, but not all of them.   I included the parser files  
mainly because I wanted to reveal any overlap with existing routines.   
That helps us understand which macros can be retired.

I view this document as useful to developers more than to problem  
writers and other users.  An abortive attempt to write manpages for the  
useful and common routines is listed at  
http://webhost.math.rochester.edu/webworkdocs/docs/pglanguage/manpages/ 
.  It  is bogged down because I'm the main contributor and because the  
best input method is using the radio/frontier outliner.  I suspect that  
I could generalize the input to handle any outliner that
uses OPML as an output or export format.  (I also have an poorly  
maintained script that will produce TeX output from the same outlines.)  
  I like the format for the routines (which I borrowed from  
docserver.userland.com), but I'm not wedded to the input mechanism.  If  
someone has a good idea of how to easily input and maintain the data  
currently in the manpages -- particularly if we can reformat that same  
data for TeX or XML or other formats, let's hear it.  Good manpages are  
becoming a high priority.

> Also, some of the routines listed are part of packages and can't be  
> called directly.  They either are object methods, or require package  
> names (package::routine).
>
>> One of my desires is to replace the calls such as
>>
>> strict_num_cmp( $ans, .001,'%0.5f')
>> by
>> num_cmp($ans, relTol=>.001, format=>'%0.5f', mode=>'strict')
>>
>> and
>>
>> strict_num_cmp_list(.001, '%0.5f',$ans1, $ans2, $ans3);
>>
>> by
>>
>> num_cmp([$ans1, $ans2, $ans3], relTol=>.001, mode=>'strict',  
>> format=>'%o.5f');
>>
>> perhaps a dozen different subroutines can be replaced by using num_cmp
>> with either a single answer, or a reference to an array of answers  
>> and then
>> followed by a list of parameters.
>

> This is admirable, but I'm not holding my breath to see people convert  
> their old problems or stop using the older forms in new ones.  If you  
> do actually remove them from PGanswermacros.pl, that will break lots  
> of existing problems, and while that will force them to update (or at  
> least to add PGcompatibility.pl to those files), it will also be a big  
> aggravation to them.  The huge number of different forms of these  
> macros is a pain, though, so I understand the desire to eliminate some  
> of them.
>
> It would not be too hard to write a script that does that conversion,  
> I would expect.  That would help people out.
>
Many of the people who might be most aggravated are using un-retouched  
versions of the rochester problem library.  By updating the library  
either by CVS or by tarball they'd have working problems.   
Unfortunately the aggravation will increase rather than decrease with  
time.  Since there are a number of new problem developers coming on  
board now, and hopefully new cleaned up problems will arrive by the end  
of the summer, now is probably as good a time as any to clean house.   
Writing transition scripts is also a good idea.

Take care,

Mike

> Davide
>

Re: [WWdevel] A table of existing macros

[Davide P.C. <dp...@un...>]

> I've made a chart of most of the macros currently available for use in
> WeBWorK problem  (this includes macros from union_problib/macros, but 
> not
> yet the macros from nau_problib/macros)

This looks like a good start, and a useful thing, though it is going to 
be a pain to maintain.  I wonder if we should institute some kind of 
coding convention to help automatically separate the internal routines 
from the public ones.  (Or do you envision maintaining this by hand 
from now on?)

I'm not quite sure I think the last column is necessary, as it is 
usually incomplete.

> There are over 900 macros -- way too many -- so some consolidation is 
> in order and the place to start would be to try to get a handle on 
> what has already been produced and how they overlap.

In addition to the suggestions that you recommend concerning the older 
anser macros, quite a few of the parser-based routines are internal and 
shouldn't be listed.  For example, pretty much everything in 
context*.pl is internal.  You might even consider not including any of 
the parser stuff here, as that is a whole other ball of wax, and only a 
portion of its routines are in .pl files.

This brings up the point that there are many important macros that are 
part of the .pm files in pg/lib rather than .pl files in pg/macros.  
The various list macros come to mind, and so on.  Should they be 
included here?

Also, some of the routines listed are part of packages and can't be 
called directly.  They either are object methods, or require package 
names (package::routine).

> One of my desires is to replace the calls such as
>
> strict_num_cmp( $ans, .001,'%0.5f')
> by
> num_cmp($ans, relTol=>.001, format=>'%0.5f', mode=>'strict')
>
> and
>
> strict_num_cmp_list(.001, '%0.5f',$ans1, $ans2, $ans3);
>
> by
>
> num_cmp([$ans1, $ans2, $ans3], relTol=>.001, mode=>'strict', 
> format=>'%o.5f');
>
> perhaps a dozen different subroutines can be replaced by using num_cmp
> with either a single answer, or a reference to an array of answers and 
> then
> followed by a list of parameters.

This is admirable, but I'm not holding my breath to see people convert 
their old problems or stop using the older forms in new ones.  If you 
do actually remove them from PGanswermacros.pl, that will break lots of 
existing problems, and while that will force them to update (or at 
least to add PGcompatibility.pl to those files), it will also be a big 
aggravation to them.  The huge number of different forms of these 
macros is a pain, though, so I understand the desire to eliminate some 
of them.

It would not be too hard to write a script that does that conversion, I 
would expect.  That would help people out.

Davide

[WWdevel] A table of existing macros

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

Hello all,


I've made a chart of most of the macros currently available for use in
WeBWorK problem  (this includes macros from union_problib/macros, but  
not
yet the macros from nau_problib/macros)

It was made essentially by searching   for
/^sub /
in the macro files, followed by a bit of text cleaning.  You can find  
them displayed
on the twiki at

http://devel.webwork.rochester.edu/twiki/bin/view/Webwork/PGmacrosByFile

and at

http://devel.webwork.rochester.edu/twiki/bin/view/Webwork/ 
PGmacrosSortedAlphabetically

The first link is easier to keep up to date.  The chart is already  
slightly obsolete since I've made some changes in the macro files.  I  
am also writing notes indicating which subroutines should be  
deprecated, which ones are really obsolete and should never be used,  
which ones are actually internal and should not be available to a  
problem writer and so forth.

It's on the twiki, so you are all invited to help with the editing and  
notating.

There are over 900 macros -- way too many -- so some consolidation is  
in order and the place to start would be to try to get a handle on what  
has already been produced and how they overlap.

One of my desires is to replace the calls such as

strict_num_cmp( $ans, .001,'%0.5f')
by
num_cmp($ans, relTol=>.001, format=>'%0.5f', mode=>'strict')

and

strict_num_cmp_list(.001, '%0.5f',$ans1, $ans2, $ans3);

by

num_cmp([$ans1, $ans2, $ans3], relTol=>.001, mode=>'strict',  
format=>'%o.5f');

perhaps a dozen different subroutines can be replaced by using num_cmp
with either a single answer, or a reference to an array of answers and  
then
followed by a list of parameters.

This is fairly similar to the style that Mathematica uses and I think  
that it will be easier
to remember, document and maintain.

I'm thinking of placing these calls in a "PGcompatibility.pl" file  
where they can
be called for those who want to use them, but taking them out of  
PGanswermacros.pl
and modifying the problems in rochester_problib that use them.

Similar savings can be made with the fun_cmp family.

This will also cut down substantially on the size of PGanswermacros.pl

I invite your comments.  Reply to this list.

Take care,

Mike

Re: [WWdevel] Backward-compatible Parser-based answer checkers

[Davide P.C. <dp...@un...>]

> OK.  I have one conflict.
>
> The terms such as    $matrix = new Matrix;
>
> (Matrix is the old style matrix) are not working -- probably a
> conflict with the Parser::Matrix objects.
>
> Nearly any example that uses PGmorematricmacros.pl or
> PGdiffeqmacros.pl will give an error about not being able
> to recognize Matrix.

OK, I'll look into it.  The only thing I can think of that would cause 
this is the presence of the Matrix subroutine (which is being defined 
by Parser.pl, which PGanwermacros.pl now loads).  Parser::Matrix won't 
conflict directly with Matrix, or we would have seen that long ago, I 
think, as the Parser::Matrix package has been loaded with the Parser 
from the very beginning.

Davide

Re: [WWdevel] Backward-compatible Parser-based answer checkers

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

Hi Davide,

The conflict of the two versions of Matrix is real.  When I rename my 
version to
MatrixReal (and the file goes from Matrix.pm to MatrixReal.pm) then the 
problem goes
away.  For this test I just changed the one occurrence of Matrix in 
PGdiffeqmacros.pl.

I was always a little puzzled as to why this conflict didn't come up 
before.  I assume
because your type is really Parser::Matrix.

Take care,

Mike

Re: [WWdevel] Backward-compatible Parser-based answer checkers

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

Hi Davide,

OK.  I have one conflict.

The terms such as    $matrix = new Matrix;

(Matrix is the old style matrix) are not working -- probably a
conflict with the Parser::Matrix objects.

Nearly any example that uses PGmorematricmacros.pl or
PGdiffeqmacros.pl will give an error about not being able
to recognize Matrix.

Error detected while loading [PG]/macros/PGmorematrixmacros.pl: 
Bareword found where operator expected at line 11 of 
[PG]/macros/PGmorematrixmacros.pl, near "new Matrix"  Died within 
main::compile_file called at line 263 of [PG]/macros/dangerousMacros.pl 
  from within main::loadMacros called at line 8 of 
[TMPL]/setLinearAlgebra3Matrices/ur_la_3_23.pg


I'm starting to look at it, but you may have a better idea
of where to look.

It's not 100% guaranteed that this is due to your changes.
I've been making some as well.


Take care,

Mike

Re: [WWdevel] Backward-compatible Parser-based answer checkers

[Davide P.C. <dp...@un...>]

> This looks really neat.

Thanks, I think it is a step in the right direction.

> I volunteer to look into rewriting BASIS_CMP to using the MultiPart 
> object
> unless someone thinks this is a bad idea.

It is worth trying out.  One thing to keep in mind:  the MultiPart 
object is intimately tied to the Parser objects, so it only works with 
Parser-based objects (and not with other answer checkers, including the 
retro-fitted tranditional ones).  Also, remember that the answer blanks 
are produced by the MultiPart object, so you need to create it BEFORE 
the answer blanks are generated.  That means it probably will require 
changes in the problem file.

Davide

Re: [WWdevel] Backward-compatible Parser-based answer checkers

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

Hi Davide,

This looks really neat.

I volunteer to look into rewriting BASIS_CMP to using the MultiPart 
object
unless someone thinks this is a bad idea.

Take care,

Mike

[WWdevel] Backward-compatible Parser-based answer checkers

[Davide P.C. <dp...@un...>]

Folks:

Over the long weekend, I have been working on a method of making the 
traditional answer checkers (like std_num_cmp() and fun_cmp()) use the 
new Parser, and I have a working version of PGanswermacros.pl that 
implements it.  It turns out not to have been as difficult as I thought 
it might be, and I think I was able to map all the various parameters 
onto corresponding Parser parameters successfully.  Of course, this is 
a pretty major switch, so there will be some problems, I'm sure.

I have created a new subdirectory of the Parser tree that contains the 
needed files.  It is pg/lib/Parser/Legacy, and there is a README file 
there that explains how to install and use it.  You should also update 
your copy of the Parser and Value packages, as there are some changes 
within them that I made while working on this.

Since PGanswermacros.pl is preloaded (unlike most .pl files), this 
means that the change has to be made for the whole server at once.  I 
have arranged, however, for the original answer checkers to remain 
available, and you can switch back on a site-wide, course-wide or 
problem-by-problem basis.  If you turn the new checkers OFF for the 
site, and ON for problem files that you want to test, you should be 
able to try this out even on an active system without causing trouble 
for existing courses.  Again, see the README for details.

All the changes to PGanswermacros.pl are in NUM_CMP and FUNCTION_CMP, 
which have been essentially replaced by functions that set up an 
appropriate Parser context, create a Parser object from the correct 
answer, and return its answer checker.  This effectively turns all the 
traditional answer checkers into ones that use the new Parser in a 
backward compatible way so that existing problem files do not need to 
be modified.  Any answer checkers that rely on the standard ones (like 
the ones in the union_problib) will also be taking advantage of the new 
Parser.  Note, however, that these replacement NUM_CMP() and 
FUNCTION_CMP() do not necessarily store the same values and fields in 
the AnswerHash, so code that takes advantage of private data from a 
checker's AnswerHash may no longer operate correctly.

I have not done a huge amount of testing in existing problem files, but 
I did run through some of the more complicated ones from the Union 
problem library that used nested answer checkers, and they seem to work 
OK.  Let me know if you try this out, and what results you get.  I'm 
sure it is not a finished product.

Davide

[WWdevel] Re: compression

[Arnold P. <ap...@ma...>]

>I have two questions about compression, one local and one global.  ...

It seems like this discussion should be taking place on the developers 
mailing list, where it would be archived for future reference.  Any chance 
that the messages about this could be added there somehow after the fact?

Davide


Prof. Arnold K. Pizer
Dept. of Mathematics
University of Rochester
Rochester, NY 14627
(585) 275-7767

[WWdevel] Re: compression

[Arnold P. <ap...@ma...>]

<html>
<body>
While it won't help the immediate situation it seems to me that this is a
case where maintaining <br>
session data our database would solve the problem cleanly and
efficiently.&nbsp; I'm not sure how <br>
far away we are from being able to do this.&nbsp; If the solution gets
too gnarly we can wait to add this feature once the infrastructure is in
place. <br><br>
Take care, <br><br>
Mike <br><br>
On Jun 24, 2005, at 12:07 PM, Arnold Pizer wrote: <br><br>
<blockquote type=3Dcite class=3Dcite cite=3D"">At 05:11 PM 6/23/2005, John
Jones wrote: <br>
<blockquote type=3Dcite class=3Dcite cite=3D"">Arnold Pizer wrote: <br>
<blockquote type=3Dcite class=3Dcite cite=3D"">Hi, <br><br>
I have two questions about compression, one local and one global.
<br><br>
The local one:&nbsp; In UserList.pm&nbsp; you can now sort by clicking on
a label which uses the GET method (I experimented with a POST method but
it didn't look good).You could still have links and use POST if you used
a little javascript.&nbsp; After all, this page <i>already</i> uses
javascript in the upper portion.&nbsp; As long as the fallback for people
who don't have javascript enabled is not too confusing, it seems like a
reasonable approach.&nbsp; For example, the link could be to a separate
window which just says that you need javascript enabled for the link to
work, and then have javascript handle &quot;onclick&quot; so that if you
do have javascript, you get the result of the JS (which would be the form
submission), otherwise you get the separate window explaining why nothing
good happened. </blockquote></blockquote>Thanks for the idea.&nbsp;
Javascript may be the way to go. This will only appear on an instructor's
page and (at least on this page) their are alternate ways to sort.
<br><br>
<blockquote type=3Dcite class=3Dcite cite=3D"">I don't see a problem.&nbsp; =
It
doesn't seem hard to install - I just tried on a relatively new server
and it was already installed. <br>
<blockquote type=3Dcite class=3Dcite cite=3D"">The Global question.&nbsp; Wo=
uld
it be a good idea to consider and/or experiment with using something like
Apache::Dynagzip to compress all WeBWorK output?&nbsp; Look at
<a href=3D"http://perl.apache.org/docs/tutorials/client/compression/compress=
ion.html">
<font color=3D"#0000EE">
http://perl.apache.org/docs/tutorials/client/compression/compression.html</a=
>
</font> for a discussion of this. </blockquote></blockquote>That's the
way it looks to me. If we experiment with this and it seems worthwhile,
we could suggest that people configure their apache to take advantage of
this. <br><br>
Arnie <br><br>
<br>
<blockquote type=3Dcite class=3Dcite cite=3D"">John
</blockquote></blockquote><br>
<x-sigsep><p></x-sigsep>
Prof. Arnold K. Pizer <br>
Dept. of Mathematics <br>
University of Rochester <br>
Rochester, NY 14627 <br>
(585) 275-7767<br>
</body>
</html>

[WWdevel] Re: compression

[Arnold P. <ap...@ma...>]

<html>
<body>
At 05:11 PM 6/23/2005, John Jones wrote:<br>
<blockquote type=cite class=cite cite="">Arnold Pizer wrote: <br>
<blockquote type=cite class=cite cite="">Hi, <br><br>
I have two questions about compression, one local and one global.
<br><br>
The local one:&nbsp; In UserList.pm&nbsp; you can now sort by clicking on
a label which uses the GET method (I experimented with a POST method but
it didn't look good).</blockquote>You could still have links and use POST
if you used a little javascript.&nbsp; After all, this page
<i>already</i> uses javascript in the upper portion.&nbsp; As long as the
fallback for people who don't have javascript enabled is not too
confusing, it seems like a reasonable approach.&nbsp; For example, the
link could be to a separate window which just says that you need
javascript enabled for the link to work, and then have javascript handle
&quot;onclick&quot; so that if you do have javascript, you get the result
of the JS (which would be the form submission), otherwise you get the
separate window explaining why nothing good happened.</blockquote><br>
Thanks for the idea.&nbsp; Javascript may be the way to go. This will
only appear on an instructor's page and (at least on this page) their are
alternate ways to sort.<br><br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite="">The problem is ... people would
have to install compress::Zlib.&nbsp; Does anyone have an objection to
this?&nbsp; Would this be useful in other places?&nbsp; Is there a better
compression module?</blockquote>I don't see a problem.&nbsp; It doesn't
seem hard to install - I just tried on a relatively new server and it was
already installed.<br>
<blockquote type=cite class=cite cite="">The Global question.&nbsp; Would
it be a good idea to consider and/or experiment with using something like
Apache::Dynagzip to compress all WeBWorK output?&nbsp; Look at
<a href="http://perl.apache.org/docs/tutorials/client/compression/compression.html">
http://perl.apache.org/docs/tutorials/client/compression/compression.html</a>
 for a discussion of this. </blockquote>Looks interesting.&nbsp; I don't
know so much about how webwork integrates into apache, but this looks
like something sites can experiment with independently, modifying their
apache installation rather than changing anything in webwork,
right?</blockquote><br>
That's the way it looks to me. If we experiment with this and it seems
worthwhile, we could suggest that people configure their apache to take
advantage of this.<br><br>
Arnie<br><br>
<br>
<blockquote type=cite class=cite cite="">John</blockquote><br>
<x-sigsep><p></x-sigsep>
Prof. Arnold K. Pizer <br>
Dept. of Mathematics <br>
University of Rochester <br>
Rochester, NY 14627 <br>
(585) 275-7767<br>
</body>
</html>

[WWdevel] Re: compression

[Arnold P. <ap...@ma...>]

<html>
<body>
Arnold Pizer wrote: <br>
<blockquote type=cite class=cite cite="">Hi, <br><br>
I have two questions about compression, one local and one global.
<br><br>
The local one:&nbsp; In UserList.pm&nbsp; you can now sort by clicking on
a label which uses the GET method (I experimented with a POST method but
it didn't look good).</blockquote>You could still have links and use POST
if you used a little javascript.&nbsp; After all, this page
<i>already</i> uses javascript in the upper portion.&nbsp; As long as the
fallback for people who don't have javascript enabled is not too
confusing, it seems like a reasonable approach.&nbsp; For example, the
link could be to a separate window which just says that you need
javascript enabled for the link to work, and then have javascript handle
&quot;onclick&quot; so that if you do have javascript, you get the result
of the JS (which would be the form submission), otherwise you get the
separate window explaining why nothing good happened.<br>
<blockquote type=cite class=cite cite="">The problem is ... people would
have to install compress::Zlib.&nbsp; Does anyone have an objection to
this?&nbsp; Would this be useful in other places?&nbsp; Is there a better
compression module?</blockquote>I don't see a problem.&nbsp; It doesn't
seem hard to install - I just tried on a relatively new server and it was
already installed.<br>
<blockquote type=cite class=cite cite="">The Global question.&nbsp; Would
it be a good idea to consider and/or experiment with using something like
Apache::Dynagzip to compress all WeBWorK output?&nbsp; Look at
<a href="http://perl.apache.org/docs/tutorials/client/compression/compression.html">
http://perl.apache.org/docs/tutorials/client/compression/compression.html</a>
 for a discussion of this. </blockquote>Looks interesting.&nbsp; I don't
know so much about how webwork integrates into apache, but this looks
like something sites can experiment with independently, modifying their
apache installation rather than changing anything in webwork,
right?<br><br>
John<br><br>
<x-sigsep><p></x-sigsep>
Prof. Arnold K. Pizer <br>
Dept. of Mathematics <br>
University of Rochester <br>
Rochester, NY 14627 <br>
(585) 275-7767<br>
</body>
</html>