search

ioccc-src / temp-test-ioccc

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

Enhancement: improve the look and feel of the constructed HTML files #2006

Open lcn2 opened 8 months ago

lcn2 commented 8 months ago

All generated HTML web pages are covered by this issue.

This issue covered all generated HTML files, including generated entry index.html files, top level web pages (both constructed form data such as authors.html and years.html as well as top level HTML files generated from markdown such as judges.html and news.html) and year level 'index.htmlweb pages,bin/index.htmlandarchive/historic/index.html`, etc. If the web page is generated or updated by a bin tool, then that page a candidate for this include the "look and feel" issue.

This issue focuses on these web pages "look and feel".

This is NOT about fixing content errors. (Well if you see something glaring, go ahead and fix it). This is about how the generated HTML pages look in a web browser.

Here are the types of questions ask about a generated HTML web page as viewed in a browser:

We are NOT focusing on the accuracy of the generated web page per se (although if you see something glaring, feel free to fix it under the guide of something that slipped passed the issue #3 effort). We are focusing on HOW it LOOKS with an emphasis on correcting dysfunctional presentations.

In many cases, corrections can be addressed by editing some markdown file such as the entry's README.md file. Please modify the entry's README.md file and re-build the entry's index.html in a pull request.

If, however, you see an issue that may be more a matter of changing ioccc.css or the related bin tool, please raise the matter as a comment in this issue #2239 so we can discuss the matter before editing the CSS and/or bin tool. Again, this is less likely to happen, but if it does, we recommend a comment related discussion first. Modification to the entry's README.md file can be done directly via pull requests.

We also want to address any fix all REASONABLE "validation errors and warnings" as reported by the "Nu HTML check this web page". We emphasize REASONABLE because in the past, we have found some of those "validation errors and warnings" to be on the pedantic side of things. Moreover, when it comes to the HTML generated by pandoc(1) we may not have much room to fix things.

See also comment-2101733908 regarding links to markdown files, links to GitHub, relative links, and links with %%TOKEN%% symbols.

Please note that the top index page of this repo, as rendered by GitHub, is https://ioccc-src.github.io/temp-test-ioccc/index.html.

A review of commit 4d6009b58fa56e966818fc4b42d8741ec4f64e73, and commit 3aec80f057cf4863a41fba40e2039293694aead1, and commit 85c991620f605d3905f386d52fe3ed3a2a32fa85, and commit 5dd3311e9ef36b4570cd972b6d1ec327ae7a4c78 should be done to consider changes impacted by the move away from "spoiler" language and towards language such as "deobfuscation".

xexyl commented 8 months ago

The generated winner index.html files need to have their "look and feel" improved.

NOTE: As of the time this issue was created, the procedure to generate HTML files other than winner index.html files has not been completed, this issue restricts itself to just the "look and fee" of the winner index.html files.

Using the method outlined in issue #1933, the winner index.html files may still be improved.

HINT: One may generate a single winner index.html file by using the bin/readme2index.sh tool on a single winner. For example, to regenerate 2020/ferguson1/index.html:

bin/readme2index.sh -v 3 2020/ferguson1

:-)

About that entry .. didn't you say I needed to fix something there in the README.md and maybe other markdown files? What did you have in mind (well besides the markdown file references on GitHub should be removed which I'll get to)?

Thanks.

HINT: We recommend using the method outlined in comment 1893176110 on a macOS machine to examine HTML files before pushing changes to the repo.

Good call on linking there.

Probably the most obvious way is to improve the winner README.md file itself. A number of "undesirable" nits and formatting issues may be addressed by changing the markdown content.

As above. Of course I think I've done much of this work but it'll be helpful to see how the index.html files come out to know what has to change further.

A somewhat less disable way to address a "Look and Feel" issue for a partical IOCCC winner would be to add a special line to the inc/md2html.cfg file that controls the way the bin/ tools and inc/ files form the winner index.html file. One would need to be sure the configuration line that matches the particular winner markdown line appears BEFORE more general configuration line. For example:

I can see how that would be less desirable yes.

# Fake example:We must disable pandoc warnings for 1984/anonymou because those warnings
# are not valid and we need a fake example.

1984/anonymous/README.md         -o bin/subst.default.sh -o bin/subst.winner-index.sh -b bin/gen-author.sh -a bin/gen-inventory.sh -P '-f markdown -t html --quiet`

# Unless matched above, default process all winner README.md files

[12][0-9][0-9][0-9]/*/README.md         -o bin/subst.default.sh -o bin/subst.winner-index.sh -b bin/gen-author.sh -a bin/gen-inventory.sh
mock/*/README.md                        -o bin/subst.default.sh -o bin/subst.winner-index.sh -b bin/gen-author.sh -a bin/gen-inventory.sh

This is an example of disabling warnings i.e. the less desirable way, right?

Or next might be to use a slightly modified inc/begin-rightcolumn.default.html file (lets pretend this file is called inc/begin-rightcolumn.1984_anonymous.html), by adding a special line to the inc/md2html.cfg file before BEFORE more general configuration line. For example:

# Fake example: We must disable pandoc warnings for 1984/anonymous because those warnings
# are not valid and we need a fake example.

1984/anonymous/README.md         -o bin/subst.default.sh -o bin/subst.winner-index.sh -b bin/gen-author.sh -a bin/gen-inventory.sh -P '-f markdown -t html --quiet` -H begin-rightcolumn=1984_anonymous

# Unless matched above, default process all winner README.md files

[12][0-9][0-9][0-9]/*/README.md         -o bin/subst.default.sh -o bin/subst.winner-index.sh -b bin/gen-author.sh -a bin/gen-inventory.sh
mock/*/README.md                        -o bin/subst.default.sh -o bin/subst.winner-index.sh -b bin/gen-author.sh -a bin/gen-inventory.sh

See the inc/md2html.cfg file comments for more information.

Again, we suggest you try and fix it by changing the README.md file first, before you try and setup a special case inc/md2html.cfg line.

Perhaps it'll be helpful to have all the html files generated so we can see what they look like here so I can know what to fix? And do feel free to assign this to me!

