Avoid flash wearing by altering behavior originally introduced by Espressif (the inventor of the ESP8266)

[pfalcon]

We are all working in respect of the community, that is for sure. I do not count contributing in "commits on github", "grep -r <author> docs/* | wc -l" or the like, but in commitment and helping and assisting the community. Even you should be able to see that i do work with stuff the community did create. I am just a stupid user of the things you and others do create, that is for sure.

That's definitely true, and a lot of people contribute to MicroPython in a lot of different ways. That's much appreciated by everyone. And there's no need to be blocked on a specific way to contribute, or on a specific change. The fact that there's a delay on some matter should not put off anyone.

Regarding this poll and what i am really angry about is the fact that my name is attached to my posts, including the top post. So as long this is my name tag and portrait attached to it, this is my poll. Like it or not, moderate by commenting in posts of yours and act accordingly to forum workflows. But *NEVER* put words in my mouth and let them look like mine.That is what you seem to not understand.

Somebody really doesn't understand something. Let me quote it for you:

Summary of the nature of the changes proposed (summarized by Paul)

Sorry, but there's only one first post in each thread, and many people don't read beyond first sentences of it. So, if you call for big changes, but fail to start with a good summary, it still needs to be done. That's what you don't understand. As a moderator, I will change (or delete) any post if required for normal community process. Note that I almost never do that, and overall, we have very liberal forum. On many forums, it's permanent offtopic to discuss moderator's actions, and attempt to do so equals "cool down" ban for a user.

Do not blame us for being busy. You by yourself did set the timelines, so blame yourself.

I don't blame, I explain.

You do partially get paid from my 40 pounds for the ESP8266 kickstarter. I do know that i am only one of many. But I imagine to be one of the few to open their mouths when they see unfair and suggestive treatment.

Rest assured that I remember that very well, and appreciate it. That's also why I explain the situation (instead of ignoring anything which "doesn't fit"), and in general glad to answer your (or anyone's) concerns and happy to seek a solution. I'm also very glad to see that you remember that there were many other people who paid. You also may be reminded for what all those people paid - it's written (and was always written) at https://kickstarter.com/projects/214379 ... -easy-iot/ . So we do that, then anything else, as much as we can, when we can. And let me be straight: I value my time much (100USD/hr) and I already spent on answering your concerns more than you paid for. If you want to continue this useless discussion, I will have to bill you for my time.

P.S.: I do not want your shoes and never asked for them!

Then please keep calm and enjoy.

[kfricke]

...And let me be straight: I value my time much (100USD/hr) and I already spent on answering your concerns more than you paid for. If you want to continue this useless discussion, I will have to bill you for my time.

Was discussing pointless things on the forum a stretch goal? If so, try to!

[kfricke]

Do not blame us for being busy. You by yourself did set the timelines, so blame yourself.

I don't blame, I explain.

Sorry, i did try to evade "whine" in my quoted post.

[kfricke]

Somebody really doesn't understand something. Let me quote it for you:

Summary of the nature of the changes proposed (summarized by Paul)

Sorry, but there's only one first post in each thread, and many people don't read beyond first sentences of it. So, if you call for big changes, but fail to start with a good summary, it still needs to be done. That's what you don't understand. As a moderator, I will change (or delete) any post if required for normal community process. Note that I almost never do that, and overall, we have very liberal forum. On many forums, it's permanent offtopic to discuss moderator's actions, and attempt to do so equals "cool down" ban for a user.

When such an initial post for a discussion around "my" pull request does not correspond with your view of this matter. It is not your right to lay any words into my mouth by silently moderating it. That has nothing to do with your majesties general kindness to allow very liberal posts. It is a misuse of responsibility and power.

Having read my initial post again today made me aware that you did moderate it actively. This is why i do get angry and no hundred keep calm stickers can cool me down that easily (and those usually can! )

[warren]

Please excuse me if this is a stupid question! It's just not obvious to me that providing the 'extra' functionality of NOT saving to flash will be "backward-incompatible and will confuse some users." [The phrase in the user poll...]

Let's assume you have a python function - lets call it "oldversion", such that it expects just one variable; "first_var":

Code: Select all

def oldversion(first_var):
    print("Hello World")
    #Do some stuff with first_var

This gets built into a library that lots of people use to write custom code that depends on it....

But then, some time later, a new version is released, this one offering more functionality which is enabled by a SECOND variable:

Code: Select all

