Catch duplicate API key specified (plus scope creep)

Why anyone of sound mind would do this is beyond me. But it does result in exceptions that want heading off at the pass...

Long may the changes in the last two PRs hide dormant. Prepped for next anyways.

Long may the changes in the last two PRs hide dormant. Prepped for next anyways.

While I was reviewing and approving your PR, I was sitting in the Palais waiting for...

Here's an example for you of how smart Copilot can be.
Scenario: I've copied a unit test function for invalid API limit, and am modifying it to test for invalid hard limit.
Result: The clever bugger has worked out exactly what I am doing and is suggesting absolutely correct lines of code (in grey italic, just press tab...)

We now meet (well, far exceed) the minimum requirements for becoming a core component. Unit testing of config_flow.py is must-ride.
I worked out how to shoehorn pytests for a custom into the dev container environment, with minimal alterations required when transitioned as a core component...
In devcontainer.json...
  "mounts": [
    "source=${localEnv:HOME}/Documents/GitHub/ha-solcast-solar/custom_components/solcast_solar,target=${containerWorkspaceFolder}/config/custom_components/solcast_solar,type=bind",
    "source=${localEnv:HOME}/Documents/GitHub/ha-solcast-solar/tests,target=${containerWorkspaceFolder}/tests/components/solcast_solar,type=bind",

from tests/components/solcast_solar run pytest.

We now meet (well, far exceed) the minimum requirements for becoming a core component. Unit testing of config_flow.py is must-ride.

OK, I'll try to have a look over the weekend.
Very tired, now, so off to bed, but maybe we throw it at the wall and see if it sticks.
Will read up on the process.

Sounds like a journey, but I'm betting it's a shorter one than HACS at the mo'...
We got this.

I've removed the self-signed certs to stop GitGuardian complaining about them. The sim creates the cert if required on startup.

The hard limit validation oopsie would have been caught by the unit test had I also looked for an expected positive outcome going wrong instead of expecting the worst from bad input. I did not. The unit test failed everyone.
It sailed through without a care in the world. It does not now.

So I am kind-of guessing re. #227. I am only led by the exception.
The latest commit catches the very first exception regarding 'index' and then bluntly refuses to start the integration with an inferance of a corrupt solcast.json file reported. It might prevent issues raised, but more likely will improve sit. rep. and avoid an exploded log with a bunch of knock-on bad stuff happening.
I thought about doing something fancier, but fancier would have required a LOT more input as to the situation, and a LOT more testing. I am not in the mood for testing. And I have no input. So it is what it is for now.

So I am kind-of guessing re. #227.

I am kind-of guessing that some ancient installs - possibly manual, non-HACS, have been upgraded, and they are the cause of the last few issues like this.

Kind-of not, I'm tipping.
The log indicated a usage cache load, with a count of two for API used, so must be a relatively recent version. Last reset was within twenty-four hours. This might have been from a prior start attempt, but there are two sites, so if anything API used should be four calls, given history load on fresh start. Unless the second site failed to load...
I got nothin' but conjecture.
2024-12-08 19:54:24.881 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Usage cache exists for ******Zr-mpU
2024-12-08 19:54:24.888 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Usage cache for ******Zr-mpU last reset 2024-12-08 01:00:00
2024-12-08 19:54:24.888 INFO (MainThread) [custom_components.solcast_solar.solcastapi] Usage loaded
2024-12-08 19:54:24.889 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] API counter for ******Zr-mpU is 2/10
2024-12-08 19:54:24.889 DEBUG (MainThread) [custom_components.solcast_solar] UTC times are converted to Europe/Berlin

Kind-of not, I'm tipping.

Ahh, I did squint at the log on my phone after I carefully picked up my specs case, left home, and discovered that I had left me specs at home, but didn't spot that.

Further fun with unit tests. test_solcastapi.py.
Just uncovered a bug: Turning off detailed half-hourly attribute with detailed hourly enabled results in a puff of virtual magic smoke.
(ha-venv) vscode ➜ /workspaces/…/tests/components/solcast_solar $ pytest -o log_cli=true --log-cli-level=DEBUG -vv
Test session starts (platform: linux, Python 3.12.7, pytest 8.3.3, pytest-sugar 1.0.0)
cachedir: .pytest_cache
rootdir: /workspaces/homeAssistant-core
configfile: pyproject.toml
plugins: github-actions-annotate-failures-0.2.0, sugar-1.0.0, pytest_freezer-0.4.8, cov-5.0.0, syrupy-4.7.1, picked-0.5.0, timeout-2.3.1, socket-0.7.0, respx-0.21.1, aiohttp-1.0.5, xdist-3.6.1, asyncio-0.24.0, requests-mock-1.12.1, unordered-0.6.1, anyio-4.6.0
asyncio: mode=Mode.AUTO, default_loop_scope=function
collected 16 items

 tests/components/solcast_solar/test_config_flow.py::test_create_entry ✓                                                                                6% ▋
 tests/components/solcast_solar/test_config_flow.py::test_api_key ✓                                                                                12% █▍
 tests/components/solcast_solar/test_config_flow.py::test_api_quota ✓                                                                                19% █▉
 tests/components/solcast_solar/test_config_flow.py::test_option_api_key ✓                                                                                25% ██▌
 tests/components/solcast_solar/test_config_flow.py::test_option_api_quota ✓                                                                                31% ███▎
 tests/components/solcast_solar/test_config_flow.py::test_option_custom_hour_sensor ✓                                                                                38% ███▊
 tests/components/solcast_solar/test_config_flow.py::test_option_hard_limit ✓                                                                                44% ████▍
 tests/components/solcast_solar/test_solcastapi.py::test_forecast_update ✓                                                                                50% █████
 tests/components/solcast_solar/test_solcastapi.py::test_build_splines ✓                                                                                56% █████▋
 tests/components/solcast_solar/test_solcastapi.py::test_get_total_energy_forecast ✓                                                                                62% ██████▍
 tests/components/solcast_solar/test_solcastapi.py::test_get_peaks ✓                                                                                69% ██████▉
 tests/components/solcast_solar/test_solcastapi.py::test_get_power_n_minutes ✓                                                                                75% ███████▌
 tests/components/solcast_solar/test_solcastapi.py::test_get_forecast_n_hour ✓                                                                                81% ████████▎
 tests/components/solcast_solar/test_solcastapi.py::test_get_forecast_custom_hours ✓                                                                                88% ████████▊
 tests/components/solcast_solar/test_solcastapi.py::test_get_forecast_remaining_today ✓                                                                                94% █████████▍
 tests/components/solcast_solar/test_solcastapi.py::test_get_forecast_day ✓                                                                                100% ██████████

Results (0.63s):
      16 passed

Just uncovered a bug: Turning off detailed half-hourly attribute with detailed hourly enabled results in a puff of virtual magic smoke.

Visible to the naked eye, or only under the magnification of the debug microscope?

A most visible display of public smoke.

Unit testing for the win again.
Another related nasty expunged.

Should reduce log noise (and therefore close #229)

The first 429s I've seen for quite a while. Almost bang on the hour, but.
Slooow successful first site fetch, then several retries on second leading to meh, success. Text book modern era robust integration stuff. Yay us.
Everyone in our community has accomplished a lot this year, turning tissue paper that used to boil my piss at times into something robust and fully featured, and reducing issue reports to almost exclusively weird stuff. Thanks for picking up this repo and being its champion.
Festive greetings to you and yours, @BJReplay. I'm getting in early should I not have need to touch base closer to the little baby Jesus b'day. 🎄
2024-12-20 17:00:16.472 INFO (MainThread) [custom_components.solcast_solar.coordinator] Auto update forecast
2024-12-20 17:00:16.472 DEBUG (MainThread) [custom_components.solcast_solar.coordinator] Started task pending_update_016
2024-12-20 17:00:16.472 DEBUG (MainThread) [custom_components.solcast_solar.coordinator] Checking for stale usage cache
2024-12-20 17:00:16.472 INFO (MainThread) [custom_components.solcast_solar.solcastapi] Getting forecast update for site b68d-c05a-c2b3-2cf9
2024-12-20 17:00:16.472 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Polling API for site b68d-c05a-c2b3-2cf9, last day 2024-12-27, 175 hours
2024-12-20 17:00:16.472 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetching forecast
2024-12-20 17:00:22.597 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetch data url https://api.solcast.com.au/rooftop_sites/b68d-c05a-c2b3-2cf9/forecasts?format=json&api_key=******NV8ggJ&hours=175
2024-12-20 17:00:22.597 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] API returned data, API counter incremented from 2 to 3
2024-12-20 17:00:22.597 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Writing API usage cache file: /config/solcast-usage.json
2024-12-20 17:00:22.606 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] HTTP session status 200/Success
2024-12-20 17:00:22.606 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task fetch_data took 6.133 seconds
2024-12-20 17:00:22.606 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] 350 records returned
2024-12-20 17:00:22.615 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task load_new_data took 0.009 seconds
2024-12-20 17:00:22.617 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task apply_dampening took 0.003 seconds
2024-12-20 17:00:22.713 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task sort_and_prune took 0.095 seconds
2024-12-20 17:00:22.713 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Forecasts dictionary length 12141 (1056 un-dampened)
2024-12-20 17:00:22.714 INFO (MainThread) [custom_components.solcast_solar.solcastapi] Getting forecast update for site 83d5-ab72-2a9a-2397
2024-12-20 17:00:22.714 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Polling API for site 83d5-ab72-2a9a-2397, last day 2024-12-27, 175 hours
2024-12-20 17:00:22.714 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetching forecast
2024-12-20 17:00:22.724 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetch data url https://api.solcast.com.au/rooftop_sites/83d5-ab72-2a9a-2397/forecasts?format=json&api_key=******NV8ggJ&hours=175
2024-12-20 17:00:22.725 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] Call status 429/Try again later, pausing 17 seconds before retry
2024-12-20 17:00:39.726 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetching forecast
2024-12-20 17:00:39.762 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetch data url https://api.solcast.com.au/rooftop_sites/83d5-ab72-2a9a-2397/forecasts?format=json&api_key=******NV8ggJ&hours=175
2024-12-20 17:00:39.762 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] Call status 429/Try again later, pausing 42 seconds before retry
2024-12-20 17:01:21.763 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetching forecast
2024-12-20 17:01:21.820 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetch data url https://api.solcast.com.au/rooftop_sites/83d5-ab72-2a9a-2397/forecasts?format=json&api_key=******NV8ggJ&hours=175
2024-12-20 17:01:21.820 WARNING (MainThread) [custom_components.solcast_solar.solcastapi] Call status 429/Try again later, pausing 51 seconds before retry
2024-12-20 17:02:12.820 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetching forecast
2024-12-20 17:02:13.419 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetch data url https://api.solcast.com.au/rooftop_sites/83d5-ab72-2a9a-2397/forecasts?format=json&api_key=******NV8ggJ&hours=175
2024-12-20 17:02:13.419 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] API returned data, API counter incremented from 3 to 4
2024-12-20 17:02:13.419 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Writing API usage cache file: /config/solcast-usage.json
2024-12-20 17:02:13.440 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] HTTP session status 200/Success
2024-12-20 17:02:13.441 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task fetch_data took 110.726 seconds
2024-12-20 17:02:13.441 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] 351 records returned
2024-12-20 17:02:13.447 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task load_new_data took 0.006 seconds
2024-12-20 17:02:13.449 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task apply_dampening took 0.002 seconds
2024-12-20 17:02:13.545 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task sort_and_prune took 0.095 seconds
2024-12-20 17:02:13.545 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Forecasts dictionary length 12141 (1056 un-dampened)
2024-12-20 17:02:13.698 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task build_data took 0.153 seconds
2024-12-20 17:02:13.744 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Forecast data from 2024-12-20 to 2024-12-27 contains all intervals
2024-12-20 17:02:13.751 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task recalculate_splines took 0.007 seconds
2024-12-20 17:02:13.875 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Saved dampened forecast cache
2024-12-20 17:02:13.889 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Saved un-dampened forecast cache
2024-12-20 17:02:13.889 INFO (MainThread) [custom_components.solcast_solar.solcastapi] Forecast update completed successfully, next auto update at 2024-12-21 05:52:10
2024-12-20 17:02:13.904 DEBUG (MainThread) [custom_components.solcast_solar.coordinator] Completed task pending_update_016

