Enhancement: Less obfuscated versions of some winners

SirWumpus commented 2 weeks ago

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 commented 2 weeks ago

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

xexyl commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 2 weeks ago

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 4d37308d120cca180a7c0dee3e128c145dd7c907 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 4d6009b58fa56e966818fc4b42d8741ec4f64e73, and commit 3aec80f057cf4863a41fba40e2039293694aead1, and commit 85c991620f605d3905f386d52fe3ed3a2a32fa85, and commit 5dd3311e9ef36b4570cd972b6d1ec327ae7a4c78: 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 commented 1 week ago

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 commented 1 week ago

.. 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 &#x28;manual&#x29; and computer playing &#x28;automatic&#x29; 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 &#x28;i.e., decreasing the iocccsize&#x29;](#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 commented 1 week ago

.. 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 &#x28;manual&#x29; and computer playing &#x28;automatic&#x29; 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 &#x28;i.e., decreasing the iocccsize&#x29;](#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 commented 1 week ago

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 commented 1 week ago

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 commented 1 week ago

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 ..

SirWumpus commented 1 week ago

I think the idea of not building or cleaning these versions has some merit.

I'm assuming that a viewer is cloning the winners repo (or portion thereof) from GitHub. If the viewer really wants a pristine tree, git clean -f will do the trick. So there are other ways to clean the tree without having to fuss with nested makefiles.

xexyl commented 1 week ago

I think the idea of not building or cleaning these versions has some merit.

I'm assuming that a viewer is cloning the winners repo (or portion thereof) from GitHub. If the viewer really wants a pristine tree, git clean -f will do the trick. So there are other ways to clean the tree without having to fuss with nested makefiles.

Well that's another matter entirely and it's not necessarily the case as there are tarballs to download too. The make clean and make clobber rules are important but whether the spoiler code should be compiled or not I guess depends on if it offers any functional difference from the entry. Some is already set in alt code though so it might not be worth to worry about changing them all back .. but whether any additional ones added in the future should be compiled is another matter.

xexyl commented 1 week ago

2020/ferguson1 almost done. Would have been done earlier if I had updated the entry_text properly first. I could use sgit(1) of course but just running the script I wrote ... will be done soon. The rest I can look at later. I hope to finish other things here today and I can worry about this issue later after discussion.

xexyl commented 1 week ago

Commit https://github.com/ioccc-src/temp-test-ioccc/pull/2526/commits/e5bcf2ee25a17b43bf72337f4c07bd60ec7fc9e2 fixes 2020/ferguson1 .. but many others probably need to be corrected, I am afraid. Discussion required first.

Will be going afk very shortly but when back I hope to look at the other stuff: where I left off yesterday.

SirWumpus commented 1 week ago

This is going off-topic slightly (maybe spin a separate issue/discussion for it).

... as there are tarballs to download too.

Why? Seems like lots of extra work on top of what git already provides. Viewers can always use git sparse-checkout to grab specific directories, rather than the whole repo. Seems like maintaining tarballs along side what git does it a lot of fuss.

What is sgit(1)?

xexyl commented 1 week ago

This is going off-topic slightly (maybe spin a separate issue/discussion for it).

Somewhat related :-)

... as there are tarballs to download too.

Why? Seems like lots of extra work on top of what git already provides. Viewers can always use git sparse-checkout to grab specific directories, rather than the whole repo. Seems like maintaining tarballs along side what git does it a lot of fuss.

Convenience. See FAQ 3.20 - How do I download individual winning entries or all winning entries of a given year?.

What is sgit(1)?