def newversion(first_var,second_var=0):
    print("Hello World")
    #Do some stuff with first_var
    if second_var!=0:
        #do stuff with second variable, IF PRESENT

People who wrote their custom code with the old version could simply replace it with the new version. It would not break anything. Their custom code would never set the second variable, and so the extra functionality would not be invoked.

In the context of this thread about saving to flash, the second variable would specifically invoke the behaviour of NOT saving to flash, like this:

Code: Select all

noflash=1
WLAN.active(TRUE,noflash)
WLAN.connect(wifi,passwd,noflash)

The extra available functionality of the new version would not confuse anything or break anything - would it??

Custom code written with the old version would simply run as formerly even if you replaced the old version with the new.

And users of the the old version would only need to know about the possibility of using a second variable if they wanted NOT to save to flash. You just tell them there is an upgraded version of the function... Windows DLLs have done this repeatedly in the past...

Why would this not be a reasonable fix here? Have I missed something really obvious?

Thanks...

[ernitron]

In the context of this thread about saving to flash, the second variable would specifically invoke the behaviour of NOT saving to flash, like this:

Code: Select all

noflash=1
WLAN.active(TRUE,noflash)
WLAN.connect(wifi,passwd,noflash)

I had the same point: two more API or an optional parameter is almost the same stuff and I think it was originally proposed by someone. But I guess the questions here are lost in translation (quote from an old movie with Bill Murray and Scarlett Joahnsson).

[warren]

I had the same point: two more API or an optional parameter is almost the same stuff and I think it was originally proposed by someone. But I guess the questions here are lost in translation (quote from an old movie with Bill Murray and Scarlett Joahnsson).

Apologies to the OP in that case! I spelled it out a bit 'longhand' because it seems there are a lot of lurkers/learners here who may have felt bemused that it was not possible to add the functionality in a way that would not 'break or confuse'....

I think that the language of the poll question may seem to be a bit prejudicial, or too stark for this issue...

Thanks

[kfricke]

I still see this topic closed. But for completeness to everyone and irony in this discussion: pfalcon did comment this in #2510 as well with a reference to a previous pull request #2506, where he did say...

.connect() method is governed by its specification: https://github.com/micropython/micropyt ... wlan-class . Specification requires 2 arguments. Someone proposing something else will need to provide extended analysis and argumentation of benefits and risks, feasibility study of implementing such feature for networking modules in general, and example of implementation for a number of popular modules in particular. (Or alternatively, any other compelling argumentation for breaking API and sustainable plan for future maintenance.)

Where is the irony you ask? That pull request, where he said this, got merged.

[deshipu]

To be fair, adding an optional parameter, or an additional function that is not available in all ports, keeps the API backward-compatible, but makes the new code incompatible between the ports.

[profra]

I was watching this discussion and I thought some "vox populi" could finally appear. Personally I was backer of both MicroPython campaigns. Many years ago I used to work with microprocessors and after 25 years in business I have been back to this wonderful and exciting hobby.
As I can see, current level of discussion is destructive and should be terminated. I understand the arguments of both parties but at the moment I prefer to work quietly to achieve all KS campaign goals. Afterwards we will have enough time and hopefully also energy to improve.

Personally I prefer the function AUTOCONNECT (I know that this feature can be also changed), as after reset I have been always waiting for the connection with AP saved in flash memory, just then (if the failure) I try to connect to a different AP to which I trust (I have stored the information about them to a file which I always delete when connected... that means I don't have SSID not password in any open text). That means that I save AP parameters to flash memory once only... if I don't change the parameters where esp8266 is placed.

Moreover I think that during repeated connection to AP stored in flash memory thanks to function "wlan.connect (ssid, password)" it is not repeatedly saved to flash if the saved information is identical to function parameters... just because Esspresif knows the parameters of flash memories... Personally I would proceed it so and as I know, I'm not the most smartest man in the world, I suppose Esspressif does so... First of all, Esspressif reads the flash, compares the data and saves new data only if there is any difference.

That's why I think that section...

Code: Select all

 wlan.active(False)
 .
 .
 wlan.active(True)
 wlan.connect(SSID, PSW)
 

... doesn't save SSID and PSW to flash (reads only and compare) if saved information is identical to function parameters.

Please can someone agree or disagree with this idea?
I think if my opinion is correct, the whole discussion would be not "so hot".

P.S. I don't know what the functions wlan.active(True | False) really do... in HW