search

PreTeXtBook / pretext

PreTeXt: an authoring and publishing system for scholarly documents
https://pretextbook.org
Other
254 stars 202 forks source link

Webwork bad xml #2132

Closed Alex-Jordan closed 2 months ago

Alex-Jordan commented 2 months ago

This fixes a few things. The first commit just moves a certain variable declaration further down. That declaration wants to parse the server's response as XML, but what if we've already established the response is not valid XML? So that line is harmlessly pushed down later past the final place where recognition of bad XML will have already caused the loop to iterate on to the next exercise. Nothing relies on that declaration until further down.

The second commit is that it seems some things changed from 2.16 to 2.17 about what the response looks like when a problem file does not exist, and when the problem failed to compile. Formerly, there was a bit of detail in the response so you could distinguish these situations. But I guess with 2.17, the response is all the same. Not sure why, maybe it is a security reason trying to minimize sending internal details info to the outside world. But I changed how we recognize the failure to compile accordingly.

To test, build the sample chapter (with pretext/pretext/pretext -v, not with the CLI) doing each of the following before and after these commits:

  1. Change the OPL problem to a nonexistent problem (just attach 'foo' to end of problem file name before the .pg).
  2. Break the syntax on a PTX-coded problem, say by removing a semicolon. If you do this on the first exercise from the sample chapter, you will actually break three problems since two later on are copies of the first.

Prior to these commits, either of these things will halt the representations build because of an lxml error. After these commits, you will get messages like PTX:ERROR: WeBWorK problem webwork-add-numbers with seed 6 is either empty or failed to compile.

After this is resolved, I would like to try to modularize the enormous webwork_to_xml def to make this kind of thing easier to prevent in the future.

Alex-Jordan commented 2 months ago

@oscarlevin Once this is resolved and reaches the CLI, it should leave you in a place where you can remove abortEarly=True and get expected behavior.

rbeezer commented 2 months ago

Good! That is a good improvement. Merged and pushed.

Messages get lost in my -v output when there are lots of problems. Can we make them more prominent? We use a border of # above and below for failing to build LaTeX. I tried to add these myself, but got lost in all the types of badness and could not see the easiest way to reliably add them in just one place.