lcn2 commented 2 months ago

Is there an existing issue for this?

[X] I have searched for existing issues and did not find anything like this

Describe the feature

Tools such as mkiocccentry(1) (and perhaps jparse(1) where printing JSON debug information where indenting it seems reasonable) should only produce JSON indented with multiples of 4 ASCII spaces and without and leading TABs.

The JSON tests should include for testing a variety of JSON indenting including that of TAB based indenting, 4 character spaced indenting, mixed space and TAB indenting (where a 2-level indent is does by a TAB character), as well as no intending whatsoever. These JSON test should be done NOT because such formatting is canonical practice, but rather than the JSON parser should be able to handle such different indentation methods. (We believe it does, but we want to explicitly make sure we have JSON test cases that show this is the case).

NOTE: There are special test cases under the test_ioccc/test_JSON/{auth.json,entry.json,info.json}/good/ directories that MUST be changed to use the new “JSON using 4 spaces and without any leading TABs” style. Existing JSON test files of the form “*.reference.json” and “*.good.json” MUST use only the “JSON using 4 spaces and without any leading TABs” method. Please add other test cases in those directories that use different JSON intending (including no JSON indenting), just don’t name them files of the form “*.reference.json” nor of the form “*.good.json”.

Nevertheless, while tools such as the JSON parser should be “generous” with type of JSON indenting (and even the lack of indenting) it is willing to accept AND it should be strict in the JSON format that is produced to be only multiples of 4 ASCII spaces and without leading TABs.

Relevant images, screenshots or other files

N/A

Relevant links

N/A

Anything else?

This is a reasonably high priority. Once this issue is completed, we will be happy to convert all JSON files in that other repo to using JSON 4 ASCII space no TAB formatting. This issue needs to be done before the Great Fork Merge.

After this issue is finished, we will release a new version of this repo.

lcn2 commented 2 months ago

We suggest that you use, form that other repo:

bin/jfmt-wrapper.sh foo.json

as this uses JSON -S -A -j -f foo.json to format JSON, as a model for the JSON canonical output that is in keeping with this issue.

lcn2 commented 2 months ago

There is an inconsistent format problem with.info.json files produced by mkiocccentry(1). For example:

        "manifest" : [
                {"info_JSON" : ".info.json"},
                {"auth_JSON" : ".auth.json"},
                {"c_src" : "prog.c"},
                {"Makefile" : "Makefile"},
                {"remarks" : "remarks.md"},
                {"extra_file" : "extra.06"}
         ],

Properly formatted, the above manifest should be:

    "manifest" : [
        {
            "info_JSON" : ".info.json"
        },
        {
            "auth_JSON" : ".auth.json"
        },
        {
            "c_src" : "prog.c"
        },
        {
            "Makefile" : "Makefile"
        },
        {
            "remarks" : "remarks.md"
        },
        {
            "extra_file" : "extra.06"
        }
    ],

lcn2 commented 2 months ago

With commit 6655e2f31cb40429de776a83a10e8150ddc8329e and commit afe9f9ea08ced270ab5f723341cf03680b36ed96 from the other repo, the JSON files in the temp-test-ioccc repo have been modified as per the bin/jfmt-wrapper.sh tool.

UPDATE 0a

Why now? In part because of the discovery of the manifest consistency and in part because the canonical format favored by GH-issuecomment-2282883461 and the subsequent discussion.

If we are going to fix the manifest consistency problem and move to the canonical JSON format, if needs to be done now.

xexyl commented 2 months ago

jparse doesn't print the json itself so that shouldn't matter for it, right?

I can look at the comments sometime soon but possibly not until tomorrow. Please assign this to me anyway though.

If I understand something right though the .info.json file should be formatted the same way as the code block you give above. Is that right? If so I might be able to do that tomorrow. I was hoping to look at 2005 - and maybe I can still but that is not certain - but this seems to be more important. Is that correct?

What about the .auth.json file?

Are there any other tools? Of course the new tools that have to be discussed more thoroughly (later on after the merge) will also have to do these things.

UPDATE 0

And I did finish the tasks I had to do today but I have to go afk now .. might (doubt it but maybe) have a little bit of time to look at things more today. Tomorrow I will have some tasks too besides IOCCC but it should not be as much. Afk now .. back tomorrow if not today.

xexyl commented 2 months ago

Working on this but I have to go afk a bit .. should be able to do it today. Unsure what else I'll get done today as it was an extremely rough night and I have other things I have to do too. But for now afk a bit.

xexyl commented 2 months ago

I've ran into a problem that requires discussion.

There are several ways to go about the printing of many spaces. One is a set of functions that uses printf "%*s". I added helper functions of this which seems like a useful thing to have. But then how can this be used with functions like json_fprintf_value_string()? Having an empty lead string will cause a problem because it checks the return value of fprintf() and that function returns the number of characters written.

A callback is a TERRIBLE idea not only because it would needlessly complicate those functions but because it puts a burden on the user to always have to have a proper function matching the required prototype: something we cannot and should NOT assume!

One way is to make it something like:

ret = fprintf(info_stream, "{\n") > 0 &&
        fpr_spaces(info_stream, __func__, 3) &&
        json_fprintf_value_string(info_stream, " ", JSON_PARSING_DIRECTIVE_NAME, " : ", JSON_PARSING_DIRECTIVE_VALUE, ",\n") /* and so on */ ;

(sorry for awful formatting here - just a copy paste)

In other words, the leading string is a single space and the space printing function prints the required number of spaces which is one under the necessary spaces. But this ALSO seems wrong. Of course we could (maybe) have a defined macro for the number of spaces we want but that's another matter entirely.

On the other hand this also seems ugly:

    ret = fprintf(info_stream, "{\n") > 0 &&
        json_fprintf_value_string(info_stream, "    ", JSON_PARSING_DIRECTIVE_NAME, " : ", JSON_PARSING_DIRECTIVE_VALUE, ",\n") &&
        json_fprintf_value_string(info_stream, "    ", "IOCCC_info_version", " : ", INFO_VERSION, ",\n") &&
        json_fprintf_value_string(info_stream, "    ", "IOCCC_contest", " : ", IOCCC_CONTEST, ",\n") /* and so on */ ;

especially when we get to higher indentation levels (numbers).

Of course IFF (which is a BIG assumption and a VERY BAD one too) the lead string is only spaces we could modify it to take the number of spaces to print. I think this is a VERY BAD idea.

So we have:

a lot of spaces in the function calls (ugly and increases line length when something better can be contrived .. and not only that it would require one to count the number of spaces to be sure .. AND it ALSO requires the number of spaces to be typed in a consistent manner which is ERROR PRONE!)
the function idea I started (and implemented) but requiring one under the required number of spaces because the json print value functions require at least one character in the lead string (this seems not only wrong but also misleading to me!)
IFF the lead is always spaces (which is a BIG assumption) we could modify the functions to call the new functions (due to the assumption I think this is a VERY BAD idea)
something else?

What is clear to me is if we're not going to use tabs (which is a good idea esp for several levels in) having a set of functions to print a callable specified number of spaces is a good idea. But what is not clear to me is (because the json print value functions require a lead string to be written out) that it could be misleading to say (for example) print out 3 spaces but then the output will actually be 4 spaces due to the " " in the json print value functions.

So we need to discuss these options before I can finish this issue. Now I can at least commit the new functions but it'd be ideal if the other part is resolved too.

In the meantime I have other things I should do so I'll be doing those things now. If I have time later (which is extremely likely) AND have the energy (that is less certain but I hope to) I can work on either this (if you reply) or 2005 and maybe more than that. Of course the last four nights have been truly dreadful so I might just need to take it easy but I hope to at least get some work done (besides what I already did in the other repo: minor and not really important at this time as it certainly does not make progress).

lcn2 commented 2 months ago

The GH-issuecomment-2302495928 certainly shows some ways we do NOT want to do this. We agree with you on this points. For various reasons you have stated we concur.

We highly recommend, for the sake of time and effort, to modify in mkiocccentry.c functions such as the wrtie_info() and write_auth(). Those pass strings as args to fprintf(3), json_fprintf_value_string(), json_fprintf_value_long(), json_fprintf_value_bool(), etc.

