Enhancement: create the chkentry tool

[xexyl]

We can discuss the details here. If you've not responded to the question on . in the other thread before I get a chance to (too tired right now) I will copy and paste my reply here to discuss it here. Otherwise I'll move my reply to your new reply here.

Please add the tags you want and also assign it to me. You can then close the other issues and refer to this one here as you suggested.

I don't know when I can start working on this but the first part will be writing main() and a sanity check function. This most likely will not happen today I'm afraid. Not even sure if I'll get anything done today here. I'm hoping I can get some rest soon but last time I tried earlier this morning I couldn't.

Later on I will wake up more but whether I do more here is yet to be seen. Anyway we can now discuss the new tool here which should also help remove some clutter elsewhere (or prevent further clutter I guess).

[lcn2]

Run into a problem I did not think of before... If the strings are encoded in rot13 what to do about newlines? It would change it to \a which of course is a beep. But if it's a static const char table we can't modify the table so we have to iterate over each char and print out the real value - which poses a problem for escape chars.

Any suggestions? Another possible way I suppose is to have them in a file and read into a dynamic array. Another thought is have .. Ah. Maybe this will work. Have a special char that means \n. I'll do that so when you see it you'll know what I mean. Let's say for now it'll be a '#' as I don't imagine many quotes will have that and it's not part of rot13. If necessary we can change it to something else that's not rot13 encoded and which isn't in any quotes.

If you are dealing with the single octet \n (i.e., 0x0a) then ROT13 won't rotate it.

If you are dealing with the 2 octet sub-string "\\n" (i.e., 0x5c 0x6e) then then ROT13 will rotate it into "\\a" for the encoded string, and then rotate it back to "\\n" (i.e., 0x5c 0x6e) when it comes time to process it.

We suspect that you will simple have NUL terminated strings the are ROT13 as in:

...
"Guvf vf na EBG13 fgevat\n"
"gung unf gjb arjyvarf\n"

[lcn2]

You should have an email. If the format does not work please let me know (format of the email - comments interspersed in the diff). If you wish to discuss it here that's fine too. If for some reason the mail did not reach you please let me know and I'll try again (or do it here). I didn't want to give too much away here which is why I chose to do it over email.

Looks good.

[xexyl]

Run into a problem I did not think of before... If the strings are encoded in rot13 what to do about newlines? It would change it to \a which of course is a beep. But if it's a static const char table we can't modify the table so we have to iterate over each char and print out the real value - which poses a problem for escape chars. Any suggestions? Another possible way I suppose is to have them in a file and read into a dynamic array. Another thought is have .. Ah. Maybe this will work. Have a special char that means \n. I'll do that so when you see it you'll know what I mean. Let's say for now it'll be a '#' as I don't imagine many quotes will have that and it's not part of rot13. If necessary we can change it to something else that's not rot13 encoded and which isn't in any quotes.

If you are dealing with the single octet \n (i.e., 0x0a) then ROT13 won't rotate it.

If you are dealing with the 2 octet sub-string "\\n" (i.e., 0x5c 0x6e) then then ROT13 will rotate it into "\\a" for the encoded string, and then rotate it back to "\\n" (i.e., 0x5c 0x6e) when it comes time to process it.

Yep. But of course this won't be printed as a C \n. I have an idea how to solve it better though. Just modify the loop so that if it sees a \ it will look at the next char. If it's a C escape sequence print it and then update the pointer by one so that when the next char is read (which means the pointer is updated again) it will be the next char.

We suspect that you will simple have NUL terminated strings the are ROT13 as in:

...
"Guvf vf na EBG13 fgevat\n"
"gung unf gjb arjyvarf\n"

That's correct though as above it was # for \n to simplify it (it was a very quickly done bit of code). I'll look at adding the fix above but how easy it'll be depends on how awake I am. Been awake too long given the hour but I hope to manage this and a few other things. I have another improvement that I think will help clean up the repo root directory as well. This is because I am thinking it might be useful to be able to generate the strings (locally but if it turns out it'll be useful to allow for people to add strings I can make it possible to do so). Well you'll see what I mean if it all goes as I am thinking.

I see you did some other changes. I haven't really read the log yet. I hope you're having a nice sleep my friend (I wish I was sleeping!).

EDIT:

Actually this idea might not work either since it'll be rot13 encoded. I think I'll have to do a translation first before this can work. I also have to make some changes to the generator (which is a local file) though that shouldn't be a problem.

[xexyl]

You should have an email. If the format does not work please let me know (format of the email - comments interspersed in the diff). If you wish to discuss it here that's fine too. If for some reason the mail did not reach you please let me know and I'll try again (or do it here). I didn't want to give too much away here which is why I chose to do it over email.

Looks good.

Thank you! I have a few minor improvements but since you already know what it looks like (and what it means) you'll see the improvements when they're in and it should be obvious right away.

[xexyl]

I just finished for the day at least adding some of the strings. However I think that the strings and maybe the functions should be split to another file (maybe header and source). The function name is (as I explained in the email what it means) Bfgrerv. There's a reason it's capitalised and it should stay that way.

The question is what should the file be called? It could be that. But it could be something else. What do you think? The chkentry.h file will have to include the header file. I could move the function to the source file as well and link it in.

I had the thought to make a custom Makefile rule or script that adds to it (i.e. make it easy to concatenate to it though that might be a problem with finding line breaks - but if it's in its own file that might not matter so much). For now I'm doing this manually with a custom rot13 program I wrote. It's like the usual rot13 but it passes '\n' as a "\\n" which the rot13 function also interprets properly. But if it was made where it could be concatenated to you could have some fun with it too.

For now though this will suffice. I'm going to do something else now. Hope you have a good day!

[lcn2]

The question is what should the file be called? It could be that. But it could be something else. What do you think? The chkentry.h file will have to include the header file. I could move the function to the source file as well and link it in.

UPDATE 0:

See commit 2bcc25cfce179f8d0ec68c5f3e96d4896e05c883

[lcn2]

no comment :-)

UPDATE 0a

See commit d41ba066cb5e764aee09c483b09cea2b41cc27a9

[lcn2]

