openwebwork-devel — WeBWorK development discussion

[WWdevel] How to announce important fixes to Parser

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

Hi Davide,


How about posting it on the news bulletin at http:// 
webhost.math.rochester.edu/WeBWorKdocs/
(click on the "news" button at  the top of your screen.  You have  
news posting privileges on webhost --
others can send me a bulletin and I'll post it. (I can do this for  
you as well if you like.) Those who
have hooked up to the RSS feed on the webwork homepage will get an  
RSS brief about the news item.


Take care,

Mike

On Sep 3, 2005, at 8:02 AM, Davide P. Cervone wrote:


> Folks:
>
> I just fixed an important bug in the Parser that prevented it from  
> properly comparing formulas that include arctangent function  
> calls.  Now that the Parser is in use for num_cmp and fun_cmp, it  
> seems to me that fixes for problems like this are more important  
> than they were in the past, and anyone who is using the Parser- 
> based legacy code (or native Parser-based problems) should update.   
> What is the best way to announce that?  Should there be a topic on  
> the discussion board where notices of important fixes are posted?   
> Is there a mailing list of WeBWorK administrators that it should be  
> sent to?
>
> Davide
>
>
>
>
>
> -------------------------------------------------------
> 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
>
>

"Only dead fish swim with the stream."




"Only dead fish swim with the stream."

[WWdevel] How to announce important fixes to Parser

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

Folks:

I just fixed an important bug in the Parser that prevented it from  
properly comparing formulas that include arctangent function calls.   
Now that the Parser is in use for num_cmp and fun_cmp, it seems to me  
that fixes for problems like this are more important than they were  
in the past, and anyone who is using the Parser-based legacy code (or  
native Parser-based problems) should update.  What is the best way to  
announce that?  Should there be a topic on the discussion board where  
notices of important fixes are posted?  Is there a mailing list of  
WeBWorK administrators that it should be sent to?

Davide

[WWdevel] Re: problem sets

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

On Sep 1, 2005, at 13:13, Michael Gage wrote:

> This all sounds good Sam.  We're obviously not going to do this  
> right away since the semester is just
> starting, but I'm glad you already have a lot of the functionality  
> in WWDBv3.

Yeah, nice that WWDBv3 isn't a total loss. :(

> I think if we make
> updating more transparent we can encourage more people to keep up  
> with the latest stable version
> and it will avoid a few of the problems we're having with people  
> complaining of bugs that are already
> fixed.

Yes.

[WWdevel] Re: problem sets

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

This all sounds good Sam.  We're obviously not going to do this right  
away since the semester is just
starting, but I'm glad you already have a lot of the functionality in  
WWDBv3.  I think if we make
updating more transparent we can encourage more people to keep up  
with the latest stable version
and it will avoid a few of the problems we're having with people  
complaining of bugs that are already
fixed.

Take care,

Mike

On Sep 1, 2005, at 12:52 PM, Sam Hathaway wrote:

> On Sep 1, 2005, at 11:00, Michael Gage wrote:
>
>
>> On Sep 1, 2005, at 10:50 AM, Sam Hathaway wrote:
>>
>>
>>> I agree. And we should fix the database import/export  
>>> functionality for 2.1.4 so that people can transfer their courses  
>>> from gdbm/sql to sql_single easily.
>>>
>>
>> Yes.  That would help a lot.  In addition we need facility that  
>> upgrades the structure of a sql database when it changes.  The update
>> facilities in moodle work very well in this regard.  When you  
>> update to a new version it triggers a module that updates the  
>> database.
>>
>
> Hi,
>
> I took a look at Moodle's database upgrade functionality in more  
> depth. Moodle stores the version of each module in a database  
> table. If the current version of a module is newer, it allows the  
> module to run a funtion that gets the old version number. This  
> function usually just adds/modifies/removes database tables, but it  
> can do other things, including modifying data in tables, etc.
>
> I've apparently done most of the work necessary for this already,  
> in the course of working on WWDBv3.
>
> The first thing we'll have to do is add a `setting` table and  
> define a `db_version` record in that table. This can actually be  
> done automatically, by checking for that table and record, and  
> adding them if they don't exist.
>
> Every time the database gets loaded, it will check the value of  
> `db_version`, and call a function for each version upgrade between  
> the value stored in `db_version` and the current version.
>
> Convenient things to do with this mechanism:
>
> * Add fields to tables, add new tables,
> * Normalize existing statuses in the database, once we figure out  
> what we're going to do about that.
> * Fix the NULL/empty string/zero situation.
> * This might be too ambitious, but we could probably use this  
> mechanism to split off the setversion information that's currently  
> encoded in the set ID (with ",v") into separate tables.
>
> It occurs to me that the system should automatically make backups  
> of the current database before modifying it.
> -sam
>
>
>

[WWdevel] Re: problem sets

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

On Sep 1, 2005, at 11:00, Michael Gage wrote:

> On Sep 1, 2005, at 10:50 AM, Sam Hathaway wrote:
>
>> I agree. And we should fix the database import/export  
>> functionality for 2.1.4 so that people can transfer their courses  
>> from gdbm/sql to sql_single easily.
>
> Yes.  That would help a lot.  In addition we need facility that  
> upgrades the structure of a sql database when it changes.  The update
> facilities in moodle work very well in this regard.  When you  
> update to a new version it triggers a module that updates the  
> database.

Hi,

I took a look at Moodle's database upgrade functionality in more  
depth. Moodle stores the version of each module in a database table.  
If the current version of a module is newer, it allows the module to  
run a funtion that gets the old version number. This function usually  
just adds/modifies/removes database tables, but it can do other  
things, including modifying data in tables, etc.

I've apparently done most of the work necessary for this already, in  
the course of working on WWDBv3.

The first thing we'll have to do is add a `setting` table and define  
a `db_version` record in that table. This can actually be done  
automatically, by checking for that table and record, and adding them  
if they don't exist.

Every time the database gets loaded, it will check the value of  
`db_version`, and call a function for each version upgrade between  
the value stored in `db_version` and the current version.

