-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Telnet Broken #3108
Comments
Terry, Thanks for splitting this out. Several things (1) Given that these symptoms have been separated from #3080, should I learn from this that only if I, the user, can definitively state that differing symptoms have the same root cause, should I keep them together? In this instance, it seemed plausible to me that they were related (e.g. how many undesirable things can happen at the same time), but technically I have no idea. As such, the symptoms should be separate, and optionally referenced as possibly related. Gotcha. (2) The bits missing from above HardwareDescribe which ESP8266/ESP32 device you use and document any special hardware setup NodeMCU Ver 0.9 (4M byte, ESP-12)
Other
Please Note
|
It appears that dev branch simple telnet without LFS (memory reserved, nothing flashed) also fails. Same firmware as above. No LFS flashed. Symptoms:
Serial Console (Dev Branch)
Code
|
@pnkowl, what's wrong with Read the |
@TerryE, I am trying to help, but I feel you are not feeling it, for what I believe from your perspective are understandable reasons. Summary
DetailsHow I got to the summary. Please note that the realization that Dev and Master are incompatible did not occur until very close to the bottom. I did not split this issue out. You did. I thought this might be relevant for the issue with LFS web service, so I added it as a comment there. I did not believe it should stand alone. I believed at the time, that the versions of telnet that I use worked with the dev firmware without LFS. I have explained this elsehere. If I recall, as part of this ticket, telnet fails for all 3 of the telnet versions I have acquired (kindly developed by others and shared) Here is another example from the master branch docs found at
and please note, there is no other reference on that page to other versions.
Okay, so let's try the same code using master branch firmware So this certainly seems to be a "better" MCVE than say the version that uses fifo, and fifosock and LFS. Have I missed something regarding MCVE? Perhaps the root problem is the need for "Minimal, Complete, and Verifiable example". This asks for the issuer to attempt to reduce the scope to its smallest extent. I understand this to mean, the smallest amount of code. The example that is most closely aligned with the official documention. To the extent that I can come up with inline code, I should. I agree with this in principle, I agree with its sentiments in practice. So I have presented an example, that works with the master branch and fails to perform as expected with the dev branch, and where the example is exactly the code as provided in the docs (albeit master branch).
Not to jump off the cliff, but this quote does not say that dev and master are not compatible with respect to "telnet" functionality. But after inspecting both sets of docs, this is exactly what appears to be happening. Dev breaks Master branch existing user application code and nowhere in the Dev branch node.output() section is this surfaced, not in a caution, not in a note, not in the fine print and not in our dialog so far. There is at least one lesson here somewhere... |
@pnkowl, you are right about me being (unfairly) a little irritated. Sorry. We are in the middle of a major piece of roadmap work, at the moment. We've added the option of a Lua 5.3 runtime engine; this in itself involved a lot of work. Getting the NodeMCU framework and modules to work under both variant APIs a lot more, and we know there are holes in the documentation. The intent was for me to do the bulk of the complex runtime changes; get a working software base available for everyone to use, and to have a shared effort at tidying up the documentation, but ... The simple telnet server isn't compatible with Also the current issue templates probably aren't a good fit IMO for discussing documentation issues. |
@TerryE, thank you for your latest reply. If I can follow up on the last point you shared
Okay, then what is? In my previous life, documentation (the written, non coded word) was the foundation for everything. It described the customer requirements. It was the design spec. It bounded unit test. It was the validation and verification plans. It was the end user documentation. It was the gantt or pert chart showing project dependencies, resource flexibility and allocation, critial paths and where risks needed to be attended to. If the documentation says the system has x behavoir, then if the customer observes x behavior, the systems is as designed -- even if it turns out that the behavior is less desireable -- at least the behavior is out in the open. From a strict perspective (IMO), bugs are when the mismatch between stated and actual function occurs. Upgrades and/or enhancements are when improvements above and beyond the current spec. are attained. Today, very little of this formality exists in much that is commercially produced. Customers just have to figure it out by trial and error. I find it very encouraging that Nodemcu seems not that way. If it were, there would be no way to even have this conversation. So for that, thank you. If the team currently struggles with this kind of thing, then perhaps that is where my talents would be most beneficial. |
@TerryE, one more thing in an effort to show support for you. If, when you are done reading, and you are not feeling it, let me know.
I was shocked when I read this, not by the tone (which I can understand), but the underlying truths not really said
|
The sad fact about nodemcu is that the majority of the code comes from a small (very small) group of people. In my case, a few years ago, when I wanted to build some apps with nodemcu, I discovered issues with the code. I realized that these issues were not important to other people, so the only solution was to fix them myself. I also needed device drivers, so I wrote those too. I also contribute (mostly small stuff) to a number of other open source projects. There is a huge difference between these projects as to how receptive they are to pull requests. There is one project where PRs are merged within hours, and others where it can take months. Is this frustrating -- yes. My approach has been to realize that the maintainers are people just like us with views on things 'ought to be'. Then I engage with the maintainers to figure out how they want to interact with contributors, and modify my style appropriately. |
A quick answer to @pnkowl. Long one tomorrow. The reality is that we tend to triage new to project posters. Anyone who looks like they are taking the time and effort to engage gets an immediate karma bump whatever the content of the contribution. So I am happy to give my time if the other party is going to do likewise. |
I notice many parallelisms between NodeMCU and an old programming language favorite of mine, REXX. It might be worth considering the adoption of the "documentation before implementation" approach used by the REXX Author: The Design of the REXX Language (page 334)
Read through that entire document when you have a few minutes. IMO, there are several morsels of insight contained within that might help make the NodeMCU journey a little easier for all of us. ;-) |
@jmd13391, Thank you for this. I happen to identify stongly with where I believe you are coming from, which brings back memories for me. Those were the days when IBM was on the last part of its ascendency and where resources were plentiful.
I have read the page your referenced, have returned to the beginning, and was about to put pencil to paper, and I realized that I was about to collect "my" morsels. Would it be possible for you to share the several morsles of insight you thought may help? (apart from what you posted here). I continue to have to remind myself to listen more, and then confirm that I understand. |
The issue with the old strategy for telnet was that Lua code (and C runtime libraries) could call
In short these example telnet sources were OK for a carefully created "in principle" demo but were unusable in practice. Various issues including #2033, #2541, #2797, #2802, #2884 have discussed this in the past. Using a pipe for STDOUT has a lot of advantages. Marshalling and packet splitting is handled automatically. With the new error handling (see #3078) errors get sent to the telnet session and the user can elect to suppress restart on panic. The
What really confuses me here is that all of our references to "telnet" in our current documentation refer to this |
@TerryE, Very nice concise summary (as far as I can tell, not having tried the new pipe version yet). I think this gets to the nub of the disconnect (my emphasis)
I can understand this! Dev is where developers spend the bulk of their time. To be effective, they must naturally think in the context of that environment. For developers, "dev" is a fact. For me "dev" is a hope. Here is an example, of the same symptom. Please understand it is an example worthy of MCVE (e.g. trivial in scope). The backstory may be relevant in developing an understanding of how disconnects develop, so here goes. 20 days ago, I opened my first issue #3080. This issue pretty much stopped my development tasks (which I do using the master branch). I found little things I could do while waiting for a fix, but 10 days ago, I read issue #3095. Issue #3095 touched on a topic in my less fun list of formally documenting the oddities I have seen during my Nodemcu journey. So I did the analysis and opened #3096. I see dev as an extension of master, and unless specified, behaves the same or better. So some of the observations (reported as issues) contain a dev banner. Out come #3108, #3109, #3110. I have others I am working on. I see this work as reporting observations (tbd facts), possibly relevant to others. The following example comes from an issue under the "master" banner, but to me, I am just documenting observations. Enough backstory, back to the point at hand, can you see the minor disconnect in the following dialog? posted by @TerryE in #3096 (comment)
posted by @pnkowl in #3096 (comment)
posted by @TerryE in #3096 (comment)
All good, right? I thought so at the time, but it shows how miscommuncation occurs when our frames of reference are not the same. I think if master and dev are considered 2 different applications, all is okay, but if they are related, then that which differentiates them should be clearly stated, both the pluses and minuses. In this instance I offer the following. Dev (soon to be master) contains telnet functionality that is
<1> I am not even comfortable naming "dev" and "master" in this proposed statement. As users, we paste the "NodeMCU startup banner" to communicate what we are using, which as far as I can tell, differentiates them commonly by "dev" and "master". But dev becomes master, so these names are temporal. As such, should we be using other information to ensure clear temporal naming during our discussions during the transition? Please also note that the 3 bulletted items above are not to pass judgement, but to simply, and as clearly as possible, state the facts I believe are most beneficial to users not intimately involved in the change, and to those that may not be terribly interested in any more detail regarding the change, than what needs to be done to their applications to keep them from breaking. In terms of getting the word out, I would include this information at the following project "checkpoints"
I would also recommend that the current master documentation be made easily accessible for folks that continue to use that as their application development platform while the dust settles on the new. |
Somehow the updates to The next cut should fix this. Marcel and I will take an action to check that the documentation is in sync on the next cut. I really don't know why it has to take 10,000 words of dialogue to go over the same ground what seems to be about 5 times. Marcel and I will take an action to check that the documentation is in sync on the next cut. |
Expected behaviour
(Copied from @pnkowl: #3080 (comment)) The telnet module should work as expected on
dev
andmaster
Actual behaviour
LFS Dev branch is not dead like master, but not as expected either. I tried 3 versions of telnet and none worked. All returned a never ending stream of the following to the putty termial:
Note that Firmware Dev Branch with "simple" telnet (run without LFS) seems ok. BTW, FTP seems ok
.
Test code
ESPlorer terminal looked like this. Note that the E;M "error" occurred many seconds later, after the putty sesson was "closed")
Most simple local telnet version
telnet.zip
NodeMCU startup banner
Hardware
Describe which ESP8266/ESP32 device you use and document any special hardware setup
required to reproduce the problem.
The text was updated successfully, but these errors were encountered: