PreTeXtBook
WeBWorK: refresh cached images only when downloading iamge files
If you write a WW exercise (using PTX source) and it generates an image, under what conditions do we tell the WW server to generate the image from scratch, as opposed to relying on some cached image from a previous run?
In general we don't want to refresh cached images. It slows things down and may be responsible for some recent issues on the utmost server with pdflatex processes that never terminated.
But if you never refresh, the risk is that the first time your tikz code was bad or something, and now you can't get a new version of the image.
I think the right decision is:
- For human readable, do not refresh cached images
- For the embedded live problems, do not refresh cached images
- Only when downloading images when gathering the static representation, refresh.
This PR does that. But in extract-pg.xsl we only distinguish between human readable and not human readable, which is both of the latter two bullets. So this commit does some surgery in pretext.py on the non-human-readable version that will be used in embedded problems.
Caveat: if an author directly writes $refreshCachedImages=1; into their pg-code, we do not alter that for human readable. But we still cut it out from the live embedded problem code.
One small conflict when I rebase, inside xsl/extract-pg.xsl, likely due to #1787.
I could guess, but would rather not. ;-)
Can you rebase, adjust, and force-push here? Thanks.
I fixed it here in GitHub. Is that OK?
Both versions were equivalent. Look for presence of a latex-image. Look for presence of an image containing a latex-image. I took the one that keeps code symmetry with something else in the vicinity.
Alex - please rebase your work here on the current tip. I don't want to be handcuffed by merge commits like this one.
I fixed it here in GitHub. Is that OK?
Only saw this now. (Looked at the merge commit first.) Generally I don't like the way GitHub tries to make life simpler. ;-)
We can walk through a rebase with conflicts on Friday, if you'd like. In that case keep your original branch intact locally.
Sorry, I missed the Oct 28 message. Merged just now.
Where is this tested? I don't see it anywhere in the samle chapter.
And I can't test anything about this myself, since I have a pip problem with Python setup...
Where is this tested?
If you go to the HTML sample article right now (before you regenerate following this PR) then here is base 64 for Exercise 9.1: A static
RE9DVU1FTlQoKTsKbG9hZE1hY3JvcygiUEdzdGFuZGFyZC5wbCIsIk1hdGhPYmplY3RzLnBsIiwiUEdNTC5wbCIsIkFuc3dlckZvcm1hdEhlbHAucGwiLCJQR2xhdGV4aW1hZ2UucGwiLCJQQ0NtYWNyb3MucGwiLCJwYXJzZXJPbmVPZi5wbCIsImNvbnRleHRJbnRlZ2VyRnVuY3Rpb25zLnBsIiwiV1dTQy5wbCIsIlBHY291cnNlLnBsIiwpOyRyZWZyZXNoQ2FjaGVkSW1hZ2VzPTE7VEVYVChiZWdpbnByb2JsZW0oKSk7CkNvbnRleHQoIkludGVnZXJGdW5jdGlvbnMiKTsKQ29udGV4dCgpLT52YXJpYWJsZXMtPmFyZShuPT4nUmVhbCcpOwokYW5zd2VyID0gT25lT2YoRm9ybXVsYSgiQyhuKzEsMikiKSxGb3JtdWxhKCIobisxKW4vMiIpKTsKJGltYWdlXzEgPSBjcmVhdGVMYVRlWEltYWdlKCk7CiRpbWFnZV8xLT5hZGRUb1ByZWFtYmxlKGxhdGV4SW1hZ2VQcmVhbWJsZSgpKTsKJGltYWdlXzEtPkJFR0lOX0xBVEVYX0lNQUdFClxiZWdpbnt0aWt6cGljdHVyZX0KICAgIFxkcmF3W2Rhc2hlZF0gKDAuNS0wLjUqNi41LC0wLjg2NjAyNSo2LjUpIC0tICg3LTAuNSo2LjUsLTAuODY2MDI1KjYuNSk7CiAgICBcZHJhd1t2ZXJ5IHRoaWNrXSAoMi0wLjUqNywtMC44NjYwMjUqNykgLS0gKDItMC41KjQsLTAuODY2MDI1KjQpIC0tICg1LTAuNSo3LC0wLjg2NjAyNSo3KTsKICAgIFxmb3JlYWNoIFx4IGluIHsxLC4uLiw2fQogICAgICAgIFxmb3JlYWNoIFx5IGluIHsxLC4uLixceH0KICAgICAgICAgICAgXHNoYWRlW2JhbGwgY29sb3I9Ymx1ZSEzMF0gKFx5LTAuNSpceCwtMC44NjYwMjUqXHgpIGNpcmNsZSAoMC4yY20pOwogICAgXGZvcmVhY2ggXHkgaW4gezEsLi4uLDd9CiAgICAgICAgXHNoYWRlW2JhbGwgY29sb3I9b3JhbmdlITQwXSAoXHktMC41KjcsLTAuODY2MDI1KjcpIGNpcmNsZSAoMC4yY20pOwogICAgXG5vZGUgYXQgKDIuNSwtMC41KSBbYW5jaG9yPW5vcnRoIHdlc3Rde1woXGNvbG9ye2JsdWV9XHN1bVxsaW1pdHNfe2s9MX1ebmtcY29sb3J7YmxhY2t9XCl9OwogICAgXHNoYWRlW2JhbGwgY29sb3I9Ymx1ZV0gKDItMC41KjQsLTAuODY2MDI1KjQpIGNpcmNsZSAoMC4yY20pOwogICAgXHNoYWRlW2JhbGwgY29sb3I9b3JhbmdlXSAoMi0wLjUqNywtMC44NjYwMjUqNykgY2lyY2xlICgwLjJjbSk7CiAgICBcc2hhZGVbYmFsbCBjb2xvcj1vcmFuZ2VdICg1LTAuNSo3LC0wLjg2NjAyNSo3KSBjaXJjbGUgKDAuMmNtKTsKXGVuZHt0aWt6cGljdHVyZX0KCkVORF9MQVRFWF9JTUFHRQoKQkVHSU5fUEdNTApUaGlzIGltYWdlIGlzIGEgdmlzdWFsIHByb29mIHRoYXQgW2Bcc3VtX3trPTF9XntufWtgXSBlcXVhbHMgd2hhdD8KCj4+IFtAaW1hZ2UoaW5zZXJ0R3JhcGgoJGltYWdlXzEpLCB3aWR0aD0+MzAwLCBhbHQ9PnFxIjIxIGJsdWUgYmFsbHMgYXJlIGFycmFuZ2VkIGluIGEgdHJpYW5ndWxhciBmb3JtYXRpb24sIHdpdGggb25lIGF0IHRoZSB0b3AsIHRoZW4gYSByb3cgb2YgdHdvLCBhIHJvdyBvZiB0aHJlZSwgYW5kIHNvIG9uIHVudGlsIGEgcm93IG9mIHNpeDsgdGhlcmUgaXMgYSBzZXZlbnRoIHJvdyB3aXRoIHNldmVuIG9yYW5nZSBiYWxsczsgb25lIGJsdWUgYmFsbCBpcyBoaWdobGlnaHRlZCwgYW5kIHR3byBsaW5lcyBleHRlbmQgZG93bndhcmQgZnJvbSB0aGF0IGJhbGwsIG9uZSB0byB0aGUgbGVmdCBhbmQgb25lIHRvIHRoZSByaWdodCwgcGFyYWxsZWwgdG8gdGhlIHNpZGVzIG9mIHRoZSB0cmlhbmdsZSwgdW50aWwgdGhleSBpbnRlcnNlY3QgdHdvIG9yYW5nZSBiYWxsczsgdGhlIGVmZmVjdCBpcyB0aGF0IGVhY2ggb2YgdGhlIDFcKzJcKzNcKzRcKzVcKzYgYmx1ZSBiYWxscyBjb3JyZXNwb25kcyB0byBvbmUgcGFpciBmcm9tIHRoZSA3IG9yYW5nZSBiYWxscyIpQF0qICA8PAoKW0BLZXlib2FyZEluc3RydWN0aW9ucygnWW91IG1heSBlbnRlciB0aGUgYW5zd2VyIHVzaW5nIFt8QyhuLGspfF0qIG5vdGF0aW9uLicpQF0qKgoKW19deyRhbnN3ZXJ9ezIwfQoKCkVORF9QR01MCgpFTkRET0NVTUVOVCgpOw==
Decode that at https://www.base64decode.org/ and you can see $refreshCachedImages=1; among the commands near the top.
Following this merge, we can peek at the same base64 encoding for that exercise, and I expect it will be $refreshCachedImagesInert=1;.
It would be more natural to have not automatically inserted the $refreshCachedImages=1; in the first place unless we are setting out to download images. But this approach also deals with the situations where the author unfortunately wrote $refreshCachedImages=1;.
and I expect it will be $refreshCachedImagesInert=1;
Bingo! Thanks.
Tested locally, just as you say. Will update website sometime today, I expect.
(Feel free to ping me after about a week, if you think I've missed something with no excuse. There's a few things here that are paused, so I lose track.)