Resolve issues #1215

[xexyl]

Now the version checks for chkentry(1) are a >= check. Uses code from jparse/verge.c. Its main() was moved to verge_main.c and verge.c now has a new function vercmp(). 'verge.o' is linked into the library and chkentry now uses it. Also there are new arrays that we called 'poisoned versions' and this allows for bad versions to be excluded. Each tool and some other versions have a minimum version allowed which at this time is equivalent to the current release. If a version is incremented then the minimum version would be changed to be the version at the time the contest opens. In this way uploaded submissions will not be invalidated. As for poisoned versions the lists are currently empty (just NULL terminated - must be last element).

Updated gen_test_JSON.sh (under test_ioccc/) to have a new function - getversion. This was necessary so we can use grep -v MIN. If it was in the same function it would cause another MIN_ macro to be excluded from limit_ioccc.h which was a problem. Updated the script's version to "1.0.2 2025-03-07".

[xexyl]

The testing procedure is described in the versions issue @lcn2. As long as the workflow works out okay I'll be doing other things for the day. If all is good though we can discuss the other enhancements that I had done but had to undo temporarily.

[lcn2]

It may be a day or so before we can get back to testing this patch. Sorry (tm Canada 🇨🇦) for the delay.

Your PR is very important and deserves careful consideration, @xexyl

[xexyl]

It may be a day or so before we can get back to testing this patch. Sorry (tm Canada 🇨🇦) for the delay.

Actually in this case it's convenient. It gives me time to work on other things. The changes (other fixes and enhancements) I have locally and on backup too so it's not like there's any chance of losing it (well okay - if something catastrophic happened but that's another matter entirely).

This (other things to do) includes things unrelated to the IOCCC too - today I plan on baking courgette (or if you prefer zucchini) bread; dinner will be salmon and mash (or if you prefer mashed potato or mashed potatoes).

I also like the idea of the tools searching the $PATH but as that's another issue entirely I'll save that comment for over there.

Your PR is very important and deserves careful consideration, @xexyl

Thanks.

[xexyl]

I just realised something unfortunate.

I have to rollback the update to forbidden directories: otherwise it could invalidate submissions that might already have those directories.

Although it's probably unlikely due to file limits.

Still I will roll that part back and it can be done next contest. Unless I am remembering wrong and the test functions don't invalidate files. Pretty sure I even put it directly in chkentry though.

[lcn2]

I just realised something unfortunate.

I have to rollback the update to forbidden directories: otherwise it could invalidate submissions that might already have those directories.

Although it's probably unlikely due to file limits.

Still I will roll that part back and it can be done next contest. Unless I am remembering wrong and the test functions don't invalidate files. Pretty sure I even put it directly in chkentry though.

As we just commented to issue #1207

While we are not opposed to issue #1207, ignoring SCCS or RCS is hardly a reason for an emergency fix while IOCCC28 is open.

Moreover, what IF there a submission to IOCCC28 already that is an obfuscated rcs tool? How would such a submitter update such a submission if mkiocccentry(1) were to suddenly change out from under them if, as part of their submission, they had a RCS directory?

While issue #1207 should NOT be added to the mkiocccenty tool set whole IOCCC28 is open. Issue #1207 should be added before IOCCC29 opens, along with suitable changes to the guidelines AND FAQs about what is ignored by mkiocccenry(1).

Request

While we are not opposed to issue #1207, we are NOT convinced that it raises to the level of a need for an emergency fix while IOCCC28 is open.

Modifying the mkiocccetry tool set while the IOCCC is open both comes with GREAT PERIL.

The need for you to issue commit efa34a03e86c3a1392599bda2b58be78d100e2a5 shows how adding what seems to be a simple change lead to problems. Prior that commit, we were considering asking you to reissue the PR.

Even though you have modified this PR, the title and history of the PR remains.

PLEASE withdraw this PR and reissue just a PR for issue #1215. Sorry to have to make this request, but we feel it is important to do so.

We will be happy to review a new PR that addresses only issue #1215.

Thank you for your patience in this important matter.

[xexyl]