A very useful tool I wrote that lets one run sed on all (or select) files in a git repo .. with a lot of really nice features. See sgit repo. Landon has actually used it in another repo (his calc repo if I'm not very much mistaken).

Only relevant here in that it made it easier to update things (related to spoilers to deobfuscation change). Of course one must be careful to edit the right things only but that always goes.

lcn2 commented 1 week ago

This is going off-topic slightly (maybe spin a separate issue/discussion for it).

... as there are tarballs to download too. Why? Seems like lots of extra work on top of what git already provides. Viewers can always use git sparse-checkout to grab specific directories, rather than the whole repo. Seems like maintaining tarballs along side what git does it a lot of fuss.

We considered dropping the compressed tarballs altogether in favor of people just using git(1) (and things like git sparse-checkout). However we received pushback and so we relented to providing compressed tarballs for each entry and for a given year to make it easy for non-git users to download entries for a new IOCCC year.

We did draw the line at not providing a tarball for everything. For everything, for multiple years, for almost everything they will need to use git / clone the repo.

xexyl commented 1 week ago

This is going off-topic slightly (maybe spin a separate issue/discussion for it). ... as there are tarballs to download too. Why? Seems like lots of extra work on top of what git already provides. Viewers can always use git sparse-checkout to grab specific directories, rather than the whole repo. Seems like maintaining tarballs along side what git does it a lot of fuss.

We considered dropping the compressed tarballs altogether in favor of people just using git(1) (and things like git sparse-checkout). However we received pushback and so we relented to providing compressed tarballs for each entry and for a given year to make it easy for non-git users to download entries for a new IOCCC year.

We did draw the line at not providing a tarball for everything. For everything, for multiple years, for almost everything they will need to use git / clone the repo.

FWIW I'm glad the tarballs are there. That might seem odd as I have multiple copies of it now but it's a nice to have feature for a smaller download. Not necessary with 8TB but even so the repo is quite large and some people might not want to download it all - or might not want to get into git or its workings.

I mean after all, who likes to deal with gits [0]? :-)

[0] Technically speaking :-) he's right about the pronunciation. He's not right, however, to say that git is slang. It's not. It's certainly considered derogatory but it's absolutely not slang. Still the README is very funny ...

xexyl commented 1 week ago

Now as far as the name 'deobfuscation' for file names I think it is a mistake to do it all this way without considering the name and I think it's a mistake to make it the default name.

In the case of 2020/ferguson1 (thanks for the fix to index.html that I missed btw) obfuscation works as a name because it was all about the obfuscation (indirectly but also directly). But let's consider a different one of 2020: endoh2. That directory has some commented code but not much and what it really is, the purpose of that directory, is to show how he formatted the code. The judges' remarks also ask the question:

With the source from the [deobfuscation](deobfuscation/index.html) directory could you make the code
render for a larger terminal window?  How about adding more glyphs?

but it used to read, of course, spoiler, instead of the change. But this question seems odd: if it's deobfuscated (which it's not really) then shouldn't it be easy to make the changes?

Now in this case the question of whether 'spoiler' is the right word is a valid question. But I don't think 'deobfuscation' is the right word either. Yusuke had it as 'spoiler' and I think it might be, as @SirWumpus said, right to keep it that way.

