unix + mpy

[stijn]

I want to test .mpy files with the unix port. What is the recommended way to do this, and is this documented somewhere?
I built mpy-cross on but mpy files created with it cannot be used with the unix port's micropython executable because of a mismatching MICROPY_OPT_CACHE_MAP_LOOKUP_IN_BYTECODE definition. So I go ahead and put that to 0 in unix's mpconfigport.h. This results in:

Code: Select all

Creating build/frozen_mpy.c
CC build/frozen_mpy.c
build/frozen_mpy.c:7:2: error: #error "incompatible MICROPY_OPT_CACHE_MAP_LOOKUP_IN_BYTECODE"
 #error "incompatible MICROPY_OPT_CACHE_MAP_LOOKUP_IN_BYTECODE"
 

That's a very chicken-and-egg type of problem. So I end up removing the 'FROZEN_MPY_DIR = modules' line from the unix Makefile and then everything works together.
This really feels like I'm doing something wrong or not as intended. Is there an easier way to do all this?

Also using 'python mpy-tool.py -d xxx.mpy' results in

Code: Select all

Traceback (most recent call last):
  File "../tools/mpy-tool.py", line 593, in <module>
    main()
  File "../tools/mpy-tool.py", line 584, in main
    dump_mpy(raw_codes)
  File "../tools/mpy-tool.py", line 457, in dump_mpy
    rc.dump()
  File "../tools/mpy-tool.py", line 242, in dump
    rc.freeze()
TypeError: freeze() takes exactly 2 arguments (1 given)

Just changing line 242 into rc.freeze('') fixes this but I'm not sure if that's the intent?

Sidenote: unix builds require seperate 'make axtls' and 'make' steps, but 'make clean' also cleans actls. That is confusing. Again, is this supposed to be used in another way maybe?

[pfalcon]

First of all, couple of months ago I also got that idea "heck, we have frozen bytecode for long enough that we should make it actually easy to use". So, there're definitely trails you could follow now, dumped below.

So I go ahead and put that to 0 in unix's mpconfigport.h

As noted elsewhere, there's no need to do that. Ideas which could lead to that conclusion are:

1. mpy-cross --help
2. Checking how mpy-cross is used in the existing ports (unix and esp8266 built frozen bytecode by default).

[pfalcon]

Trails I mentioned above are accessible from https://github.com/micropython/micropython/pull/3057 .

It's a bit zigzagish, because after you played with .mpy's, you understand they're not much useful on their own (beyond unix port, and unix port is still usually used to test stuff for other ports). For example, my latest conclusion is that, while having added mpy_cross_all.py was useful to cover a development workflow gap, the best realworld way is "upip install -p modules <something>". To that end, one of these months I'm going to add make clean-frozen target. That still doesn't solve the issue completely, as even with zigzagish turn to https://github.com/micropython/micropython/pull/3228, not all files can be frozen-bytecoded (hint: @micropython.native). That all requires an RFC, but there're too many open RFCs already.

[pfalcon]

Sidenote: unix builds require separate 'make axtls' and 'make' steps, but 'make clean' also cleans actls. That is confusing. Again, is this supposed to be used in another way maybe?

"make clean" in MicroPython works very simple: it cleans. Cleans in a reliable way, such that after it you can try any other config in the same dir.

Beyond that, (pseudo)automation is known to cause more problems than it solves. We already tried to automate mpy-cross building, and now it causes unneeded delays in the real development workflow: https://github.com/micropython/micropython/issues/3255 .

[stijn]

As noted elsewhere, there's no need to do that

Yah I forgot to come back here and mark it 'answered' after this was pointed out already in https://github.com/micropython/micropython/pull/2911

"make clean" in MicroPython works very simple: it cleans. Cleans in a reliable way

That's a good argument, and my point is actually the same argument but for the counterpart of cleaning, namely buildng: it would be nice if "make" or "make all" (especially that one) would work very simple and would just build micropython. It would be nice and symmetric.

[pfalcon]

would work very simple and would just build micropython

Yeah, sure. And patches welcome. But above is the counter-example when desire to make it "simple" caused it to be actually more "complex" for some people (just those who produce many commits). It's actually on my todo list for some time, but now I'm actually discouraged to look into that by the mpy-cross auto-build case, and need instead to look on undoing its effect.