Skip to content

WeBWorK 2.19 support (Tacoma 2024 project) #2336

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

Alex-Jordan
Copy link
Contributor

This is a large PR, just in time for everyone to be going on vacation :)

I'm doing my best to group the contributions from @drgrice1. @drdrew42, and myself from Tacoma. According to my testing, with these changes:

  1. Nothing significantly changes (using the minimal webwork example and the sample-chapter) when you use a WeBWorK 2.17 or 2.18 server, like the AIM webwork-ptx server or the Runestone book support server. It would be good if we work out a way to test that Runestone books aren't broken if this is merged and makes its way to the CLI.
  2. Things work (and work better) when there is a WeBWorK 2.19 server involved. The AIM webwork-dev server is using 2.19.

Once using a 2.19 server, there are new features that I have tested and documented using the minimal webwork example and the sample-chapter.

  • You can use local .pg files in the external folder.
  • You can do the static processing of PG using a local instance of the pg repository. For me in testing today, this took close to 1/4 the time of using the AIM webwork-dev server. You do need to install that pg repo is all.
  • You can do the static processing of PG using an instance of the standalone renderer that is also located on webwork-dev. For me in testing today, this took close to 80% of the time of using the AIM webwork-dev server.

Possibly, we need a schedule for pulling the trigger on this. Here's a draft.

  1. Rob reviews.
  2. Alex amends according to Rob's review
  3. Work with @bnmnetp to check that RS books are not adversely affected.
  4. Rob merges.
  5. Work with @bnmnetp to also check that RS books are not adversely affected if the RS support server moves to version 2.19.
  6. Alex upgrades both the RS support server and AIM's webwork-ptx to version 2.19.

@drgrice1
Copy link
Contributor

Thanks for putting this together for us.

@rbeezer
Copy link
Collaborator

rbeezer commented Dec 26, 2024

I've checked all of this against existing behavior, and will have some comments in a minute.

But, I don't see any reason to not start testing behavior on Runestone now, step (3) of above with @bnmnetp.

@rbeezer
Copy link
Collaborator

rbeezer commented Dec 26, 2024

Thanks, @Alex-Jordan for putting all of this together. Some comments:

  • Are you sure you want to load LaTeX macros into an attribute (@data-macros)? Could they not be accessed from an element? Looks mildly dangerous to me.
  • I think "choice" type problems are losing their \item in the conversion to LaTeX lists. Sample Chapter, Checkpoint 1.6.1 about sqrt(2) being rational or not, is a good first example.
  • Using the makefile to generate problem sets seems to land them someplace much deeper than expected in the output. Might just be a problem with the makefile, I haven't investigated too deep.

Not much, given the quantity of code. Good job. I'm going to familiarize myself with the new features now, so may have more to say. But wanted to get this going in the right direction as quickly as possible.

@rbeezer
Copy link
Collaborator

rbeezer commented Dec 26, 2024

Using the makefile to generate problem sets seems to land them someplace much deeper

OK, I see rendering-data in a file now, I was confused by the diff I was looking at. Scratch that comment.

@rbeezer
Copy link
Collaborator

rbeezer commented Dec 26, 2024

And with AIM's 2.19 server, the \item in the LaTeX conversion are back, so this may just be an issue for backward compatibility.

@rbeezer
Copy link
Collaborator

rbeezer commented Dec 26, 2024

  • Built with AIM dev server in publication file. Problems hang with "Loading" when I click Activate. Firefox and Chrome.
  • Guide has two sections "Using a local copy of PG", which need to be edited/merged?

@rbeezer
Copy link
Collaborator

rbeezer commented Dec 26, 2024

@static-processing="local"

Can't locate Mojo/Base.pm in @INC (you may need to install the Mojo::Base module) (@INC entries checked: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.38.2 /usr/local/share/perl/5.38.2 /usr/lib/x86_64-linux-gnu/perl5/5.38 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.38 /usr/share/perl/5.38 /usr/local/lib/site_perl) at /home/rob/mathbook/mathbook/script/webwork/pg-ptx.pl line 3.
BEGIN failed--compilation aborted at /home/rob/mathbook/mathbook/script/webwork/pg-ptx.pl line 3.

Ideally, an Ubuntu package would provide what I need?

https://packages.ubuntu.com/oracular/libmojolicious-perl

@drgrice1
Copy link
Contributor

