search

ioccc-src / temp-test-ioccc

Temporary test IOCCC web site that will go away
Creative Commons Attribution Share Alike 4.0 International
42 stars 6 forks source link

Enhancement: hack chkentry(1) to process (validate) .entry.json and author_handle.json files #2614

Closed xexyl closed 3 weeks ago

xexyl commented 1 month ago

Is there an existing issue for this?

Describe the feature

Currently chkentry(1) validates the .info.json and .auth.json files (in two ways: specifying a directory name or the individual files). It has been determined through discussion that the directory name (single arg) form needs to validate instead the .entry.json and the author/Author_Handle.json files. To validate the .info.json and .auth.json files one must use the two arg form. I have done this on a branch but no commits yet.

This issue is to discuss the finer details of this important change.

It might be helpful if you add an addendum to this comment (below this - keeping this in for context) the details you need OR making a comment with the details and then adding a link to that comment in this comment.

Relevant images, screenshots or other files

No response

Relevant links

chkentry(1) can be found in the mkiocccentry repo.

Anything else?

Did you know that a team of astronomers spent four YEARS to determine the indeterminable meaning behind 'life, the universe and everything' only to come up with the same answer that Deep Thought after many years of working on it - only to come up with the nonsensical and meaningLESS value of 42? Indeed it is true. Of course many people seem to also actually believe this was serious (look at google for 'proof that 42 is the answer to life, the universe and everything' - some are quite amusing!) despite the fact that Douglas Adams said flat out on USENET that it was a JOKE.

BTW: did you know that the Earth is Flat ? :-) (to those who miss irony and jokes: obviously the Earth is NOT flat and anyone who believes it is very wrong; indeed if the Earth really was Flat then cats would have pushed everything off it by now - to say nothing else of all the other evidence including the fact that the Soviets would have done ABSOLUTELY ANYTHING to discredit the Americans .. and they did not).

Okay that's enough for now! :-)

UPDATES

See comment 2269551230 for requirements of the changes.

lcn2 commented 1 month ago

Do you have an example where there is a difference for a NAMED member? And what are the unnamed members if you have an example?

Sorry (tm Canada 🇨🇦), we do not know what a "NAMED member" is, let alone what difference it might have with something.

xexyl commented 1 month ago

A name variable. The struct has one. In some cases it is NULL and in others it's a string like affiliation.

lcn2 commented 1 month ago

Hmm .. would having an identifier for the different tables be something to consider instead of having to patch files?

Hmm .. sure? But perhaps a higher level question needs to be consider instead.

While one can generate a table for a given JSON file using jparse/jsemtblgen:

jsemtblgen 2020/endoh1/.entry.json

other semantically valid .entry.json files may have difference counts, such as:

jsemtblgen 1984/anonymous/.entry.json

How can you find the range of something? We hacked together what we thought of as a "bare minimum" JSON file for some types of JSON files. For example, for the .info.json case:

jsemtblgen test_ioccc/test_JSON/info.json/good/info.min-manifest.json

With the assumption that other somatically valid .info.json files would have counts that are >= the count for the "good minimum case".

QUESTION

Are jsemtblgen generated tables the wrong approach?

Perhaps jsemtblgen generated tables is the WRONG approach.

What is needed, so to detect that those required JSON items be present, that they have the requires types, and that one is able to determine if the number of a given JSON item is OK or not.

Take the .info.json case. Let us look at a few examples of requirements:

We MUST have 1 and only 1 "empty_override" JSON member name AND that the JSON member value MUST be a boolean (true or false), AND that the "empty_override" JSON member name/value pair be under the root of the JSON file.

We MUST have 1 and only 1 "formed_timestamp" JSON member name AND that the JSON member value MUST be an integer, AND that the "formed_timestamp" JSON member name/value pair be under the root of the JSON file.

We must have 1 and only 1 "c_src" JSON member name, AND that the JSON member value MUST be a string, AND that "c_src" JSON member MUST be under a JSON array, AND that JSON array be a JSON member value associated with the JSON member name "manifest", AND that the JSON member name/value pair be under the root of the JSON file.

We may have 0 or more "extra_file" JSON member names, AND AND that the JSON member value MUST be a string, AND that "extra_file" JSON member MUST be under a JSON array, AND that JSON array be a JSON member value associated with the JSON member name "manifest", AND that the JSON member name/value pair be under the root of the JSON file.

etc.

All of the above requirements are BEFORE one calls upon validation functions such as chk_empty_override, chk_formed_timestamp, chk_c_src, chk_extra_file, etc.

Is there a BETTER way to verify what we call the semantics of a given type of JSON file?

lcn2 commented 1 month ago

Problem

It is rather difficult to look for questions within a long comment, then guess if something with a "?" is a question that needs to be answered or is later on rendered not important (because perhaps you found the answer, or you decided it was not important, or you were just pondering something out loud, or) and then to try and determine the context for the question, and the try to reply to the question.

