Skip to content
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

When a set def file numbers a problem as 0 #2255

Open
Alex-Jordan opened this issue Nov 16, 2023 · 2 comments
Open

When a set def file numbers a problem as 0 #2255

Alex-Jordan opened this issue Nov 16, 2023 · 2 comments

Comments

@Alex-Jordan
Copy link
Contributor

This is discussed at #2194 (comment), but I'm moving it to an issue. The issue is about what can happen if a set def file uses 0 as a problem id.

Some discussion on that thread is about how to salvage the situation and what new number to use for the problem numbered 0. But I suggest that if the set def file has a bad problem id anywhere, the whole thing should halt and no problem set should be created. With an informative error message about what is wrong with the set def file.

The cases of a set definition containing any invalid problem id comes from someone editing a set definition file by hand.

Possibly from other places too though. PreTeXt automatically creates set def files for all the WW exercises from a section of a book. I don't think it can create invalid problem numbers, but my point is that some automatic creation of set def files can come from external sources. PTX is one example (possibly the only one but who knows).

My suggestion would be to just edit lines 2414-2419 of DB.pm. The regex pattern could change to disallow a leading 0. And the message could be rephrased. If there is an existing set def file out in the world that uses 0 for a problem, it will now fail to import but....good?

@drgrice1
Copy link
Member

Doesn't #2254 fix this? It doesn't give a warning but fixes the numbering as it was intended to do. So this issue is really a feature request asking for a warning?

@drgrice1
Copy link
Member

Note that #2254 fixes the numbering as it was intended, but the previous code did something silly that made it not work. It was trying to get problem ids from the database for the set that was just created which of course would not have any problems yet. #2254 gets valid problem ids from the set definition file, and then does what the previous code did and adds the invalid problem numbers at the end.

I don't think that halting as you say is a good idea. We could add a warning when an invalid problem id is encountered, but halting is to much. Note that 0 is not the only invalid problem id that can be encountered, and that this is all prior to the anything that will be seen by code in DB.pm.

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

No branches or pull requests

2 participants