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

[lcn2]

With commit 1ac055f the wording situation should be in a much better state.

We agree that there are a number of improvements to in that commit.

There are a few places what the term "spoiler" was re-introduced that we need to ponder.

Our initial guess is that we might accept the pull request as is, and reconsider a few of the changes in a later commit.

We need to study the effect of this pull request some more.

[xexyl]

With commit 1ac055f the wording situation should be in a much better state.

We agree that there are a number of improvements to in that commit.

There are a few places what the term "spoiler" was re-introduced that we need to ponder.

Our initial guess is that we might accept the pull request as is, and reconsider a few of the changes in a later commit.

We need to study the effect of this pull request some more.

I just gave you there two examples where it cannot possibly work otherwise. There are others. The problem with it is that many of them are not about obfuscation or deobfuscation. In many cases the deobfuscation does not work well at all. And the ...we'll stop spouting spoilers... one would not work with deobfuscation information either. it has nothing to do with deobfuscating the entry. It simply is a summary of what it is. So there are more examples where it would not work.

I think to be that against the word spoiler is the wrong way to go about it. It works better than the proposed suggestions in some cases and in some cases it's the right word. In other cases there are no better words that I can think of off the top of my head but seeing the changes in the web pages might help figure it out.

[xexyl]

Anyway I must go for now .. will likely be a couple hours or so. Not sure what I can do after that but it also kind of depends on this.

[xexyl]

Quickly .. just thought of an alternative for stop spouting spoilers. Summaries. Brief descriptions. But it doesn't have quite the same feeling. But it could be done. Afk now.

[lcn2]

Quickly .. just thought of an alternative for stop spouting spoilers. Summaries. Brief descriptions. But it doesn't have quite the same feeling. But it could be done. Afk now.

That is a very interesting idea 💡 @xexyl.

As we mentioned elsewhere, our inclination is to accept the pull request as it is now (after studying it first) and then ponder suggestions such as the one you made above.

[xexyl]

Quickly .. just thought of an alternative for stop spouting spoilers. Summaries. Brief descriptions. But it doesn't have quite the same feeling. But it could be done. Afk now.

That is a very interesting idea 💡 @xexyl.

As we mentioned elsewhere, our inclination is to accept the pull request as it is now (after studying it first) and then ponder suggestions such as the one you made above.

Okay .. I hope you do accept it but if not please let me know what you want changed so I can fix it as it would be a lot of work to do it all again and not nearly as much work to fix.

Thanks.

[xexyl]

Just took a few minutes to look at the first one .. one file had a few compilation errors. Resolved those. Updated Makefile (to be more GNU like so it would compile to the right file name). Updated README.md. Will check the index.html file. Will update manifest too. But I won't do the manifest update until the other entries are looked at as well.

[xexyl]

Okay before I do the manifest update ... a general question. Should these become alt versions in the entry directory or should they be put in a subdirectory deobfuscated? Both ways are used in the repo in different entries. What if there already is an alt version?

If there's any use of a try script (like there is for 1992) then it would be better to have it as an alt file, assuming we want it to compile, but if not it might be better in a subdirectory?

The discussion of whether or not to compile it if it has no functional difference comes up. On the one hand it seems like it might not be useful but on the other it might help people explore how the original one worked if they can compile both (that's how I'm looking at it now).

So I think what I'll do is I'll get these to compile and then before I do a commit (or update the manifest) we can discuss this. That will delay completing this issue but hopefully not by very long.

[xexyl]

But for now I have to go afk a while ... and it very possibly will be a slow day. Feeling off. I hope that will change but it's possible. Still I guess I will be able to get these all in today even if it has to be changed somewhat.

[xexyl]

Okay before I do the manifest update ... a general question. Should these become alt versions in the entry directory or should they be put in a subdirectory deobfuscated? Both ways are used in the repo in different entries. What if there already is an alt version?

If there's any use of a try script (like there is for 1992) then it would be better to have it as an alt file, assuming we want it to compile, but if not it might be better in a subdirectory?

The discussion of whether or not to compile it if it has no functional difference comes up. On the one hand it seems like it might not be useful but on the other it might help people explore how the original one worked if they can compile both (that's how I'm looking at it now).

So I think what I'll do is I'll get these to compile and then before I do a commit (or update the manifest) we can discuss this. That will delay completing this issue but hopefully not by very long.

Okay obviously in some they have to be a subdirectory as there are other files like a test Makefile and so on. So maybe because of that to make the entries consistent they should all be a subdirectory. I'll do that .. when back.

[xexyl]

I have come up with what I think is a nice way to present the files. The am one was giving me some issues but I got it sorted. It does change the way the Makefile alt rule looks but it keeps the deobfuscated/ directory clean. I will be leaving for a bit soon possibly but when back I will work on the next one. After the files are in I can update the README.md files and then I can update the manifest.

[SirWumpus]

What challenge did am give you? Asking for a friend.

[xexyl]

