templates/packer: configure pulp creds on startup

Configure pulp credentials on worker startup.

hi, with this pr, do we need to change/update test cases in https://github.com/osbuild/osbuild-composer/blob/main/test/cases/ostree-pulp.sh ?
And one more question, I can see the pulp server, username and password in this pr, so there will be an embedded pulp server here? because from my understanding, customer is supposed to setup their own pulp server environment.

hi, with this pr, do we need to change/update test cases in https://github.com/osbuild/osbuild-composer/blob/main/test/cases/ostree-pulp.sh ? And one more question, I can see the pulp server, username and password in this pr, so there will be an embedded pulp server here? because from my understanding, customer is supposed to setup their own pulp server environment.

This PR is so we can eventually use pulp in the service, at the moment there is a pulp instance in staging. This kind of goes together with the #3744 pr. As for users who want to use this on-prem, they will have to configure a pulp server themselves.
Regarding the test, I'm not sure if we run any tests against stage, maybe @croissanne can correct me?


Llava Models

Does the Llava part work ?
https://github.com/intel/intel-extension-for-transformers/tree/main/intel_extension_for_transformers/transformers/modeling/llava_models
If so are they optimized for Intel Device and are there any examples ?
Thanks for building this library.  I have seen the token generation performance to be very good compared to OpenVino.
Great work !
Thanks

Thanks for your usage!!!
Unfortunately, we are not support LLaVA for now.
But we may consider to support it in future, please stay tune.
Regrads,
Bo

Someone tried low-bits for llava: https://arxiv.org/pdf/2306.00978.pdf .
We may try quantiation.

Thanks @kevinintel

Hi, support for quantization of multimodal models is currently planned, and any updates will be communicated here.

we can optimize llava in https://github.com/intel/neural-compressor/pull/1797
will add examples


Trouble installing open_pdks

Hi, I tried to install open_pdk in my ubuntu system. While running make command I got the following error.

Here is the log file
sky130A_make.log
sky130B_make.log

@Blue-moon-pix don't know if this will make difference, but looks like your using an older version of magic.
Magic 8.3 revision 50 - Compiled on Friday 19 January 2024 04:15:11 PM IST.

The current version is 8.3.460. Can you install the most recent version?

I installed recent version of magic. when I ran the make command my terminal stuck like this. I tried 3 times but still same

@Blue-moon-pix Do you need all the standard cell libraries?
volare is a quick way to download pre-built libraries if you don't need the extra hs or hdll etc libraries.

@Blue-moon-pix :  I think likely the "stuck" state is still processing---Unless you have a pretty high-end, multi-core machine, the process of compiling the PDK can take a long time;  if you have low memory overhead and it causes a lot of swapping, it might be a very long time.  Make sure you give it at least an hour to finish, even if it's not paging.  Or, you can take Mitch's advice and use volare (https://github.com/efabless/volare), which installs pre-compiled PDKs.

Got it. Thanks for the advice :)

Can i install one library at a time?

@Blue-moon-pix :  Yes, although it's not really set up to do that conveniently.  If you run configure --help you will get a list of all the libraries open_pdks knows about.  Some are enabled by default and some are disabled by default.  If you want to cut down the number of libraries installed, you will need to run configure with a bunch of disables for the libraries that you don't want, like --disable-sc-ms-sky130 (note that there are libraries supported for both sky130 and gf180mcu;  only libraries for the PDK that has itself been enabled will be installed;  so if you use --enable-sky130-pdk, for example, then you don't need to worry about disabling all of the gf180 libraries because none of them is going to be installed anyway.

@Blue-moon-pix :  Yes, although it's not really set up to do that conveniently.  If you run configure --help you will get a list of all the libraries open_pdks knows about.  Some are enabled by default and some are disabled by default.  If you want to cut down the number of libraries installed, you will need to run configure with a bunch of disables for the libraries that you don't want, like --disable-sc-ms-sky130 (note that there are libraries supported for both sky130 and gf180mcu;  only libraries for the PDK that has itself been enabled will be installed;  so if you use --enable-sky130-pdk, for example, then you don't need to worry about disabling all of the gf180 libraries because none of them is going to be installed anyway.

I have one doubt though, if I run 'configure' with disabling low power and low speed and run 'make' to install it and again I run configure with disabling other libraries and enable low power and low speed then other libraries got deleted or its unchanged?
Ps: I have only 2 gigs of ram for my Ubuntu VM

@Blue-moon-pix :  Each library is entirely self-contained, and if you generate libraries one at a time, make install will add them to whatever is already there and will not delete any libraries that were previously installed.

@Blue-moon-pix :  Each library is entirely self-contained, and if you generate libraries one at a time, make install will add them to whatever is already there and will not delete any libraries that were previously installed.

Alright will try that


cargo test fails

Not all examples are defined in the Cargo.toml, such as examples/salvo.rs, so if cargo test is run without --all-features the tests will fail with a spam of failed to resolve errors as the salvo feature/other features are not enabled

Should be fixed by #202

I've merged the changes thanks @DusterTheFirst


Update to 1.4.9

Checklist

[ ] Used a personal fork of the feedstock to propose changes
[ ] Bumped the build number (if the version is unchanged)
[ ] Reset the build number to 0 (if the version changed)
[ ] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[ ] Ensured the license file is being packaged.

Waiting for https://github.com/conda-forge/potentials-feedstock/pull/30

Close this in favor of https://github.com/conda-forge/atomman-feedstock/pull/34


Fixed #6105: Add mntent.h include path

@3eka had a few minutes of time, this should fix your build.

does not work, the system is lacking getmntent function.


Add URL as property on query object

Would be good to be able to access the url used to generate the query.  Pull request incoming.

Not sure whether it should be merged to official master branch


Build POC for .NET and .NET Core extension

Based on the research performed in #46, build a proof of concept using IronPython to interact with secureli. This will require some collaboration with @calebtonn on what the user experience might look like.
Acceptance Criteria

A POC has been built that proves viability of the approach for using a .Net extension for Visual Studio
Additional backlog items have been added to build this in a production viable way

I would recommend prioritizing extensions for other IDEs (probably VS Code & JetBrains products) before this one.


views: multiple parameters fix for default view

Fixes issue in which the default view function did not support
multiple URL parameters.

Signed-off-by: Lars Holm Nielsen<EMAIL_ADDRESS>

Coverage remained the same at 100.0% when pulling 2d26886c8c6e236263be7422d6ea0d399fb44f7c on lnielsen:defaultviewfunc into 556cf22e75ac588178331ae61a436ef2dba1aeb4 on inveniosoftware:master.

Coverage remained the same at 100.0% when pulling 381acb86bc31434dda7ecfe00c7c49fe140d8c71 on lnielsen:defaultviewfunc into 556cf22e75ac588178331ae61a436ef2dba1aeb4 on inveniosoftware:master.


Dependencies not automatically install in docker image while debugging locally

Thanks for this useful repo.
During local debugging by running the following command:

sam local invoke HelloWorldFunction --debug-port 5858

I always get an error message saying that "axios" can not be found. This seems to be an issue of the dependencies in package.json file does not get installed inside the docker image.
Is it possible to change some config in template.yml file to make it happen? Thanks
Note:
I understand that if I copy the dependencies to "dist" folder it works. I think if I could tell "sam" to reference the node_modules folder inside template.yml file it would be more efficient.

Closing this due to a lack of activity. Feel free to reopen or to comment on this issue if you still have any unanswered questions :)


Failed to respond messages

The url is http://people.com.
And it seems like the site is working fine.
2017-01-18 14:18:21,136 WARN [Crawler 1] e.u.i.c.c.WebCrawler [:412] Unhandled exception while fetching http://people.com/: people.com:80 failed to respond
2017-01-18 14:18:21,140 INFO [Crawler 1] e.u.i.c.c.WebCrawler [:357] Stacktrace: org.apache.http.NoHttpResponseException: people.com:80 failed to respond

Team may i know which is the latest version 4.1 or 4.2. Web site have mentioned 4.1 as latest but 4.2 seems listed above 4.1 hyper link. Link for reference [https://github.com/yasserg/crawler4j/releases] . In Maven listing , 4.2 listed at top [http://search.maven.org/#search|gav|1|g%3A"edu.uci.ics" AND a%3A"crawler4j"]. Please help me in choosing stable version.

The latest versione is 4.2. I suspect @yasserg has uploaded 4.2 without marking release on github.

@s17t  Thank you !

@pekerayhan there a number of sites that will block requests from "unknown" user-agents.

@JCotton1123  Thanks for the response. I have been setting  the user agent as "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.19 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/525.19"


Warnings/mechanisms to avoid losing data

At the Schwartz lab, we sometimes make mistakes.  In Symphony 1, a large red text indicator made it clear when epochs were not being recorded. In Symphony 2, this is much more subtle, with the only sign being "viewing" rather than "recording" at the bottom.
To ameliorate this issue, it would be good to have some warning, or perhaps a fail-safe mechanism.  Something like the red text, displayed when a data file is open but not being written to, would be a good place to start. Or, perhaps, a confirmation step required for viewing-only when a file is open. Alternatively, all epochs (from both view and record mode) could be saved automatically, then those marked as "view mode" would be not stored with the saved recording h5, unless they were mode-switched beforehand.

What about a popup window that warns the user they're attempting to view with a data file open? Maybe with a checkbox to say "Don't warn me again until the next experiment".

Ah, that was one of the suggestions I had in mind but didn't type; yes that would be good.


Initialize Browse with default filters

last two months
<= 10 percent of clouds

Also add 2017 to list year filters

Closed by #976


[Bug]: Select and MultiSelect widgets clear user choices when the filtered options do not contain these choices

Is there an existing issue for this?

[X] I have searched the existing issues

Description
For Select and MultiSelect widgets with server-side filtering enabled, when a user picks one or more options and then filters the remaining options using text not contained in the previously chosen ones, those choices are cleared by the widget.
As a user, I expect my selected options to remain even if they are not in the filtered available options.
Steps To Reproduce

In the linked sample app, choose a name from the list.
Type a random string.
The previously selected name will disappear unless it matches the filter text.

Public Sample App
https://app.appsmith.com/app/select-and-multiselect-bug/page1-65677457dceb3203679b73fc
Environment
Production
Issue video log
No response
Version
Cloud v1.9.49-SNAPSHOT

@hweissig I think you didn't deploy your app. Could you deploy it and mark it as forkable?

Oops… done.

@hweissig thanks! I'm able to see it now. Really sorry you faced this issue. We'll have someone from the team look into this.

Upon rechecking, even if the options are present in the filtered list, they still get removed from selection!

Hi! Just checking if there has been progress on this. We've tried some frontend workarounds but have not been able to fix it that way, unfortunately.

Hey @hweissig , We're picking this up early next week.

That's great news, @sbalaji1192 !

@hweissig  We debugged and found the issue. Working on a solution and will tag a PR here soon.


WIP: sketch out source code architecture for apidoc

** Not ready for merge **

initial commit: add benchpark version -- Benchpark driver needs to be python to import modules. Spack gets around this by having a top-level bash script that calls main.py which has the driver code.

Think we converged on keeping the benchpark help docs page updated (need to update the condition for when docs are re-rendered) instead of adding API docs (too many tokens for RTD to search on). This PR can be closed.


This is pure awesomeness :)

https://github.com/RyanCCollins/scalable-react-boilerplate/blob/master/app/src/store.js#L79
Thank you for your work. There are hundreds of react boilerplates. I saw most of them. But this is the only one that really showed me how things are really done so that I could build my own react, redux, webpack2, graphql, apollo boilerplate. With hot module replacement. With f****** reducer hot replacement.   I made countess Issues begging people to fix their boilerplates so that I could see how is reducer HMR really done.
You are awesome. :)