We invite you add lots of comments throughout the Bfgrerv() function that appear at first glance to explain some sort of algorithm / appear to document what the function might or might not be doing.

UPDATE 0

See commit 15b06c4d31d902ad621c2e42188ee4455035d02e

We invite you add lots of comments throughout the foo.c file.

UPDATE 1c

See commit 0ef74b814ad3eefae9e8cc128954a97236639742

... returning to semantic error checking code now. Thanks for the foo @xexyl :-)

[xexyl]

The question is what should the file be called? It could be that. But it could be something else. What do you think? The chkentry.h file will have to include the header file. I could move the function to the source file as well and link it in.

UPDATE 0:

See commit 2bcc25c

no comment :-)

UPDATE 0a

See commit d41ba06

We invite you add lots of comments throughout the Bfgrerv() function that appear at first glance to explain some sort of algorithm / appear to document what the function might or might not be doing.

UPDATE 0

See commit 15b06c4

We invite you add lots of comments throughout the foo.c file.

UPDATE 1c

See commit 0ef74b8

... returning to semantic error checking code now. Thanks for the foo @xexyl :-)

LOL. Thanks for the log messages and the idea of foo! They're all brilliant.

As for the comments comment I agree that adding comments to the already existing comments is a great idea. Thank you for that! I'll look at it soon I hope - once I'm awake enough. I'll also maybe look at a way for you to add to it - unless you don't think you'd want to? Even so it might be nice if I make the rot13c program available for all - though after some clean up and additional features.

Hope you're having a nice sleep my friend! I'm hoping I can go back to sleep in a bit as well but I figured since I'm not sleeping (even though lying down in the dark) I will sit up with the light and work at the laptop for a bit first.

UPDATE 0:

I also love the following that you added:

 * returns:
 *      "No it doesn't"!

r = 2*3*337;
/*..*/
r = tm->tm_year + 2*2*5*5*19;
/*..*/
    idx = (r*2*2*13 + (int)(i / 7)) % max;

I also like how you changed the parameter names. Good call.

I'm not sure the significance of the magic number 314159265. I wondered if that was the seconds since the UNIX epoch but of course it's not:

$ date +%s
1659347630

Mind elaborating? Since it only matters in the case of time(NULL) returning (time_t)-1 I'm not sure it matters saying? Ah, maybe because it's the default time you set up so it just sets it back to the time to use. That has to be it. Even so why that number?

These are fun too:

    sleep(1+(((i+r)>0?(i+r):(-r-i))%5));
    exit(1+(((i-r)>0?(i-r):(-i+r)) % 254)); /*ooo*/

Though I'm not sure why the need to sleep :) Well okay I need to sleep but I'm not sure why the program will sleep!. :-)

Now as far as the array the one thing with it being in foo.c is it will make it hard to automatically update the array. Can you think of a good way to do this even? If I were to provide you with the program I wrote to do the conversion (with the proper C escape codes) would you like to add to the table too?

Hopefully I can add comments a bit later but I'm not sure. I'm pretty tired and I'm hoping I can go back to sleep soon.

EDIT 0:

Oh I see now you changed the algorithm a bit as well. I like how you did that. Well I'm going to try sleeping again now. Hope you're having a good sleep too!

[xexyl]

no comment :-)

UPDATE 0a

See commit d41ba06

As for this one you originally had that it should remove the -D and -Y. The reason I did this just so you know is that I could see the messages. I unfortunately did not have all them saved in a file. Of course there is another way to obtain them. But that does bring up a point:

And perhaps the most important reason is that if someone wants to completly spoil their daily egg 🍳 breakfast, you might as well make them work for it. :-)

