Add ability to enter multiple numbers at a time.

[alanhoyle]

I have 5 real dice that I use with real-world diceware. If I specify --randomsource realdice it would be much nicer if I could just type "12345" instead of having to type each number separately and with a carriage return.

[ulif]

Hi @alanhoyle , thanks for your suggestion!

You certainly have a point with the "too-much-keystrokes" problem. Unfortunately, "12345" would not work, as some people use dice with more than 9 sides. Here "1,11" makes a difference to "11,1". So, what about "1,2,3,4,5" or "1 2 3 4 5" (with any separator chars)? Could you live with that?

Apart from that, I would like to keep diceware as un-smart as possible - trying to be smart normally makes things worse (just in case you fancy something like a "smart" find-the-numbers-in-this-very-long-textstring feaure) ;)

What do you think?

[alanhoyle]

I feel like anyone who is using diceware, especially with the --randomsource realdice option, is probably paranoid and smart enough to be able to translate their dice value notations into something similar to the way we do hexadecimal. I.e. using letters and numbers [0-9,a-z] etc. That would cover us up to 36 sided-dice, or up to 62 if we allow capital letters to be distinct from lower case.

The important thing is the entropy, right?

Maybe you could have the parsing be smart enough to use different input schemes for different sidedness values?

Another option would be to request/force leading zeros for values from 0-9. I.e. if I rolled 17,6,1,11 on a d20 I would type in 17060111. If someone typed in 176111, it would be rejected since 61 is too big or it could request more rolls if they were using a d100.

[ulif]

Mixing up lowercase and even uppercase letters just to save some keystrokes? Nah, that would confuse people more than it would help. Could you tell quickly how "42" had to be written as a d62 code? How many other people would do that accurately and on the fly?

I am afraid, what you request seems to be some kind of "smart" understanding of user input. I would like to avoid that.

Maybe we could change the goal to accept some input format, which is better suited for machines. But this should then be suitable for n-sided dice (with n being large) and would need some more clarification.

[alanhoyle]

For me, it's not so much the sheer number of keystrokes, it's that I can't enter them all at once. A separator (or "non-number character") would work fine from my perspective, assuming that I could dump in as many numbers as I care to generate all at once.

--

• Alan Hoyle - alan@alanhoyle.com - http://www.alanhoyle.com/ -

On Wed, Feb 6, 2019 at 11:55 AM Uli Fouquet notifications@github.com wrote:

Mixing up lowercase and even uppercase letters just to save some keystrokes? Nah, that would confuse people more than it would help. Could you tell quickly how "42" had to be written as a d62 code? How many other people would do that accurately and on the fly?

I am afraid, what you request seems to be some kind of "smart" understanding of user input. I would like to avoid that.

Maybe we could change the goal to accept some input format, which is better suited for machines. But this should then be suitable for n-sided dice (with n being large) and would need some more clarification.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ulif/diceware/issues/58#issuecomment-461099286, or mute the thread https://github.com/notifications/unsubscribe-auth/AARr84zP_w_ev93QJhf79Fyuo3Ai06m-ks5vKwkXgaJpZM4akTUF .

[ulif]

Okay, that sounds good :) I guess I can find a solution for that problem.

[alanhoyle]

My apologies for being a neophyte for how to test a well developed python program like this.  I've cloned the git repo, and I've made a couple simple changes that I'd like to propose as a pull request, but I don't know how to actually run a locally modified copy.  

Basically, my proposed changes would be to use a regular expression instead of space to do the split, and allow excess rolls that might get discarded:

import re
# [....]
# LOTS OF LINES OF CODE
   def __get_rolls(self, num_rolls):
        """Ask the user for all dice results at once
        """
        rolls = []
        valid_rolls = [str(x) for x in range(1, self.dice_sides + 1)]
        while len(rolls) <= num_rolls or not set(rolls).issubset(valid_rolls):
            rolls = re.split('\D+',input_func(
                "Enter your %d dice results, separated by non-digit characters: "
                    % num_rolls))
        return [(num_rolls - i, roll) for i, roll in enumerate(rolls)]

[adinklotz]

@alanhoyle Did you follow the developer install instructions in the README? Once you source the virtualenv and install the tests you should just be able to call diceware for the modified program and py.test to run the tests.

With regards to your changes, in my opinion as Some Internet Guy: Allowing non-whitespace characters as separators does seem reasonable; that way you can do it comma separated or something if you prefer. I'm not sure about allowing excess rolls though. It seems to me that typing in more numbers than needed would generally be a mistake (e.g. accidentally typing 1 2 3 4 5 6 <enter> 7... instead of 1 2 3 4 5 <enter> 6 7 ..., which is the kind of thing I do when I'm typing too fast), and I'd rather a sensitive program like a password generator inform me about mistakes early rather than try to silently deal with them. What is the situation where you would actually want to give it an extra die?

[ulif]

Hey @alanhoyle, the idea to accept any sequence of non-digits as separator sounds promising to me :) I hope that the description for running tests (@adinklotz linked to it, thank you!) helps you get going. It really comes down to creating a virtualenv, then running a few install commands and that's it. Please tell if you would like more details.

Oh, and for pull requests you might want to create a diceware fork (not only a local clone) on github and work on that before submission. Github provides some magic to turn such forks into pull-requests when you are done with your changes. If you are uncomfortable with that, a simple diff with your changes will do as well, of course :)

[ulif]

@alanhoyle @adinklotz I opened the new issue #74 to continue this discussion and narrow the topic a bit.