Another somewhat complex way to address a "Look and Feel" problem is to modify the default inc/_something_.default.html file. As an example, if the problem being address in the inc/begin-rightcolumn.default.html file is wide spread, instead adding a bunch of special case lines to the inc/md2html.cfg file using a bunch of special case inc/begin-rightcolumn.XYZZY.html files, one might be better off modifying the inc/begin-rightcolumn.default.html file.

I guess in general complex ways should be weighed against the easier ways and what is gained/lost. Of course in some cases more complex is the right way to go but not always. I can see how a widespread problem would be better fixed at the source of course.

This approach would require one to regenerate ALL HTML files that use inc/begin-rightcolumn.default.html, which because it is a default file for the "begin-rightcolumn" phase, is nearly all (if not all) HTML files. One cannot use the bin/quick-readme2index.sh either one can to force the rebuild of ALL HTML files and then test ALL HTML files to verify that the fix did not create a bunch of new problems.

Speaking of such. What will the other html files (from other markdown files I mean) be using?

Another more complex way to address a "Look and Feel" problem is to modify the ioccc.css file. By "more complex" and "less desirable" we mean that changing the ioccc.css file may impact ALL HTML files on the web site, forcing one to check the impact on ALL HTML files from the point of view of several common browses, and with various window sizes AND with printing files. This can be done (and there could be cases where it must be done), but hopefully this method can be avoided.

Agreed it would be good if this can be avoided!

Probably the most complex way to address a Look and Feel" problem to change the way scripts in bin/ work. This will impact ALL HTML files on the web site, forcing one to check the impact on ALL HTML files in addition to having to modify the bin/ code.

True. That seems even worse than modifying the CSS file. I guess you agree there. Anyway feel free to assign this (and every other one .. I'll mention that in 5) to me. I'll be asking for a priority list too.

lcn2 commented 8 months ago

This is an example of disabling warnings i.e. the less desirable way, right?

Probably it is: that is untested and likely not needed. It was just a fake example.

xexyl commented 8 months ago

This is an example of disabling warnings i.e. the less desirable way, right?

Probably it is: that is untested and likely not needed. It was just a fake example.

Just making sure. Thanks for assigning it to me. I presume you'll get back to me on the other things later on.

lcn2 commented 8 months ago

The generated winner index.html files need to have their "look and feel" improved. NOTE: As of the time this issue was created, the procedure to generate HTML files other than winner index.html files has not been completed, this issue restricts itself to just the "look and fee" of the winner index.html files. Using the method outlined in issue #1933, the winner index.html files may still be improved. HINT: One may generate a single winner index.html file by using the bin/readme2index.sh tool on a single winner. For example, to regenerate 2020/ferguson1/index.html:

bin/readme2index.sh -v 3 2020/ferguson1

:-)

About that entry .. didn't you say I needed to fix something there in the README.md and maybe other markdown files? What did you have in mind (well besides the markdown file references on GitHub should be removed which I'll get to)?

We just needed a fake example to use.

lcn2 commented 8 months ago

Or next might be to use a slightly modified inc/begin-rightcolumn.default.html file (lets pretend this file is called inc/begin-rightcolumn.1984_anonymous.html), by adding a special line to the inc/md2html.cfg file before BEFORE more general configuration line. For example:

# Fake example: We must disable pandoc warnings for 1984/anonymous because those warnings
# are not valid and we need a fake example.

1984/anonymous/README.md         -o bin/subst.default.sh -o bin/subst.winner-index.sh -b bin/gen-author.sh -a bin/gen-inventory.sh -P '-f markdown -t html --quiet` -H begin-rightcolumn=1984_anonymous

# Unless matched above, default process all winner README.md files

[12][0-9][0-9][0-9]/*/README.md         -o bin/subst.default.sh -o bin/subst.winner-index.sh -b bin/gen-author.sh -a bin/gen-inventory.sh
mock/*/README.md                        -o bin/subst.default.sh -o bin/subst.winner-index.sh -b bin/gen-author.sh -a bin/gen-inventory.sh

See the inc/md2html.cfg file comments for more information. Again, we suggest you try and fix it by changing the README.md file first, before you try and setup a special case inc/md2html.cfg line.

Perhaps it'll be helpful to have all the html files generated so we can see what they look like here so I can know what to fix?

They ARE generated ‼️ Well OK, only all of the winner index.html files are generated. 😉 Maybe we did not announce that fact with enough fanfare? 😀

OK, as mentioned the higher level HTML files and the winner HTML files that are not index.html still need to be generated. 😉

It was a milestone that we had been working on for months. It was why we asked to hold off on edits being made to the manifest numbers spreadsheet until now. It was the reason for the creation of all those new issues, etc.

start side note