Suggestion

When you find something you need to ask, put a ## Question header followed by an explicit question.

Possible Answer to a previous question

We think in GH-issuecomment-2271322924 you asked a question you wish us to answer.

We will now try to quote the relevant text below:

Ah, here. But it's not a member with a name.

{ 5, JTYPE_STRING,   1,      104,    104,    1,      0,      NULL,   NULL },

is changed to:

  { 5,  JTYPE_STRING,   15,     104,    104,    1,      0,      NULL,   NULL },

which means the min is 15, not 1.

The min is minimum allowed count (I guess that AT LEAST that many are required?) but since it's not named I'm not sure what it indicates.

Do you have an example where there is a difference for a NAMED member? And what are the unnamed members if you have an example?

OK, now we will make a guess that NAMED member might relate, given GH-issuecomment-2272396477, to the struct json_sem in jparse/json_sem.h there are 3 structs with an element of "name" so we are guessing here.

So now we will make a guess that "where there is a difference" might be asking about something where min had to be changed. But that question followed an example that you provided where the min was changed from 1 to 15, so perhaps the string:

Do you have an example where there is a difference for a NAMED member?

is not a question since you seemed you have provided an example above it

Maybe the real question lies in the that that immediately follows:

And what are the unnamed members if you have an example?

Here we will guess that (assuming our guess of name related to the struct json_sem in jparse/json_sem.h) "unnamed members" might refer to some (struct json_sem *)p->name is NULL.

Well the patch file soup/chk.info.ptch.c shows as the first difference:

--- ref/info.reference.json.c   2024-05-19 00:08:13
+++ chk_sem_info.c      2024-05-18 23:59:02
@@ -39,17 +39,17 @@

 struct json_sem sem_info[SEM_INFO_LEN+1] = {
 /* depth    type        min     max   count   index  name_len validate  name */
-  { 5, JTYPE_STRING,   1,      84,     84,     0,      0,      NULL,   NULL },
+  { 5, JTYPE_STRING,   10,     84,     84,     0,      0,      NULL,   NULL },

So there is a case where the min value had to change from 1 to 10 for some JSON string that was NOT a JSON member name.

That example is at level 5 of the JSON parse tree (where 0 is the root). Looking a minimal example of a .info.json file we see that at level 5 of the JSON tree we find 5 JSON strings that are NOT JSON member names:

        {"info_JSON" : ".info.json"},
        {"auth_JSON" : ".auth.json"},
        {"c_src" : "prog.c"},
        {"Makefile" : "Makefile"},
        {"remarks" : "remarks.md"}

In particular the 5 JSON member value strings:

  1. ".info.json"
  2. ".auth.json"
  3. "prog.c"
  4. "Makefile"
  5. "remarks.md"

are those 5 JSON strings that are not JSON member names and, if you count the levels, are at the JSON parse tree depth level of 5.

QUESTION

Did we answer your question with the above text?

UPDATE 0

Perhaps the high level question raised in GH-ssuecomment-2272414067 should be addressed first before trying to determine details about the current "jsemtblgen / patch" mechanism that, while it functioned for .info.json and auth.json, might be extended to files such as .entry.json and related author/author_handle.json files.

The need for JSON semantic checking the JSON parse tree for tools that link to jparse/jparse.a. The "jsemtblgen / patch" mechanism may not be a useful want to describe what JSON items should be found at various levels of a JSON parse tree.

Perhaps a better and different approach is needed altogether.

xexyl commented 1 month ago

Problem

It is rather difficult to look for questions within a long comment, then guess if something with a "?" is a question that needs to be answered or is later on rendered not important (because perhaps you found the answer, or you decided it was not important, or you were just pondering something out loud, or) and then to try and determine the context for the question, and the try to reply to the question.

I can see that in a way now. I was trying to hurry up yesterday and that might not have been the best time to do it either.

Suggestion

When you find something you need to ask, put a ## Question header followed by an explicit question.

I do that sometimes but I guess I should do it throughout comments too. Is that something you are getting at? I'll see about doing that more if I can remember (should be able to).

Possible Answer to a previous question

We think in GH-issuecomment-2271322924 you asked a question you wish us to answer.

Given the uncertainty it might be better if I just try writing that comment again. .. after the other issue is resolved. However a few comments below still might be worth making.

OK, now we will make a guess that NAMED member might relate, given GH-issuecomment-2272396477, to the struct json_sem in jparse/json_sem.h there are 3 structs with an element of "name" so we are guessing here.

So now we will make a guess that "where there is a difference" might be asking about something where min had to be changed. But that question followed an example that you provided where the min was changed from 1 to 15, so perhaps the string:

Yup. The need for the patch is indeed one of the things I was talking about.

Do you have an example where there is a difference for a NAMED member?

is not a question since you seemed you have provided an example above it

Actually it was but I no longer know exactly what I was after.

Maybe the real question lies in the that that immediately follows:

And what are the unnamed members if you have an example?

Here we will guess that (assuming our guess of name related to the struct json_sem in jparse/json_sem.h) "unnamed members" might refer to some (struct json_sem *)p->name is NULL.

Yes I meant json_sem and when that variable is NULL. But as we seem to be needing something else I'll not go beyond that.

Well the patch file soup/chk.info.ptch.c shows as the first difference:

--- ref/info.reference.json.c   2024-05-19 00:08:13
+++ chk_sem_info.c      2024-05-18 23:59:02
@@ -39,17 +39,17 @@

 struct json_sem sem_info[SEM_INFO_LEN+1] = {
 /* depth    type        min     max   count   index  name_len validate  name */
-  { 5, JTYPE_STRING,   1,      84,     84,     0,      0,      NULL,   NULL },
+  { 5, JTYPE_STRING,   10,     84,     84,     0,      0,      NULL,   NULL },

So there is a case where the min value had to change from 1 to 10 for some JSON string that was NOT a JSON member name.

Ah .. I might have been too quick. By members I was not referring to JTYPE_MEMBER but simply the fact that that part of the json_sem array had a NULL name. Apologies for the confusion! It seems I made quite a few in haste.

QUESTION

Did we answer your question with the above text?

It's hard to be sure now: I am either not awake yet enough or I am more interested in trying to resolve the other part (next comment I make).; it seems your update below is what needs to be resolved first so it's not as important and perhaps that's the real issue - you do bring up a great point and it should be resolved first (or so I think).

UPDATE 0

Perhaps the high level question raised in GH-ssuecomment-2272414067 should be addressed first before trying to determine details about the current "jsemtblgen / patch" mechanism that, while it functioned for .info.json and auth.json, might be extended to files such as .entry.json and related author/author_handle.json files.

The need for JSON semantic checking the JSON parse tree for tools that link to jparse/jparse.a. The "jsemtblgen / patch" mechanism may not be a useful want to describe what JSON items should be found at various levels of a JSON parse tree.

Perhaps a better and different approach is needed altogether.

I think that might be the way to go yes. Will reply to that comment next.

xexyl commented 1 month ago

Let me see if I can make this clearer this time.

Hmm .. would having an identifier for the different tables be something to consider instead of having to patch files?

Hmm .. sure? But perhaps a higher level question needs to be consider instead.

Maybe. I don't know. I think the two are interconnected somehow but let's see what we get from my reply and your thoughts to it.

While one can generate a table for a given JSON file using jparse/jsemtblgen:

jsemtblgen 2020/endoh1/.entry.json

Aha! Sot that's how you created the original tables! Then you just made the patch file to allow for changes. That makes much more sense now (sure I could have tried it but the scripts that do all that are much more complicated and it was your concept so I did not get too deep into it - though it seems like I might have to now which is okay).

other semantically valid .entry.json files may have difference counts, such as:

jsemtblgen 1984/anonymous/.entry.json

How can you find the range of something? We hacked together what we thought of as a "bare minimum" JSON file for some types of JSON files. For example, for the .info.json case:

jsemtblgen test_ioccc/test_JSON/info.json/good/info.min-manifest.json

With the assumption that other somatically valid .info.json files would have counts that are >= the count for the "good minimum case".

Right. And for those that might not have the 'start' value (my wording, good or bad I do not know) we have the patch system that creates the actual tables. That's why I was thinking it might be useful to have an identifier of which file rather than having to have a complex system in place which might also mandate manually editing the patch file. If we have the name of the file type then we could just make slight modifications if necessary (maybe even using the above tool as a starting point - that's why I wonder if the two are interconnected btw).

QUESTION

Are jsemtblgen generated tables the wrong approach?

Perhaps jsemtblgen generated tables is the WRONG approach.

What is needed, so to detect that those required JSON items be present, that they have the requires types, and that one is able to determine if the number of a given JSON item is OK or not.

Hmm yes. That's true. The benefit for the way it is now (not counting the patch complexities) is that it can be programmatically done as in not have to check name specifically. For if we did that we could just check names and then verify that the values are in the correct range (or if it cannot be a range then it is a specific value - etc.).

The latter would mean we would have to put in more code but it would be easier to do (in some ways - it might be harder to do in other ways though). The question is is it worth that. It might be better to come up with an entirely different system. I do confess that (now I think on it) even with an identifier for the semantics tables it does seem like a lot of work that one would have to do to get working. But then again so would manually writing code that valises the file based on the requirements of the file. At the bare minimum they would have to use the tool you refer to and then work on a patch system. But of course they would have to do that in either case here so perhaps it's not much different in the end.

Put another way, the programming specific checks (which would be complicated in other ways since more - perhaps much more - code would have to be added) and the semantics tables are both complex so maybe indeed something else could be devised: the question of course is what is that thing?

Take the .info.json case. Let us look at a few examples of requirements:

We MUST have 1 and only 1 "empty_override" JSON member name AND that the JSON member value MUST be a boolean (true or false), AND that the "empty_override" JSON member name/value pair be under the root of the JSON file.

We MUST have 1 and only 1 "formed_timestamp" JSON member name AND that the JSON member value MUST be an integer, AND that the "formed_timestamp" JSON member name/value pair be under the root of the JSON file.

We must have 1 and only 1 "c_src" JSON member name, AND that the JSON member value MUST be a string, AND that "c_src" JSON member MUST be under a JSON array, AND that JSON array be a JSON member value associated with the JSON member name "manifest", AND that the JSON member name/value pair be under the root of the JSON file.

We may have 0 or more "extra_file" JSON member names, AND AND that the JSON member value MUST be a string, AND that "extra_file" JSON member MUST be under a JSON array, AND that JSON array be a JSON member value associated with the JSON member name "manifest", AND that the JSON member name/value pair be under the root of the JSON file.

etc.

All of the above requirements are BEFORE one calls upon validation functions such as chk_empty_override, chk_formed_timestamp, chk_c_src, chk_extra_file, etc.

Is that how it is now? If it is now do you recall what functions this would be in? Ah .. maybe the object2manifest() function? Let's see ... okay I looked and I do see that (or so I think at this hour).

Is there a BETTER way to verify what we call the semantics of a given type of JSON file?

By this do you refer to the later semantics tables or something else? I presume you mean the semantics tables which is mostly what we are talking about. See below.

...

Of course the first part in object2 functions actually is manually programmed so maybe the above thought about manually adding checks (semantics) is not that much worse to add? On the one hand it would be more work to do INITIALLY but it would be easier to update I think, once it is in place.

What do you think about all the above?

lcn2 commented 1 month ago

What do you think about all the above?

We think that the "## Problem" section of the GH-issuecomment-2272443630 is still a bit of a problem.

Given the "## Suggestion" section of the GH-issuecomment-2272443630 had little effect, we speculate that the above line was the only sentence that was timely in need of answering. 😄 😄 😄

Answer

We will write a new comment with a new suggestion based on the question we raised in GH-issuecomment-2272414067. When we complete our next comment we speculate that we will have provided better content, to move us forward, than if we had responded to all of the direct and implied questions from GH-issuecomment-2273496974.

However for that next comment we are promising above, you will have to wait a bit while we ponder the answer to our question we raised in GH-issuecomment-2272414067.

UPDATE 0

We we are in a hurry to complete bin/cvt-submission.sh so that we can return to working on the submit server, and as this issue is not on the critical path, we will ponder our idea and return later to post the answer to our question.

If we forget to do so in a few days, please remind us, @xexyl. 🤓

xexyl commented 1 month ago

No worries! I should have reconsidered how to write it but was in a hurry (again). I'll look back but probably not until tomorrow.

Best wishes! Have to go again!

xexyl commented 1 month ago

Just reminding you of your comments/thoughts you were going to post. No rush on my behalf as I have some days left of mostly inactivity here but it might be nice to read as I can then ponder things.

xexyl commented 1 month ago

What do you think about all the above?

We think that the "## Problem" section of the GH-issuecomment-2272443630 is still a bit of a problem.

Given the "## Suggestion" section of the GH-issuecomment-2272443630 had little effect, we speculate that the above line was the only sentence that was timely in need of answering. 😄 😄 😄

As for this: not really a problem it's just I have been preoccupied and I was trying to hurry the comment along. Well that and I was too tired to think about it much. I suspect that the next comment will be very helpful though and perhaps we can come up with something much nicer than having to patch files.

lcn2 commented 1 month ago

We have a concept for testing JSON semantics by use of JSON.

We are thinking of how illustrate our idea with a simple tool in the near future, for certain values of near.

xexyl commented 1 month ago

We have a concept for testing JSON semantics by use of JSON.

We are thinking of how illustrate our idea with a simple tool in the near future, for certain values of near.

Sure. I thought that you might have it already and I was going to read something wonderful but I see you have to ponder it more. The idea of using JSON itself reminds me of what I had briefly brought up earlier on but I think it'll be better.

I am waiting on photos to sync from iCloud .. have some things to go through with that. In a short while I'll be afk. I would suspect I won't get anything done today either. Incidentally I am trying to push out how late I stay up so there is potential slowness for this reason too but it is hoped it will improve sleep some (it can and has happened before - though obviously still not perfect - but it can take some getting used to too).

The Olympics unwinding means I can probably take a bit more time each day but I still have lots to watch before they are 'cleared out'. Tomorrow I have a zoom meeting but I might be able to do some before that. I hope so.

Anyway I don't think I'll get anything in today so I bid you a great rest of your weekend! Look forward to seeing wha you come up with here!

xexyl commented 1 month ago

Question for soup/version.h (related to this issue)

I added to soup/version.h in the other repo two macros, ENTRY_VERSION and AUTHOR_VERSION. These match the json files in this repo. Do you want me to commit it there? It would be used when this tool is updated (after your thoughts have been discussed).

lcn2 commented 1 month ago

Question for soup/version.h (related to this issue)

I added to soup/version.h in the other repo two macros, ENTRY_VERSION and AUTHOR_VERSION. These match the json files in this repo. Do you want me to commit it there? It would be used when this tool is updated (after your thoughts have been discussed).

Yes, commit it in that other repo.

xexyl commented 1 month ago

Question for soup/version.h (related to this issue)

I added to soup/version.h in the other repo two macros, ENTRY_VERSION and AUTHOR_VERSION. These match the json files in this repo. Do you want me to commit it there? It would be used when this tool is updated (after your thoughts have been discussed).

Yes, commit it in that other repo.

Can do. Maybe tomorrow as long as I remember. It will eventually be added anyway so I guess it's not that much of a rush for now.

lcn2 commented 1 month ago

In regards to GH-issuecomment-2282227580:

The high level idea is to have add command line option to jparse(1), or more likely to create some new tool that takes valid JSON input an outputs a JSON that is equivalent form but where every JSON value (JSON string, JSON number, JSON boolean, JSON null) will be replaced by a JSON string that we will call a "JSON semantic string". The resulting JSON output from such a tool (or command line option to jparse(1)) would be valid JSON AND the JSON parse tree structure would be identical to the JSON parse tree of the original JSON input, AND where each JSON string be a specially formatted "JSON semantic string" that would help describe the semantics of the original JSON input.

We are woking out the details of the format of those "JSON semantic strings", so expect a later comment describing them.

The "JSON semantic string" output could be modified by a developer of a JSON semantic checking tool (such as chkentry(1)) to indicate that a given JSON value was optional, or that the JSON value could be repeated between some number of times (with a possible min and/or max repeat count). Such modifications could be performed by the developer by hand, or with a patch file. This would make it much easier to update JSON semantic checking code when the original format of the JSON needs to change.

In the generic case, semantic checking code (such as chkentry(1)) would JSON parse both the JSON file in question (such as, say, .entry.json) as well as a JSON semantic reference file (such as, say, sem.entry.json). The result in memory will be two JSON parse trees, one for the JSON in question (such as, say, .info.json) and one for the JSON semantic reference file (such as sem.info.json).

Then by "walking over" both JSON parse trees in memory in parallel, one could use the JSON semantic reference parse tree to examine the parse tree of JSON input the question. We say "walking over" because when one encounters a "JSON semantic string" indicating that the corresponding JSON value is optional or that the corresponding JSON value could be repeated (with a possible min and/or max repeat count), one as to "walk around" the JSON parse tree of the JSON in question (such as the JSON parse tree of .auth.json where the number of authors may vary from 1 to 10) accordingly.

The "JSON semantic string" will also contain an optional reference to a "chk-function" that, when called, will perform various value specific checks (similar to functions found in soup/chk_validate.c). There will be a way for the developer of a JSON semantic checking tool (such as chkentry(1)) to convert string containing the name of a function to an actual C value checking function (similar to functions found in soup/chk_validate.c).

The result of the above architecture will be a more generic way that you and others can check the semantics of any form of JSON.

FYI, More TBD

This is just an FYI for the curious and is not intended to be a complete technical specification.

Please wait as more details relating to the above are developed and modified and deleted and replaced. :-) Please also wait as the specification of the format of the "JSON semantic string" is being developed.