Yes, the libmojolicious-perl package provides what is needed. That is the primary down side of the local approach. It does require that the necessary Perl modules be installed.

@rbeezer
Copy link
Collaborator

rbeezer commented Dec 26, 2024

Thanks, @drgrice1! I needed the following Ubuntu packages to get through the sample chapter.

libmojolicious-perl
liblocale-maketext-lexicon-perl
libgd-perl
libdbi-perl
libuuid-tiny-perl
libclass-tiny-perl

@rbeezer
Copy link
Collaborator

rbeezer commented Dec 26, 2024

Built representations throug to the end. Some non-fatal errors. About 6 instances, problem numbers 62-68 (or so), and maybe the very last one. Can't tell what I might be missing.

PTX:INFO    : sending webwork-62 to socket to save in /home/rob/mathbook/mathbook/examples/webwork/sample-chapter/generated/webwork/webwork-representations.xml: origin is 'generated'
errors:
ERRORS from evaluating PG file:
Undefined subroutine &main::latexImagePreamble called at line 7 of 
warnings:
Can't locate macro file |WWSC.pl| via path: |.|,<br/> |[PG]/macros/|,<br/> |[PG]/macros//answers|,<br/> |[PG]/macros//capa|,<br/> |[PG]/macros//contexts|,<br/> |[PG]/macros//core|,<br/> |[PG]/macros//deprecated|,<br/> |[PG]/macros//graph|,<br/> |[PG]/macros//math|,<br/> |[PG]/macros//misc|,<br/> |[PG]/macros//parsers|,<br/> |[PG]/macros//ui|
PTX:ERROR: WeBWorK problem generated/webwork/pg/Integrating_WeBWorK_into_Textbooks/1_8_1-A_static_lateximage_graph.pg with seed 62 is either empty or failed to compile  
  Use -a to halt with full PG and returned content

@Alex-Jordan
Copy link
Contributor Author

Thanks Rob! Some quick responses and I may do more this evening.

Are you sure you want to load LaTeX macros into an attribute (@data-macros)? Could they not be accessed from an element? Looks mildly dangerous to me.

What's going on here is the PTX HTML page has a div with id latex-macros. The contents of that div will be the LaTeX macros, but wrapped in \(...\). Now, later the webwork js needs to get the latex macros to write them into the srcdoc for an iframe where the WW problem will render. So how will it get them? I have it accessing them from where they are stored redundantly as a data attribute on the div#latex-macros (without the \(...\)). It's been a while, but I think I felt uneasy with having it access them from the content of the div#latex-macros. Particularly because the \(...\) would already be present. Possibly it could change to access them from the content and remove the redundant data attribute. If there is a future need to add macros at this stage, either I'd have to peel off the \(...\) or revert to how it is now.

I think "choice" type problems are losing their \item in the conversion to LaTeX lists. Sample Chapter, Checkpoint 1.6.1 about sqrt(2) being rational or not, is a good first example. And with AIM's 2.19 server, the \item in the LaTeX conversion are back, so this may just be an issue for backward compatibility.

OK, I will follow up with this.

Using the makefile to generate problem sets seems to land them someplace much deeper than expected in the output. Might just be a problem with the makefile, I haven't investigated too deep.

I neglected to test with the makefile but I'll do that to make sure things are still working. I was testing by running pretext/pretext/pretext directly. But actually this sounds like an expected change (that I forgot to mention in all the mix of things). Prior to this PR, when you make an archive of PG files, that gets made wherever you happen to be. Or possibly you can specify a -d or a -o. But now it all gets placed in an appropriate subfolder of the generated folder. I think this is a good change.

Built with AIM dev server in publication file. Problems hang with "Loading" when I click Activate. Firefox and Chrome.

Are you viewing with file://? Same thing happened to me if I didn't view through an actual web server.

Guide has two sections "Using a local copy of PG", which need to be edited/merged?

Sounds like an oversight. Will follow up.

Ideally, an Ubuntu package would provide what I need?

I'll add to the documentation as best I can about what packages are needed. Or maybe a generic "you may need to install some perl packages". With Ubuntu packages, using cpanm, and more variants, I'm not sure about getting too specific.

Undefined subroutine &main::latexImagePreamble

This indicates a host course doesn't have the access it needs to the .pl file for WWSC. I'll look into it.

@drgrice1
Copy link
Contributor

Undefined subroutine &main::latexImagePreamble

