A word about the complexity of the address list command

[buhtignew]

I've been thinking about the reason I was not able to use correctly the -w and the -o in the issue #122 and I came to the following conclusions:

In short 1) We have 13 flags in the address list command; 2) 5 of them (about 38%) have to do with the labels; 3) the word "mode" is used in two different meanings inside of the different sections of the help.

Explanation of the above 3 points: 1) It literally impossible to test all the flags combinations - there are more than 6 billions. Even without considering -w and -o and with the recent reduction of -b to be used with the -l and -f only, there are still millions of combinations left. I've tested about 5K of them (knowing, unfortunately, that it's possible you would not appreciate my effort) and the majority of them were providing meaningful results, some were throwing errors I haven't reported because I don't really know which one will make you angry at me. However I've given up for the moment (unless you have some solution to this) - I feel it's just impossible to test all of the combination of the flags of the address list command. 2) We shouldn't assume people would read the help sequentially, learn it by heart and make all the logical connection between its different sections. At least although I've read the address list help dozens of times so far it's still difficult for me to keep the whole thing in my mind. It's especially difficult to remember in the same time all the distinctions between the different flags that have to do with the labels. For that reason it's was quite natural for me just to try them one by one specifically because not all the explanations were that much clear to me (see the next point). 3) The word "mode" has two different meanings in context of the address list help:

• "flag" in case of -w and -o description and
• "the sequence of commands" in the expression "Usage mode"

To understand "In advanced mode" expression in the -w and -o explanation one should have

• read the help sequentially, which doesn't always happen because people often look for a quick solution to the issue they are trying to solve,
• have memorized that -a flag means "Advanced mode" (and not some advanced combination of commands, for instance)
• and, differently from any other place in our help where we stating this things explicitly, on the basis of the previous two operation to make the conclusion that "In advanced mode" means "with the -a flag only". And all above while he is trying hard to understand and to memorize the difference between the different flags that have to do with labels (see the previous point).

I'm not sure there will be many users that will be able to make all this computations that quickly.

At least I was not able to, sorry.

[d5000]

I think there's a misunderstanding: I don't require you to test all option/flag combinations. I apologize if you thought that and wasted time on it, even if I don't remember having written that.

Such "minor issues" can be tested in an automated way once unittests are there. I wanted to start with that long ago already, but this needs the feature/option set to be stable (frozen), and there were until recently still major bugs (for example, the recent block locator issue, and the token list issue, which were my main focus in the last week) and also feature requests (to change or add features), so it still doesn't make so much sense.

You sometimes write very good bug reports, but sometimes your testing is a bit unfocused. And we're taking much more time I had thought before (so no, I don't think Q3 is realistic anymore for PoB launch). This is the reason why I sometimes get a bit "spicy", above all when you complain about minor things in options I don't consider that important.

I have regretted to have added so much complexity to some commands, but now testing on most options is almost done so it also doesn't make sense to remove them, and most are in some way useful.

Perhaps I should have written that earlier in a more clear way, but what would be incredibly helpful, if you want me to continue with this project, is to focus on commands would be useful for most users and test these with priority.

The focus is, as I wrote somewhere else I think, the PoB/AT token function as this is meant as the first thing to be launched on mainnet. Important steps are:

• create (spawning) a new token
• burn coins or send coins to a gateway address (depending on it being PoB or AT)
• claim tokens
• and then check if they are shown correctly.

Then there is the block locator feature which is unfortunately necessary due to the slimcoind bugs which leads to inconsistencies in the balances.

And later then the DEX, which would be also important to test before PoB token launch, so people can buy/sell the PoB token trustlessly from the start.

In contrast, the label management is for me a secondary feature which adds comfort for the user but is not that important, except perhaps for decks. If there are minor shortcomings with commands like address list or deck list this isn't that serious for me, and this is as I wrote above solvable with unittests mostly.

Regarding the address list help I've already added the clarification that -a is meant with "advanced mode". Of course I can't guarantee that some words in the help aren't used ambiguously. That's why the help thread is a good idea.

[buhtignew]

I'm happy for your reply. Because it has made me clear many points that weren't that obvious to me.

I'll reply here to some points to make us understand each other even better, if possible.

I don't remember having written that.

You have never asked me about. My thought was that since we've dedicated a bit of time to this project it worth making it as perfect as possible so I was trying hard to discover every slightest thing that can be improved. The issue with my approach is of course that there is not limit to perfection and we would be risking to stay here for years improving something we don't even know anybody would use. However in my experience I'm not able to evaluate whether an issue I'm seeing is urgent or not to solve. Sometimes I think to have found something big and it's just nothing, the other times I feel that the issue can be solved in a few lines of code to discover from your feedback that it's almost impossible to solve, the other times I find something small and by looking into it you are finding an important bugs nearby I was not aware of which requires weeks to be solved, there are other times that I feel something is important and it's not, and finally there are things that are real bug and we both agree on it. I think the perception of what is important and what is not is quite subjective and it's your availability that dictates us what should we implement and what we shouldn't. That's why I just mine the code over over again by making tests or by looking into it each time from a different prospective and try to provide as much feedback as possible. The sad thing for me is that that quantity of feedback makes you sometimes angry at me as if I wasn't respecting your work, while on my side it's just the opposite. For that reason along with the help improvement thread I've decided to create the wish list thread (in order to avoid losing something already found) where to keep things that I feel as important, but you think they are at least not urgent at this stage. I'd also like to share with you this my assumption: as much bugs we find and solve as much the quantity of the important bugs will decrease and the majority of the bugs we'll be finding over time will be less and less important and urgent. If so that explains better why is it that I'm not finding that much of important bugs anymore.

I don't think Q3 is realistic anymore for PoB launch

If we consider Q3 as the 1 of July I think it's not realistic and I was positive about since the first time we've spoken about that deadline, but I'm trying to work hard on my part and maybe we can hope to be able to deliver during the month of September, which is still inside of the Q3. I'll try to adhere to the most urgent things you've mentioned as much as I can. I'm going to finish with the address group check, finish the work on the block cache feature and then will concentrate on the priorities you've mentioned.

[d5000]

I'll be more selective in the next weeks with the issues I fix due to limited time. If something is better to be fixed with an unittest, I'll leave it open until I go for the unittests. I have created the "on hold" label for these issues, they can be left open if not too many pile up.

I will not accept deadlines. It's done when it's done. The Q3 estimation was based on my naive estimation that the PoB features would take at most 2 months to test, and that the CLI was already stable with exception of minor tweaks. We're 5 months in already. To be fair, that was not only caused by the CLI and label management discussions but also by two major bugs, but it is what it is. The release date will depend on how efficient the testing process is.

[buhtignew]

Agreed.

This can be closed, IMO.