Lines such as:

json_fprintf_value_long(info_stream, "\t", "rule_2a_size", " : ", (long)infop->rule_2a_size, ",\n") &&

Just need to become:

json_fprintf_value_long(info_stream, "    ", "rule_2a_size", " : ", (long)infop->rule_2a_size, ",\n") &&

For example.

Let us avoid overcomplicating this matter. For future tools such as jfmt(1) and jprint(1), you can ponder a more general solution: one that uses the data structures of the JSON parse tree to output multiples of 4 spaces based on the tree depth level. Nevertheless, such a solution (one that seems fairly straightforward) is for future tools, NOT existing tools that this issue needs to be modified.

We think the only tool that may be impacted by this issue is the mkiocccentry(1) tool. That, for now, seems to be the only tool in this repo that creates JSON content.

Well that, and updating the test cases as noted in top level TODO comment.

xexyl commented 2 months ago

The GH-issuecomment-2302495928 certainly shows some ways we do NOT want to do this. We agree with you on this points. For various reasons you have stated we concur.

We highly recommend, for the sake of time and effort, to modify in mkiocccentry.c functions such as the wrtie_info() and write_auth(). Those pass strings as args to fprintf(3), json_fprintf_value_string(), json_fprintf_value_long(), json_fprintf_value_bool(), etc.

Lines such as:
json_fprintf_value_long(info_stream, "\t", "rule_2a_size", " : ", (long)infop->rule_2a_size, ",\n") &&
Just need to become:
json_fprintf_value_long(info_stream, "    ", "rule_2a_size", " : ", (long)infop->rule_2a_size, ",\n") && 
For example.

Let us avoid overcomplicating this matter. For future tools such as jfmt(1) and jprint(1), you can ponder a more general solution: one that uses the data structures of the JSON parse tree to output multiples of 4 spaces based on the tree depth level. Nevertheless, such a solution (one that seems fairly straightforward) is for future tools, NOT existing tools that this issue needs to be modified.

We think the only tool that may be impacted by this issue is the mkiocccentry(1) tool. That, for now, seems to be the only tool in this repo that creates JSON content.

Well that, and updating the test cases as noted in top level TODO comment.

I can do that but do you want it for the cases where there were two tabs too? Well I guess that would not be too bad. Just concerned it is error prone, having to make sure that eight spaces are entered.

Anyway that's for later today or else tomorrow. It is unfortunate if I have to get rid of the general purpose functions but I can yank paste them to another file for later I guess.

Must be away for a while. Unsure if I will get to do more today other than what I did here and the many fixes over at the other repo.

Thanks.

xexyl commented 2 months ago

.. actually just thought of a good easy and not error prone way to do it. But later on.

lcn2 commented 2 months ago

Anyway that's for later today or else tomorrow. It is unfortunate if I have to get rid of the general purpose functions but I can yank paste them to another file for later I guess.

One just needs to change the arguments you give to the existing functions. There shouldn't be any reason to add new functions.

Right now those args include \t characters. A simple MACRO that given the JSON level, produces multiples of 4 spaces is could be used, but even that is way over complicating things.

Just change the strings being passed to indent with multiples of 4 spaces.

UPDATE 0a

The mkiocccentry.c code was intended to be steightforward and easy to read. Please do not overcomplicate the change. Please just change the required strings in the two functions that write out the two JSON files.

Feel free to come hop with a more general solution when it comes time to write new tools such as jfmt(1) and jprint(1).

This issue is about the existing tool, which seems to only be mkiocccentry(1), that writes out two very specific JSON files (.info.json and .auth.json) that need to be intended in the way that bin/jfmt-wrapper.sh (from the other repo) does things. Those 2 JSON files are fairly simple, do not have a lot of depth, and just need to be written out using multiples of 4 spaces.

UPDATE 1

Just concerned it is error prone, having to make sure that eight spaces are entered.

For the two JSON files produces by mkiocccentry(1), first just try by hand to see of bin/jfmt-wrapper.sh (from the other repo) modifies them or not.

