openwebwork-devel — WeBWorK development discussion

Re: [WWdevel] ATTENTION: rel-2-2-dev branch created

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

Hi,

I have fixed some of the issues raised by Davide for PGProblemEditor

Specifically I believe I fixed the problem when editing a pg file  
which is not attached
to a specific   setID/problemID  (this is the case when you "edit"  
from the library browser).

There are still issues when you try to edit a set header.
Not everything works as one would expect.  I can probably fix those  
this weekend.

I have not fixed the "new window" problem since it sounds to me like  
Davide has a good fix for that.

I commit this to HEAD for now.  As soon as Davide and/or I have a  
stable version that is better than
the version in the current release we can back port it to the current  
release.

Is this ok, Sam?

Take care,

Mike


On Jan 6, 2006, at 6:54 PM, Sam Hathaway wrote:

> Hello,
>
> We've added a rel-2-2-dev branch in anticipation of the release of  
> WeBWorK 2.2. The intent of this branch is to provide a place to  
> commit bugfixes, while development can continue in HEAD. If you're  
> contribution to WeBWorK development, here is what we need from you:
>
> * Go read <http://devel.webwork.rochester.edu/twiki/bin/view/ 
> Webwork/ReleaseBranches>. It details how to use this branch for bug  
> fixes, and how to easily commit a fix to both this branch and HEAD.
>
> * If you want to work on the release, check out a new working copy  
> on the rel-2-2-dev branch, or update your existing working copy to  
> that branch.
>
> * If you are going to fix a bug, fix it in the rel-2-2-dev branch,  
> and then forward port it to HEAD. I'm going to be watching the CVS  
> commit logs, so if you forget to forward port (or just don't feel  
> like it) I'll take care of it for you.
>
> * If you feel like it, expose rel-2-2-dev to testing. The  
> installation process and upgrade process especially need testing.  
> Refer to the draft 2.2 installation manual < http:// 
> devel.webwork.rochester.edu/twiki/bin/view/Webwork/ 
> InstallationManualV2pt2>.
>
> * Please refrain from adding new features to rel-2-2-dev.
>
> Thank you for your help. Hopefully 2.2 will be a stable and  
> enjoyable release for everyone. If you have any questions, ask!
> -sam
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
> log files
> for problems?  Stop!  Download the new AJAX search engine that makes
> searching your log files as easy as surfing the  web.  DOWNLOAD  
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> OpenWeBWorK-Devel mailing list
> Ope...@li...
> https://lists.sf.net/lists/listinfo/openwebwork-devel

"Only dead fish swim with the stream."

[WWdevel] ATTENTION: rel-2-2-dev branch created

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

Hello,

We've added a rel-2-2-dev branch in anticipation of the release of  
WeBWorK 2.2. The intent of this branch is to provide a place to  
commit bugfixes, while development can continue in HEAD. If you're  
contribution to WeBWorK development, here is what we need from you:

* Go read <http://devel.webwork.rochester.edu/twiki/bin/view/Webwork/ 
ReleaseBranches>. It details how to use this branch for bug fixes,  
and how to easily commit a fix to both this branch and HEAD.

* If you want to work on the release, check out a new working copy on  
the rel-2-2-dev branch, or update your existing working copy to that  
branch.

* If you are going to fix a bug, fix it in the rel-2-2-dev branch,  
and then forward port it to HEAD. I'm going to be watching the CVS  
commit logs, so if you forget to forward port (or just don't feel  
like it) I'll take care of it for you.

* If you feel like it, expose rel-2-2-dev to testing. The  
installation process and upgrade process especially need testing.  
Refer to the draft 2.2 installation manual < http:// 
devel.webwork.rochester.edu/twiki/bin/view/Webwork/ 
InstallationManualV2pt2>.

* Please refrain from adding new features to rel-2-2-dev.

Thank you for your help. Hopefully 2.2 will be a stable and enjoyable  
release for everyone. If you have any questions, ask!
-sam

Re: [WWdevel] WeBWorK 2.2 prerelease, code freeze in a branch?

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

Hi Davide,

This will help  a lot in tracking this down.

I can reproduce your results if I start from the Library page.

However if I start by going directly to a problem in a homework set  
and then clicking

"Edit this problem"

I get:

Re: [WWdevel] WeBWorK 2.2 prerelease, code freeze in a branch?

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

>> Then there is the issue of opening new windows, which I always  
>> found terribly confusing, and I think may have been the real  
>> source of problem for our professors   For example, if you edit a  
>> problem then view it, you get a new window (fine) and in that  
>> window there is "Edit this problem", and pressing this gets me an  
>> editor in the same window.  I now have two edit windows that I  
>> think of as being the same file, but they aren't.  The new window  
>> opened a view of a TEMPORARY file, and we are now editing the  
>> temporary file as a SECOND temporary file.
> Is this really true?

Yes, I was testing it as I wrote so that I would get it right.

Here's what I did:

1.  I started with the Library Browser and selected a problem to  
which I have write access.  Then used the "Edit it" link from the  
Library Browser.  This brings up the editor in the same window.  I  
get the "editing in .... .pg" message.

2.  Then I viewed the problem (the default action).  You get a new  
window in which you see the problem as a student would see it.  I see  
the "Saved to ... .pg.dpvc.tmp" and "viewing  
temporary .... .pg.dpvc.tmp" messages you mentioned.

3.  Now press the "Edit this problem" link at the bottom of the  
problem in the new window (which should be the font-most window).   
Now the editor comes up (in the window where I clicked) with the  
"Editing in ... .pg.dpvc.tmp" (note that I'm now editing the .tmp  
file not the original).  I now have two edit windows showing, one for  
the original .pg file and one for .pg.dpvc.tmp.

4.  Now use the view action (in the editor editing the .tmp file,  
which should be the front-most window).  This views the file in the  
SAME window (not a new one, as before), and I see a "Saved  
to ... .pg.dpvc.tmp.dpvc.tmp" and message and am told I'm "Editing  
in ... .pg.tmp.dpvc.tmp".  Note the double ".dpvc.tmp".  Continuing  
to edit and view in this same window gets me more and more  
".dpvc.tmp" suffixes.

5.  Saving the file (in the window editing ".pg.dpvc.tmp", the front- 
most window) gets me a message "Saved to ... .pg.dpvc.tmp" (not to  
the original .pg file) and a warning about not  
finding .pg.dpvc.tmp.dpvc.tmp, then a message saying I'm editing  
".pg.dpvc.tmp.dpvc.tmp".  At this point I give up in frustration,  
unable to cope with all the temporary files and lack of consistency  
about new windows.

> I though that a save operation always saved to the original file  
> (the one without a .tmp extension).

Yes, but when there are multiple .dpvc.tmp suffixes, the "original"  
file is not the one you might expect.

> You may want to change the name of the temporary file in order to  
> force the browser to refresh the data --
> we had a problem a while ago where the data being displayed by the  
> browser would not reflect the latest updates.

Oh, I can certainly get around it, but the general faculty are  
confused by this behavior, and I don't blame them.