Convenient things to do with this mechanism:

* Add fields to tables, add new tables,
* Normalize existing statuses in the database, once we figure out  
what we're going to do about that.
* Fix the NULL/empty string/zero situation.
* This might be too ambitious, but we could probably use this  
mechanism to split off the setversion information that's currently  
encoded in the set ID (with ",v") into separate tables.

It occurs to me that the system should automatically make backups of  
the current database before modifying it.
-sam

Re: [WWdevel] Fwd: GDBM compatibility

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

<html>
<body>
At 08:54 AM 9/1/2005, Michael Gage wrote:<br><br>
<br>
How about having the admin course in versions
<font face="Courier, Courier">2.1.3 and above create only sql -single
databases and not mention databases at all.<br><br>
</font>Arnie<br><br>
<br><br>
<blockquote type=cite class=cite cite="">Begin forwarded
message:<br><br>
<blockquote type=cite class=cite cite="">
<font face="Helvetica, Helvetica"><b>From: </b>Michael Gage
&lt;<a href="mailto:ga...@ma...">ga...@ma...</a>
&gt;<br>
<b>Date: </b>September 1, 2005 8:52:54 AM EDT (CA)<br>
<b>To: </b>Sam Hathaway
&lt;<a href="mailto:sh...@ma...">
sh...@ma...</a>&gt;<br>
<b>Cc: </b>Michael Gage
&lt;<a href="mailto:ga...@ma...">ga...@ma...</a>
&gt;<br>
<b>Subject: Re: problem sets<br>
</b></font><br><br>
<br>
On Sep 1, 2005, at 1:10 AM, Sam Hathaway wrote:<br><br>
<blockquote type=cite class=cite cite="">On Aug 31, 2005, at 21:28,
Michael Gage wrote:<br><br>
<br>
<blockquote type=cite class=cite cite="">Hi Sam,<br><br>
If you get a chance could you build a gdbm database&nbsp;&nbsp; course
and see if we somehow introduced a bug in<br>
the gdbm database handling somewhere around version 2.1.3?&nbsp; I
haven't seen it on hosted, but who knows?<br>
</blockquote><br>
Sure, no problem.</blockquote>I looked at this a little bit.&nbsp; The
HEAD of cvs generates many errors just in creating set 0 with a gdbm
database:<br><br>
<font face="Courier, Courier">field set.0.assignment_type is not defined.
at
/home/gage/webwork/webwork-modperl/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetList.pm
line 1846.<br><br>
and so forth.<br><br>
I don't think we want to do all the back porting that would be necessary
to<br>
have the gateway quiz module run on gdbm.&nbsp; So the question
becomes<br>
how far back to we have to go to have scripts that are compatible with
gdbm.<br><br>
I suggest starting with the version 2.1.3&nbsp; which we established in
June, just <br>
before we added the code for the gateway quizzes. Establish a branch
there <br>
and put in the patches needed to make it run reasonably well with
gdbm.<br><br>
Versions after 2.1.3 will not support gdbm or sql database modes at
all.<br><br>
Take care,<br><br>
Mike<br><br>
<br><br>
</font><blockquote type=cite class=cite cite="">-sam<br><br>
</blockquote><br>
&quot;Only dead fish swim with the stream.&quot;<br><br>
</blockquote><br>
&quot;Only dead fish swim with the stream.&quot;<br><br>
</blockquote>
<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: Library browser -- version 2

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

Michael Gage wrote:

> What is the status of the library and the library browser?  Is it  
> ready for the rest of the developers to start using the version 2 of 
> the library browser and to update the  library? or do you have an 
> estimate as to when would be a good time for the rest of us to do  this? 

Please, try it out.  My only caveat has to do with compatibility with 
version 1.

The new version does not have all of the same problems the older version 
had.  Some may have been duplicates which were pruned.  Others may have 
been moved.  I plan to figure out where they all went, but this means 
set definition files created with the original version may point to 
places which don't exist in the current version.

You cannot have a course which accesses both since the link 
"templates/Library" points to the top of the directory tree.  I have 
wondered whether to have version 2 use "Library2" so you could have a 
course with both (toggling which one to use by the problem library 
version setting, which can go in course.conf).  I should say the 
database tables have new names, so mysql can have both the old data and 
the new data without conflict.

So, if you want to compare back and forth, you have to change the link 
under templates and change the version setting in a .conf file.

There are still issues with some of the tags themselves, but I am 
especially interested on feedback on the installation process, and the 
interface itself.

John

[WWdevel] Library browser -- version 2

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

Hi John,

What is the status of the library and the library browser?  Is it  
ready for the rest of the developers
to start using the version 2 of the library browser and to update the  
library? or do you have
an estimate as to when would be a good time for the rest of us to do  
this?

Take care,

Mike

[WWdevel] Fwd: GDBM compatibility

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

Begin forwarded message:

> From: Michael Gage <ga...@ma...>
> Date: September 1, 2005 8:52:54 AM EDT (CA)
> To: Sam Hathaway <sh...@ma...>
> Cc: Michael Gage <ga...@ma...>
> Subject: Re: problem sets
>
>
>
> On Sep 1, 2005, at 1:10 AM, Sam Hathaway wrote:
>
>> On Aug 31, 2005, at 21:28, Michael Gage wrote:
>>
>>
>>> Hi Sam,
>>>
>>> If you get a chance could you build a gdbm database   course and  
>>> see if we somehow introduced a bug in
>>> the gdbm database handling somewhere around version 2.1.3?  I  
>>> haven't seen it on hosted, but who knows?
>>>
>>
>> Sure, no problem.
> I looked at this a little bit.  The HEAD of cvs generates many  
> errors just in creating set 0 with a gdbm database:
>
> field set.0.assignment_type is not defined. at /home/gage/webwork/ 
> webwork-modperl/lib/WeBWorK/ContentGenerator/Instructor/ 
> ProblemSetList.pm line 1846.
>
> and so forth.
>
> I don't think we want to do all the back porting that would be  
> necessary to
> have the gateway quiz module run on gdbm.  So the question becomes
> how far back to we have to go to have scripts that are compatible  
> with gdbm.
>
> I suggest starting with the version 2.1.3  which we established in  
> June, just
> before we added the code for the gateway quizzes. Establish a  
> branch there
> and put in the patches needed to make it run reasonably well with  
> gdbm.
>
> Versions after 2.1.3 will not support gdbm or sql database modes at  
> all.
>
> Take care,
>
> Mike
>
>
>
>> -sam
>>
>>
>
> "Only dead fish swim with the stream."
>
>

"Only dead fish swim with the stream."

Re: [WWdevel] [WWdevel]: Library Browser (SetMaker) question: "combining up"

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

On Aug 31, 2005, at 16:51, Michael Gage wrote:

> What I'd REALLY like is resource forks for files a la the old mac  
> system --
> but that's not immediately available.  Perhaps there is some other  
> way to implement it.  How does the new Mac simulate
> "applications" that are really folders containing code files and  
> auxiliary files?

One option would be to define some kind of "PG package" format which  
would be a folder (perhaps with a .pgpkg extection) that would  
contain a .pg file, any number of auxiliary files, and perhaps a file  
containing metadata (maybe problem classification data).

This would be similar to the OS X bundle format that Apple has  
defined to replace dual-forked. See also <http://developer.apple.com/ 
documentation/CoreFoundation/Conceptual/CFBundles/>.
-sam

Re: [WWdevel] [WWdevel]: Library Browser (SetMaker) question: "combining up"

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

On Aug 31, 2005, at 3:08 PM, Davide P. Cervone wrote:

>> Michael Gage wrote:
>>
>>> Privately (but not formally) I had used the convention that when  
>>> constructing a directory contaning a
>>> .pg file and auxiliary files   that the  directory name was  
>>> related to the .pg name   e.g.  prob1/prob1.pg
>>>
>>> Would it be reasonable to add that condition to the default  
>>> method for "combining up"?  I know the rules I used for making  
>>> these problems, but I haven't searched through the rest of the  
>>> problem collections, so perhaps there are reasons not to do this.
>>>
>>
>> I am not sure I understand.  Is the suggestion that outside of  
>> other hints like =library-combine-up, a directory named this- 
>> directory containing one pg file problem.pg should not be combined  
>> up because the name of the pg file doesn't match the name of the  
>> directory?
>>
>
> I think what he is suggesting is that (in the absense of =library- 
> combine-up or =library-no-combine-up) a directory with one pg file  
> will be combined upward only if the directory name is the same as  
> the problem name. So prob1/prob1.pg would but setSparse/prob1.pg  
> would not.  I don't have any problem with that, but haven't looked  
> at hard it would be to accomplish it.  Should be straight forward,  
> I would think.
>
That's what I'm suggesting.  It is my private naming convention for  
problems with auxiliary files.
> Another possibility would be not to combine up into the top level  
> at all (unless explicitly requested).
>
  I'd prefer the currently implemented system to this.  The goal of  
representing a ".pg file with accompanying auxiliary files"
as a single problem in the library is the right approach.  The only  
question is how to best recognize when we are dealing
with a ".pg file with accompanying auziliary files".  What I'd REALLY  
like is resource forks for files a la the old mac system --
but that's not immediately available.  Perhaps there is some other  
way to implement it.  How does the new Mac simulate
"applications" that are really folders containing code files and  
auxiliary files?