What challenge did am give you?

It was not am itself but integrating it into the Makefile in a way that works with the alt model.

Asking for a friend.

Of course you are ... yourself? Or maybe your √-1 friend? :-)

[xexyl]

.. although I wonder if this is desired, to separate it like this. I don't really know. I think it helps with identifying it as being deobfuscated code but maybe it should just be alt in the entry directory. The main reason I have it in the subdirectory is you have provided Makefiles and the main Makefile uses them for the alt build.

Well we'll see I guess. It can be changed in how it's organised later.

[xexyl]

1991, 1992 and 1993 done except for the manifest. Will work on the next ones now.

[xexyl]

Hmm ... well hibachi ought to be fun!

I am not sure how to best go about this. I think for starters I'll just add the code to the subdirectory and update the manifest and README.md file to note it. Then it can be decided how to best approach building it.

UPDATE 0

Maybe mynx will be the same but not sure yet.

[xexyl]

• 2005 https://github.com/SirWumpus/ioccc-mynx (original http: version)

Question for you @SirWumpus. I see 'original http: version'. Does that mean you have a https version? If you do would you share it? I had added alt code that scans (but only scans) in case someone wanted to try and get a command line that might work out (what that would be I don't know) but obviously if you have a version that works with https that would be better and I would happily add it for you. As one of the files says: without this it might just have to be an entry that can be enjoyed for what it is, without it working for many websites.

Let me know and we can go from there.

[SirWumpus]

I never had an https version of mynx. I think someone did a conversion. Otherwise I can look into it this weekend.

[xexyl]

... actually on second thought I'm not going to do 2004/hibachi right away. There are too many questions that have to be answered first: should it use the configure script is a good example. But then it also has the Makefile template and it would all have to be updated to not have the -spoiler part.

[xexyl]

I never had an https version of mynx. I think someone did a conversion. Otherwise I can look into it this weekend.

That would be excellent if you would like to do that! It would mean the entry could be used with the IOCCC website again, for example. Of course it's been a long time so maybe it's harder to get the same ... and setting up https isn't exactly fun (or so I think - I haven't enjoyed it with sockets anyway, getting encryption to work, usually opting for stunnel).

[SirWumpus]

One of the things about hibachi as winner, was that it supplied a configure script, so it really should appear in the build process. I think you want an ioccc.mk and the hibachi configure and Makefile.in. Have the root level Makefile either invoke hibachi/ioccc.mk or have the root go directly to the configure/makefile. \Gotta love me!</>.

[xexyl]

Okay @lcn2 I have 1991, 1992 and 1993 sorted though it might be that we want to reorganise how these deobfuscated versions are built.

However the question is how to go about hibachi and maybe mynx with their configure scripts and such. One thought is that I could run ./configure and add the generated files and then have the entry's Makefile updated along the lines of how the original entry build works.

In one case at least one would have to remove -spoiler and just have the name hibachi (not sure if mynx has that form yet) but this should not be a problem.

[xexyl]

One of the things about hibachi as winner, was that it supplied a configure script, so it really should appear in the build process. I think you want an ioccc.mk and the hibachi configure and Makefile.in. Have the root level Makefile either invoke hibachi/ioccc.mk or have the root go directly to the configure/makefile. Gotta love me!</>.

Yeah you're right. Hence the comment I just posted. It might be the way to go about it but it has to be discussed first I think. Same possibly with mynx.

[xexyl]

Okay @lcn2 I have 1991, 1992 and 1993 sorted though it might be that we want to reorganise how these deobfuscated versions are built.

However the question is how to go about hibachi and maybe mynx with their configure scripts and such. One thought is that I could run ./configure and add the generated files and then have the entry's Makefile updated along the lines of how the original entry build works.

In one case at least one would have to remove -spoiler and just have the name hibachi (not sure if mynx has that form yet) but this should not be a problem.

These same questions apply to mynx too as I thought. Or maybe that's as I feared :-)

[SirWumpus]

You got to love winners that make life ... interesting.

Hibachi Sidebar fact: The code took about two days to write, while animated gif logo took about 5 days to design each frame and build up the .gif.

[SirWumpus]

BTW a mynx with https support would be need a configure script :) to get all the libs in correct.

[xexyl]

You got to love winners that make life ... interesting.

Yes indeed. I think that all winning entries have this in some form or another but the configure scripts were a unique thing for those two to be sure.

But I have to say that whatever the answers to these questions are, they will probably not be as complicated as fixing entries to not use -traditional-cpp - for one example kind of fix I had to do (unfortunately clang does not support it). Still those two entries will complicate matters.

The nice thing is that I already did 2015/howe so I can now just update the manifest and once it has been decided how to do the other two those can be done and then this issue can hopefully be closed.

Hibachi Sidebar fact: The code took about two days to write, while animated gif logo took about 5 days to design each frame and build up the .gif.

Interesting. I did have to fix links - some probably to refer to the Internet Wayback Machine and maybe other issues besides in the html files.