> There is one problem with controlling the viewing and editing  
> windows which we didn't know how to solve at the time, but perhaps  
> can be solved now.  What you would like is a window named EDITOR  
> and a window named "PREVIEW"
> and you would like each to be properly linked to the other and you  
> would like them to always contain current data.  You could bring up  
> the second window as "PREVIEW" but there was no way to determine or  
> assign the name of the first window.

I get around this by targeting EVERY edit action to a window called  
"WW_Editor" and EVERY view action to "WW_View".  The first attempt to  
make an edit opens the edit window, and the first view opens the view  
window.  Then the two can bounce between each other as much as they  
want.  This does mean that I can only edit one file at a time, but I  
rarely have two open simultaneously anyway.  One could be more  
sophisticated about pairing edit and view windows if you wanted to,  
but I haven't tried to do that.

> In the early days we also used javaScript as little as possible --  
> it's possible we could relax that now in order to fix this problem.

It doesn't require JavaScript to do it, though I did add some so that  
"Revert" and "Save a copy as" don't target a new window, but "View",  
"Add" and "Save" do, because they show the actual problem or header,  
not the editor.  (I also added a "in a new window" checkbox, and have  
those radio buttons set that -- I also hooked up the onChange stuff  
-- and when that checkbox is checked, the form's target is set, and  
when unchecked, the target is cleared.)

Finally, you mention making the header problem 0, but I don't think  
this really helps.  From the professor's standpoint, it is still a  
different item, and will be thought of as different.  Saying "Editing  
set Orientation/ problem 0" will be confusing, I think (I have it say  
"Editing header info in ...").  Also, you have a course_info file  
that is still a special case, and there could be other such files (I  
have added an info panel to the options page that includes advice on  
not using your email password and so on, so that is another special  
case for me).  Since you are going to need them anyway, I don't see  
that handling the header too is all that much extra.

In any case, I would like to see some of this straightened out before  
the 2.2 release.

Davide

Re: [WWdevel] WeBWorK 2.2 prerelease, code freeze in a branch?

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

>
>> Then there is the issue of opening new windows, which I always  
>> found terribly confusing, and I think may have been the real  
>> source of problem for our professors   For example, if you edit a  
>> problem then view it, you get a new window (fine) and in that  
>> window there is "Edit this problem", and pressing this gets me an  
>> editor in the same window.  I now have two edit windows that I  
>> think of as being the same file, but they aren't.  The new window  
>> opened a view of a TEMPORARY file, and we are now editing the  
>> temporary file as a SECOND temporary file.
> Is this really true?  I don't think that more than one temporary  
> file is created -- that certainly wasn't intended.  The original  
> editor kept all temporary data in the HTML itself.  In some sense  
> this was good, but lead to pretty large files being transmitted  
> back and forth -- if your login timed out you were likely to loose  
> all your edits.  The current effort is to mimic this behavior but  
> keep the temporary data on the server.

I haven't been able to duplicate this behavior yet. I'll try again a  
bit later tonight.

  However I do get messages such as the one below when I "view"  
changes in a problem.

Re: [WWdevel] WeBWorK 2.2 prerelease, code freeze in a branch?

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

Hi Davide,


On Jan 5, 2006, at 4:56 PM, Davide P. Cervone wrote:

>> I've been changing on the PGeditor incrementally during this last  
>> semester (and also trying to use it to write and fix the problems  
>> I use so I get the full experience) but I still think there is a  
>> lot work to do.  Part of my plan has been to bring the action  
>> buttons on that page in line with the style used on the "Hmwk sets  
>> editor" and "Classlist editor" pages.  I also wanted to make it  
>> easier to make a local copy of a library problem, since this has  
>> been requested by several users on hosted.
>
> Those are all good ideas, and they help.  But the editor doesn't  
> work properly with set headers: sometimes get error pages, can't  
> preview, the good and bad error messages are confusing and  
> sometimes contradictory (e.g., if you edit the default header file,  
> then save a new copy, you still get a a message about editing the  
> default file, then a message about a saved file, then another  
> message about a new local copy), you can't rename the header file  
> using "Save as", and so on.

My personal preference would be to get rid of the hardcopy set  
headers and make set headers complete synonyms for
problem 0.  This would solve a lot of special cases that need to be  
handled in the PGeditor.  The downside is that some
people like to use direct HTML in set header files which will then  
not work when hardcopy of the problem sets are corrected.  Perhaps we  
can figure out an ordinary PG problem format that will satisfy everyone.

> Things were in better shape for problem files, but I found the  
> "Save as" and "Save a copy as" buttons to be named in a way that  
> didn't correspond to my intuition of what those names mean.  My  
> expectation of "Save as" (from other programs) is that it makes a  
> copy of the file, leaving the original unchanged, and starts  
> editing the new file, while "Save a copy as" would make a copy of  
> the file but continue editing the original.  The effect of "Save  
> as" in the new arrangement is to make a new copy, edit it, AND  
> CHANGE THE PROBLEM SET to use the new problem.  That last effect  
> was a complete surprise to me, and counter to my expectations for  
> save as.  "Save a copy as" does what I think "Save as" should do,  
> and "Save as" does what I think "Rename" or "Reassign" or some  
> other such name should do.  I'm not quite sure what "Make a local  
> copy" is for, if you have "Save a copy as", but since it isn't  
> often showing, I didn't worry about it too much.
>
"Reassign" or "rename" sounds like a good suggestion to me.  I agree  
that the nomenclature is confusing, but I couldn't think of anything  
better at the time.

The "make a local copy" shows up when you are viewing a library file  
that can't be edited.  This was the first addition that was made and  
is for those using hosted courses and libraries of courses that they  
are not allowed to modify it shows up frequently.  It greatly  
simplifies that process of creating a local copy of the library  
problem and reassigning the file name path so that the problem set  
refers to the local copy.  It is then possible to make corrections or  
modifications. My experience is that this works pretty well, although  
there may be a better name than "make local copy".  Eventually I'd  
like to wire up John Jone's Compare module so that it is easy to view  
the changes between the local and library copy and then to make it  
easy to submit the local copy as a candidate to replace or supplement  
the library copy if that seems desirable.  This option shows up only  
when you are viewing a file that cannot be modified, so you might not  
see it often on your server.

The "save as" feature  was added later to allow you to perform the  
same function with problems that could be modified.
(e.g. you might have a problem that you liked but for this specific  
course you wanted to use a modification of it while still preserving  
the original file).  The "save a copy as" was added for  
completeness.  If you think of this as modifying the
problem in the current set, this nomenclature makes some sense --  
"save as" allows you to modify the problem that is currently being  
used in the set,  "save a copy as" saves a template of the current  
problem which you might, for example, want to later import into some  
other set as a template to be further modified.    Having said that,  
I'm not satisfied with the nomenclature either and would be glad to  
see suggestions for improvements.  I think the three functions are  
the correct ones (although "save as" and "make local copy" are really  
the same function applied in different contexts).