This indicates a host course doesn't have the access it needs to the .pl file for WWSC. I'll look into it.

I think that this was when @rbeezer was testing the local approach based on the output line "sending webwork-62 to socket". The local approach adds the macros directory in the generated directory to the macro path. So the macro should be available. Although, I also don't see that path in the output that @rbeezer showed.

@Alex-Jordan
Copy link
Contributor Author

I think "choice" type problems are losing their \item

Looking over the diff, I think this is from -assembly where I replaced var[@form] with ul, ol, dl as appropriate. I think if I bring back support for var[@form] as equivalent to ul[@form], that will address the backwards compatibility.

@Alex-Jordan
Copy link
Contributor Author

I think "choice" type problems are losing their \item

OK, this one is addressed. I added a commit (rather than force push) but it can be squashed later as it indicates.

@Alex-Jordan
Copy link
Contributor Author

Guide has two sections "Using a local copy of PG", which need to be edited/merged?

Copy-paste oversight. The second one should have had its title changed to be about using a renderer.

@Alex-Jordan
Copy link
Contributor Author

@drgrice1 Do you have a recommendation about what I should put in the documentation about which perl version (or later) is required for local PG processing?

@drgrice1
Copy link
Contributor

I am not exactly sure how old of a Perl version will work for local PG processing. I know that Perl 5.16 or newer is certainly needed. I suspect that versions that old will have problems though. I think that 5.26 is probably the oldest that we should try to support, and so I guess put that in the documentation. Although you would need 5.32 or newer for a version that I can truly guarantee everything will work for.

@Alex-Jordan
Copy link
Contributor Author