We are actively working on generating the rest of the HTML files (see the TODO list of issue #4): racing to try and finish issue #4 before the other ((top primary)) issues are completed. For a number of people, work on issue #2 and issue #3 might seem nice, but as they might not take the time to try all of the IOCCC winners of the past, they might not understand the full benefit .. that it until they are looking at past winners for ideas and discover that they actually have a reasonable change to download the core, compile it and run it today. Sadly it will be the look and feel that will catch the attention of most people.

The winner index.html files are ready for review and improvement on their look at feel. Again this isn't to say that the tremendous work on issue #2 and issue #3 are not important: they are very important and your efforts on behalf of the IOCCC website are very much appreciated.

If we were make a new accouchement now about the work done so far, and people see a bunch of broken links, missing HTML files, etc. it will be hard for some people to perceive the tremendous progress that was made by issue #2 and issue #3. Thus we have be working very hard to race to try and get the look and feel ready so that your important efforts may present themselves in a good light for others to see.

end side note

And as the top comment suggests, much of the work will likely involve editing the README.md file, running bin/readme2index.sh for the given winner, looking at the resulting winner index.html locally using the method outlined in comment 1893176110. Because what really matters now is what the resulting winner index.html looks like from a web browser.

lcn2 commented 8 months ago

This approach would require one to regenerate ALL HTML files that use inc/begin-rightcolumn.default.html, which because it is a default file for the "begin-rightcolumn" phase, is nearly all (if not all) HTML files. One cannot use the bin/quick-readme2index.sh either one can to force the rebuild of ALL HTML files and then test ALL HTML files to verify that the fix did not create a bunch of new problems.

Speaking of such. What will the other html files (from other markdown files I mean) be using?

For this issue, only the winner index.html files are involved. As it states in the issue title "... winner index.html files".

When other HTML files are generated, there will be other issues to review them: likely 2 more issues that will be created, one for the winner non-index.html files and one more for all of the top level HTML files, one those HTML files are generated in the first place.

xexyl commented 8 months ago

This approach would require one to regenerate ALL HTML files that use inc/begin-rightcolumn.default.html, which because it is a default file for the "begin-rightcolumn" phase, is nearly all (if not all) HTML files. One cannot use the bin/quick-readme2index.sh either one can to force the rebuild of ALL HTML files and then test ALL HTML files to verify that the fix did not create a bunch of new problems.

Speaking of such. What will the other html files (from other markdown files I mean) be using?

For this issue, only the winner index.html files are involved. As it states in the issue title "... winner index.html files".

When other HTML files are generated, there will be other issues to review them: likely 2 more issues that will be created, one for the winner non-index.html files and one more for all of the top level HTML files, one those HTML files are generated in the first place.

Sure .. but I was thinking of in general. But I'll worry about that later on. Thanks.

Still what problem existed in I think you said 2020/ferguson1/README.md ? That way I can correct it.

xexyl commented 8 months ago

The generated winner index.html files need to have their "look and feel" improved. NOTE: As of the time this issue was created, the procedure to generate HTML files other than winner index.html files has not been completed, this issue restricts itself to just the "look and fee" of the winner index.html files. Using the method outlined in issue #1933, the winner index.html files may still be improved. HINT: One may generate a single winner index.html file by using the bin/readme2index.sh tool on a single winner. For example, to regenerate 2020/ferguson1/index.html:

bin/readme2index.sh -v 3 2020/ferguson1

:-) About that entry .. didn't you say I needed to fix something there in the README.md and maybe other markdown files? What did you have in mind (well besides the markdown file references on GitHub should be removed which I'll get to)?

We just needed a fake example to use.

Right but I thought you said some days back that that file needed some fixes?

xexyl commented 8 months ago

Or next might be to use a slightly modified inc/begin-rightcolumn.default.html file (lets pretend this file is called inc/begin-rightcolumn.1984_anonymous.html), by adding a special line to the inc/md2html.cfg file before BEFORE more general configuration line. For example:

# Fake example: We must disable pandoc warnings for 1984/anonymous because those warnings
# are not valid and we need a fake example.

1984/anonymous/README.md         -o bin/subst.default.sh -o bin/subst.winner-index.sh -b bin/gen-author.sh -a bin/gen-inventory.sh -P '-f markdown -t html --quiet` -H begin-rightcolumn=1984_anonymous

# Unless matched above, default process all winner README.md files

[12][0-9][0-9][0-9]/*/README.md         -o bin/subst.default.sh -o bin/subst.winner-index.sh -b bin/gen-author.sh -a bin/gen-inventory.sh
mock/*/README.md                        -o bin/subst.default.sh -o bin/subst.winner-index.sh -b bin/gen-author.sh -a bin/gen-inventory.sh

See the inc/md2html.cfg file comments for more information. Again, we suggest you try and fix it by changing the README.md file first, before you try and setup a special case inc/md2html.cfg line.

Perhaps it'll be helpful to have all the html files generated so we can see what they look like here so I can know what to fix?

They ARE generated ‼️ Well OK, only all of the winner index.html files are generated. 😉 Maybe we did not announce that fact with enough fanfare? 😀

No .. you did indeed mention it. I was thinking of something specific but I'm afraid I don't know what it is now. Maybe it's already fine as it is. That's possible - it might just be I have to look at the rendered files to find errors.

OK, as mentioned the higher level HTML files and the winner HTML files that are not index.html still need to be generated. 😉

Of course.

It was a milestone that we had been working on for months. It was why we asked to hold off on edits being made to the manifest numbers spreadsheet until now. It was the reason for the creation of all those new issues, etc.

I remember you saying that yes. And I wish I had thought of the fact that I know of some errors in one of my entries. Wrong file name. Well I won't do that today. The manifest task is taking too much for me today. I really don't know why I am so exhausted today but I am.

start side note

We are actively working on generating the rest of the HTML files (see the TODO list of issue #4): racing to try and finish issue #4 before the other ((top primary)) issues are completed. For a number of people, work on issue #2 and issue #3 might seem nice, but as they might not take the time to try all of the IOCCC winners of the past, they might not understand the full benefit .. that it until they are looking at past winners for ideas and discover that they actually have a reasonable change to download the core, compile it and run it today. Sadly it will be the look and feel that will catch the attention of most people.

Hmm yes I can imagine that. I don't think nearly as many people understand how many entries no longer worked and how almost all of them now do. And the ones that don't I think work in some platforms. In one case I'm pretty sure it has to do with the version of perl in macOS, as to why it crashes. I think this based on the author's remarks.

Even those that do they might not care as much as the look and feel as you say. Presentation etc. seems to get to people in ways that sometimes goes to quite some extremes. The flashy websites being something that so many people like (even if the content is not quality) is a classic example.

The winner index.html files are ready for review and improvement on their look at feel. Again this isn't to say that the tremendous work on issue #2 and issue #3 are not important: they are very important and your efforts on behalf of the IOCCC website are very much appreciated.

Thank you very much! I needed to hear that! When I'm done with that other issue, 3, I will look at the rendered files and then go from there. It is probably better that order anyway since that way I can be sure the html files are up to date. As noted in another issue some are not now (though they're being updated). Then if a file name changes or a file is added or removed or that also means the index.html is out of date. So better to finish that first. Though I have to say today the manifest one is getting to me. But that's because I'm extremely tired - more than usual - and also probably because it's my first time with the very long process.

If we were make a new accouchement now about the work done so far, and people see a bunch of broken links, missing HTML files, etc. it will be hard for some people to perceive the tremendous progress that was made by issue #2 and issue #3. Thus we have be working very hard to race to try and get the look and feel ready so that your important efforts may present themselves in a good light for others to see.

That's true and it's also true that there will be broken links. Let me say that differently: there ARE broken links. That includes from typos on my part (normal typos that I haven't gone back to 'zoom in on' yet and also it's possible I had the wrong link to type .. and then there are other things too).

end side note

And as the top comment suggests, much of the work will likely involve editing the README.md file, running bin/readme2index.sh for the given winner, looking at the resulting winner index.html locally using the method outlined in comment 1893176110. Because what really matters now is what the resulting winner index.html looks like from a web browser.

Yes. I'm still doing that of course.

I think manifest issue is about done, what I'm working on, so I'll post this and hopefully be making a pull request shortly.

lcn2 commented 7 months ago

Added an "UPDATE 0" to the top level comment.

xexyl commented 7 months ago

Added an "UPDATE 0" to the top level comment.

I did like the 2020 version of the entries' index.html files and the year's index.html too but I also liked the way you had the index.html files here. Speaking of such I thought you had linked to an example index.html that was rendered as html. I can't find it now though. Can you post it again please? Thanks. That'll help I think.

lcn2 commented 7 months ago

Added an "UPDATE 0" to the top level comment.

I did like the 2020 version of the entries' index.html files and the year's index.html too but I also liked the way you had the index.html files here. Speaking of such I thought you had linked to an example index.html that was rendered as html. I can't find it now though. Can you post it again please? Thanks. That'll help I think.

Then are rendering on the GitHub pages for the web site such as:

https://ioccc-src.github.io/temp-test-ioccc/2020/ferguson1/index.html

Better still one can view them locally on macOS using the built in Apache server as needed.

xexyl commented 7 months ago

Added an "UPDATE 0" to the top level comment.

I did like the 2020 version of the entries' index.html files and the year's index.html too but I also liked the way you had the index.html files here. Speaking of such I thought you had linked to an example index.html that was rendered as html. I can't find it now though. Can you post it again please? Thanks. That'll help I think.

Then are rendering on the GitHub pages for the web site such as:

https://ioccc-src.github.io/temp-test-ioccc/2020/ferguson1/index.html

Better still one can view them locally on macOS using the built in Apache server as needed.

The GitHub version is better for me actually. Thanks. Would you mind adding a link to it in the todo list so I am sure to not lose it again? Thanks.

xexyl commented 7 months ago

Speaking of such I see a problem with the index.html files ...

They should list more than just name and location. In particular they should list URLs and also award title. Where should this be fixed? And if it's later in the file I think that's a mistake.

A lesser matter is I'm not sure if the 'Author' heading level is right. But I'm not sure if it's wrong either. Seems smaller though and maybe it shouldn't be? But I don't know and the more #s there are the smaller it gets and that's not good esp for the author's/authors' remarks as if they have sections too it gets too small.