> Then there is the issue of opening new windows, which I always  
> found terribly confusing, and I think may have been the real source  
> of problem for our professors   For example, if you edit a problem  
> then view it, you get a new window (fine) and in that window there  
> is "Edit this problem", and pressing this gets me an editor in the  
> same window.  I now have two edit windows that I think of as being  
> the same file, but they aren't.  The new window opened a view of a  
> TEMPORARY file, and we are now editing the temporary file as a  
> SECOND temporary file.
Is this really true?  I don't think that more than one temporary file  
is created -- that certainly wasn't intended.  The original editor  
kept all temporary data in the HTML itself.  In some sense this was  
good, but lead to pretty large files being transmitted back and forth  
-- if your login timed out you were likely to loose all your edits.   
The current effort is to mimic this behavior but keep the temporary  
data on the server.
> Saving edits here saves to the first temporary file, and at this  
> point I have no way to get those changes into the original file.   
> Granted, the messages are telling me about which file I'm actually  
> using, but even after having spent quite some time trying to figure  
> out how it works, I still have to think hard when I look at the  
> file names to see that I'm doing what I should be.  For example, it  
> says I'm editing in a temp file, but I have to realize that saving  
> is to the NON-temp file, which is counterintuitive to me.  Plus I  
> get spurious messages about the temp file not being found (even  
> though the save message is generated).
>
I'll have to check this out.  I agree this is not desirable behavior.  
I though that a save operation always saved to the original file (the  
one without a .tmp extension).  I have one hypothesis of how this  
creeps in.
You may want to change the name of the temporary file in order to  
force the browser to refresh the data --
we had a problem a while ago where the data being displayed by the  
browser would not reflect the latest updates.
> I have to say I find the whole thing very confusing.  I don't like  
> to have several windows open editing different versions, and it is  
> FAR to easy to do that.  I would prefer to have one editing window  
> and one viewing window, and ALWAYS having editing occur in the edit  
> window and always have viewing occur in the other (rather than  
> sometimes have a window open, sometimes view in the same window as  
> the editor, and never know what is really going to happen, or where  
> you are).  I have to say, I understand why the faculty got  
> frustrated.  I don't see why you should be allowed to edit the  
> temporary file at all; when I view the file and then say edit it, I  
> would expect to back to the editing the same file I was viewing,  
> not a new copy of that file.

There is one problem with controlling the viewing and editing windows  
which we didn't know how to solve at the time, but perhaps can be  
solved now.  What you would like is a window named EDITOR and a  
window named "PREVIEW"
and you would like each to be properly linked to the other and you  
would like them to always contain current data.  You could bring up  
the second window as "PREVIEW" but there was no way to determine or  
assign the name of the first window.   In the early days we also used  
javaScript as little as possible -- it's possible we could relax that  
now in order to fix this problem.

Glad you are interested in working with the PGeditor.  It is one of  
the interfaces which I still think  could really benefit from  
additional work.

take care,

Mike

> Anyway, that's where I'm coming from with it.
>
> Davide

"Only dead fish swim with the stream."

Re: [WWdevel] WeBWorK 2.2 prerelease, code freeze in a branch?

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

> I've been changing on the PGeditor incrementally during this last  
> semester (and also trying to use it to write and fix the problems I  
> use so I get the full experience) but I still think there is a lot  
> work to do.  Part of my plan has been to bring the action buttons  
> on that page in line with the style used on the "Hmwk sets editor"  
> and "Classlist editor" pages.  I also wanted to make it easier to  
> make a local copy of a library problem, since this has been  
> requested by several users on hosted.

Those are all good ideas, and they help.  But the editor doesn't work  
properly with set headers: sometimes get error pages, can't preview,  
the good and bad error messages are confusing and sometimes  
contradictory (e.g., if you edit the default header file, then save a  
new copy, you still get a a message about editing the default file,  
then a message about a saved file, then another message about a new  
local copy), you can't rename the header file using "Save as", and so  
on.  Things were in better shape for problem files, but I found the  
"Save as" and "Save a copy as" buttons to be named in a way that  
didn't correspond to my intuition of what those names mean.  My  
expectation of "Save as" (from other programs) is that it makes a  
copy of the file, leaving the original unchanged, and starts editing  
the new file, while "Save a copy as" would make a copy of the file  
but continue editing the original.  The effect of "Save as" in the  
new arrangement is to make a new copy, edit it, AND CHANGE THE  
PROBLEM SET to use the new problem.  That last effect was a complete  
surprise to me, and counter to my expectations for save as.  "Save a  
copy as" does what I think "Save as" should do, and "Save as" does  
what I think "Rename" or "Reassign" or some other such name should  
do.  I'm not quite sure what "Make a local copy" is for, if you have  
"Save a copy as", but since it isn't often showing, I didn't worry  
about it too much.

Then there is the issue of opening new windows, which I always found  
terribly confusing, and I think may have been the real source of  
problem for our professors   For example, if you edit a problem then  
view it, you get a new window (fine) and in that window there is  
"Edit this problem", and pressing this gets me an editor in the same  
window.  I now have two edit windows that I think of as being the  
same file, but they aren't.  The new window opened a view of a  
TEMPORARY file, and we are now editing the temporary file as a SECOND  
temporary file.  Saving edits here saves to the first temporary file,  
and at this point I have no way to get those changes into the  
original file.  Granted, the messages are telling me about which file  
I'm actually using, but even after having spent quite some time  
trying to figure out how it works, I still have to think hard when I  
look at the file names to see that I'm doing what I should be.  For  
example, it says I'm editing in a temp file, but I have to realize  
that saving is to the NON-temp file, which is counterintuitive to  
me.  Plus I get spurious messages about the temp file not being found  
(even though the save message is generated).

I have to say I find the whole thing very confusing.  I don't like to  
have several windows open editing different versions, and it is FAR  
to easy to do that.  I would prefer to have one editing window and  
one viewing window, and ALWAYS having editing occur in the edit  
window and always have viewing occur in the other (rather than  
sometimes have a window open, sometimes view in the same window as  
the editor, and never know what is really going to happen, or where  
you are).  I have to say, I understand why the faculty got  
frustrated.  I don't see why you should be allowed to edit the  
temporary file at all; when I view the file and then say edit it, I  
would expect to back to the editing the same file I was viewing, not  
a new copy of that file.

Anyway, that's where I'm coming from with it.

Davide

Re: [WWdevel] WeBWorK 2.2 prerelease, code freeze in a branch?

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

>
> I also agree.  Out faculty had some serious problems with the PG  
> Editor when they started using it this week, and there are a number  
> of problems with it.  I'll try to write something up soon.  I don't  
> usually use the PG editor myself, but when I did, I really found it  
> difficult and confusing.  I think I have a version that works the  
> way I expect it to, but was planning to use it a bit longer before  
> making suggested changes.

I've been changing on the PGeditor incrementally during this last  
semester (and also trying to use it to write and fix the problems I  
use so I get the full experience) but I still think there is a lot  
work to do.  Part of my plan has been to bring the action buttons on  
that page in line with the style used on the "Hmwk sets editor" and  
"Classlist editor" pages.  I also wanted to make it easier to make a  
local copy of a library problem, since this has been requested by  
several users on hosted.   I'd be interested in seeing your version  
Davide.