Thanks for all your amazing efforts, @autoSteve - I would have just been picking up pieces from the floor every time it broke without you.
I just checked my logs - no 429s, but I did have a cache reset stale.
That said, it could be because I've now got watchtower somewhat aggressively updating images, and it did update homeassistant so that might be the cause - but I only notices because I just went looking for 429s:
homeassistant  | 2024-12-19 11:00:14.818 DEBUG (MainThread) [custom_components.solcast_solar.coordinator] Create task pending_update_239
homeassistant  | 2024-12-19 11:03:48.984 DEBUG (MainThread) [custom_components.epa_victoria_air_quality.coordinator] Finished fetching epa_victoria_air_quality data in 0.103 seconds (success: True)
homeassistant  | 2024-12-19 11:04:25.137 INFO (MainThread) [custom_components.solcast_solar.coordinator] Auto update forecast
homeassistant  | 2024-12-19 11:04:25.138 DEBUG (MainThread) [custom_components.solcast_solar.coordinator] Started task pending_update_239
homeassistant  | 2024-12-19 11:04:25.138 DEBUG (MainThread) [custom_components.solcast_solar.coordinator] Checking for stale usage cache
homeassistant  | 2024-12-19 11:04:25.138 WARNING (MainThread) [custom_components.solcast_solar.coordinator] Usage cache reset time is stale, last reset was more than 24-hours ago, resetting API usage
homeassistant  | 2024-12-19 11:04:25.146 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Writing API usage cache file: /config/solcast-usage.json
homeassistant  | 2024-12-19 11:04:25.154 WARNING (MainThread) [custom_components.solcast_solar.coordinator] Restarting midnight UTC timer
homeassistant  | 2024-12-19 11:04:25.154 DEBUG (MainThread) [custom_components.solcast_solar.coordinator] Cancelled task midnight_update
homeassistant  | 2024-12-19 11:04:25.154 DEBUG (MainThread) [custom_components.solcast_solar.coordinator] Started task midnight_update
homeassistant  | 2024-12-19 11:04:25.155 INFO (MainThread) [custom_components.solcast_solar.solcastapi] Getting forecast update for site a546-98c5-53c5-d101
homeassistant  | 2024-12-19 11:04:25.155 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Polling API for site a546-98c5-53c5-d101, last day 2024-12-26, 181 hours
homeassistant  | 2024-12-19 11:04:25.155 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetching forecast
homeassistant  | 2024-12-19 11:04:25.804 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Fetch data url https://api.solcast.com.au/rooftop_sites/a546-98c5-53c5-d101/forecasts?format=json&api_key=******bvvHxW&hours=181
homeassistant  | 2024-12-19 11:04:25.804 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] API returned data, API counter incremented from 0 to 1
homeassistant  | 2024-12-19 11:04:25.804 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Writing API usage cache file: /config/solcast-usage.json
homeassistant  | 2024-12-19 11:04:25.826 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] HTTP session status 200/Success
homeassistant  | 2024-12-19 11:04:25.827 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task fetch_data took 0.672 seconds
homeassistant  | 2024-12-19 11:04:25.827 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] 363 records returned
homeassistant  | 2024-12-19 11:04:25.843 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task load_new_data took 0.016 seconds
homeassistant  | 2024-12-19 11:04:25.846 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task apply_dampening took 0.003 seconds
homeassistant  | 2024-12-19 11:04:25.989 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task sort_and_prune took 0.143 seconds
homeassistant  | 2024-12-19 11:04:25.989 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Forecasts dictionary length 5805 (1056 un-dampened)
homeassistant  | 2024-12-19 11:04:26.066 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task build_data took 0.075 seconds
homeassistant  | 2024-12-19 11:04:26.097 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Forecast data from 2024-12-19 to 2024-12-26 contains all intervals
homeassistant  | 2024-12-19 11:04:26.105 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Task recalculate_splines took 0.008 seconds
homeassistant  | 2024-12-19 11:04:26.137 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Saved dampened forecast cache
homeassistant  | 2024-12-19 11:04:26.145 DEBUG (MainThread) [custom_components.solcast_solar.solcastapi] Saved un-dampened forecast cache
homeassistant  | 2024-12-19 11:04:26.145 INFO (MainThread) [custom_components.solcast_solar.solcastapi] Forecast update completed successfully, next auto update at 11:48:34
homeassistant  | 2024-12-19 11:04:26.165 DEBUG (MainThread) [custom_components.solcast_solar.coordinator] Completed task pending_update_239

Enjoy your festivus however you choose to.  I'm just finishing up writing a PIR because there is no rest for the wicked.

Caches during testing get created at tests/testing_config and not config. They are cleaned up at the conclusion of each test using __init__.async_cleanup_integration_tests().
I am still on the hunt for code that is not exercised. The current set of tests hit heaps of code paths (excepting Solcast API failure), and where specific asserts might be missing there are catch-all assertions that the log is error free.
Me like.

The pytest coverage report is your friend to find un-exercised code, BTW.
(ha-venv) vscode ➜ /workspaces/…/tests/components/solcast_solar $ pytest  --cov=homeassistant.components.solcast_solar --cov-report term-missing -vv
Test session starts (platform: linux, Python 3.12.8, pytest 8.3.3, pytest-sugar 1.0.0)
cachedir: .pytest_cache
rootdir: /workspaces/homeAssistant-core
configfile: pyproject.toml
plugins: github-actions-annotate-failures-0.2.0, sugar-1.0.0, pytest_freezer-0.4.8, cov-5.0.0, syrupy-4.7.1, picked-0.5.0, timeout-2.3.1, socket-0.7.0, respx-0.21.1, aiohttp-1.0.5, xdist-3.6.1, asyncio-0.24.0, requests-mock-1.12.1, unordered-0.6.1, anyio-4.6.0
asyncio: mode=Mode.AUTO, default_loop_scope=function
collected 19 items

 tests/components/solcast_solar/test_config_flow.py::test_create_entry ✓                                                                                5% ▌
 tests/components/solcast_solar/test_config_flow.py::test_api_key ✓                                                                                11% █▏
 tests/components/solcast_solar/test_config_flow.py::test_api_quota ✓                                                                                16% █▋
 tests/components/solcast_solar/test_config_flow.py::test_option_api_key ✓                                                                                21% ██▏
 tests/components/solcast_solar/test_config_flow.py::test_option_api_quota ✓                                                                                26% ██▋
 tests/components/solcast_solar/test_config_flow.py::test_option_custom_hour_sensor ✓                                                                                32% ███▎
 tests/components/solcast_solar/test_config_flow.py::test_option_hard_limit ✓                                                                                37% ███▊
 tests/components/solcast_solar/test_config_flow.py::test_entry_options_upgrade ✓                                                                                42% ████▎
 tests/components/solcast_solar/test_diagnostics.py::test_diagnostics ✓                                                                                47% ████▊
 tests/components/solcast_solar/test_energy.py::test_energy_data ✓                                                                                53% █████▍
 tests/components/solcast_solar/test_init.py::test_init[input0] ✓                                                                                58% █████▊
 tests/components/solcast_solar/test_init.py::test_init[input1] ✓                                                                                63% ██████▍
 tests/components/solcast_solar/test_init.py::test_init[input2] ✓                                                                                68% ██████▉
 tests/components/solcast_solar/test_init.py::test_remaining_actions ✓                                                                                74% ███████▍
 tests/components/solcast_solar/test_select.py::test_select_change_value[0-estimate-forecast_today-42.552] ✓                                                                                79% ███████▉
 tests/components/solcast_solar/test_select.py::test_select_change_value[1-estimate10-forecast_today-35.46] ✓                                                                                84% ████████▌
 tests/components/solcast_solar/test_select.py::test_select_change_value[2-estimate90-forecast_today-47.28] ✓                                                                                89% ████████▉
 tests/components/solcast_solar/test_sensor.py::test_sensor_states[1-settings0] ✓                                                                                95% █████████▌
 tests/components/solcast_solar/test_sensor.py::test_sensor_states[2-settings1] ✓                                                                                100% ██████████

