Enhancement: Less obfuscated versions of some winners

[SirWumpus]

I was reviewing how my past entries currently appear in the updated site.

All my winning entries are on GitHub, have spoilers, some have been cleaned up to C89 versions (ae, ag). All of them should work. Much of the documentation has been converted to Markdown (not the .hint files). Not sure if you want to reference these repositories, copy the formatted documentation, etc.

Anyway I provide these links to the material:

• 1991 https://github.com/SirWumpus/ioccc-ae/91 (top level provides history and updated version)
• 1992 https://github.com/SirWumpus/ioccc-am
• 1993 https://github.com/SirWumpus/ioccc-ag
• 2004 https://github.com/SirWumpus/ioccc-hibachi
• 2005 https://github.com/SirWumpus/ioccc-mynx (original http: version)
• 2015 https://github.com/SirWumpus/ioccc-npdif

[xexyl]

Thanks! Landon told me that there shouldn't be any hidden spoilers nowadays .. I can help out here.

[xexyl]

Actually .. I was going to do this now but I wonder something. Landon, do you think the spoiler files should be included in the website or just have them linked to from the index.html file ? I can do either one but including the files obviously means a manifest update. I'll hold off until you let me know what you prefer, @lcn2, and go from there.

UPDATE 0

Observe that each has a spoiler/ subdirectory and it is those files I refer to. Could be under a subdirectory in the winning entry or somewhere else. Maybe easiest to just link to that subdirectory or the repo in question?

[SirWumpus]