And you don't need (or want) to add use of the bin/jfmt-wrapper.sh tool as part of the testing.

You can simply use that tool to create a "reference" JSON files that a test can compare using the cmp(1) tool.

xexyl commented 2 months ago

Anyway that's for later today or else tomorrow. It is unfortunate if I have to get rid of the general purpose functions but I can yank paste them to another file for later I guess.

There is no need to get rid of the general purpose functions. One just needs to change the arguments you give them.

Right now those args include \t characters. A simple MACRO that given the JSON level, produces multiples of 4 spaces is could be used, but even that is way over complicating things.

Just change the strings being passed to indent with multiples of 4 spaces.

That seems like maybe I shouldn't include them. Though I did think about a macro instead too. But it also checks errors and returns a boolean which is a reason to keep it a function.

But we can discuss that all another time. I will for now just save them elsewhere. In a bit I will be back at the laptop and might look at this.

But I do not know just yet. If I do do this it's quite possible that will be all for the day (which of course was quite a bit and much more than I anticipated).

lcn2 commented 2 months ago

Anyway that's for later today or else tomorrow. It is unfortunate if I have to get rid of the general purpose functions but I can yank paste them to another file for later I guess.

There is no need to get rid of the general purpose functions. One just needs to change the arguments you give them.

Right now those args include \t characters. A simple MACRO that given the JSON level, produces multiples of 4 spaces is could be used, but even that is way over complicating things.

Just change the strings being passed to indent with multiples of 4 spaces.

That seems like maybe I shouldn't include them. Though I did think about a macro instead too. But it also checks errors and returns a boolean which is a reason to keep it a function.

But we can discuss that all another time. I will for now just save them elsewhere. In a bit I will be back at the laptop and might look at this.

But I do not know just yet. If I do do this it's quite possible that will be all for the day (which of course was quite a bit and much more than I anticipated).

If it helps, we are willing to modify mkiocccentry.c to fix the format of the 2 JSON files. Let us know and we will do that. That might break tests, but you can then modify the tests to pass according to the new JSON 4-space indenting.

xexyl commented 2 months ago

Anyway that's for later today or else tomorrow. It is unfortunate if I have to get rid of the general purpose functions but I can yank paste them to another file for later I guess.

There is no need to get rid of the general purpose functions. One just needs to change the arguments you give them. Right now those args include \t characters. A simple MACRO that given the JSON level, produces multiples of 4 spaces is could be used, but even that is way over complicating things. Just change the strings being passed to indent with multiples of 4 spaces.

That seems like maybe I shouldn't include them. Though I did think about a macro instead too. But it also checks errors and returns a boolean which is a reason to keep it a function. But we can discuss that all another time. I will for now just save them elsewhere. In a bit I will be back at the laptop and might look at this. But I do not know just yet. If I do do this it's quite possible that will be all for the day (which of course was quite a bit and much more than I anticipated).

If it helps, we are willing to modify mkiocccentry.c to fix the format of the 2 JSON files. Let us know and we will do that. That might break tests, but you can then modify the tests to pass according to the new JSON 4-space indenting.

Please do that as I am having one of those days and trying to fix alignments is not fun on such days. I would be happy to fix any tests that fail of course.

Thanks. I'm going to merge the changes in the repos on my forks and then not sure what else. Maybe I can look at 2005 over there but I'm not sure. I am feeling pretty worn out but I have been so slow in making progress that it's bothering me (though I know that's a temporary thing it's still bothering me as it's almost the end of August now).

lcn2 commented 2 months ago

With commit 03fe3f61e55e5bf0f274bb2fbc0cfc541a8d5e32 and as per the request of GH-issuecomment-2302909009:

The .info.json and .auth.json JSON files created by mkiocccentry(1) are now using the "new" canonical indenting with multiples of 4 spaces (no tabs).

NOTE: The version of mkiocccentry(1) has NOT been updated, nor have any tests been added not updated. See the TODO item at the top of the issue for more information.

We will now return to work on the other repo.

UPDATE 0

The above does NOT complete the issue. The MKIOCCCENTRY_VERSION value in soup/version.h needs to be updated.