Take care,

Mike

[WWdevel] Re: WeBWorK 2.2 prerelease, code freeze in a branch?

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

On Jan 5, 2006, at 3:44 PM, Sam Hathaway wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Guys,
>
> A few of things:
>
> I think this release should be 2.2. It has a few major non-bug-fix  
> features, like gateway testing (including database changes), the  
> removal of deprecated database layouts, and jsMath updates  
> (including the new fonts tarball).
>
> However, in my opinion, we're not ready for a "final" 2.2 release,  
> since many changes went in after fall semester ended, and therefore  
> haven't received much testing.
>
> I propose that we release "2.2-pre1" very soon (like today), to  
> give users a chance to install the new version and work out any  
> kinks on their local systems, and then fix bugs and make the final  
> 2.2 release a painless update.
>
This sounds just right to me.

> I'd also like to tweak the way we track releases in CVS for this  
> series.
>
> Right now, we do a "feature freeze" in HEAD towards the end of the  
> release cycle, with the intent that we'll stop adding new features  
> and concentrate on fixing bugs. The problem is, features creep in  
> during the freeze, creating more bugs that have to be discovered  
> and fixed late in the cycle.
>
> When we're satisfied that HEAD is stable, we create a "-patches"  
> branch, and tag the beginning of the patches branch as our stable  
> release. Then, we continue to fix bugs on "-patches". Bugs  
> inevitably also get discovered on HEAD in the course of further  
> development, and we're supposed to backport those fixes into "- 
> patches" as soon as we fix them, but we don't. This creates a  
> difficult situation when we want to make a new release, where we  
> need to backport a LOT of bugfixes from HEAD to "-patches" all at  
> once. (CVS doesn't make it very easy to do this, either.)
>
right.  This is the biggest drawback to CVS that I've experienced.   
It's the one reason I'd be willing to switch to
more some kind of recent software that supports version development.
> Here's an illustration:
>
>      |<-- development -->|<-- freeze -->|<-- development & bug  
> fixes - -->
> HEAD ----------------------------------- 
> +-------------------------------------->
>                                         | /\    /\    /\    /\
>                                         | ||    ||    ||    ||  bug  
> fixes
>                                         | ||    ||    ||    ||   
> exchanged (or not)
>                                         | \/    \/    \/    \/
>                rel-2-1-patches (branch) +-----------+----------- 
> +----->
>                                         |<-- bug -->|<-- bug -->|
>                                         |   fixes   |   fixes   |
>                                        /           /           /
>                                       /           /           /
>                                   rel-2-1    rel-2-1-1   rel-2-1-2
>
> I think we can fix this by taking a few steps:
>
> First, we should create a release branch ("rel-2-2-dev") *before*  
> the feature freeze, and do the freeze on that branch instead of in  
> HEAD. We can upgrade hosted.webwork and math.webwork to this branch  
> at the same time, to get some serious testing done. If other  
> developers happen to be working on big features at the time, they  
> can continue to do so in HEAD.
>
> It would look like this:
>
>      |<-- development -->|<---------- development -------->
> HEAD --------------------+------------------------------------------>
>                          | /\    /\    /\    /\
>                          | ||    ||    ||    ||  bug fixes
>                          | ||    ||    ||    ||  forward-ported
>                          | ||    ||    ||    ||
>     rel-2-2-dev (branch) *--------------+--------------+----->
>     (math.webwork and    |<-- freeze -->|<-- freeze -->|
>     hosted.webwork run   |  (bugfixes)  |  (bugfixes)  |
>     this branch)        /              /              /
>                        /              /              /
>             (not a release)      rel-2-2-0      rel-2-2-1
>
> Second, we should do minor (2.x) releases more often, maybe every  
> four months or so, so that people won't be forced to use HEAD to  
> get the latest features. We should also do bugfix releases (2.x.y)  
> VERY often -- if we fix a couple of bugs in a month, it's time for  
> a new bugfix release.
>
I agree with this -- although it seems to me that this can be done  
through CVS update procedures rather than creating
a tar file.  You just update to the most recent stable release.  We  
can notify people periodically about new stable releases if we can  
figure out how to maintain a distribution list.  Is there anyway we  
can maintain a distribution list of folks
  that should be notified if we fix some important bug?  Does CVS and/ 
or sourceforge make this feasible?
> Third, we should maintain development systems on the release branch  
> in addition to the HEAD branch. When we do debugging, we should  
> ALWAYS do it on the release branch. When we fix bugs, we should  
> ALWAYS commit the fixes to the release branch. My theory is that  
> it's easier to forward port bugfixes from a branch that only  
> contains bugfixes than it is to tease bugfixes out of an unstable  
> and rapidly-changing HEAD and backport them.
>
OK.  We can try this.  I suspect that CVS is still not going to allow  
this to be an easy operation.
> Here's a recipe for committing a change to two branches easily.  
> (See <http://tinyurl.com/dzan3>.) If your current working copy is  
> on the rel-2-2-dev branch:
>
> cd webwork2
> <tweak file "foo">
> cvs commit foo                        # check into rel-2-2-dev
> <CVS says, checked in "foo" version 1.10.2.5>
> cvs up -A foo                         # switch to HEAD
> cvs up -j 1.10.2.4 -j 1.10.2.5 foo    # merge the change
> <deal with conflicts in "foo", if any>
> cvs commit foo                        # check into HEAD
> cvs up -r rel-2-2-dev foo             # go back to rel-2-2-dev
>
> This gets slightly more complex for multiple file commits, since  
> you need a separate merge line for each file:
>
> cd webwork2
> <tweak files "foo" and "bar">
> cvs commit foo bar                    # check into rel-2-2-dev
> <CVS says, checked in "foo" version 1.10.2.5 and "bar" version  
> 1.5.2.4>
> cvs up -A foo                         # switch to HEAD
> cvs up -j 1.10.2.4 -j 1.10.2.5 foo    # merge the change for "foo"
> cvs up -j 1.5.2.3 -j 1.5.2.4 bar      # merge the change for "bar"
> <deal with conflicts in both files, if any>
> cvs commit foo                        # check into HEAD
> cvs up -r rel-2-2-dev foo             # go back to rel-2-2-dev
>
> But most bug fixes should be pretty localized, so I think it'll be  
> manageable. If it turns out to be onerous, I can write or find a  
> script to do it automatically.
>
> Fourth, we should establish some definite rules for commits to the  
> release branch. Of course, only bugfixes should be committed to the  
> release branch. In addition, each commit should fix a single bug,  
> and each should mention the Bugzilla bug number for the bug it  
> fixes in the log message. If we fix a bug that doesn't have a  
> corresponding bug report, we should create one and mark it fixed  
> immediately. (The goal here is to be able to describe the changes  
> in a bugfix release by listing a series of Bugzilla bugs.)
>
We've been doing an ok job in this regard.  Every now and then you or  
I have gone back and matched up fixes with bugs that were not  
reported as resolved.  There are a few cases where things get patched  
without correlating with a bug report but there are many more where  
both a CVS update and a resolution to the bug are done at the same time.
> If there are no objections, I'm going to go ahead and branch HEAD  
> as rel-2-2-dev, and tag the start of the branch as rel-2-2-pre1 and  
> release it. Let me know your thoughts.

fine with me.  Go ahead.

Take care,


Mike

> - -sam
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
>
> iD8DBQFDvYUr14CQX+2WvVgRAnFLAJ4tKI2FJlmmZDqcT7o1i3tJb1oMhgCfZcQO
> Gv/m1xtpIXdJFWlzcjhoeyA=
> =LV0g
> -----END PGP SIGNATURE-----

"Only dead fish swim with the stream."

Re: [WWdevel] WeBWorK 2.2 prerelease, code freeze in a branch?

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

> I think this release should be 2.2. It has a few major non-bug-fix  
> features, like gateway testing (including database changes), the  
> removal of deprecated database layouts, and jsMath updates  
> (including the new fonts tarball).

That sounds good.

> However, in my opinion, we're not ready for a "final" 2.2 release,  
> since many changes went in after fall semester ended, and therefore  
> haven't received much testing.

I also agree.  Out faculty had some serious problems with the PG  
Editor when they started using it this week, and there are a number  
of problems with it.  I'll try to write something up soon.  I don't  
usually use the PG editor myself, but when I did, I really found it  
difficult and confusing.  I think I have a version that works the way  
I expect it to, but was planning to use it a bit longer before making  
suggested changes.

> I'd also like to tweak the way we track releases in CVS for this  
> series.

I'm happy to do whatever you ask, and I appreciate the examples, as I  
don't know CVS well enough to be sure I'm doing it properly.

Davide

[WWdevel] WeBWorK 2.2 prerelease, code freeze in a branch?

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

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

Hi Guys,

A few of things:

I think this release should be 2.2. It has a few major non-bug-fix  
features, like gateway testing (including database changes), the  
removal of deprecated database layouts, and jsMath updates (including  
the new fonts tarball).

However, in my opinion, we're not ready for a "final" 2.2 release,  
since many changes went in after fall semester ended, and therefore  
haven't received much testing.

I propose that we release "2.2-pre1" very soon (like today), to give  
users a chance to install the new version and work out any kinks on  
their local systems, and then fix bugs and make the final 2.2 release  
a painless update.

I'd also like to tweak the way we track releases in CVS for this series.

Right now, we do a "feature freeze" in HEAD towards the end of the  
release cycle, with the intent that we'll stop adding new features  
and concentrate on fixing bugs. The problem is, features creep in  
during the freeze, creating more bugs that have to be discovered and  
fixed late in the cycle.

When we're satisfied that HEAD is stable, we create a "-patches"  
branch, and tag the beginning of the patches branch as our stable  
release. Then, we continue to fix bugs on "-patches". Bugs inevitably  
also get discovered on HEAD in the course of further development, and  
we're supposed to backport those fixes into "-patches" as soon as we  
fix them, but we don't. This creates a difficult situation when we  
want to make a new release, where we need to backport a LOT of  
bugfixes from HEAD to "-patches" all at once. (CVS doesn't make it  
very easy to do this, either.)

Here's an illustration:

      |<-- development -->|<-- freeze -->|<-- development & bug fixes  
- -->
HEAD ----------------------------------- 
+-------------------------------------->
                                         | /\    /\    /\    /\
                                         | ||    ||    ||    ||  bug  
fixes
                                         | ||    ||    ||    ||   
exchanged (or not)
                                         | \/    \/    \/    \/
                rel-2-1-patches (branch) +-----------+-----------+----->
                                         |<-- bug -->|<-- bug -->|
                                         |   fixes   |   fixes   |
                                        /           /           /
                                       /           /           /
                                   rel-2-1    rel-2-1-1   rel-2-1-2

I think we can fix this by taking a few steps:

First, we should create a release branch ("rel-2-2-dev") *before* the  
feature freeze, and do the freeze on that branch instead of in HEAD.  
We can upgrade hosted.webwork and math.webwork to this branch at the  
same time, to get some serious testing done. If other developers  
happen to be working on big features at the time, they can continue  
to do so in HEAD.

It would look like this:

      |<-- development -->|<---------- development -------->
HEAD --------------------+------------------------------------------>
                          | /\    /\    /\    /\
                          | ||    ||    ||    ||  bug fixes
                          | ||    ||    ||    ||  forward-ported
                          | ||    ||    ||    ||
     rel-2-2-dev (branch) *--------------+--------------+----->
     (math.webwork and    |<-- freeze -->|<-- freeze -->|
     hosted.webwork run   |  (bugfixes)  |  (bugfixes)  |
     this branch)        /              /              /
                        /              /              /
             (not a release)      rel-2-2-0      rel-2-2-1

Second, we should do minor (2.x) releases more often, maybe every  
four months or so, so that people won't be forced to use HEAD to get  
the latest features. We should also do bugfix releases (2.x.y) VERY  
often -- if we fix a couple of bugs in a month, it's time for a new  
bugfix release.

Third, we should maintain development systems on the release branch  
in addition to the HEAD branch. When we do debugging, we should  
ALWAYS do it on the release branch. When we fix bugs, we should  
ALWAYS commit the fixes to the release branch. My theory is that it's  
easier to forward port bugfixes from a branch that only contains  
bugfixes than it is to tease bugfixes out of an unstable and rapidly- 
changing HEAD and backport them.

Here's a recipe for committing a change to two branches easily. (See  
<http://tinyurl.com/dzan3>.) If your current working copy is on the  
rel-2-2-dev branch:

cd webwork2
<tweak file "foo">
cvs commit foo                        # check into rel-2-2-dev
<CVS says, checked in "foo" version 1.10.2.5>
cvs up -A foo                         # switch to HEAD
cvs up -j 1.10.2.4 -j 1.10.2.5 foo    # merge the change
<deal with conflicts in "foo", if any>
cvs commit foo                        # check into HEAD
cvs up -r rel-2-2-dev foo             # go back to rel-2-2-dev

This gets slightly more complex for multiple file commits, since you  
need a separate merge line for each file:

cd webwork2
<tweak files "foo" and "bar">
cvs commit foo bar                    # check into rel-2-2-dev
<CVS says, checked in "foo" version 1.10.2.5 and "bar" version 1.5.2.4>
cvs up -A foo                         # switch to HEAD
cvs up -j 1.10.2.4 -j 1.10.2.5 foo    # merge the change for "foo"
cvs up -j 1.5.2.3 -j 1.5.2.4 bar      # merge the change for "bar"
<deal with conflicts in both files, if any>
cvs commit foo                        # check into HEAD
cvs up -r rel-2-2-dev foo             # go back to rel-2-2-dev

But most bug fixes should be pretty localized, so I think it'll be  
manageable. If it turns out to be onerous, I can write or find a  
script to do it automatically.

Fourth, we should establish some definite rules for commits to the  
release branch. Of course, only bugfixes should be committed to the  
release branch. In addition, each commit should fix a single bug, and  
each should mention the Bugzilla bug number for the bug it fixes in  
the log message. If we fix a bug that doesn't have a corresponding  
bug report, we should create one and mark it fixed immediately. (The  
goal here is to be able to describe the changes in a bugfix release  
by listing a series of Bugzilla bugs.)

If there are no objections, I'm going to go ahead and branch HEAD as  
rel-2-2-dev, and tag the start of the branch as rel-2-2-pre1 and  
release it. Let me know your thoughts.
- -sam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFDvYUr14CQX+2WvVgRAnFLAJ4tKI2FJlmmZDqcT7o1i3tJb1oMhgCfZcQO
Gv/m1xtpIXdJFWlzcjhoeyA=
=LV0g
-----END PGP SIGNATURE-----

Re: [WWdevel] interval_cmp

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

> In a calculus problem, I want students to find critical points and  
> indicate if they correspond to maxima, minima, or neither.  And I  
> don't want to give away in advance how many points there are.  So I  
> was trying to coerce interval_cmp to do this for me by having it  
> evaluate a set of "intervals," viz.,
>   interval_cmp( "(-2,min),(3,max)", 'unions'=>'no',
> 		'strings'=>['none','min','max','neither'] );

I'm not sure why you are using interval_cmp for this when you could  
use the List object directly.  E.g.,

	Context("Numeric")->strings->add(none=>{},min=>{},max=>{},neither=>{});
	ANS(List("(-2,min),(3,max)")->cmp);

There's really no need to mislabel this as an interval check when it  
isn't.  You are really checking for a list of lists, which is just  
what List() is designed for.  (I agree with John that the semantics  
of the traditional answer checkers are more direct, but the Parser  
versions do allow more flexibility, when it is needed.)

> This works very well, until there is no maximum (or no minimum), in  
> which case
>   interval_cmp( "(-2,min)", 'unions'=>'no',
> 		'strings'=>['none','min','max','neither'] );
> has trouble: as student entering (-2,min) has her/his answer marked  
> wrong with the message "The parentheses for your list should be  
> removed."

I was not able to reproduce this.  Are you using current versions of  
all the Parser files?  (In particular lib/Value/AnswerChecker.pm)

In any case, there was a problem dealing with this that I have fixed,  
so you should get the AnswerChecker.pm that I have just added to teh  
CVS archive.  The issue is that when a student types a list like  
"(1,max)" it is not clear if they mean the list containing two items,  
1 and "max", or the list containing one item, the list "1,max".  The  
default had been the former, which is probably a bad choice, since  
that turns out to be rarely what is intended.  I have changed the  
answer checker to use the latter, and added a flag to allow the  
former behavior in those cases where it is desired.  This should not  
adversely effect existing usages, as it only happens when the student  
explicitly includes the parens.  Anyway, that should clear up your  
problem whether you use interval_cmp or the List object directly.

>  1. Have I overlooked a better way of checking this type of problem?

I think using List() directly makes more sense.

>  2. Is there some feature of interval_cmp that I can change to get  
> a more
>     intuitive (at least from the perspective of a student) behavior?

I think my change to the list checker will take care of this.

>  3. Is there an easy tweak to interval_cmp that will have the same  
> effect?

No need at this point.

> I also have a problem where I want to check the answer "(0,min), 
> (a,max)", where a is a constant.  My rather coarse solution was to  
> copy the interval_cmp evaluator into the problem, calling it  
> my_interval_cmp, and add the variable 'a' to the Parser Context.   
> Is there a better way of doing this?

There wasn't a way using interval_cmp, so I added new "var" and  
"vars" flags that allow you to do

	interval_cmp("(0,min),(a,max)",var=>'a');

One of the problems with using this approach is that the warning  
messages will now say that you are looking for a formula rather than  
a constant.  but in your case, since the items in your list are  
themselves lists, you should not get any type mismatch errors (since  
lists can be practically anything).  The Parser doesn't know what the  
legitimate values for your list are, so can't issue warnings when the  
student types something different.

If you want to provide more meaningful error messages, you can supply  
your own type checker as follows:

	Context("Numeric")->strings->are(none=>{},max=>{},min=>{},neither=>{});
         Context()->variables->add(a=>'Real');

	ANS(List("(0,max),(a,max)")->cmp(
	  typeMatch => sub {
	    my $student = shift;
	    return 0 unless $student->type eq 'List' && $student->length == 2;
	    my ($x,$t) = $student->value;
	    return ($x->type eq 'Number' && $x->class ne 'Formula') && $t- 
 >type eq 'String';
	  },
	  entry_type=>"a critical-point specification",
	));

	$showPartialCorrectAnswers = 1;

This overrides the type checker and supplies your own that checks  
that the student answer is a list of the desired form (a number  
followed by a string value).  The list checker will call this on each  
answer, and will report an error if the result is zero (or false).  I  
also supply an entry_type string that will be part of the messages.   
You will get messages like "Your first critical-point specification  
is incorrect" and "Your first value doesn't look like a critical- 
point specification (it looks like a ...)" in the situations where  
these apply.

A more complicated approach would be to define your own Parser  
syntax, say "-2 = max" or "-2 => max" or some such, and then ask for  
a list of those.  The "=" or "=>" would be an operator, and it could  
return a list formed by its two operands, so that the equality  
checking would as expected.  It wouldn't be too hard to do, so if you  
want that, let me know and I'll give it a shot (I'm not doing it now,  
since I already spent most of the morning on this, and I have to get  
back to work :-).

John's suggestion of an array of text entries with pop-up lists also  
looks like a possibility, though you would have to handle the pairing  
of numbers with menus yourself, and allowing the points in any order  
(and not repeated) and so on.  The Multipart object can certainly  
handle that, though there is some work to do.  I haven't tried nested  
multi-parts, but if that worked, it would simplify things  
considerably (use a bunch of ordered multi-parts for the pairs of  
number with pop-up, and then collect those into an unordered multipart).

Davide

Re: [WWdevel] interval_cmp

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

Hi Gavin,

Interval_cmp is now a front-end to the Parser for its answer checking.  
Some people (including me) are more comfortable with its semantics, so 
it will persist, but if you need to do something with extra 
complications, you should probably use the Parser directly.

 From the cvs updates, I can see that Davide has made some changes 
recently to make this work better using the Parser.

Another way to go would be to think of other ways for students to input 
their answers here.  It seems to me that the most natural interface to 
the student would be a column of entry text boxes, each with a drop-down 
list next to it (for picking from ?, max, min, neither), where the order 
is not important, and unused entries can be left blank.  I sure the 
multipart checker could handle that.

John


P Gavin LaRose wrote:

> Hi guys (esp. John),
>
> I have a question about the behavior of interval_cmp (from John's 
> extraAnswerEvaluators.pl macro file).  I'm using it in a brutally 
> unintended way, which may explain why I am (or it is) confused.
>
> In a calculus problem, I want students to find critical points and 
> indicate if they correspond to maxima, minima, or neither.  And I 
> don't want to give away in advance how many points there are.  So I 
> was trying to coerce interval_cmp to do this for me by having it 
> evaluate a set of "intervals," viz.,
>   interval_cmp( "(-2,min),(3,max)", 'unions'=>'no',
>         'strings'=>['none','min','max','neither'] );
>
> This works very well, until there is no maximum (or no minimum), in 
> which case
>   interval_cmp( "(-2,min)", 'unions'=>'no',
>         'strings'=>['none','min','max','neither'] );
> has trouble: as student entering (-2,min) has her/his answer marked 
> wrong with the message "The parentheses for your list should be 
> removed." Removing the parentheses works if the interval_cmp call is 
> changed to
>   interval_cmp( "-2,min", 'unions'=>'no',
>         'strings'=>['none','min','max','neither'] );
>
> So I guess I have a couple of questions.  Or three.
>  1. Have I overlooked a better way of checking this type of problem?
>  2. Is there some feature of interval_cmp that I can change to get a more
>     intuitive (at least from the perspective of a student) behavior?
> and/or
>  3. Is there an easy tweak to interval_cmp that will have the same 
> effect?
>
> Thanks, and Happy New Year,
> Gavin
>
> p.s. I also have a problem where I want to check the answer 
> "(0,min),(a,max)", where a is a constant.  My rather coarse solution 
> was to copy the interval_cmp evaluator into the problem, calling it 
> my_interval_cmp, and add the variable 'a' to the Parser Context.  Is 
> there a better way of doing this?
>

[WWdevel] interval_cmp

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

Hi guys (esp. John),

I have a question about the behavior of interval_cmp (from John's 
extraAnswerEvaluators.pl macro file).  I'm using it in a brutally 
unintended way, which may explain why I am (or it is) confused.

In a calculus problem, I want students to find critical points and 
indicate if they correspond to maxima, minima, or neither.  And I don't 
want to give away in advance how many points there are.  So I was trying 
to coerce interval_cmp to do this for me by having it evaluate a set of 
"intervals," viz.,
   interval_cmp( "(-2,min),(3,max)", 'unions'=>'no',
 		'strings'=>['none','min','max','neither'] );

This works very well, until there is no maximum (or no minimum), in which 
case
   interval_cmp( "(-2,min)", 'unions'=>'no',
 		'strings'=>['none','min','max','neither'] );
has trouble: as student entering (-2,min) has her/his answer marked wrong 
with the message "The parentheses for your list should be removed." 
Removing the parentheses works if the interval_cmp call is changed to
   interval_cmp( "-2,min", 'unions'=>'no',
 		'strings'=>['none','min','max','neither'] );

So I guess I have a couple of questions.  Or three.
  1. Have I overlooked a better way of checking this type of problem?
  2. Is there some feature of interval_cmp that I can change to get a more
     intuitive (at least from the perspective of a student) behavior?
and/or
  3. Is there an easy tweak to interval_cmp that will have the same effect?

Thanks, and Happy New Year,
Gavin

p.s. I also have a problem where I want to check the answer 
"(0,min),(a,max)", where a is a constant.  My rather coarse solution was 
to copy the interval_cmp evaluator into the problem, calling it 
my_interval_cmp, and add the variable 'a' to the Parser Context.  Is there 
a better way of doing this?

-- 
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] recent changes

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