>
>>> On Aug 31, 2005, at 8:20 AM, Davide P. Cervone wrote:
>>>
>>>> Yes, that was the problem.  I still can't think of a better  
>>>> name, can anyone else?  "Toplevel Problems"?  "Unclassified  
>>>> Problems"?
>>>>
>>
>> I don't have strong feelings about this, especially since it  
>> should be a moot question (a standard problem collection probably  
>> shouldn't have problems there).  But, now that I think about it,  
>> Unclassified might be better than Main or Toplevel.  The latter  
>> two could be construed as meaning that these problems are  
>> especially important.  But, Unclassified could inaccurate if a  
>> problem is the lone problem in its classification.  How about  
>> "Misc. Problems"?
>>
>
> That would be fine by me.  It is easy to change, since there is a  
> constant at the top of the file for the phrase to be used.
>
Unclassified sounds good to me.

Take care,

Mike

> Davide
>
>
> -------------------------------------------------------
> 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
>

Re: [WWdevel] [WWdevel]: Library Browser (SetMaker) question: "combining up"

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

> Michael Gage wrote:
>> Privately (but not formally) I had used the convention that when  
>> constructing a directory contaning a
>> .pg file and auxiliary files   that the  directory name was  
>> related to the .pg name   e.g.  prob1/prob1.pg
>>
>> Would it be reasonable to add that condition to the default method  
>> for "combining up"?  I know the rules I used for making these  
>> problems, but I haven't searched through the rest of the problem  
>> collections, so perhaps there are reasons not to do this.
>
> I am not sure I understand.  Is the suggestion that outside of  
> other hints like =library-combine-up, a directory named this- 
> directory containing one pg file problem.pg should not be combined  
> up because the name of the pg file doesn't match the name of the  
> directory?

I think what he is suggesting is that (in the absense of =library- 
combine-up or =library-no-combine-up) a directory with one pg file  
will be combined upward only if the directory name is the same as the  
problem name. So prob1/prob1.pg would but setSparse/prob1.pg would  
not.  I don't have any problem with that, but haven't looked at hard  
it would be to accomplish it.  Should be straight forward, I would  
think.

Another possibility would be not to combine up into the top level at  
all (unless explicitly requested).

>> On Aug 31, 2005, at 8:20 AM, Davide P. Cervone wrote:
>>> Yes, that was the problem.  I still can't think of a better name,  
>>> can anyone else?  "Toplevel Problems"?  "Unclassified Problems"?
>
> I don't have strong feelings about this, especially since it should  
> be a moot question (a standard problem collection probably  
> shouldn't have problems there).  But, now that I think about it,  
> Unclassified might be better than Main or Toplevel.  The latter two  
> could be construed as meaning that these problems are especially  
> important.  But, Unclassified could inaccurate if a problem is the  
> lone problem in its classification.  How about "Misc. Problems"?

That would be fine by me.  It is easy to change, since there is a  
constant at the top of the file for the phrase to be used.

Davide

Re: [WWdevel] [WWdevel]: Library Browser (SetMaker) question: "combining up"

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

Michael Gage wrote:

> Privately (but not formally) I had used the convention that when 
> constructing a directory contaning a 
> .pg file and auxiliary files   that the  directory name was related to 
> the .pg name   e.g.  prob1/prob1.pg
>
> Would it be reasonable to add that condition to the default method for 
> "combining up"?  I know the rules I used for making these problems, 
> but I haven't searched through the rest of the problem collections, so 
> perhaps there are reasons not to do this.

I am not sure I understand.  Is the suggestion that outside of other 
hints like =library-combine-up, a directory named this-directory 
containing one pg file problem.pg should not be combined up because the 
name of the pg file doesn't match the name of the directory?

> On Aug 31, 2005, at 8:20 AM, Davide P. Cervone wrote:
>
>> Yes, that was the problem.  I still can't think of a better name, can 
>> anyone else?  "Toplevel Problems"?  "Unclassified Problems"?
>
I don't have strong feelings about this, especially since it should be a 
moot question (a standard problem collection probably shouldn't have 
problems there).  But, now that I think about it, Unclassified might be 
better than Main or Toplevel.  The latter two could be construed as 
meaning that these problems are especially important.  But, Unclassified 
could inaccurate if a problem is the lone problem in its 
classification.  How about "Misc. Problems"?

John

[WWdevel] [WWdevel]: Library Browser (SetMaker) question: "combining up"

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

Thanks Davide and John.

I've got it.  Thanks.  I'm happy with the "Main problems" label, but  
I was puzzled that they were not toplevel problems.
  I guess I was paying attention when this improvement came through  
last September, so I was a bit
puzzled by the behavior.

Privately (but not formally) I had used the convention that when  
constructing a directory contaning a
.pg file and auxiliary files   that the  directory name was related  
to the .pg name   e.g.  prob1/prob1.pg

Would it be reasonable to add that condition to the default method  
for "combining up"?  I know the rules
I used for making these problems, but I haven't searched through the  
rest of the problem collections, so perhaps
there are reasons not to do this.

Take care,

Mike


On Aug 31, 2005, at 8:20 AM, Davide P. Cervone wrote:

>> With the extra  buttons like Rochester Library, there is the same  
>> sort of question: how should the top level directory within the  
>> Rochester Library appear in the list of directories.  They aren't  
>> "My Problems" since by design, one probably doesn't have write  
>> access to them.  So, I guess Davide called them Main Problems,  
>> probably because it is hard thinking of a good name for them.
>>
>
> Yes, that was the problem.  I still can't think of a better name,  
> can anyone else?  "Toplevel Problems"?  "Unclassified Problems"?
>
>
>> There is a way to turn off the "combine a directory up" feature  
>> for an individual directory.  If the standard Rochester library  
>> has single problem directories at its top level, then you might  
>> want to include the required file in those directories so they  
>> don't get promoted to Main Problems.
>>
>
> The CVS log entry for version 1.26 of SetMaker.pm explains the  
> method for doing this, in case anyone wants to give SetMaker these  
> extra hints about how to show their library's problems.
>
> Davide
>
>

This patch modified the Library Browser so that these single-pg-file
directories are merged with their parents, as long as they also
include other non-pg-files.

It also provides a method of controling the library browser on a
directory-by-directory basis using specially named files.  If a
directory contains a file named "=library-ignore", then the directory
is never shown in the directory menu.  If it contains a file called
"=library-combine-up", then its contents are considered to be part of
the parent directory, even if it has more than one pg file.  If it
contains one called "=library-no-combine", then the directory is
always listed separately in the menu, even if it has only one pg file.

Re: [WWdevel] Re: [webwork-user] Re: pdf generation problem and image problem

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

At 11:18 PM 8/29/2005, Sam Hathaway wrote:

I just uploaded the following change to Constants.pm

################################################################################
# WeBWorK::PG::ImageGenerator
################################################################################

# Arguments to pass to dvipng. This is dependant on the version of dvipng.
#
# For dvipng versions 0.x
#     $WeBWorK::PG::ImageGenerator::DvipngArgs = "-x4000.5 -bgTransparent 
-Q6 -mode toshiba -D180";
# For dvipng versions 1.0 to 1.5
#     $WeBWorK::PG::ImageGenerator::DvipngArgs = "-bgTransparent -D120 -q 
-depth";
#
# For dvipng versions 1.6 (and probably above)
#     $WeBWorK::PG::ImageGenerator::DvipngArgs = "-bgtransparent -D120 -q 
-depth";
# Note: In 1.6 and later, bgTransparent gives alpha-channel transparency while
# bgtransparent gives single-bit transparency. If you use alpha-channel 
transparency,
# the images will not be viewable with MSIE.  bgtransparent works for 
versions lower
# than 1.6, but does not give transparent backgrounds.
#
$WeBWorK::PG::ImageGenerator::DvipngArgs = "-bgtransparent -D120 -q -depth";

I think this is a reasonable compromise. Note that at least for dvipng 1.5 
there is a difference between
-bgTransparent and -bgtransparent but at least both do work.  When I looked 
for documentation all I found
was "-bg s" where "s" is TeX-style colors but I never found a list of 
TeX-style colors.

Arnie

>On Aug 29, 2005, at 20:02, Davide P.Cervone wrote:
>
>>>>If you change -bgTransparent to -bgtransparent (i.e., remove the
>>>>capitalization)
>>>
>>>Is this a bug in Constants.pm?
>>
>>No, it's a bug in MSIE.  :-)
>>
>>In dvipng prior to version 1.6, both forms meant the same thing.
>>In 1.6 and later, the first gets you alpha-channel transparency
>>while the second gets your single-bit transparency.  While every
>>other modern browser handles alpha-channel transparency, MSIE only
>>does this if you include a horrible proprietary call to a special
>>image filter that references the alpha image and link the source
>>image to a blank image file (if I remember correctly).  I would
>>love to switch to alpha-channel transparency so that the background
>>colors work better, but as long as we are saddled with the
>>lumbering and decrepit beast known as MSIE, we have to dump down to
>>its (in-)capabilities.  Not that I'm upset by this.  >:-p
>>
>>The upshot is, though, that Constants.pm probably should have the
>>lower-case transparency to avoid the alpha-channel problem.
>
>Right, that's what I meant. -bgTransparent is not a valid switch to
>dvipng, so Constants.pm is wrong.
>  -sam
>
>
>

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

[WWdevel] Re: [webwork-user] Re: pdf generation problem and image problem

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

On Aug 29, 2005, at 20:02, Davide P.Cervone wrote:

>>> If you change -bgTransparent to -bgtransparent (i.e., remove the  
>>> capitalization)
>>>
>>
>> Is this a bug in Constants.pm?
>
> No, it's a bug in MSIE.  :-)
>
> In dvipng prior to version 1.6, both forms meant the same thing.   
> In 1.6 and later, the first gets you alpha-channel transparency  
> while the second gets your single-bit transparency.  While every  
> other modern browser handles alpha-channel transparency, MSIE only  
> does this if you include a horrible proprietary call to a special  
> image filter that references the alpha image and link the source  
> image to a blank image file (if I remember correctly).  I would  
> love to switch to alpha-channel transparency so that the background  
> colors work better, but as long as we are saddled with the  
> lumbering and decrepit beast known as MSIE, we have to dump down to  
> its (in-)capabilities.  Not that I'm upset by this.  >:-p
>
> The upshot is, though, that Constants.pm probably should have the  
> lower-case transparency to avoid the alpha-channel problem.

Right, that's what I meant. -bgTransparent is not a valid switch to  
dvipng, so Constants.pm is wrong.
  -sam

[WWdevel] Re: [webwork-user] Re: pdf generation problem and image problem

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

>> If you change -bgTransparent to -bgtransparent (i.e., remove the 
>> capitalization)
>
> Is this a bug in Constants.pm?

No, it's a bug in MSIE.  :-)

In dvipng prior to version 1.6, both forms meant the same thing.  In 
1.6 and later, the first gets you alpha-channel transparency while the 
second gets your single-bit transparency.  While every other modern 
browser handles alpha-channel transparency, MSIE only does this if you 
include a horrible proprietary call to a special image filter that 
references the alpha image and link the source image to a blank image 
file (if I remember correctly).  I would love to switch to 
alpha-channel transparency so that the background colors work better, 
but as long as we are saddled with the lumbering and decrepit beast 
known as MSIE, we have to dump down to its (in-)capabilities.  Not that 
I'm upset by this.  >:-p

The upshot is, though, that Constants.pm probably should have the 
lower-case transparency to avoid the alpha-channel problem.

Davide

[WWdevel] Re: [webwork-user] Re: pdf generation problem and image problem

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

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

On Aug 29, 2005, at 23:00, dp...@un... wrote:

> If you change -bgTransparent to -bgtransparent (i.e., remove the  
> capitalization)

Is this a bug in Constants.pm?
  -sam

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

iD8DBQFDE5qq14CQX+2WvVgRAsjgAJ9FnDXRfkAFdOWBO3qahqspgUWyAACdHxs0
+rTVem+WOlmrrmNZa0pzrdU=
=Bdc+
-----END PGP SIGNATURE-----

Re: [WWdevel] recording instructor answers

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

At 02:18 PM 8/29/2005, Sam Hathaway wrote:

>I think this is worthwhile, and we could also add a flag for who the
>"real" user was who submitted/checked/previewed the answer.
>  -sam

I think this would be a good way to go.

Arnie


>_______________________________________________
>OpenWeBWorK-Devel mailing list
>Ope...@li...
>https://lists.sourceforge.net/lists/listinfo/openwebwork-devel

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

Re: [WWdevel] recording instructor answers

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

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

On Aug 29, 2005, at 12:31, Michael Gage wrote:

> We actually specifically decided against it, since we didn't want  
> the instructor's answers mixed in
> with the student's answers.  I suppose we can revisit the decision,  
> but there are good reasons
> not to record instructor answers, so if we are going to think about  
> again it we should do it thoroughly.

On Aug 28, 2005, at 11:56, John Jones wrote:

> For the last item, another approach to dealing with this would be  
> to put the information in the answer log (which, as you pointed  
> out, is basically redundant with the transaction log).  We would  
> need to add another field for whether something was a submit/ 
> preview/check, and then display that in the "Show Past Answers"  
> page.  That might be a good idea in any case since it makes it easy  
> for individual teachers to research student complaints.

I think this is worthwhile, and we could also add a flag for who the  
"real" user was who submitted/checked/previewed the answer.
  -sam

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

iD8DBQFDE1Fr14CQX+2WvVgRAscGAKCYQw8im6EbGuU3XMsooqtVwD3zVwCgtJ8v
N/50Hw2t3r3KekN+pFPADOY=
=Rkxk
-----END PGP SIGNATURE-----

Re: [WWdevel] recording instructor answers

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

Actually, the question of whether or not a professor's answers are 
recorded is configurable in global.conf.  It is part of the permissions 
system.  You can modify the distribution-default setting in 
global.conf.dist if you think the current default is confusing to people.

I have had instructors run into this and be alarmed.  Maybe it can say 
something like "No submitted answers have been logged."

John


Michael Gage wrote:

> We actually specifically decided against it, since we didn't want the 
> instructor's answers mixed in
> with the student's answers.  I suppose we can revisit the decision, 
> but there are good reasons
> not to record instructor answers, so if we are going to think about 
> again it we should do it thoroughly.
>
>  It's easy enough to log in as a practice student to see how things
> REALLY work.
>
> I agree that the error message is  misleading and needs some kind of 
> explanation.  We can also
> add some information that reminds instructors that their answers are 
> not recorded. I often forget that fact myself.
>
> Take care,
>
> Mike
>
> On Aug 29, 2005, at 11:51 AM, Arnold Pizer wrote:
>
>> At 11:13 AM 8/29/2005, you wrote:
>>
>>> This is a bug, but not a serious one. 
>>> It turns out that the  error message occurs because no questions 
>>> have yet been answered,
>>> so no answer_log has been created.
>>>
>>> Remember that instructors answers are not recorded!!!
>>
>>
>> I think it would be a good idea to record instructors answers since 
>> it's likely that instructors will view their own answers just to see 
>> how things work.
>>
>> Arnie
>>
>>
>>> You need to login as a student and answer a question to get rid of 
>>> the warning message.
>>>
>>> Take care,
>>>
>>> Mike
>>>
>>>
>>>
>>> On Aug 29, 2005, at 10:46 AM, Arnold Pizer wrote:
>>>
>>>> Hi Sam,
>>>>
>>>> I get the same error Susan did with my test course on the template 
>>>> machine.
>>>> I tried logging in again and that didn't help.  I don't have access 
>>>> to the server so I can't look and see what's happening.  My guess 
>>>> is that on hosted Mike intervened and solved the problem.
>>>>
>>>> *Can't open the access log 
>>>> /ww/webwork/webwork2/courses/apizer_test_course/logs/answer_log*
>>>>
>>>> http://128.151.231.12/webwork2/apizer_test_course/instructor/show_answers/ 
>>>>
>>>>
>>>> Since course are already set up on webwork.rochester.edu,  this is 
>>>> a bug that won't effect those courses.
>>>>
>>>> Arnie
>>>>
>>>> Prof. Arnold K. Pizer
>>>> Dept. of Mathematics
>>>> University of Rochester
>>>> Rochester, NY 14627
>>>> (585) 275-7767
>>>
>> Prof. Arnold K. Pizer
>> Dept. of Mathematics
>> University of Rochester
>> Rochester, NY 14627
>> (585) 275-7767
>>
>

[WWdevel] recording instructor answers

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

We actually specifically decided against it, since we didn't want the  
instructor's answers mixed in
with the student's answers.  I suppose we can revisit the decision,  
but there are good reasons
not to record instructor answers, so if we are going to think about  
again it we should do it thoroughly.

  It's easy enough to log in as a practice student to see how things
REALLY work.

I agree that the error message is  misleading and needs some kind of  
explanation.  We can also
add some information that reminds instructors that their answers are  
not recorded. I often forget that fact myself.

Take care,

Mike

On Aug 29, 2005, at 11:51 AM, Arnold Pizer wrote:

> At 11:13 AM 8/29/2005, you wrote:
>> This is a bug, but not a serious one.
>> It turns out that the  error message occurs because no questions  
>> have yet been answered,
>> so no answer_log has been created.
>>
>> Remember that instructors answers are not recorded!!!
>
> I think it would be a good idea to record instructors answers since  
> it's likely that instructors will view their own answers just to  
> see how things work.
>
> Arnie
>
>
>> You need to login as a student and answer a question to get rid of  
>> the warning message.
>>
>> Take care,
>>
>> Mike
>>
>>
>>
>> On Aug 29, 2005, at 10:46 AM, Arnold Pizer wrote:
>>
>>> Hi Sam,
>>>
>>> I get the same error Susan did with my test course on the  
>>> template machine.
>>> I tried logging in again and that didn't help.  I don't have  
>>> access to the server so I can't look and see what's happening.   
>>> My guess is that on hosted Mike intervened and solved the problem.
>>>
>>> Can't open the access log /ww/webwork/webwork2/courses/ 
>>> apizer_test_course/logs/answer_log
>>>
>>> http://128.151.231.12/webwork2/apizer_test_course/instructor/ 
>>> show_answers/
>>>
>>> Since course are already set up on webwork.rochester.edu,  this  
>>> is a bug that won't effect those courses.
>>>
>>> Arnie
>>>
>>> Prof. Arnold K. Pizer
>>> Dept. of Mathematics
>>> University of Rochester
>>> Rochester, NY 14627
>>> (585) 275-7767
> Prof. Arnold K. Pizer
> Dept. of Mathematics
> University of Rochester
> Rochester, NY 14627
> (585) 275-7767

Re: [WWdevel] more logging

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

>
> Since part of the rationale for the transaction log is to back up  
> the sql database, keeping it as a file makes sense.  But, it should  
> probably be merged with the answer log (with maybe the tiny extra  
> bit of information of logging submit/check/preview :) ).
>
>

Hi John,

I'm not sure that we've ever used the transaction log to rebuild a  
database -- the information is there, but not in a very useable form.
The sql databases have their own efficient methods for dumping a  
backup image, or even of journalling every transaction if that is
desirable.  I want to to shift the burden of backup and efficiency to  
those software projects.  They have a lot more manpower. :-)