See GH-issuecomment-2708383978).

I already rolled it back. See commit efa34a03e86c3a1392599bda2b58be78d100e2a5.

So there's nothing to fix.

[lcn2]

See GH-issuecomment-2708383978).

I already rolled it back. See commit efa34a0.

So there's nothing to fix.

The PR title, the lead comment message mention issue #1207.

Can those be amended, @xexyl ? If so, please do so. If not, please re-issue.

We will continue to test as you advise.

UPDATE 0

Moreover the commit message for 33150d59d414a3a4cef30d6c660e1e3947c34bb8 mentions issue #1207. Can that commit message be amended to issue #1207?

[xexyl]

See GH-issuecomment-2708383978).

I already rolled it back. See commit efa34a0. So there's nothing to fix.

The PR title, the lead comment message mention issue #1207.

Can those be amended, @xexyl ? If so, please do so. If not, please re-issue.

We will continue to test as you advise.

Updated both.

[xexyl]

See GH-issuecomment-2708383978).

I already rolled it back. See commit efa34a0. So there's nothing to fix.

The PR title, the lead comment message mention issue #1207.

Can those be amended, @xexyl ? If so, please do so. If not, please re-issue.

We will continue to test as you advise.

UPDATE 0

Moreover the commit message for 33150d5 mentions issue #1207. Can that commit message be amended to issue #1207?

As for as amending - not to my knowledge, not after it being pushed. But the CHANGES.md and the changelog in commits state it was rolled back.

[lcn2]

Sorry to bother, but the CHANGES.md file change for this PR should NOT include the "Release 2.4.4 2025-03-08" section as that is not going to be released.

As there is no release that is being rolled back, the CHANGES.md file should NOT mention issue #1207.

We can edit your PR to do this, but we think, @xexyl that you will find it easier ir you do that with a 3rd commit to this PR.

[xexyl]

Done.

[lcn2]

Sorry (tm Canada 🇨🇦) to have to be be so careful.

[xexyl]

Sorry (tm Canada 🇨🇦) to have to be be so careful.

It's okay. I was in a rush. I will be able to address the issue in a little longer.

[xexyl]

And yes I certainly want to fix that typo.

I was just starting to stand up when I quickly did that.

As far as the macros go that's a fair point. I decided to keep them in for later but strictly speaking they are not really necessary and it's only two lines so it's not a big deal.

I hope to be able to complete this soonish.

[xexyl]

Lastly for now: thanks for quoting the top of the changes file. As you know my eyes are immediately drawn to typos and similar things and although it probably wouldn't bother most people nearly as much as me you're right that it would really annoy me even though I was in a rush.

So thank you! I will be able to commit in a little bit.

[xexyl]

👍 and thank you @xexyl for your patience on this matter

We will commit this too the master branch and perform more testing. This will also allow other potential urgent PRs to now be considered.

Good call on your merge commit message.

We will hold off on format release of the repo for now.

Good idea.

REQUEST

If we do add more PRs before the formal release of 2.4.3 of this repo is made, then please just amend and/or append to the "Release 2.4.3" section of CHANGES.md instead of creating a new "Release 2.4.4" section.

Sure - that's not a problem.

As for more pull requests: do you wish me to take care of the other issues that have fixes? They are:

• the -u uuid option (minimal change, not required)
• clarify and improve prompting for files/directories that mkiocccentry will ignore
• it now prevents people from having a topdir in workdir and vice versa (oops - I did not think of that but I should have!)

I just thought of an issue - something that the new version system cannot take care of. It's not really an issue but it should be noted. I'll do it over there.

[lcn2]

As for more pull requests: do you wish me to take care of the other issues that have fixes? They are:

• the -u uuid option (minimal change, not required)

As this is NOT required while IOCCC28 is open, it should be a POST-IOCCC28 issue

• clarify and improve prompting for files/directories that mkiocccentry will ignore

By this you mean in the FAQ and/or guidelines of "the other repo"? Yes, please.

• it now prevents people from having a topdir in workdir and vice versa (oops - I did not think of that but I should have!)

