10000 main.py not executed, but can be imported. · Issue #2026 · micropython/micropython · GitHub
[go: up one dir, main page]

Skip to content

main.py not executed, but can be imported. #2026

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

Closed
dmarkey opened this issue May 2, 2016 · 15 comments
Closed

main.py not executed, but can be imported. #2026

dmarkey opened this issue May 2, 2016 · 15 comments

Comments

@dmarkey
Copy link
dmarkey commented May 2, 2016

Hi,
cat scripts/main.py
import webrepl
webrepl.start()

But on boot:
could not open file 'main.py' for reading
#5 ets_task(401002d8, 3, 3fff5180, 4)

MicroPython v1.7-257-g26fd0ac-dirty on 2016-05-02; ESP module with ESP8266
Type "help()" for more information.

However I can import main...

import main
WebREPL daemon started on ws://192.168.4.1:8266
Started webrepl in setup mode

@pfalcon
Copy link
Contributor
pfalcon commented May 2, 2016

cat scripts/main.py

Why do you think there should be scripts/main.py ?

@dmarkey
Copy link
Author
dmarkey commented May 2, 2016

Oh, that isnt the place for it? I thought that folder was transferred onto the rom (and it is as I can import main)

@pfalcon
Copy link
Contributor
pfalcon commented May 2, 2016

Yes, scripts/ is system-level thing, useful for advanced users. Novices and end users in general should not change (or add) anything to scripts/. The main.py should be in the filesystem.

@pfalcon pfalcon closed this as completed May 2, 2016
@dmarkey
Copy link
Author
dmarkey commented May 2, 2016

Cool, and whats the best way to get main.py onto the filesystem?

@pfalcon
Copy link
Contributor
pfalcon commented May 2, 2016

The best to find an answer answer to any support question is by joining and reading forum at http://forum.micropython.org/ . You are welcome to use this bug tracker for bug reports.

@dmarkey
Copy link
< 8000 span aria-label="This user is the author of this issue." data-view-component="true" class="tooltipped tooltipped-n"> Author
dmarkey commented May 2, 2016

Obviously this was not intended to be a support question as I opened the bug as it wasn't clear to me where main.py should live. (I still think that if main.py is in scripts it should be executed. But thats just me.)

@pfalcon
Copy link
Contributor
pfalcon commented May 2, 2016

Sorry, "wasn't clear to me" isn't a bug. It's either lack of studying the topic on your side (or using wrong resources), or an issue on our side of not providing clear/accessible documentation. That's why I asked why do you think there should be scripts/main.py in the first place.

@dmarkey
Copy link
Author
dmarkey commented May 2, 2016

In this case the bug is the error message should be more precise. "could not open file 'main.py' for reading" is ambiguous, it should read "could not open file 'main.py' for reading from the internal filesystem" or something to that effect.

@pfalcon
Copy link
Contributor
pfalcon commented May 2, 2016

What makes you think it's an "error message"? Maybe it has "error" in it, or colored red? It's a standard diagnostic boot message which any booting device produces bunch (or gazillion) of.

@dmarkey
Copy link
Author
dmarkey commented May 2, 2016

I dunno where the attitude is coming from.

I'm simply trying to suggest an improvement that would have avoided the need for me to open this ticket.

If the message had have read "could not open file 'main.py' for reading from the internal filesystem" it would have been pretty obvious to me what the problem was, hence I wouldn't have bothered opening the issue.

@pfalcon
Copy link
Contributor
pfalcon commented May 2, 2016

It's coming from people who seem to come with more or less random (alternatively, severely outdated) presuppositions (e.g. that scripts/main.py should run). When asked where they got that idea, they ignore the question, and instead keep repeating their more or less random presuppositions, ignore hints that there's actually something to learn on their side.

If the message had have read "could not open file 'main.py' for reading from the internal filesystem" it would have been pretty obvious to me what the problem was, hence I wouldn't have bothered opening the issue.

Right, it was the same to me with the cases like #2022 - I took my macbook and went to Apple shop, straight to Genius Bar or how it's called, and told them: "hey, your ar is broken, fix it!" And they replied: "Yes, sir, you're right. But we won't fix it, so learn to deal with it." So I did. P.S. the message is of course generic and not tied to any filesystem and can't be changed on a whim. Clean patches are always welcome though, but it may take some good argumenting that there's actually something to fix.

@dmarkey
Copy link
Author
dmarkey commented May 2, 2016

Given there is no mention in the documentation (https://docs.micropython.org/en/latest/esp8266/) as to where main.py should live, it's pretty reasonable to think that if there are a load of python scripts in the "scripts" directory that main.py would (and probably should) follow the same pattern.

Flaming people that are genuinely trying to test and suggest improvements to a project is going to be counter productive in the long run.

@pfalcon
Copy link
Contributor
pfalcon commented May 2, 2016

Yes, so I'm trying to explain why questions asked in response are important, and why answers to them are useful. The common situation we have as that some random guy wrote in his blog something year ago, and now people come and report "that it doesn't work". And extracting the fact that it's all based on some old "gossip" is quite effortful, as many people come with assumption that they know how it should be, and if that doesn't work for them, something is broken.

Given there is no mention in the documentation (https://docs.micropython.org/en/latest/esp8266/) as to where main.py should live

Right, and the documentation isn't ready yet, so so far the port is of interest to developers, and all the information is available in git log and tickets here. And from people who're interested in contribution, we really could use clear 8000 and concise reports, not long arguments on who knows better what should be done.

@pfalcon
Copy link
Contributor
pfalcon commented May 2, 2016

Description of the boot process has been pushed as a22aa53 . It will be on docs.micropython.org tomorrow. Comments/suggestions/articles fixes from native English speaker are welcome.

@zinahe
Copy link
zinahe commented Jul 7, 2018

Hi,

I'm reading this conversation 2 years after the fact, but can't help but comment that the attitude from pfalcon was completely uncalled for. I can understand him getting frustrated with having to deal with mundane issues repeatedly, but he didn't have to take it out on dmarkey so harshly.

My opinoin.

tannewt added a commit to tannewt/circuitpython that referenced this issue Aug 6, 2019
Fix missing write_ram_command in _stage
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants
0