There seems to be a slight bug when entering "NONE" or "none" as an answer to a List that's begun with the number 0, e.g.
ANS(List("0, 1")->cmp);
It returns the following error message:
String constant 'Value::List' is not defined in this context
As near as I can tell, this is the only circumstance under which the above error occurs; 0 has to not only be in the list, it has to begin the list -- but the nature of the other numbers in the list is irrelevant AFAICT -- and the answer has to be "NONE" or "none" (other ones are interpreted either as constants (e.g. "e") or variables (e.g. "p")).
Also: I think we're always using Parser.pl, instead of MathObjects.pl, in our source code. How much of a difference do people think this is going to make, deprecation notwithstanding? If I were to simply add the string "MathObjects.pl" to all the loadMacros currently using "Parser.pl", would I have to edit any of the resulting problems?
As always, thanks for any advice you can give.
I think this was corrected in version 1.91 of pg/lib/Value/AnswerChecker.pm. What version of this file are you using? The change was about 4 months ago. In any case, I can't reproduce the error, so I'm pretty sure that was taken care of.
Davide
Davide
I realized I hadn't answered your second question.
You should use MathObjects.pl in place of Parser.pl. The original name for MathObjects was Parser Objects, and Parser.pl was the file that made them available. At the beginning of the summer, we changed the name to MathObjects, which was more descriptive (most people don't know what a parser is anyway), and so MathObjects.pl was created. It simply loads Parser.pl, so there is no need for both. You should use MathObjects.pl rather than Parser.pl, though they both currently do the same thing.
(Actually, we should move the contents of Parser.pl to MathObjects.pl and make Parser.pl call MathObjects.pl, and eventually remove Parser.pl).
Davide
You should use MathObjects.pl in place of Parser.pl. The original name for MathObjects was Parser Objects, and Parser.pl was the file that made them available. At the beginning of the summer, we changed the name to MathObjects, which was more descriptive (most people don't know what a parser is anyway), and so MathObjects.pl was created. It simply loads Parser.pl, so there is no need for both. You should use MathObjects.pl rather than Parser.pl, though they both currently do the same thing.
(Actually, we should move the contents of Parser.pl to MathObjects.pl and make Parser.pl call MathObjects.pl, and eventually remove Parser.pl).
Davide
I actually don't know what version of the Parser we're running here, all I know is that I'm a little scared of trying to run an update on webwork while > 1000 students are actually using it for homework purposes :) CVS, don't fail me now...
Also, when you say "use in place of", can I really just s/Parser.pl/MathObjects.pl/g throughout the entire course -- in which case I'll just write an appropriate script and *zap* the whole thing in one fell swoop -- or are there additional changes that I'll need to make by hand?
Also, when you say "use in place of", can I really just s/Parser.pl/MathObjects.pl/g throughout the entire course -- in which case I'll just write an appropriate script and *zap* the whole thing in one fell swoop -- or are there additional changes that I'll need to make by hand?
I actually don't know what version of the Parser we're running here
You can find out by CDing to the pg/lib/Value directory and using the command
cvs status AnswerChecker.pm
which will list both the version you have and the version in the repository.
I'm a little scared of trying to run an update on webwork while > 1000 students are actually using it for homework purposes
I fully understand, and it is definitely good practice to hold off such changes until in between terms. On the other hand, the pg code is very well isolated from the rest of WeBWorK, and I have never had a problem upgrading pg without updateing WeBWorK. I am running the current HEAD version of pg with version 2.3.1 of WeBWorK, for example. I would NOT update webwork itself, only the pg directory.
Unless you are very far out of date (more than a year, say), I don't think you will have any problems updating pg. To be safe, you can make a copy of the pg directory (preserving the permissions and ownership), before doing the update. Or you could simply check out a new copy and then rename the old pg directory as pg-old and the new copy as pg (in quick succession) and then restart the server. That way, you can always just name the directories back again if there is trouble and you would have your original setup back again instantly.
Also, when you say "use in place of", can I really just s/Parser.pl/MathObjects.pl/g throughout the entire course
Yes, that is exactly what I mean. The one file simply loads the other and does nothing else. Unless some other file matches Parser.pl, I don't see any problem (though you might want Parser\.pl rather than Parser.pl).
Davide
We do look pretty far out of date; AnswerChecker.pm, for example, is 1.78 here and 1.114 in the repository. Based on that, would you recommend an update of the pg files during the semester?
Also: I did finally write that simplification checker -- more or less ;) -- but it manipulates Parser and Formula objects rather extensively. Has the basic tree structure of those objects changed significantly between 1.39 and 1.60 (Formula.pm), 1.52 to 1.92 (Value.pm) or 1.31 to 1.48 (Parser.pm)?
Also: I did finally write that simplification checker -- more or less ;) -- but it manipulates Parser and Formula objects rather extensively. Has the basic tree structure of those objects changed significantly between 1.39 and 1.60 (Formula.pm), 1.52 to 1.92 (Value.pm) or 1.31 to 1.48 (Parser.pm)?
Yes, I would say that you can do the update, but I'd still recommend following the backup procedure that I outlined above. I did a quick scan of the changes since then, and there don't appear to be any backward compatibility issues.
The tree structure hasn't changed, so your simplification checker should still work. (That is, of course, without having seen any of the code). There were some significant changes this past summer, but they are mostly to the non-formula MathObjects, and I tried hard to make it all backward compatible.
Davide
The tree structure hasn't changed, so your simplification checker should still work. (That is, of course, without having seen any of the code). There were some significant changes this past summer, but they are mostly to the non-formula MathObjects, and I tried hard to make it all backward compatible.
Davide