Do we need to require that for IOCCC28? Perhaps so.

[xexyl]

As for more pull requests: do you wish me to take care of the other issues that have fixes? They are:

• the -u uuid option (minimal change, not required)

As this is NOT required while IOCCC28 is open, it should be a POST-IOCCC28 issue

Sure but the changes are already there with others. So I am not sure what to do about that - I won't commit then until you give me your ideas.

• clarify and improve prompting for files/directories that mkiocccentry will ignore

By this you mean in the FAQ and/or guidelines of "the other repo"? Yes, please.

No. I was referring to an issue that @SirWumpus opened. It is now clearer in the code.

• it now prevents people from having a topdir in workdir and vice versa (oops - I did not think of that but I should have!)

Do we need to require that for IOCCC28? Perhaps so.

This is also done all with the other changes.

So please advise me how you wish me to proceed.

[lcn2]

As for more pull requests: do you wish me to take care of the other issues that have fixes? They are:

• the -u uuid option (minimal change, not required)

As this is NOT required while IOCCC28 is open, it should be a POST-IOCCC28 issue

Sure but the changes are already there with others. So I am not sure what to do about that - I won't commit then until you give me your ideas.

• clarify and improve prompting for files/directories that mkiocccentry will ignore

By this you mean in the FAQ and/or guidelines of "the other repo"? Yes, please.

No. I was referring to an issue that @SirWumpus opened. It is now clearer in the code.

Which issue that @SirWumpus opened? If you mean the stuff about the first all rule test, then yes please.

• it now prevents people from having a topdir in workdir and vice versa (oops - I did not think of that but I should have!)

Do we need to require that for IOCCC28? Perhaps so.

This is also done all with the other changes.

Thanks.

So please advise me how you wish me to proceed.

Please proceed.

[xexyl]

As for more pull requests: do you wish me to take care of the other issues that have fixes? They are:

• the -u uuid option (minimal change, not required)

As this is NOT required while IOCCC28 is open, it should be a POST-IOCCC28 issue

Sure but the changes are already there with others. So I am not sure what to do about that - I won't commit then until you give me your ideas.

• clarify and improve prompting for files/directories that mkiocccentry will ignore

By this you mean in the FAQ and/or guidelines of "the other repo"? Yes, please.

No. I was referring to an issue that @SirWumpus opened. It is now clearer in the code.

Which issue that @SirWumpus opened? If you mean the stuff about the first all rule test, then yes please.

• it now prevents people from having a topdir in workdir and vice versa (oops - I did not think of that but I should have!)

Do we need to require that for IOCCC28? Perhaps so.

This is also done all with the other changes.

Thanks.

So please advise me how you wish me to proceed.

Please proceed.

I'll clarify so you can determine if i should commit.