I just pushed an additional commit with some guidance for the perl version and packages. I think what remains is:

  • the @data-macros comments...does anything need to change?
  • problems hanging in the live rendering (was the page being viewed from file://?)
  • what was going on with Undefined subroutine &main::latexImagePreamble? Maybe need to meet live at a drop-in to look into that?
  • testing a Runestone build won't break. Will follow up on an email thread with @bnmnetp and @rbeezer

@rbeezer
Copy link
Collaborator

rbeezer commented Jan 1, 2025

Publication file: webwork/@static-processing="local"

Use the Sample Chapter stanza for sample-chapter-macros target.

Now have fresh (within PTX distribution):

./examples/webwork/generated/webwork/pg/Integrating_WeBWorK_into_Textbooks/macros/WWSC.pl

but when doing sample-chapter-representations I still get

PTX:INFO    : sending webwork-62 to socket to save in /home/rob/mathbook/mathbook/examples/webwork/sample-chapter/generated/webwork/webwork-representations.xml: origin is 'generated'
errors:
ERRORS from evaluating PG file:
Undefined subroutine &main::latexImagePreamble called at line 7 of 
warnings:
Can't locate macro file |WWSC.pl| via path: |.|,<br/> |[PG]/macros/|,<br/> |[PG]/macros//answers|,<br/> |[PG]/macros//capa|,<br/> |[PG]/macros//contexts|,<br/> |[PG]/macros//core|,<br/> |[PG]/macros//deprecated|,<br/> |[PG]/macros//graph|,<br/> |[PG]/macros//math|,<br/> |[PG]/macros//misc|,<br/> |[PG]/macros//parsers|,<br/> |[PG]/macros//ui|
PTX:ERROR: WeBWorK problem generated/webwork/pg/Integrating_WeBWorK_into_Textbooks/1_8_1-A_static_lateximage_graph.pg with seed 62 is either empty or failed to compile  
  Use -a to halt with full PG and returned content

Is that book-title directory in the way? I'm not 100% sure what I'm debugging here exactly. And other PreTeXt projects (that other people are hanging fire on) are going to keep me busy.

@rbeezer
Copy link
Collaborator

rbeezer commented Jan 1, 2025

I may merge #2341 in a bit. Which will require a rebase here. (And perhaps you can fix in (not squash) the newer commits along the way?)

@Alex-Jordan
Copy link
Contributor Author

OK, as suspected, I was not hitting that error because at some previous time I had manually placed the needed macro file in an OK place. But it's working now with my testing. And while fixing this up, I noticed parallel issues with making a problem set archive and fixed those too.

Summary:

  • When you use pretext-ww-problem-sets.xsl or pretext-pg-macros.xsl directly (which we don't do), it's always going to create a folder named like Integrating_WeBWorK_into_Textbooks in the working directory. This will have subfolders with problems, def files, header files, and macros if we used pretext-ww-problem-sets.xsl. If we only used pretext-pg-macros.xsl, it will only have like Integrating_WeBWorK_into_Textbooks/macros/WWSC.pl.
  • When you invoke these via pretext/pretext/pretext (or indirectly with the Makefile), if there is no generated folder, then the "destination directory" takes the place of the working directory.
  • When you invoke these via pretext/pretext/pretext, if there is a generated folder, then the "destination directory" will effectively be generated/webwork/pg.

So for example if you run make sample-chapter-macros, then look in sample-chapter/generated/webwork/pg/Integrating_WeBWorK_into_Textbooks/macros/ to see the .pl file. And if you are then building representations locally, you don't need to do anything; it knows to look there for the macros.

Lastly, say you clear out your generated folder, and then run make sample-chapter-representations with local processing. Actually one of the first things the corresponding python routine does is make the macros. So that's enough; no need to make the macros first. It's only when the processing will be done by a webwork2 server that we need to build macros ahead of time and manually place them in the webwork2 server.

@Alex-Jordan
Copy link
Contributor Author

We tested at RSA and for a while we had some issues with multiple choice questions. But we've ironed that all out. So I think this is ready unless there is more PTX-side testing to do. After this is merged, my next step would be to upgrade the AIM WW server (the production one) to version 2.19. Of course, with advanced warning posted on -announce. (We don't expect bad consequences, but it's always possible.)

Eventually the changes here would make it into the CLI. Then we could upgrade the RSA WW server to 2.19, but I think it is less stressful to wait and do that in June.

The commits here are still separated in case it helps to only put eyes on new changes since whenever the last review was. Let me know if you would prefer I (a) squash all related commits [for example, all that are about the js] or (b) squash it all into one big commit. Ideally we somehow still assign credit (and blame) to me, Drew, and Glenn though. git wants one single email address for each commit, even when it is muddy which bits were mine, which were Drew's, and which were Glenn's. So I mostly used my email address for these commits, and therefore GH wants to say these commits are mine. But where it matters, I put multiple names (like "Jordan, Parker, Rice") as the commit author's name. One option is to squash down to three: one all me, one that is all Glenn, and one that is "Jordan, Parker, Rice".

@Alex-Jordan
Copy link
Contributor Author

Oh, I also rebased from master since there was a small conflict.

@rbeezer
Copy link
Collaborator

rbeezer commented Jan 17, 2025

Thanks - I'll try to address this one in about a week. If there is no change for status quo (as is the intent) then I'm inclined to merge this with new features being subject to change after used in the wild. If you haven't already, you might prepare a blurb for -announce. Thanks.

@Alex-Jordan
Copy link
Contributor Author

I force pushed a small change regarding the recent thread on -dev about showPartialCorrectAnswers. It was only a relatively small change to pretext-webwork.js and only makes a difference on problems where showPartialCorrectAnswers = 0.

@Alex-Jordan
Copy link
Contributor Author

I opened 4 PRs that peel off things you mentioned, plus something I else I noticed could be easily separated. Once those are reviewed and merged I will rebase here and see where that leaves us.

Answers 1,2,3,5 are empty

I've run out of time to investigate today. But I do find that on this branch, the WW server is returning those answers as empty. So it's not about LaTeX specifically. Also the constructed PG file is the same on master and this branch, so it's nothing with how PG is being constructed. So current guess is something in pretext.py is doing something unwanted with these special characters.

@rbeezer
Copy link
Collaborator

rbeezer commented Apr 11, 2025

I opened 4 PRs that peel off things you mentioned

Thanks! I'll try to get to them very soon, but today is packed.

But I do find that on this branch, the WW server is returning those answers as empty.

Great - thanks for tracking that down. I just had not been able to get to that exercise.

@Alex-Jordan Alex-Jordan force-pushed the ww-219 branch 2 times, most recently from 3a1d2ad to 7c110b7 Compare April 11, 2025 20:08
@Alex-Jordan
Copy link
Contributor Author

You are probably getting alerts, but I'm rebasing as those other PRs get merged. (Sitting in a Zoom meeting now, being a bit bad by letting my attention wander...)

@rbeezer
Copy link
Collaborator

rbeezer commented Apr 12, 2025

Two recent small PRs I merged worked great. Thanks. Will address the two others soon.

I've rebased this branch here locally. That worked great, too. Just so that I can see what's remaining easily, not something I intend to put out there publicly.

Other ideas: PG list indent? PG side-by-side, with sample chapter examples if necessary?

Looks like LaTeX macros is a 2.19 thing? Can't recall if I said. I'm not wild about the extra hidden "p" with duplication of the macros. The current device will always have a \(...\) wrapper (and if it changes we will hear bout it!). So if the Javascript needs it, I'd prefer that it just strip the first and last two characters from each end.

Can the 2.17 change go in now without any adverse consequences? I could do it under your name (or somebody else) if it is easier.

@Alex-Jordan
Copy link
Contributor Author

sidebyside stuff will only work with 2.19. (And no examples in the sample chapter, at least not here in this PR.) Should I peel it off like other things and it's just moot for now?

Can the 2.17 change

Do you just mean the change to js/pretext-webwork/2.17/pretext-webwork.js? That can go in any time. It is only there to preserve backward compatibility once pretext is basically set up to talk to a 2.19 server, but in case it's actually 2.17. The key for a certain password changed in webwork2 versions, and I changed the key name on the pretext side too to avoid confusion.

@rbeezer
Copy link
Collaborator

rbeezer commented Apr 12, 2025

OK, then I think we can just pay no attention to the side-by-side stuff for the moment. Maybe on its own commit at some point when you are rearranging, but definitely with examples in the sample chapter.

Thanks for explaing the 2.17 change. I'll pick htat up as a new commit when I get to the other two.

@rbeezer
Copy link
Collaborator

rbeezer commented Apr 13, 2025

the 2.17 change. I'll pick htat up as a new commit when I get to the other two.

Done at 4bdff41

@Alex-Jordan Alex-Jordan force-pushed the ww-219 branch 2 times, most recently from c75dec8 to 0eef9b6 Compare April 15, 2025 00:19
@Alex-Jordan
Copy link
Contributor Author

A timing note about one of the main new features here. I am editing ORCCA, currently with parts I and II (out of three) uncommented. Using the PCC webwork2 server for PG processing, it takes 32 minutes. Using local PG processing takes 20 minutes.

@rbeezer
Copy link
Collaborator

rbeezer commented Apr 17, 2025

LaTeX: special characters are still going missing, as reported above. That needs to be tracked down before any 2.19 changes.

HTML: it is impossible to do any careful testing if the chunking level changes. It took me a long time to find it, over in the publication file. (Not in the Makefile like for the problem sets.) This is a big delay that could have been avoided.

Macros: please remove the duplication in the p and just strip the delimiters off the existing version. It'd be nice if all the PG changes for the macros were isolated on a later commit that could be temporarily avoided during testing.

@Alex-Jordan
Copy link
Contributor Author

Will it help with whittling this down if I opened a PR now that applies debug.datedfiles no everywhere in the Makefile? I'm thinking to make the diffs smaller as this iterates. But then second guessing myself, if there is a reason to keep those timestamps in place.

@Alex-Jordan Alex-Jordan marked this pull request as draft May 20, 2025 18:26
@Alex-Jordan
Copy link
Contributor Author

I wanted to push incomplete edits off from my local computer, and converted this to draft status. This needs #2462 (which needs #2505) and then this can be continued.

@rbeezer
Copy link
Collaborator

rbeezer commented May 30, 2025

With current commits, I get:

~/mathbook/mathbook/examples/webwork$ make sample-chapter-representations 

<snip>

PTX:INFO    : successful application of /home/rob/mathbook/mathbook/xsl/support/pretext-pg-macros.xsl
Traceback (most recent call last):
  File "/home/rob/mathbook/mathbook/pretext/pretext", line 879, in <module>
    main()
  File "/home/rob/mathbook/mathbook/pretext/pretext", line 685, in main
    ptx.webwork_to_xml(
  File "/home/rob/mathbook/mathbook/pretext/lib/pretext.py", line 1289, in webwork_to_xml
    "courseID": extracted_pg_xml.find("server-params-pub").find("course-id").text,
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'text'
make: *** [Makefile:129: sample-chapter-representations] Error 1

@Alex-Jordan
Copy link
Contributor Author

Alex-Jordan commented May 31, 2025 via email

@rbeezer
Copy link
Collaborator

rbeezer commented May 31, 2025

I marked this as draft

I looked for that and did not see it. Now I do. GH does not make it particularly obvious... Sorry for the noise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants