search

ioccc-src / mkiocccentry

Form an IOCCC submission as a compressed tarball file
Other
30 stars 6 forks source link

Enhancement: Revisit command line options for "answers" #1242

Open SirWumpus opened 1 month ago

SirWumpus commented 1 month ago

Is there an existing issue for this?

Describe the enhancement

For IOCCC29. IMO There are too many options doing similar things WRT canned "answers".

-i, -a , -y, -Y seem redundant if you provide an answers file; different options to read or write see like overkill; better to stream line the UI/UX and merge the behaviour of several options into one.

Part of the reason is that I can simply create a Makefile target "mkentry:" to handle first time and subsequent updates. When there are multiple options with slight variations in behaviour, I have do a manual run once then change the target options for subsequent runs.

Relevant images, screenshots or other files

No response

Relevant links

No response

Anything else?

No response

xexyl commented 1 month ago

No. There's a very good reason to not have the reading from an answer file prompt you if things are okay.

The point of the file is to not have to input answers to QUESTIONS. It has nothing to do with potential problems with the submission. If it did that you could easily miss an error you introduce without knowing about it only to have your submission rejected for violating the rules or not including something that was there earlier on.

If you don't want that safety net then use the option provided like the script does. That what it's there for.

And -a exists as well as -A and they function as needed.

xexyl commented 1 month ago

-i, -a , -y, -Y seem redundant if you provide an answers file; different options to read or write see like overkill; better to stream line the UI/UX and merge the behaviour of several options into one.

It is not redundant. They do different things.

Part of the reason is that I can simply create a Makefile target "mkentry:" to handle first time and subsequent updates.

There are many ways to do this.

When there are multiple options with slight variations in behaviour, I have do a manual run once then change the target options for subsequent runs.

But they do different things.

If the same option letter existed to read and write from the same file it could cause a lot of problems and it would mean the tool would have to make assumptions.

That is asking for trouble.

SirWumpus commented 1 month ago

I disagree. I found the UI cumbersome and IMO needs future consideration. But since its an enhancement request, not a bug, I'd prefer to discussion at a later date, like after IOCCC28 after other contestants have had time to comment (or not).

lcn2 commented 1 month ago

While we tend to see @xexyl's points on this issue, the questions raised by @SirWumpus should be answered.

And while it is possible that this issue is closed with a "not planned", lets discuss anyway.

xexyl commented 1 month ago

While we tend to see @xexyl's points on this issue, the questions raised by @SirWumpus should be answered.

And while it is possible that this issue is closed with a "not planned", lets discuss anyway.

Yes. I gave it a bit more thought after I wrote that (I was about to sleep but I gave it more thought anyway) - and as I woke up again briefly after a little sleep and before I went back to sleep.

I had a thought and unfortunately it did not work as I hoped.

The use of -i implies -y. This is because otherwise you get:

Enter information for author #0

Please enter either y (yes) or n (no)
Please enter either y (yes) or n (no)
ERROR[159]: prompt: EOF while reading prompt input

That's because it's expecting you to verify author information - as can be seen - but because we don't want to have to re-input that ....

That is why we have the -Y if that helps you understand, @SirWumpus.

As for the other options. Well I would be okay removing -A answers. That is the one that overwrites the answers file. They can always remove it if they wish.

A number of options are for our tools - setting the path. With make install that shouldn't be necessary but what if someone has a strange set up? Well we might say that's on them but that doesn't seem very good to me even if I would actually like to not have those options.

What else. Let's see:

Perhaps the -W could be used instead of -Y? That is ignore warnings: maybe when ignore warnings is enabled the user won't be prompted for the verifying of information (like file set changes etc.) even when using an answers file?

I haven't tested that out but it's something to consider perhaps?

What do you think @SirWumpus about those thoughts ?

And I am sorry if I seemed short yesterday - I have been super tired and maybe somewhat overwhelmed lately. I was about to go to sleep (as this comment says) but I did give it thought and once I am at the computer (I was typing those above comments by phone) I could look at things more.

xexyl commented 1 month ago

And speaking of such ... I fixed a comment in mkiocccentry.c which could cause confusion to people who read the source - on the subject of -y.

Anyway thanks for raising this issue @SirWumpus. Although I think the option set is good there can be no denying there are a lot of options. Most of them are not really needed for most people but some could be confusing and so it would be good if we can figure out a better way to deal with some of these things.

It might not be possible but maybe it can be done. But as you say it's definitely for IOCCC29 and not this one.

SirWumpus commented 1 month ago

This issue can be broken into three parts:

Sidebar: All Y/N questions should be phrased to assume acknowledgement by default, never a negative. Consistency.

Side-saddle: mkiocccentry should have always asked to "save answers to a file?" at the end without need of an option. The process is lengthy enough that this would have been helpful and improve UX.

Side-car: There is a lot of text output that kinda blends in with the questions. I'd consider indenting text output and outdent prompts (or visa versa) so I can distinguish between sections (or some other means to highlight, bar separator between blocks or invert/standout prompts, or prefix ">>> question?").

xexyl commented 1 month ago

This issue can be broken into three parts:

  • -y and -Y : The point of specifying an option to answer "yes", "oui", "hai", "get on with it" means I do not want to interact, just build it or fail. Of the two options, -Y does more what is expected (similar to fsck -y though that is use case might be poor comparison). If something goes wrong that absolutely needs human conformation then write an error and abort (eg. do you want to ignore Rule 2a or 2b?; you exceeded your file allowance, ignore?; "Want to play a game?") - otherwise just build the tarball.

Wrong. But I have an idea about this that might help. We'll see what you have to say. But as I note below: it's NOT FOR PROMPTS. It's for questions.

  • -a, -A, and -i : Three options to do one job, Whisk Tango Foxtrot. I should only need one option to say create an answer file and replay it on future runs. Essential after the first time "I do not want to interact, just build it or fail"- do NOT prompt for lots of Y/N questions for which you know my answer. Now if I have an answer file, why do I need an option to answer "yes", "oui", hai", ...? Why am I being subject to questions for which I created the answer file?

No they don't do the same job. And you're being subjected to it because things can change. Once again: the answers file is NOT FOR PROMPTS. It is for QUESTIONS.

I do have an idea though which I'll get to in next comment.

  • Last night while cogitating the inside of my eye lids I wondered why do we have -a, -A, -i, -y, and -Y options at all when I could simply create a flat text file to redirect input from, ie. mkiocccntry [other opts] < answers. After all this is one of the benefits of redirection. Any answer that does not make sense causes an abort - yes I could end up with my author name being "Y" or "Yes", but at least I have automated a repetitive process - yes its MY RESPONSIBILITY to ensure correct answers and a well formed submission. The contestants are developers who should know how to follow a specification and the benefits of validation - too much hand holding or you'd had better but me dinner first.

There are plenty of reasons for this. So many reasons in fact I don't even want to get into it.

Sidebar: All Y/N questions should be phrased to assume acknowledgement by default, never a negative. Consistency.

Disagree.

Side-saddle: mkiocccentry should have always asked to "save answers to a file?" at the end without need of an option. The process is lengthy enough that this would have been helpful and improve UX.

And so what would happen if the file is not writable? What would happen if it was the input file? Etc. Though I have an idea .. see next comment.

But anyway: one can argue that doing this is adding yet another question when the user doesn't want to worry about it. Also it would cause more interruptions with some modes.

Side-car: There is a lot of text output that kinda blends in with the questions. I'd consider indenting text output and outdent prompts (or visa versa) so I can distinguish between sections (or some other means to highlight, bar separator between blocks or invert/standout prompts, or prefix ">>> question?").

That's not a bad idea.

xexyl commented 1 month ago

Now as for an idea.

We could merge -y and -Y by having the tool always ask for confirmation. I get the feeling you would not like this even though there are clear benefits. Making assumptions is a bad idea always.

But with this there could be a new option that lets you edit the answers.

But essentially your idea of the answers file is a misunderstanding of what it is meant to be. It was originally everything but as more had to be done and more had to be confirmed it was changed.

Assuming yes is not a good idea when there are now so many other things to consider. And remember that you were in favour of the topdir approach. THAT is why it's been done this way - there are too many things to assume. I don't see the problem really when the option to ignore this is there. It's there for people who want it and those who don't don't have to use it. If you have a problem with it why not just alias it?

And as for a file you build yourself I will say this much: it will not always work! And just because people can does not mean that it's the easiest way. Now what could break it?

Simple: if you change your file set or some new problem comes up or some other reason the order will change! Then your answers are out of sync.

SirWumpus commented 1 month ago

You might see prompts and questions as two separate entities, and I suppose they are semantically, but in terms of user experience they are the same - progress halts until I supply input. I want to automated ALL the input, cause I might have to repeat this process more than once (been there).

xexyl commented 1 month ago

You might see prompts and questions as two separate entities, and I suppose they are semantically, but in terms of user experience they are the same - progress halts until I supply input. I want to automated ALL the input, cause I might have to repeat this process more than once (been there).

They are different things. You just admitted it. Just use -Y and be done with it. That is why it's there. I don't see how it's a problem when the option is there. It's three extra characters counting the space and if you automate it it's never a problem (automate in the sense of an alias).

xexyl commented 1 month ago

... and whether or not you see them as the same: that does not mean it's what it was meant for. The only reason it EVER had yes to answers was because of how it was originally worked in. Not because I felt the need for it.

SirWumpus commented 1 month ago

Simple: if you change your file set or some new problem comes up or some other reason the order will change! Then your answers are out of sync.

Doesn't matter. As a user I want to automated it (possibly for testing) - I'll validated it for correctness later.

xexyl commented 1 month ago

Simple: if you change your file set or some new problem comes up or some other reason the order will change! Then your answers are out of sync.

Doesn't matter. As a user I want to automated it (possibly for testing) - I'll validated it for correctness later.

Nothing is stopping you from doing that. Go ahead and do it if you wish.

SirWumpus commented 1 month ago

So far nothing you've said improves the UX. Its convoluted IMO.

xexyl commented 1 month ago

So far nothing you've said improves the UX. Its convoluted IMO.

So far nothing you've said prevents you from doing it your way. But so far what I have said gives a safety net for those who want one - including me.

You are given the option. Use the option if you wish. Problem solved. Or pipe yes to it. Or use your own file. Nothing is stopping you. Giving more options is an improvement not a regression.

Giving users more flexibility is better than assuming and not giving them flexibility.

xexyl commented 1 month ago

And I am sorry but I have a lot of experience with programs making blatant assumptions and it NEVER goes well. If I'm honest you're the first one ever who's told me that making assumptions like this is a good idea - even more so when there's an option to assume. I have seen PEOPLE LOSE DATA (photos in fact!) because developers made BLATANT ASSUMPTIONS that they thought were clear but they were not and the user did not fully understand the implication.

Just because some of the participants are more than capable of this and just because one maybe SHOULD understand the implications does not mean that everyone does. Should and do very often are not the same thing.

The options are there for those who wish to use it. Nobody is forcing you to not use it or do it your own way. That's why the options exist.

lcn2 commented 4 weeks ago

Important checkpoint

Please see GH-issuecomment-2762004417 for a recent comment on existing issues, priorities, and on a deadline for going into pending state for IOCCC29.