MicroPython Forum (Archive)

That looks nice. What is the target audience? School or kids or adults, or everyone?

The only “documentation” is the code … which is terribly documented. Sorry, but no. Most of MicroPython's code, as well as the git commit log, is so well-written and self-documenting it does not require additional documentation in order to understand it. Though in order to understand it you usually...

Yeah having to acquire code by running Python to return the code as a string is quite a convoluted way for something which can be achieved in many, many other ways, most of them easier. Also because you have to get the source in there in the first place. And what if the .mpy has a problem and the co...

I tried to build MicroPython on a Raspberry Pi 3 here >> uname -a Linux rpi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux >> clang --version Raspbian clang version 3.5.0-10+rpi1 (tags/RELEASE_350/final) (based on LLVM 3.5.0) Target: arm-unknown-linux-gnueabihf Thread model: posix...

Sorry I missed that part about the other asm statements; the assembly written is likely some gcc dialect. However you don't really need asmarm.c to get a working executable: #define MICROPY_EMIT_ARM (0) in your mpconfigport.h and it will skip what's in asmarm.c

it's your compiler that's the issue Looks like in this case one could equally well say MicroPython's code is the issue here: it works ok for one compiler but not the other on some code which is (as far as I know) not subject to any real standard. Should this be some valid C99 code which gets reject...

Plus you can debug the Unix port's C code using gdb if needed

If you want to do that in an accurate way you'll have to measure it. There's nothing inherently time-consuming in gc.c (except possibly the calling of the finaliser since that calls arbitrary user code): operations like VERIFY_MARK_AND_PUSH are just load/comparisions/store. It's just that they get c...

with nothing to actually collect Are you sure? Standard MicroPython allocates one big chunk of memory at the start of execution and then continuously uses that. Once all memory in it has been used and/or fragmented there is a need for gc_collect. Only if you never reach that threshold there is noth...

There's no need to duplicate that for each and every port. Just look them up in mpfonfig.h (if that takes a lot of time you are using a crappy text editor and cannot really blame the code for it), where pretty much all of them have one or more documentation. If that is not sufficient paste the macro...