We could have the author information at the top level 1 (as in #) too. I think that might look nicer esp as it won't be indented (or I presume it won't be). It seems odd to have subsection heading level as the very first heading. It seems out of place: like something is missing. What do you think?

lcn2 commented 7 months ago

Added an "UPDATE 0" to the top level comment.

I did like the 2020 version of the entries' index.html files and the year's index.html too but I also liked the way you had the index.html files here. Speaking of such I thought you had linked to an example index.html that was rendered as html. I can't find it now though. Can you post it again please? Thanks. That'll help I think.

Then are rendering on the GitHub pages for the web site such as: https://ioccc-src.github.io/temp-test-ioccc/2020/ferguson1/index.html Better still one can view them locally on macOS using the built in Apache server as needed.

The GitHub version is better for me actually. Thanks. Would you mind adding a link to it in the todo list so I am sure to not lose it again? Thanks.

As mentioned in the top comment:

HINT: We recommend using the method outlined in comment 1893176110 on a macOS machine to examine HTML files before pushing changes to the repo.

This allows you to first check and test HTML files on your local machine before pushing out a commit for a pull request.

xexyl commented 7 months ago

Added an "UPDATE 0" to the top level comment.

I did like the 2020 version of the entries' index.html files and the year's index.html too but I also liked the way you had the index.html files here. Speaking of such I thought you had linked to an example index.html that was rendered as html. I can't find it now though. Can you post it again please? Thanks. That'll help I think.

Then are rendering on the GitHub pages for the web site such as: https://ioccc-src.github.io/temp-test-ioccc/2020/ferguson1/index.html Better still one can view them locally on macOS using the built in Apache server as needed.

The GitHub version is better for me actually. Thanks. Would you mind adding a link to it in the todo list so I am sure to not lose it again? Thanks.

As mentioned in the top comment:

HINT: We recommend using the method outlined in comment 1893176110 on a macOS machine to examine HTML files before pushing changes to the repo.

You should first check and test HTML files on your local machine before pushing out a commit for a pull request.

I meant to see what they look like now. I was too tired to think of more details but that's what I was getting at.

lcn2 commented 7 months ago

Speaking of such I see a problem with the index.html files ...

They should list more than just name and location. In particular they should list URLs and also award title. Where should this be fixed? And if it's later in the file I think that's a mistake.

A lesser matter is I'm not sure if the 'Author' heading level is right. But I'm not sure if it's wrong either. Seems smaller though and maybe it shouldn't be? But I don't know and the more #s there are the smaller it gets and that's not good esp for the author's/authors' remarks as if they have sections too it gets too small.

We could have the author information at the top level 1 (as in #) too. I think that might look nicer esp as it won't be indented (or I presume it won't be). It seems odd to have subsection heading level as the very first heading. It seems out of place: like something is missing. What do you think?

Addressing any such missing information is probably premature given the ongoing actions are mentioned in comment 1928224505.

xexyl commented 7 months ago

Speaking of such I see a problem with the index.html files ... They should list more than just name and location. In particular they should list URLs and also award title. Where should this be fixed? And if it's later in the file I think that's a mistake. A lesser matter is I'm not sure if the 'Author' heading level is right. But I'm not sure if it's wrong either. Seems smaller though and maybe it shouldn't be? But I don't know and the more #s there are the smaller it gets and that's not good esp for the author's/authors' remarks as if they have sections too it gets too small. We could have the author information at the top level 1 (as in #) too. I think that might look nicer esp as it won't be indented (or I presume it won't be). It seems odd to have subsection heading level as the very first heading. It seems out of place: like something is missing. What do you think?

Addressing any such missing information is probably premature given the ongoing actions are mention in comment 1928224505.

Just wanted to bring it up. No rush on my behalf. I'm afraid I won't do more than the manifest that I did today .. too tired and too much on my mind. I'll do more tomorrow.

lcn2 commented 7 months ago

FYI @xexyl , the mention of the IOCCC award for a winning entry has been addressed in index.html files and will be released when we finish the actions mentioned in comment 1928224505.

xexyl commented 7 months ago

FYI @xexyl , the mention of the IOCCC award for a winning entry has been addressed in index.html files and will be released when we finish the actions mentioned in comment 1928224505.

Thanks for the update.

lcn2 commented 7 months ago

Also FYI: @xexyl , the questions about formatting such as 'Author' heading level has been addressed in index.html files and will be released when we finish the actions mentioned in comment 1928224505.

xexyl commented 7 months ago

Also FYI: @xexyl , the questions about formatting such as 'Author' heading level has been addressed in index.html files and will be released when we finish the actions mentioned in comment 1928224505.

Thanks!

I am going to get myself to bed now. I don't know what I will be able to do tomorrow but hopefully I can do a bit. If nothing else I should be able to start back at doing more in the days after my birthday - though as I said there are a few days after it that will be slower.

Enjoy the rest of your day!

lcn2 commented 7 months 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.

lcn2 commented 7 months ago

See commit cc73503c102137f03ba02bf712fccc5dc2bae7e9

As a result, from the top level Makefile:

make quick_www

and try:

make www

among other things. :-)

xexyl commented 7 months ago

See commit cc73503

As a result, from the top level Makefile:

make quick_www

and try:

make www

among other things. :-)

Nice. Thanks! That'll be helpful. I guess I can update the manifest tool I wrote to do that too but we'll see. Will hopefully do some things tomorrow morning. Just spending a couple more hours and then probably will get sleep: very tired.

lcn2 commented 7 months ago

We have expanded this issue to include the top level HTML files such as:

As well as:

And the year level YYYY/index.html files.

UPDATE 0

This is now a ((top priority)) issue.

xexyl commented 6 months ago

We have expanded this issue to include the top level HTML files such as:

  • CODE_OF_CONDUCT.html
  • README.html
  • authors.html
  • bugs.html
  • contact.html
  • faq.html
  • index.html
  • judges.html
  • location.html
  • news.html
  • thanks-for-help.html
  • winners.html
  • years.html

As well as:

  • bin/index.html
  • inc/index.html

And the year level YYYY/index.html files.

UPDATE 0

This is now a ((top priority)) issue.

I am sorry that I did not see this comment. Thanks for the updates. I'll go in the order you asked me to of course. I hope 3 will be done soon but I'm also waiting for you to finish the Makefile task before I can do one of the steps.

xexyl commented 6 months ago

After running make www I got the following:

=-=-=-=-= IOCCC begin make gen_status =-=-=-=-=
bin/gen-status.sh -v 1
bin/gen-status.sh: ERROR: in output_mod_date: TZ=UTC ls -D '%FT%T+00:00' -ld news.html failed, error: 2
bin/gen-status.sh: ERROR: in output_status_json: modification date of news.html failed, error: 6
bin/gen-status.sh: ERROR: failed to form temporary status.json file: .gen-status.sh.27023.entry.md, error code: 9
make[1]: *** [Makefile:365: gen_status] Error 12

Additionally I see:

$ git diff years.html
diff --git i/years.html w/years.html
index 28caf571613223da8e44019c5819acde2ba7ce13..380c0f0882a9466c85641da0ec9a37f0fb21ab31 100644
--- i/years.html
+++ w/years.html
@@ -120,19 +120,19 @@ Year</h1>
 source</a></p>
 <h3 id="jump-to">Jump to:</h3>
 <p><a href="#2020">2020</a> | <a href="#2019">2019</a> | <a
 href="#2018">2018</a> | <a href="#2015">2015</a> | <a
 href="#2014">2014</a> | <a href="#2013">2013</a> | <a
-href="#2012">2012</a> | <a href="#2011">2011</a><br><br> <a
+href="#2012">2012</a><br><br> <a href="#2011">2011</a> | <a
 href="#2006">2006</a> | <a href="#2005">2005</a> | <a
 href="#2004">2004</a> | <a href="#2001">2001</a> | <a
-href="#2000">2000</a> | <a href="#1998">1998</a> | <a
-href="#1996">1996</a> | <a href="#1995">1995</a><br><br> <a
+href="#2000">2000</a> | <a href="#1998">1998</a><br><br> <a
+href="#1996">1996</a> | <a href="#1995">1995</a> | <a
 href="#1994">1994</a> | <a href="#1993">1993</a> | <a
 href="#1992">1992</a> | <a href="#1991">1991</a> | <a
-href="#1990">1990</a> | <a href="#1989">1989</a> | <a
-href="#1988">1988</a> | <a href="#1987">1987</a><br><br> <a
+href="#1990">1990</a><br><br> <a href="#1989">1989</a> | <a
+href="#1988">1988</a> | <a href="#1987">1987</a> | <a
 href="#1986">1986</a> | <a href="#1985">1985</a> | <a
 href="#1984">1984</a></p>
 <h2 id="the-27th-ioccc"><a name=2020></a>2020 - The 27th IOCCC</h2>
 <p><strong>Download IOCCC</strong> <a
 href="2020/ioccc.2020.tar.bz2">2020 entry source</a></p>

even though I did not touch any markdown file. Which incidentally I don't see a years.md but I do see in years.html that it's auto-generated. What from?

I'm not committing years.html. I did also get this though:

$ git diff
diff --git i/1992/.filelist w/1992/.filelist
index 8beb2e51b90dab69afebe7a530fad0827fc52787..c02d237d1b51f9dd9fbc294672f03357032c3a09 100644
--- i/1992/.filelist
+++ w/1992/.filelist
@@ -1,7 +1,6 @@
 1992/1992.tar.bz2
-1992/.DS_Store
 1992/Makefile
 1992/README.md
 1992/.filelist
 1992/.gitignore
 1992/guidelines.txt

I presume that the script needs to exclude that file and perhaps you had it in your system when running the command? Ah .. I see. It's in a make rule. Using find. Well with multiple paths to negate in find(1) I don't want to mess anything up so I'll let you fix it: too much to test for my mind right now.

Nevertheless as I did not mean to update the status page (of course I didn't) the one I did mean to update was modified so it'll be committed - soon I hope.

lcn2 commented 6 months ago

After running make www I got the following:

=-=-=-=-= IOCCC begin make gen_status =-=-=-=-=
bin/gen-status.sh -v 1
bin/gen-status.sh: ERROR: in output_mod_date: TZ=UTC ls -D '%FT%T+00:00' -ld news.html failed, error: 2
bin/gen-status.sh: ERROR: in output_status_json: modification date of news.html failed, error: 6
bin/gen-status.sh: ERROR: failed to form temporary status.json file: .gen-status.sh.27023.entry.md, error code: 9
make[1]: *** [Makefile:365: gen_status] Error 12

Looks like Linux is behind in ls(1) functionality. Will have to work around this.

xexyl commented 6 months ago

After running make www I got the following:

=-=-=-=-= IOCCC begin make gen_status =-=-=-=-=
bin/gen-status.sh -v 1
bin/gen-status.sh: ERROR: in output_mod_date: TZ=UTC ls -D '%FT%T+00:00' -ld news.html failed, error: 2
bin/gen-status.sh: ERROR: in output_status_json: modification date of news.html failed, error: 6
bin/gen-status.sh: ERROR: failed to form temporary status.json file: .gen-status.sh.27023.entry.md, error code: 9
make[1]: *** [Makefile:365: gen_status] Error 12

Looks like Linux is behind in ls(1) functionality. Will have to work around this.

I actually wondered if it was the ls. But I tried that command at the command prompt and no problem. Also it was under macOS though my default path does use GNU ls.

But then trying the direct paths:

$ TZ=UTC /bin/ls -D '%FT%T+00:00' -ld ../../news.html
-rw-r--r--  1 cody  staff  19131 2024-03-10T17:09:13+00:00 ../../news.html
TZ=UTC /opt/local/libexec/gnubin/ls -D '%FT%T+00:00' -ld ../../news.html
ls: cannot access '%FT%T+00:00': No such file or directory
  -rw-r--r-- 1 cody staff 19131 Mar 10 17:09 ../../news.html
//DIRED// 45 60
//DIRED-OPTIONS// --quoting-style=shell-escape

Hope that helps .. off again.

lcn2 commented 6 months ago

After running make www I got the following:

=-=-=-=-= IOCCC begin make gen_status =-=-=-=-=
bin/gen-status.sh -v 1
bin/gen-status.sh: ERROR: in output_mod_date: TZ=UTC ls -D '%FT%T+00:00' -ld news.html failed, error: 2
bin/gen-status.sh: ERROR: in output_status_json: modification date of news.html failed, error: 6
bin/gen-status.sh: ERROR: failed to form temporary status.json file: .gen-status.sh.27023.entry.md, error code: 9
make[1]: *** [Makefile:365: gen_status] Error 12

Looks like Linux is behind in ls(1) functionality. Will have to work around this.

I actually wondered if it was the ls. But I tried that command at the command prompt and no problem. Also it was under macOS though my default path does use GNU ls.

But then trying the direct paths:

$ TZ=UTC /bin/ls -D '%FT%T+00:00' -ld ../../news.html
-rw-r--r--  1 cody  staff  19131 2024-03-10T17:09:13+00:00 ../../news.html
TZ=UTC /opt/local/libexec/gnubin/ls -D '%FT%T+00:00' -ld ../../news.html
ls: cannot access '%FT%T+00:00': No such file or directory
  -rw-r--r-- 1 cody staff 19131 Mar 10 17:09 ../../news.html
//DIRED// 45 60
//DIRED-OPTIONS// --quoting-style=shell-escape

Hope that helps .. off again.

Yes, it looks like we will need to "port" the bin tools to Linux as well.

There are differences on the ls(1) command, and differences the sort(1) command, and differences with bash(1) supported shell options.

sigh

We will not address this UNTIL the Makefile mods are finished.

UPDATE 0

Now that the Makefile mods are finished, we will now focus on porting the bin tools to Linux to address the problems of scripts running under that system.

Until we do, we suggest doing things such as make quick_www and make www under macOS only.

lcn2 commented 6 months 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 6 months ago

After running make www I got the following:

=-=-=-=-= IOCCC begin make gen_status =-=-=-=-=
bin/gen-status.sh -v 1
bin/gen-status.sh: ERROR: in output_mod_date: TZ=UTC ls -D '%FT%T+00:00' -ld news.html failed, error: 2
bin/gen-status.sh: ERROR: in output_status_json: modification date of news.html failed, error: 6
bin/gen-status.sh: ERROR: failed to form temporary status.json file: .gen-status.sh.27023.entry.md, error code: 9
make[1]: *** [Makefile:365: gen_status] Error 12

Looks like Linux is behind in ls(1) functionality. Will have to work around this.

I actually wondered if it was the ls. But I tried that command at the command prompt and no problem. Also it was under macOS though my default path does use GNU ls. But then trying the direct paths:

$ TZ=UTC /bin/ls -D '%FT%T+00:00' -ld ../../news.html
-rw-r--r--  1 cody  staff  19131 2024-03-10T17:09:13+00:00 ../../news.html
TZ=UTC /opt/local/libexec/gnubin/ls -D '%FT%T+00:00' -ld ../../news.html
ls: cannot access '%FT%T+00:00': No such file or directory
  -rw-r--r-- 1 cody staff 19131 Mar 10 17:09 ../../news.html
//DIRED// 45 60
//DIRED-OPTIONS// --quoting-style=shell-escape

Hope that helps .. off again.

Yes, it looks like we will need to "port" the bin tools to Linux as well.

There are differences on the ls(1) command, and differences the sort(1) command, and differences with bash(1) supported shell options.

sigh

We will not address this UNTIL the Makefile mods are finished.

UPDATE 0

Now that the Makefile mods are finished, we will now focus on porting the bin tools to Linux to address the problems of scripts running under that system.

Until we do, we suggest doing things such as make quick_www and make www under macOS only.

Yes. That's all I use now. I'm still not sure why using ls at the command line works but the script does not when it should be the same path.

xexyl commented 6 months ago

Do we want to fix the validation errors and warnings? For instance see: https://validator.w3.org/nu/?showimagereport=yes&doc=https%3A%2F%2Fioccc-src.github.io%2Ftemp-test-ioccc%2Flocation.html

Sorry for not making a markdown link. Doing this with the phone.

I don't know if pandoc can do all these and in those cases we could for some possibly fix it with sed but is it worth it?

I can't answer that for the contest on a whole but I can say that I can't help but think that if we're going to have the link on the pages it should be correct.

What do you think? I think it's probably a lower priority but maybe something to consider anyway?

xexyl commented 6 months ago

As for make www: as I said I do use macOS but a problem I noticed today (or rather that registered) is that if I change the PATH to use system paths then bash version is not high enough. But if I use the other the ls(1) is insufficient.

Still baffled by the fact that running the command directly at the command line and it seems to run successfully but that's another matter entirely and not something I really analyses.

Or let me rephrase that one. Using ls with the options the same works and I am pretty sure that type -P ls shows the one that is problematic. I might have even specified the absolute path and then ran into the problem but not sure of that now.

Anyway at this time I cannot successfully run make www though I am pretty sure that the quick version worked.

lcn2 commented 6 months ago

Do we want to fix the validation errors and warnings? For instance see: https://validator.w3.org/nu/?showimagereport=yes&doc=https%3A%2F%2Fioccc-src.github.io%2Ftemp-test-ioccc%2Flocation.html

Yes, perhaps as part of the issue #2006 work. We just added a note to the top of the first comment in issue #2006.

We also removed the "incomplete" notice at the top of issue #2239 ... now off to town lunch and then to porting bin code to Linux.

lcn2 commented 6 months ago

As for make www: as I said I do use macOS but a problem I noticed today (or rather that registered) is that if I change the PATH to use system paths then bash version is not high enough. But if I use the other the ls(1) is insufficient.

The code at the top of the bin shell scripts was designed to stop the tool from running when the bash version was less than version 4.2. We might even change it to require bash version 5.1.8 or higher, but that is TBD.

lcn2 commented 6 months ago

Still baffled by the fact that running the command directly at the command line and it seems to run successfully but that's another matter entirely and not something I really analyses.

Or let me rephrase that one. Using ls with the options the same works and I am pretty sure that type -P ls shows the one that is problematic. I might have even specified the absolute path and then ran into the problem but not sure of that now.

Beware that the macOS shell is zsh(1) which is NOT bash. And one needs to be sure that the $PATH finds a more modern bash instead of the very old macOS bash. The zsh(1) shell contains some well meaning changes that can cause subtile problems, including in the execution of other shell scripts. We get around that a bit by mostly invoking the bin tools via the Makefile, which should enforce (or need to enforce) the use of bash. Nevertheless the need to run a bin command directly will be there from time to time. In those cases, launching a bash sub-shell and running it from there might be needed.

xexyl commented 6 months ago

Still baffled by the fact that running the command directly at the command line and it seems to run successfully but that's another matter entirely and not something I really analyses. Or let me rephrase that one. Using ls with the options the same works and I am pretty sure that type -P ls shows the one that is problematic. I might have even specified the absolute path and then ran into the problem but not sure of that now.

Beware that the macOS shell is zsh(1) which is NOT bash. And one needs to be sure that the $PATH finds a more modern bash instead of the very old macOS bash. The zsh(1) shell contains some well meaning changes that can cause subtile problems, including in the execution of other shell scripts. We get around that a bit by mostly invoking the bin tools via the Makefile, which should enforce (or need to enforce) the use of bash. Nevertheless the need to run a bin command directly will be there from time to time. In those cases, launching a bash sub-shell and running it from there might be needed.

I'm indeed aware that the default shell is zsh but I strongly dislike it. If possible I like it less than csh which says a great deal as I am sure you know! My PATH indeed does have a more recent bash(1) but that itself is the problem I am having with ls.

But yes I might at times have to do the commands directly. That's not what I was getting at here but I am certainly aware of it. Thanks.

lcn2 commented 6 months ago

In case this matters: the tool that generates the sitemap now makes 2 different attempts with stat(1) before trying to use the non-standard -D arg with ls(1).

lcn2 commented 6 months ago

With commit ec6dc7187e47af49ecd400824b9eaf222d6a893c all instances of bold code has been removed. :-)

Puzzled? See the commit message for details. :-)

