Develop wwclientsup8 #672
Develop wwclientsup8 #672
Conversation
…ot always set by standalone editor. Should we continue to support apache 1? or just move entirely to apache2?
…roblems at least.
… sendxmlrpc client. This is a sample -- something similar, but definitely not identical, can be used to connect other editors to the client.
# Conflicts: # lib/WebworkClient.pm
|
This set of commits should look a lot shorter once wwclientsup7 is pulled. This pull should finish the job of making it possible to check all problems in a given directory. |
|
At that point you can do more massive checking of the webwork2 part of this change. The PG part of this change seems more straightforward but it changes some basic structure of PG and it will take a while to make sure that subtle gremlins haven't been created. The automatic tester helps with this. |
|
Check the merge at 6f9fc08. Make sure that the choices I made with respect to essay questions in Problem.pm are correct. (I didn't work on those files and it wasn't always clear which was the desired code in the conflict.) |
|
I dont see any changes in Problem.pm that impact essay questions. What On Sun, Jan 3, 2016 at 9:40 AM, Michael Gage notifications@github.com
|
|
What is going on with that commit. It has an awful lot of jitar changes On Sun, Jan 3, 2016 at 11:13 AM, goehle@gmail.com goehle@gmail.com wrote:
|
|
What I was worried about came from the merge. I expect I had built on an earlier version of your
|
|
I still dont know what code your talking about. But essay answers havent On Sun, Jan 3, 2016 at 8:53 PM, Michael Gage notifications@github.com
|
|
It’s referencing devel from a long time ago at the moment. I was expecting
|
|
I did pull wwclient 5 On Sun, Jan 3, 2016 at 8:55 PM, Michael Gage notifications@github.com
|
…wwclientsup8 # Conflicts: # lib/WeBWorK/ContentGenerator/instructorXMLHandler.pm # lib/WebworkClient.pm # lib/WebworkWebservice.pm
|
Here is a list of things from wwclients7 that were pushed forward:
|
# Conflicts: # lib/WeBWorK/ContentGenerator/instructorXMLHandler.pm
| @@ -0,0 +1,4 @@ | |||
| #!/usr/bin/perl -w | |||
There was a problem hiding this comment.
This whole tool is too mac specific. It has hardcoded paths and is centered around BB edit. I would just keep this on your computer as a personal tool, or find some way to make it configurable to work on linux with emacs/vim/nano/whatever.
There was a problem hiding this comment.
P.S. A good place for this (and other scripts you find useful) would be http://webwork.maa.org/wiki/Contributed_Admin_Scripts_(Large_Installations)#.VqVM3N9vGEI
I think it would be great if this page could be cleaned up and brought into the light a little bit more. We need a place for tools which sys admins may find useful but which are not polished enough, or are too specific, for git.
There was a problem hiding this comment.
What I was envisioning was having a number of tools like this -- one for each OS. The tool is so small it's hardly worth configuring. Which editor do you use? Could you write a matching tool for that? It's convenient to write in your favorite editor and then just hit a button to see what you have rendered so far.
It could go in admin scripts (it has the same flavor in that it almost demands being customized to the users environment) but it's really more of an author tool -- as are the various flavors of clients. Maybe when we polish up the admin page we can add one for author tools.
There was a problem hiding this comment.
I'd really like to see some versions of this file for emacs, or vim or nano or sublime, etc. Then authors will have some models to start with to build connecting links that suit their own work flow.
There was a problem hiding this comment.
I think having multiple versions is the wrong way to go. IMO it should be a single tool configurable by things like environment variables, config files, etc... For example most linux distributions have an EDITOR environment variable that people will set (https://en.wikibooks.org/wiki/Guide_to_Unix/Environment_Variables). If you used that you could probably get rid of the BB edit specific stuff.
More generally, I'm not a fan of having files that you need to configure to use be managed by git. It really interferes with the git workflow since those files are tracked and your changes will have a tendency to revert, get overwritten, or cause conflicts.
There was a problem hiding this comment.
It wouldn't work for BBedit -- this file is an extension of BBedit and needs to be moved to a specific directory in order to work. It's like writing a small extension for emacs.
There was a problem hiding this comment.
By the way — its ok if the bbedit connection file is stored somewhere else as long as it is highly visible to people who want to use it as a model to
write their own connecting tool.
On Jan 24, 2016, at 7:42 PM, Geoff Goehle notifications@github.com wrote:
@@ -0,0 +1,4 @@
+#!/usr/bin/perl -w
I think having multiple versions is the wrong way to go. IMO it should be a single tool configurable by things like environment variables, config files, etc... For example most linux distributions have an EDITOR environment variable that people will set (https://en.wikibooks.org/wiki/Guide_to_Unix/Environment_Variables https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikibooks.org_wiki_Guide-5Fto-5FUnix_Environment-5FVariables&d=BQMCaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=C6Pt5AGtImanmAdcooarL-JZO8M5dSFPfs3VweYXYkE&m=ks-sV4IwC-I5SHSObvclCpZW-Xt8uu3XYG1iJsbHRcM&s=GswFzmTp4Rj1NWw078NB7RgtxFrE5P2Px_ZHc-kGMFs&e=). If you used that you could probably get rid of the BB edit specific stuff.More generally, I'm not a fan of having files that you need to configure to use be managed by git. It really interferes with the git workflow since those files are tracked and your changes will have a tendency to revert, get overwritten, or cause conflicts.
—
Reply to this email directly or view it on GitHub https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openwebwork_webwork2_pull_672_files-23r50646605&d=BQMCaQ&c=kbmfwr1Yojg42sGEpaQh5ofMHBeTl9EI2eaqQZhHbOU&r=C6Pt5AGtImanmAdcooarL-JZO8M5dSFPfs3VweYXYkE&m=ks-sV4IwC-I5SHSObvclCpZW-Xt8uu3XYG1iJsbHRcM&s=kM4ZPkOKTuytsixKoRHS6ugL733oXczk_02vF_UAWWI&e=.
|
Is it possible there were merge issues when you fixed conflicts with develop? There are only 4 changed files, two basically trivial ones and two new additions. The newly added files are FormatRenderedProblem.pm and system2.template, however I can't find any references to either of these two files being used in develop or this branch. |
|
I've removed system2.templates --- it was an earlier version of simple.templates. I've also changed the templateName() method in Problem.pm, ProblemSet.pm and ProblemSets.pm so that those pages can access other templates. (I also removed a restriction that the template had to be named system, simple or gateway as being overly cautious). There are files in webwork2/t for testing these templates: |
|
Should the the 2 test .pg problems be in pg/t and not webwork2/t ? |
|
I'll make a list of things below to check up on:
You were going to look at redoing a couple things with the detail problem debugging info. The two that I remember are
|
… all non-empty strings. ProblemSeed=0 is considered to be an empty string.
… xmlrpc (through WebworkClient) and via ContentGenerator (standard webwork2 interface).
|
alternate_templates.html has been cleaned up and points to hosted2. Check that two templates work acceptably when viewing a problem (Problem.pm), a homework set homepage (ProblemSet.pm) or a course homepage (ProblemSets.pm). The links on the homework set homepage and course homepage revert back to the "system" template for now. The "simple" template is not sticky in those cases. It should be sticky for a single problem. simpleTemplateTest.html.dist also points to hosted2 -- compares appearance of the WebworkClient "simple" template (used for xmlrpc) with the simple template used through ContentGenerator (the webwork2 route) If displayMode, courseID, userID, or problemSeed is missing then the problem is not rendered and the server returns an error message for the request. Check that this works properly on hosted2 (when it is running the most recent develop). Check that it is not possible to use this error message for XSS. |
…s to be shown. (The introduction of knows changes when the showHint and showSolution checkbox are displayed. Even if knowls is disabled the checkboxes already display "show hints" and "show solutions" as labels. )
|
Fixed display of Show. Test by viewing a problem containing a hint as a student. If you have patience disable showing knowls for hints and for solutions and test again. Also view the same problem after the due date when both show solutions and show correct answer check boxes are available to make sure that the presentation is acceptable. |
|
Great, I'll try to check this stuff out later today. Two things.
|
|
which branch do you want pulled? ltigrade? That hasn't yet been pull requested to openwebwork, but I can pull directly from your github. There is a trade-off between error messages when important information hasn't been provided and supplying defaults (which in some cases can become confusing if the guessed defaults are not appropriate). Needing the defaults for LTI requests seems like a good reason to provide them. I'll make those changes in the next pull request wwclientsup9 so there is a clear record of which changes were made to accommodate LTI. |
|
I made a pull request directly to your github account. On Sun, Feb 21, 2016 at 9:58 AM, Michael Gage notifications@github.com
|
…configurations can be made in that file and that the lack of a configuration is either reported or replaced with a sensible default. (The webwork displayMode defaults to "MathJax" for example.) The hash output modes print directly to STDOUT -- one can pipe this through less if desired, or use the output in otherwise. The output continues to be pretty printed. It is possible to set the log file path using --log=path_to_log_file. The path defaults to ...../webwork2/DATA/xmlrpc_results.log
|
Move more configuration to the ww_credentials.dist file. Allow log file path to be specified using --log. Test by changing the various configurations in ww_creditentials (or your private copy of same). Make sure that the configurations take effect and that if they are omitted either an appropriate warning or an appropriate default is chosen. Check that the --log=path_to_log_file switch works correctly. (The full path is required.) Check that the directions in --help and the directions given in the POD documentation agree. |
…develop_wwclientsup8
|
Merged myclients8 from goehle. Tests: ?? |
|
Remaining items:
|
|
PGinfo now prints without using the macro file PGinfo.pl. Both of these fixes involve changes only to pg files -- they appear in the pull request develop_showinfo |
|
I tested the following and everything checked out, so I will merge the result.
|
Replaces the client "renderProblem.pl" and various derivatives with a single script "sendXMLRPC.pl".
Using switches this script has all the capabilities of the previous collection of clients.
It should also be compared to the script "standalonePGproblemRenderer.pl" in the github.com/mgage/standaloneProblemRenderer repo. That script behaves in exactly the same way but instead of sending the problem via xmlrpc to be rendered remotely it connects directly to a local pg repo and renderers it that way. standaloneProblemRenderer is currently more experimental. It is faster, but it also reveals a memory leak in PG, so having it process 100's of files in a directory will probably cause the process to exceed RAM memory bounds
Command line commands connect the clients to browsers and to editors. Some adjustments may need
to be made at the top of the file to switch the commands from Mac specific commands for BBEdit and Chrome to unix commands for other browsers and editors.
After setting up a credentials file the beginning tests
(the tests for standaloneProblemRenderer are essentially the same.)
sendXMLRPC.pl -bB input.pg --- displays problem in the browser, then answers the questions and displays again
sendXMLRPC.pl -C input.pg -- enters an entry in the log file webwork2/DATA/bad_problems.txt -- indicates whether the problem would accept its own correct answers.
sendXMLRPC.pl -C /opt/webwork/libraries/webwork-open-problem-library/OpenProblemLibrary/Utah
will check all of the files in the Utah section of the OPL.
sendXMLRPC.pl --help will print a copy of the POD documentation describing the switches.
(Check that these two bits of documentation remain in sync and that they give adequate instructions.)
sendXMLRPC.pl -v input.pg ----- gives more verbose output useful for debugging
NAME
webwork2/clients/sendXMLRPC.pl
DESCRIPTION
This module provides functions for rendering html from files outside the
normal context of providing a webwork homework set user an existing
problem set.
SYNOPSIS
sendXMLRPC -vcCbB input.pg
DETAILS
credentials file
These locations are searched, in order, for the credentials file.
("$ENV{HOME}/.ww_credentials", "$ENV{HOME}/ww_session_credentials", 'ww_credentials')
Options
-a
Displays the answer hashes returned by the question on the command line.