Port PyUnit/UnitTest module #44

piranna · 2014-01-03T02:38:33Z

It's the standard Python test library, and this way the tests would be done in an automatically way directly from inside the board... :-)

http://pyunit.sourceforge.net/
http://docs.python.org/3.3/library/unittest.html

pfalcon · 2014-01-30T20:54:57Z

@piranna, did you try to look into porting this yet?

piranna · 2014-01-30T21:01:13Z

Sorry, I didn't look on porting this, and currently I'm really busy with lessons and work. If you want you can take on it, I don't think it should be too dificult since PyUnit/UnitTest module is written in pure python...

msiemens · 2014-01-30T21:41:53Z

I'd love to take a shot on this. I'm fairly new to C development but pretty fluent in Python, so I surely would learn a thing or two :)

piranna · 2014-01-30T21:54:19Z

Please don't doubt on ask me anything :-)

dpgeorge · 2014-01-30T23:08:32Z

If it's written in pure Python (v3) then it would be a good way to test uPy itself, to see how well (or not!) it conforms to Python.

piranna · 2014-01-30T23:17:06Z

Seems PyUnit since it got integrated on Python source code it was not available outside and got outdated, maybe it's better to try it with unittest2, the backport version with the upcoming changes.

And yes, I proposed also as a self-test for uPy ;-)

Neon22 · 2014-02-03T09:23:42Z

@piranna I think I misunderstand you.
PyUnit is the name for the python unit testing framework - which is exposed in python 3.3 as the unittest module.
docs here: http://docs.python.org/3/library/unittest.html#module-unittest
It appears in your python 3.3 source tree in lib/unittest as a pile of python files.

unittest2 is a backport of unittest for python 2.4, 2.6 but as the python is in 3.3 version - why do suggest unittest2 ?
I know I'm missing something, apologies in advance.

piranna · 2014-02-03T09:36:34Z

@piranna I think I misunderstand you.
PyUnit is the name for the python unit testing framework - which is
exposed in python 3.3 as the unittest module.
docs here: http://docs.python.org/3/library/unittest.html#module-unittest
It appears in your python 3.3 source tree in lib/unittest as a pile of
python files.

unittest2 is a backport of unittest for python 2.4, 2.6 but as the python
is in 3.3 version - why do suggest unittest2 ?
I know I'm missing something, apologies in advance.

I proposed unittest2 because I didn't know where the PyUnit/unittest code
integrated on Python source code was, but both should be equivalent if not
the same. If the integrated one is located at lib/unittest, don't doubt it
and use it since it's the official, good one.

This kind of things is why I don't understand the reason python modules are
not in an independent source tree in CPython, you can't be able to locate
and reuse them easily on other projects. Maybe we could start doing it us
on MicroPython putting the ported modules like unittest in an independent
repo (github.com/micropython/python-modules, for instance)?

msiemens · 2014-02-04T18:08:40Z

I'm facing problems now. Currently uPy's import statement is very minimal. It only imports mod_name.py, no support for mod_name/__init__.py nor import mod_name.SomeClass or from mod_name import SomeClass (the last two result in failed asserts in compile.c, line 1197).

I was able to let uPy try to import mod_name/__init__.py, but am struggling with the rest. I'll propably will have to wait, until we have a more powerfull import (or use a big fat file without any imports -- but who would want that?).

pfalcon · 2014-02-04T18:18:31Z

Note that I'm working on import code to support sys.path. We apparently need to get decent module import support before going to support packages. But you're of course welcome to prototype how it would work - it won't appear on its own, someone who needs it will need to implement it (and my guess that MCU usage which is direct target of uPy can live happily without packages for quite some time).

probar · 2014-03-16T00:14:29Z

What about a python testing library running on the pc using full python , controlling the board through an remote procedure call ?

This way , we'll get remote procedure call library and an ability to test python using more testing tools(for example quickcheck ) and the full power of python ?

dpgeorge · 2014-03-20T23:52:54Z

There is now a way of doing RPC on the pyboard: you can enter raw REPL mode by using CTRL-A. This allows you to send arbitrary Python code to the board over the USB serial connection, and get the result back. I have written a small Python class that runs on the PC, which allows you to do pyboard.exec('....') and pyboard.eval('...'). I'll add it to the repo after I tidy it up.

dhylands · 2014-03-21T00:28:14Z

Sweet

pfalcon · 2014-03-26T22:14:29Z

I just pushed getattr() implementation, which was another missing piece to implement this stuff.

dpgeorge · 2014-03-26T22:57:04Z

