WeBWork files with dates

9 views
Skip to first unread message

Rob Beezer

unread,
May 22, 2026, 3:44:12 PM (9 days ago) May 22
to prete...@googlegroups.com
Definitely for Alex, perhpaps useful to to others.

WW sample chapter now has @label on every WW exercise, so every per-exercise
representation file has a stable filename. So I have committed these to the
PreTeXt repository. Only they all have banners with the date the file was
written, which I know annoys Alex and now really annoys me when dealing with
nonsensical diffs. So the dates are gone, too.

I know we are generating the "problem sets" for use with things like the HTML
builds. That will include *.def files, which have things like starting dates
for problem sets. Which is now making a mess in diffs as well. Do we really
need those *.def files?

Once this is in order, I may replicate everything for the minimal WW example.

Rob

Alex Jordan

unread,
May 22, 2026, 5:06:21 PM (8 days ago) May 22
to prete...@googlegroups.com
There is one function in the python that builds both the .def files and the .pg files at the same time. It used to be that the only purpose of the .pg files was for packaging with the .def files, so making the two things at the same time made sense.

Now the .pg files are needed for more. They are built very early in the processing of source files. And when the script requests rendering to static PTX, these .pg files are the "source" for whatever is doing that rendering. So we always need to make these .pg files. Currently, the .def files just always come along for the ride since we are using the same function.

Yes, we could separate these things (.pg and .def production). But it's not something I would float to the top of my to-do too soon. 

Here is something you could consider doing. In pretext-ww-problem-sets.xsl, there are blocks that set these three dates:
openDate
dueDate
answerDate

I think it's not helpful that currently, these dates are set based on the date you are processing your project. Surely if someone needs to use the .def file, they will have to change those dates after they import the set.

An option: Just remove those date setting blocks from the .def file. The set can still be imported, and the user will see warning messages that no dates were in place. The import will still happen, using WeBWorK's own default date setting scheme.

Another option: Set those dates to be fixed. Like opening on Jan 1, 2026, closing on Jan 1, 2036. Or something like that. Note that alll but the most recent versions of WW require no more than 10 years in between open date and due date.

You could do either of these and the date diff annoyance would go away. And I don't think anyone would complain.


--
You received this message because you are subscribed to the Google Groups "PreTeXt development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pretext-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pretext-dev/MTAwMDAzMi5iZWV6ZXI.1779479050%40pnsh.

Rob Beezer

unread,
May 23, 2026, 9:09:47 PM (7 days ago) May 23
to prete...@googlegroups.com
Thanks, Alex. I was thinking of parameterizing said function, but I like the idea of fixed, generic dates better. Might make actual edits easier, especially for a patient, accurate assistant. (I'll make the change.)

Rob

Rob Beezer

unread,
May 24, 2026, 9:49:43 PM (6 days ago) May 24
to prete...@googlegroups.com
Now we have (obviously) generic dates in the *.def files - who would open an
assignment on New Year's Day and close it on New Year's Eve? And no dates in the
PreTeXt blurbs at the top of each file, so these should be behaving as residents
of the repository. Can't say the same for the generated images, but that is
true all over.

Rob
Reply all
Reply to author
Forward
0 new messages