Thanks for adding the journalling facility to the current WeBWorK2.   
It is quite useful for trouble shooting problems after the fact.

>> On a separate note I think we would be interested in the changes   
>> needed to accommodate the ASU login and authentication scheme.  We  
>> haven't had much experience with this yet but if it's  possible  
>> I'd like to factor things so that ContentGenerator.pm would be  
>> fixed  and Authen.pm and/or if necessary Login.pm could be   
>> subclassed to allow for a variety of authentication schemes.
>>
>
> Some things would probably be easy, and others much harder.  The  
> main changes to ContentGenerator relate to logout.  We have to show  
> a particular icon for logout, and it has to call a particular  
> university url.  So, I removed the logout link from the left panel  
> and replaced the link in the upper-right corner with the icon  
> linking to the university url instead of calling the logout  
> module.  I tinkered with the logout module, but this meant that I  
> had one fewer module to change.  So, I leave it as is, and it never  
> gets called.  I think I could have done the icon through the  
> template, but then I would still need to remove the webwork logout  
> link in the upper right corner.
>
> I changed Login.pm so the only options are to log in through the  
> university, or to guest login.
>
> I changed Options.pm since webwork has no access to actual  
> passwords.  The standard message was potentially confusing since  
> university passwords could be changed, just not through webwork.   
> If you wanted to make that configurable, I imagine it could be a  
> string to show when password changes are not allowed, and set in  
> Constants.
>
> The biggest changes were to Authen since that's where we need to  
> deal with the university system for login-redirect and reading  
> their cookie.  I think there was something done in webwork to make  
> that easier, but I haven't looked at it.
>
> There are a few things which could be better when it comes to  
> practice users, but they haven't caused any problems.
>
> You can see the result by logging into any of the ASU courses.  Of  
> course, the login through ASU button will just get you the ASU  
> login page where you will be stuck.  But, you can login as a guest  
> and everything looks the same as if you were a registered student.
>
> John