Such detailed info will be posted as comments below. Stay tuned over the next several days. And if you don't see more of the promised above content posted below soon enough (because we may have gotten so busy with work on matters related to GH-issuecomment-2293850933, please remind us after a few days.

xexyl commented 1 month ago

Thanks for the details. I guess you'll have to modify the chkentry(1) tool to do what it does now and then I'll have to merge my changes. Although this might be a bit unfortunate it would allow you to clearly demonstrate your ideas. I will wait on this then and if you don't get back to it in a few days I will try and bring it up.

xexyl commented 1 month ago

QUESTION

Does chkentry(1) need these updates prior to the next IOCCC? I could see how it might be useful but I can also see how it might slow things down esp as there won't be many more entries to inspect: just the next winners. But of course I could also work on it during the judging process (for example). Either way I'll do it when necessary. I would admittedly like to get it done but running the next contest before this if possible would also be great.

xexyl commented 1 month ago

a JSON semitic reference

Oh so THAT'S why JSON specs are so messed up! It's not that it's messed up but it's in languages we don't know - or rather translated by a tool from languages that are quite different, and in some cases ancient languages!

That makes me feel a whole lot better in not following it all! I hope it does for you too.

lcn2 commented 1 month ago

QUESTION

Does chkentry(1) need these updates prior to the next IOCCC? I could see how it might be useful but I can also see how it might slow things down esp as there won't be many more entries to inspect: just the next winners. But of course I could also work on it during the judging process (for example). Either way I'll do it when necessary. I would admittedly like to get it done but running the next contest before this if possible would also be great.

The chkentry(1) updates can wait until after IOCCC28.

xexyl commented 1 month ago

QUESTION

Does chkentry(1) need these updates prior to the next IOCCC? I could see how it might be useful but I can also see how it might slow things down esp as there won't be many more entries to inspect: just the next winners. But of course I could also work on it during the judging process (for example). Either way I'll do it when necessary. I would admittedly like to get it done but running the next contest before this if possible would also be great.

The chkentry(1) updates can wait until after IOCCC28.

That is wonderful.

lcn2 commented 1 month ago

QUESTION

Does chkentry(1) need these updates prior to the next IOCCC? I could see how it might be useful but I can also see how it might slow things down esp as there won't be many more entries to inspect: just the next winners. But of course I could also work on it during the judging process (for example). Either way I'll do it when necessary. I would admittedly like to get it done but running the next contest before this if possible would also be great.

The chkentry(1) updates can wait until after IOCCC28.

That is wonderful.

Working on a python submit server, unfortunately, will not wait.

xexyl commented 1 month ago

QUESTION

Does chkentry(1) need these updates prior to the next IOCCC? I could see how it might be useful but I can also see how it might slow things down esp as there won't be many more entries to inspect: just the next winners. But of course I could also work on it during the judging process (for example). Either way I'll do it when necessary. I would admittedly like to get it done but running the next contest before this if possible would also be great.