---------- coverage: platform linux, python 3.12.8-final-0 -----------
Name                                                                                Stmts   Miss  Cover   Missing
----------------------------------------------------------------------------------------------------------------------
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/__init__.py          412     76    82%   114-115, 128-129, 132, 197, 225-238, 254-259, 262-265, 307-308, 317, 321, 384-385, 390, 410, 413, 423, 430-432, 434, 455-459, 463, 476-477, 482, 500, 505, 511, 524, 526, 545-546, 596, 607, 624-625, 639-640, 645, 648-650, 681, 717, 745-749, 800-806, 836-838
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/config_flow.py       175     43    75%   85, 100-102, 108-122, 136, 139, 185-197, 258, 262, 281, 306-309, 371-386
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/const.py              46      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/coordinator.py       295     81    73%   127-129, 135, 138, 143-146, 153, 157-169, 177-185, 188-199, 208-218, 220, 223-228, 232-238, 242-246, 265-266, 322, 352-353, 362-364, 401, 411, 470, 472, 495, 497, 518-519, 526-527
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/diagnostics.py        17      1    94%   36
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/energy.py             15      3    80%   29-30, 35
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/recorder.py            5      1    80%   10
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/select.py             46      2    96%   71-72
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/sensor.py            172     28    84%   378-380, 383, 412-414, 426-428, 462, 466-468, 470, 473, 527-529, 561, 578-580, 611, 615-618
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/sim/__init__.py        0      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/sim/simulate.py       27      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/sim/wsgi.py          197    197     0%   42-354
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/solcastapi.py       1595    471    70%   84-86, 134, 142-148, 152-154, 158, 174, 176, 508-509, 513-517, 519-521, 530-532, 550, 600-603, 617-621, 623-624, 631-637, 641-663, 686-737, 762-764, 769-770, 787-788, 797, 799-805, 820-832, 843-845, 854-859, 878-879, 883-887, 917-925, 967-968, 1000-1003, 1024-1032, 1038-1039, 1056-1078, 1096, 1125-1130, 1132-1137, 1139-1140, 1151-1158, 1162-1163, 1180-1181, 1218-1235, 1249, 1265, 1341-1362, 1390-1392, 1397-1398, 1431-1432, 1472-1481, 1499, 1503-1504, 1507-1509, 1533, 1547-1549, 1600, 1615, 1660, 1669, 1678, 1716-1726, 1743, 1766, 1782-1783, 2013-2014, 2046, 2048, 2130-2131, 2137-2138, 2163-2165, 2183-2185, 2225-2237, 2239, 2251-2257, 2289, 2307-2313, 2339-2354, 2387-2408, 2424-2426, 2445, 2452, 2470-2493, 2495, 2517-2526, 2528-2530, 2540, 2571-2586, 2601-2609, 2621-2622, 2655, 2664-2665, 2677-2678, 2680, 2683-2684, 2686, 2742-2743, 2759-2760, 2762-2766, 2771-2775, 2784-2788, 2802-2803, 2819-2820, 2823-2824, 2828-2829, 2839-2843, 2916, 2918-2919, 2943-3107, 3134-3135, 3143, 3168, 3233, 3269-3275, 3366-3367, 3394-3397, 3450, 3466, 3471, 3481, 3483-3493, 3501-3505
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/spline.py             64      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/system_health.py      10     10     0%   3-22
----------------------------------------------------------------------------------------------------------------------
TOTAL                                                                                3076    913    70%

Results (10.09s):
      19 passed

Is it reasonable to expect to get to 100% coverage?  Or even "expected" in terms of form?
For example, I wouldn't have thought that 3-13 in system_helath.py needed any testing coverage, nor 29-30 (assuming 28 does) or 35 (assuming 34 does) in energy.py.  As I couldn't see recorder.py at all in the branch on github, I assume that yet isn't committed 🤣

couldn't see recorder.py

Lols. That's right... I got rid of it. It's still on me dev repo. 😂
It is reasonable to have good coverage because it saves you and I and others testing time.

Bronze: 100% coverage for the config/options flows
Silver: Above 95% test coverage according to one bit of doco. Above average test coverage noted elsewhere.
Gold: Full automated test coverage of its codebase.
Platinum: Per gold.

An assigned quality scale is a technicality. My aim is to address the glaring gaps that represent a higher risk, and improve the coverage over time.
A good example of this is that our sensors are rigged to return zero should things turn to custard, which is not the way things should be. We have both seen this reported many times. "It broke and now all my values are zero!" The sensors should instead show as 'unavailable' if a value cannot be returned. Testing so far has highlighted this by not being able to test certain exception conditions because the test method I tried blows up because the code "works", but is dodgy from an HA POV.

The sensors should instead show as 'unavailable' if a value cannot be returned.

Yeah, I sort of get that, but at the same time, I'm not sure that I agree, completely.
I sort of prefer a boolean sensor / diagnostic which can be used to know if all is good or not.
I guess it depends on what the sensor is.
But having said all that, I'm neither a python nor a home assistant style expert.
However, this is the side effect of a sensor becoming unavailable instead of an empty string or a zero count on the warnings entity:
Code that attempts to access warnings.count fails if warnings is unavailable, which it sometimes is (but not always - sometimes it is there, but with a zero count), so the ugly template has three tests queued up before the one to actually look for the one that should be true most of the time - is the number of weather warnings < 1 - if so, report "No Warnings".
{% if (states("sensor.st_kilda_west_warnings") not in ["unavailable", "none", "unknown"]) and (states("sensor.st_kilda_west_warnings") and ((state_attr("sensor.st_kilda_west_warnings", "warnings") | count) < 1 )) %}
  {{"No Warnings"}}
{% else %}
  {{ state_attr("sensor.st_kilda_west_warnings" , "warnings") [0].short_title }}
{% endif %}

This is pretty satisfying.
Near 100% code test coverage. So to-do is improve the scenarios over time instead if there are gaps. I'm pretty sure there are very few gaps now...
There are two lines that fail to be exercised. These relate to sensors never becoming unavailable. I'm yet to further consider the implications of that design choice by our predecessors.
There are many except blocks that I have excluded from coverage because they're only going to be hit if there is a code defect. These would be hit during a test on encountering a code defect, so coverage reporting is unnecessary noise.
I also needed to exclude code that is substituted under testing conditions. Things like getting the current date/time, and the forecast fetch itself because no requests calls can be made using pytest. This code gets tested when running with the wsgi "live" REST simulator instead. (A future possibility is to extend the approach used to test system_health.py to simulate requests responses, which would be cool, but would get gnarly. Deprecation warning for that approach until I can think of a better way...)
(ha-venv) vscode ➜ /workspaces/…/tests/components/solcast_solar $ pytest --cov=homeassistant.components.solcast_solar --cov-report term-missing -vv
Test session starts (platform: linux, Python 3.12.8, pytest 8.3.3, pytest-sugar 1.0.0)
cachedir: .pytest_cache
rootdir: /workspaces/homeAssistant-core
configfile: pyproject.toml
plugins: github-actions-annotate-failures-0.2.0, sugar-1.0.0, pytest_freezer-0.4.8, cov-5.0.0, syrupy-4.7.1, picked-0.5.0, timeout-2.3.1, socket-0.7.0, respx-0.21.1, aiohttp-1.0.5, xdist-3.6.1, asyncio-0.24.0, requests-mock-1.12.1, unordered-0.6.1, anyio-4.6.0
asyncio: mode=Mode.AUTO, default_loop_scope=function
collected 24 items

 tests/components/solcast_solar/test_config_flow.py::test_single_instance ✓                                                                                4% ▌
 tests/components/solcast_solar/test_config_flow.py::test_create_entry ✓                                                                                8% ▉
 tests/components/solcast_solar/test_config_flow.py::test_api_key ✓                                                                                12% █▍
 tests/components/solcast_solar/test_config_flow.py::test_api_quota ✓                                                                                17% █▋
 tests/components/solcast_solar/test_config_flow.py::test_option_api_key ✓                                                                                21% ██▏
 tests/components/solcast_solar/test_config_flow.py::test_option_api_quota ✓                                                                                25% ██▌
 tests/components/solcast_solar/test_config_flow.py::test_option_custom_hour_sensor ✓                                                                                29% ██▉
 tests/components/solcast_solar/test_config_flow.py::test_option_hard_limit ✓                                                                                33% ███▍
 tests/components/solcast_solar/test_config_flow.py::test_step_to_dampen ✓                                                                                38% ███▊
 tests/components/solcast_solar/test_config_flow.py::test_dampen ✓                                                                                42% ████▎
 tests/components/solcast_solar/test_config_flow.py::test_entry_options_upgrade ✓                                                                                46% ████▋
 tests/components/solcast_solar/test_diagnostics.py::test_diagnostics ✓                                                                                50% █████
 tests/components/solcast_solar/test_energy.py::test_energy_data ✓                                                                                54% █████▌
 tests/components/solcast_solar/test_init.py::test_init[options0] ✓                                                                                58% █████▉
 tests/components/solcast_solar/test_init.py::test_init[options1] ✓                                                                                62% ██████▍
 tests/components/solcast_solar/test_init.py::test_init[options2] ✓                                                                                67% ██████▋
 tests/components/solcast_solar/test_init.py::test_remaining_actions ✓                                                                                71% ███████▏
 tests/components/solcast_solar/test_init.py::test_scenarios ✓                                                                                75% ███████▌
 tests/components/solcast_solar/test_select.py::test_select_change_value[0-estimate-forecast_today-42.552] ✓                                                                                79% ███████▉
 tests/components/solcast_solar/test_select.py::test_select_change_value[1-estimate10-forecast_today-35.46] ✓                                                                                83% ████████▍
 tests/components/solcast_solar/test_select.py::test_select_change_value[2-estimate90-forecast_today-47.28] ✓                                                                                88% ████████▊
 tests/components/solcast_solar/test_sensor.py::test_sensor_states[1-settings0] ✓                                                                                92% █████████▎
 tests/components/solcast_solar/test_sensor.py::test_sensor_states[2-settings1] ✓                                                                                96% █████████▋
 tests/components/solcast_solar/test_system_health.py::test_system_health ✓                                                                                100% ██████████
====================================================================================================================================================== warnings summary ======================================================================================================================================================
tests/components/solcast_solar/test_system_health.py::test_system_health
  /workspaces/homeAssistant-core/tests/components/solcast_solar/__init__.py:276: DeprecationWarning: Setting custom ClientSession._request attribute is discouraged
    base._request = _request

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html