I have had a similar experience but a different kind. I guess we all have: the things that you might think would take longest actually go relatively quickly but the simplest (sounding) things take a lot longer.

[xexyl]

BTW a mynx with https support would be need a configure script :) to get all the libs in correct.

Well considering you already supplied a configure script ... :-)

[xexyl]

The c89 file is to work for C89 or is it more like to look like c89? At a quick glance it seems to use ANSI style functions so I'm not sure.

[SirWumpus]

The c89 file is to work ...

Which entry you referring too? In my spoilers ae-c89.c and ag-c89.c (I doubt I got around toam-c89.c) are conversions from the original K&R source to something that will compile with -std=c89 or higher. New compilers complain about K&R C unless you turn on an -std for it (gcc supports K&R just, but I don't think clang does).

[xexyl]

The c89 file is to work ...

Which entry you referring too? In my spoilers ae-c89.c and ag-c89.c (I doubt I got around toam-c89.c) are conversions from the original K&R source to something that will compile with -std=c89 or higher. New compilers complain about K&R C unless you turn on an -std for it (gcc supports K&R just, but I don't think clang does).

Right but I got the other version to compile too - though with a few fixes necessary. But that answers the question: it's a conversion from the original K&R. But this brings up the question of what the original .. aha. I see what you mean, maybe: that might explain why I had to fix the version that was not c89 but the c89 worked. Is that so?

[xexyl]

The c89 file is to work ...

Which entry you referring too? In my spoilers ae-c89.c and ag-c89.c (I doubt I got around toam-c89.c) are conversions from the original K&R source to something that will compile with -std=c89 or higher. New compilers complain about K&R C unless you turn on an -std for it (gcc supports K&R just, but I don't think clang does).

As far as clang and -std= it does support it but it certainly is a much more strict compiler and it is the reason that many entries had to be fixed, especially as macOS would not work even if you invoke it as gcc (it is clang): the default install does not have gcc; you have to install it with MacPorts or Homebrew or compile it yourself.

[SirWumpus]

... not c89 but the c89 worked. Is that so?

Yep. The C89 versions should compile without errors.

As far as clang and -std= it does support it but

clang has a -std option but I don't not think tit has a K&R standard setting, eg. -std-knr. I tried looking last year.

gcc will detect K&R and I recall there is some option to enable to silence some errors or warnings concerning the K&R function declarations.

[xexyl]

... not c89 but the c89 worked. Is that so?

Yep. The C89 versions should compile without errors.

They did fine yes. I figured it was the opposite purpose which is why it surprised me.

As far as clang and -std= it does support it but

clang has a -std option but I don't not think tit has a K&R standard setting, eg. -std-knr. I tried looking last year.

It might not have a knr to it, no. If you didn't see one then it's extremely unlikely it was added. It has some defects or at leat some features that break older code that shouldn't really break. Some code obviously does break over time but some I think should not break. The C committee of course is not a help there.

gcc will detect K&R and I recall there is some option to enable to silence some errors or warnings concerning the K&R function declarations.

Yes gcc is far more forgiving in things that clang is against - including things that seem questionable. Fortunately it was easy to fix the other one for clang. Just a couple minor things.

[xexyl]

... updating manifest .. will take a bit of time but when done I will do a pull request. Then it's a matter of figuring out hibachi and mynx. After that this issue can be closed (I guess). Though I will probably not check the links until tomorrow as I have been at it too long.

[SirWumpus]

I've added an am-c89.c to my personal repo spoiler directory. You probably don't need it since it was actually pretty small and straight forward K&R to C89 clean-up.

https://github.com/SirWumpus/ioccc-am/blob/master/spoiler/am-c89.c

[xexyl]

I've added an am-c89.c to my personal repo spoiler directory. You probably don't need it since it was actually pretty small and straight forward K&R to C89 clean-up.

https://github.com/SirWumpus/ioccc-am/blob/master/spoiler/am-c89.c

Probably not needed indeed since I got the other one to compile. But maybe to be consistent it should be added. What do you think, Landon? Should I add it? If yes I can do that .. tomorrow. Should be done updating the manifest soon - I hope. The spreadsheet and CSV file have been updated some time ago and just waiting on the scripts to finish.

[xexyl]

You might enjoy something too Anthony that I put in the entry_text in your sleep.c file:

author provided code for those who need a nap

so the link in the index.html will look like:

I did this because I did not know the real purpose of it, it amused me and I thought you and Landon would find it amusing too. But I won't note it in the changelog .. let people discover it for themselves.

[SirWumpus]

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.

[SirWumpus]

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.

[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 https://github.com/ioccc-src/temp-test-ioccc/pull/2543/commits/a4fb0a8c8ca85751e2069a7e814a282894a66756 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 2e2ae5f132f2e4f7f60ad8c275038c8db506c7ec 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 2e2ae5f132f2e4f7f60ad8c275038c8db506c7ec 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!