lcn2 commented 6 months ago

With commit a7896eb8ae657c3977048ca9c16c9574e75c622b the HTML rendered in browsers does not suck as much. :-)

lcn2 commented 6 months ago

With commit cbc022d864bdc069f0c98fedb4031ab1eb95019b the footer Copyright and CC for all HTML and markdown files was made consistent.

lcn2 commented 6 months ago

Help wanted

Currently one of the most wanted to be fixed:

In:

``` multiline code blocks ```

The first line is slightly more intended than the subsequent lines.

For an example, see the code block after the To use: in https://ioccc-src.github.io/temp-test-ioccc/2020/ferguson1/index.html. The W if the first line of that code block is slightly intended relative to the next time.

The fix needs to come in the form of editing ioccc.css and NOT the markdown or HTML itself. Moreover, the fix needs to not adversely impact other parts of web pages.

xexyl commented 6 months ago

With commit ec6dc71 all instances of bold code has been removed. :-)

Puzzled? See the commit message for details. :-)

I wasn't puzzled, no. I remembered something like it being done.

xexyl commented 6 months ago

With commit cbc022d the footer Copyright and CC for all HTML and markdown files was made consistent.

I think the 2020/ferguson2/chocolate-cake.{md,html} should be updated by me so that it's enciphered with the key I use because otherwise it's both enciphered and not enciphered and if someone did play with it and figure it out (I gave possible keys and hints, if you recall, to give users a way to see how the entry works and get a nice treat in return) it would mess up the new output.