---------- coverage: platform linux, python 3.12.8-final-0 -----------
Name                                                                                Stmts   Miss  Cover   Missing
----------------------------------------------------------------------------------------------------------------------
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/__init__.py          347      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/config_flow.py       132      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/const.py              46      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/coordinator.py       213      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/diagnostics.py        17      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/energy.py             13      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/select.py             42      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/sensor.py            145      2    99%   375, 457
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/solcastapi.py       1050      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/spline.py             64      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/system_health.py      11      0   100%
----------------------------------------------------------------------------------------------------------------------
TOTAL                                                                                2080      2    99%

Results (12.83s):
      24 passed

While test coverage may now be 💯% without "cheating" with pragma: notest for the outstanding misses, I am still to naval-gaze unavailable sensors in case of exceptions.
Test scenarios have been bolstered as well.
Name                                                                                Stmts   Miss  Cover   Missing
----------------------------------------------------------------------------------------------------------------------
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/__init__.py          347      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/config_flow.py       132      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/const.py              46      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/coordinator.py       213      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/diagnostics.py        17      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/energy.py             13      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/select.py             42      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/sensor.py            147      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/solcastapi.py       1048      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/spline.py             64      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/system_health.py      11      0   100%
----------------------------------------------------------------------------------------------------------------------
TOTAL                                                                                2080      0   100%

Deprecation warning for the patch-aiohttp-client-session approach be damned. I can't think of a better way right now...
All API calls are now tested without monkey-patching in substitute functions in SolcastApi. It only got a little bit gnarly. 😂
Now tested for are 429s and exceptions in sites load, 401 invalid key responses, plus API limit exhaustion. And misc other goodies.
Next thing on the list is to remove the retry mechanism in get sites. I changed the init sequence a while back to prevent integration load if the sites fail to get, and Home Assistant automatically retries a load with a back-off mechanism. All retrying in the integration does is to slow down the Home Assistant restart sequence should a dodgy integration config be in place and forgotten about/ignored.

Deprecation warning for the patch-aiohttp-client-session approach be damned.

I hadn't seen that (at least in debug logs) - I assume it is a ruff warning?
I have seen 429s at 20:00 ADST last two days, (two retries each night) and cache stale warnings at UTC midnight last two days, which is interesting, but then again, I'm running old code 🤣

cache stale warnings

This is very interesting. Almost never happens to my prod rig, and never dev. You have weirdo scheduling (because Docker?), with stuff not happening exactly when it should and I wonder if that is somehow implicated. Unlikely, but it's the only thing I can think of.
Feeling quite smug that I incorporated a stale check, as it sounds like you are my # 1 customer...

Deprecation warning

Only seen under pytest.
If the core folk get ansey then they can tell me how to avoid it!
(ha-venv) vscode ➜ /workspaces/…/tests/components/solcast_solar $ pytest --cov=homeassistant.components.solcast_solar --cov-report term-missing -vv
Test session starts (platform: linux, Python 3.12.8, pytest 8.3.3, pytest-sugar 1.0.0)
cachedir: .pytest_cache
rootdir: /workspaces/homeAssistant-core
configfile: pyproject.toml
plugins: github-actions-annotate-failures-0.2.0, sugar-1.0.0, pytest_freezer-0.4.8, cov-5.0.0, syrupy-4.7.1, picked-0.5.0, timeout-2.3.1, socket-0.7.0, respx-0.21.1, aiohttp-1.0.5, xdist-3.6.1, asyncio-0.24.0, requests-mock-1.12.1, unordered-0.6.1, anyio-4.6.0
asyncio: mode=Mode.AUTO, default_loop_scope=function
collected 27 items

 tests/components/solcast_solar/test_config_flow.py::test_single_instance ✓                                                                                4% ▍
 tests/components/solcast_solar/test_config_flow.py::test_create_entry ✓                                                                                7% ▊
 tests/components/solcast_solar/test_config_flow.py::test_api_key ✓                                                                                11% █▎
 tests/components/solcast_solar/test_config_flow.py::test_api_quota ✓                                                                                15% █▌
 tests/components/solcast_solar/test_config_flow.py::test_option_api_key ✓                                                                                19% █▉
 tests/components/solcast_solar/test_config_flow.py::test_option_api_quota ✓                                                                                22% ██▎
 tests/components/solcast_solar/test_config_flow.py::test_option_custom_hour_sensor ✓                                                                                26% ██▋
 tests/components/solcast_solar/test_config_flow.py::test_option_hard_limit ✓                                                                                30% ██▉
 tests/components/solcast_solar/test_config_flow.py::test_step_to_dampen ✓                                                                                33% ███▍
 tests/components/solcast_solar/test_config_flow.py::test_dampen ✓                                                                                37% ███▊
 tests/components/solcast_solar/test_config_flow.py::test_entry_options_upgrade ✓                                                                                41% ████▏
 tests/components/solcast_solar/test_diagnostics.py::test_diagnostics ✓                                                                                44% ████▌
 tests/components/solcast_solar/test_energy.py::test_energy_data ✓                                                                                48% ████▊
 tests/components/solcast_solar/test_init.py::test_api_failure ✓                                                                                52% █████▎
 tests/components/solcast_solar/test_init.py::test_init[options0] ✓                                                                                56% █████▋
 tests/components/solcast_solar/test_init.py::test_init[options1] ✓                                                                                59% █████▉
 tests/components/solcast_solar/test_init.py::test_init[options2] ✓                                                                                63% ██████▍
 tests/components/solcast_solar/test_init.py::test_init[options3] ✓                                                                                67% ██████▋
 tests/components/solcast_solar/test_init.py::test_remaining_actions ✓                                                                                70% ███████▏
 tests/components/solcast_solar/test_init.py::test_scenarios ✓                                                                                74% ███████▌
 tests/components/solcast_solar/test_select.py::test_select_change_value[0-estimate-forecast_today-42.552] ✓                                                                                78% ███████▊
 tests/components/solcast_solar/test_select.py::test_select_change_value[1-estimate10-forecast_today-35.46] ✓                                                                                81% ████████▎
 tests/components/solcast_solar/test_select.py::test_select_change_value[2-estimate90-forecast_today-47.28] ✓                                                                                85% ████████▌
 tests/components/solcast_solar/test_sensor.py::test_sensor_states[1-settings0] ✓                                                                                89% ████████▉
 tests/components/solcast_solar/test_sensor.py::test_sensor_states[2-settings1] ✓                                                                                93% █████████▍
 tests/components/solcast_solar/test_sensor.py::test_sensor_unknown ✓                                                                                96% █████████▋
 tests/components/solcast_solar/test_system_health.py::test_system_health ✓                                                                                100% ██████████
====================================================================================================================================================== warnings summary ======================================================================================================================================================
tests/components/solcast_solar/test_config_flow.py: 2 warnings
tests/components/solcast_solar/test_diagnostics.py: 1 warning
tests/components/solcast_solar/test_energy.py: 1 warning
tests/components/solcast_solar/test_init.py: 16 warnings
tests/components/solcast_solar/test_select.py: 3 warnings
tests/components/solcast_solar/test_sensor.py: 3 warnings
tests/components/solcast_solar/test_system_health.py: 1 warning
  /workspaces/homeAssistant-core/tests/components/solcast_solar/__init__.py:327: DeprecationWarning: Setting custom ClientSession._request attribute is discouraged
    base._request = _request  # Will generate a deprecation warning

-- Docs: https://docs.pytest.org/en/stable/how-to/capture-warnings.html

---------- coverage: platform linux, python 3.12.8-final-0 -----------
Name                                                                                Stmts   Miss  Cover   Missing
----------------------------------------------------------------------------------------------------------------------
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/__init__.py          346      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/config_flow.py       130      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/const.py              46      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/coordinator.py       211      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/diagnostics.py        17      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/energy.py             13      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/select.py             42      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/sensor.py            147      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/solcastapi.py       1141      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/spline.py             64      0   100%
/workspaces/homeAssistant-core/homeassistant/components/solcast_solar/system_health.py      11      0   100%
----------------------------------------------------------------------------------------------------------------------
TOTAL                                                                                2168      0   100%

Results (15.63s):
      27 passed


use spaced en-dash instead of spaced hyphen

I'm not sure if such patches dealing with punctuation style are welcome or not. I base my preference for dashes on English Wikipedia's Manual of Style:

Punctuating a sentence (em or en dashes)
Dashes are often used to mark divisions within a sentence: in pairs (parenthetical dashes, instead of parentheses or pairs of commas); or singly (perhaps instead of a colon). They may also indicate an abrupt stop or interruption, in reporting quoted speech. [...]

An em dash is unspaced (with no space on either side):

Another "planet" was detected—but it was later found to be a moon of Saturn.

An en dash is spaced (with a space on each side) when used as sentence punctuation:

Another "planet" was detected – but it was later found to be a moon of Saturn.

(permalink)

"Markdown links / check" seems to have failed, because https://opensource.org/osd doesn't like being queried too often and starts returning 503 after too many.
FILE: ./emails.md
5 links checked.
FILE: ./intro/terms.md
[✖] https://opensource.org/osd
2 links checked.
ERROR: 1 dead links found!
[✖] https://opensource.org/osd → Status: 503
[...]
FILE: ./start/license.md
[✖] https://opensource.org/
1 links checked.
ERROR: 1 dead links found!
[✖] https://opensource.org/ → Status: 503

https://github.com/bagder/uncurled/runs/6785043092?check_suite_focus=true#step:4:308

Thanks!


When I click "Become a lucky airdropee"

Hello there,
I got the issue about two months ago:

Please suggest the solution, thank you.

Exact same issue for me, in based on New Zealand and others had no issues a few days ago they said

Same issue here!

This is a known issue for a long-long time but noone can certainly say what causes it. If you check the reported issues, you can find a lot of reports, most of them closed without any help or provided information.
One of the (still) open tickets is #21055


[OPA] Unable to clone constraint

What kind of request is this (question/bug/enhancement/feature request):
Bug
Steps to reproduce (least amount of steps as possible):
Install OPA v3.3.002-rc01
Create a constraint
Clone the constraint
Result:
Cloning fails with metadata.resourceVersion is required for update

Other details that may be helpful:
Environment information

Rancher version (rancher/rancher/rancher/server image tag or shown bottom left in the UI): Rancher v2.5-head 03b8153
Installation option (single install/HA): Single install

The bug fix is verified with Rancher server rancher\rancher:v2.5-head version b4be2b2 on OPA v3.3.000-rc02
Constraints can be cloned without error.


Fixed Installation Instructions

Throws this error
fatal: repository 'github.com/jbenet/compress-pdf' does not exist
That's why updated README.md :smile:

Also see #5


Publish Swift SDK

This should aim for at least a 0.1.0 level, and is a prerequisite for #23

It's currently in a SemVer beta state, but this is complete: https://github.com/snapauthapp/sdk-swift/releases


Thanks!

Just wanted to say thanks for the excellent library. Have been using it reliably in some production code for a year or more now. :beers:

Cheers :)


refactor: fix line endings with dos2unix

Summary
fix line endings for selected files:
find -type f -exec dos2unix {} +

i think it is better to use LF (linux) line endings because application is developed under linux/mac machines :)

@mfederowicz hi thanks for contributing however I do not think these are necessary changes

@mfederowicz I think it better to discuss it first since not all are following the same before modifying all files in the codebase.

@tenshiAMD afaik there are not all files but thouse which have CRLF format, we should discuss that topic, because most of developers uses linux/mac machines and android studio/vs code :)

Good source of knowledge Article

@mfederowicz hi closing this for now. I will check and resolve this later for us to be sure about the changes. Thanks!


[FEATURE] LabelUI Customizations

Describe the solution you'd like
Allow for customizations in how labels are shown using Tadukoo Look & Feel
Is your feature request related to a problem? Please describe.
No
Describe alternatives you've considered
None
Additional context
Part of #1
TODO Changes

[ ] Create a new Tadukoo Label class extending JLabel
[ ] The following customizations need to be allowed to be set in Tadukoo Label, all of the form fields, and Tadukoo Theme, and Tadukoo Theme Factory should handle them as appropriate... and of course Tadukoo Look & Feel should set them in the defaults map

[ ] Label colors

[ ] background
[ ] foreground
[ ] disabledForeground
[ ] disabledShadow

[ ] font
[ ] border
[ ] shape?

While disabledShadow is a color set in BasicLookAndFeel for Labels, it is never used in the LabelUI classes (Metal or Basic), so we're not going to implement it in Label itself (at least not for now, maybe in the future?)

While disabledShadow is a color set in BasicLookAndFeel for Labels, it is never used in the LabelUI classes (Metal or Basic), so we're not going to implement it in Label itself (at least not for now, maybe in the future?)

Don't need disabled foreground on the Form Field's Label due to not disabling it

Don't need disabled foreground on the Form Field's Label due to not disabling it


New plugin embedLinkedImages: embed images as base64 data URIs

Clearly embedding images as base64 will make the SVG bigger, not smaller, but the SVG is still optimized in the sense that it becomes a fully self-contained resource (no external dependencies).
Embedding images has the following benefits compared to linking:

More portable (move the SVG without risk of losing images)
Fewer requests made to server / filesystem (potential speed increase)
Increased compatibility with SVG viewers (loading of external resources not always implemented)
Makes the file useable inside HTML's <img> tag (loading of external resources disallowed for security reasons)

Embedding has the following drawbacks compared to linking:

Increased file size of SVG (since images are embedded rather than separate)
Increased overall file size (base64 is inefficient compared to raw binary data)
Embedded resources don't benefit from browser caching to the same extent as linked resources

Hence this is a useful feature, but one that should probably be optional and disabled by default (though it is enabled by default in other SVG optimizers, such as Scour).

Embedding is not something you can rely on an editor to do, as you might want images to be linked in the source SVG and only embedded in the published version. This keeps the source SVG small, making it easier to keep track of in a Git repository, and edit by hand if necessary.

Not sure if svgo is the place for this task but it would certainly help our use case as well. We already optimize SVGs with svgo, and would need a way to embed external images as inline base64 versions.


Updated README.md

Changed the order of the Start Pinpoint Daemons from
Collector - Run quickstart/bin/start-collector.sh
Web UI - Run quickstart/bin/start-web.sh
TestApp - Run quickstart/bin/start-testapp.sh

TO:
Collector - Run quickstart/bin/start-collector.sh
TestApp - Run quickstart/bin/start-testapp.sh
Web UI - Run quickstart/bin/start-web.sh
Which is the correct order

@abhijith0505
Thanks for the fix.
Although Collector -> Web -> TestApp should work, your fix is more elegant as it would eliminate the possibility of the Web UI having an empty list of applications which might lead to confusion.
Thanks!

@Xylus
Pinpoint is a great open source APM. Wonderful to have it here!
Kudos to the team!

@abhijith0505 thanks.


Use Nested Namespaces resembling directory structure

This is a fix for #2752
I have started with the shogun.distance package.
There is a lot of refactoring to be done, however I'd like to know if this is the way to go.
@lisitsyn @karlnapf

@lisitsyn has to comment here. I am not sure what is the most elegant way to go ahead here

Hmm I am so sorry I missed this PR. Gonna glance over it now

Any updates here?

closing as inactive

Coverage remained the same at 100.0% when pulling 97ce2955c8be95da67f063824e975b40b30185ed on ajaybhat:namespaces into afec7f84ff014ccd58479db982b72c4cdf999848 on shogun-toolbox:develop.


Add check to only open flyout if a menubaritem has items

Description

Adds a check to only open a menubaritems flyout if it has items.
Motivation and Context

Closes #2740
How Has This Been Tested?

Tested manually:

Screenshots (if appropriate):

/azp run

/azp run


Add yaocccc/nvim-hlchunk and yaocccc/nvim-lines.lua

Checklist:

[x] The plugin is specifically built for Neovim.
[x] The lines end with a .. This is to conform to awesome-list linting and requirements.
[x] It's not already on the list.
[x] If it's a colorscheme, it supports treesitter syntax.
[x] The title of the pull request is Add `username/repo`  when adding a new plugin.
[ ] Neovim is spelled as Neovim (not nvim, NeoVim or neovim), Lua is spelled as Lua (capitalized).

ok, fixed.

Thanks for the PR!


Enable dependabot for docker

Change-type: patch

Please make sure to read the CONTRIBUTING document before opening the PR for relevant information on contributing to the documentation. Thanks!

From my understanding, dependabot will try to update https://github.com/balena-io/docs/blob/6d10aa3f910dc7cf2b55c3ecfc0e57fceadb7c05/Dockerfile#L1
Do you know if it only updates patch so we'll see PRs to FROM node:14.0.5 for example ? Since we don't have a minor and patch version I'm worried if it will try to update major version.

@20k-ultra my intention is actually to get https://github.com/balena-io/docs/pull/1955 in before this one, so that it works as you describe.
Explained that to @vipulgupta2048 in a meet, but obviously I should have noted it in the description as well.

@balena-ci rebase

@balena-ci rebase


This is a highly desirable feature for me, and I think potentially for many other folks as well. The mocha-as-promised precedent makes me think that this feature request aligns with the philosophy of Mocha and worth it to pursue.

Related: https://github.com/mochajs/mocha/pull/1575 https://github.com/mochajs/mocha/issues/1891 https://github.com/mochajs/mocha/issues/1748 https://github.com/mochajs/mocha/issues/1032

@danielstjules thanks for the info!
Looks like the main challenge was getting co to work in the browser back in March. From what I've learned digging around in the source, Mocha has switched to using browserify to build its browser version since that time, which means we are closer to getting this to work. I did a quick check to see that co actually will work with browserify as a required module and it did.
In the process of trying to start working on this, I am getting some lint errors and integration test errors from make test and make test-all. Anyone else aware of these or is it just me? I would have thought they'd be caught by CI.

Did you just checkout that branch and rebase master? The PR was opened before either linting or integration tests were added to mocha, so if you're running into issues - that's why. It could def use a refactor too. :)
In any case, I think the bigger issue is that it wasn't felt it belonged in core mocha. https://github.com/blakeembrey/co-mocha is a great alternative.

@danielstjules thanks, I figured out the issue, and have put out this PR for review. This incorporates the code in your https://github.com/mochajs/mocha/pull/1575 and @blakeembrey's https://github.com/blakeembrey/co-mocha. The tests are passing, and I have tested it in Chrome with its native generator support as well as with the Babel transpiler plus the regenerator runtime - it works in both cases. I haven't updated the browser version mocha.js because it seems out of date wrt to the source in the rest of the repo. When I did make clean; make build mocha.js, I noticed a bug that causes assertion errors to be rendered twice on the test page at test/browser/index.html. I would be happy to investigate further, but I believe this is separate from the coroutines discussion because I saw this same bug when I went back to the master branch.
To address whether this features belongs in mocha, I feel hopeful that given the precedent of promises support - it can. I have been using coroutines and generators with promises for various projects and it's been very helpful to the clarity of my code, productivity, and it's just been a joy to use. I want to share this joy and excitement with others. Back in 2014, @tj implied that generators is a more appealing feature than promises. Now that even promises has made the cut, it should be easy to make the case for generators. Having this feature be built-in to Mocha - the most popular testing framework in the ecosystem - will not only help folks get started easier, but it will also give coroutines/generators legitimacy.
To weigh the upside against the downside: similar to the addition of promises support, this change is 100% backwards compatible. It is also doesn't require any architecture change to Mocha - the change is incremental.

+1 would love to get this in, we are also using co-mocha to help with clarifying the code.

I just wanted to leave a comment about having this inside of Mocha core, instead of leaving it in user-land. I thought I'd left a more detailed comment in the past, but can't find it now. At least, my last comment looks like it was https://github.com/mochajs/mocha/issues/1748#issuecomment-112360352.
I see promises support as aligning with the future. It was, and still is, on an upward usage trajectory. Generators, however, are not. The current use is literally a hack to be make it do what async/await does out of the box. Plus, async/await already works with Mocha since they're just promises. Generators, however, should be promoted in more creative ways than just serial async code.
That said, I don't have an issue either way, but the proper implementation should go a bit further than co-mocha does and should not use the same function toString tricks on Mocha.

Indeed, I was using co-mocha and now I'm just using async/await which works fine in Mocha out of the box. No need for the generator hack…

Both TJ and Travis previously mentioned wanting to wait for async/await, and I think a compelling argument has been made in support of this. Closing for now. Thanks though!


Reloading a save makes the upgrades disappear

Reloading a save makes the upgrades disappear and I have to buy everything new, i don't know what to do to fix this :c

Without any sort of logs, I can only guess and is that an error is happening when trying to save LGU relevant data, leading to an empty/trash save file.
I have reworked a bit of the saving mechanism we use to save stuff so maybe next release this issue won't occur or at least as often.
I would like to look at the logs whenever this happens to understand if the issue will still persist.