Is this a daily thing then? It appeared to not be: when I added a string for example it changed the message that was printed. Then if I added another one it changed it again. Or would it be that this happens but then the next day it would print something new? (I've still not even attempted to work out the logic in the index calculation btw.)

But your other points are fair and this one is too I suppose. Thanks for going ahead and doing it. If you could just answer the 'daily' question that'd be good. I'm just not sure though: if I add a message and it does change the current message (for that day) won't that mean the person will have to do it every day (once they discover the details of how) to find the new messages?

EDIT 0:

Though I do see there's still a way to change it for now. I like the way it's done - again for now - but still curious about the daily part. Going to try sleeping again soon. I hope to add comments in the coming days - hopefully some today though that's not certain.

[xexyl]

I'm not sure the significance of the magic number 314159265. I wondered if that was the seconds since the UNIX epoch but of course it's not:

In my sleepy eyes I just realised what it is. It's the first digits of pi of course. Not sure how I managed that now and not yesterday but at least I know now.

[xexyl]

It appears that 7c428821db8df0514c4d4fbd3f56a23df99e7228 broke compilation:

cc -D_DEFAULT_SOURCE -D_ISOC99_SOURCE -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=600 -std=gnu11 -O0 -g -pedantic -Wall -Wextra -Werror -Wno-unused-command-line-argument -Wno-poison-system-directories -Wno-unreachable-code-break -Wno-padded -ferror-limit=0 -lm chk_validate.c -c
chk_validate.c:743:15: error: implicit declaration of function 'member_value_bool' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    boolean = member_value_bool(node, depth, sem, __func__, val_err);
              ^
chk_validate.c:743:15: note: did you mean 'sem_member_value_bool'?
./json_sem.h:127:14: note: 'sem_member_value_bool' declared here
extern bool *sem_member_value_bool(struct json *node, unsigned int depth, struct json_sem *sem,
             ^
chk_validate.c:743:13: error: incompatible integer to pointer conversion assigning to 'bool *' from 'int' [-Werror,-Wint-conversion]
    boolean = member_value_bool(node, depth, sem, __func__, val_err);
            ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
chk_validate.c:794:15: error: implicit declaration of function 'member_value_bool' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    boolean = member_value_bool(node, depth, sem, __func__, val_err);
              ^
chk_validate.c:794:13: error: incompatible integer to pointer conversion assigning to 'bool *' from 'int' [-Werror,-Wint-conversion]
    boolean = member_value_bool(node, depth, sem, __func__, val_err);
            ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
chk_validate.c:845:15: error: implicit declaration of function 'member_value_bool' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    boolean = member_value_bool(node, depth, sem, __func__, val_err);
              ^
chk_validate.c:845:13: error: incompatible integer to pointer conversion assigning to 'bool *' from 'int' [-Werror,-Wint-conversion]
    boolean = member_value_bool(node, depth, sem, __func__, val_err);
            ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[...]
27 errors generated.
make: *** [chk_validate.o] Error 1

To make any commits until this is resolved I'll just do specific make invocations. Right now not sure what I'll get in but I'm hoping to go back to sleep soon. I do have some additions to add to foo later on but I'm too tired to do even that now. Hope you're having a nice sleep. Would you let me know when this is resolved if you have the moment and think about it? I would resolve it but as you suggested I stay away from that file I will do so.

EDIT:

Actually I can't even do make chkentry because it of course links that file in. I have a possible workaround but I'll worry about that when I go for any changes.

UPDATE 0:

I see the function is a typo. member_value_bool should actually be sem_member_value_bool. I will fix this. I'll then look at the other issues. If it looks okay I'll do a commit but if necessary you can skip that commit. But this way it will compile and it might save you the effort of doing so.

UPDATE 1:

See https://github.com/ioccc-src/mkiocccentry/pull/299/commits/1ff3c0a94deacceb0d2df79d10b7e8b637d7bd67.

[xexyl]

Hmm ... week of the year? In that case we would be limited in the number of messages. Month would be even a tighter limit.

But I guess you mean use time(3) and extract the week or month and use it as an index to the table? If that's not it what do you have in mind? And what about if we want to add more strings?

Perhaps given a table of M messages, compute year*52 + int(day of year / 7) and use that value, mod M, to index into the table?

Not thinking this out so maybe it should be obvious and it's not. Would this allow for any number of messages? If so that would work. At a very quick thought it would allow this. Is that right?

Yes, for M > 0.

I wanted to bring this up again because this calculation is flawed but I'm not sure what should be done instead. How is it flawed?

Well changing the day a number of times (specifying it at the command line) will rotate through the messages but does not go through them all. Now that might be because of some other part of the calculation ... but if I add a few quotes it'll change it back to a quote that was recently shown. Is this how it should be i.e. is that what you had in mind? The way I envisioned it: every N days it would show a new message so that one can cycle through the list - but then at the end it would go back to the beginning should there be not enough messages (like now there's not enough for a year for example).

What did you think it should be? The reason I think above might be nice is so that people can see more of the messages and have fun with them.

[lcn2]

Hmm ... week of the year? In that case we would be limited in the number of messages. Month would be even a tighter limit.

But I guess you mean use time(3) and extract the week or month and use it as an index to the table? If that's not it what do you have in mind? And what about if we want to add more strings?

Perhaps given a table of M messages, compute year*52 + int(day of year / 7) and use that value, mod M, to index into the table?

Not thinking this out so maybe it should be obvious and it's not. Would this allow for any number of messages? If so that would work. At a very quick thought it would allow this. Is that right?

Yes, for M > 0.

I wanted to bring this up again because this calculation is flawed but I'm not sure what should be done instead. How is it flawed?

Well changing the day a number of times (specifying it at the command line) will rotate through the messages but does not go through them all. Now that might be because of some other part of the calculation ... but if I add a few quotes it'll change it back to a quote that was recently shown. Is this how it should be i.e. is that what you had in mind? The way I envisioned it: every N days it would show a new message so that one can cycle through the list - but then at the end it would go back to the beginning should there be not enough messages (like now there's not enough for a year for example).

What did you think it should be? The reason I think above might be nice is so that people can see more of the messages and have fun with them.

Given that r is the year and i is the day of the year, and max is the oebxergfB table length:

(r*52 + i/7) % max

The above expression will take on all index values of the oebxergfB table over time. Every 7 days, the index will move tp the next oebxergfB table entry until it reaches the end in which case it will start all over again.

For the time being (before chkentry is modified to remove this debugging code), we can set r and i as follows:

r=1
i=224
$ ./chkentry $i $r .

This general expression seems to work:

$ ./chkentry 0 0 .
_stuff_

$ ./chkentry 1 0 .
_same stuff_

$ ./chkentry 2 0 .
_same stuff_

...

$ ./chkentry 6 0 .
_same stuff_

$ ./chkentry 7 0 .
_new stuff_

So the output changes after 7 days.

As of this comment, table is was 84 element long (not including the final NULL), so after 84*7 = 588 days, the table should wrap. This appears to be the case:

$ ./chkentry 587 0 .
_84th stuff_

$ ./chkentry 223 1 .
_also 84th stuff, just showing the year arg works_

$ ./chkentry 588 0 3
_same stuff as 1st stuff_

$ ./chkentry 224 1 .
_also same stuff as 1st stuff, just showing the year arg works_

We need to focus on other code and let you decide what to do here, if anything. But as far as we can still, foo works as intended. If that isn't what you intended to happen, feel free to change foo.c. :-)

[xexyl]

Hmm ... week of the year? In that case we would be limited in the number of messages. Month would be even a tighter limit.

But I guess you mean use time(3) and extract the week or month and use it as an index to the table? If that's not it what do you have in mind? And what about if we want to add more strings?

Perhaps given a table of M messages, compute year*52 + int(day of year / 7) and use that value, mod M, to index into the table?

Not thinking this out so maybe it should be obvious and it's not. Would this allow for any number of messages? If so that would work. At a very quick thought it would allow this. Is that right?

Yes, for M > 0.