Tests added or modified as per GH-issue-2476151770 are also needed.

This was just to satisfy the request in GH-ssuecomment-2302909009.

We will leave that task to you, @xexyl .. we hope this helps.

UPDATE 1

With commit 8ce8f89490e67d2140bb10dbd97d8657e5ac9fd1

Formatting a most of the test_ioccc/test_JSON/auth.json/good/*.json and most of the test_ioccc/test_JSON/info.json/good/*.json files. We did NOT modify bad files, and did NOT modify the good files that used a minimum of whitespace.

NOTE: We have NOT added new test cases, just canonically formatted most good existing test cases.

NOTE: We have NOT updated MKIOCCCENTRY_VERSION.

xexyl commented 2 months ago

With commit 03fe3f6 and as per the request of GH-issuecomment-2302909009:

The .info.json and .auth.json JSON files created by mkiocccentry(1) are now using the "new" canonical indenting with multiples of 4 spaces (no tabs).

NOTE: The version of mkiocccentry(1) has NOT been updated, nor have any tests been added not updated. See the TODO item at the top of the issue for more information.

We will now return to work on the other repo.

UPDATE 0

The above does NOT complete the issue. The MKIOCCCENTRY_VERSION value in soup/version.h needs to be updated.

Tests added or modified as per GH-issue-2476151770 are also needed.

This was just to satisfy the request in GH-ssuecomment-2302909009.

We will leave that task to you, @xexyl .. we hope this helps.

UPDATE 1

With commit 8ce8f89

Formatting a most of the test_ioccc/test_JSON/auth.json/good/*.json and most of the test_ioccc/test_JSON/info.json/good/*.json files. We did NOT modify bad files, and did NOT modify the good files that used a minimum of whitespace.

NOTE: We have NOT added new test cases, just canonically formatted most good existing test cases.

NOTE: We have NOT updated MKIOCCCENTRY_VERSION.

I will do these things soon .. I hope to do that today but it's going to be a hectic day with a contractor here. I might have time before that and I might be able to do it even when he is here (at least we can trust him - he's family - but the problem is the dogs will be .. well, barking mad, to make the correct pun).

xexyl commented 2 months ago

Okay the version is easy enough to do but I looked at the top comment and am unclear about some things - or how to approach some of the things. I must go afk for a while but when I'm back I will try and address them. As noted I have a hectic day and I also have other things I need to do but I hope to at least get this issue started if not resolved. I'm unsure I can get it resolved as it might require discussion.

I believe I can format the json files with the jfmt-wrapper.sh. However what is unclear to me is whether or not all should be done as we have minimal json files too. There are other questions I also have but for now I must go afk. Hopefully with discussion this can be resolved soon.

I will add, as an aside, the other thing that has been slowing me down, is drawing to an end, so hopefully I will be back in full force soon.

UPDATE 0

I also have a quick phone call today (doctor appointment).

xexyl commented 2 months ago

Quick thought

Should the manifest in the .info.json file be at the very end of the file ? Okay this is not strictly necessary but it might be easier to read? It not slow things down really: it would take minimal effort to update the code and just a yank paste in the FAQ over there. Just a thought. Afk a while now.

lcn2 commented 2 months ago

Quick thought

Should the manifest in the .info.json file be at the very end of the file ? Okay this is not strictly necessary but it might be easier to read? It not slow things down really: it would take minimal effort to update the code and just a yank paste in the FAQ over there. Just a thought. Afk a while now.

While it is near the bottom already, we do not think that moving it below the final 4 timestamp related values helps readability all that much. Moreover the current order of .infi.json mirrors the current .auth.json layout.

xexyl commented 2 months ago

Quick thought

Should the manifest in the .info.json file be at the very end of the file ? Okay this is not strictly necessary but it might be easier to read? It not slow things down really: it would take minimal effort to update the code and just a yank paste in the FAQ over there. Just a thought. Afk a while now.

While it is near the bottom already, we do not think that moving it below the final 4 timestamp related values helps readability all that much. Moreover the current order of .infi.json mirrors the current .auth.json layout.

Well as for the latter part that could also be changed but it's also unnecessary. It doesn't help much at all, no. Probably the only reason it popped into my head is 'order' (as in those are single values where the other part is an array). It does not matter but since it popped into my head I figured I'd mention it.

xexyl commented 2 months ago

I will try and reply to the things that need to be done here, now, before I go take care of other things. I hope that after those things I can look at the other repo again or if replies here maybe address this issue instead..

xexyl commented 2 months ago

With commit 03fe3f6 and as per the request of GH-issuecomment-2302909009:

The .info.json and .auth.json JSON files created by mkiocccentry(1) are now using the "new" canonical indenting with multiples of 4 spaces (no tabs).

NOTE: The version of mkiocccentry(1) has NOT been updated, nor have any tests been added not updated. See the TODO item at the top of the issue for more information.

We will now return to work on the other repo.

UPDATE 0

The above does NOT complete the issue. The MKIOCCCENTRY_VERSION value in soup/version.h needs to be updated.

Tests added or modified as per GH-issue-2476151770 are also needed.

This was just to satisfy the request in GH-ssuecomment-2302909009.

We will leave that task to you, @xexyl .. we hope this helps.

UPDATE 1

With commit 8ce8f89

Formatting a most of the test_ioccc/test_JSON/auth.json/good/*.json and most of the test_ioccc/test_JSON/info.json/good/*.json files. We did NOT modify bad files, and did NOT modify the good files that used a minimum of whitespace.

The minimum whitespace ones should not even be modified either, right?

NOTE: We have NOT updated MKIOCCCENTRY_VERSION.

That's not a problem to take care of of course.

xexyl commented 2 months ago

NOTE: We have NOT added new test cases, just canonically formatted most good existing test cases.

The new test case is the part I am entirely unclear about. What needs to be tested? Let's say you want the format tested - how would we do that and in what tool would we do that in? That seems like a jparse thing but that also seems like something we might in the future use jfmt but in the meantime run the shell script.

But even so how do we test it and what if any tests fail? What kind of test files are needed (I believe that answering the other questions will help with answering this but maybe not).

xexyl commented 2 months ago

Nevertheless, while tools such as the JSON parser should be “generous” with type of JSON indenting (and even the lack of indenting) it is willing to accept AND it should be strict in the JSON format that is produced to be only multiples of 4 ASCII spaces and without leading TABs.

.. this might suggest that we need to make sure other tools that might generate JSON also do this but what else besides mkiocccentry(1) does this? It's also possible I misunderstand this. It is also not clear to me what you mean by:

it should be strict in the JSON format that is produced to be only multiples of 4 ASCII spaces and without leading TABs.

What is it? The parser? Because of course we don't want to restrict space versus tab as otherwise it would make the parser far less useful.

These things I am also confused by. Off to take care of some other things now.

lcn2 commented 2 months ago

The new test case is the part I am entirely unclear about. What needs to be tested?

Adding a few variants of indenting of canonically formatted JSON, under good directory might be a good idea. We know that whitespace won't matter to the JSON parser, but it is a good idea to have a few good whitespace variants to prove that.

We suggest you add a few more, less extreme, indenting variables such as:

tab intending
2 space intending
no intending
random / mixed intending

We need just a few under both the auth.json/good and info.json/good directories to "prove" that indenting does not matter to the JSON parser.

The minimum whitespace ones should not even be modified either, right?

Correct. The "minimal" file (both with and without the trailing newline) were two extreme examples of an indenting variant. :-)

UPDATE 0

Speaking of JSON test cases:

Also the MKIOCCCENTRY_VERSION value needs to be updated such as to "1.0.8 2024-08-22" , and thus all of the existing JSON test cases that use the older "1.0.7 2024-07-12" need to be changed to use the new value.

And then finally CHANGES.md needs to be updated accordingly.

lcn2 commented 2 months ago

We believe we have addressed all of the current questions that still need answering at this time. If we've missed something or something else needs to be clarified, please ask again.

xexyl commented 2 months ago

The new test case is the part I am entirely unclear about. What needs to be tested?

Adding a few variants of indenting of canonically formatted JSON, under good directory might be a good idea. We know that whitespace won't matter to the JSON parser, but it is a good idea to have a few good whitespace variants to prove that.

We suggest you add a few more, less extreme, indenting variables such as:

tab intending

2 space intending

no intending

random / mixed intending

We need just a few under both the auth.json/good and info.json/good directories to "prove" that indenting does not matter to the JSON parser.

Ahhh I see. Thanks. I am unsure if I can get to this today but if not I should be able to tomorrow morning. It is one of those days. If I don't get to it today I'll of course change the date in the version to tomorrow.

lcn2 commented 2 months ago

Ahhh I see. Thanks. I am unsure if I can get to this today but if not I should be able to tomorrow morning. It is one of those days. If I don't get to it today I'll of course change the date in the version to tomorrow.

Thank you 🙏.

And once you are finished (no rush), we will push out a new release of this repo - perhaps the final one before the Great Fork Merge.

xexyl commented 2 months ago

Ahhh I see. Thanks. I am unsure if I can get to this today but if not I should be able to tomorrow morning. It is one of those days. If I don't get to it today I'll of course change the date in the version to tomorrow.

Thank you 🙏.

You are most welcome.

And once you are finished (no rush), we will push out a new release of this repo - perhaps the final one before the Great Fork Merge.

Sounds good. I'm sure I can do it tomorrow. I'm leaving earlier than I expected. I did not end up getting what I was going to work on today done but I will do that tomorrow instead. As I said earlier I am getting to the point where I can do more in the days which will be good.

Have a great rest of your day!

xexyl commented 2 months ago

Running make prep on these new files ... will commit after updating version and changes if all is good. Will be leaving shortly. Unsure what I'll do today as I'm really not feeling well. But hopefully that changes in a bit. I do have other things to take care of too I'm afraid but at least this issue should be resolved.

xexyl commented 2 months ago

Oh that was silly of me .... should have changed version first. Just did and now running make prep again. Unsure if I'll commit before I go afk.

xexyl commented 2 months ago

If I understand correctly the commit https://github.com/ioccc-src/mkiocccentry/pull/936/commits/67195e8ffd05dbbda86b87cef7712037f2589074 resolves this issue. If this is incorrect please advise what else has to be done. Thanks.

It was a very hard night and I am not feeling well so I doubt I'll get much done today unfortunately. I have some things i need to take care of but if I have time I'll work on the other repo a bit. I hope tomorrow will be better.

lcn2 commented 2 months ago

If I understand correctly the commit https://github.com/ioccc-src/mkiocccentry/pull/936/commits/67195e8ffd05dbbda86b87cef7712037f2589074 resolves this issue. If this is incorrect please advise what else has to be done. Thanks.

It was a very hard night and I am not feeling well so I doubt I'll get much done today unfortunately. I have some things i need to take care of but if I have time I'll work on the other repo a bit. I hope tomorrow will be better.

Thank you and best wishes for a better tomorrow, @xexyl

xexyl commented 1 month ago

If I understand correctly the commit 67195e8 resolves this issue. If this is incorrect please advise what else has to be done. Thanks. It was a very hard night and I am not feeling well so I doubt I'll get much done today unfortunately. I have some things i need to take care of but if I have time I'll work on the other repo a bit. I hope tomorrow will be better.

Thank you and best wishes for a better tomorrow, @xexyl

Just saw this ... thank you! It's kind of all over the place but I do hope things will start speeding up soon. At least I intend tomorrow to work on 2005 - it's been too long and I really want and need to get to the last years and beyond - and I will have more time than usual. The question is how much energy will I have.

ioccc-src / mkiocccentry

Enhancement: indent JSON using 4 spaces and without any leading TABs #931

Is there an existing issue for this?

Describe the feature

Relevant images, screenshots or other files

Relevant links

Anything else?

UPDATE 0a

UPDATE 0

UPDATE 0a

UPDATE 1

UPDATE 0

UPDATE 1

UPDATE 0

UPDATE 1

UPDATE 0

Quick thought

Quick thought

Quick thought

UPDATE 0

UPDATE 1

UPDATE 0