Also there's a new problem with the scripts generating a html file for that markdown file: it's not going to be deciphered right with the right key and if the scripts that generate html change or if the pandoc changes that creates new output it'll also be broken. This is one of the files which should not be automatically generated for these reasons and others too. In particular it means that it won't be correct output and that means nobody can use it.

This applies to any other injected html of course. I can add the copyright details to the markdown and then rebuild it but right now as it stands I have to do something or else it won't work right. I just need to know what you need.

xexyl commented 6 months ago

Help wanted

Currently one of the most wanted to be fixed:

In:

multiline code blocks

The first line is slightly more intended than the subsequent lines.

For an example, see the code block after the To use: in https://ioccc-src.github.io/temp-test-ioccc/2020/ferguson1/index.html. The W if the first line of that code block is slightly intended relative to the next time.

The fix needs to come in the form of editing ioccc.css and NOT the markdown or HTML itself. Moreover, the fix needs to not adversely impact other parts of web pages.

Strange .. well I can maybe look at this after other issues are resolved.

xexyl commented 6 months ago

I believe I addressed everything and with the fix in the commit I made a bit ago I'm afraid that's probably all I'll end up doing today. I have some other things I want to take care of and that might be for a few days but maybe each day I can get a bit done.

lcn2 commented 6 months ago