The chkentry(1) updates can wait until after IOCCC28.

That is wonderful.

Working on a python submit server, unfortunately, will not wait.

So does that mean that it does have to be updated first, then? I hope not but if necessary it's necessary.

lcn2 commented 1 month ago

QUESTION

Does chkentry(1) need these updates prior to the next IOCCC? I could see how it might be useful but I can also see how it might slow things down esp as there won't be many more entries to inspect: just the next winners. But of course I could also work on it during the judging process (for example). Either way I'll do it when necessary. I would admittedly like to get it done but running the next contest before this if possible would also be great.

The chkentry(1) updates can wait until after IOCCC28.

That is wonderful.

Working on a python submit server, unfortunately, will not wait.

So does that mean that it does have to be updated first, then? I hope not but if necessary it's necessary.

The python submit server will need to be in advanced enough state before the Great Fork Merge in order that screen shots may be added to FAQ(s) related to how to submit to the IOCCC.

The "register for the IOCCC" process will need to be in advanced enough state before the Great Fork Merge in order that screen shots may be added to FAQ(s) related to how to register for the IOCCC.

Before IOCCC28 goes into "pending" state the BETA submit server will need to be up and running so that people may test using the mkiocccentry(1) tool by uploading compressed tarballs to the test submit server.

Before IOCCC28 goes into "pending" state the BETA "register for the IOCCC" process will need to be and running so that people (including the IOCCC judges) may test the submit server workflow.

The "screen sorts" before the * Great Fork Merge AND these BETA registration & BETA submit server take the place of what was once called IOCCCMOCK.

xexyl commented 1 month ago

Ah. Then it's what I thought. You mean the server has to be ready before the merge.

Okay that's good. Sorry you have to work with a snake in the grass though!

xexyl commented 4 weeks ago

Okay I will quickly write the thing that I was thinking of and then go to the other things that I have to do. Tomorrow and Wednesday I'll have more time. About chkentry(1) authorship.

In the comments it says I improved it. True but I also wrote many of the lower level routines. I will also be modifying it to validate .entry.json and author_handle.json files which will necessitate updating that comment (co-developed). That includes foo and other related files too. Now I can wait on that (despite the fact I did write many of the lower level functions - the check functions) until the time to update it with the additions. I leave that up to your thought. But if we're going to do this it might also be good to update the guidelines on this fact (the 'original work' part that is there for iocccsize - for Anthony Howe - and the other tools fur me and also for you and me).

Of course that could also be for the next contest but it does seem SLIGHTLY odd to have it as one way this time and another way the next time. But of course this I also leave to your thoughts.

I have numerous things to do now and I won't be doing more here today. I did make a typo fix in the json wrapper scripts in bin/ though but that's all I can do. Tomorrow and the next day I will have several hours where I can work on things: including on Wednesday (I think it is .. have to check) where it'll be long enough where I probably won't be able to work on it the whole time. Still I hope to make reasonable progress tomorrow and the next day.