• the uuid issue (#1206)

• 1210

• 1221

Also the issue that seems to have been closed which checks that topdir and workdir are not the same is also resolved.

These all were done relatively quickly. Some of those would have been committed yesterday (like the one about workdir/topdir) but for the versions issue.

So if I were to not commit some of those it could be problematic to remove some of the code and not the others.

Now if you need this I can do it but otherwise I can commit them all. It seems to work fine.

[xexyl]

Sorry. One of those is not right. Let me try again ...

[xexyl]

Updated comment with the correct list.

[lcn2]

I'll clarify so you can determine if i should commit.

• the uuid issue (Enhancement: add a new option to mkiocccentry to read from a file the UUID for easier updating and creating new tarballs #1206)

This seems to be a convenience feature, mostly for the those maintain stuff although we can see how it might be useful for others too. Nevertheless it seems to not a critical problem for IOCCC28, so it should remain as post-IOCCC28 to be safe.

Instead of post-IOCCC28, maybe this is really a IOCCC29 matter as the IOCCC judges won't need it for judging.

• Enhancement: Directory ignore list confusing #1210

This seems to be a convenience fire that should be set for IOCCC29.

• Bug: mkiocccentry fails if the Makefile contains := assignments. #1221

This should be fixed now.

Also the issue that seems to have been closed which checks that topdir and workdir are not the same is also resolved.

Issue #1209 is open and set for IOCCC29.

These all were done relatively quickly. Some of those would have been committed yesterday (like the one about workdir/topdir) but for the versions issue.

So if I were to not commit some of those it could be problematic to remove some of the code and not the others.

Now if you need this I can do it but otherwise I can commit them all. It seems to work fine.

UPDATE 0

The IOCCC28 is open and we have to be VERY CAREFUL.

We should only change things that impact submitters' ability to submit to IOCCC28, even if we think the code change seems minor.

[xexyl]

I'll clarify so you can determine if i should commit.

• the uuid issue (Enhancement: add a new option to mkiocccentry to read from a file the UUID for easier updating and creating new tarballs #1206)

This seems to be a convenience feature, mostly for the those maintain stuff although we can see how it might be useful for others too. Nevertheless it seems to not a critical problem for IOCCC28, so it should remain as post-IOCCC28 to be safe.

Instead of post-IOCCC28, maybe this is really a IOCCC29 matter as the IOCCC judges won't need it for judging.

Sure but it's really cumbersome to copy and paste the UUID for each submission.

Yes it's not critical but it's already in and you wish other changes to be committed. One I'm also not sure about - it might be because I've been waking up so early but I could swear you've said both ways.

• Enhancement: Directory ignore list confusing #1210

This seems to be a convenience fire that should be set for IOCCC29.

All it does is change the prompting but it's a reasonable amount of changes which would have to be removed for what seems like no real good reason.

• Bug: mkiocccentry fails if the Makefile contains := assignments. #1221

This should be fixed now.

Right. It is.

Also the issue that seems to have been closed which checks that topdir and workdir are not the same is also resolved.

Issue #1209 is open and set for IOCCC29.

I just missed it. And it was said by you this might be necessary for this IOCCC too. If this is the one about topdir/workdir. I am confused about this one most of all because you have (I think) said at times it should be fixed now and at times that it should not be fixed.

Now again if you need me to undo those changes I can do that but it'll take more time and it might not happen until tomorrow. It might happen today but it's getting to the time where I'll be thinking of leaving.

[lcn2]

Now again if you need me to undo those changes I can do that but it'll take more time and it might not happen until tomorrow. It might happen today but it's getting to the time where I'll be thinking of leaving.

If by "those changes" you mean:

• issue #1206

As much as this is a nice feature, it is hard to just that it is a critical fix for IOCCC28 while it is open.

However as you stated elsewhere in issue #1206

But it involves some code and it's in place and it'll be a pain to get it out (along with other changes if necessary) just to get the other fix in.

while we are not happy about this, outcome, and if you think it is SAFE, then you can keep it in.

• issue #1210

Unless this is also a case of "some code and it's in place and it'll be a pain to get it out", let it side into IOCCC29.

If, however it is a "some code and it's in place and it'll be a pain to get it out" and if you think it is SAFE, then you can keep it in.

QUESTION

Do we need her you decide on anything else?

[xexyl]

Now again if you need me to undo those changes I can do that but it'll take more time and it might not happen until tomorrow. It might happen today but it's getting to the time where I'll be thinking of leaving.

If by "those changes" you mean:

• issue Enhancement: add a new option to mkiocccentry to read from a file the UUID for easier updating and creating new tarballs #1206

As much as this is a nice feature, it is hard to just that it is a critical fix for IOCCC28 while it is open.

However as you stated elsewhere in issue #1206

But it involves some code and it's in place and it'll be a pain to get it out (along with other changes if necessary) just to get the other fix in.

while we are not happy about this, outcome, and if you think it is SAFE, then you can keep it in.

• issue Enhancement: Directory ignore list confusing #1210

Unless this is also a case of "some code and it's in place and it'll be a pain to get it out", let it side into IOCCC29.

If, however it is a "some code and it's in place and it'll be a pain to get it out" and if you think it is SAFE, then you can keep it in.

QUESTION

Do we need her you decide on anything else?

I feel bad not updating the code as you don't wish it there. It is indeed safe but it seems like you do not want it there.

You've said enough though yes thanks. I will look at it tomorrow and either commit them all or extract the ones that are important and then commit just those. As much as I would like the others in I am guessing I will not do that - I can always keep a local copy for me. But this is to be worried about tomorrow.

Best wishes on a good rest of your day! I'm off pretty soon for food and just to unwind.

[lcn2]

Perhaps this will help, @xexyl, and on further reflection.

In PRs (separate if it is easy, otherwise combine them), please:

• Commit the code as per issue #1206

Please explain in CHANGES.md for this pending repo release that these mods (for issue #1206) were urgently requested by some people who wish to enter IOCCC28 with multiple submissions.

• Commit the code as per issue #1210

Please explain in CHANGES.md for this pending repo release that these mods (for issue #1210) were urgently needed to help clarify how to ignore multiple files some people who wish to enter IOCCC28.

• Commit the code as per Issue #1221

Please explain in CHANGES.md for this pending repo release that these mods (for issue #1221) were urgently because some people had Makefiles that were OK but the previous code incorrectly objected to.

• Commit the code as per Issue #1222

Please explain in CHANGES.md for this pending repo release that these mods (for issue #1222) were urgently because some people had Makefiles that were OK but the previous code incorrectly objected to.

• Commit the code as per Issue #1214

Please explain in CHANGES.md for this pending repo release that these mods (for issue #1214) were urgently because some people had valid code that previous code incorrectly objected to.

NOTE

To further clarify and be sure you understand in some cases, our change to mind, we have set each issue to have a ((TOP PRIORITY)) and removed any other tags that implied a delay.

QUESTION

Did we miss anything?

[xexyl]

Perhaps this will help, @xexyl, and on further reflection.

Oh that is helpful yes - thanks! I will do it tomorrow morning though as I do have a question and I remembered something that has not been done yet.

In PRs (separate if it is easy, otherwise combine them), please:

• Commit the code as per issue Enhancement: add a new option to mkiocccentry to read from a file the UUID for easier updating and creating new tarballs #1206

Please explain in CHANGES.md for this pending repo release that these mods (for issue #1206) were urgently requested by some people who wish to enter IOCCC28 with multiple submissions.

Will do.

• Commit the code as per issue Enhancement: Directory ignore list confusing #1210

Please explain in CHANGES.md for this pending repo release that these mods (for issue #1210) were urgently needed to help clarify how to ignore multiple files some people who wish to enter IOCCC28.

Will do.

• Commit the code as per Issue Bug: mkiocccentry fails if the Makefile contains := assignments. #1221

Please explain in CHANGES.md for this pending repo release that these mods (for issue #1221) were urgently because some people had Makefiles that were OK but the previous code incorrectly objected to.

Sure.

• Commit the code as per Issue Enhancement: Remove first_rule_is_all from .info.json for IOCCC29 #1222

Please explain in CHANGES.md for this pending repo release that these mods (for issue #1222) were urgently because some people had Makefiles that were OK but the previous code incorrectly objected to.

I'll do that.

• Commit the code as per Issue Enhancement: disable some iocccsize warnings unless -v set greater than 1 #1214

Okay but as far as this one - this is not code I should change. Or do you maybe mean that the mkiocccentry tool should not warn about the buffer overflow? This one is not done but I can do - though that would only be not warning about it and making sure to set the boolean to false.

Please explain in CHANGES.md for this pending repo release that these mods (for issue #1214) were urgently because some people had valid code that previous code incorrectly objected to.

NOTE

To further clarify and be sure you understand in some cases, our change to mind, we have set each issue to have a ((TOP PRIORITY)) and removed any other tags that implied a delay.

QUESTION

Did we miss anything?

Well there's the question above about iocccsize and mkiocccentry warnings. Other than that I think you covered it.

Let me know how you wish me to address that and then tomorrow morning I'll do it and then commit.

Bread is about to come out of the oven and I'm also going to get a meal as well so I'll just reply quickly to the other thread and then get going.

Have a great day and thanks!

[lcn2]

Okay but as far as this one - this is not code I should change. Or do you maybe mean that the mkiocccentry tool should not warn about the buffer overflow? This one is not done but I can do - though that would only be not warning about it and making sure to set the boolean to false.

If you follow the guidelines in GH-issuecomment-2708497612 and GH-issuecomment-2708506641 you should be able to modify the code just fine.

[lcn2]

Okay but as far as this one - this is not code I should change. Or do you maybe mean that the mkiocccentry tool should not warn about the buffer overflow?

It could do that, @xexyl , yes. Or perhaps instead if warning it could just remark along the lines of:

The iocccsize reported a buffer overflow.  How curious!
You might mention this fun fact in your remarks.md file.

A nice friendly non-alarming message, with an empty line above and below it to help that 2 line message stand out.

The mkiocccentry(1) tool could still set any .info.json booleans as before and just be sure that tools such as chkentry(1) do not consider them to be errors.

[xexyl]

Okay but as far as this one - this is not code I should change. Or do you maybe mean that the mkiocccentry tool should not warn about the buffer overflow? This one is not done but I can do - though that would only be not warning about it and making sure to set the boolean to false.

If you follow the guidelines in GH-issuecomment-2708497612 and GH-issuecomment-2708506641 you should be able to modify the code just fine.

Sure but I was thinking of rule_count.c. Anyway I'll look at the comments in a while. I'm going to commit the other stuff first (in a bit) and then fix this one. So it'll be more than one pull request.

Thanks.

[xexyl]

Okay but as far as this one - this is not code I should change. Or do you maybe mean that the mkiocccentry tool should not warn about the buffer overflow?

It could do that, @xexyl , yes. Or perhaps instead if warning it could just remark along the lines of:

The iocccsize reported a buffer overflow.  How curious!
You might mention this fun fact in your remarks.md file.

A nice friendly non-alarming message, with an empty line above and below it to help that 2 line message stand out.

The mkiocccentry(1) tool could still set any .info.json booleans as before and just be sure that tools such as chkentry(1) do not consider them to be errors.

Oh I like that idea! I'll do that instead.

[xexyl]

I decided to make it a new date in the release. If you wish me to set it to another date, @lcn2, please let me know.

I'm going to address the iocccsize stuff next and then I can look at the FAQ and other files to see what might need to be updated.

[SirWumpus]

I would prefer to see the message silent, its a diagnostic. Not significant to normal operations so display a message creates unnecessary worry.

[xexyl]

I would prefer to see the message silent, its a diagnostic. Not significant to normal operations so display a message creates unnecessary worry.

Hmm ... are you referring to the friendly message Landon suggested ?

I could do that but I'll let you two decide how it should go first.

[SirWumpus]

I could do that but I'll let you two decide how it should go first.

I'll go get my Judo gi out out of the closet.

[xexyl]

I could do that but I'll let you two decide how it should go first.

I'll go get my Judo gi out out of the closet.

LOL.

I used to do karate as a kid - a Japanese kind .. I have the shirt from there somewhere here in my wardrobe which has the kind but I am not 100% sure of the kind without looking. It's Okinawa though, I know that. I have my tonfa(s?) and my belts and the boards I chopped with my hand. Sadly I only have training nunchaku because I quit before I finished my training.

Just do me a favour when you meet him in the ring: don't bite an ear off! Okay I know that's boxing but I saw a reference to that infamous fight yesterday. Back then there was a joke about that and Metallica: Metallica leaves a ring in your ear but Mike Tyson leaves your ear in a ring. Mean but funny. Even now it makes me laugh out loud.

[SirWumpus]

Shodan diploma 1993

[xexyl]

Shodan diploma 1993

Nice! Thanks for sharing. And now that you say that .. it started with an S - pretty sure of it. I'd recognise it if I saw the word. I'm working on something for jparse (for later on - it's quick) and then going to look at the website for the recent mods. Might try and find what martial arts it was. I might even be able to tell . I have a picture of me as a kid with the shirt on watching tv with two cats on my shoulders (well one cat on each). If I can find that it might be clear enough.

[xexyl]

Nope .. picture is too blurry. Well that was before digital cameras even so (and quick picture probably and I have bad vision).

[xexyl]

I think it was Shōtōkan but perhaps not.

Anyway - thanks for sharing.

[SirWumpus]

Its kinda like winning the IOCCC; no prizes (ok skills & a diploma) and bragging rights.

[xexyl]

Its kinda like winning the IOCCC; no prizes (ok skills & a diploma) and bragging rights.

You mean the judo you did ?

[lcn2]

I decided to make it a new date in the release. If you wish me to set it to another date, @lcn2, please let me know.

I'm going to address the iocccsize stuff next and then I can look at the FAQ and other files to see what might need to be updated.

BTW

The date for the release of this repo in CHANGES.md and the date we actually do the release may be different. Nevertheless, the release name will be based in the top version headline in CHANGES.md.

[xexyl]

I decided to make it a new date in the release. If you wish me to set it to another date, @lcn2, please let me know. I'm going to address the iocccsize stuff next and then I can look at the FAQ and other files to see what might need to be updated.

BTW

The date for the release of this repo in CHANGES.md and the date we actually do the release may be different. Nevertheless, the release name will be based in the top version headline in CHANGES.md.

Yes. I was not sure if today's changes should update it or not. I can fix it to be earlier if you wish - though if you do please let me know what it should be changed to.

It seemed like it should be changed but if you have something particular in mind I don't know (I am only unsure because you had said something about this yesterday or the day before).

[lcn2]

I would prefer to see the message silent, its a diagnostic. Not significant to normal operations so display a message creates unnecessary worry.

Hmm ... are you referring to the friendly message Landon suggested ?

I could do that but I'll let you two decide how it should go first.

We can see it go either way.

The advantage of leaving in the diagnostic and the friendly message is that it might give people someone to try and achieve: I.e., some harmless fun.

Does that help, @SirWumpus? If not, we can remove it altogether if it " bothers" you.

[lcn2]

I decided to make it a new date in the release. If you wish me to set it to another date, @lcn2, please let me know.

I'm going to address the iocccsize stuff next and then I can look at the FAQ and other files to see what might need to be updated.

BTW

The date for the release of this repo in CHANGES.md and the date we actually do the release may be different. Nevertheless, the release name will be based in the top version headline in CHANGES.md.

Yes. I was not sure if today's changes should update it or not. I can fix it to be earlier if you wish - though if you do please let me know what it should be changed to.

It seemed like it should be changed but if you have something particular in mind I don't know (I am only unsure because you had said something about this yesterday or the day before).

The usual practice is that if you make a change that "deserves" a mention in CHANGES.md, then you should change the date 📆 of the version (as well as to any related line(s) in soup/version.h) to today.

IMPORTANT

When changing versions in soup/version.h:

Be sure that the "MIN" versions remain as they were when IOCCC28 opened in soup/version.h.

Those "MIN" versions in soup/version.h won't change until we start to get ready for IOCCC29.

[xexyl]

I decided to make it a new date in the release. If you wish me to set it to another date, @lcn2, please let me know.

I'm going to address the iocccsize stuff next and then I can look at the FAQ and other files to see what might need to be updated.

BTW

The date for the release of this repo in CHANGES.md and the date we actually do the release may be different. Nevertheless, the release name will be based in the top version headline in CHANGES.md.

Yes. I was not sure if today's changes should update it or not. I can fix it to be earlier if you wish - though if you do please let me know what it should be changed to. It seemed like it should be changed but if you have something particular in mind I don't know (I am only unsure because you had said something about this yesterday or the day before).

The usual practice is that if you make a change that "deserves" a mention in CHANGES.md, then you should change the date 📆 of the version (as well as to any related line(s) in soup/version.h) to today.

IMPORTANT

When changing versions in soup/version.h:

Be sure that the "MIN" versions remain as they were when IOCCC28 opened in soup/version.h.

Those "MIN" versions in soup/version.h won't change until we start to get ready for IOCCC29.

Of course.

[SirWumpus]

Does that help, @SirWumpus? If not, we can remove it altogether if it " bothers" you.

Leave the diagnostic. never know when it might be useful.