MathQuill replaces AnSwEr input fields#922
Conversation
|
This branch looks much simpler, thanks! You should probably remove your old branches that are no longer needed (as they complicate the network diagram unnecessarily). An @mgage can remove his branch, as yours now includes all of his commits. |
|
Further customization to the handling of "union" now creates Modifications to .text() output: inserting whitespace into text output to ensure that we 'exit' out of fractions properly (issues with mismatching parenthesis when re-rendering a submitted student answer). Also corresponding modifications to .typedText() to read inputs with whitespace-as-tabs according to the MathQuill.options setting. I believe this is functional enough for some of my more-experienced instructors to begin using with their classes. I'm proceeding with a beta-test of this feature in a handful of classrooms. I will continue to keep this thread updated with issues that we encounter (and hopefully fixes for them as well). |
I've now fixed the text-mode issue, and raw text strings are behaving normally. As discovered by our |
MathQuill editor idea.
inputs should be hidden.
method in ProblemUtil.pm, and call that from both the gateway quizzes and single problems.
notably the fix to the text block handling.
answer boxes. Each response group can set options individually. For example if a problem wants to change the way that roots are sent to webwork from the (current) default of entering root(a,b) to b^(1/a), and also change it so that '+-=<>' don't end superscripts and subscripts, then the in the pg problem file do: $answer->cmp(mathQuillOpts => "rootsAreExponents: 1, charsThatBreakOutOfSupSub: ''") Any of the MathQuill document options can be set in this way as well as our added option above (rootsAreExponents), with the exception of the handlers option. Also add in some niceties to the way that the mathquill answer boxes work.
…ce1/webwork2 into develop_mathquill-GR
…_past_answer table
encountered in createAnswerQuill method of mqeditor.js, do not return false. That ends the processing of the jQuery .each function, and so any valid inputs after that are skipped. Also in the mathquill toolbar, remove the intersection and inequality buttons, and add a text button. The charsThatBreakOutOfSupSub option of mathquill is also removed. Finally, just a little code clean up in the ProblemUtil.pm file.
are converted to exponents. Probably the ideal thing to do here would be to have the parserRoot.pl PG macro set the rootsAreExponents option to false automatically.
|
Another round of updates to this feature - which is proving quite robust by this point! Big thanks to @drgrice1, who had the excellent idea of stashing the LaTeX'ed version of the student answer with the other "sticky" answers (in _problem_user). These extra, hidden answer blanks are also then removed before responses are stored in _past_answer. The mathquill feature now replaces all answer blanks (both for named_ans and the usual AnSwEr blanks), and will accurately re-render the most recent student input when the page is reloaded. A sidebar with commonly used structures has also been added - allowing for alternate entry of fractions, radicals, text mode, etc... PG problems can also pass an option (rootsAreExponents: true/false) to the mathquill object, determining whether or not non-square roots should be interpreted as rational exponents (default) or as @drgrice1 am I forgetting anything? |
|
I think you covered the changes. It might also be noted that there is information in ddeff29 as to how to set the rootsAreExponents and other MathQuill options from a PG problem. |
|
Merging the MathQuill PR #922 |
|
@drdrew42 @taniwallach @mgage : |
|
@nmoller Thanks for having a look - yes, that looks accurate. (Though I certainly need to do some housecleaning and prune some of those old WW branches.) In short, yes, one must update the user tables in the db for the use of this new feature. |
|
Thanks for the hints. After doing that: The admin part does work... but login in as a student in a course and going to the set.... and I'm still having |
|
Now log into the admin course and "upgrade courses" |
|
Still...It does not work. I add an user.... I choose MathQuill in the course config. And everything works.. |
Maybe change the user's config of the old course to use MathView, save the change, then change it to use MathQuill and save the change. Hopefully that will force the DB to get a valid setting in the field which had not existed in the past. I'm suggesting 2 steps just in case setting something expected as the current value would not trigger a save to the DB. |
| useWirisEditor => $ce->{pg}->{options}->{useWirisEditor}, | ||
| useMathView => $user->useMathView ne '' ? $user->useMathView : $ce->{pg}->{options}->{useMathView}, | ||
| useWirisEditor => $user->useWirisEditor ne '' ? $user->useWirisEditor : $ce->{pg}->{options}->{useWirisEditor}, | ||
| useMathQuill => $user->useMathQuill ne '' ? $user->useMathQuill : $ce->{pg}->{options}->{useMathQuill}, |
There was a problem hiding this comment.
Is it possible that $user->useMathQuill is a false-ish value that is also not explicitly equal to empty-string? In which case, the un-initialized course (that has been converted via "upgrade courses") has the sort of unintended consequences that @nmoller is seeing here?
Would it be better to use $user->useMathQuill ? if_yes : if no instead of ne ''?
There was a problem hiding this comment.
@drdrew42 - It sound like something like that is probably causing the problem. Why guess - just test what shows up in the DB field if an old course is upgraded to add the MathQuill field and the user is not manually edited. We certainly want a patch to avoid this happening once WW 2.15 gets released.
There was a problem hiding this comment.
I've checked, db entries are NULL and I cannot replicate the issue described by @nmoller above. I did the following:
git checkout develop_mathquill- un-archived an old course that did not contain the new db column
- upgraded the course via the admin course
- logged into the course as admin and turned on MathQuill
- switched accounts to a professor in same course, loaded a problem page and MathQuill worked
- switched accounts to a student in same course, loaded a problem page and MathQuill worked
SELECT user_id, useMathQuill from upgraded_course_name;shows that all users have NULL value for useMathQuill (and MathQuill behaved as expected with NULL value).
There was a problem hiding this comment.
@nmoller - Could you examine what is in the database table directly.
docker container exec -it webwork2_db_1 bash
mysql -u webworkWrite -p webwork
- the password should get you into the database.
In order to test the functionality of the MathQuill feature:
|
|
@nmoller I've wondered whether the course upgrade took properly. You can check by going to |
|
@drdrew42 : You are right something weird with that updated cours (its user table looks like In the other... it looks fine: @taniwallach I'm used to have a phpmyadmin to go into the db: @mgage You was right ... something weird happens I revisited the upgrade page...and it worked for my test01 course But the other courses reappeared than the upgrade page: Tomorrow I'll follow the script suggested in comment Thanks for your patience. |
|
I'm trying to follow the script kindly given by @drdrew42 ... and when I go to the new course Classlist Editor I get : And what is weirder is that i happens 2 out ~3 times??? |
|
I do not understand what we're seeing here - there is no reason why the db tables should need to be repeatedly upgraded... @nmoller when you're re-upgrading these courses, what does WeBWorK say is in need of updating? |
|
@drdrew42 : I can give you access to my testing env if you want. I've send you the link and user by email.. |
|
@drdrew42 @mgage : Rebuilding the env... and everything worked: I've gone through activate/desactivate as indicated in the script and it works as expected. |
|
I think that the problem is that the Docker builds were using the old master branch, and not everything needed was being mounted from a local directory into Docker. We probably should write up some more detailed instructions on how to test using externally mounted pg and webwork2 against a "standard" Docker image, as it is far easier to get special branches in an external directory than to change the Docker image. |
|
The difference was the pg branch but the build process works fine. Resuming that means... if we are testing a branch of ww2, it would be fine to state which pg branch to use or vice-versa. For a tester does have no idea (as it is my case) the best would be to have the dockerfile set with the right components without having to mount a local version of ww2 or pg. A developer is surely aware of what combination to use. |
The problem is that at the PR stage, there is not always a "standard" branch to test against in the main repository, only in the developer's personal fork, and most such PRs should not be changing the main Instead, maybe we can standardize test procedures based on either:
@xcompass , @mgage, @heiderich - Thoughts on this? |
|
I agree with you Nathan, and here I rejoin Pan opinion that the best way would be to have an "official image" meaning a dockerhub version where to push. And having the dev branches accordingly built and pushed to some tagging system (to be established too). That maybe could be added after Pan comments in PR-972 but as this is turning more into a general discussion ... in my images, I try to follow the advice to log everything to stdout so the command "docker logs -f... " or the centralising process of the orchestrator (mostly pushing it to some kind of ELK stack) works as expected. |












Updated and cleaned version of #920 & #921
MathQuill feature greedily replaces up to 9 answer blanks per problem, offering live TeX rendering of student answer entry. This feature pulls the most recent student entry for each answer blank, parses it into LaTeX through mathJS and then MathQuill renders the result into an editable answer blank.
updates include:
(still waiting on response from MathQuill developers regarding the MathQuill edit handler not reacting as expected when in text-mode... strings still do not quite work correctly - but we're closer than before, even if it doesn't seem that way!)fixedIf anyone is interested, the MathQuill edits are here