Thanks, John.  Once the beginning of semester flurry dies down I'd  
like to look a the changes you've made in your modules and
also at the experience of others who have been using university  
authentication of one form or another.  We'll see what improvements
can be made in the way the current code is factored.
>
>
>

Re: [WWdevel] more logging

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

Thanks Mike,

I was aware of most of the information on logging.  The question remains 
as to whether there should be more.  I'll give a couple of scenerios 
where I would have found additional logging to be useful.  It is 
possible I could have found the needed information in the debug log if I 
had that turned on, but I find that it has too much information.  It is 
more appropriate to debugging a problem on a private system when you 
know how to produce it.  Here are the examples:

    * recently I was doing a workshop for CC teachers.  While showing
      how to assign a set to the whole class, I got an add vs. put
      database error.  I don't have any reasonable way to figure out why
      that happened.  I have a guess, but it would have been nice to go
      back to the logs to verify it.
    * this week we had a course which had an sql_single database
      corrupted.  This was a "" vs. 0 type error (every student suddenly
      had 0 allowed attempts on the problems and the problems had value
      0).  I asked the teacher what things he had done, repeated the
      steps, but was unable to reproduce the bug.  With more logging, I
      would know everything that happened to that set from the time it
      was imported, and I think I would then be able to reproduce and
      fix it.  This is a pretty problematic bug, but unless we know how
      to trigger it, it will be hard to fix.
    * every semester we get students who say they did some problems,
      came back, and they no longer had credit for them.  Our guess as
      to what happened are - you only previewed the answers; you were
      after the due date and just checked answers; you were logged in as
      a guest user.  With WW 1.*, we could pin this down.  Now, we have
      no way of verifying the first two since previews and checks don't
      get logged.  If the instructor says, it might be this, or it might
      be that, the student may think "or it was a bug in that system
      they make me use".  If you can say, we checked the logs and here
      is what you did, then it is much more convincing.