Okay there were some cases where I renamed files, sometimes maybe not necessary (as it turns out it wouldn't be but these were done before the manifest and how to view - GitHub or download - was figured out).

One might not have been necessary at all: a matter of semantics only and I have on more than one occasion thought of reverting that change for that reason ('olympic' to 'olympics'). The question is whether it refers to the games or is the games. The problem is determining this though as I don't have a shortwave radio .. or if I do (no idea now) it certainly cannot work with this. So with that in mind I've renamed it to what it was but I'll have to update the manifest another time (let me rephrase that: commit the manifest changes). The fact the manifest just says 'sample input' is not very useful for this but it probably should never have been changed in the first place, even more since it's not possible for me to see what it does (not really see it). It was done hastily and that's why I will change it back. it would be nice of course if we could have a better description though.

But in general I think if an author provides a spoiler version it might be good to keep the name as they provide it.

A question of consistency might arise here but the thing is: different authors do things differently (of course and as we would want) so we can't really aim for consistency. In the html files that were spoiler.html I think that's a good name for what they do: typing out how it was programmed (at least that's what I gathered from it .. as you can probably imagine I never watched more than a few seconds of it).

So if consistency of names of files cannot be or should not be the goal what should they be called? If we want to rename all versions that are less obfuscated (or something else - as referenced above not all of these files are about deobfuscation as such) where do we draw the line?

There are many entries, mine and others, that could have files renamed but which do they need to be renamed?

Also, one more thing to consider: as long as the entry_text of the manifest is correct does it really matter what the name is? And although this might not be the case (I have not verified this btw) we have to remember that some names are hardcoded into obfuscated code and changing the names could break the code. If it's just the file name we can change it to __FILE__ (as you did for some and I did for others and maybe others did too) but this is not always the case. I distinctly remember one case where I could not use __FILE__ actually.

Of course if these should be considered (and I think they should be, especially the paragraph right above this) then the question is how to go about changing the names back. In some cases it might be okay but I remember that a lot of the files (probably most if not all) that are now called 'deobfuscation' are actually just less obfuscated but they are not not obfuscated. And to be pedantic (sorry :-) ) deobfuscation sounds like how it might be done rather than it being done. But as noted this is not usually the case.

Just some things to think about. As this is not a high priority issue I won't worry about it for now (other than the one change above I noted) but rather let this be thought about and we can have any discussion that might be necessary or useful.

lcn2 commented 1 week ago

Fair points raised in comment-2204483053.

One may wish to reconsider parts of commit 4d6009b58fa56e966818fc4b42d8741ec4f64e73, and commit 3aec80f057cf4863a41fba40e2039293694aead1, and commit 85c991620f605d3905f386d52fe3ed3a2a32fa85, and commit 5dd3311e9ef36b4570cd972b6d1ec327ae7a4c78.

UPDATE 0

In general the shift away from "spoiler" versions and towards "debofuscated" versions is a good thing.

Sure, a few mistakes were made and some of those have been fixed already.

A review of commit 4d6009b58fa56e966818fc4b42d8741ec4f64e73, and commit 3aec80f057cf4863a41fba40e2039293694aead1, and commit 85c991620f605d3905f386d52fe3ed3a2a32fa85, and commit 5dd3311e9ef36b4570cd972b6d1ec327ae7a4c78 should be done as part of the issue #2006 work needs to be done as that might turn up a few more places where the change needs to be improved.

We will add a note into issue #2006 to that effect.

UPDATE 1

Please review the URLs in the top comments and see if those should and can be incorporated into their respective entries as "debofuscated" versions.

xexyl commented 1 week ago

Fair points raised in comment-2204483053.

One may wish to reconsider parts of commit 4d6009b, and commit 3aec80f, and commit 85c9916, and commit 5dd3311.

UPDATE 0

In general the shift away from "spoiler" versions and towards "debofuscated" versions is a good thing.

Sure, a few mistakes were made and some of those have been fixed already.

A review of commit 4d6009b, and commit 3aec80f, and commit 85c9916, and commit 5dd3311 should be done as part of the issue #2006 work needs to be done as that might turn up a few more places where the change needs to be improved.

We will add a note into issue #2006 to that effect.

UPDATE 1

Please review the URLs in the top comments and see if those should and can be incorporated into their respective entries as "debofuscated" versions.

I left comments in that other issue including a request that would be very helpful. I'm not sure the best way to go about doing this but I believe that it should be done before the continuing the rest of the work with that issue. I think git cinfo will be sufficient to tell me files modified but what would be helpful is to have another alias like cdiff but that shows the diff between the commit and the previous commit. There are many changes made.

But I wonder .. maybe any of the files that were modified were actually called spoiler or spoilers? That might help some but the question then is: was there text that did not refer to files also changed?

I do have a copy on backup of the repo prior to the changes though I have to mount the disk.. I really should fix the fedora box *sigh* ... but not yet .. not yet.

xexyl commented 1 week ago

Okay copied the older copy (the only good thing from the stupid mistake I made at the stupid hour I was doing it at on the fedora box .. but getting dangerously close to EOL :(( ) to the /home on the server and just rsynced to the laptop as ~/code/old-temp-test-ioccc/. The downside is a lot of other things have also changed so I'm not sure how useful it's going to be except for filenames: which admittedly are not many. Problem is there have been many other filenames changed as well since that was last pulled ...

I suppose you don't have any idea what changed, do you Landon?

UPDATE 0

Removed write access to .git/ .. not sure if that's all that should have write access removed from but at least I cannot pull (completely?) by accident. Though of course I still have a copy on backup and on the server /home volume.

UPDATE 1

.. hmm that might not be very useful after all: last commit in August last year :( I thought i had updated it more recently .. though I also might have had two copies .. will have to check. If it's from August last year it's probably not useful at all or barely useful.

In which case having some kind of idea of what was changed (words in text and otherwise) would be helpful. I know that the files that are the new name were probably either spoiler or spoilers and I might be able to determine the file names that might want to be changed back but what else is there, Landon? Please advise as I feel like maybe this should be done before the other things .. though maybe I could fix the formatting of the entry I last stopped at. That would I think work. If I can get it to work okay. Unfortunately in 20 minutes or under 20 minutes I have to go for a while and it'll likely be some hours before I can really do much work. I hope that I can do more when I'm home again but that will depend on a lot of factors. At least I slept in a bit .. woke. up close to 3:30 or 4.

UPDATE 2

The proper copy was last pulled 27 January 2024 .. ouch .. that means I'm almost out of time for the fixing of the system :(( and it's such a burden .. if only anaconda did md+lvm well.

... ugh .. fedora 39 and 41 is in development.

xexyl commented 1 week ago

I figured out the spoiler versus otherwise: if nothing but the filenames and text of the words 'spoiler' and 'spoilers' were changed. I just did a pull and then checked out the commit immediately before you started.

Then i did..

git ls '*spoiler*'
git grep -il spoiler '*md'

to get a list of files that have the word spoiler in it (though I do recall now I think on it an upper case file) and then the list of files that have the word, case insensitive, 'spoiler' (or of course 'spoilers').

Now I can do a diff on the two directories too and see what was changed: I hope.

The question is how to go about the naming. It might be better to just change it back to what the authors had but I'm not sure yet: it seems like you might want otherwise but I think keeping the author's filenames the same (or close to the same: a few changed like spoiler1 to spoiler and some others that were not named to a way that might suggest what they are). The text is easy to fix with sgit(1) of course though I have to check all the cases too.

xexyl commented 1 week ago

Now as far as the URLs in the top comment here I think that should be addressed only after the other files are checked. The question is will the subdirectory work? And another question is should they be compiled? I think in this case at least they should not.

Another problem I just thought of: if any prog.alt.c files were changed then those are missed in the above commands.

xexyl commented 1 week ago

Some files can have the text of deobfuscation kept in I think. 1989/paul for instance I think works well enough. I'm not sure entirely: spoiler is not maybe the right word but the other is not either. But it is also in the judges' remarks and it might be, for historical purposes, better to revert it. It is true that many entries had the remarks changed but in this case I'm not sure if that is one that should be changed. I wonder.

UPDATE 0

I think the original remarks look and sound better.

xexyl commented 1 week ago

In some cases 'obfuscation' works well and probably better than 'spoiler' but certainly better than 'deobfuscation' as it describes how it is obfuscated rather than how to deobfuscate it - so I have changed those though I have quite a few files to look at I think. That's not considering the files being renamed: that will come after the text .. I think.

xexyl commented 1 week ago

Making good progress ... my lessdiff script is proving very useful. I will be going afk for a bit soon though .. and not long after that I will have to leave for a while. I hope to at least finish this task today, however.

xexyl commented 1 week ago

Well I just went through 2004/hibachi and I think that's a good place to stop for now .. will do more later. As a reminder to myself the command I used:

lessdiff -r . ../xexyl-temp-test-ioccc

Back later.

xexyl commented 1 week ago

Okay I must leave now (or very shortly) but when I'm back I hope to fix the rest of the changes. That depends on how I feel but if I do it will require some effort and the manifest will have to be updated. I expect having to do this a few times to make sure everything is in order. I could possibly get away with the quick_readme2index rule but to be safe I'll do the www one - which of course a fair amount more time to complete.

I guess after that I will not be up to anything else but we'll see. The weather is not helping matters of course. Hopefully no power outage today.

Anyway back later and hopefully this first part will be done. Then I will look at the information from @SirWumpus and after that go back to the other tasks of #2006.

lcn2 commented 1 week ago

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

xexyl commented 1 week ago

Almost done with the fixes .. have to update manifest but first going to run test on the links.

What would be very helpful is if you could update the DATA variables in the Makefile if necessary: I'm not sure it affects all entries.

Seeing a list of renaming when merging would make it easier I think. BUT I wonder what the purpose is anyway? Do we really need the compilation of the programs to depend on DATA? Even so the variable should be updated to be consistent with filenames.

xexyl commented 1 week ago

.. that being said I must go afk .. quite a while I think: at least an hour I think.

xexyl commented 1 week ago

No missing links: at least not direct to repo link: if any are missing in %%REPO_URL%% or similar I don't know. For reference for the DATA variable this might be useful for filename changes and maybe I can take care of it looking at this list:

renamed:    ../../1995/leo/deobfuscation.html -> ../../1995/leo/secret.html
renamed:    ../../1995/leo/deobfuscation.md -> ../../1995/leo/secret.md
renamed:    ../../2004/hibachi/src/localhost/CHANGES-DEOBFUSCATED.TXT -> ../../2004/hibachi/src/localhost/CHANGES-SPOILER.TXT
renamed:    ../../2012/omoikane/deobfuscation.html -> ../../2012/omoikane/obfuscation.html
renamed:    ../../2013/misaka/deobfuscation.html -> ../../2013/misaka/obfuscation.html
renamed:    ../../2014/endoh1/deobfuscation.html -> ../../2014/endoh1/quine-qr.html
renamed:    ../../2014/endoh1/deobfuscation.md -> ../../2014/endoh1/quine-qr.md
renamed:    ../../2014/sinon/deobfuscation.html -> ../../2014/sinon/obfuscation.html
renamed:    ../../2015/burton/deobfuscation.html -> ../../2015/burton/obfuscation.html
renamed:    ../../2015/burton/deobfuscation.md -> ../../2015/burton/obfuscation.md
renamed:    ../../2015/howe/deobfuscation/Makefile -> ../../2015/howe/deobfuscated/Makefile
renamed:    ../../2015/howe/deobfuscation/err.h -> ../../2015/howe/deobfuscated/err.h
renamed:    ../../2015/howe/deobfuscation/prog.c -> ../../2015/howe/deobfuscated/prog.c
renamed:    ../../2015/yang/deobfuscation.html -> ../../2015/yang/obfuscation.html
renamed:    ../../2018/algmyr/deobfuscation.png -> ../../2018/algmyr/spectrogram.png
renamed:    ../../2018/yang/deobfuscation.html -> ../../2018/yang/obfuscation.html
renamed:    ../../2019/adamovsky/deobfuscation.c -> ../../2019/adamovsky/deobfuscated.c
renamed:    ../../2019/yang/deobfuscation.html -> ../../2019/yang/obfuscation.html
renamed:    ../../2020/endoh2/deobfuscation/code.c -> ../../2020/endoh2/obfuscation/code.c
renamed:    ../../2020/endoh2/deobfuscation/gen.rb -> ../../2020/endoh2/obfuscation/gen.rb
renamed:    ../../2020/endoh2/deobfuscation/glyphs.txt -> ../../2020/endoh2/obfuscation/glyphs.txt
renamed:    ../../2020/endoh2/deobfuscation/index.html -> ../../2020/endoh2/obfuscation/index.html
renamed:    ../../2020/endoh2/deobfuscation/index.md -> ../../2020/endoh2/obfuscation/index.md
renamed:    ../../2020/endoh2/deobfuscation/prog.c -> ../../2020/endoh2/obfuscation/prog.c
renamed:    ../../2020/endoh2/deobfuscation/tmpl.txt -> ../../2020/endoh2/obfuscation/tmpl.txt
renamed:    ../../2020/yang/deobfuscation.html -> ../../2020/yang/obfuscation.html

..but that can come later .... will start the manifest update script and then will be afk a while .. I do have some other things to take care of when I'm back, too, I'm afraid, but I might be able to do it in between things.

xexyl commented 1 week ago

Actually I'll do this when I'm back (here just a moment) and then do a commit: everything else in order I think. I do have an idea for something else that belongs in another issue but I can't say it now as I have to leave again ... hopefully remember it.

xexyl commented 1 week ago

With commit https://github.com/ioccc-src/temp-test-ioccc/pull/2541/commits/1ac055fa85daccab8e09a86f6a7681eef69afea2 the wording situation should be in a much better state.

The next step with this issue is to add the files linked to in the top comment. I am not sure if I will get to that today or not: it's one of those days. But I would like to so that I can then get to seeing how this looks. There is something I need to do though and there is something I should do and I'll be doing those first. I am sure I will manage to do more here today but this is a good change.

And I took care of the DATA variable. Some were not even used (empty) so I didn't worry about those. Some I added files (since they already had some). I still wonder if:

# alternative executable
#
alt: data ${ALT_TARGET}
        @${TRUE}

${PROG}.alt: ${PROG}.alt.c
        ${CC} ${CFLAGS} $< -o $@ ${LDFLAGS}

is a good idea though. In that case it was once prog also but I removed it: it's in 2020/ferguson1. But there are other entries that are not mine that also have this and it means that if a file is missing or is renamed and the Makefile is not updated it fails to compile. In fact when this repo was created (or the winner one) and the files were renamed from .text to .markdown (or whatever they were .. not sure if all were immediately named .md but I do know that hint files were renamed by me to README.md files at your request) it prevented 2020/ferguson1 from compiling and for a while I had on my site a tarball with the fixes.

ioccc-src / temp-test-ioccc