In the meantime: have a great day today!

xexyl commented 4 weeks ago

What do you think about the authorship thing?

I have other things I must do now but if I have time to work on 2005 I'll start it today. Well time and energy. It might be that after all I have to do I just want to take it easy. Tomorrow I guess I won't have as many things to do. Part of the delay here today is that I was working on another program (or suite of programs) of mine. Otherwise I probably would be close to being done with the other things I have to do. Anyway hopefully those things won't take too long!

lcn2 commented 4 weeks ago

What do you think about the authorship thing?

We didn't think it was an important issue as we both have our names over much of the code. However if the "authorship thing" bothers you, feel free to propose a change in a separate PR.

xexyl commented 4 weeks ago

What do you think about the authorship thing?

We didn't think it was an important issue as we both have our names over much of the code. However if the "authorship thing" bothers you, feel free to propose a change in a separate PR.

I'm not sure if it does or does not. If it does I will do that when I do the updates as I already have many changes (the first steps). I could do that with the guidelines though. I have other things to do so I can't worry about that now but I'll do it later on - maybe tomorrow if I don't get to it today.

Meanwhile whenever you have a more concrete idea about semantics I'll be happy to discuss it with you. But for now I must go back to the other things I have to do. Might be able to do more here later today. Either way have a good day!

xexyl commented 3 weeks ago

Just took care of the guidelines with another fix.

lcn2 commented 3 weeks ago

QUESTION

Should this issue be moved to the mkiocccentry repo?

xexyl commented 3 weeks ago

QUESTION

Should this issue be moved to the mkiocccentry repo?

I actually wondered about that. The real thing is: can it be moved without losing the comments? If not then perhaps it should stay here even though the tool is in the other repo?

xexyl commented 3 weeks ago

It might be esp useful to remember all the discussion about semantics. To lose that would be a shame and problematic I think.

lcn2 commented 3 weeks ago

QUESTION

Even though this issue will not be resolved until after IOCCC28, it may be best to change chkentry(1) NOW do throw an error if given only one argument. This would clear the way for the future of this issue when given a single arg means to process an entry instead of a submission.

We think this (throw an error if given only one argument) needs to be done before the pending next release of the mkiocccentry repo.

xexyl commented 3 weeks ago

QUESTION

Even though this issue will not be resolved until after IOCCC28, it may be best to change chkentry(1) NOW do throw an error if given only one argument. This would clear the way for the future of this issue when given a single arg means to process an entry instead of a submission.

We think this (throw an error if given only one argument) needs to be done before the pending next release of the mkiocccentry repo.

I have a number of changes like it already starting to parse the other files (or at least find the files based on the arg). That being said I can make a copy and then edit it to reject one arg only. After that is merged I can then pull and replace it with what I already wrote.

I can do this tomorrow if you wish? If I don't get to it please remind me!

lcn2 commented 3 weeks ago

QUESTION

Should this issue be moved to the mkiocccentry repo?

I actually wondered about that. The real thing is: can it be moved without losing the comments? If not then perhaps it should stay here even though the tool is in the other repo?

The comments do not disappear when an issue is closed. Moreover, the more important comments:

Can be duplicated (with a link back to the original post) onto the new issue in the mkiocccentry repo.

We would be willing to do such a creat(2) 🤓 and copy.

xexyl commented 3 weeks ago

QUESTION

Should this issue be moved to the mkiocccentry repo?

I actually wondered about that. The real thing is: can it be moved without losing the comments? If not then perhaps it should stay here even though the tool is in the other repo?

The comments do not disappear when an issue is closed. Moreover, the more important comments:

Can be duplicated (with a link back to the original post) onto the new issue in the mkiocccentry repo.

We would be willing to do such a creat(2) 🤓 and copy.

They aren't removed, no, but ... well I guess if you want to copy them. I don't know. It seems like the issue could also belong here since it's about files in this repo. But how will you copy the comments I made? As in how will they be displayed and can you do that in the order? If you replied to each one I guess you could add a > (or however many) to what I replied to but what if there was no reply?

Well I'll let you figure it out as I have other things I have to do and it's something you are pondering anyway so not something I can do.

lcn2 commented 3 weeks ago

They aren't removed, no, but ... well I guess if you want to copy them. I don't know. It seems like the issue could also belong here since it's about files in this repo. But how will you copy the comments I made? As in how will they be displayed and can you do that in the order? If you replied to each one I guess you could add a > (or however many) to what I replied to but what if there was no reply?

If you want every comment to be duplicated, we can. We were proposing the text of the main comments be copied with a link to the original at the top of the copied comment so that one may jump back and see it in context.

lcn2 commented 3 weeks ago

While the files chkentry(1) will use are in this repo, all of the code that needs to be modified is in the mkiocccentry repo. All of the work will need to be performed in the mkiocccentry repo. All of the PR to perform any actions will be in the mkiocccentry repo.