For the last item, another approach to dealing with this would be to put 
the information in the answer log (which, as you pointed out, is 
basically redundant with the transaction log).  We would need to add 
another field for whether something was a submit/preview/check, and then 
display that in the "Show Past Answers" page.  That might be a good idea 
in any case since it makes it easy for individual teachers to research 
student complaints.

As it stands, the only changes I made on our systems for this were in 
two files which are entirely local: local.conf (we adopted Davide's 
approach of not touching global.conf.dist; having global.conf load 
global.conf.dist and then load local.conf) and ContentGenerator.pm 
(which we had to fork to accomodate some things related to the ASU login 
scheme).  So, it is no extra work for me to maintain separate versions 
of these files.  I was wondering if others would find this useful enough 
to include it as an option.

John



Michael Gage wrote:

> Hi,
>
> Here is some data about the current logging facilities in WeBWorK2.   
> It is taken from global.conf.dist with a few annotations comparing
> the facilities with WW1.9
>
> ######################################################################## 
> ########
> # Logs
> ######################################################################## 
> ########
>
> # FIXME: take logs out of %webworkFiles/%courseFiles and give them  
> their own
> # top-level hash.
>
>> Fixing this would also allow us to consolidate the writeLog and  
>> writeCourseLog subroutines.  Currently the only difference
>> is where in the course environment they search for the path to the  
>> log file.
>
>
> # Logs data about how long it takes to process problems. (Do not  
> confuse this
> # with the /other/ timing log which can be set by WeBWorK::Timing and  
> is used
> # for benchmarking system performance in general. At some point, this  
> timing
> # mechanism will be deprecated in favor of the WeBWorK::Timing  
> mechanism.)
> $webworkFiles{logs}{timing}         = "$webworkDirs{logs}/timing.log";
>
>>    - this is total time taken for any given response.  I find this  
>> helpful in moderating day to day
>> performance of our local servers.  It is also possible to obtain  
>> more detailed timing data
>> -- but it is now housed in the Debug.pm module, not Timing.pm.  I  
>> don't think it is necessary
>> for production installations.  The timing log fills up fast and  
>> should be rotated.
>
> # Logs courses created via the web-based Course Administration module.
> $webworkFiles{logs}{hosted_courses} = "$webworkDirs{logs}/ 
> hosted_courses.log";
>
>> this is only used in the Admin course, and keeps a record of  courses 
>> created and deleted on the server.
>
>
> # The transaction log contains data from each recorded answer  
> submission. This
> # is useful if the database becomes corrupted.
> $webworkFiles{logs}{transaction}    = "$courseDirs{logs}/ 
> transaction.log";
>
>> This records all of the data provided by a student when they answer  
>> a problem. It is updated using the
>
> Utils::writeLog(ce, "transaction" ... ) subroutine.
>
>> It is roughly  equivalent to
>> the Global::log_info logging facility in WW1.9 which "captured  every 
>> key stroke" of the student and store its data in
>> the file, usually named access_log.  What it actually saved was the  
>> entire url query string, including any hidden data.
>>
>> There is one important difference in that Global::log_info was  
>> called on most scripts, including instructor scripts, while
>> the transaction log is only updated when answering a WeBWorK  
>> problem. The WW1.9 log contains instructor house keeping
>> actions as  well as student actions.
>
>
> # The answer log stores a history of all users' submitted answers.
> $courseFiles{logs}{answer_log}      = "$courseDirs{logs}/answer_log";
>
>> This is a separate log that records the students' answer history.   
>> it duplicates some information in the transaction log. It was
>> created at a different time and for a different purpose than the  
>> transaction.log.  It might be useful to consolidate some of the
>> code involved in these two logs.  It also would be worth  considering 
>> placing this data directly in the sql database.  The  upside, 
>> particularly for student answers, is that it would become  easier to 
>> search for certain types of student mistakes using sql  queries.  On 
>> the downside this might interfere with performance.
>
>
>> The format for storing the data in both answer_log and in  
>> transaction log is somewhat ad hoc.  If we continue to store the  
>> data in a file then storing the data in an xml format would  
>> facilitate being able to manipulate the data later using  
>> standardized tools.  We might store the data in a file, but  
>> periodically extract it and store it in an sql database for  research 
>> purposes.
>
>
>
> # Log logins.
> $courseFiles{logs}{login_log}       = "$courseDirs{logs}/login.log";
>
>> This merely records each time a student logs in to webwork.
>
>
>
> Take care,
>
> Mike
>
> #################
>
> On Aug 27, 2005, at 6:49 PM, John Jones wrote:
>
>> Webwork 1 had a fuller logging procedure, where basically every  
>> click was logged.  I found that useful since I sometimes had to  
>> figure out what a teacher had done (in addition to answering  
>> questions about what students did).
>>
>> The webwork 2 logging framework made it easy to replicate this: one  
>> line in global.conf to define the log file, and then one (long)  line 
>> in ContentGenerator to call the writeCourseLog to record the  url and 
>> the cgi parameters.  So, this raised a couple of questions:
>> would we want this facility in the main webwork?
>> if so, should it be more refined (so individual modules can give  
>> more finely tuned log entries)?
>> Thoughts?
>>
>> 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