Hey @developer239!!
Man this is the nicest Issue I have ever seen.  Thank you so much for your kind words.
I agree with everything that you said.  I built this, along with some help of course, because of the fact that there was no boilerplate out there that completely met my needs and the needs of my friends and coworkers.  This is the result of over a years worth of research and iteration.  I might be biased, but this is also my favorite boilerplate and I use it for literally all of my projects.
Anyways, thank you again for the kind words.  I would love to hear about anything you build with it and I would also love for you to contribute to it if you find that there are improvements to be made.
Cheers!

Agreed. Nice work!


Multiwallet tweaks

Cleaning up multiwallet and adding some minor functionality

Merging as there's a lot of little stuff in here, happy to make changes


Sudo is not necessary for Travis

The build failures were actually caused by the git config issue that was fixed later in #181.

:+1:


add_basemap: keep original axis limits of figure

Opening this for discussion: in my original implementation (http://geopandas.readthedocs.io/en/latest/gallery/plotting_basemap_background.html#contextily-helper-function) I reset the axis limits to the original ones when the ax is passed to the function.
One reason to do this: the extent of the figure does not depend on the zoom level (on how many tiles are merged).

Coverage increased (+0.03%) to 93.548% when pulling 899b738898099ff63d40a7de81d3cda35798f5fd on jorisvandenbossche:add_basemap-restore-axis into 1f748d8b2f1228c49d548099ef283cb460dd55f1 on darribas:master.

Nice! so, just to make sure I get it correctly, this PR will make sure the extent of the plot will stay that of the original plot, not that of the pulled down full image, right?

(will add a test if you approve the change)

Yes, I think this makes sense. Quick question, would this also apply to the case where url is a local file?

Updated the PR to fix merge conflicts.

Yes, I think this makes sense. Quick question, would this also apply to the case where url is a local file?

For now, I didn't make any distinction between both.
And I also updated the test

Cool. One more thing, could you please add the option of reset_extent as mentioned in #45? I think you're right it makes more sense to set the default to True, but it I think in some contexts (particularly when url points to a local file), the user might be interested in letting the extent be reset by the addition.

@jorisvandenbossche I've cleaned conflicts in one of the tests with current master and added the option to reset the extent (as opposed of always doing it) into a PR to your branch. If you merge that one, I'm happy to merge this too into master.

Whoops, looks like this introduces errors on the tests now...
https://travis-ci.org/darribas/contextily/jobs/522345969
These are in addition to the 3.5 issue and come up in 3.6. Would you mind having a look into it @jorisvandenbossche?


::: Copy saved to /tmp/debug.txt
:::

Issue
Creating new user with both pivpn add or pivpn add nopass succeeds but if I create a profile with password the generated .ovpn file when imported to OpenVPN client doest not connect and returns error saying: Core exception: connection error: PEM_PASSWORD_FAILED: PolarSSL error parsing config private key : PK - Private key password can't be empty.
It however works and connects fine when profile is generated without password. Looks like the password entered for pivpn add is ignored and private key for profile is created with empty password.

That's Odd!! even yesterday installed PiVPN on a couple of times on a VPS and it worked perfectly! =S
don't even know what to think of this! =S can be the case of some special character you are entering the cause of the issue? try with a simple password like 12345 just for testing purposes ...

I tried even simple passwords like 12345678 or testtest and none have worked. I also tried to change private key encryption as described here or here and nothing works. I can only connect to the server if profile is created using pivpn add nopass which does not require any password (poor security).

that's gotta be a local issue on your side....
Just tested 5++ new pivpn installs today and none gave me that kind of issue!
Wondering how can we track such thing!

No issues here, too, I have installed PiVPN on a fresh Stretch install and the keys generated just fine.
Is it possible to attach one of the faulty .ovpn files? (just be sure to edit out any sensitive info, like the server name and half or more of the certificate/keys where present)

Closing issue, assuming issue resolved.
@LKay any further questions post here .. I will reopen if needed!

Hello
I am experiencing exact same issue. This is a brand new Raspberry Pi3 with new installation of PiVPN (this is my first time setting this up).
Anyone found any solutions or know how or why this happens?
Best regards

Here are the client error:
CLIENT_EXCEPTION : connect error: PEM_PASSWORD_FAIL: mbed TLS: error parsing config private key : PK - Private key password can't be empty [FATAL-ERR] FATAL:CLIENT_EXCEPTION: connect error: PEM_PASSWORD_FAIL: mbed TLS: error parsing config private key : PK - Private key password can't be empty

After wasting almost an entire day I found the solution/work around in case anyone is stuck with this. The issue is not with the PiVPN, but with the OpenVPN client. Since this is my first time ever using OpenVPN I downloaded "OpenVPN Connect" as client, and this client does not ask for password when connecting.
Downloaded and installed full OpenVPN client (including OpenVPN GUI) and it must be "Run as Administrator" and it asks for password and connects without any issues.

Thanks @gorbehnare ! I also downloaded open VPN connect instead of the openVPN client.

Thank you @gorbehnare same issue here!

had the same issue.  updated to openvpn connect ver 3 and it worked.

same issue


Update Vite and Vite plugins in app-tos and app-risk packages

next-env files updated when project test ran

Summary by CodeRabbit
Release Notes

Documentation

Updated TypeScript configuration references in the next-env.d.ts files for improved guidance.

Dependency Updates

Upgraded various dependencies across multiple packages, including vite, glob, and vite-plugin-dts, to enhance performance and compatibility.
Replaced @vitejs/plugin-react with @vitejs/plugin-react-swc in app-risk and app-tos for improved build speed.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 73.24%. Comparing base (99e8d9e) to head (8d13b0e).

:exclamation:  There is a different number of reports uploaded between BASE (99e8d9e) and HEAD (8d13b0e). Click for more details.
HEAD has 1 upload less than BASE

Flag
BASE (99e8d9e)
HEAD (8d13b0e)

2
1

Additional details and impacted files
@@             Coverage Diff             @@
##              dev     #506       +/-   ##
===========================================
- Coverage   85.03%   73.24%   -11.79%
===========================================
  Files         291      129      -162
  Lines        2967     1357     -1610
  Branches      178       78      -100
===========================================
- Hits         2523      994     -1529
+ Misses        444      363       -81

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Upgrade Spring Boot to 3.0

With Spring Boot 3.0 out of the door (https://spring.io/blog/2022/11/24/spring-boot-3-0-goes-ga), we should update the templates to support this version.
But I was wondering if we can have spring-boot2 and spring-boot3 support in the templates?
This brings a lot of complications, but because it's a new major version, it might be worth the hassle.

/good-first-issue

I started looking at this and there are a few things to consider. Boot 3.0 requires Java 17, so it is a step up from the current requirement of Java 11. To build the native images you need to provide both the build env var BP_NATIVE_IMAGE and set a Maven profile in a customer maven build command using BP_MAVEN_BUILD_ARGUMENTS plus set BP_JVM_VERSION to "17", so quite q few things to test and verify. Adding the issues with buildpacks on M1 Macs I think it is safer to bump the Boot version to the lates 2.7.x for now. I created this issue for now: https://github.com/knative/func/issues/1501

This is more urgent now that repo.spring.io/release will require authentication after Jan 26. See - https://spring.io/blog/2022/12/14/notice-of-permissions-changes-to-repo-spring-io-january-2023


Bug in P/B/H trigo calculator

Describe the bug

A clear and concise description of what the bug is.
If all 3 parameters (base, height and hypotenuse) are entered together which don't follow Pythagoras theorem then too it shows the values of trigonometric ratio instead of the warning such right angle triangle is not possible.

Possible solution

Describe the solution you thought of.
We should consider the condition that only 2 parameters are entered or all 3 follow Pythagoras theorem.

Feel free to ask your doubts, if any
Deadline 25 March,2021 (11:59 PM IST)


Adding iterative dfs python solution for tree traversal

This is a python solution for iterative dfs traversal of a tree.

What a great code :smile: !
Thank you for contributing! :rocket:


Elemental-cli to unify UX

Given the several components involved (and those that will come in the future), it is straightforward to create a single cli that embeds the needed parts from all the involved pieces:

luet build could be easily imported as standalone module and created a separate cli command with the specific defaults set for our use-cases. E.g. elemental build
luet utils unpack can be imported / replaced by elemental pull. Given that derivatives will have to push their final image to a :latest tag for rolling updates, loosing the upgrade channels capabilities. ( see https://github.com/rancher/wharfie for a possible replacement )
yip can be used already as a standalone module and replaced by a elemental cloudinit
Image verification (#107 outcome) by a elemental verify
#56  can become directly elemental build-iso and replace the current luet extension, which is just a bash script. This means we could also drop yq and jq from the dependencies
cos-setup can be an hypotetical  elemental run-stage
cos-features can become elemental features enable/disable/list
Image builder scripts (arm, raw images, etc) should be part of the CLI. E.g. elemental build-raw ...

This have the advantage that we can then tag in a unique piece the moving pieces and decide when to pick new versions of our internal dependencies.
Besides, we can have one repository containing the CLI and package specs. The package specs can be embedded assets into the binary so they are carried over as part of the binary release. Along with the binaries required by derivatives developers when building a Dockerfile. In this way we have one portable binary which can be both used to rebuild the assets, but also to place them during build in an immutable (and reproducible) way.
Action Items
To have a replacement for the current feature set, we need:

[x] #881

Building Images, Packages, Derivatives:
The build part of elemental, should allow us to get rid of the makefiles target, CI specific code to build packages, image building scripts, and luet as a binary dependency.

[x] #1217
[x] #1227
[ ] elemental build --packages:  re-use luet build code as library to build packages, possibly embedding https://github.com/rancher-sandbox/cOS-toolkit/blob/master/.github/build.go to build package definition from embedded or remote assets
[ ] elemental install-packages: A command that embeds or replaces luet install so that can be used inside Dockerfiles while creating derivatives. This ideally can take optional arguments as packages, but should provide a out of the box working experience covering minimal needs

Cloud-init, user-features:

[x] #942
[x] #987
[ ] elemental features {enable,disable,list} $feature: port current cos-features

Core features:

[x] #997
[x] #905
[x] #941
[x] #1049

Plugins:

[ ] elemental-plugin-cosign: reuse/port cosign plugin as library
[ ] elemental-plugin-mtree: reuse/port mtree plugin as library

Nice to have:

[ ] elemental new: Create skeleton Dockerfile for a derivative (with customizable arch, flavor, etc)
[x] #1305

dependent issues

#155 (yq)
#157 (yq)
#174 (cloud images)
#182 (image verification plugin)
https://github.com/rancher-sandbox/cOS-toolkit/pull/312
#449

@davidcassany @kkaempf I think we should close this. Do we expect to implement the elemental build and install-packages command into elemental any time?
I mean, we dont seem to use them or need them anywhere really as to make them a needed feature, cosign is already in IIRC, mtree is kind of not used for now anywhere, and the new command was already implemented.

Agreed.


Support Request: Honeywell T10 & Room Sensors Show Wrong Temp & Target Temp

Describe Your Problem
My thermostat & room sensors have been showing 75F target temp and 68F current temp for months now. I completely removed and reset the plugin today with new API account, and it's still broken. I'm fairly technical so happy to provide any more details as needed!
Relevant log output
[7/18/2024, 6:55:27 AM] [Resideo] Thermostat: Master Bedroom failed to refreshStatus, Too Many Requests
[7/18/2024, 6:55:27 AM] [Resideo] Thermostat: Office failed to refreshStatus, Too Many Requests
[7/18/2024, 6:57:27 AM] [Resideo] Thermostat: Thermostat failed to refreshStatus, Too Many Requests
[7/18/2024, 6:57:27 AM] [Resideo] Thermostat: Living Room failed to refreshStatus, Too Many Requests
[7/18/2024, 6:57:27 AM] [Resideo] Thermostat: Kitchen failed to refreshStatus, Too Many Requests
[7/18/2024, 6:57:27 AM] [Resideo] Thermostat: Master Bedroom failed to refreshStatus, Too Many Requests
[7/18/2024, 6:57:27 AM] [Resideo] Thermostat: Office failed to refreshStatus, Too Many Requests
[7/18/2024, 6:59:27 AM] [Resideo] Thermostat: Living Room failed to refreshStatus, Too Many Requests
[7/18/2024, 6:59:27 AM] [Resideo] Thermostat: Thermostat failed to refreshStatus, Too Many Requests
[7/18/2024, 6:59:27 AM] [Resideo] Thermostat: Kitchen failed to refreshStatus, Too Many Requests
[7/18/2024, 6:59:27 AM] [Resideo] Thermostat: Master Bedroom failed to refreshStatus, Too Many Requests
[7/18/2024, 6:59:27 AM] [Resideo] Thermostat: Kitchen failed to refreshStatus, Too Many Requests
[7/18/2024, 6:59:27 AM] [Resideo] Thermostat: Office failed to refreshStatus, Too Many Requests
[7/18/2024, 6:59:27 AM] [Resideo] Thermostat: Master Bedroom failed to refreshStatus, Too Many Requests
[7/18/2024, 6:59:27 AM] [Resideo] Thermostat: Office failed to refreshStatus, Too Many Requests
[7/18/2024, 7:51:32 AM] [Resideo] Thermostat: Kitchen failed to refreshStatus,
[7/18/2024, 7:57:27 AM] [Resideo] Thermostat: Thermostat failed to refreshStatus, Too Many Requests
[7/18/2024, 7:57:27 AM] [Resideo] Thermostat: Living Room failed to refreshStatus, Too Many Requests
[7/18/2024, 7:57:27 AM] [Resideo] Thermostat: Master Bedroom failed to refreshStatus, Too Many Requests
[7/18/2024, 7:57:27 AM] [Resideo] Thermostat: Office failed to refreshStatus, Too Many Requests
[7/18/2024, 7:57:27 AM] [Resideo] Thermostat: Master Bedroom failed to refreshStatus, Too Many Requests
[7/18/2024, 7:59:27 AM] [Resideo] Thermostat: Living Room failed to refreshStatus, Too Many Requests
[7/18/2024, 7:59:27 AM] [Resideo] Thermostat: Thermostat failed to refreshStatus, Too Many Requests
[7/18/2024, 7:59:27 AM] [Resideo] Thermostat: Kitchen failed to refreshStatus, Too Many Requests
[7/18/2024, 7:59:27 AM] [Resideo] Thermostat: Living Room failed to refreshStatus, Too Many Requests
[7/18/2024, 7:59:27 AM] [Resideo] Thermostat: Master Bedroom failed to refreshStatus, Too Many Requests
[7/18/2024, 7:59:27 AM] [Resideo] Thermostat: Kitchen failed to refreshStatus, Too Many Requests
[7/18/2024, 7:59:27 AM] [Resideo] Thermostat: Office failed to refreshStatus, Too Many Requests
[7/18/2024, 7:59:27 AM] [Resideo] Thermostat: Master Bedroom failed to refreshStatus, Too Many Requests
[7/18/2024, 7:59:27 AM] [Resideo] Thermostat: Office failed to refreshStatus, Too Many Requests
18/2024, 8:27:44 AM] ---
[7/18/2024, 8:27:44 AM] Loaded plugin<EMAIL_ADDRESS>[7/18/2024, 8:27:44 AM] Registering platform 'homebridge-resideo.Resideo'
[7/18/2024, 8:27:44 AM] ---
[7/18/2024, 8:27:46 AM] [Resideo] Initializing Resideo platform...
[7/18/2024, 8:27:46 AM] [Resideo] Total Locations Found: 1
[7/18/2024, 8:27:46 AM] [Resideo] Total Devices Found at Home: 1
[7/18/2024, 8:27:46 AM] [Resideo] Restoring existing accessory from cache: T10 DeviceID: LCC-48A2E68E5254
[7/18/2024, 8:27:47 AM] [Resideo] Failed to Get T9 Firmware Version: Requst Not Found
[7/18/2024, 8:27:47 AM] [Resideo] Restoring existing accessory from cache: Living Room Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 8:27:47 AM] [Resideo] Restoring existing accessory from cache: Living Room Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 8:27:47 AM] [Resideo] Restoring existing accessory from cache: Kitchen Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 8:27:47 AM] [Resideo] Restoring existing accessory from cache: Kitchen Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 8:27:47 AM] [Resideo] Restoring existing accessory from cache: Master Bedroom Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 8:27:47 AM] [Resideo] Restoring existing accessory from cache: Master Bedroom Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 8:27:47 AM] [Resideo] Restoring existing accessory from cache: Office Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 8:27:48 AM] [Resideo] Restoring existing accessory from cache: Office Serial Number:<PHONE_NUMBER>0000
/18/2024, 9:35:26 AM] Loaded plugin<EMAIL_ADDRESS>[7/18/2024, 9:35:26 AM] Registering platform 'homebridge-resideo.Resideo'
[7/18/2024, 9:35:26 AM] [Resideo] Initializing Resideo platform...
[7/18/2024, 9:35:26 AM] [Resideo] Total Locations Found: 1
[7/18/2024, 9:35:26 AM] [Resideo] Total Devices Found at Home: 1
[7/18/2024, 9:35:26 AM] [Resideo] Restoring existing accessory from cache: T10 DeviceID: LCC-48A2E68E5254
[7/18/2024, 9:35:27 AM] [Resideo] Failed to Get T9 Firmware Version: Requst Not Found
(node:26928) [DEP0123] DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version.
(Use `node --trace-deprecation ...` to show where the warning was created)
[7/18/2024, 9:35:27 AM] [Resideo] Restoring existing accessory from cache: Living Room Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:35:27 AM] [Resideo] Restoring existing accessory from cache: Living Room Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:35:27 AM] [Resideo] Restoring existing accessory from cache: Kitchen Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:35:27 AM] [Resideo] Restoring existing accessory from cache: Kitchen Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:35:27 AM] [Resideo] Restoring existing accessory from cache: Master Bedroom Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:35:27 AM] [Resideo] Restoring existing accessory from cache: Master Bedroom Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:35:27 AM] [Resideo] Restoring existing accessory from cache: Office Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:35:27 AM] [Resideo] Restoring existing accessory from cache: Office Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:05 AM] ---
[7/18/2024, 9:36:05 AM] Loaded plugin<EMAIL_ADDRESS>[7/18/2024, 9:36:05 AM] Registering platform 'homebridge-resideo.Resideo'
[7/18/2024, 9:36:06 AM] [webostv] Initializing webostv platform...
[7/18/2024, 9:36:06 AM] [Resideo] Initializing Resideo platform...
[7/18/2024, 9:36:06 AM] [Resideo] Total Locations Found: 1
[7/18/2024, 9:36:06 AM] [Resideo] Total Devices Found at Home: 1
[7/18/2024, 9:36:06 AM] [Resideo] Restoring existing accessory from cache: T10 DeviceID: LCC-48A2E68E5254
(node:27290) [DEP0123] DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version.
(Use `node --trace-deprecation ...` to show where the warning was created)
[7/18/2024, 9:36:06 AM] [Resideo] Failed to Get T9 Firmware Version: Requst Not Found
[7/18/2024, 9:36:07 AM] [Resideo] Restoring existing accessory from cache: Living Room Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:08 AM] [Resideo] Restoring existing accessory from cache: Living Room Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:08 AM] [Resideo] Restoring existing accessory from cache: Kitchen Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:08 AM] [Resideo] Restoring existing accessory from cache: Kitchen Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:08 AM] [Resideo] Restoring existing accessory from cache: Master Bedroom Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:08 AM] [Resideo] Restoring existing accessory from cache: Master Bedroom Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:08 AM] [Resideo] Restoring existing accessory from cache: Office Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:09 AM] [Resideo] Restoring existing accessory from cache: Office Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:34 AM] Loaded plugin<EMAIL_ADDRESS>[7/18/2024, 9:36:34 AM] Registering platform 'homebridge-resideo.Resideo'
[7/18/2024, 9:36:35 AM] [Resideo] Initializing Resideo platform...
(node:27533) [DEP0123] DeprecationWarning: Setting the TLS ServerName to an IP address is not permitted by RFC 6066. This will be ignored in a future version.
(Use `node --trace-deprecation ...` to show where the warning was created)
[7/18/2024, 9:36:35 AM] [Resideo] Total Locations Found: 1
[7/18/2024, 9:36:35 AM] [Resideo] Total Devices Found at Home: 1
[7/18/2024, 9:36:35 AM] [Resideo] Restoring existing accessory from cache: T10 DeviceID: LCC-48A2E68E5254
[7/18/2024, 9:36:36 AM] [Resideo] Failed to Get T9 Firmware Version: Requst Not Found
[7/18/2024, 9:36:36 AM] [Resideo] Restoring existing accessory from cache: Living Room Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:36 AM] [Resideo] Restoring existing accessory from cache: Living Room Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:36 AM] [Resideo] Restoring existing accessory from cache: Kitchen Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:36 AM] [Resideo] Restoring existing accessory from cache: Kitchen Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:36 AM] [Resideo] Restoring existing accessory from cache: Master Bedroom Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:36 AM] [Resideo] Restoring existing accessory from cache: Master Bedroom Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:36 AM] [Resideo] Restoring existing accessory from cache: Office Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:36:36 AM] [Resideo] Restoring existing accessory from cache: Office Serial Number:<PHONE_NUMBER>0000
[7/18/2024, 9:37:02 AM] Loaded plugin<EMAIL_ADDRESS>[7/18/2024, 9:37:02 AM] Registering platform 'homebridge-resideo.Resideo'
[7/18/2024, 9:37:02 AM] [Resideo] Initializing Resideo platform...
[7/18/2024, 9:37:58 AM] [Homebridge UI] [homebridge-resideo] Incoming Request: Start Resideo Login Server
[7/18/2024, 9:37:58 AM] [Homebridge UI] [homebridge-resideo] Server is running
[7/18/2024, 9:38:16 AM] Loaded plugin<EMAIL_ADDRESS>[7/18/2024, 9:38:16 AM] Registering platform 'homebridge-resideo.Resideo'
[7/18/2024, 9:38:16 AM] [Resideo] Initializing Resideo platform...
[7/18/2024, 9:39:47 AM] Loaded plugin<EMAIL_ADDRESS>[7/18/2024, 9:39:47 AM] Registering platform 'homebridge-resideo.Resideo'
[7/18/2024, 9:39:59 AM] [Homebridge UI] [homebridge-resideo] Incoming Request: Start Resideo Login Server
[7/18/2024, 9:39:59 AM] [Homebridge UI] [homebridge-resideo] Server is running
[7/18/2024, 9:40:10 AM] [Homebridge UI] Changes to config.json saved.
[7/18/2024, 9:40:10 AM] [Homebridge UI] Running Command: sudo -E -n npm uninstall -g homebridge-resideo
[7/18/2024, 9:42:23 AM] [Homebridge UI] Running Command: sudo -E -n npm install -g<EMAIL_ADDRESS>[7/18/2024, 9:42:30 AM] [Homebridge UI] [homebridge-resideo] Incoming Request: Start Resideo Login Server
[7/18/2024, 9:42:30 AM] [Homebridge UI] [homebridge-resideo] Server is running
[7/18/2024, 9:45:22 AM] Loaded plugin<EMAIL_ADDRESS>[7/18/2024, 9:45:22 AM] Registering platform 'homebridge-resideo.Resideo'
[7/18/2024, 9:45:29 AM] [Homebridge UI] [homebridge-resideo] Incoming Request: Start Resideo Login Server
[7/18/2024, 9:45:29 AM] [Homebridge UI] [homebridge-resideo] Server is running
[7/18/2024, 9:48:25 AM] Loaded plugin<EMAIL_ADDRESS>[7/18/2024, 9:48:25 AM] Registering platform 'homebridge-resideo.Resideo'
[7/18/2024, 9:48:25 AM] [Resideo] Initializing Resideo platform...
[7/18/2024, 9:48:59 AM] [Homebridge UI] [homebridge-resideo] Incoming Request: Start Resideo Login Server
[7/18/2024, 9:48:59 AM] [Homebridge UI] [homebridge-resideo] Server is running
[7/18/2024, 9:57:40 AM] [Homebridge UI] [homebridge-resideo] Incoming Request: Start Resideo Login Server
[7/18/2024, 9:57:40 AM] [Homebridge UI] [homebridge-resideo] Server is running