I originally proposed the idea of including spoilers a few years ago (didn't want to get hit by a ebike without having shared the originals), which were available in some places on ioccc.org.

I think if the author is maintaining the code on GitHub, GitLab, ... then a suitable link in the repository is probably sufficient (fewer changes), but of the author has abandoned the code and left spoilers, then a spoiler/ directory seems apropos and I think at this stage you would have accounted for those cases in a manifest.

I did see place last night source/ directories? Where these spoilers or part of the original submission; if spoiler then I think an explicit name like spoiler/ is clearer as to purpose.

[SirWumpus]

In my repos, I have the original entry at the root with a spoiler/ directory.

Would you link to the repo root or to the spoiler within the repo? I recommend the repo root, because the owner may restructure it in the future breaking links.

[xexyl]

I originally proposed the idea of including spoilers a few years ago (didn't want to get hit by a ebike without having shared the originals), which were available in some places on ioccc.org.

Well I'm glad you didn't get hit by an e-bike .. or any other kind!

I think if the author is maintaining the code on GitHub, GitLab, ... then a suitable link in the repository is probably sufficient (fewer changes), but of the author has abandoned the code and left spoilers, then a spoiler/ directory seems apropos and I think at this stage you would have accounted for those cases in a manifest.

That's probably good enough but not sure what Landon thinks. I'd agree it's enough though. And if the files are not added then the manifest does not need to be updated.

I'd say that maybe the only reason to include files is in case the repo is deleted. That seems most unlikely but the problem with including the files too is if they change (as you say in your next comment).

I did see place last night source/ directories? Where these spoilers or part of the original submission; if spoiler then I think an explicit name like spoiler/ is clearer as to purpose.

Well as for that one entry had a spoiler/ subdirectory but it was moved to the directory itself. This was in 2020: it had been a zip file which was password protected but the password was no longer known (wiki article that was changed). I had it from the winner archive though so I just added the files.

But I'm not sure if a subdirectory is necessary or not. If it is then spoiler/ sounds like a good name to me too.

[xexyl]

In my repos, I have the original entry at the root with a spoiler/ directory.

I noticed that. The first link you had I think was broken but I corrected it in the browser and got to it.

Would you link to the repo root or to the spoiler within the repo? I recommend the repo root, because the owner may restructure it in the future breaking links.

Good point indeed.

[SirWumpus]

The first link you had I think was broken but I corrected it in the browser and got to it.

You referring to the https://github.com/SirWumpus/ioccc-ae? That one is rather specially organised, because there was a some derivative work that followed after 1991.

[xexyl]

The first link you had I think was broken but I corrected it in the browser and got to it.

You referring to the https://github.com/SirWumpus/ioccc-ae? That one is rather specially organised, because there was a some derivative work that followed after 1991.

Yes that one .. but the link is 404. https://github.com/SirWumpus/ioccc-ae/tree/master seems good.

[SirWumpus]

That doesn't make sense. It works for me and DuckDuckGo search lists the repo URL in the results ( https://duckduckgo.com/?t=ffab&q=howe+ioccc+ae ). I would avoid reference .../tree/master or .../tree/main or whatever GitHub will use to point into the source tree.

[xexyl]

That doesn't make sense. It works for me and DuckDuckGo search lists the repo URL in the results ( https://duckduckgo.com/?t=ffab&q=howe+ioccc+ae ). I would avoid reference .../tree/master or .../tree/main or whatever GitHub will use to point into the source tree.

I thought it was odd too but clicking on it got 404. I would also avoid the last part but I just copy pasted it from Safari without worrying about changing it.

[SirWumpus]

OK. Tested in Firefox and Vivaldi. The top level URL https://github.com/SirWumpus/ioccc-ae works as expected, while subdirectory https://github.com/SirWumpus/ioccc-ae/91 does not (404). From the top level README, GitHub converts the relative link to something like https://github.com/SirWumpus/ioccc-ae/blob/master/91 so using internal links into a repo can vary.

[lcn2]

The IOCCC web site has shifted to a more educational format: preferring to explain entries rather than hiding things under the guise of such information being a "spoiler".

As a result, content that was "hidden" is now being made available. For example, stuff that was rot13 are now plaintext.

Instead of a "can you guess", the IOCCC favors people being able to learn about an IOCCC winning entry.

If there is a de-obfuscated version of an IOCCC winning entry, adding such code would be welcome. How to add a de-obfuscated version is up for discussion: one way is the provide an alt code version and reference it in the README.md file. Another would be to add it as some sort of prog.deobfuscated.c file and again reference it in the README.md file. There may be other ways as well.

We would have the alt method (as prog.alt.c or as prog.alt2.c in case prog.alt.c already exists) and then referencing the de-obfuscated code in the README.md as something the reader might wish to explore.

Anyone who would care to provide de-obfuscated code would be thanked and credited in the thanks-for-the-help.md file with our thanks. 🙏

So, @SirWumpus, if you have de-obfuscated code versions, we would be happy to add them into the IOCCC collection with our thanks. 🙏

[xexyl]

OK. Tested in Firefox and Vivaldi. The top level URL https://github.com/SirWumpus/ioccc-ae works as expected, while subdirectory https://github.com/SirWumpus/ioccc-ae/91 does not (404). From the top level README, GitHub converts the relative link to something like https://github.com/SirWumpus/ioccc-ae/blob/master/91 so using internal links into a repo can vary.

Interesting. That is how I guessed it might be too given that I had to go to the top level directory. I found it odd. This was n Safari btw (I think I might have said that though). I wonder why subdirectories don't work.

[SirWumpus]

I've always tried to educate with each of my entries.

I would reserve *.alt.c or alt anything for literal alternative versions, typically compiler bug fixes or minor change to the original entry.

I still think the original developer's code (and any support tools they provide) go in a spoiler/ or if you prefer directors_cut/ or similar directory to denote that it was not part of the original submission, but provides more details, like a commented version, full source, extra docs and reference material, etc.

[xexyl]

The IOCCC web site has shifted to a more educational format: preferring to explain entries rather than hiding things under the guise of such information being a "spoiler".

As a result, content that was "hidden" is now being made available. For example, stuff that was rot13 are now plaintext.

Yes and also uuencoded things .. I undid both rot13 things (except in one case where it wasn't rot13 but a different rotation - if you recall) and uuencode. I did not undo the 2020/ferguson2 one of course: that is a way to experiment with the entry and it also has some good fun in it too! And that's another reason we don't always do it - if it's part of the entry it should not be done (though I guess if by some chance [0] one won it would not be that way).

Instead of a "can you guess", the IOCCC favors people being able to learn about an IOCCC winning entry.

This might be something that can't say as it pertains to judging but I guess that it is not actually going to decrease the chance of winning if this is not done? (Whether it would increase if it is done I know you would not say and I would not want you to say it either).

If there is a de-obfuscated version of an IOCCC winning entry, adding such code would be welcome. How to add a de-obfuscated version is up for discussion: one way is the provide an alt code version and reference it in the README.md file. Another would be to add it as some sort of prog.deobfuscated.c file and again reference it in the README.md file. There may be other ways as well.

I refer to that 'way to go about it' below. We often do alt but in at least one or two cases there's the name of the file given by the author say on their website (like with one entry of Bellard).

We would have the alt method (as prog.alt.c or as prog.alt2.c in case prog.alt.c already exists) and then referencing the de-obfuscated code in the README.md as something the reader might wish to explore.

That's one way of doing it. I think I did that in a few cases but I'm not sure. In some cases it was already done - code submitted with the entry itself was turned into an alt version.

Anyone who would care to provide de-obfuscated code would be thanked and credited in the thanks-for-the-help.md file with our thanks. 🙏

Ha. I did do that for a few .. maybe. I'm not sure. But I found it on the respective author's repo (or in one case website).

So, @SirWumpus, if you have de-obfuscated code versions, we would be happy to add them into the IOCCC collection with our thanks. 🙏

I can add those .. unless you wish to, @SirWumpus ? Let me know and I'd be happy to do it. On second thought .. I guess you don't have macOS so you can't update the manifest. Okay I'll do that in the next few days I hope.

A question for you Landon is: where should they be? A subdirectory called spoiler/ or in the entry's directory? If in the entry's directory what should they be called? Perhaps the name of the files in the particular directory? I guess we should do the alt method but the question is how many alt versions should there be. This is hypothetical but if there were 42 revisions we would not want all the way up to .alt41 (or whatever we have used .. can't remember right now - too tired and can't be bothered checking). In at least one case I called the file the name the author gave (those I found - didn't touch the ones that the author submitted originally).

Of course if @SirWumpus prefers to do it one of us can always fix the manifest. But might just be easier if I do it so the questions above still apply I think?

[0] Siri really has told that joke. I have a screenshot of it .. alas I tried it again some years ago and no luck :(

[lcn2]

We would have the alt method (as prog.alt.c or as prog.alt2.c in case prog.alt.c already exists) and then referencing the de-obfuscated code in the README.md as something the reader might wish to explore.

That's one way of doing it. I think I did that in a few cases but I'm not sure. In some cases it was already done - code submitted with the entry itself was turned into an alt version.

The focus from those initial readings the website is on the entry index.html file (as generated from the README.md) file.

If the alt section, if there is a de-obfuscated version of prog.c, then the entry index.html file (as generated from the README.md) file should mention that file as being a de-obfuscated version (formerly "sppiler").

Those wishing to just "download, compiler and dive-into the code" can just do a make and starting reading prog.c as the prog.c code will never be a de-obfuscated version.

There are very special cases where make builds an "alt" version of the code, but that case the "alt" code is NOT a de-obfuscated version but rather version that is able to compile or otherwise fixes something "fatal" or "nearly fatal" with the original code.

Moreover prog.orig.c remains the original winning source (or as close we have to the original), and again never be a de-obfuscated version.

Anyone who would care to provide de-obfuscated code would be thanked and credited in the thanks-for-the-help.md file with our thanks. 🙏

Ha. I did do that for a few .. maybe. I'm not sure. But I found it on the respective author's repo (or in one case website).

👍

So, @SirWumpus, if you have de-obfuscated code versions, we would be happy to add them into the IOCCC collection with our thanks. 🙏

I can add those .. unless you wish to, @SirWumpus ? Let me know and I'd be happy to do it. On second thought .. I guess you don't have macOS so you can't update the manifest. Okay I'll do that in the next few days I hope.

Well @SirWumpus, I would recommend working with @xexyl to contribute your de-obfuscated code. If you provide @xexyl with the URLs of the code, and any additional commentary that might prove educational, @xexyl can go through the steps of adding your contributions with our THANKS and appreciation!

A question for you Landon is: where should they be? A subdirectory called spoiler/ or in the entry's directory? If in the entry's directory what should they be called? Perhaps the name of the files in the particular directory? I guess we should do the alt method but the question is how many alt versions should there be. This is hypothetical but if there were 42 revisions we would not want all the way up to .alt41 (or whatever we have used .. can't remember right now - too tired and can't be bothered checking). In at least one case I called the file the name the author gave (those I found - didn't touch the ones that the author submitted originally).

Of course if @SirWumpus prefers to do it one of us can always fix the manifest. But might just be easier if I do it so the questions above still apply I think?

[0] Siri really has told that joke. I have a screenshot of it .. alas I tried it again some years ago and no luck :(

Adding a spoiler sub-directory with code to compile and clean and clobber adds some more complicatation the build system, so we would prefer to not use such a subdirectory mechanism.

UPDATE 0a

BTW: There is a TODO item issue #2239:

• Add an FAQ about how to handle so-called spoiler content

Perhaps we need an "FAQ 5.8: How may I contribute a de-obfuscated version of an entry?" @xexyl.

Please see the updated DO item issue #2239: "Add an FAQ about how to handle de-obfuscated code".

WE should NOT use terms like "spoiler" in the FAQ as well as NOT using "spoiler" in the entry's README.md file. At a most, the README.md should suggest that the reader might wish to study the prog.c code first before going on to review the de-obfuscated "alt" code.

UPDATE 1a

Thank you, @SirWumpus, for your willingness to contribute de-obfuscated code!

UPDATE 2

We suggest, @xexyl, that you write the FAQ as mentioned in "UPDATE 0a" first, as this will help guide the design for how to add de-obfuscated "alt" code.

You might even take one of @SirWumpus's contributions and write that up according to the FAQ you draft (including the thanks-for-help.md file) . Once things look good for the FAQ and prototype de-obfuscated "alt" code contribution, and thanks-for-help.md update, one can then proceed with adding the read of @SirWumpus's contributions and then revise previous de-obfuscated "alt" code contribution previously made by you/others.

[SirWumpus]

All the spoiler code and any extra stuff are in a spoiler/ for each repo from above.

Adding a spoiler sub-directory with code to compile and clean and clobber adds some more complicatation the build system, so we would prefer to not use such a subdirectory mechanism.

I'd suggest NOT building (or cleaning) spoiler/ subdirectories (ohh, just remembered contrib/ is a fav of many, might be better than spoiler/) as part of the build system. These are supplemental to the winner and provided for learning. Leave them to the viewers to play with IMO. I wouldn't fuss with the extra stuff- just provide as-is.

[xexyl]

Excellent comment Landon and great idea about the FAQ. I think that would be a good idea. The question is do you want to do that or should I?

I will reply to your comment in more detail tomorrow when at the laptop. I will be going to bed shortly.

[lcn2]

Excellent comment Landon and great idea about the FAQ. I think that would be a good idea. The question is do you want to do that or should I?

I will reply to your comment in more detail tomorrow when at the laptop. I will be going to bed shortly.

We will draft an initial FAQ for you to modify as needed ... doing that now ..

UPDATE 0

With commit 4d37308 added a draft of FAQ 5.8.

QUESTION

Should we use the term "deobfuscated" or "de-obfuscated"?

We used "deobfuscated" below.

UPDATE 1d

With commit 4d6009b, and commit 3aec80f, and commit 85c9916, and commit 5dd3311: we shifted away from "spoiler" language and filenames and to "deobfuscation" information and filenames: as per FAQ 5.8.

So all existing "spoiler" usage have been converted into "deobfuscated", although one may wish to check out and correct these edits.

[xexyl]

Excellent comment Landon and great idea about the FAQ. I think that would be a good idea. The question is do you want to do that or should I?
I will reply to your comment in more detail tomorrow when at the laptop. I will be going to bed shortly.

We will draft an initial FAQ for you to modify as needed ... doing that now ..

UPDATE 0

With commit 4d37308 added a draft of FAQ 5.8.

QUESTION

Should we use the term "deobfuscated" or "de-obfuscated"?

We used "deobfuscated" below.

UPDATE 1d

With commit 4d6009b, and commit 3aec80f, and commit 85c9916, and commit 5dd3311: we shifted away from "spoiler" language and filenames and to "deobfuscation" information and filenames: as per FAQ 5.8.

So all existing "spoiler" usage have been converted into "deobfuscated", although one may wish to check out and correct these edits.

Yes I think some might be wrong indeed. One is in 2020/ferguson1 in fact. It's not really about de-obfuscation (well some of it is but it's not strictly it). It certainly is not an unobuscated version! It's just notes on how it's obfuscated so it might be better to call it (in this case) obfuscation.{md,html} ? I like that. And I'm not sure about some other files either ... The ones with JavaScript that type out the code: I'm not sure. Those by I think Don Yang. For instance what do you think the name of 2019/yang/deobfuscation.html should be? In this case it might work as it shows how it was developed.

On the other hand the file: 2018/algmyr/deobfuscation.png doesn't seem like the right name, somehow.

That being said I do think 'deobfuscated' is better than 'de-obfuscated'. But then again unobfuscated might also be valid depending on the context ... I don't know. What I do know though is that in some cases the way you put it is definitely not right.

The question is what else has to be done with the changing of the file names. That I'm not sure other than updating the manifest. In the case of 2020/ferguson1 it's referenced in at least some files so I can just use sgit(1) on those files .. but not so simple on all of them, maybe.

In any case I will change 2020/ferguson1 now and then we can discuss the others later. I hope to look at the guidelines in a bit too ...

[xexyl]

.. actually I'm not sure that's the right name for 2020/ferguson1 either. The name spoilers works well but obfuscation does not work as well as it's not just about obfuscation. It has as a table of contents:

-   [How does the snake movement work?](#movement)
-   [Drawing (manual) and computer playing (automatic) modes](#manual-automatic)
-   [Collision detection](#collision)
    *   [Cannibal collision detection](#cannibalcollision)
    *   [Collision detection when resizing the window of the game](#resizing)
-   [Obfuscation](#obfuscation)
-   [Skinning the snake (i.e., decreasing the iocccsize)](#skinning)
-   [A few more interesting size optimisations](#size)

so deobfuscation and variants are definitely wrong but I think obfuscation an variants are also wrong. The problem is that since it does talk about obfuscation (rather than deobfuscation) AND the other things it can't simply be named 'obfuscation'. Something like details (for implementation details) doesn't work that well either because it has the obfuscation part and more importantly other files also talk about these things ...

So I don't know.

.. and I see some grammar issues in that table of contents: odd. I don't recall having added a comma after i.e. : I wouldn't. But maybe I did by accident (ah: just in the table of contents, not in the title itself .. which is expected).

[xexyl]

.. actually I'm not sure that's the right name for 2020/ferguson1 either. The name spoilers works well but obfuscation does not work as well as it's not just about obfuscation. It has as a table of contents:

-   [How does the snake movement work?](#movement)
-   [Drawing (manual) and computer playing (automatic) modes](#manual-automatic)
-   [Collision detection](#collision)
    *   [Cannibal collision detection](#cannibalcollision)
    *   [Collision detection when resizing the window of the game](#resizing)
-   [Obfuscation](#obfuscation)
-   [Skinning the snake (i.e., decreasing the iocccsize)](#skinning)
-   [A few more interesting size optimisations](#size)

so deobfuscation and variants are definitely wrong but I think obfuscation an variants are also wrong. The problem is that since it does talk about obfuscation (rather than deobfuscation) AND the other things it can't simply be named 'obfuscation'. Something like details (for implementation details) doesn't work that well either because it has the obfuscation part and more importantly other files also talk about these things ...

So I don't know.

.. and I see some grammar issues in that table of contents: odd. I don't recall having added a comma after i.e. : I wouldn't. But maybe I did by accident (ah: just in the table of contents, not in the title itself .. which is expected).

Now as far as this file goes I could split it into two: a file that explains details on how things are implemented (details.md, implementation.md, something else ?) and one about obfuscation (obfuscation.md) but that then that also changes the way the judges' remarks looks and I quite like how it looks ...

[SirWumpus]

Who is the source of the deobfuscated file (weak name)? Was it supplied by the entry author or 3rd party?

• By a 3rd party I suppose you can take liberties to rename stuff, but splitting information into more files seems wrong. You're moving into the area of being an editor and possibly changing the writing teaching focus. Also creating more work. What if different sections of a document make reference to "see above" or "see below" but now those are in different files.

• By the author I would NOT change how they presented and name their supplemental files; possible clashes and confusion with their personal repos. In almost all my spoiler directories I have support files I used to transform a program into prog.c. Some I have created C89 versions from the original K&R C and supply both.

• If prog.c is the obfuscated entry, then maybe name the deobfuscated version program.c (original version needs more "ram" ;-) )

Again I repeat an earlier missive:

I'd suggest NOT building (or cleaning) spoiler/ subdirectories (ohh, just remembered contrib/ is a fav of many, might be better than spoiler/) as part of the build system. These are supplemental to the winner and provided for learning. Leave them to the viewers to play with IMO. I wouldn't fuss with the extra stuff- just provide as-is.

I don't see an issue with spoiler/ as a directory name, its commonly used and well understood. If you're still searching for a name Answers/, Bonus/, Contrib/, Exrta/, Other/, Supplemental/.

You can tell we're all programmers here. I think it takes a programmer to understand the power of what is in a name of a variable, function, file, object, etc. The original author would have put thought into it to some degree which should be respected.

Like programmers working on an existing project, we should maintain the "coding & whitespace style" (or editorial style of documentation) of the original, no matter how much we want to scratch that itch to reformat. (I remember being told off about such things in my first professional job after uni.)

[xexyl]

Who is the source of the deobfuscated file (weak name)? Was it supplied by the entry author or 3rd party?

I don't particularly like the name either in this case. In many cases the 'deobfuscated' version is simply less obfuscated but still obfuscated which means it's NOT deobfuscated (which means the file name is a misnomer). In some cases it's not even a C file but something else. That applies to a number of files including one of mine and as I noted above it has presented me a problem on what to call it as it's definitely not 'deobfuscated': it's not even code. I liked the name spoilers and it works well for that file: not only with the judges' remarks (that I quite loved) but also because it had a number of different types of things. At first I was thinking 'obfuscated' might work but it shows more information than just how it was obfuscated (or at least some of its obfuscation) so that can't work either.

Thus in that case I don't know what to do. For Don Yang's entries that had spoiler.html (or maybe it was spoilers.html) it's not code but it types out from start to finish. That might work for deobfuscated but event that I think not as it ends up becoming obfuscated. In that case it might be better called 'obfuscation' but is that the right name? I don't know but I do know spoiler/spoilers worked fine.

• By a 3rd party I suppose you can take liberties to rename stuff, but splitting information into more files seems wrong. You're moving into the area of being an editor and possibly changing the writing teaching focus. Also creating more work. What if different sections of a document make reference to "see above" or "see below" but now those are in different files.

Personally I think anything provided in this way by a person other than the author should NOT be accepted.

As for 2020/ferguson1 I could split those two but I don't want to have to do that and it rather changes quite a bit of what was done. And as you said I would have to do more work as I refer to the file in a number of places in a number of ways which would have to be reviewed, updated etc.

• By the author I would NOT change how they presented and name their supplemental files; possible clashes and confusion with their personal repos. In almost all my spoiler directories I have support files I used to transform a program into prog.c. Some I have created C89 versions from the original K&R C and supply both.
• If prog.c is the obfuscated entry, then maybe name the deobfuscated version program.c (original version needs more "ram" ;-) )

Funny and very clever! :-)

I don't think changing how the author presented it is a good idea either unless it's (for some cases where it's possible) only to make it fit into the new website.

Again I repeat an earlier missive:

I'd suggest NOT building (or cleaning) spoiler/ subdirectories (ohh, just remembered contrib/ is a fav of many, might be better than spoiler/) as part of the build system. These are supplemental to the winner and provided for learning. Leave them to the viewers to play with IMO. I wouldn't fuss with the extra stuff- just provide as-is.

I think contrib/ is the wrong place as this should be from the author only anyway. I think the idea of not building or cleaning these versions has some merit. This would require some changes in entries that do have this (as alt code) but that would not take much work to undo. I quite like your idea that alt code should only be built for things that actually change functionality or fix something.

I don't see an issue with spoiler/ as a directory name, it's commonly used and well understood. If you're still searching for a name Answers/, Bonus/, Contrib/, Exrta/, Other/, Supplemental/.

I don't see an issue with a spoiler/ directory either .. and I prefer it over the others: unless of course the author wants something else .. which here is of course the only person who should be providing this type of thing.

You can tell we're all programmers here. I think it takes a programmer to understand the power of what is in a name of a variable, function, file, object, etc. The original author would have put thought into it to some degree which should be respected.

:-) that's true ... and something to consider too.

Like programmers working on an existing project, we should maintain the "coding & whitespace style" (or editorial style of documentation) of the original, no matter how much we want to scratch that itch to reformat. (I remember being told off about such things in my first professional job after uni.)

I rather agree with this.

So with all this said, Landon, what do you think? I am at loss with the 2020/ferguson1 file rename other than to say it's wrong and I think in many other cases it's wrong too but I don't know what to call them all. One is an image which simply shows the output. I think that 'spoiler' is not only not the wrong word but it is the right and a good word for it. Like 2018/algmyr/deobfuscation.png: not only is it not deobfuscation (if anything maybe would be better to call it deobfuscatd), spoiler works nice. Certainly other things do too but that's just it: a single name shouldn't be necessary. It really depends on the file and the purpose of it (and in the case of spoilers - provided by authors only - who provided it).

Please advise. I can change 2020/ferguson1/deobfuscation.md etc. to spoilers.md but I don't know now ... I would like to. I can see how in SOME cases it might be worth renaming them but not all.

[xexyl]

Okay looking at 2020/ferguson1 again the file name obfuscation.md could work okay .. it all is about obfuscation, some indirectly and others directly. I'll do that for this one but for the others I do not know ..

[xexyl]

The ioccc-am/spoiler/sleep.c is used when building using WatCom C back in the day. I use to build my entries for DOS, AtariST, SysV, and Solaris to test portability. WatCom C on DOS didn't provide any unix/posix support functions then.

Ah. Well it's a fun Easter egg for people to find now. AtariST was the first OS I used. I do seem to recall seeing something about you testing in some of those systems before but unless it was in a README file I don't know where. I have fond memories of SunOS/Solaris too but it's been years since I last used it. I have a mate who had an UltraSPARC and we used to play with it (though for me from a distance ... that was back in the days before ssh).

[xexyl]

In theory you could probably drop the sleep.c, since I doubt anyone will try to build with DOS 3.3 these days or have WatCom C.

I doubt it too but it's a fun addition for people to find and it's already in so why not?

[xexyl]

Commit a4fb0a8 takes care of 199[1-3]/ant. The other two can be decided later (it seems I did 2015 yesterday). What can also be discussed is if the way the build of alt code should be reorganised: it might need it but I'm not sure.

I will look at the index.html files tomorrow .. been at this too long today and I'll be leaving soon most likely.

[xexyl]

I am not convinced the look of the Alternate code and the reference of deobfuscated/ looks good in these three entries and probably the same in 2015 (or at least possibly).

However I do not feel up to fixing it today. Tomorrow should be better. But we still need to discuss the other two years, the ones with configure, before I can do those. Also if you are not sure of using the Makefile in the subdirectory we should talk about that (I was unsure but it does keep it clean). I don't like the directory name deobfuscated that much but I can't think of another word if spoiler is not allowed. I mean it makes sense in these entries but not sure how it looks. Still the way the presentation of it in index.html looks is I think bad.

But I will have to worry about this tomorrow - hopefully with discussion already. I will reply to some comments in another issue and then I will be doing other things for the rest of the day.

[lcn2]

With commit 2e2ae5f we add notices to those who wish for a greater challenge.

We believe this achieves a better convergence to our intent with the fixes and improvements that were made by @xexyl in response to our previous but not very good attempt.

The details:

We add the following level-3 header to help people identify text
they may wish to skip if they wish for a greater challenge:

### NOTICE to those who wish for a greater challenge

After that notice we add:

**If you want a greater challenge, don't read any further**:
just try to understand the program via the source.

If you get stuck, come back and read below for additional hints and information.

And sometimes follow with:

### How this entry works:

Or sometimes follow with:

### What this entry does:

Where the alt code impacts a "greater challenge", we add instead:

**If you want a greater challenge, don't read any further**:
just try to understand the program without looking at the Alternate code.

If you get stuck, come back and look at the Alternate code.

And where a given command impacts a "greater challenge", we add instead:

**If you want a greater challenge, don't read any further**:
just try to understand the program without running the command below.

If you get stuck, come back and run the following command:

[xexyl]

With commit 2e2ae5f we add notices to those who wish for a greater challenge.

We believe this achieves a better convergence to our intent with the fixes and improvements that were made by @xexyl in response to our previous but not very good attempt.

The details:

We add the following level-3 header to help people identify text

they may wish to skip if they wish for a greater challenge:

### NOTICE to those who wish for a greater challenge

After that notice we add:

**If you want a greater challenge, don't read any further**:

just try to understand the program via the source.



If you get stuck, come back and read below for additional hints and information.

And sometimes follow with:

### How this entry works:

Or sometimes follow with:

### What this entry does:

Where the alt code impacts a "greater challenge", we add instead:

**If you want a greater challenge, don't read any further**:

just try to understand the program without looking at the Alternate code.



If you get stuck, come back and look at the Alternate code.

And where a given command impacts a "greater challenge", we add instead:

**If you want a greater challenge, don't read any further**:

just try to understand the program without running the command below.



If you get stuck, come back and run the following command:

Well without having looked at it just yet that does sound like an improvement.

Thanks! The only other question is the directory name. But I will be booting up the laptop next and I can take a look.

[SirWumpus]

The only other question is the directory name.

Dragons/ as in Beyond here be dragons.

[xexyl]

The only other question is the directory name.

Dragons/ as in Beyond here be dragons.

Sorry but would that be Smaug? Scatha? Ancalagon? When you're talking to Landon and me about dragons 🐉 you have to be more specific!

[SirWumpus]

When you're talking to Landon and me about dragons 🐉 you have to be more specific!

Puff https://www.youtube.com/watch?v=Y7lmAc3LKWM

[xexyl]

When you're talking to Landon and me about dragons 🐉 you have to be more specific!

Puff https://www.youtube.com/watch?v=Y7lmAc3LKWM

Hahaha .. well if you're going for magic dragons why not Piff the Magic Dragon?

Anyway I thank you for elaborating!

[xexyl]

Updating manifest now (.entry.json stage) for 1991, 1992, 1993 and 2015. However there still is the question of what to do about 2004 and 2005: as they have a configure script and Makefile templates. How do you want to deal with this, Landon? I can't add these files to finish this issue until this is decided.

.. and I'll be afk soon: I think. But if I do not finish the manifest before then I will do so when I'm back. That will solve the problem from the other day. Hopefully today I can review the changes you made several hours back too: though I think that's probably pretty good. If I get that done then I can finally (!! - unless we decide upon 2004 and 2005: seems good to finish an issue first) get back to formatting fixes up through 1995 I think it was. After that I can then go beyond that and move towards 2020.

UPDATE 0

Just about done .. then will sync to server and take a quick look. Don't expect any problems. A couple other entries had an entry_text changed: changed deobfuscated to unobfuscated and now they're all the same text. Seemed a better word: if only slightly.

[xexyl]

Question for you @SirWumpus.

In 2015/howe you wrote a summary for support files. You left out a summary for avgtime.sh though. Do you wish to provide one? The entry_text in the manifest has: support script .. but that could be improved too. I could come up with something, maybe, but I want to offer you the opportunity first.

[xexyl]

Commit 92139c5 updates the 1991-1993 and 2015 entries plus the manifest for a couple other entries (as the entry_text was made the same wording - unobfuscated).

What remains for this issue is 2004 and 2005 entries but I don't know how we want to have those organised. Please advise, Landon, when you can, so that we can hopefully get this issue resolved soon.

[SirWumpus]

You left out a summary for avgtime.sh

Was only intended to help test basic performance of npdif (mine) verses the system diff(1) (typically GNU). So feel free to apply your wit "in a timely manner".

[xexyl]

You left out a summary for avgtime.sh

Was only intended to help test basic performance of npdif (mine) verses the system diff(1) (typically GNU). So feel free to apply your wit "in a timely manner".

Thanks .. and great pun! I put in the manifest report average time running a command N times and in the README.md file Run time(1) N times on a command to determine average runtime.

I think that works well enough. Unless you think something better can be contrived?

[xexyl]

Oh .. I just remembered the ideas you had about text to have about for a challenge etc. I did not add that to the entries I moved the alt code in. I will be finishing the four up today (except for the one with the pending question/concern) - perhaps you'd like to do this? Otherwise I can look at it tomorrow. I just feel like that issue is taking time away from this issue and it's taking longer than I was hoping :(

[SirWumpus]

the ideas you had about text to have about for a challenge etc

Say woot?

[xexyl]

the ideas you had about text to have about for a challenge etc

Say woot?

What Landon committed. But it I wasn't clear it's because I am very tired. Can try again tomorrow.

[xexyl]

I got hibachi done .. well minus the manifest. That will be fun!

I'll also have to do the other one too. Might as well finish that before doing the manifest.

An odd problem though with hibachi: it seems only the unobfuscated version is working. But perhaps that's due to socket options that were not used (just a guess based on my experience with sockets). Will have to try it in a bit.

[xexyl]

Working on manifest for both .. if all good then this issue can be closed (I think) - once something is decided in another issue (which is a simple fix once it's decided).

The configure script for hibachi was quite annoying but I got it. The mynx one has a configure for both but they're not used: I only added them because they originally were submitted. (Not my doing of not using the script .. if I had my way the other one wouldn't either though once this is resolved that will likely change: a unique thing is very much a good thing).

[xexyl]

Commit 0d65af1 added 2004/hibachi and 2005/mynx. I have not looked at the manifest results as I haven't got to those years yet but I suspect that there won't have to be any real changes if any at all (unless it is decided that the order of files should be changed).

This means that this issue is almost resolved - just the one thing we've been discussing. But I am off for the day. Back tomorrow!

[xexyl]

Looking at commit 2e2ae5f now but also made a change in the heading name used (added a ':'). When those files are rebuilt (quick_readme2index is taking longer as I used sgit and should have done on all rather than just .md files) I'll sync to server and then look at those entries - or at least those of the years I have already checked. After that I'll see if I can figure out the problematic file and entry_text for the one entry here. If I can then I think this issue can be closed as complete. Otherwise we will have to work that out.

It would be nice if this can be marked complete as I could then move forward on the other issue in important ways.

I also have to update the FAQ today but that shouldn't take much time I think.

What else I'll do today I really don't know. I'm pretty worn out but it's also early enough where it's quite possible I'll be doing more.

[lcn2]

Thank you @SirWumpus and @xexyl

[xexyl]

Thank you @SirWumpus and @xexyl

You are most welcome .. though it's not completely resolved yet. Nonetheless it's about to be. I'll make a commit very soon: within minutes at most.

[xexyl]

Commit 88d8a30 should be it!

Now (or next time I look at the repo .. not sure how much more I'll do here today) I can look at the 'look and feel' issue again.