xexyl commented 3 weeks ago

They aren't removed, no, but ... well I guess if you want to copy them. I don't know. It seems like the issue could also belong here since it's about files in this repo. But how will you copy the comments I made? As in how will they be displayed and can you do that in the order? If you replied to each one I guess you could add a > (or however many) to what I replied to but what if there was no reply?

If you want every comment to be duplicated, we can. We were proposing the text of the main comments be copied with a link to the original at the top of the copied comment so that one may jump back and see it in context.

It would be helpful if at least the comments of importance are duplicated but the rest might be put in the top comment too?

Thanks.

xexyl commented 3 weeks ago

While the files chkentry(1) will use are in this repo, all of the code that needs to be modified is in the mkiocccentry repo. All of the work will need to be performed in the mkiocccentry repo. All of the PR to perform any actions will be in the mkiocccentry repo.

That's true .. and why I wondered as well.

lcn2 commented 3 weeks ago

It would be helpful if at least the comments of importance are duplicated but the rest might be put in the top comment too?

What does that mean?

xexyl commented 3 weeks ago

It would be helpful if at least the comments of importance are duplicated but the rest might be put in the top comment too?

What does that mean?

I wondered about that. Sorry. I mean those that were discussing fine details like the semantics as well as what is required of the changes.

lcn2 commented 3 weeks ago

QUESTION

Even though this issue will not be resolved until after IOCCC28, it may be best to change chkentry(1) NOW do throw an error if given only one argument. This would clear the way for the future of this issue when given a single arg means to process an entry instead of a submission. We think this (throw an error if given only one argument) needs to be done before the pending next release of the mkiocccentry repo.

I have a number of changes like it already starting to parse the other files (or at least find the files based on the arg). That being said I can make a copy and then edit it to reject one arg only. After that is merged I can then pull and replace it with what I already wrote.

I can do this tomorrow if you wish? If I don't get to it please remind me!

Performed on that other repo with commit 7a3907c9adc61d9cb1ebeabd587da2adb50bcd4e.

xexyl commented 3 weeks ago

QUESTION

Even though this issue will not be resolved until after IOCCC28, it may be best to change chkentry(1) NOW do throw an error if given only one argument. This would clear the way for the future of this issue when given a single arg means to process an entry instead of a submission. We think this (throw an error if given only one argument) needs to be done before the pending next release of the mkiocccentry repo.

I have a number of changes like it already starting to parse the other files (or at least find the files based on the arg). That being said I can make a copy and then edit it to reject one arg only. After that is merged I can then pull and replace it with what I already wrote. I can do this tomorrow if you wish? If I don't get to it please remind me!

Performed on that other repo with commit 7a3907c9adc61d9cb1ebeabd587da2adb50bcd4e.

That's extremely unfortunate as it will conflict with what I have already done.

xexyl commented 3 weeks ago

And using git stash and git stash pop caused a merge conflict too :(

xexyl commented 3 weeks ago

.. and resolving them means I no longer see any diff in git diff :(

... which is extremely helpful to me esp as I no longer know what's even correct for the changes in the future.

lcn2 commented 3 weeks ago

We have "cloned" this enhancement request into issue #940 in the mkiocccentry repo.

lcn2 commented 3 weeks ago

.. and resolving them means I no longer see any diff in git diff :(

... which is extremely helpful to me esp as I no longer know what's even correct for the changes in the future.

We didn't mean to create this negative impact on your coding efforts.

We can revert the change .. or we could revert and then edit just make a change to chkentry.c before the next release.

We could just roll back the entire commit and let you make the change to chkentry.c.

Let us know if and how we can help.

xexyl commented 3 weeks ago

.. and resolving them means I no longer see any diff in git diff :( ... which is extremely helpful to me esp as I no longer know what's even correct for the changes in the future.

We didn't mean to create this negative impact on your coding efforts.

We can revert the change .. or we could revert and then edit just make a change to chkentry.c before the next release.

We could just roll back the entire commit and let you make the change to chkentry.c.

Let us know if and how we can help.

First of all I apologise for the delay. I had already shut down the laptop.

Second of all please DO make the new release. It occurred to me before I went to bed I can likely do git restore --staged chkentry.c to show the diff and that is indeed the case.

THANK YOU for offering to help here! I really appreciate it. All good.

I am going to look at the CSS change we discussed and after that I have to do some things I have not got to in some days. I hope after that to look at 2005 (hopefully finish it depending on how long it takes to do the other things). At 1400 hours or so I should have a bit of extra time too so depending on how I feel I might get more done then too.

Anyway thank you again and please do make a new release! All is good here. Hope you had a great sleep! I have been sleeping in more finally which is nice although sleep is still rough. I feel mostly okay today energy wise (a bit sleepy but not too bad as long as I have the fan on).