Config for homebridge-resideo
{
    "name": "Resideo",
    "credentials": {
        "consumerKey": "REDACTED",
        "consumerSecret": "REDACTED",
        "accessToken": "REDACTED",
        "refreshToken": "REDACTED"
    },
    "platform": "Resideo"
}

Screenshots

Device & Model
Honeywell T10
Node.js Version
v20.15.1
NPM Version
v10.7.0
Homebridge Version
v1.8.3
Homebridge Resideo Plugin Version
v2.1.4
Homebridge Config UI X Plugin Version
v4.56.4
Operating System
Ubuntu 22.04

I am also experiencing this issue with the Honeywell T9 thermostat.  It also will reflect No Response various times throughout the day.

I've been experiencing the same issue for several months now with my T5 thermostat. I haven't seen any No Response indicators as of late, but the current temperature always shows 68 regardless of what temp it actually is in the room. Happy to provide any additional information if needed.

Same issue here on my T10, temps are all wrong including the main thermostat itself.

I get this same behavior on any version beyond 1.4.6, so I keep it held back at that release.

So far 2.1.9 seems to work fine.  So it's either fixed or only an AC issue, not heat.


Doomfist indicator slam

Created by: UgandanF16

The game at times will have trouble recognizing you are able to slam, the indicator will show, so its not a range issue, but pressing E does nothing at times and the slam will just refuse to activate. (semi easily replicated)