Ooh okay ty ! if it happens again, I will send you the logs


GD-62: Add full .NET8 support

Why
We want to support the latest .NET version
What

switch to SDK 8.0.0
update runsettings to support .NET7 and .NET8
use for test and example project .NET8

@van800 Perhaps you have an idea where these warnings come from?

It is from the Godot sources, however I don't know much
https://github.com/godotengine/godot/issues?q=AD0001%3A+

@van800 Can you please take a look at this branch and check with Raider if it works?


Make the system upload information online via a server

@3vivekb

The initial challenge here is internet connectivity on our current setup, which uses a Raspberry Pi 2 (doesn't have WiFi).
We'd either need to upgrade to the Pi 3 or get a USB WiFi dongle for it.
We also need to decide where to put this information so that it's secure. I'm thinking this should be done with the Google Sheets API.

Google Sheets Api should be fine.
On Fri, Feb 23, 2018 at 11:33 AM Kyle Falconer<EMAIL_ADDRESS>wrote:

The initial challenge here is internet connectivity on our current setup,
which uses a Raspberry Pi 2 (doesn't have WiFi).
We'd either need to upgrade to the Pi 3 or get a USB WiFi dongle for it.
We also need to decide where to put this information so that it's secure.
I'm thinking this should be done with the Google Sheets API
https://developers.google.com/sheets/api/.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/codeforsanjose/CFSJ-Login-System/issues/8#issuecomment-368115944,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEUIrTEuc-7tqt3nNoGMqE38ix61yIlEks5tXxKWgaJpZM4LZTz_
.

I have a Raspberry Pi WiFi adapter you can have. I don't get to San Jose often, so send me a mail address or if someone wants to meet me in Sunnyvale I can treat you to lunch at the Microsoft office and give you the adapter.

From: Kyle Falconer<EMAIL_ADDRESS>Sent: Friday, February 23, 2018 11:33 AM
To: codeforsanjose/CFSJ-Login-System
Cc: Subscribed
Subject: Re: [codeforsanjose/CFSJ-Login-System] Make the system upload information online via a server (#8)
The initial challenge here is internet connectivity on our current setup, which uses a Raspberry Pi 2 (doesn't have WiFi).
We'd either need to upgrade to the Pi 3 or get a USB WiFi dongle for it.
We also need to decide where to put this information so that it's secure. I'm thinking this should be done with the Google Sheets APIhttps://developers.google.com/sheets/api/.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://github.com/codeforsanjose/CFSJ-Login-System/issues/8#issuecomment-368115944, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKn9cppo085vpdjYKtf8KcIF2IxcN-6oks5tXxKVgaJpZM4LZTz_.

 Unfortunately, my Thursday and Friday this week are totally full of meetings, including lunch meetings. I can leave the adapter with the receptionist, but if you want to stop by and check things out and have lunch, we'd have to push to next week.
The address for the Sunnyvale office is 1020 Enterprise Way, Sunnyvale, CA 94089

From: Emily Ann Ramos<EMAIL_ADDRESS>Sent: Thursday, March 8, 2018 8:22 PM
To: codeforsanjose/CFSJ-Login-System
Cc: kennyspade; Comment
Subject: Re: [codeforsanjose/CFSJ-Login-System] Make the system upload information online via a server (#8)
Hi Kenny! I can pick up the WiFi adapter from you! I can meet you next Friday (3/16) and I never turn down an opportunity for lunch! I thought the office was in North Bayshore, though. Did you move offices?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/codeforsanjose/CFSJ-Login-System/issues/8#issuecomment-371709573, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AKn9chl2FALMJ9bfoD8rMV4IATSsML9gks5tcgOggaJpZM4LZTz_.

I'm down to meet next week! Is 1:30 too late?

I don't think we need a wifi adapter.  It makes more sense just to build with a raspberry pi 3.  @SWLF and @Kyle-Falconer are on it.
Thanks for the offer!

This has been working since 9165b18cb8828bbd937e3f73121861add5a953e7


Kabat numbering not working with --details ?

./migmap --use-kabat --blast-dir /data/xxx/ncbi-igblast-1.6.1/bin --data-dir /data/xxx/migmap-1.0.2/data -R IGH -S human --by-read --details fr1aa,fr2aa,fr3aa,cdr1aa,cdr2aa test.txt test.kabat.txt
[Tue Mar 07 12:10:17 PST 2017 MIGMAP +00m00s] Loaded database for human IGH gene(s): 89 Variable, 37 Diversity and 6 Joining segments.
[Tue Mar 07 12:10:17 PST 2017 MIGMAP +00m00s] Creating temporary BLAST database /data/xxx/migmap-1.0.2/data/database-a06324d2-8746-4ea1-9bd3-35ae88c29cec.
[Tue Mar 07 12:10:17 PST 2017 MIGMAP +00m00s] Annotating variable segments.
[Tue Mar 07 12:10:19 PST 2017 MIGMAP +00m02s] Fully annotated 0 of 89 segments.
[Tue Mar 07 12:10:19 PST 2017 MIGMAP +00m02s] Analyzing sample test.txt
[Tue Mar 07 12:10:19 PST 2017 MIGMAP +00m02s] Started analysis
[Tue Mar 07 12:10:19 PST 2017 MIGMAP +00m02s] Loaded 159 reads.
[Tue Mar 07 12:10:24 PST 2017 MIGMAP +00m07s] Finished analysis. Processed 2000 reads, of them 100.0% mapped. Among mapped reads 42.2% passed quality filter and 29.8% passed all filters.
[Tue Mar 07 12:10:24 PST 2017 MIGMAP +00m07s] Finished.
./migmap -Xmx14G --blast-dir /data/xxx/ncbi-igblast-1.6.1/bin --data-dir /data/xxx/migmap-1.0.2/data -R IGH -S human --by-read --details fr1aa,fr2aa,fr3aa,cdr1aa,cdr2aa test.txt test.imgt.txt
[Tue Mar 07 12:10:54 PST 2017 MIGMAP +00m00s] Loaded database for human IGH gene(s): 89 Variable, 37 Diversity and 6 Joining segments.
[Tue Mar 07 12:10:54 PST 2017 MIGMAP +00m00s] Creating temporary BLAST database /data/xxx/migmap-1.0.2/data/database-3672583a-048e-4a01-9719-034d9c5a541d.
[Tue Mar 07 12:10:54 PST 2017 MIGMAP +00m00s] Annotating variable segments.
[Tue Mar 07 12:10:57 PST 2017 MIGMAP +00m02s] Fully annotated 89 of 89 segments.
[Tue Mar 07 12:10:57 PST 2017 MIGMAP +00m02s] Analyzing sample test.txt
[Tue Mar 07 12:10:57 PST 2017 MIGMAP +00m02s] Started analysis
[Tue Mar 07 12:10:57 PST 2017 MIGMAP +00m02s] Loaded 393 reads.
[Tue Mar 07 12:11:02 PST 2017 MIGMAP +00m07s] Finished analysis. Processed 2000 reads, of them 100.0% mapped. Among mapped reads 42.2% passed quality filter and 30.0% passed all filters.
[Tue Mar 07 12:11:02 PST 2017 MIGMAP +00m07s] Finished.
When comparing test.imgt.details to test.kabat.details , the fr1aa, fr2aa, fr3aa, cdr1aa, and cdr2aa sequences at the end of the tables are messed up (concatenated together, and seemingly wrong sequences).
IMGT on read SRR747768.2037:
XXQLVESGGGVVQPGRSLRLSCAAS       MHWVRQAPGKGLEWVAV       YYADSVKGRFTISRDNSKNTLYLQMNSLRAEDTAVYY   GFTFSSYG        ISYDGSNK
Kabat on read SRR747768.2037:
XXAAGGVWGRRGPAWEVPETLLCSLWIHLQ*LWHALGPPGSRQGAGVGGSYII*WK**ILCRLREGPIHHLQRQFQEHAVSANEQPES*GHGCVL
test.txt
test.imgt.txt
test.kabat.txt

Yes, I also notice this issue, any update how to solve this problem? thanks.

I ended up manually parsing the IMGT output.


Documentation of shape of theta in generating cluster maps

The documentation regarding angular radius in the iso beta model maps specifies a 2D array when any shape of array would likely work. I tested it with a 1D array and it worked perfectly. Please update the documentation accordingly

Fixed in aff9b25


UC 11: As a developer, I want to delete specific components from my application

As a developer, I want to be able to delete components with a single command.
$ ocd delete [myfrontend]
Do you really want to delete myfrontend in application <name> (y/n)?
Component myfrontend will be deleted.
This component was externally exposed, and the URL will be removed
Delete a binding to other service
Other non-essential stuff as needed
(if there is storage) Should we delete the associated storage (y/n)?

Tasks (create new issues if deferring some work):

[x] #201 If name of the component is not specified, then delete current component.
[x] If name of the component is specified, then delete specified component.
[x] #200 Delete should always ask for confirmation.
[x] Delete should show what other things get deleted as part the action
[x] If cascading delete includes storage, should again ask for removal confirmation

3/5 completed. I do agree with regards to the last two parts.
We should:

[ ] Have debugging messages indicating what is being deleted
[ ] If storage will be deleted, prompt for confirmation.

It should allow providing --force and/or -f flag for skip confirmation. This needs to be true in each subtask.

@jorgemoralespou we have a flag -f to skip confirmation in all deletion tasks

Cool, didn't notice it.

/close
all implemented


nrf_bsim: Enforce 8-byte alignments for long words

Different GNU compilers may have different aligment defaults. For example:
4 byte alignment: x86_64-zephyr-elf-gcc (Zephyr SDK 0.16.5-1) 12.2.0
8 byte alignment: gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
This can be seen when defining a struct:
typedef struct {
	uint32_t a;
	uint64_t b;
} my_struct_t;
BUILD_ASSERT(__alignof__(my_struct_t) == 8);

To ensure the nrf_bsim board behaves similarly to nrf devices, explicitly set the alignment default to 8 bytes.

Just to resume an offline discussion: It concerns me quite a bit to merge this.. it is effectively an ABI breaking change.

This changes only x86 test target, not any libraries for a real product, right?
In a real product compiled for ARM, u64 is aligned to 8 bytes without option to change it by compile flag.
If we don't do this change we could miss really nasty bugs. For example, struct in simulation may have less size and if memory allocation for them have a bug, test may still pass. But on a real target that may lead to a buffer overflow possibly exploitable to remote code execution.

So one needs to be sure all libraries which are used are built with the same flag or only pass packed structs.. (We could have really nasty breaks for users which they can't debug if they use some host library, or link to another library built without this flag.)

Is not this already the case? How do we guarantee that we already don't link any libraries built with -malign-double?

This changes only x86 test target, not any libraries for a real product, right?

Yes, but that is built with other host libraries. Both libraries provided by the OS, and libraries the user may have built without Zephyr's build options.

How do we guarantee that we already don't link any libraries built with -malign-double?

A 3rd party library would better ensure it is ABI compatible with callers using default build options. If they don't, it is a fault of that library maintainers.
Anyhow, if you want to add this option behind a kconfig that is disabled by default, I would be ok with it.


Investigate into OpenAPI stub generating repository

Description:
Look into brew and docker repository systems on how they are structured so that a stub generating repository can be created.

Not relevant.


Why all Process Managers always have version 0?

Currently, any Process Manager, in any case, has its version equal to 0. Is it a desired behavior or bug?
P.S. Aggregates and Projections versions are advanced.

Process Managers now act by advancing their versions upon any dispatched message. Each advance is an auto-increment.
Closing the issue as addressed. For more details see #893.


Added the constants to both prototype and class itself

Added the constants to both the prototype of the XMLHttpRequest Class and the class itself

checkout https://www.npmjs.com/package/xmlhttprequest-ts - i added your pull request


layout_wrap=

Like facet_wrap https://ggplot2.tidyverse.org/reference/facet_wrap.html

Closed by #155


[Release] sdk/resourcemanager/springappdiscovery/armspringappdiscovery/0.1.0

https://github.com/Azure/sdk-release-request/issues/4834

/azp run prepare-pipelines

/azp run go - armspringappdiscovery - ci

/check-enforcer override


"Your request couldn't be completed" when using Phone Auth

Environment

Objective C or Swift: Swift
iOS version: 10.3
Firebase SDK version: 4.x
FirebaseUI version: 4.0.0
CocoaPods Version: 1.1.1

The problem
When I tap the "verify" button, I immediately get a pop-up saying "Your request couldn't be completed. Please try again." I don't get any errors in the log and I'm not sure whether there is anything I might have missed.
The strange thing is that I have successfully received an sms message in the past yet I can't find anything in my code that has changed. Checking out several commits did not make a difference..
I also tried running my app with both the debug and release configs to if that makes a difference.
Just for the record, I feel like migrating from Digits to Firebase is way too intensive. Why couldn't the existing Digits SDK be ported to Firebase? Mixing Firebase + Firebase UI is causing me a lot of troubles so far because everything seems to work different. I know that this is the UI repo and you can't fix it but I just wanted to throw this frustration out there..
Steps to reproduce:
Fill out phone number, tap verify, see error message.
Observed Results:
I see an error message
Expected Results:
I would expect to receive an sms message to verify my phone number or a more descriptive error
Relevant Code:
func application(_ application: UIApplication, didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
    Auth.auth().setAPNSToken(deviceToken, type: AuthAPNSTokenType.prod)
}

func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any], fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void) {
    if Auth.auth().canHandleNotification(userInfo) {
        completionHandler(UIBackgroundFetchResult.noData)
        return
    }
}

func confirmPhoneNumber(withViewController viewController: UIViewController,
                        completionHandler: @escaping PhoneConfirmationHandler) {

    guard let authUI = FUIAuth.defaultAuthUI() else {
        completionHandler(.error(GenericError.unkownError))
        return
    }

    phoneNumberConfirmedHandlers.append(completionHandler)

    authUI.delegate = self
    let provider = FUIPhoneAuth(authUI: authUI)
    authUI.providers = [provider]
    provider.signIn(withPresenting: viewController)
}

@donnywals I understand your frustration. Here're some suggestions:

Have you tried Digits migration helpers?
There is headless Firebase API. You can use it if you don't need UI.
Can you please check this issue and send us logs (you should enabled GTMSessionFetcher)?

@donnywals Can you please provide more info otherwise I'll close this ticket.

@yramanchuk I'm going to look into this more today, didn't have much time the past week. I'll let you know what I find asap :)

@yramanchuk I may have found the problem. The error I see is "Token mismatch", what could this mean and how can I go about fixing it?

Looking in to this further, it seems that signInWithCustomToken:completion: is called on the Auth instance. Shouldn't this be signInwithCredential:completion:?

Token mismatch problems:

you should change token type for production and development;
you haven't uploaded distribution/dev APNS certificate
your APNS certificate is wrong: verify bundeID

Thanks for your help @yramanchuk, it seems to be working now. Our app uses multiple bundle ids and schemes, trans out I was using a bad combination of the two...
I will close the issue


Firebase terraform

Summary by CodeRabbit
Release Notes

New Features

Introduced a tag-based deployment process for streamlined production updates.
Enhanced staging deployment workflow to utilize staging-specific credentials and environment variables.

Bug Fixes

Temporarily commented out the test execution step in the integration testing workflow due to an unspecified error.

Chores

Updated deployment workflow to trigger on pull requests instead of direct pushes.
Improved Firebase project setup with comprehensive Terraform configurations for better management and security.

https://github.com/Greek-Academy/one-pager-maker/pull/103#pullrequestreview-2302800643
Change English!


Exclude glassfish Executor which does not permit wrapped runnables

fixes elastic/apm-agent-java#589

Contains no tests because we would have to instrument java.util.concurrent.ThreadPoolExecutor which is loaded from the bootstrap class loader and thus can't be instrumented in unit tests.

Snapshot for this PR: elastic-apm-agent-1.6.1-SNAPSHOT.jar.zip

@mdindoffer could you give this snapshot a try?
elastic-apm-agent-1.6.1-SNAPSHOT.jar.zip

@felixbarny Perfect, that seems to do the trick.

Codecov Report

Merging #596 into master will increase coverage by 0.02%.
The diff coverage is 66.66%.

@@             Coverage Diff              @@
##             master     #596      +/-   ##
============================================
+ Coverage      62.4%   62.42%   +0.02%
  Complexity       68       68
============================================
  Files           188      188
  Lines          7062     7066       +4
  Branches        814      814
============================================
+ Hits           4407     4411       +4
  Misses         2387     2387
  Partials        268      268

Impacted Files
Coverage Δ
Complexity Δ

.../apm/agent/concurrent/ExecutorInstrumentation.java
52.63% <66.66%> (+5.57%)
0 <0> (ø)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1ca0be8...aa7f50a. Read the comment docs.


Getting HWTH-COMMUNICATION-ERROR

Hi Team,
I am trying to test the HTTP Web Enablement toolkit using the COBOL sample program (HWTHXCB1) for invoking https://example.org and getting the below error.
FAILED: HWTHCONN connect attempt
Return code: HWTH-COMMUNICATION-ERROR
Service: 001835009
Reason Code: HWTH-RSN-REDIRECTED
Reason Desc: EDC9501I The name does not resolve for the supplied parameters.
Request your help in fixing this issue.
Thanks,
Arun

Hello Arunk,
you could first check on these parameters,

try accessing http://example.org/ from your implemenation, if it works then you are missing configurations essential for https protocol (for example keychain). I've provided essential https configuiration here<EMAIL_ADDRESS>

if http://example.org/ does not work, then try some simple http(not https) endpoints withing your organisation's network. if this does not work, it essentially means that your network policies need change(talk with you network administrators

Hi Aravind,
Thanks for the quick response. We are facing the same issue with http as well.
We are able to access the link from browser . So I guess it is due to some restriction within zOS. I will check with the infra team regarding this,
Thanks,
Arun

Hi Aravind,
Thanks for the quick response. We are facing the same issue with http as well.
We are able to access the link from browser . So I guess it is due to some restriction within zOS. I will check with the infra team regarding this,
Thanks, Arun

Perfect, could you proceed to close this issue.

Sure, will close this issue.


CODE_OF_CONDUCT.adoc not recognized by GitHub

According to Insights->Community Standards, this project doesn't have a code of conduct.
Possible solutions:

Change CODE_OF_CONDUCT.adoc to CODE_OF_CONDUCT.md
Add .github/CODE_OF_CONDUCT.md
Define a default code of conduct for Apple projects by adding CODE_OF_CONDUCT.md to the .github project of the apple organization

Since this is not part of our Antora build, there's no reason why it shouldn't just be .md.


Update UG

Codecov Report
Base: 74.30% // Head: 74.21% // Decreases project coverage by -0.08% :warning:

Coverage data is based on head (cd21aa8) compared to base (8492611).
Patch has no changes to coverable lines.

Additional details and impacted files
@@             Coverage Diff              @@
##             master     #225      +/-   ##
============================================
- Coverage     74.30%   74.21%   -0.09%
- Complexity      666      667       +1
============================================
  Files           100      100
  Lines          2016     2017       +1
  Branches        222      223       +1
============================================
- Hits           1498     1497       -1
  Misses          444      444
- Partials         74       76       +2

Impacted Files
Coverage Δ

...rc/main/java/seedu/phu/model/internship/Email.java
70.00% <0.00%> (-10.00%)
:arrow_down:

.../main/java/seedu/phu/model/internship/Website.java
63.63% <0.00%> (-6.37%)
:arrow_down:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Query: How we can create object of UserManager without using in built dependency injection ?

Right with ASP.NET Core 1.0 there is only one way initialize the user manager class is to use the dependency injection.
But in our application, We have created a custom user store for the multi-tenant application.  We need to use that UserStore class in UserManager class. So is there any way to create a new object with NEW keyword. I have tried lots of ways but not succeed as there are lots many arguments in the constructor and every time I am getting some error.
Please provide some guideline for this.

You don't want to "new" dependencies.
You put them as a dependency in your constructor:
public class MyUserStore
{
    public MyUserStore(MyDependency dependency)
    {
        ...
    }
}

Then you add it to the ConfigureServices by overriding IUserStore
That's it really. Did I forget something?

I have already created code for user store. I need to use that user store in UserManger class.
public class ApplicationUserStore : UserStore<ApplicationUser>
    {
        public ApplicationUserStore(Rg2Context context)
          : base(context)
        {
        }

        public int TenantId{ get; set; }

        public override Task<ApplicationUser> FindByNameAsync(string userName, CancellationToken cancellationToken = new CancellationToken())
        {
            return this.GetUserAggregateAsync(u => u.UserName.ToUpper() == userName.ToUpper()
                  && TenantId== this.TenantId);
        }

        public override Task<ApplicationUser> FindByEmailAsync(string email, CancellationToken cancellationToken = new CancellationToken())
        {
            return this.GetUserAggregateAsync(u => u.Email.ToUpper() == email.ToUpper()
                   && u.TenantId == this.TenantId);
        }

        Task<ApplicationUser> GetUserAggregateAsync(Expression<Func<ApplicationUser, bool>> filter)
        {
            return Users.Include(u => u.Roles)
                .Include(u => u.Claims)
                .Include(u => u.Logins)
                .FirstOrDefaultAsync(filter);
        }
    }

@dotnetjalps have you tried replacing the default store with your version by adding it to the service collection? E.g.
services.AddScoped<IUserStore<ApplicationUser>, ApplicationUserStore>();

Sorry the late reply. its working fine thank you.

how did it work for you


[WIP]Bumpup CNI repo version

Pull Request Test Coverage Report for Build 857

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 73.516%

Totals

Change from base Build 856:
0.0%

Covered Lines:
941

Relevant Lines:
1280

💛  - Coveralls

@dougbtv thank you for your review! I've updated the PR to reflect the change to vendor directory.
After CI passed, will be merged.


Add golangci-lint as a new make target

I would like to make sure that we uphold strong code quality within this repository, as such, I think we should be running golangci-lint over the code to keep us honest (eg having comments etc). I will set this up as a check on PRs.

go run /go/src/github.com/openshift/cluster-control-plane-machine-set-operator/vendor/github.com/golangci/golangci-lint/cmd/golangci-lint run ./...
2022/02/[28](https://prow.ci.openshift.org/view/gs/origin-ci-test/pr-logs/pull/openshift_cluster-control-plane-machine-set-operator/6/pull-ci-openshift-cluster-control-plane-machine-set-operator-main-lint/1498391311282081792#1:build-log.txt%3A28) 20:16:53 failed to initialize build cache at /.cache/golangci-lint: mkdir /.cache: permission denied
exit status 1
make: *** [lint] Error 1

Suggest to point cache dir to /tmp/ for ci runs

/lgtm

/override ci/prow/e2e-aws
/override ci/prow/e2e-aws-serial
/override ci/prow/e2e-aws-upgrade
/skip
This project isn't in payload yet so these tests aren't actually testing these changes, also, this doesn't affect the product as it's just linting


Missing unicode 14.0.0 emojis

I believe I'm using the latest version. I noticed several emojis are missing from the iOS set, including 🫡. Peculiarly, I see this unhappy fellow in the list as of 1.5.0:

Here is a workaround: You could add the Noto Color Emoji Font to your app (but it is 23,7MB 😣) and use it when rendering emojis:
val emojiTextStyle = TextStyle(
    fontWeight: FontWeight.w400,
    fontSize: 15,
    fontFamily: 'NotoColorEmoji',
  );

// ...

Text(
  emoji,
  style:  emojiTextStyle,
)

Use it for the picker by setting the  emojiTextStyle in the Config:
Config(
// ...
  emojiTextStyle: emojiTextStyle,
),

Thx for answering the question @RobertHeim !
The question must have slipped my attention 🙇

That's not a workaround because the default emoji set is still incomplete, so you won't see "🫡" etc. This file needs to be updated, it's been out of date since 2021: https://github.com/Fintasys/emoji_picker_flutter/blob/63eaf3ebdefdf3cb2ef1f33cd812bab54385975a/lib/src/default_emoji_set.dart

@maxkrieger ah I see, that's what you meant.
This was the very first issue I created #1 and we are still missing some automation.
Currently Im busy, but if it's urgend feel free to help with updating the list 🙇

@maxkrieger you can pass your own set to the picker. But I agree that the set should be v15 compliant. @Fintasys wrt automation I think we should use the machine readable file from the unicode standard: https://unicode.org/Public/emoji/15.0/emoji-test.txt (Note that most applications put the groups Smileys & Emotion and People & Body in the same semantic group.
Also I would suggest guiding people on how to implement the search function, because by default it does not include the CLDR keyword annotations, but only the emoji names - for example, coffee does not find the Hot Beverage emoji (☕), but a user would expect it of course. We can lookup keywords in different languages using the CLDR annotations data sets: https://github.com/unicode-org/cldr-json/tree/main/cldr-json/cldr-annotations-modern/annotations

@RobertHeim not sure if I would use that dataset as many in that list are unimplemented on iOS, and it exhaustively enumerates the skin tone variants

@RobertHeim Thanks for the information and the links, I didn't know about those.
But I found automation would be still be difficult here since the current order is different from the order in the files (all animal faces together for example). Unless we give up the order I think automation might be difficult. But I saw that Unicode 14 for example just has 36 new emojis that could be added manually in worst case for now. 🤔

Added missing emoji's
https://github.com/Fintasys/emoji_picker_flutter/pull/129

For anyone looking in the future, I couldn't find any dart package on pub.dev that has the latest emoji unicode version (v15.1) so I ended up creating unicode-emoji-dart to help with this issue.


Rebuild to update base image for security vulns

Fixes vulns:

SNYK-ALPINE315-CURL-2938000
SNYK-ALPINE315-CURL-2938003
SNYK-ALPINE315-CURL-2938011
SNYK-ALPINE315-CURL-2937998
SNYK-ALPINE315-CURL-2937999
SNYK-ALPINE315-CURL-2938004
SNYK-ALPINE315-CURL-2938002

docker build . --build-arg NODE_VERSION=12 --tag localnode12
snyk container test localnode12
...
Docker image:      localnode12
Platform:          linux/amd64
Base image:        node:12.22.12-alpine3.15
...

✔ Tested 80 dependencies for known issues, no vulnerable paths found.

docker build . --build-arg NODE_VERSION=14 --tag localnode14
snyk container test localnode14
...
Docker image:      localnode14
Platform:          linux/amd64
Base image:        node:14.19.3-alpine3.15
...

✔ Tested 80 dependencies for known issues, no vulnerable paths found.

docker build . --tag localnode16
snyk container test localnode16
...
Docker image:      localnode16
Platform:          linux/amd64
Base image:        node:16.15.1-alpine3.15
...

✔ Tested 80 dependencies for known issues, no vulnerable paths found.

[sc-12540]


Testing the possibility to approve random PR to dev branch

Motivation

Solution

Closing this to clean up

Closing this to clean up


Traits mentioned in the docs not shown in the crate root

The docs mention:

These traits are all defined – and explained en detail – in the [traits] module. They are, however, all re-exported here at the crate root.

Note that the [traits] link is not linkified, since there is no member with this name. Additionally, there are no traits listed in the root module:

If you want to re-export traits and have them show up in the documentation for the root module, you need to explicitly include pub use self::mod::trait. Using wildcards won't document them as expected.

Thank you for the report and sorry for the late reply. Looks like that doc string is a wee bit outdated.
As for the wildcard re-exports, they really shouldn’t be there: Only the main types and traits from every module should be re-exported. I’ll make a PR to fix that.


[Dialect] Add basic linalgx dialect infrastructure and linalgx.sigmoid op

Add basic linalgx dialect infrastructure.
Kept a copy of mlir LinalgOps.cpp helpers inside our project.
Added linalgx.sigmoid as a structured named op, so now linalgx.sigmoid can be lowered to one single linalg.generic using --linalg-generalize-named-ops.
A potential linalg-decomposition pass can be a idea to decomposed linalgx.sigmoid to a series of named ops.
Tracking: #14

Since we are going to lower sigmoid into a set of math+arith do we need it at all in linalgx? Can we just generate the generic right from ondenn graph?

We want to experiment with all named ops first and learn the strength/limitations, in the future we will decide how to continue the design for future/upstream, etc.


rkt/run: don't check treestore if insecure

Disable checking the treestore when using --insecure-skip-verify.
This reduces the start-up time of big images dramatically.
For example, with docker://jenkins.
docker://jenkins
real	0m7.200s
user	0m6.740s
sys	0m0.550s
docker://jenkins --insecure-skip-verify
real	0m0.384s
user	0m0.100s
sys	0m0.030s

I know this is yet another meaning added to the --insecure-skip-verify sledgehammer but I wanted to start a discussion.
Personally, I like the option of a combined "options" flag --insecure-options=image,tls like mentioned in #912.
Perhaps something like --insecure-options=ondisk-integrity or similar.

How will you optimize loading ACIs that do have a signature? Is that simply just going to have to verify the full contents and this essentially only speeds up the insecure use-case?

How will you optimize loading ACIs that do have a signature? Is that simply just going to have to verify the full contents and this essentially only speeds up the insecure use-case?

The idea is granular verification. You might not trust getting the images from the internet (so you verify them) but maybe you trust your disk, so you don't verify your tree store on each run and can benefit from the optimization.

Closing in favor of #1804.


Add download command

This PR depends on #17 (or equivalent) being merged first :)
$ ost download --file ~/Movies/test.avi
Found 5 subtitles, downloading the first into /Users/shish2k/Movies/test.srt

$ ost download --file ~/Movies/not-a-movie.webm
No subtitles found for /Users/shish2k/Movies/not-a-movie.webm

Error handling isn't great yet - in particular the OSC API appears to be pretty overloaded right now and keeps giving me "the server is down, try again later" errors, which are shown to the user as a generic stack trace

you can pull and use latest code


validate and commit index definition

This commit validates DB index defined for the database. An index
for a database can be defined or updated for an existing database and
also can be defined when the db is created
Signed-off-by: senthil<EMAIL_ADDRESS>

Looks good, except for couple of nits


jsx-closing-bracket-location with 'props-aligned' violates ESLint indent rule

I'd like to write my non-empty tags like this:
<foo
    prop='bar'
    >
    Text
</foo>

And it seems that react/jsx-closing-bracket-location:  ['error',  {nonEmpty: 'props-aligned'}] would get me exactly what I want, but then I get an error thrown from eslint 4.3.0 saying it wants this style:
<foo
    prop='bar'
>
    Text
</foo>

Is it possible that props-aligned is just not possible to use along with the indent rule now?

Yes. In eslint 4, you have to configure the indent rule to ignore JSX if you want anything besides what they enforce by default.

Ok, looks like we'll need to wait for https://github.com/eslint/eslint/issues/8594.  Thanks.

eslint/eslint#8594 has landed.