That's the same thing I'm seeing here.  I have one record of the  
error in the logs and I haven't been able
to reproduce it since.

I'll keep watch.

Take care,

Mike

On Dec 27, 2005, at 5:15 PM, John Jones wrote:

> Michael Gage wrote:
>> Hi John,
>>
>> I just updated hosted.webwork.rochester.edu and while I haven't  
>> been able to trigger the error, one of the
>> users of hosted has.  Unfortunately when I log in to her course I  
>> can't trigger it myself.
>>
>> Can you tell me what you do to trigger the error?  Is it just  
>> viewing the problem set as a student?
>> or do you need to edit something?
> I was logged in as myself (permissions 10), and just clicked on the  
> name of the problem set.
>
> I stopped and restarted the webserver, and the problem persisted.   
> I came back later, and it had cured itself.  Now it won't come  
> back.  So, I have no idea what triggered it, and now I can't  
> reproduce it.
>
> John
>

Re: [WWdevel] recent changes

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

Michael Gage wrote:

> Hi John,
>
> Another issue.  I added some configurations to the Course Configuration
> page -- these are mostly changes in Constants.pm, but I also added a  
> widget
> to Config.pm -- one that allows a choice of values for the pop-up  
> menu.  This
> is used to choose the theme for the course.  I'd appreciate it if  
> you'd check the code and make sure I added the widget properly.