RPC on the pyboard now exists as tools/pyboard.py

pfalcon · 2014-04-01T23:49:16Z

I did some hacking to run unittest-based tests in adhoc manner, and put up outcome of it here: https://github.com/micropython/micropython-lib/blob/master/unittest/unittest.py . Contributions are welcome.

pfalcon · 2014-05-12T00:08:54Z

micropython-unittest 0.0.5 has just been released to PyPI: https://pypi.python.org/pypi/micropython-unittest/0.0.5 . The module now has more than a kilobyte of code and can run almost complete non-trivial tests (specifically, test_urlparse.py from CPython 3.3.3 distro, without Unicode tests).

Closing this, please report further issues against micropython-lib.

Fonts

Update docs

Update from adafruit main

Although the original motivation given for the workaround[1] is correct, nlr.o and nlrthumb.o are linked with a small enough distance that the problem does not occur, and the workaround isn't necessary. The distance between the b instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the ±2046 byte range addressable by an unconditional branch instruction in Thumb mode. The workaround induces a relocation in the text section (textrel), which isn't supported everywhere, notably not on musl-libc, where it causes a crash on start-up. With the workaround removed, micropython works on an ARMv5T Linux built with musl-libc. [1]: commit dd376a2 Author: Damien George <damien.p.george@gmail.com> Date: Fri Sep 1 15:25:29 2017 +1000 py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2). "b" on Thumb might not be long enough for the jump to nlr_push_tail so it must be done indirectly. [2]: Excerpt from objdump -d micropython: 000095c4 <nlr_push_tail>: 95c4: b510 push {r4, lr} 95c6: 0004 movs r4, r0 95c8: f02d fd42 bl 37050 <mp_thread_get_state> 95cc: 6943 ldr r3, [r0, micropython#20] 95ce: 6023 str r3, [r4, #0] 95d0: 6144 str r4, [r0, micropython#20] 95d2: 2000 movs r0, #0 95d4: bd10 pop {r4, pc} 000095d6 <nlr_pop>: 95d6: b510 push {r4, lr} 95d8: f02d fd3a bl 37050 <mp_thread_get_state> 95dc: 6943 ldr r3, [r0, micropython#20] 95de: 681b ldr r3, [r3, #0] 95e0: 6143 str r3, [r0, micropython#20] 95e2: bd10 pop {r4, pc} 000095e4 <nlr_push>: 95e4: 60c4 str r4, [r0, micropython#12] 95e6: 6105 str r5, [r0, micropython#16] 95e8: 6146 str r6, [r0, micropython#20] 95ea: 6187 str r7, [r0, micropython#24] 95ec: 4641 mov r1, r8 95ee: 61c1 str r1, [r0, micropython#28] 95f0: 4649 mov r1, r9 95f2: 6201 str r1, [r0, micropython#32] 95f4: 4651 mov r1, sl 95f6: 6241 str r1, [r0, micropython#36] @ 0x24 95f8: 4659 mov r1, fp 95fa: 6281 str r1, [r0, micropython#40] @ 0x28 95fc: 4669 mov r1, sp 95fe: 62c1 str r1, [r0, micropython#44] @ 0x2c 9600: 4671 mov r1, lr 9602: 6081 str r1, [r0, micropython#8] 9604: e7de b.n 95c4 <nlr_push_tail> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct, nlr.o and nlrthumb.o are linked with a small enough distance that the problem does not occur, and the workaround isn't necessary. The distance between the b instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the ±2046 byte range addressable by an unconditional branch instruction in Thumb mode. The workaround induces a relocation in the text section (textrel), which isn't supported everywhere, notably not on musl-libc, where it causes a crash on start-up. With the workaround removed, micropython works on an ARMv5T Linux system built with musl-libc. [1]: commit dd376a2 Author: Damien George <damien.p.george@gmail.com> Date: Fri Sep 1 15:25:29 2017 +1000 py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2). "b" on Thumb might not be long enough for the jump to nlr_push_tail so it must be done indirectly. [2]: Excerpt from objdump -d micropython: 000095c4 <nlr_push_tail>: 95c4: b510 push {r4, lr} 95c6: 0004 movs r4, r0 95c8: f02d fd42 bl 37050 <mp_thread_get_state> 95cc: 6943 ldr r3, [r0, micropython#20] 95ce: 6023 str r3, [r4, #0] 95d0: 6144 str r4, [r0, micropython#20] 95d2: 2000 movs r0, #0 95d4: bd10 pop {r4, pc} 000095d6 <nlr_pop>: 95d6: b510 push {r4, lr} 95d8: f02d fd3a bl 37050 <mp_thread_get_state> 95dc: 6943 ldr r3, [r0, micropython#20] 95de: 681b ldr r3, [r3, #0] 95e0: 6143 str r3, [r0, micropython#20] 95e2: bd10 pop {r4, pc} 000095e4 <nlr_push>: 95e4: 60c4 str r4, [r0, micropython#12] 95e6: 6105 str r5, [r0, micropython#16] 95e8: 6146 str r6, [r0, micropython#20] 95ea: 6187 str r7, [r0, micropython#24] 95ec: 4641 mov r1, r8 95ee: 61c1 str r1, [r0, micropython#28] 95f0: 4649 mov r1, r9 95f2: 6201 str r1, [r0, micropython#32] 95f4: 4651 mov r1, sl 95f6: 6241 str r1, [r0, micropython#36] @ 0x24 95f8: 4659 mov r1, fp 95fa: 6281 str r1, [r0, micropython#40] @ 0x28 95fc: 4669 mov r1, sp 95fe: 62c1 str r1, [r0, micropython#44] @ 0x2c 9600: 4671 mov r1, lr 9602: 6081 str r1, [r0, micropython#8] 9604: e7de b.n 95c4 <nlr_push_tail> Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct, nlr.o and nlrthumb.o are linked with a small enough distance that the problem does not occur, and the workaround isn't necessary. The distance between the b instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the ±2046 byte range addressable by an unconditional branch instruction in Thumb mode. The workaround induces a relocation in the text section (textrel), which isn't supported everywhere, notably not on musl-libc[3], where it causes a crash on start-up. With the workaround removed, micropython works on an ARMv5T Linux system built with musl-libc. [1]: commit dd376a2 Author: Damien George <damien.p.george@gmail.com> Date: Fri Sep 1 15:25:29 2017 +1000 py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2). "b" on Thumb might not be long enough for the jump to nlr_push_tail so it must be done indirectly. [2]: Excerpt from objdump -d micropython: 000095c4 <nlr_push_ta 8000 il>: 95c4: b510 push {r4, lr} 95c6: 0004 movs r4, r0 95c8: f02d fd42 bl 37050 <mp_thread_get_state> 95cc: 6943 ldr r3, [r0, micropython#20] 95ce: 6023 str r3, [r4, #0] 95d0: 6144 str r4, [r0, micropython#20] 95d2: 2000 movs r0, #0 95d4: bd10 pop {r4, pc} 000095d6 <nlr_pop>: 95d6: b510 push {r4, lr} 95d8: f02d fd3a bl 37050 <mp_thread_get_state> 95dc: 6943 ldr r3, [r0, micropython#20] 95de: 681b ldr r3, [r3, #0] 95e0: 6143 str r3, [r0, micropython#20] 95e2: bd10 pop {r4, pc} 000095e4 <nlr_push>: 95e4: 60c4 str r4, [r0, micropython#12] 95e6: 6105 str r5, [r0, micropython#16] 95e8: 6146 str r6, [r0, micropython#20] 95ea: 6187 str r7, [r0, micropython#24] 95ec: 4641 mov r1, r8 95ee: 61c1 str r1, [r0, micropython#28] 95f0: 4649 mov r1, r9 95f2: 6201 str r1, [r0, micropython#32] 95f4: 4651 mov r1, sl 95f6: 6241 str r1, [r0, micropython#36] @ 0x24 95f8: 4659 mov r1, fp 95fa: 6281 str r1, [r0, micropython#40] @ 0x28 95fc: 4669 mov r1, sp 95fe: 62c1 str r1, [r0, micropython#44] @ 0x2c 9600: 4671 mov r1, lr 9602: 6081 str r1, [r0, micropython#8] 9604: e7de b.n 95c4 <nlr_push_tail> [3]: https://www.openwall.com/lists/musl/2020/09/25/4 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct, nlr.o and nlrthumb.o are linked with a small enough distance that the problem does not occur, and the workaround isn't necessary. The distance between the b instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the ±2046 byte range addressable by an unconditional branch instruction in Thumb mode. The workaround induces a relocation in the text section (textrel), which isn't supported everywhere, notably not on musl-libc[3], where it causes a crash on start-up. With the workaround removed, micropython works on an ARMv5T Linux system built with musl-libc. This commit changes nlrthumb.c to use a direct jump by default, but leaves the long jump workaround as an option for those cases where it's actually needed. [1]: commit dd376a2 Author: Damien George <damien.p.george@gmail.com> Date: Fri Sep 1 15:25:29 2017 +1000 py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2). "b" on Thumb might not be long enough for the jump to nlr_push_tail so it must be done indirectly. [2]: Excerpt from objdump -d micropython: 000095c4 <nlr_push_tail>: 95c4: b510 push {r4, lr} 95c6: 0004 movs r4, r0 95c8: f02d fd42 bl 37050 <mp_thread_get_state> 95cc: 6943 ldr r3, [r0, micropython#20] 95ce: 6023 str r3, [r4, #0] 95d0: 6144 str r4, [r0, micropython#20] 95d2: 2000 movs r0, #0 95d4: bd10 pop {r4, pc} 000095d6 <nlr_pop>: 95d6: b510 push {r4, lr} 95d8: f02d fd3a bl 37050 <mp_thread_get_state> 95dc: 6943 ldr r3, [r0, micropython#20] 95de: 681b ldr r3, [r3, #0] 95e0: 6143 str r3, [r0, micropython#20] 95e2: bd10 pop {r4, pc} 000095e4 <nlr_push>: 95e4: 60c4 str r4, [r0, micropython#12] 95e6: 6105 str r5, [r0, micropython#16] 95e8: 6146 str r6, [r0, micropython#20] 95ea: 6187 str r7, [r0, micropython#24] 95ec: 4641 mov r1, r8 95ee: 61c1 str r1, [r0, micropython#28] 95f0: 4649 mov r1, r9 95f2: 6201 str r1, [r0, micropython#32] 95f4: 4651 mov r1, sl 95f6: 6241 str r1, [r0, micropython#36] @ 0x24 95f8: 4659 mov r1, fp 95fa: 6281 str r1, [r0, micropython#40] @ 0x28 95fc: 4669 mov r1, sp 95fe: 62c1 str r1, [r0, micropython#44] @ 0x2c 9600: 4671 mov r1, lr 9602: 6081 str r1, [r0, micropython#8] 9604: e7de b.n 95c4 <nlr_push_tail> [3]: https://www.openwall.com/lists/musl/2020/09/25/4 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct, nlr.o and nlrthumb.o are linked with a small enough distance that the problem does not occur, and the workaround isn't necessary. The distance between the b instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the ±2046 byte range addressable by an unconditional branch instruction in Thumb mode. The workaround induces a relocation in the text section (textrel), which isn't supported everywhere, notably not on musl-libc[3], where it causes a crash on start-up. With the workaround removed, micropython works on an ARMv5T Linux system built with musl-libc. This commit changes nlrthumb.c to use a direct jump by default, but leaves the long jump workaround as an option for those cases where it's actually needed. [1]: commit dd376a2 Author: Damien George <damien.p.george@gmail.com> Date: Fri Sep 1 15:25:29 2017 +1000 py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2). "b" on Thumb might not be long enough for the jump to nlr_push_tail so it must be done indirectly. [2]: Excerpt from objdump -d micropython: 000095c4 <nlr_push_tail>: 95c4: b510 push {r4, lr} 95c6: 0004 movs r4, r0 95c8: f02d fd42 bl 37050 <mp_thread_get_state> 95cc: 6943 ldr r3, [r0, micropython#20] 95ce: 6023 str r3, [r4, #0] 95d0: 6144 str r4, [r0, micropython#20] 6D47 95d2: 2000 movs r0, #0 95d4: bd10 pop {r4, pc} 000095d6 <nlr_pop>: 95d6: b510 push {r4, lr} 95d8: f02d fd3a bl 37050 <mp_thread_get_state> 95dc: 6943 ldr r3, [r0, micropython#20] 95de: 681b ldr r3, [r3, #0] 95e0: 6143 str r3, [r0, micropython#20] 95e2: bd10 pop {r4, pc} 000095e4 <nlr_push>: 95e4: 60c4 str r4, [r0, micropython#12] 95e6: 6105 str r5, [r0, micropython#16] 95e8: 6146 str r6, [r0, micropython#20] 95ea: 6187 str r7, [r0, micropython#24] 95ec: 4641 mov r1, r8 95ee: 61c1 str r1, [r0, micropython#28] 95f0: 4649 mov r1, r9 95f2: 6201 str r1, [r0, micropython#32] 95f4: 4651 mov r1, sl 95f6: 6241 str r1, [r0, micropython#36] @ 0x24 95f8: 4659 mov r1, fp 95fa: 6281 str r1, [r0, micropython#40] @ 0x28 95fc: 4669 mov r1, sp 95fe: 62c1 str r1, [r0, micropython#44] @ 0x2c 9600: 4671 mov r1, lr 9602: 6081 str r1, [r0, micropython#8] 9604: e7de b.n 95c4 <nlr_push_tail> [3]: https://www.openwall.com/lists/musl/2020/09/25/4 Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>

Although the original motivation given for the workaround[1] is correct, nlr.o and nlrthumb.o are linked with a small enough distance that the problem does not occur, and the workaround isn't necessary. The distance between the b instruction and its target (nlr_push_tail) is just 64 bytes[2], well within the ±2046 byte range addressable by an unconditional branch instruction in Thumb mode. The workaround induces a relocation in the text section (textrel), which isn't supported everywhere, notably not on musl-libc[3], where it causes a crash on start-up. With the workaround removed, micropython works on an ARMv5T Linux system built with musl-libc. This commit changes nlrthumb.c to use a direct jump by default, but leaves the long jump workaround as an option for those cases where it's actually needed. [1]: commit dd376a2 Author: Damien George <damien.p.george@gmail.com> Date: Fri Sep 1 15:25:29 2017 +1000 py/nlrthumb: Get working again on standard Thumb arch (ie not Thumb2). "b" on Thumb might not be long enough for the jump to nlr_push_tail so it must be done indirectly. [2]: Excerpt from objdump -d micropython: 000095c4 <nlr_push_tail>: 95c4: b510 push {r4, lr} 95c6: 0004 movs r4, r0 95c8: f02d fd42 bl 37050 <mp_thread_get_state> 95cc: 6943 ldr r3, [r0, micropython#20] 95ce: 6023 str r3, [r4, #0] 95d0: 6144 str r4, [r0, micropython#20] 95d2: 2000 movs r0, #0 95d4: bd10 pop {r4, pc} 000095d6 <nlr_pop>: 95d6: b510 push {r4, lr} 95d8: f02d fd3a bl 37050 <mp_thread_get_state> 95dc: 6943 ldr r3, [r0, micropython#20] 95de: 681b ldr r3, [r3, #0] 95e0: 6143 str r3, [r0, micropython#20] 95e2: bd10 pop {r4, pc} 000095e4 <nlr_push>: 95e4: 60c4 str r4, [r0, micropython#12] 95e6: 6105 str r5, [r0, micropython#16] 95e8: 6146 str r6, [r0, micropython#20] 95ea: 6187 str r7, [r0, micropython#24] 95ec: 4641 mov r1, r8 95ee: 61c1 str r1, [r0, micropython#28] 95f0: 4649 mov r1, r9 95f2: 6201 str r1, [r0, micropython#32] 95f4: 4651 mov r1, sl 95f6: 6241 str r1, [r0, micropython#36] @ 0x24 95f8: 4659 mov r1, fp 95fa: 6281 str r1, [r0, micropython#40] @ 0x28 95fc: 4669 mov r1, sp 95fe: 62c1 str r1, [r0, micropython#44] @ 0x2c 9600: 4671 mov r1, lr 9602: 6081 str r1, [r0, micropython#8] 9604: e7de b.n 95c4 <nlr_push_tail> [3]: https://www.openwall.com/lists/musl/2020/09/25/4 Signed-off-by: J. Neuschäfer <j.ne@posteo.net>

pfalcon closed this as completed May 12, 2014

drrk pushed a commit to drrk/micropython that referenced this issue Jan 22, 2017

Merge pull request micropython#44 from emfcamp/fonts

4aab201

Fonts

WeActStudio pushed a commit to WeActStudio/micropython that referenced this issue Feb 14, 2021

Merge pull request micropython#44 from kwagyeman/openmv

be77733

Update docs

tannewt pushed a commit to tannewt/circuitpython that referenced this issue Mar 16, 2021

Merge pull request micropython#44 from adafruit/main

4b56717

Update from adafruit main

sidorenkom pushed a commit to sidorenkom/micropython that referenced this issue Oct 5, 2021

Add CI build for rp2 port (micropython#44)

a59bd67

jgpeiro mentioned this issue Jan 7, 2022

Add rp2 build instructions to the readme file #8146

Closed

neuschaefer mentioned this issue Apr 27, 2023

py/nlrthumb: Make non-Thumb2 workaround opt-in. #11353

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Port PyUnit/UnitTest module #44

Port PyUnit/UnitTest module #44

Port PyUnit/UnitTest module #44

Port PyUnit/UnitTest module #44

Comments