Doomfist will arc slam sometimes even when indicators are shown, but I'm not sure if anything can be done about this, as it was a common well-known issue in OW1.  (pretty hard to replicate as it is just RNG and rarely happens)

Meteor strike behaves strangely when landing on top of a Mei wall. It will no reg (non-register) on anyone who is standing on the wall AS it is rising and do 0 damage even if they are in the center of it. (not sure if you can fix this, it happens to OW2 doom as well, its just a design issue I believe.

Indicator slam VERY OFTEN can slam below the horizon line, or below the flat surface. (Extremely easy to replicate) https://streamable.com/6imhfz https://streamable.com/vdi7xw

Even if majority of Doom's OW1 bugs are fixed, I suspect some will be left over because his kit design was just buggy in OW1. There is not much to do about some of these bugs, Blizzard refused to fix them over the years and instead lazily just reworked/redesigned his kit.

Created by: yeahPluem
for arc indicators I remember the workshop specifically made for dps doomfist had that so maybe the code could be copied for there? (I have 0 knowledge about how this works)

Created by: MaxwellJung

Meteor strike behaves strangely when landing on top of a Mei wall. It will no reg (non-register) on anyone who is standing on the wall AS it is rising and do 0 damage even if they are in the center of it. (not sure if you can fix this, it happens to OW2 doom as well, its just a design issue I believe.

Submit a new issue for this as it's not related to the title of this issue.

Created by: MaxwellJung
@yeahPluem see MaxwellJung/ow1_emulator#725

Created by: MaxwellJung
Closing this issue as indicator slam is somewhat stable since v0.3.0

moved from ow1_emulator_backup#593


Add (bi-)LSTM encoder as an alternative to the Transformer encoder for DIET

Description of Problem:

DIET uses a Transformer encoder, however it is perfectly possible to use a different encoder instead. In my experiments (see below) both encoders achieve comparable performance, with the LSTM typically being slightly weaker than the Transformer. Nonetheless, our experiments are not exhaustive and it might be that some users find the LSTM encoder performing better than the Transformer. In terms of training time, the Transformer based model trains slightly faster than the LSTM based one, but the difference isn't dramatic.
Preliminary experimental results:

Dataset
LSTM
Transformer

ATIS - Intent
95.53 (Accuracy)
96.61 (Accuracy)

ATIS - Entities
94.83 (micro-avg F1)
95.37 (micro-avg F1)

SNIPS - Intent
97.71 (Accuracy)
98.03 (Accuracy)

SNIPS - Entities
95.62 (micro-avg F1)
95.10 (micro-avg F1)

HERMIT - Intent
90.77 (+/- 0.72) (micro-avg F1)
89.89 (+/- 0.43) (micro-avg F1)

HERMIT - Entities
81.47 (+/- 1.27) (micro-avg F1)
87.38 (+/- 0.64) (micro-avg F1)

Overview of the Solution:

There are some upsides and some downsides to adding this option to rasa OSS
Pro:

An additional option for the users
Some of the DIET code will be refactored, making future changes - i.e. replacing the Transformer by whatever new thing - easier
Harmonising some of the pipeline keys (e.g. currently num_transformer_layers vs. num_lstm_layers) could become num_encoder_layers for parameters with shared semantics.

Con:

No clear benefit result wise (on the datasets we've used) or runtime wise
More code = more maintainable code
Additional complexity for pipeline configuration if not harmonised (e.g. num_transformer_layers vs num_lstm_layers)

An initial implementation is done, integration into rasa OSS will involve at least a little bit of refactoring in the DIET model + optionally harmonising some of the config keys.
Whats your thoughts @tabergma @Ghostvv @amn41 @tmbo?
Definition of Done:

which version of Rasa is it? Is it before I reintroduced scale_loss?

yes, its branched off 1.8, so doesn't include that fix yet

@tttthomasssss The current results above don't give a lot of motivation to include LSTM as a configurable option IMO. Do you have any results with pipelines that don't have ConveRT featurizer in them? Curious if LSTM is better for other feature combination.

Results with sparse feature have been substantially worse. I haven't run many experiments with GloVe, though I can certainly give it a go.


SpeechRecognition

Hi.
Will the SpeechRecognition project go?
I don't want to use button.
I would like to run over OK google.
It will work ?

It's not designed to work with OK Google.


WIP Extend Router DSL  #904

Opening a WIP PR since this issue had quite a bit of activity today to give some transparency with where things are at.
I'm definitely welcome to suggestions! Here's my current list of questions:

How should we handle authenticatedRoute name conflict?
How should we bring over the container utilities?
Any suggestions on tests?

Will make some more progress on this tonight. After we figure out how to handle the name conflict, expanding to handle authenticatedRoute will be easy.
There is a name conflict with authenticatedRoute via torii
Since torii is currently using this.unauthenticatedRoute on Router, we have no way to distinguish whether they want torii or ESA mixins.
Should we somehow namespace our new routes to Ember Simple Auth? (That's why I started with unauthenticatedRoute.)
Should we combine container utilities into one file?
Several container utilities are needed for registering the mixin on a given route. addon/utils/lookup.js is an example of one that ESA already had. Grabbed register and lookup-factory from troii. Should we consolidate this into one file in ESA, pull out into independent addon, or leave in different files?
addon/utils/lookup.js
addon/utils/register.js from https://github.com/Vestorly/torii/blob/master/addon/lib/container-utils.js
addon/utils/lookup-factory.js from https://github.com/Vestorly/torii/blob/master/addon/lib/container-utils.js
Still working on the tests.
Suggestions welcome. I still want to verify that addon/bootstrap/routing.js is properly applying a mixin via test. Will probalby break this out into its own unit test.
May rethink some of the tests based off of reading https://github.com/Vestorly/torii/blob/master/tests/acceptance/routing-test.js. (Probably should have done that much earlier)
/cc @mdentremont

(This relates to #904)

The conflicting router DSL method names are a really a bit unfortunate. Given that the mixin's names are AuthenticatedRouteMixin and UnauthenticatedRouteMixin it would be great to be able to use authenticatedRoute and unauthenticatedRoute accordingly of course.
It might be a good idea to make the router DSL opt-in (and ask the torii project to do so as well) as changes of Ember.js core APIs will always have that potential for conflicts and thus should maybe not switched on by default anyway (/cc @mixonic).
An alternative API we could use that would be conflict-free would be sth. like this:
Router.map(function() {
  this.route('index');
  this.authenticated(function() {
    this.route('projects');
  });
  this.unauthenticated(function() {
    this.route('login');
  });
})

@ryanlabouve: an alternative might be to use this.route('projects', { authenticated: true });/this.route('projects', { unauthenticated: true });

Interested in this. Commented so that I get notification on the proceeding of this PR

OT: @mtangoo: you can always click the subscribe button on the right on anything.

Thanks,  @marcow. Didn't know that

Moving this to 1.3 to make it easier for us to finally get 1.2 out.

I'm not even so sure anymore we need this at all as the only case where this is really useful is if you have a totally flat routing structure with a lot of routes that should all be authenticated but are not below a common parent route that the AuthenticatedRouteMixin could be applied to which seems to be a pretty rare case.
At the same time making this so that it works in all supported Ember versions (which actually go back all the way to 1.2) would be a huge effort, not to speak about future Ember versions…

👍 closing.

Didn't want to imply it has to be closed - but if you think the above points make sense that's cool.


Upgrade to Angular 5.1 and TypeScript 2.6

I'll put in a pull request as soon to upgrade after figuring out other tickets. I'm already running  Angular 5x and ts 6.2.


docs: include PyArrow in quick start

Currently, https://narwhals-dev.github.io/narwhals/quick_start/ only shows the output for pandas and Polars
Let's get PyArrow in there too?

file to modify: https://github.com/narwhals-dev/narwhals/blob/main/docs/quick_start.md
contributing guide: https://github.com/narwhals-dev/narwhals/blob/main/CONTRIBUTING.md

@MarcoGorelli both https://narwhals-dev.github.io/narwhals/quick_start/ and https://github.com/narwhals-dev/narwhals/blob/main/docs/quick_start.md return 404

I would like to work on this.


add hash support any types of key (interface{}).

Thanks a lot, but you can support value of any types as well.
By the way, add test cases.


feat: defer resolving the pipeline until after the name is selected

Avoids the need to resolve every pipeline in the triggers file - which can sometimes take a bit of time if using uses: syntax

Hi @cameronbraid. Thanks for your PR.
I'm waiting for a jenkins-x or todo member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test label.
I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign rajdavies
You can assign the PR to them by writing /assign @rajdavies in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment


Cannot find name '$colorMode'.ts(2304)

The error still occurs under nuxt 3 & "@nuxtjs/color-mode": "^3.0.1"
Cannot find name '$colorMode'.ts(2304)
I have installed it under dev

I've just published it as 3.0.2. You should continue to access it as $colorMode unless you are using composition API, in which case you will use const colorMode = useColorMode() in your setup function. (This is the recommended approach.)

sorry i am brand new to this story. So I try to use the part below with Tailwind v2

When you tried earlier, I hadn't published it yet. You can try installing 3.0.2. And if you are using it in your template, access it as $colorMode.

Same after update

It's working here. If you're still experiencing this after restarting your IDE, would you provide a reproduction?

I will try, and of course provide a reproduction

ok it took an IDE restart. Now it works.
Thanks a lot!


Added plotly_intercept_code configuration option

There are use cases where a Plotly figure is being generated by a user defined class and shown through one of the class methods. For example, one of the commands in my module might be:
plot(sin(x), (x, -10, 10))

The function plot returns a custom Plot object, containing the Plotly figure. Inside the plot function, the Plotly figure will be shown before the return statement.
With the current implementation of this extension it is impossible to visualize the resulting plot. Plotly doesn't have something similar to Matplotlib's figure managers, which "intercepts" the figures being shown at a lower level.
Solution: create a new configuration option, plotly_intercept_code, which will eventually be set to a user-defined function, accepting the current code-block being processed and returning a modified code. The user can modify the code with regex or ast to extract the Plotly figure from the custom objects. Then, the current implementation will be able to continue successfully.
Consider the following code-block example contained into a docstring. If a user executes it, it will show a Plotly figure.
fx = lambda u, v: (4 + np.cos(u)) * np.cos(v)
fy = lambda u, v: (4 + np.cos(u)) * np.sin(v)
fz = lambda u, v: np.sin(u)
plot3d_parametric_surface(fx, fy, fz, ("u", 0, 2 * pi), ("v", 0, 2 * pi),
    rendering_kw=dict(
        contours={
            "z": {"show": True, "start": -1, "end": 1, "size": 1/10,
                  "width": 1, "usecolormap": True}
        },
        showscale=False, colorscale="Aggrnyl"),
    zlim=(-2.5, 2.5), title="Torus", backend=PB)

If this extension executes the above code block, it will open the plot on a new browser window, but it won't be able to include the figure in the docs, because it doesn't know where the figure is actually stored.
With this commit, the extension processes this code block, send it to the "intercept code function", where I can use the ast module to modify the code to:
fx = lambda u, v: (4 + np.cos(u)) * np.cos(v)
fy = lambda u, v: (4 + np.cos(u)) * np.sin(v)
fz = lambda u, v: np.sin(u)
myplot = plot3d_parametric_surface(fx, fy, fz,
    ("u", 0, 2 * pi), ("v", 0, 2 * pi),
    rendering_kw=dict(
        contours={
            "z": {"show": True, "start": -1, "end": 1, "size": 1/10,
                  "width": 1, "usecolormap": True}
        },
        showscale=False, colorscale="Aggrnyl"),
    zlim=(-2.5, 2.5), title="Torus", backend=PB, show=False)
myplot.fig

Here:

I assigned the object returned by the plot command to a variable.
I added show=False to the plot command, so no figure will be shown on the browser (which is annoying if you have dozen of figures opening every time you build the docs).
I added a new command extracting the Plotly figure from my custom object.

Once this modified code is returned, it will be normally processed by this extension and everything works as expected.

@harupy Please let me know if you intend to merge my pull requests and eventually update the package to a new version...


fix(docs) Added a mention about ModuleConcatenationPlugin in the tree shaking (#2440)

Added a mention about ModuleConcatenationPlugin in the tree shaking, because it will not run without it.

@montogeek URLs updated

Thanks!


Scripts to install dependencies

Fix bugs of installation among various OS, add installation scripts for further use.
Status
READY
Description
Added scripts to ease up installing dependencies.
Todos

[x] Tests
[x] Documentation

Deploy Notes
Make sure you have sudo priveleges
Steps to Test or Reproduce
sudo bash script_name_based_on_os.py
git pull --prune
git checkout <feature-branch>

Impacted Areas in Application

Installation

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 24

Complexity increasing per file
==============================
- ServerApp/app/user/controllers.py  6
- ServerApp/app/user/models.py  1
- ServerApp/app/__init__.py  67

Clones added
============
- ServerApp/app/__init__.py  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 24

Complexity increasing per file
==============================
- ServerApp/app/user/controllers.py  6
- ServerApp/app/user/models.py  1
- ServerApp/app/__init__.py  67

Clones added
============
- ServerApp/app/__init__.py  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 11

Complexity increasing per file
==============================
- ServerApp/app/__init__.py  67
- ServerApp/app/user/models.py  1
- ServerApp/app/user/controllers.py  6

Clones added
============
- ServerApp/app/__init__.py  2
- ServerApp/app/user/controllers.py  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 9

Complexity increasing per file
==============================
- ServerApp/app/user/controllers.py  6
- ServerApp/app/__init__.py  67
- ServerApp/app/user/models.py  1

Clones added
============
- ServerApp/app/user/controllers.py  2
- ServerApp/app/__init__.py  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 13

Complexity increasing per file
==============================
- ServerApp/app/__init__.py  67
- ServerApp/app/user/controllers.py  6
- ServerApp/app/user/models.py  1

Clones added
============
- ServerApp/app/__init__.py  2
- ServerApp/app/user/controllers.py  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 11

Complexity increasing per file
==============================
- ServerApp/app/user/models.py  1
- ServerApp/app/__init__.py  67
- ServerApp/app/user/controllers.py  6

Clones added
============
- ServerApp/app/__init__.py  2
- ServerApp/app/user/controllers.py  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 10

Complexity increasing per file
==============================
- ServerApp/app/user/controllers.py  6
- ServerApp/app/user/models.py  1
- ServerApp/app/__init__.py  67

Clones added
============
- ServerApp/app/user/controllers.py  2
- ServerApp/app/__init__.py  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 9

Complexity increasing per file
==============================
- ServerApp/app/user/models.py  1
- ServerApp/app/user/controllers.py  6
- ServerApp/app/__init__.py  67

Clones added
============
- ServerApp/app/user/controllers.py  2
- ServerApp/app/__init__.py  2

See the complete overview on Codacy

 Here is an overview of what got changed by this pull request:

Issues
======
- Added 8

Complexity increasing per file
==============================
- ServerApp/app/user/controllers.py  6
- ServerApp/app/user/models.py  1
- ServerApp/app/__init__.py  67

Clones added
============
- ServerApp/app/user/controllers.py  2
- ServerApp/app/__init__.py  2

See the complete overview on Codacy


Update README about flags on cluster logs

Release note:

NONE

/assign @sebastienvas

@chxchx: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
88427754694e708104d5a6591cd994eebeea28eb
link
@istio-testing bazel test this

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/approve no-issue
/lgtm

/test all


Deprecate public or protected method and variable that contains "master" terminology in 'server', 'client/rest', 'client/rest-high-level' and 'test/framework' directory

Is your feature request related to a problem? Please describe.
A part of issue https://github.com/opensearch-project/OpenSearch/issues/1684.
To support inclusive language, the master terminology is going to be replaced by cluster manager in the code base.
The goal for this issue is:

Deprecate the public/protected methods and variables that have "master" in the names. The involved methods and variables are located in server, client/rest, client/rest-high-level and test/framework directories, and the deprecated items will be removed in the next major version (3.0)
Have alternative methods and variables aside, which replaced the non-inclusive name "master" and have the same functionality with the deprecated items.

Describe the solution you'd like
For overall solution to replace "master" in public Java APIs: https://github.com/opensearch-project/OpenSearch/issues/1684#issuecomment-1145541374
Key points:

Any public/protected method or variable with "master" in the name will directly call the renamed method to maintain only one method/variable while supporting the old ones.

In detail:

Copy the code of method/variable definition and keep it in another place.
Replace master word with clusterManager in the method or variable name. This is done by the Rename refactoring feature of IntelliJ IDEA, so that both the definition and reference can be renamed.
Paste the original code of master method/vairable definition back.
Remove all the existing implementation in the old method, and directly call the new renamed method with the same parameters.
Add @Deprecated annotation and @deprecated Javadoc tag for the method/variable that contains "master" in the name.
Backport all the changes to 2.x branch.

Describe alternatives you've considered
None.
Additional context
The regex to filter the lines with public or protected method/variable definition contains "master" terminology:
method: (public|protected)(.)+[Mm]aster(\w)*\(
variable: (public|protected)(.)+(MASTER|master)(.)*=
Totally 195 methods and 21 variables.
The above number need excluding:

There are 15 method definitions and 7 variables that are covered by issue https://github.com/opensearch-project/OpenSearch/issues/3542 and https://github.com/opensearch-project/OpenSearch/issues/3543.
75 masterOperation() overrides which will be resolved by #3542

List of public methods to be renamed:
in sever directory:
public boolean hasDiscoveredMaster() {
public boolean localNodeMaster() {
public void updateMappingOnMaster(Index index, Mapping mappingUpdate, ActionListener<Void> listener) {
public boolean isBecomeMasterTask() {
public Optional<DiscoveryNode> getMasterNode() {
public PutRequest masterTimeout(TimeValue masterTimeout) {
public RemoveRequest masterTimeout(TimeValue masterTimeout) {
public static boolean isMasterNode(Settings settings) {
public boolean isMasterNode() {
public boolean isLocalNodeElectedMaster() {
public ImmutableOpenMap<String, DiscoveryNode> getMasterNodes() {
public ImmutableOpenMap<String, DiscoveryNode> getMasterAndDataNodes() {
public Stream<DiscoveryNode> mastersFirstStream() {
public String getMasterNodeId() {
public DiscoveryNode getMasterNode() {
public boolean masterNodeChanged() {
public DiscoveryNode previousMasterNode() {
public DiscoveryNode newMasterNode() {
public Builder masterNodeId(String clusterManagerNodeId) {
public boolean isLocalNodeElectedMaster() {
protected void assertClusterOrMasterStateThread()
public void addLocalNodeMasterListener(LocalNodeMasterListener listener)
public MasterService getMasterService() (not changed in this PR)
public static boolean assertClusterOrMasterStateThread()
void connectToRemoteMasterNode(TransportAddress transportAddress, ActionListener<DiscoveryNode> listener)
TimeValue masterNodeTimeout()
public synchronized void updateFromMaster()
public ClusterState joinNodesAndBecomeMaster(ClusterState clusterState, List<DiscoveryNode> nodes)

In client directory:
public void setMasterTimeout(TimeValue clusterManagerTimeout)
public TimeValue masterNodeTimeout()
public TimeValue getMasterNodeTimeout()
public void setMasterNodeTimeout(@Nullable TimeValue clusterManagerNodeTimeout)
public void setMasterNodeTimeout(String clusterManagerNodeTimeout)
public boolean isMasterEligible()

In test/framework directory:
public static String blockMasterFromFinalizingSnapshotOnIndexFile(final String repositoryName) {
public static String blockMasterOnWriteIndexFile(final String repositoryName) {
public static void blockMasterFromDeletingIndexNFile(String repositoryName) {
public static String blockMasterFromFinalizingSnapshotOnSnapFile(final String repositoryName) {
public static MasterService createMasterService(ThreadPool threadPool, ClusterState initialClusterState) {
public static MasterService createMasterService(ThreadPool threadPool, DiscoveryNode localNode) {
public abstract int numDataAndMasterNodes();
public Client masterClient() {
public Client nonMasterClient() {
public boolean isMasterEligible() {
public synchronized <T> T getCurrentMasterNodeInstance(Class<T> clazz) {
public <T> Iterable<T> getDataOrMasterNodeInstances(Class<T> clazz) {
public <T> T getMasterNodeInstance(Class<T> clazz) {
public synchronized void stopCurrentMasterNode() throws IOException {
public synchronized void stopRandomNonMasterNode() throws IOException {
public String getMasterName() {
public String getMasterName(@Nullable String viaNode) {
public List<String> startMasterOnlyNodes(int numNodes) {
public List<String> startMasterOnlyNodes(int numNodes, Settings settings) {
public int numMasterNodes() {
public static Settings masterNode()
public static Settings masterNode(final Settings settings)
public static Settings masterOnlyNode()
public static Settings masterOnlyNode(final Settings settings)
public static Settings nonMasterNode()
public static Settings nonMasterNode(final Settings settings)
public Version masterVersion()

List of public variables to be renamed:
In client directory:
public static final TimeValue DEFAULT_MASTER_NODE_TIMEOUT

In test/framework directory:
(all in org.opensearch.test.InternalTestCluster)
public static final int DEFAULT_LOW_NUM_MASTER_NODES
public static final int DEFAULT_HIGH_NUM_MASTER_NODES
public static final int REMOVED_MINIMUM_MASTER_NODES

Progress update on 07/20/2022:
Completed:
public methods and variables in server directory are deprecated and renamed by PR https://github.com/opensearch-project/OpenSearch/pull/3647.
Remaining:
a few public methods and variables in client/rest, client/rest-high-level and test/framework are pending to be deprecated and renamed. There is no blockers.

Progress update on 07/31/2022:
Completed:
The 2 methods are deprecated and renamed.

In test/framework directory:
public static MasterService createMasterService(ThreadPool threadPool, ClusterState initialClusterState)
public static MasterService createMasterService(ThreadPool threadPool, DiscoveryNode localNode)

Remaining:
The abstract methods in the interface will be deprecated with the other one method in issue https://github.com/opensearch-project/OpenSearch/issues/3543#issuecomment-1189593243 together, using the solution in issue https://github.com/opensearch-project/OpenSearch/issues/3688#issuecomment-1190795480

In interface AckedRequest: TimeValue masterNodeTimeout() (in interface AckedRequest)

Progress update on 08/03/2022:
Nothing remains for this issue.
The above remaining item, the abstract method TimeValue masterNodeTimeout() has been deprecated and renamed by PR https://github.com/opensearch-project/OpenSearch/pull/4121, and backported to 2.x and 2.2 branches by PR https://github.com/opensearch-project/OpenSearch/pull/4122 and https://github.com/opensearch-project/OpenSearch/pull/4123.


lexbor.dll is built when separated libs is set : is it normal ?

well, everything is in the subject :)

@vtorri
yes, it is normal.


Remove TupleType::underlying_ field

Motivation

Basically the same change as #3833, but for TupleType instead of ShapeType.
Same motivation:

prework broken out of #3822
no behavior changes
drops TupleType size

Has one unique downside:

we're doing lubAll inside underlying, so we could potentially be doing more
lubbing work over and over again. if this ends up being too slow, we can
always memoize the result of this function.

Test plan

See included automated tests.

We have a policy of testing changes to Sorbet against Stripe's codebase before
merging them. I've kicked off a test run for the current PR.  When the build
finishes, I'll share with you whether or how it failed. Thanks!
Stripe employees can see the build results here:
→ https://go/builds/bui_IcGsM9m348CPtd
→ https://go/builds/bui_IcGsWfGRZO95RB


Python bindings

Next to the Micropython bindings, there should also be bindings for 'regular' Python. The goal should be to have the same API for Micropython and regular Python.

cc @kisvegabor

As discussed earlier @rreilink would like to rely more on naming conventions. For example it should be known that a paramter is saved by LittelvGL or not. What other places of the library should be improved to aid Python binding generation?

One other issue that I have come across is the inconsistent naming of enum types / members lv_hal_indev_type_t and lv_preloader_type_t . If we want to annotate setters/getters with the enum type that they expect/return, this consistency is desirable.
lv_hal_indev_type_t
enum {
    LV_INDEV_TYPE_NONE,        /*Show uninitialized state*/
    LV_INDEV_TYPE_POINTER,     /*Touch pad, mouse, external button*/
    LV_INDEV_TYPE_KEYPAD,      /*Keypad or keyboard*/
    LV_INDEV_TYPE_BUTTON,      /*External (hardware button) which is assinged to a specific point of the screen*/
    LV_INDEV_TYPE_ENCODER,     /*Encoder with only Left, Right turn and a Button*/
};
typedef uint8_t lv_hal_indev_type_t;

This should be renamed to lv_indev_type_t or the members renamed to LV_HAL_INDEV_TYPE_xxx (the former has the advantage of not requiring changes to code that uses lvgl).
lv_preloader_type_t
enum {
    LV_PRELOAD_TYPE_SPINNING_ARC,
    LV_PRELOAD_TYPE_FILLSPIN_ARC,
};
typedef uint8_t lv_preloader_type_t;

This should be renamed to lv_preload_type or the members renamed to LV_PRELOADER_xxx.

@kisvegabor two other issues that IMHO could be improved:

lv_btnm_set_map should be changed to take a char* instead of char**. (Terminating each item with '\x00' and terminating the list with '\x00\x00' as discussed earlier in #557)

lv_ddlist_get_selected_str should have a way to specify the buffer size to prevent buffer overflow (this is not Python specific). Could be like snprintf: provide the buffer size in the call, and return the length of the item as return value.

@rreilink do you have a script to list all the enum incompatibilities?

lv_btnm_set_map should be changed to take a char* instead of char**. (Terminating each item with '\x00' and terminating the list with '\x00\x00' as discussed earlier in #557)

I'm considering it for a while and will try it soon in v6.0.

lv_ddlist_get_selected_str should have a way to specify the buffer size to prevent buffer overflow (this is not Python specific). Could be like snprintf: provide the buffer size in the call, and return the length of the item as return value.

It seems like an easy and reasonable improvemnt.

@rreilink @kisvegabor @embeddedt
On #557 we started a discussion about Python bindings and how to integrate Python and Micropython bindings.
I agree, as @rreilink says, that the goal should be to have the same API for Micropython and regular Python. But I don't think this should be done "at all cost".
The question is how to achieve this and also keep the bindings General and Forward Compatible.
My opinion is that the bindings script should know as little as possible about the specifics of lvgl: which specific functions/enums/globals/structs it contains and what is the meaning of each.
Instead, the binding script should build the bindings solely according to conventions. Such conventions would allow the script to know, for example, what are the "classes", their hierarchies, their members, etc. They would allow the script to know what a "struct" is, but not care it this struct represents a style, a theme or a driver handler.
That way, when lvgl changes, the binding is kept compatible. Even if lvgl forks, or users decide to make their own changes to their local version of lvgl, the binding should still work.
In fact, if someone decides to use the same conventions and build an entirely different library, the binding should, at least theoretically, still work for his new library, as long as he sticks the same conventions.
Today, micropython binding is designed that way. I think the Python binding is not, and contains specifics of lvgl hard coded in the binding script itself, instead of relying solely on conventions.
Some examples:

lv_style_t is predefined as Style_Object instead of deducing it from the struct definition.
Fonts are predefined instead of deducing them from the struct definition.
lv_coord_t is predefined as short int instead of deducing it from the typedef
Only 16 bits color depth is supported
Callback handling is predefined, for example btn_set_action, instead of handling generic callback
Display and input drivers are predefined

I think it makes sense to continue this discussion now, when we consider having the same API for Python and Micropython, and maybe even having the same script to generate them both.
So here are some questions I have for @rreilink in this context:

Do you plan to support generic structs and globals? This would cover styles fonts etc. without the need to hard-code them into the binding script. This is supported in Micropython binding today.
Do you plan to support generic callbacks? I have a limited support for this today (one callback per object), and planning full support for v6.0.
Do you plan to support generic driver registration? This is supported in Micropython today and I have several "plug-in" drivers ready. I'm also planning to support pure-python drivers.
We had a discussion about preprocessor. Do you plan to use a standard preprocessor or rely on something else? Are you performing custom parsing of the sources or only parse the preprocessed code? As we previously discussed, I'm against source level parsing since it's not a generic solution, and prefer parsing prerpocessesd code.
How do you support symbols in a generic way? On Micropython I'm using numstr technique to convert enum values to 32bit long string values.
How is memory managed? When are structs allocated and deallocated? To solve this for Micropython, I've enable micropython's Garbage-Collection mechanism on lvgl so it becomes very easy and "pythonic" for the user to create and use structs, without the need to specifically allocate/deallocate them, and without the need to keep track of reference counting.

So here are some questions I have for @rreilink in this context:

Do you plan to support generic structs and globals? This would cover styles fonts etc. without the need to hard-code them into the binding script. This is supported in Micropython binding today.

Yes.

Do you plan to support generic callbacks? I have a limited support for this today (one callback per object), and planning full support for v6.0.

Yes. The current implementation is like this to support more than one callback per object (which I needed in a project). If v6.0 of lvgl can support registering an additional void * or the like when registering an action, all this stuff is no longer needed, and both MicroPython and Python bindings can use the same solution.

Do you plan to support generic driver registration? This is supported in Micropython today and I have several "plug-in" drivers ready. I'm also planning to support pure-python drivers.

Yes

We had a discussion about preprocessor. Do you plan to use a standard preprocessor or rely on something else? Are you performing custom parsing of the sources or only parse the preprocessed code? As we previously discussed, I'm against source level parsing since it's not a generic solution, and prefer parsing prerpocessesd code.

I plan to use the 'standard' preprocessor as that was the consensus in #557. I have already switched to it (not yet committed/pushed). I did run into an issue that cpp misbehaves in Mac OS X, but cc -E  surely worked.

How do you support symbols in a generic way? On Micropython I'm using the numstr technique to convert enum values to 32bit long string values.

I believe for the colors and symbols, custom parsing of those specific include files outweighs the loopholes that one needs to jump through if only using the preprocessed source. The numstr technique increased lv_symbols.h from to 140 to 207 lines, having two lines on different places for each line, and introduced a compile issue.
As discussed in #557, and as @kisvegabor stated:

The new evidence was that we couldn't find a good way to add the colors and the related macros without source code parsing. In light of that, it seemed to me, the source code parsing need to introduced for colors. And once we have source code parsing it should be easy to add it for the symbols too which are quite similar.

How is memory managed? When are structs allocated and deallocated? To solve this for Micropython, I've enabled micropython's Garbage-Collection mechanism on lvgl so it becomes very easy and "pythonic" for the user to create and use structs, without the need to specifically allocate/deallocate them, and without the need to keep track of reference counting.

They will have to be reference-counted. That's the way things are in 'regular' Python. The good new is, with generic structs, this only needs to be implemented once.
Regarding your other remarks:

lv_style_t is predefined as Style_Object instead of deducing it from the struct definition.
Font type is predefined instead of deducing it from the struct definition.
lv_coord_t is predefined as short int instead of deducing it from the typedef

Style_Object and the Font type can go away when the generic structs are implemented

Only 16 bits color depth is supported

This is only a quirck of the way I hacked the framebuffer in there, this should obviously go away with the support for registering a display driver.

Callback handling is predefined, for example btn_set_action, instead of handling generic callback

As mentioned, if lvgl 6.0 supports an additional argument for the callbacks, this can be made generic.

Display and input drivers are predefined

As mentioned, will be made generic. I think for desktop-applications it makes sense to (maybe as a compile-time option) supply a framebuffer implementation that can be registered as the display via the lvgl driver registration way.

Yes. The current implementation is like this to support more than one callback per object (which I needed in a project). If v6.0 of lvgl can support registering an additional void * or the like when registering an action, all this stuff is no longer needed, and both MicroPython and Python bindings can use the same solution.

The current implementation of generic events (it replaces the obejct specific actions) for v6.0 look like this. Just to be sure, is it good for Python and Micropython too?

The current implementation of generic events (it replaces the obejct specific actions) for v6.0 look like this. Just to be sure, is it good for Python and Micropython too?

@kisvegabor Looks good to me.
We would need to define LV_USE_USER_DATA_MULTI to 1 and single to 0 to make it really generic (user_data that can be deduced from callback name).
Do you plan to change all callbacks in that manner? (a quick search shows get_bitmap and get_width, for example, don't have user_data members on lv_font_t.
lv_log_register_print doesn't even receive a struct as the first parameter)

Do you plan to change all callbacks in that manner? (a quick search shows get_bitmap and get_width, for example, don't have user_data members on lv_font_t.

I'm trying to add the most difficult and critical things of v6.0` first. So I'm planning to update the other function too but just a little bit later. Do the missing parts block you in updating the Micropython binding?

Do the missing parts block you in updating the Micropython binding?

@kisvegabor No, it's not blocking me.
Just wanted to make sure other callbacks will be handled the same way. For example, in case of lv_log_register_print I don't have a clear understanding how the same convention can be used, as there is no struct to hold the user_data.

@amirgon
I remember that you already explained why you think that a ser_data would be useful for lv_log_register_print too but I can't find that conversation. Can you tell it again?

@kisvegabor I think that logging callback can be useful on (micro)python. To let the user redirect the logs either to screen, to file, to UART etc. in pure (micro)python.
To create a callback on micropython, we need an associated micropython object which is set when the callback is registered and used when it is called. This micropython object is used when the user register a callback which is an object method or a closure as I explained here.
To make this callback generic we need to follow come naming convention, but this is a bit different because there is no existing struct to hold the user_data.
The callback registration is defined today like this:
void lv_log_register_print(void f(lv_log_level_t, const char *, uint32_t,  const char *));

The convention we discussed assumes that the first argument of the callback would be a pointer to struct which has a void *<callback_name>_user_data member.
In this case the first argument is a lv_log_level_t which is int8_t, and not a struct, so this doesn't match our convention and we need to decide how to handle such case.
One option is to add the user_data to the callback and callback registration:
void lv_log_register_print(void f(lv_obj_user_data_t, lv_log_level_t, const char *, uint32_t,  const char *), lv_obj_user_data_t);

Another option is to leave it as is, and let the micropython define its user_data internally.  This means that we could have only one global callback associated with lv_log_register_print, but this is the case anyway. So the convention would be extended for the case that the first argument is not void*.
My opinion is that users may find the user_data useful (to keep track of output file descriptor or whatever) so adding user_data to the callback makes sense. However, it can work both ways.

To create a callback on micropython, we need an associated micropython object which is set when the callback is registered and used when it is called

Clear now, thank you!
Could it work to use a global user_data for logging in Python? We will have only one callback so don't need to store an arbitrary number of user_data in this case.

Could it work to use a global user_data for logging in Python? We will have only one callback so don't need to store an arbitrary number of user_data in this case.

Yes. As I said, we don't have to add the user_data to the callback, if it's global. In such case the binding script could create and use the user_data internally.
We can only do that in case of a "global" callbacks, where there is only one instance of such callback across all lvgl. So this may be valid for this case, but not for driver or object callbacks.

Yes. As I said, we don't have to add the user_data to the callback, if it's global. In such case the binding script could create and use the user_data internally.

Then I vote for using the "internal user data" in this case. It seems more reasonable to redirect LOG/WARN/ERROR types to the console/file etc. inside the callback than registering separate callbacks for each of them.

@rreilink I fixed:

lv_hal_indev_type_t
lv_preloader_type_t
lv_ddlist_get_selected_str (buf_size argument added)

Is it not possible or "just" difficult to handle const char * x[] variables in the python binding? I'm asking because it's quite convenient in C and I want bo sure it's really worth to change it.

Thanks! Using const char ** variables is surely possible, I had already implemented it before I started some major overhauling to get things aligned with MicroPython. I'll put that code back.

If you also have time these days, please let me know what topics need to be discussed yet.

I'll try to free up some time in the evenings the coming week :-)

Using const char ** variables is surely possible, I had already implemented it before I started some major overhauling to get things aligned with MicroPython. I'll put that code back.

Great! @amirgon what is your view about const char **?

I'll try to free up some time in the evenings the coming week :-)

Awesome! :)

@kisvegabor Is the purpose to represent an array of strings? Can we assume char **  will always represent an array of strings? (in C, in the general case, char **  could represent other things as well. For example, char ** passed as a function argument could represent a single string that is accessed indirectly so the called function could set it as a result value)
If we can assume it always represents an array of strings and nothing else, then we can automatically convert between char ** and a python array of strings.

If we can assume it always represents an array of strings and nothing else, then we can automatically convert between const char ** and a python array of strings.

The problem with assumptions like these in the C language is that the assumptions could later be forgotten.
What about taking advantage of the fact that arrays and pointers are somewhat interchangeable and specify the parameter as const char *[] some_arg instead? That makes it clear that it is being treated like an array, and allows us to clearly distinguish between the two cases you mentioned. We could add that kind of requirement to the coding standard.

@embeddedt
I agree it would be a clear solution (even clearer for the user). But the definition looks like this, doesn't it? const char * some_arg[]
Reference: https://www.tutorialspoint.com/cprogramming/c_passing_arrays_to_functions.htm

@kisvegabor Whoops, I was thinking of C# and Java syntax when I typed it. Your definition is correct.
@amirgon What do you think about it?

@amirgon What do you think about it?

What we need is a strict set of rules how to convert between C types and Python types.
If we agree that const char * some_arg[] would always represent an array of strings, then we could convert it automatically to python array of strings in the [micro]python bindings.

@amirgon I think that it would be safe to enforce that rule. The syntax makes it obvious as well.

I've updated dev-6.0 accordingly: https://github.com/littlevgl/lvgl/commit/1d986e13df0468d4d90cdc0d3fd770b2dcf083d1

I've updated dev-6.0 accordingly: 1d986e1

@kisvegabor What about return values? For example:
const char ** lv_btnm_get_map(const lv_obj_t * btnm);

@amirgon I find that the same syntax is not supported for return values.
If really this is the case, probably a naming convention inforthe parameter, like map_array, would be more reasonable.

@amirgon I find that the same syntax is not supported for return values.
If really this is the case, probably a naming convention for the parameter, like map_array, would be more reasonable.

A naming convention could help. Without it, the [micro]python user would have to "cast" explicitly between the pointer and the array.
For example:
Without naming convention:
map = lv.btnm.get_map()
arr = lv.cast_to_string_array(map)

vs. with naming convention:
arr = lv.btnm.get_map()

cast_to_string_array does not exist today, this is just an example of how this can be solved without naming convention.
If we decide to use naming convention, how would we define it for return values?
We could, for example, require the usage of a typedef:
const char lv_string_array**;
lv_string_array lv_btnm_get_map(const lv_obj_t * btnm);

If we decide to use naming convention, how would we define it for return values?

It can work. An other solution could be to add the hint to function name: lv_btnm_set/get_map_array.
Both are fine for me. We can implement which you prefer more.

What do you think of the following two solutions to differentiate between char * arrays as input argument vs. indirect access to a char*

use the _out suffix to denote return values passed via pointers:

lv_btnm_set_map(lv_obj_t *obj, char ** map)
char ** lv_btnm_get_map(lv_obj_t *obj)
void some_other_function(char ** arg_out)

If some_other_function is were store a char* in arg_out

use const to differentiate between a char*[] input argument and a char* output argument:

lv_btnm_set_map(lv_obj_t *obj, char * const * map)
char * const * lv_btnm_get_map(lv_obj_t *obj)
void some_other_function(char ** arg)

use the _out suffix to denote return values passed via pointers:

If this is the default, we might not need to use any special prefix at all. If you see char ** - it means "out arg" and nothing else.

use const to differentiate between a char*[] input argument and a char* output argument

I think it feels more intuitive to use C array notation (char*[]) than const (char * const *).
We really want to represent an array here, not a constant value, so the usage of const to represnt an array is  confusing.
So I prefer this:
lv_btnm_set_map(lv_obj_t *obj, const char * map[])

over this:
lv_btnm_set_map(lv_obj_t *obj, const char * const * map)

The probéem I see with _out is we can't use it for return values in get functions i.e. still there is no way to know if the return value is an array or pointer.
I feel char * const * map difficult to read. Something more descriptive would be better. But it has the advantage to can be used in return values too.
What about my earlier suggestion: lv_btnm_set/get_map_array?

What about my earlier suggestion: lv_btnm_set/get_map_array?

Sounds to me like this is the best solution of the suggestions that we have discussed.

Sounds to me like this is the best solution of the suggestions that we have discussed.

Great! If @amirgon also agrees, I'll add it.

Sure. It's good for me.

Done. I also update
void lv_chart_set_points_array(lv_obj_t * chart, lv_chart_series_t * ser, lv_coord_t * y_array);
It might be tricky because it has 3 parameters.

Done. I also update
void lv_chart_set_points_array(lv_obj_t * chart, lv_chart_series_t * ser, lv_coord_t * y_array);
It might be tricky because it has 3 parameters.

@kisvegabor That's the solution for array return value. But what about array arguments?
(lv_chart_series_t[] ser, lv_coord_t[] y_array)

I meant ..._array can be used for both set and get functions. However, it still possible to denote array arguments with []
E.g.:
void lv_chart_set_points_array(lv_obj_t * chart, lv_chart_series_t * ser, lv_coord_t y_array[]);
void lv_btnm_set_map_array(const lv_obj_t * btnm, const char map[]);
void lv_btnm_set_ctrl_map_array(const lv_obj_t * btnm, const lv_btnm_ctrl_t ctrl_map[]);

I meant ..._array can be used for both set and get functions. However, it still possible to denote array arguments with []

@kisvegabor I think it's easier and clearer to specify that a function argument is an array in the argument itself (using [], or naming convention) than in the function name (for "set" functions).
When you specify this in the function name, there is no "automatic" way to know which parameter is the array, in case there are more than one, like in lv_chart_set_points_array.
For "get" functions, since a function has only one return value, specifying that the return value is an array on the function name makes more sense.

@amirgon
That makes sense. Updated accordingly. See 3d4c784

@rreilink Is there anything else to improve?

@kisvegabor I am currently looking in how to manage data that is passed to LittlevGL by reference. This will require some way to manage when those references are used by LittlevGL and when they are released. I am still figuring out how to do this exactly, what I am currently thinking of is the following:
Everywhere where a reference that is passed as function argument is retained (stored) by LittlevGL, this is marked.
ext->styles[xxx] = style; --> LV_REF_REPLACE(ext->styles[xxx], style);
When not using Python, this macro would just expand to the original assignment. When compiling for Python, this would be something like:
do {
  void *tmp = ext->styles[LV_BTN_STATE_REL]
  pylv_incref(style);
  ext->styles[LV_BTN_STATE_REL]=style;
  pylv_decref(tmp);
} while (0);

(The temporary pointer is required since the old object should only be freed after the new one has been assigned, since the decref could trigger code that requires a valid object in ext->styles)
pylv_incref and pylv_decref would be support functions that ensure that the underlying data will not be freed while it is used.
Furthermore, there needs to be some additional cleanup when an lvgl object is deleted, it should call something like LV_REF_RELEASE(ext->styles[xxx]);
As said, this still does require some figuring out on how it would work in total, so I'll try some stuff out first.

Are you interested in hosting the Python binding in LittlevGL organization? If so, I can create an lv_binding_python and give Write or even Admin access .

That might help in keeping the binding-specific discussions, issues etc centralized, so I would say yes.

I see the problem.
I have to concerns:

It's easy to miss an assignment.
It's difficult to read.

How does it work in the current Python binding?

How does it work in the current Python binding?

In micropython it's solved by the fact that we use Garbage Collection. Micropython does not require or support reference counting, in order to save RAM and simplify things. This actually makes porting libraries to micropython much easier, if they can be adjusted to support gc (like we did for lvgl!)
I know that Python also has gc that can be enabled optionally. I wonder if it could be used instead of reference counting, making lvgl support much simpler.

The current (non-micro) Python binding just leaks references, i.e. if a structure is passed to lvgl once, it will never be freed. This makes sure nothing will ever crash, but is not the desired behavior I would say.
Unfortunately, when creating C extensions in Python, one has to use reference counting. The gc is only used to break reference cycles (i.e. object a referencing b and b referencing a), but reference counting still has to be used.
I share the concern that it is easy to miss an assignment. Therefore, I created a Python script that parses the lvgl source code and looks for assignments that store pointer arguments to a function. It also handles the case when pointer arguments are passed on to a function that is called, which in turn stores the pointer. The result of that is found here.
As shown, the majority of the cases is related to all xxx_set_style functions. Only those lines that do an actual assignment (e.g. ext->styles_btn[LV_BTN_STATE_REL]) would need to be marked; calls to yyy_set_style(...) would disappear from this list once yyy_set_style is properly marked.

I thought there are more reference assignments. Looking at the list it seems doable to add the macros as you suggested.
Can you narrow the list to only to the assignments which really needs to be marked?

I will add the macros in my fork; this enables me to check that it is indeed correct. Will keep you posted.

See this commit
for what I think would be required to make this work. Would this be acceptable? Obviously, the used macro's need to be defined somewhere, what would be the best place to put a default definition for them (that does nothing but to create the original behavior)?

@amirgon @canardos @kisvegabor
It's not at all @rreilink's fault (I think it's just the way Python and reference counting are), but if this macro trickery is necessary to make the Python binding work, I'm not sure if it's a good idea to support this. From what I can tell, even with the script, we could end up allowing a reference assignment into the code tree that isn't guarded in this manner. That would later result in a memory leak.
The MicroPython binding is much simpler... there are a few places where LV_GC_ROOT is used, but those are rare, and aside from that, the only other requirement is to use a custom heap allocator (the functionality for which was already present anyway).
What do you think? Like @canardos pointed out here, this is looking quite complicated, and I'm not sure it's worthwhile. I do understand why having Python as well as MicroPython support would be a bonus, but is it worth the extra awkwardness in the code?

@rreilink Thank you for the update. Now we can clearly how would it look like.
Unfortunately, It really makes LittlevGL more difficult to read and maintain. So we need to discuss the things mentioned by @embeddedt  and @canardos.
I believe Python binding is important as it could be the core of a drag and drop GUI builder once. But we need to figure out something to leave LittlevGL simple.
As it was already said it's mainly about the styles, would it be possible to have functions to create/release styles? For example (probably it's not the best approach just an example)
style1 = lv.style_create;
style1.init(lv.style_plain);  #Inc. reference count as well
style1.delete();

It seems with Python inited styles like this we would solve the majority of the issues.

... but is it worth the extra awkwardness in the code?

I would say, no, actually. Looking at the changeset, let's just not add this to LittlevGL. I agree with @canardos , we should be reluctant to changing too much to LittlevGL. I made the first version of the Python bindings without any changes to LittlevGL.
What I propose to do in the bindings is the following:

once a reference is passed to LittlevGL, this is marked, and the refcount is increased
when it is no longer used, the user can call a style.free() or the like. If the item was marked as being used by LittlevGL, refcount is decreased and the item is marked as not in use by LittlevGL. When subsequently the last reference in Python goes out of scope, the item is cleaned up.

If the user chooses not to call style.free, the code will work but the object will stay alive. This is no big deal as long as there are no styles created and set within a loop or similar
If the users calls style.free() while it is still in use in LittlevGL --> boom as would be the case when using C and freeing a style that is still in use

A proposed approach would be to create just the number of styles that are required, and then modifying those styles as opposed to creating a new style for each required appearance change.

@rreilink That idea could work. Considering that styles aren't likely to be created over and over, imposing "manual" garbage collection would be fine.

It sounds good to me as well!

@rreilink Are there any news here?

Yes, I did not have too much time for a while, but picked it up again.
Upon updating to the latest dev-6.0, I noticed that lv_obj_get_style now returns a const *style_t instead of previous non-const.
So, in C, you can no longer do e.g. obj_get_style(ob)->body.radius = 0. Should I also enforce this behavior in Python?
Is there a particular reason that styles are now const?

@rreilink See #999. The API was updated because in many cases styles are constant and don't need to change.

So, in C, you can no longer do e.g. obj_get_style(ob)->body.radius = 0. Should I also enforce this behavior in Python?

Yes, if possible it should be enforced in Python too to avoid writing into const data.

@rreilink We will announce a feature freeze for v6.0 in a few days. Is there anything "API breaking" to do here?

None that I currently foresee

Great!
Earlier we were talking about moving the Python binding to littlevgl organization. Are you still interested in it? You would have write or admin right in that repo.