It seems to work.  I was going to look to see if it could avoid 
overriding some of the widget methods (probably not).

I was wondering if it should deduce the available themes itself (by 
looking in htdocs/css).

John

Re: [WWdevel] recent changes

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

Hi John,

On the comment below -- I'm pretty sure that the psvn being passed to  
PG::new() is extraneous.
It is not used as best I can remember.  I've been planning to take it  
out at some point, but I guess
I never remembered to do it when I had sufficient time to check the  
consequences. I'm 99% sure
that it is never used.

Take care,

Mike
On Dec 27, 2005, at 1:58 PM, John Jones wrote:

> In trying to see what might be the matter, I was confused by the  
> passing of psvn  to WeBWorK::PG::new, which then gets passed  
> forward.  It looks like the psvn value which is passed is never  
> used.  Instead, the routines are extracting it from $set (which is  
> where the error comes from).

"Only dead fish swim with the stream."

Re: [WWdevel] recent changes

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

Hi John,

Another issue.  I added some configurations to the Course Configuration
page -- these are mostly changes in Constants.pm, but I also added a  
widget
to Config.pm -- one that allows a choice of values for the pop-up  
menu.  This
is used to choose the theme for the course.  I'd appreciate it if  
you'd check the code
and make sure I added the widget properly.

Take care,

Mike

On Dec 27, 2005, at 1:58 PM, John Jones wrote:

> Hi,
>
> I just did a cvs update and get the errors below on the list of  
> problems page, in the right panel which shows the screen set  
> header.  I have not made any changes to the headers recently.  I  
> can't see where other recent changes might be causing this either.
>
> In trying to see what might be the matter, I was confused by the  
> passing of psvn  to WeBWorK::PG::new, which then gets passed  
> forward.  It looks like the psvn value which is passed is never  
> used.  Instead, the routines are extracting it from $set (which is  
> where the error comes from).
>
> John
>

[WWdevel] recent changes

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

Hi,

I just did a cvs update and get the errors below on the list of problems 
page, in the right panel which shows the screen set header.  I have not 
made any changes to the headers recently.  I can't see where other 
recent changes might be causing this either.

In trying to see what might be the matter, I was confused by the passing 
of psvn  to WeBWorK::PG::new, which then gets passed forward.  It looks 
like the psvn value which is passed is never used.  Instead, the 
routines are extracting it from $set (which is where the error comes from).

John



      Warning messages


      Error messages

    |Can't call method "psvn" without a package or object reference at
    /opt/devel/webwork-modperl/lib/WeBWorK/PG.pm line 78.
    |


      Call stack

The information below can help locate the source of the problem.

    * |in WeBWorK::PG::Local::new called at line 50 of
      /opt/devel/webwork-modperl/lib/WeBWorK/PG.pm|
    * |in WeBWorK::PG::new called at line 223 of
      /opt/devel/webwork-modperl/lib/WeBWorK/ContentGenerator/ProblemSet.pm|
    * |in WeBWorK::ContentGenerator::ProblemSet::info called at line 152
      of /opt/devel/webwork-modperl/lib/WeBWorK/Template.pm|
    * |in WeBWorK::Template::template called at line 437 of
      /opt/devel/webwork-modperl/lib/WeBWorK/ContentGenerator.pm|
    * |in WeBWorK::ContentGenerator::content called at line 174 of
      /opt/devel/webwork-modperl/lib/WeBWorK/ContentGenerator.pm|
    * |in WeBWorK::ContentGenerator::go called at line 299 of
      /opt/devel/webwork-modperl/lib/WeBWorK.pm|