Re: [WWdevel] more logging

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

Hi,

Here is some data about the current logging facilities in WeBWorK2.   
It is taken from global.conf.dist with a few annotations comparing
the facilities with WW1.9

######################################################################## 
########
# Logs
######################################################################## 
########

# FIXME: take logs out of %webworkFiles/%courseFiles and give them  
their own
# top-level hash.

> Fixing this would also allow us to consolidate the writeLog and  
> writeCourseLog subroutines.  Currently the only difference
> is where in the course environment they search for the path to the  
> log file.

# Logs data about how long it takes to process problems. (Do not  
confuse this
# with the /other/ timing log which can be set by WeBWorK::Timing and  
is used
# for benchmarking system performance in general. At some point, this  
timing
# mechanism will be deprecated in favor of the WeBWorK::Timing  
mechanism.)
$webworkFiles{logs}{timing}         = "$webworkDirs{logs}/timing.log";
>    - this is total time taken for any given response.  I find this  
> helpful in moderating day to day
> performance of our local servers.  It is also possible to obtain  
> more detailed timing data
> -- but it is now housed in the Debug.pm module, not Timing.pm.  I  
> don't think it is necessary
> for production installations.  The timing log fills up fast and  
> should be rotated.
# Logs courses created via the web-based Course Administration module.
$webworkFiles{logs}{hosted_courses} = "$webworkDirs{logs}/ 
hosted_courses.log";

> this is only used in the Admin course, and keeps a record of  
> courses created and deleted on the server.

# The transaction log contains data from each recorded answer  
submission. This
# is useful if the database becomes corrupted.
$webworkFiles{logs}{transaction}    = "$courseDirs{logs}/ 
transaction.log";
> This records all of the data provided by a student when they answer  
> a problem. It is updated using the
Utils::writeLog(ce, "transaction" ... ) subroutine.
> It is roughly  equivalent to
> the Global::log_info logging facility in WW1.9 which "captured  
> every key stroke" of the student and store its data in
> the file, usually named access_log.  What it actually saved was the  
> entire url query string, including any hidden data.
>
> There is one important difference in that Global::log_info was  
> called on most scripts, including instructor scripts, while
> the transaction log is only updated when answering a WeBWorK  
> problem. The WW1.9 log contains instructor house keeping
> actions as  well as student actions.

# The answer log stores a history of all users' submitted answers.
$courseFiles{logs}{answer_log}      = "$courseDirs{logs}/answer_log";

> This is a separate log that records the students' answer history.   
> it duplicates some information in the transaction log. It was
> created at a different time and for a different purpose than the  
> transaction.log.  It might be useful to consolidate some of the
> code involved in these two logs.  It also would be worth  
> considering placing this data directly in the sql database.  The  
> upside, particularly for student answers, is that it would become  
> easier to search for certain types of student mistakes using sql  
> queries.  On the downside this might interfere with performance.

> The format for storing the data in both answer_log and in  
> transaction log is somewhat ad hoc.  If we continue to store the  
> data in a file then storing the data in an xml format would  
> facilitate being able to manipulate the data later using  
> standardized tools.  We might store the data in a file, but  
> periodically extract it and store it in an sql database for  
> research purposes.


# Log logins.
$courseFiles{logs}{login_log}       = "$courseDirs{logs}/login.log";

> This merely records each time a student logs in to webwork.


Take care,

Mike

#################

On Aug 27, 2005, at 6:49 PM, John Jones wrote:

> Webwork 1 had a fuller logging procedure, where basically every  
> click was logged.  I found that useful since I sometimes had to  
> figure out what a teacher had done (in addition to answering  
> questions about what students did).
>
> The webwork 2 logging framework made it easy to replicate this: one  
> line in global.conf to define the log file, and then one (long)  
> line in ContentGenerator to call the writeCourseLog to record the  
> url and the cgi parameters.  So, this raised a couple of questions:
> would we want this facility in the main webwork?
> if so, should it be more refined (so individual modules can give  
> more finely tuned log entries)?
> Thoughts?
>
> John
>