I wanted to bring this up again because this calculation is flawed but I'm not sure what should be done instead. How is it flawed? Well changing the day a number of times (specifying it at the command line) will rotate through the messages but does not go through them all. Now that might be because of some other part of the calculation ... but if I add a few quotes it'll change it back to a quote that was recently shown. Is this how it should be i.e. is that what you had in mind? The way I envisioned it: every N days it would show a new message so that one can cycle through the list - but then at the end it would go back to the beginning should there be not enough messages (like now there's not enough for a year for example). What did you think it should be? The reason I think above might be nice is so that people can see more of the messages and have fun with them.

Given that r is the year and i is the day of the year, and max is the oebxergfB table length:

(r*52 + i/7) % max

The above expression will take on all index values of the oebxergfB table over time. Every 7 days, the index will move tp the next oebxergfB table entry until it reaches the end in which case it will start all over again.

For the time being (before chkentry is modified to remove this debugging code), we can set r and i as follows:

r=1
i=224
$ ./chkentry $i $r .

This general expression seems to work:

$ ./chkentry 0 0 .
_stuff_

$ ./chkentry 1 0 .
_same stuff_

$ ./chkentry 2 0 .
_same stuff_

...

$ ./chkentry 6 0 .
_same stuff_

$ ./chkentry 7 0 .
_new stuff_

So the output changes after 7 days.

As of this comment, table is was 84 element long (not including the final NULL), so after 84*7 = 588 days, the table should wrap. This appears to be the case:

$ ./chkentry 587 0 .
_84th stuff_

$ ./chkentry 223 1 .
_also 84th stuff, just showing the year arg works_

$ ./chkentry 588 0 3
_same stuff as 1st stuff_

$ ./chkentry 224 1 .
_also same stuff as 1st stuff, just showing the year arg works_

We need to focus on other code and let you decide what to do here, if anything. But as far as we can still, foo works as intended. If that isn't what you intended to happen, feel free to change foo.c. :-)

No. That's fine. it could also be that it happens because I've been adding more strings. It might be once that I'm done with that it will stop doing that. I've actually suspected this or had a suspicion of this. I'll wait on it. I like your ideas though and seeing your example output is maybe of value. Thanks.

BTW: You did read what I added yesterday, right?

[xexyl]

As far as my tool goes. I did make progress as I noted in the other thread but I remembered this thread which is actually where it probably belongs.

I just wanted to say that although I've made progress on it I don't think it's ready for sending it yet because I'm aware of a few problems / things that have to be worked out. At the simplest level - doing a simple text file with one entry it's fine.

But I added some code that is meant to allow for more than one entry (previously I did manual editing during this) but some things have to be worked out - not correct output in other words (probably the best example is if two end of string markers are found in a row it results in invalid output for C but there are other problems as well).

Unfortunately last night was pretty rough so I don't think I'm going to do anything more on it today. I hope that tonight will be better and I can do more tomorrow on the tool and other things as well. I have a zoom meeting but other than that today is going to be a take it easy kind of day I think.

If however you would like a current version so you can at least add strings or see what strings were added please let me know and I'd be happy to send it your way with the caveat that it's kind of messy right now.

[lcn2]

No worries @xexyl , hope you get some much needed rest.

There is a compile issue that we ran into where the Centos 7 legacy defines are creating a problem. A commit is coming with details, along with a new issue that we need you to address.

Stay tuned.

[xexyl]

No worries @xexyl , hope you get some much needed rest.

I didn't but I did add some quotes a bit ago - one in particular I am sure you'll enjoy (though the others too I'm sure)! I will be leaving for the day soon.

There is a compile issue that we ran into where the Centos 7 legacy defines are creating a problem. A commit is coming with details, along with a new issue that we need you to address.

Interesting. I'm sure I can help though it might not be until tomorrow as I'll be leaving soon most likely. If you can maybe let me know here as well as mention me in the new issue that would be of help. I imagine you'll mention the system and conditions but just in case not that would be helpful.

Stay tuned.

Sure.

[lcn2]

We are now forming the new Enhancement issue, as the problems uncovered by commit f85ec5ac7673281b9b2035de752f6df9be207902 should be discussed in that new issue.

[xexyl]

We are now forming the new Enhancement issue, as the problems uncovered by commit f85ec5a should be discussed in that new issue.

Just pulled under CentOS and I do see some compiler issues. I'll see if I can get it to compile as is.

[xexyl]

I do have an idea but I'll wait until the issue has been opened. It might or might not be workable. I'm afraid that it'll only be a thought for the day though - too tired to actually focus on much of anything. Basic idea is to use some Makefile magic to determine which flags to include. It might be possible.

Alternatively it could be given in documentation that under CentOS one would have to modify the Makefile slightly? That's another possibility. Since we have the makefile.local override that would be a way to go about it?

These are some thoughts anyway that might or might not be useful but we can discuss it there.

Edit: Another thought is based on some system define checks directly give a function prototype. Maybe that's risky though but it just popped into my head since it is about implicit function declaration.

[xexyl]

BTW: Am I right in the other thread where the test functions are exactly like what is in the mkiocccentry tool ? If so I can help add the functions. Otherwise having some clarification would be of help - I could then help add some of the functions.

Some of the test code could be adapted from the old code as well.

[lcn2]

Please refer discussion about commit f85ec5ac7673281b9b2035de752f6df9be207902 to a new issue #311, @xexyl

[xexyl]

Please refer discussion about commit f85ec5a to a new issue #311, @xexyl

Was already on it but I got distracted with a text from a friend. Going to copy the ideas there. Probably all I can do today though I'm afraid :(

[lcn2]

BTW: Am I right in the other thread where the test functions are exactly like what is in the mkiocccentry tool ? If so I can help add the functions. Otherwise having some clarification would be of help - I could then help add some of the functions.

Some of the test code could be adapted from the old code as well.

We do not know what thread you refer to. Perhaps you should ask your question in that other thread if possible?

[xexyl]

BTW: Am I right in the other thread where the test functions are exactly like what is in the mkiocccentry tool ? If so I can help add the functions. Otherwise having some clarification would be of help - I could then help add some of the functions. Some of the test code could be adapted from the old code as well.

We do not know what thread you refer to. Perhaps you should ask your question in that other thread if possible?

Actually it belongs here so I'll copy paste it:

More specific questions. I see you have commented out calls to some of the above functions - commented out because they don't exist yet. So what I wonder is what do the below functions have to do?

• test_name
• test_location_code
• test_location_name
• test_url(url) -- what is this about ? Why url and also the next one, twitter?
• test_url(twitter) - see above question, why is it the same function?
• In fact all the test_url() invocations: github and affiliation etc.?
• test_past_winner
• test_extra_file

Are these (as I suspect) the same as what is done in mkiocccentry? If so I'd be happy to add them but I'd like clarification first. I believe that is it and some of the others like UTC timestamp I can take from my old code. Right now I want to go work on the private tool but maybe later today I can do a bit of work on some of these functions. I'm really not even sure what is more important.

[lcn2]

BTW: Am I right in the other thread where the test functions are exactly like what is in the mkiocccentry tool ? If so I can help add the functions. Otherwise having some clarification would be of help - I could then help add some of the functions. Some of the test code could be adapted from the old code as well.

We do not know what thread you refer to. Perhaps you should ask your question in that other thread if possible?

Actually it belongs here so I'll copy paste it:

More specific questions. I see you have commented out calls to some of the above functions - commented out because they don't exist yet. So what I wonder is what do the below functions have to do?

• test_name
• test_location_code
• test_location_name
• test_url(url) -- what is this about ? Why url and also the next one, twitter?
• test_url(twitter) - see above question, why is it the same function?
• In fact all the test_url() invocations: github and affiliation etc.?
• test_past_winner
• test_extra_file

Are these (as I suspect) the same as what is done in mkiocccentry? If so I'd be happy to add them but I'd like clarification first. I believe that is it and some of the others like UTC timestamp I can take from my old code. Right now I want to go work on the private tool but maybe later today I can do a bit of work on some of these functions. I'm really not even sure what is more important.

As of now, these test functions need to be added to entry_util.c and entry_util.h:

• test_formed_timestamp_usec
• test_github
• test_info_JSON
• test_ioccc_contest
• test_ioccc_year
• test_location_code
• test_location_name
• test_manifest
• test_min_timestamp
• test_name
• test_no_comment
• test_past_winner
• test_remarks
• test_rule_2a_size
• test_rule_2b_size
• test_tarball
• test_timestamp_epoch
• test_twitter
• test_url

For test_foo(arg) the JSON member element value foo (passed as arg) needs to be sanity checked.

For example, test_url(str) would perform the test on str to determine if it passes the rules for an author's URL.

For example, test_github(str) would perform the test on str to determine if it is a GitHub username.

For example, test_formed_timestamp_usec(integer) would perform a test on the formed_timestamp_usec JSON integer. I.e., the integer must be >= 0 and <= 999999.

In some cases, inspection of mkiocccentry.c will show you what is tested. For example, for the github value you can see that mkiocccentry.c checks for too small, to long, bogus chars, and must begin with @.

Another thing is to modify mkiocccentry.c to use existing test_foo() functions in entry_util.c where reasonable. We say reasonable, because in some cases mkiocccentry.c as no need for a test. However where there is code to test, say the (author's) name, the embedded test for name should be replaced by a call to test_name().

UPDATE 0

So for test_foo(arg), look in the .into.json and .author.json for hints on how the value of the JSON member named"foo" is used.

Look into mkiocccentry.c to see if the code applies sanity check on foo.

Those might give you a hint as to what test_foo(arg) should do.

If you cannot figure it out, skip the function.

We will be racing to also fill in the code, we suggest checking for commits on a frequent bases.

UPDATE 1

Look for cases, if there are any, in mkiocccentry.c that duplicates an existing test_foo(arg) and replace that mkiocccentry.c code with a call to test_foo(arg).

UPDATE 2

Some functions such as test_manifest(arg) are going to be tricky. You might want to skip coding such functions.

[xexyl]

BTW: Am I right in the other thread where the test functions are exactly like what is in the mkiocccentry tool ? If so I can help add the functions. Otherwise having some clarification would be of help - I could then help add some of the functions. Some of the test code could be adapted from the old code as well.

We do not know what thread you refer to. Perhaps you should ask your question in that other thread if possible?

Actually it belongs here so I'll copy paste it: More specific questions. I see you have commented out calls to some of the above functions - commented out because they don't exist yet. So what I wonder is what do the below functions have to do?

• test_name
• test_location_code
• test_location_name
• test_url(url) -- what is this about ? Why url and also the next one, twitter?
• test_url(twitter) - see above question, why is it the same function?
• In fact all the test_url() invocations: github and affiliation etc.?
• test_past_winner
• test_extra_file

Are these (as I suspect) the same as what is done in mkiocccentry? If so I'd be happy to add them but I'd like clarification first. I believe that is it and some of the others like UTC timestamp I can take from my old code. Right now I want to go work on the private tool but maybe later today I can do a bit of work on some of these functions. I'm really not even sure what is more important.

As of now, these test functions need to be added to entry_util.c and entry_util.h:

• test_formed_timestamp_usec
• test_github
• test_info_JSON
• test_ioccc_contest
• test_ioccc_year
• test_location_code
• test_location_name
• test_manifest
• test_min_timestamp
• test_name
• test_no_comment
• test_past_winner
• test_remarks
• test_rule_2a_size
• test_rule_2b_size
• test_tarball
• test_timestamp_epoch
• test_twitter
• test_url

For test_foo(arg) the JSON member element value foo (passed as arg) needs to be sanity checked.

For example, test_url(str) would perform the test on str to determine if it passes the rules for an author's URL.

For example, test_github(str) would perform the test on str to determine if it is a GitHub username.

For example, test_formed_timestamp_usec(integer) would perform a test on the formed_timestamp_usec JSON integer. I.e., the integer must be >= 0 and <= 999999.

In some cases, inspection of mkiocccentry.c will show you what is tested. For example, for the github value you can see that mkiocccentry.c checks for too small, to long, bogus chars, and must begin with @.

Another thing is to modify mkiocccentry.c to use existing test_foo() functions in entry_util.c where reasonable. We say reasonable, because in some cases mkiocccentry.c as no need for a test. However where there is code to test, say the (author's) name, the embedded test for name should be replaced by a call to test_name().

UPDATE 0

So for test_foo(arg), look in the .into.json and .author.json for hints on how the value of the JSON member named"foo" is used.

Look into mkiocccentry.c to see if the code applies sanity check on foo.

Those might give you a hint as to what test_foo(arg) should do.

If you cannot figure it out, skip the function.

We will be racing to also fill in the code, we suggest checking for commits on a frequent bases.

UPDATE 1

Look for cases, if there are any, in mkiocccentry.c that duplicates an existing test_foo(arg) and replace that mkiocccentry.c code with a call to test_foo(arg).

UPDATE 2

Some functions such as test_manifest(arg) are going to be tricky. You might want to skip coding such functions.

This is exactly what I thought. Thank you for confirming!

Hypothetical question for you. Not sure if you will see it before I am up to working on the repo again and it might be that I also feel up to it or something else over another but:

Assuming that I feel up to anything which changes should I do over the others? This goes for these functions as well as txzchk (which I guess I should try prioritising anyway as it’s kind of my thing) as well as all the other issues - not just these here.

Thank you. I will try replying to the other comments and then I will try sleeping but I am not sure if I will reply to everything as typing on the phone is such a bother. If I miss anything I will reply to it tomorrow.

[lcn2]

Assuming that I feel up to anything which changes should I do over the others? This goes for these functions as well as txzchk ...

These are probably near equal in priority

[xexyl]

Assuming that I feel up to anything which changes should I do over the others? This goes for these functions as well as txzchk ...

These are probably near equal in priority

Thank you. Right now not feeling well and I feel like it might be a today thing so I'm not sure what I'll end up doing but I hope to do something here. Will see. Once the backup drive cools down a little bit more I'm going to put it away and then try and sleep a bit more - though unlikely I will but at least I slept in a bit today.

[xexyl]

Updated my tool: it now has a test mode so it can verify that the encryption and decryption match.

It still has some other things to be worked out though. I've had some additional ideas that might make it more usable but as I noted in another thread I'm probably not going to do end up doing that today.

It might be I add some quotes though but nothing is certain other than almost certainly I wouldn't expect anything productive from me today (I mean committed: I got one issue mostly resolved but a few things have to be verified and cleaned up).

Hopefully later on today I can be more awake or tomorrow I can be if not today.

[xexyl]

As of now, these test functions need to be added to entry_util.c and entry_util.h:

• test_formed_timestamp_usec
• test_github
• test_info_JSON
• test_ioccc_contest
• test_ioccc_year
• test_location_code
• test_location_name
• test_manifest
• test_min_timestamp
• test_name
• test_no_comment
• test_past_winner
• test_remarks
• test_rule_2a_size
• test_rule_2b_size
• test_tarball
• test_timestamp_epoch
• test_twitter
• test_url

I had a little bit of time and enough energy (only barely enough .. I hope) to write test_url, test_github and test_url. See commit https://github.com/ioccc-src/mkiocccentry/pull/316/commits/f48e3827120a9248ac8ea0cdf8d4860e58f6fc04.

Please note I did not update mkiocccentry.c as I need to leave now to try sleeping again. Hope this helps and hopefully tomorrow I can do more.

Good day!

[xexyl]

You should have email with the tool by now. Make sure to read it all as there are some important points to consider.

I'm going to take it easy now but depending on how I feel after that I might try getting more test functions / something else in.

Enjoy the rest of your day!

...Ah. You have a vacation file set up I see. Maybe you won't see it then? Shame. You'll appreciate it when you get it anyway. Is there another way I can get this email to you? If not I'll send it when you're back. Please advise.

[xexyl]

You should have email with the tool by now. Make sure to read it all as there are some important points to consider.

I'm going to take it easy now but depending on how I feel after that I might try getting more test functions / something else in.

Enjoy the rest of your day!

...Ah. You have a vacation file set up I see. Maybe you won't see it then? Shame. You'll appreciate it when you get it anyway. Is there another way I can get this email to you? If not I'll send it when you're back. Please advise.

Just a quick few points of importance:

I have fixed an important bug in the code of the private tool. I also made some fixes to the formatting of foo. Additionally I have moved the array into a separate file. But I am also thinking (for personal reasons) to slightly change the key so if I do so I'll have to recreate the array entirely. This means the following files have been changed:

• Makefile (this can be redone if necessary: mostly because foo.c now includes a new file and make depend)
• foo.c
• And the new file oebxergfB.h

Thus if you can avoid touching foo.c that would be great. I can fix Makefile again no problem.

Once I have done the change in the key (if I do) I'll send you the new tool though maybe you won't be able to access it for now).

[xexyl]

BTW: I like how in commit edb3bd70bb5715caf5e392339a4b0b885eecec89 you adopted what I do with testing for strlen() == 0:

    } else if (*str == '\0') { /* strlen(str) == 0 */

I know it depends on the length of the string but it would be more efficient and as the string gets longer the more efficient it will be. Probably doesn't make much of a difference all considered but it's still something. But it's still cool you adopted it for at least this commit.

I'll be doing a pull request soonish - as long as my eyes let me.

[xexyl]

With https://github.com/ioccc-src/mkiocccentry/pull/322/commits/f95e092de85146d6c095cd67f86c96cd63fc728f I believe all the test_ functions have been added.

I didn't add a call to them though and they're not in mkiocccentry either.

[xexyl]

Quick note before I try getting back to sleep (unlikely though that is):

I have made good progress with the private tool. In fact it appears that the decryption mode will generate output that can be used as input to create the original input! I'm aware of at least one bug but I expect more than one (and it is a bit messy .. and maybe more than messy). It doesn't handle syntax errors very well at all but as long as the unencrypted input file is correct it should be possible to use it as input.

This means that with some new features or a script we can automatically generate the file which means it'll be easy for us to make updates. One thing that has to be figured out though:

Where to store the unencrypted text. Probably in a text file in the same directory which is in .gitignore which using the tool would overwrite. Or maybe a script should do that: not sure yet.

Anyway it's great news if it is indeed what it seems to be. I'll work on it more later on. I do have some foo updates as well but that'll come later on - today or the next day.

Hope you're having a great time abroad!

[xexyl]

Please see 22dd89cc0522fdeb84f16eb3a80102158efb6d6b: it's now possible to automatically create the header file with the array (strings for foo)!

I will explain how it works in email when you're back home as well as send you the updated tool. There still are some things to be done with it but mostly it's done now which is good. I added some strings to the file as well - some good fun stuff including one reference to a winning entry of 2020 (not mine though).

Anyway that's all I'm doing for the day. I wonder what you think of this though: having a Makefile rule to do it so you can easily do it too? Certainly a script would be worth writing as well. Obviously only we could use it and yes of course I added the plaintext file to .gitignore.

Good day! Hope you're well and having a great time my friend! Cheers.

[lcn2]

Please see 22dd89c: it's now possible to automatically create the header file with the array (strings for foo)!

I will explain how it works in email when you're back home as well as send you the updated tool. There still are some things to be done with it but mostly it's done now which is good. I added some strings to the file as well - some good fun stuff including one reference to a winning entry of 2020 (not mine though).

Anyway that's all I'm doing for the day. I wonder what you think of this though: having a Makefile rule to do it so you can easily do it too? Certainly a script would be worth writing as well. Obviously only we could use it and yes of course I added the plaintext file to .gitignore.

Good day! Hope you're well and having a great time my friend! Cheers.

We will look at commit 22dd89cc0522fdeb84f16eb3a80102158efb6d6b in due course. Perhaps a Makefile rule might be in order .. we shall see.

On a note that isn't intended to ruin fun, we need to be sure that the easter egg fun does not deal us from the overall objective: getting the IOCCC up and running again. There still is a massive amount of work that needs to be done, some of that in this repo. So please pardon us as we put foo and friends on the back burner as "we hear the call of people who want to submit to the IOCCC and cannot do so now".

We do thank you for putting a bit of fun into foo: I think others might appreciate it BUT ONLY IF we get the IOCCCMOCK up and running! So for the sake of the fun in foo .. and more importantly the people who want to enter the next IOCCC, lets put effort in to closing the gap between the state now, and a,, IOCCCMOCK.

Even so, foo was fun .. now we return back to work! :-)

[xexyl]

Please see 22dd89c: it's now possible to automatically create the header file with the array (strings for foo)! I will explain how it works in email when you're back home as well as send you the updated tool. There still are some things to be done with it but mostly it's done now which is good. I added some strings to the file as well - some good fun stuff including one reference to a winning entry of 2020 (not mine though). Anyway that's all I'm doing for the day. I wonder what you think of this though: having a Makefile rule to do it so you can easily do it too? Certainly a script would be worth writing as well. Obviously only we could use it and yes of course I added the plaintext file to .gitignore. Good day! Hope you're well and having a great time my friend! Cheers.

We will look at commit 22dd89c in due course. Perhaps a Makefile rule might be in order .. we shall see.

On a note that isn't intended to ruin fun, we need to be sure that the easter egg fun does not deal us from the overall objective: getting the IOCCC up and running again. There still is a massive amount of work that needs to be done, some of that in this repo. So please pardon us as we put foo and friends on the back burner as "we hear the call of people who want to submit to the IOCCC and cannot do so now".

We do thank you for putting a bit of fun into foo: I think others might appreciate it BUT ONLY IF we get the IOCCCMOCK up and running! So for the sake of the fun in foo .. and more importantly the people who want to enter the next IOCCC, lets put effort in to closing the gap between the state now, and a,, IOCCCMOCK.

Even so, foo was fun .. now we return back to work! :-)

I agree. However right now I am holding off on your changes so I might as well have some fun during this wait. After that wait I will get back to the other stuff. No question about that!

Have a zoom meeting at the hour and doing other things after that. Good day!

[lcn2]

Issues #248 and #250 are open. Meanwhile we have some time to make a strong push on JSON semantics before we get delayed again due to Artemis stuff and family event stuff and travel stuff that is also looming on our time horizon.

Best wishes on your meetings and THANKS for your help @xexyl !

[xexyl]

Issues #248 and #250 are open. Meanwhile we have some time to make a strong push on JSON semantics before we get delayed again due to Artemis stuff and family event stuff and travel stuff that is also looming on our time horizon.

True. Plus documentation. That's another thing though - kind of low on motivation the last days. Been having off days I guess. I'll have to look at these issues again.

Best wishes on your meetings and THANKS for your help @xexyl !

Thank you for the best wishes and also thank you for noting your appreciation and you're welcome! I enjoy it a lot!

Good luck with the rocket in the coming days (and everything else even)!

[lcn2]

With commit 139fe0cbf915fe9c4cec9028113b943c84f22e23:

Checkpoint validation code complete.

    Added the remaining `chk_foo()` functions to chk_validate.c.
    Updated `chk_foo()` functions in chk_validate.c to be more
    particularly in how parent JSON nodes are found and
    sibling nodes of those parents are processed.

    Sorted `test_foo()` functions in entry_util.c and made
    minor changes for consistency.

NOTE: All of the `chk_foo()` functions are untested!

NOTE: Some of the `test_foo()` functions are untested!

And next:

TODO: Write a tree walking function that will examine the
          JSON semantic tables AND invoke the `chk_foo()` functions
          via the chkentry.c code (also to be written).

With this @xexyl PLEASE feel free to edit away at the typos and inconsistencies in all of the files in this repo, especially the ones we asked you leave alone while there were under active editing while remote. We apologize for any inconvenience this may have created for you.

[xexyl]

With commit 139fe0c:

I just did a pull and then saw you made changes. Checked mail and see you made this comment. I was going to say some things about it too which is why I checked.

Checkpoint validation code complete.

    Added the remaining `chk_foo()` functions to chk_validate.c.
    Updated `chk_foo()` functions in chk_validate.c to be more
    particularly in how parent JSON nodes are found and
    sibling nodes of those parents are processed.

    Sorted `test_foo()` functions in entry_util.c and made
    minor changes for consistency.

NOTE: All of the `chk_foo()` functions are untested!

NOTE: Some of the `test_foo()` functions are untested!

And next:

TODO: Write a tree walking function that will examine the
          JSON semantic tables AND invoke the `chk_foo()` functions
          via the chkentry.c code (also to be written).

As for this I would be happy to look into doing at least some of this - I imagine you'll want to do some of it too. I guess the tree walking function can use the function that already exists? I don't remember the name and I no longer am certain which file it is in even but would that be good to start?

As for the chkentry.c code I am happy to start working on that too. I won't do today as I'll be off shortly to get food and then a bit later sleep but I should hopefully be able to start it tomorrow. I might have to look back in the thread to remember some details but that's okay - though it's annoying how GitHub forces you to repeatedly load more comments at different parts of the page instead of just having multiple pages or loading all of them (or having an option). Still I can do that.

With this @xexyl PLEASE feel free to edit away at the typos and inconsistencies in all of the files in this repo, especially the ones we asked you leave alone while there were under active editing while remote. We apologize for any inconvenience this may have created for you.

No problem at all but thank you for the concern. I will indeed look at typos too. But no inconvenience anyway. Besides I had fun with my private tool and foo! I still actually have more ideas for quotes to add but that can be done another time - or maybe every so often I can slip some into a commit.

No rush on getting back to me on the above questions. I can at least work on typos/inconsistencies until you get a chance to look at it. Same with the concern I raised in the other thread about MAX_DIR_KSIZE*1024 versus just MAX_DIR_KSIZE. I can make any corrections later on. No worries.

Hope you have a good rest of your day!

[lcn2]

As for this I would be happy to look into doing at least some of this - I imagine you'll want to do some of it too. I guess the tree walking function can use the function that already exists? I don't remember the name and I no longer am certain which file it is in even but would that be good to start?

This is what we will work on next, after a bit of rest.

[xexyl]

As for this I would be happy to look into doing at least some of this - I imagine you'll want to do some of it too. I guess the tree walking function can use the function that already exists? I don't remember the name and I no longer am certain which file it is in even but would that be good to start?

This is what we will work on next, after a bit of rest.

Sounds good.

I was going to say. In yesteryears I would have more time to work on these things later into the day. But because I wake up so early no matter what time I go to sleep I have to go to sleep earlier (or at least try going to sleep - some nights it takes longer to fall asleep).

But also because of some things that happened in my life the past few years I have felt the need to spend more time with my mum and my pets. They’re the most important things to me by far.

I also know better now and do other things besides programming so I have less time in that way as well.

Still I know I have done a great deal for the IOCCC and I am incredibly proud and appreciative and honoured and privileged. Leo said something to me about it too - that he is glad I am working hard to keep the IOCCC going!

It’s a real gift that I can do this. It gives me a lot of joy and purpose and so much more.

Anyway I just wanted to say those things. I know you appreciate it a lot too. But you know something. Even though the ultimate goal is to get the contest ready for running I will miss our dialogues at that point! That’s the best part of all of this. The friendship here. It’s so wonderful! Thank you for that over everything else (even the C and Unix history etc. being so special to me is not as special as this)!

I will look at the other thread tomorrow as that’s OT (I guess this kind of is too but that one is totally OT). I hope tomorrow I can start working on the chkentry tool! I should think that once I’ve found the details (as in the spec) again because the supporting code is now in place that I should likely be able to make good progress. Let’s just hope I get enough sleep and not so disturbed sleep and this might very well happen!

With that all said I am going to watch a short video and then try sleeping. Good night my friend!

[lcn2]

As for this I would be happy to look into doing at least some of this - I imagine you'll want to do some of it too. I guess the tree walking function can use the function that already exists? I don't remember the name and I no longer am certain which file it is in even but would that be good to start?

This is what we will work on next, after a bit of rest.

Sounds good.

I was going to say. In yesteryears I would have more time to work on these things later into the day. But because I wake up so early no matter what time I go to sleep I have to go to sleep earlier (or at least try going to sleep - some nights it takes longer to fall asleep).

But also because of some things that happened in my life the past few years I have felt the need to spend more time with my mum and my pets. They’re the most important things to me by far.

I also know better now and do other things besides programming so I have less time in that way as well.

Still I know I have done a great deal for the IOCCC and I am incredibly proud and appreciative and honoured and privileged. Leo said something to me about it too - that he is glad I am working hard to keep the IOCCC going!

It’s a real gift that I can do this. It gives me a lot of joy and purpose and so much more.

Anyway I just wanted to say those things. I know you appreciate it a lot too. But you know something. Even though the ultimate goal is to get the contest ready for running I will miss our dialogues at that point! That’s the best part of all of this. The friendship here. It’s so wonderful! Thank you for that over everything else (even the C and Unix history etc. being so special to me is not as special as this)!

I will look at the other thread tomorrow as that’s OT (I guess this kind of is too but that one is totally OT). I hope tomorrow I can start working on the chkentry tool! I should think that once I’ve found the details (as in the spec) again because the supporting code is now in place that I should likely be able to make good progress. Let’s just hope I get enough sleep and not so disturbed sleep and this might very well happen!

With that all said I am going to watch a short video and then try sleeping. Good night my friend!

Thanks and best wishes.

[xexyl]

[...] With that all said I am going to watch a short video and then try sleeping. Good night my friend!

Thanks and best wishes.

Thank you and you too - and a safe trip home! As you know it was a difficult night last night so I probably won't get much done more than what you already saw but hopefully tomorrow will be better.

[xexyl]

I am looking at the man page of chkentry and have made some minor fixes but II'm unsure of something and wondering if you can enlighten me on it.

We have:

SYNOPSIS
       chkentry [-h] [-v level] [-J level] [-V] [-q] [-F fnamchk] [-w] entry_dir
       chkentry [-h] [-v level] [-J level] [-V] [-q] [-F fnamchk] [-w] info.JSON author.JSON

But I don't see the -w in the OPTIONS section and it's not in getopt() call in the source file either. Any idea what this was supposed to be for? Thanks.

[xexyl]

Another thing. In chkentry.h we have:

#define MATCH_PRECISION ((long double)(1<<22))

But this same definition is in jnum_chk.h. Should chkentry.h #include "jnum_chk.h" or should the definition be removed? Just thinking it's better (at least normally) to not have the same definition twice as it means if one changes one has to remember to change the others or else have some problems.

And yes I'm looking at working on these tools though not a great deal. I'll probably (not certain) do a pull request at some point today but I won't be doing a lot today either.