With commit cbc022d the footer Copyright and CC for all HTML and markdown files was made consistent.

I think the 2020/ferguson2/chocolate-cake.{md,html} should be updated by me so that it's enciphered with the key I use because otherwise it's both enciphered and not enciphered and if someone did play with it and figure it out (I gave possible keys and hints, if you recall, to give users a way to see how the entry works and get a nice treat in return) it would mess up the new output.

Also there's a new problem with the scripts generating a html file for that markdown file: it's not going to be deciphered right with the right key and if the scripts that generate html change or if the pandoc changes that creates new output it'll also be broken. This is one of the files which should not be automatically generated for these reasons and others too. In particular it means that it won't be correct output and that means nobody can use it.

This applies to any other injected html of course. I can add the copyright details to the markdown and then rebuild it but right now as it stands I have to do something or else it won't work right. I just need to know what you need.

You raise a number of fair points. In response, we can suggest these options:

Option 0

One solution is for you to remove 2020/ferguson2/chocolate-cake.md and then for you to replace 2020/ferguson2/chocolate-cake.html with your own file.

If you select this option, we ask:

Option 1

Another solution is for you to remove 2020/ferguson2/chocolate-cake.html and then for you to replace 2020/ferguson2/chocolate-cake.md with your own file.

If you select this option, we ask:

If you do this, we will then modify bin/gen-other-html.sh and/or inc/md2html.cfg to not form the 2020/ferguson2/chocolate-cake.html file.

Option 0+1

Another solution is for you to both form, by hand, 2020/ferguson2/chocolate-cake.md and 2020/ferguson2/chocolate-cake.md. If you do that, we ask that:

Option b

Something else ...

our preference

Our preference would be "Option 0".

Let us know which option is preferable to you.

xexyl commented 6 months ago

With commit cbc022d the footer Copyright and CC for all HTML and markdown files was made consistent.

I think the 2020/ferguson2/chocolate-cake.{md,html} should be updated by me so that it's enciphered with the key I use because otherwise it's both enciphered and not enciphered and if someone did play with it and figure it out (I gave possible keys and hints, if you recall, to give users a way to see how the entry works and get a nice treat in return) it would mess up the new output. Also there's a new problem with the scripts generating a html file for that markdown file: it's not going to be deciphered right with the right key and if the scripts that generate html change or if the pandoc changes that creates new output it'll also be broken. This is one of the files which should not be automatically generated for these reasons and others too. In particular it means that it won't be correct output and that means nobody can use it. This applies to any other injected html of course. I can add the copyright details to the markdown and then rebuild it but right now as it stands I have to do something or else it won't work right. I just need to know what you need.

You raise a number of fair points. In response, we can suggest these options:

Option 0

One solution is for you to remove 2020/ferguson2/chocolate-cake.md and then for you to replace 2020/ferguson2/chocolate-cake.html with your own file.

If you select this option, we ask:

  • do not add a copyright notice
  • do not use ioccc.css
  • use a "look and feel" that is "distinct": do not try to make it look like an IOCCC generated web page in either encrypted or decrypted form
  • do not link to "outside" IOCCC HTML nor IOCCC markdown files in the IOCCC web site / repo: It is, however, OK to link to other HTML and markdown files in the 2020/ferguson2 entry

Option 1

Another solution is for you to remove 2020/ferguson2/chocolate-cake.html and then for you to replace 2020/ferguson2/chocolate-cake.md with your own file.

If you select this option, we ask:

  • do not add a copyright notice
  • do not link to "outside" IOCCC HTML nor IOCCC markdown files in the IOCCC web site / repo: It is, however, OK to link to other HTML and markdown files in the 2020/ferguson2 entry

If you do this, we will then modify bin/gen-other-html.sh and/or inc/md2html.cfg to not form the 2020/ferguson2/chocolate-cake.html file.

Option 0+1

Another solution is for you to both form, by hand, 2020/ferguson2/chocolate-cake.md and 2020/ferguson2/chocolate-cake.md. If you do that, we ask that:

  • the point raised for each file be observed for "Option 0" and "Option 1".

Option b

Something else ...

our preference

Our preference would be "Option 0".

Let us know which option is preferable to you.

Option 0 is nice but it'd be ideal if it looked like, when decrypted, the 2020/ferguson1 version. That was the point and that also allows me to regenerate it if necessary which has happened before when new things have been discovered that make it a better recipe (important notes discovered). That's another reason why having a markdown file would be helpful. But then the real thing is this: the way it is generated is by running the proper key on the 2020/ferguson1 files. That's why it has to be the same. It would not be very practical to not have it that way.

Please explain to me why it can't look like the others so that I understand the problem better.

.. another option would be to have the copyright notice there but then if ever that changes I would have to update it via a pull request. But how that would work with the generated html files is not something I am aware of unless of course I run the script and then encrypt it after that. That would work I think if you're okay with that.