[WWdevel] Re: funny formatting problem?

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

On Dec 22, 2005, at 12:12, P Gavin LaRose wrote:

> Hi Sam,
>
> I just noticed that a regular homework problem set problem list  
> shows up as the attached on my workstation.  (The fonts seem to be  
> the wrong size.)
>
> This is Firefox 1.0.7 on RedHat Enterprise, with random fonts  
> installed.
>
> I'm not sure if this is a bug or a function of my configuration,  
> but I thought you might be interested in it.

This is because the left-side menus have a fixed width.

I want to play with adding the Unicode "ZERO WIDTH SPACE" character  
in the same places that we split for sorting set names (lower-to- 
upper boundaries, digit/non-digit boundaries).
-sam

[WWdevel] impending release -- get your changes in

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

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

Hi All,

We're planning to release HEAD as WeBWorK 2.1.4 in a week or so. I'm  
working on resolving all "important" bugs before then. As always, if  
you have pet bugs you'd like fixed, please let me know. If you have  
changes in your local source tree that are stable, and you'd like to  
see in the release, commit them now.

Our hope is that by releasing soon, administrators will have time to  
deploy 2.1.4 before the start of the Spring semester.
- -sam, WeBWorK Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFDoaXJ14CQX+2WvVgRAt09AKCcy/fWJW79w7JbTh++0GMtPJQEjQCgoBsl
CpMowYF/7BJznxgJLGfYBYA=
=hgtW
-----END PGP SIGNATURE-----

Re: [WWdevel] Fwd: [WWcvs] pg: give answer is equivalent message regardless of correctness.

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

On Dec 13, 2005, at 16:32, Davide P.Cervone wrote:

> On Dec 13, 2005, at 1:23 PM, Sam Hathaway via activitymail wrote:
>> give answer is equivalent message regardless of correctness.
>> fixes bug #752.
>
> I'm not sure I think this is the right solution to this.  Now the  
> student can test for equivalence of answer without submitting.  I  
> think of preview mode as not giving any information except how the  
> expression has been parsed.  It should only give information about  
> how the answer is being interpretted, not anything else about the  
> answer (in my opinion).  Being told that it is the same as the  
> previous answer is information about the meaning and the value of  
> the answer, and I don't think that belongs in preview mode.

I see your point. That's quite right.

> The lines you changed had already fixed bug 752 in the sense that  
> they did not give the message in preview mode regardless of the  
> correctness.  So this "attack" on the problem is already blocked by  
> the old version.

I was looking at the Parser version but testing the non-Parser  
version. I backed out of the change to the parser version, and added  
the "isPreview" check to the non-parser version.

Thanks.
-sam

[WWdevel] Fwd: [WWcvs] pg: give answer is equivalent message regardless of correctness.

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

On Dec 13, 2005, at 1:23 PM, Sam Hathaway via activitymail wrote:
> give answer is equivalent message regardless of correctness.
> fixes bug #752.

I'm not sure I think this is the right solution to this.  Now the  
student can test for equivalence of answer without submitting.  I  
think of preview mode as not giving any information except how the  
expression has been parsed.  It should only give information about  
how the answer is being interpretted, not anything else about the  
answer (in my opinion).  Being told that it is the same as the  
previous answer is information about the meaning and the value of the  
answer, and I don't think that belongs in preview mode.

The lines you changed had already fixed bug 752 in the sense that  
they did not give the message in preview mode regardless of the  
correctness.  So this "attack" on the problem is already blocked by  
the old version.

Just a thought.

Davide

[WWdevel] Re: [WWcvs] webwork2: Allow reordering to succeed even if some UserProblems are

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

Sam Hathaway via activitymail wrote:

>Lingering questions:
>
>(1) When multiple problems are assigned the same number, this results in 
>the last one ending up first in the new ordering. I think it would be 
>more natural for the first one to end up first. This would be an easy 
>fix.
>  
>
It depends.  If the only change the user makes is to set number 5 to 
number 2 (so he leaves number 2 as number 2), then the old number 5 
should become the new number 2 even though it started with the higher 
number.

>(2) $force always gets set if reordering needs to be done, so we aren't 
>able to delete a problem, reorder some other problems, and end up with a 
>hole where where the deleted problem was. We can either fix this by 
>mentioning this next to the force checkbox, or change it so that 
>particular holes (i.e. those left by deleted problems) are allowed when 
>reordering.
>  
>
The only reason for leaving holes that I know of is if an assignment is 
already out to students and you want to remove a bad problem without 
changing the other problem numbers.  It is hard to imagine someone who 
wants to do that and change the order of some of the problems.  So, I 
would suggest documenting it rather than providing a means for leaving a 
hole in the numbering.

John

[WWdevel] ssh connection multiplexing -- great stuff

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

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

Hi everyone,

OpenSSH 4.0 has the ability to multiplex multiple sessions on top of  
one connection. That means that there can be only one TCP session,  
only one key exchange, only one login, etc. for all your connections  
to a particular server. This speeds things up considerably! I find  
this particularly useful for remote editing of WeBWorK files on  
devel. It could also be useful for remote CVS activities.

The catch is you have to update your SSH client to version 4.0 or  
greater. I did it on Mac OS X with Fink. Most Linux distros supply it  
as well.

Instructions are at:

http://www.debian-administration.org/articles/290
http://gcc.gnu.org/wiki/SSH%20connection%20caching

I use Interarchy on the Mac, and though it does internal connection  
caching, it doesn't do multiplexing, and the cached connections time  
out after a while. I used to find it really annoying when I had to  
wait for a reconnect when going back to an Interarchy window after a  
while.

One catch with this setup is that if you put a "ControlMaster" line  
in your ~/.ssh/config file, you'll have to actually replace /usr/bin/ 
ssh with the new version, or Interarchy will choke while connecting.  
I renamed /usr/bin/ssh to ssh.ORIG and put a symlink to /sw/bin/ssh  
at /usr/bin/ssh.

Hope this is useful to you all.
- -sam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFDlJ3214CQX+2WvVgRAh+CAJ9txpBnv1viHJhwebuGSF3HPWPixACfQxkD
jYAEeCUX4WyCw2gwCGdHaKk=
=m1D9
-----END PGP SIGNATURE-----