Skip to content
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

added micropython versions of libs examples #2762

Merged
merged 3 commits into from Nov 25, 2021
Merged

added micropython versions of libs examples #2762

merged 3 commits into from Nov 25, 2021

Conversation

uraich
Copy link
Contributor

@uraich uraich commented Nov 4, 2021

Description of the feature or fix

A clear and concise description of what the bug or new feature is.

Checkpoints

  • Follow the styling guide
  • Update CHANGELOG.md
  • Update the documentation
    Added MicroPython equivalents of all examples in examples/libs

@uraich
Copy link
Contributor Author

uraich commented Nov 4, 2021

The examples are supposed and do work on the unix port only.
I have no idea why I get the error:
ERROR! AttributeError: 'module' object has no attribute 'rlottie_create_from_file'
The example works perfectly on my lv_micropython unix port.

@embeddedt
Copy link
Member

It's probably because the CI runner doesn't have Rlottie and FreeType installed. FreeType can be added easily using apt, but Rlottie is more complex to install because it needs to be cloned and built.

I've already written a script to do this for Emscripten, and it'd be ideal to not have the same logic in two places. I'll think about this over the next day or so and see if I can come up with a better way of handling this.

Rlottie also doesn't have versioning from what I could tell, so it's important for repeatability that we check out an exact commit.

@uraich
Copy link
Contributor Author

uraich commented Nov 5, 2021

@embeddedt : On my Ubuntu system, I installed rlottie with apt. There is a package named librlottie-dev, which did the trick for me.

@embeddedt
Copy link
Member

Thanks! I think that will work. Unfortunately, the action we use for the STM32 and Raspberry Pi CI is very flaky nowadays, so they keep failing and blocking the Unix check from actually running to completion. Working on that...

Copy link
Member

@embeddedt embeddedt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@amirgon libfreetype-dev and librlottie-dev need to be added to lv_micropython's CI as well, right?

@@ -8,6 +8,7 @@ jobs:
build:
name: Build ${{ matrix.port }} port
runs-on: ubuntu-latest
continue-on-error: true
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why continue on error?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That gcc-arm-none-eabi action is failing sporadically again on stm32/rp2 ports. This allows the other ports' checks to keep going instead of being cancelled by the failure.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see.
Is it possible to set this behavior specifically for these ports?

Because the unix port runs many tests and if one of them fails, I think it's easier to check the bottom of the log instead of trying to search in the middle.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that this changes nothing about how steps (e.g. run tests) work within a job. This just affects whether one of the overall jobs (e.g. the Unix port) cancels the other jobs (the other ports) if it happens to fail.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is how it works - then that's good for me.

@amirgon
Copy link
Contributor

amirgon commented Nov 5, 2021

libfreetype-dev and librlottie-dev need to be added to lv_micropython's CI as well, right?

Yes that would be a good idea.

@amirgon
Copy link
Contributor

amirgon commented Nov 6, 2021

libfreetype-dev and librlottie-dev need to be added to lv_micropython's CI as well, right?

Yes that would be a good idea.

Done although there is still a related issue I can't understand

@uraich
Copy link
Contributor Author

uraich commented Nov 13, 2021

@amirgon: I am trying to build the esp32 system again, but I have issues:
1116/1504] Generating ../../lv_espidf.c
FAILED: lv_espidf.c
cd /opt/ucc/micros/esp32/lv_micropython/ports/esp32/build-GENERIC_SPIRAM/esp-idf/main && /home/uli/pythonEnvironments/espidf/bin/python3 /opt/ucc/micros/esp32/lv_micropython/lib/lv_bindings/gen/gen_mpy.py -M espidf -MD /opt/ucc/micros/esp32/lv_micropython/ports/esp32/build-GENERIC_SPIRAM/lv_espidf.c.json -E /opt/ucc/micros/esp32/lv_micropython/ports/esp32/build-GENERIC_SPIRAM/lv_espidf.c.pp.filtered /opt/ucc/micros/esp32/lv_micropython/lib/lv_bindings/driver/esp32/espidf.h > /opt/ucc/micros/esp32/lv_micropython/ports/esp32/build-GENERIC_SPIRAM/lv_espidf.c || ( rm -f /opt/ucc/micros/esp32/lv_micropython/ports/esp32/build-GENERIC_SPIRAM/lv_espidf.c && /bin/false )
Traceback (most recent call last):
File "/opt/ucc/micros/esp32/lv_micropython/lib/lv_bindings/gen/gen_mpy.py", line 2666, in
try_generate_structs_from_first_argument()
File "/opt/ucc/micros/esp32/lv_micropython/lib/lv_bindings/gen/gen_mpy.py", line 2601, in try_generate_structs_from_first_argument
try_generate_type(args[0].type)
File "/opt/ucc/micros/esp32/lv_micropython/lib/lv_bindings/gen/gen_mpy.py", line 2058, in try_generate_type
try_generate_struct(type, structs[type]) if type in structs else None
File "/opt/ucc/micros/esp32/lv_micropython/lib/lv_bindings/gen/gen_mpy.py", line 1760, in try_generate_struct
converted = try_generate_type(decl.type)
File "/opt/ucc/micros/esp32/lv_micropython/lib/lv_bindings/gen/gen_mpy.py", line 2039, in try_generate_type
return try_generate_type(type_ast.type)
File "/opt/ucc/micros/esp32/lv_micropython/lib/lv_bindings/gen/gen_mpy.py", line 2095, in try_generate_type
if try_generate_struct(type, structs[type]):
File "/opt/ucc/micros/esp32/lv_micropython/lib/lv_bindings/gen/gen_mpy.py", line 1770, in try_generate_struct
try_generate_struct(type_name, decl.type.type)
File "/opt/ucc/micros/esp32/lv_micropython/lib/lv_bindings/gen/gen_mpy.py", line 1751, in try_generate_struct
return try_generate_type(structs[struct.name])
KeyError: None

any idea why?

Sorry, I forgot! It is the problem that it only runs with esp-idf v4.2!

@amirgon
Copy link
Contributor

amirgon commented Nov 13, 2021

any idea why?

Sorry, I forgot! It is the problem that it only runs with esp-idf v4.2!

Right. Currently v4. 2 is supported.
In the future I'm planning to add support to v4.4 (lvgl/lv_binding_micropython#192) but currently that wasn't officially released yet by Espressif.

@kisvegabor
Copy link
Member

Can we merge this?

@amirgon
Copy link
Contributor

amirgon commented Nov 24, 2021

Can we merge this?

I think you can.

@embeddedt embeddedt merged commit cd197a8 into lvgl:master Nov 25, 2021
@embeddedt
Copy link
Member

Looks good to me as well, so I merged it. It shouldn't be a breaking change in any case; we don't depend on the MicroPython examples for anything except CI tests.

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

Successfully merging this pull request may close these issues.

None yet

4 participants