APIError: FL1001: Insufficient remaining available licenses

Version of the custom_component 1.0.13
Configuration
Core 2023.11.3
Supervisor 2023.11.3
Operating System 11.1
Frontend 20231030.2
Logger: custom_components.imou_life
Source: custom_components/imou_life/entity.py:81
Integration: Imou Life (documentation, issues)
First occurred: 18:47:28 (10 occurrences)
Last logged: 18:47:30

APIError: FL1001: Insufficient remaining available licenses, please contact platform customer service. Traceback (most recent call last): File "/config/custom_components/imou_life/entity.py", line 79, in async_added_to_hass await self.sensor_instance.async_update() File "/usr/local/lib/python3.11/site-packages/imouapi/device_entity.py", line 128, in async_update data = await self.api_client.async_api_deviceSdcardStatus(self._device_id) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/imouapi/api.py", line 466, in async_api_deviceSdcardStatus return await self._async_call_api(api, payload) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/imouapi/api.py", line 216, in _async_call_api raise APIError(error_message) imouapi.exceptions.APIError: FL1001: Insufficient remaining available licenses, please contact platform customer service.
APIError: FL1001: Insufficient remaining available licenses, please contact platform customer service. Traceback (most recent call last): File "/config/custom_components/imou_life/entity.py", line 79, in async_added_to_hass await self.sensor_instance.async_update() File "/usr/local/lib/python3.11/site-packages/imouapi/device_entity.py", line 294, in async_update data = await self.api_client.async_api_getDeviceCameraStatus(self._device_id, self._name) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/imouapi/api.py", line 343, in async_api_getDeviceCameraStatus return await self._async_call_api(api, payload) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/lib/python3.11/site-packages/imouapi/api.py", line 216, in _async_call_api raise APIError(error_message) imouapi.exceptions.APIError: FL1001: Insufficient remaining available licenses, please contact platform customer service.

Describe the bug
Starting from 6th November 2 cameras are not visible anymore.

I have checked in https://open.imoulife.com/consoleNew/vas/deviceIn but I do not see licenses exceeded

I've the same problem.
But get error only with IPC-S42F-D. I've 5 IPC-TA22C-G and get no error

I confirm that also from my side nothing has been changed in my configuration.
The error message is not reporting the right information, in my case, because I have 7 cameras, 10 licenses available and, most important information, 0 licenses exceed!
Many thanks in advence to try help  us on this “strange” issue.

Nothing change from my side.
As I said I've only have problem with 1 camera: my external Imou Cruiser 4MP but with my 5 Imou ranger 2C dont' have any problem

Hi @user2684
Same for me, I also wrote, before finding this thread, in the HA community
Same as @ncosta24, I'm getting the issue when using PTZ location service in a Cruiser 4MP

Ok, so definitely something that has changed on the Imou side which are somehow limiting API calls that our integration is doing. Let's try to understand now if this is related to specific models, to number of concurrent queries, specific operations etc. because I see different and conflicting views on this. I'll investigate and report back

Based on a first round of tests, at least here, the error shows up when interacting ONLY with one device (out of the 9 that I have). Apparently it is not linked to the specific model, this one is a IPC-C22F-C and the others IPC-C22F-C are working fine. It is not related to the specific API call since any API for that specific device throws that error. My guess is that Imou lowered down the number of devices which can be linked to one account but still it is obscure how they did that. I tried deleting a registered device from Imou Life app but still I get the error. I've opened up a ticket asking for a clarification but I'm not very optimistic, I never got decent answers from Imou support so far. Does this resonate with what you are experiecing?

Hello @user2684 in my environment I have 7 Imou cams: 5 are IPC-C22E, 1 is IPC-C22E-A and the last one is IPC-C26E-V2.
The 2 cams that are not working are 1 of IPC-C22E and the IPC-C26E-V2.
I think that the models is not correlated to the issue.
In addition as I have already posted I do not have licenses that exceeded.
The test that maybe I can do is to reduce the numbers of API calls. Because I have configured them only to have the camera view and I’m not using the rest of the sensors created by the integration.
the only problem is to know how to do it. If you can help me maybe we can also try to follow also this route.

it may be worth trying. At least in this way you will not mess up anything and does not require physical access to the device. Even if I'm unsure how shared device would work with the current set of APIs we are using. I remember some specific functions and I'm unsure this will eventually use subaccounts which do require different APIs but maybe for what we do this does not come into play. If you want to try it out, let us know the results of the test, if successful could be a great workaround :-) Many thanks

I have already made the test. I have created a new Imou account and shared from the previous one the 2 cameras that weren't working in HA.
From the Imou App, I'm able to see the 2 shared cameras (as expected).
I have also created a new Developer account to get the new AppID and AppSecret into https://open.imoulife.com/
I'm able to see the 2 cameras without knowing if they are shared or not.
Just for your information also creating a new Developer account we still get the information that we have 10 licenses available.
2 of them are used also for shared cameras:

In HA I added the new "account" by entering the new AppID and AppSecret... the 2 shared cameras have been discovered.
But after adding the first one I noticed that the same camera that was already registered before disappeared. I think that it was replaced by the new one.
I also added the second camera and I had the same behaviour.
Maybe you cannot link the same serial number of the camera at the same time in HA with @user2684 integration.
In addition I have check in the HA log and the error:
APIError: FL1001: Insufficient remaining available licenses
is disappeared.
I'm able to see the 2 cameras now in HA but... they are very slow to show the camera streaming video!!!! And sometimes nothing appears... the box is white!
When this issue happens this is the error in the HA log:
Logger: aiohttp.server
Source: /usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py:403
First occurred: 16:01:33 (4 occurrences)
Last logged: 16:01:37

Error handling request
Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/imouapi/device_entity.py", line 578, in async_get_image
    raise InvalidResponse(f"status code {response.status}")
imouapi.exceptions.InvalidResponse: status code 404

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py", line 433, in _handle_request
    resp = await request_handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_app.py", line 504, in _handle
    resp = await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/aiohttp/web_middlewares.py", line 117, in impl
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 85, in security_filter_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 94, in forwarded_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 28, in request_context_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/ban.py", line 80, in ban_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 236, in auth_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 31, in headers_middleware
    response = await handler(request)
               ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/view.py", line 148, in handle
    result = await handler(request, **request.match_info)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/camera/__init__.py", line 767, in get
    return await self.handle(request, camera)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/camera/__init__.py", line 785, in handle
    image = await _async_get_image(
            ^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/camera/__init__.py", line 176, in _async_get_image
    else await camera.async_camera_image(width=width, height=height)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/imou_life/camera.py", line 98, in async_camera_image
    return await self.sensor_instance.async_get_image()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/imouapi/device_entity.py", line 581, in async_get_image
    raise InvalidResponse(f"unable to retrieve image from {url}: {exception}") from exception
imouapi.exceptions.InvalidResponse: unable to retrieve image from https://ali-pano-fk.oss-eu-central-1.aliyuncs.com/snappic/6E0998CPAZ5EC89_img/Alarm/0/727f44ba30584caca7be826cfd71fd6c.jpg?Expires=1702306891&OSSAccessKeyId=LTAIyrmtqw10bcyQ&Signature=CejxPcUuQ1dOXcpcjyle3u71cM0%3D: status code 404

And also this one, that for me it's more relevant for the Imou integration:
Logger: homeassistant.components.websocket_api.http.connection
Source: custom_components/imou_life/camera.py:106
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 16:01:17 (2 occurrences)
Last logged: 16:01:17

[547225311808] Error handling message: Unknown error (unknown_error) Nico from <IP_ADDRESS> (Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/<IP_ADDRESS> Safari/537.36)
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 26, in _handle_async_response
    await func(hass, connection, msg)
  File "/usr/src/homeassistant/homeassistant/components/camera/__init__.py", line 843, in ws_camera_stream
    url = await _async_stream_endpoint_url(hass, camera, fmt=msg["format"])
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/camera/__init__.py", line 1006, in _async_stream_endpoint_url
    stream = await camera.async_create_stream()
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/camera/__init__.py", line 558, in async_create_stream
    source = await self.stream_source()
             ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/imou_life/camera.py", line 106, in stream_source
    return await self.sensor_instance.async_get_stream_url()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/imouapi/device_entity.py", line 661, in async_get_stream_url
    existing_stream = await self.async_get_existing_stream()
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/imouapi/device_entity.py", line 613, in async_get_existing_stream
    data = await self.api_client.async_api_getLiveStreamInfo(self._device_id)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/imouapi/api.py", line 576, in async_api_getLiveStreamInfo
    return await self._async_call_api(api, payload)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/site-packages/imouapi/api.py", line 210, in _async_call_api
    raise NotAuthorized(f"{error_message}")
imouapi.exceptions.NotAuthorized: OP1009: No right, cannot operate.

I think that there is still something that is not working correctly!

Thanks for all the tests! I probably need to replicate the same scenario to figure it out because I see too many moving pieces :-)
Device disappearing in HA may be related to the fact that the unique id of the device I generate in the integration cannot be reused in HA, so maybe this is why one is appearing and the same is disappearing on the other side. But this can be solved somehow.
The 404 error sometimes happens while retrieving image previews. The process is to request a snapshot and after a while downloading it from the provided url. Sometimes the Imou server takes more time than expected and hence the 404 since the picture is not ready yet but if this happens consistently then it is something different.
The "No right, cannot operate" is instead when calling API calls not supported by the device but once again if was working in the main account, should work also on the shared one.
So I definitely need to replicate to understand a bit more of what's going on there. But at least I think we can confirm the new limitation of 5 devices I guess. Many thanks

Hi @scannifn, I run a few tests and these are my findings:

I shared a device with another account and add it to HA. The error message is not showing up and all the switches work correctly
Despite I've shared all the devices with the other account, it looks like they do not count against the licenses (which makes sense since already consuming a license in the main account, why should they consume another license if it is shared)
Video streaming on any shared device does not work correctly, I got the "OP1009: No right, cannot operate" error message as well. This has nothing to do with the integration, the error comes directly from the Imou service. This is despite giving all the permissions in the Imou Life app to the shared user. The video in HA then shows up correctly but it is slow because it is not a real video but a sequence of snapshots. This is because HA is smart enough to fallback to snapshot streaming when the video streaming is not working. I guess this is what you were noticing too
I've not  experienced any issue with mixing multiple accounts since the appId and appSecret are part of the configuration of a device and when you delete a device, then it is gone and you can attach it with the other account without any problem

Just checking if my findings match with yours. If it is the case, sharing the device is a good workaround, with the only limitation of having the video stream not working (falling back to snapshot streaming would still be ok).

@user2684

Despite I've shared all the devices with the other account, it looks like they do not count against the licenses (which makes sense since already consuming a license in the main account, why should they consume another license if it is shared)

This is the answer from Imou tech support that instead said that shared cam counts

And I'm still having issue when calling ptz-location from a call service in Nodered using the HA device

Hi, thanks. It must be said their answer is not really answering your question but just saying you can view video streaming. Always like that with their support :-)
I finished up my tests and can confirm I was able to mix cameras from the main account with cameras from a secondary account with the current version of the integration without any issue.
Specifically, I've shared the camera which was causing the error with a secondary Imou account, removed it from HA and re-added it back using the app id and secret of the secondary Imou account. It shows up correctly and I can control all the switches.
Kindly asking if you guys can also verify so we can confirm this workaround is fully working.
The issue of the live video streaming is still there so we need to address it in a different way (the secondary imou account has video access through the app so I don't get why we cannot get the same, maybe they are calling different APIs), but at least we are no more blocked by this new license limitation.
Many thanks

i have 7 devices that 5 of them work and 2 wont . i submitted a ticket but it is likely they answered with robot:
hello,developers can log in to the Open Platform website and click "Purchased Resources" to view the remaining number of device channel accesses.
i shared the two one that wont work with another account and add them too app via second account and it works now.

Ciao grazie. Va detto che la loro risposta non è realmente rispondere alla tua domanda ma semplicemente dire che puoi visualizzare lo streaming video. Sempre così con il loro supporto :-) Ho terminato i miei test e posso confermare di essere riuscito a combinare le fotocamere dell'account principale con le fotocamere di un account secondario con la versione attuale dell'integrazione senza alcun problema. Nello specifico, ho condiviso la fotocamera che causava l'errore con un account Imou secondario, l'ho rimossa da HA e l'ho aggiunta di nuovo utilizzando l'ID app e il segreto dell'account Imou secondario. Si presenta correttamente e posso controllare tutti gli interruttori. Vi chiedo gentilmente se potete verificare anche voi in modo da poter confermare che questa soluzione alternativa funziona perfettamente. Il problema dello streaming video in diretta esiste ancora, quindi dobbiamo affrontarlo in un modo diverso (l'account imou secondario ha accesso al video tramite l'app, quindi non capisco perché non possiamo ottenere lo stesso, forse stanno chiamando API diverse ), ma almeno non siamo più bloccati da questa nuova limitazione della licenza. Grazie molto

Hello @user2684 I confirm that also for me it's working using this "alternative" method... even if it's not the best but in the end, it's working.

@user2684
just tried the workaround sharing the device not working to a new account and it's working fine.
Thanks

Test done.
Works sharing the now working device from a secondary account. The only error that I'm getting is on camera.record service, but adding a generic camera to the rtsp url works as a workaround

Test done. Works sharing the now working device from a secondary account. The only error that I'm getting is on camera.record service, but adding a generic camera to the rtsp url works as a workaround

Please could you share the RTSP URL used to add the cameras as Generic Cameras?

Like this: rtsp://<IP_ADDRESS>:554/cam/realmonitor?channel=1&subtype=1

Test done. Works sharing the now working device from a secondary account. The only error that I'm getting is on camera.record service, but adding a generic camera to the rtsp url works as a workaround

Please could you share the RTSP URL used to add the cameras as Generic Cameras?

You can search also in ispyconnect website for imou cam and url for specific cams

Test done. Works sharing the now working device from a secondary account. The only error that I'm getting is on camera.record service, but adding a generic camera to the rtsp url works as a workaround

Please could you share the RTSP URL used to add the cameras as Generic Cameras?

You can search also in ispyconnect website for imou cam and url for specific cams

Many thanks for the hint.

rtsp://<IP_ADDRESS>:554/cam/realmonitor?channel=1&subtype=1

Still image link is not mandatory?

Not mandatory

Thanks all for the tests, so this discussion came to the conclusion that:

Imou decreased to 5 the number of devices which can be handled with a developer account, despite their website still shows 10, regardless of the model and the API which is called
A workaround to this limitation is to create a new Imou account and either bind the camera there or share with this new account the camera from the first account (in this way to avoid any impact on current operations with Imou Life app)
For shared devices, native video streaming (and hence camera.record) does not work properly (I've opened up #80 for this). HA should fallback automatically to snapshots streaming which is suboptimal but working solution. Alternative workaround until we address #80 are to use RTSP or Onvif to integrate the video stream

I will update the documentation with this information as we will release a new version of the integration.
Thanks!


Adding "keepModulesOnUnmount" boolean flag to DynamicModuleLoader

Adding boolean flag to DynamicModuleLoader to optionally prevent unloading modules on react component unmount

@ahrnee  Thanks for the Pull request. Please explain the use case/scenario when this is needed.

I was looking for exactly this.  I'm intending to use this to load my state on first page render, but keep the state for subsequent returns to the page.  Example:  An administer navigates to a page with all users.  On the first page load, we load the module and query for all users to store in the state.  On subsequent returns to the admin page, we no longer have to query for all users as they remain in the store.
That said, I think this change needs to account for the possibility that the modules have been previously loaded and to not load them again.

I was looking for exactly this. I'm intending to use this to load my state on first page render, but keep the state for subsequent returns to the page. Example: An administer navigates to a page with all users. On the first page load, we load the module and query for all users to store in the state. On subsequent returns to the admin page, we no longer have to query for all users as they remain in the store.
That said, I think this change needs to account for the possibility that the modules have been previously loaded and to not load them again.

I looked at the source, and there is already a check in place to ensure duplicate modules are not loaded (see line 109 of Module Manager)


Power level threeshold.

Hello everyone.
I was able to successfully spoof GPS on a USB GPS chip
But no luck on a galaxy s6 (even when no sim card and on airplane mode). One thing is suggested that android will throw away measurement if above certain threshold.
So the question is What power level of GPS should be received on a phone.
Thanks,
HA

Specified for GPS is a guaranteed reception power level of -136dBm on every place on earth.

Hello everyone. I was able to successfully spoof GPS on a USB GPS chip But no luck on a galaxy s6 (even when no sim card and on airplane mode). One thing is suggested that android will throw away measurement if above a certain threshold. So the question is What power level of GPS should be received on a phone. Thanks, HA

It is not about the power level of the GPS it is the receiver configuration of the phone. Since most phones use A-GNSS which include GLONASS, Galileo, BaiDou and GPS therefore, it will not be easy to spoof a multi constellation GNSS receiver with just GPS signal


Extending our cluster deployed by kargo

As I know the recommended way to adding new master/minion/etcd-node to our cluster is add new line to inventory file and running kargo ansible again. With @pskrzyns we have some objections here. Actually it is
cluster re-deployment, not adding a new node. What when something will go wrong with deployment? Our production cluster is broken? Also at this moment kargo is changing very fast and cluster deployed one month ago can be redeployed incorrectly (or in another way) when we add new node.
Can we discuss/find/prepare any better solution for adding node to cluster?
For example for etcd it can be etcd-operator managed by coreos (https://github.com/coreos/etcd-operator)
cc @lleszczu @pskrzyns @dkrzyszczyk @bogdando

#694 can be related

I think you can use --limit newnode1,newnodeX as well. But that should be tested.

I think that the upgrade process in #694 does circle around this point as well. I've found that there's certain tasks that have to be run in order to bootstrap extra nodes, but it's a subset of the cluster.yml file. I have something like this for an autoscaling group that spins up new nodes (meaning to write this up soon). But yeah, I agree we definitely need to chat about the best (and fastest!) way to do this and provide a cluster-expand.yml or similar.
---
- hosts: kube-node
  gather_facts: False
  roles:
    - { role: bootstrap-os, tags: bootstrap-os}

- hosts: all
  gather_facts: True

##Necessary to update /etc/hosts on all nodes
- hosts: all
  roles:
    - { role: kubernetes/preinstall, tags: preinstall }

##Finally bootstrap new nodes
- hosts: kube-node
  roles:
    - { role: kubernetes/preinstall, tags: preinstall }
    - { role: etcd, tags: etcd }
    - { role: kubernetes/node, tags: node }
    - { role: network_plugin, tags: network }

It's actually not so important for /etc/hosts entries to exist for kube-node only role hosts. Only masters and etcds really need to be on all hosts.
Simply doing --limit like Bogdan said is effective if you want to avoid making changes on other nodes.
Delegated tasks will still be performed on k8s/etcd master as needed, including certs gen/sync.

Yeah, I had a bit of a goofy environment where I couldn't actually resolve the compute.internal DNS names, so having /etc/hosts was crucial. No longer blocked by that bit. However, the limit doesn't work for me b/c Tower doesn't seem to support fact caching and the gather_facts for all was required to get the worker nodes to bootstrap properly (was missing things like IPs for etcd nodes and whatnot). I'll explore the fact-caching bit on my side to see if I'm mistaken, but I'm not sure it's something we can expect users to have or know that Ansible does.

@rsmitty the included ansible.cfg enables fact caching, but it might be ignored unless you're in that directory when calling ansible. You can try setting the shell variable ANSIBLE_CONFIG

@mattymo For handling cert generation I would suggest using creates: param in shell module. That way if certain certificate exists it's not overwritten.

@lleszczu ideally, we'll consume certs management from kubeadm, once it has feature flags

@lleszczu https://github.com/kubernetes-incubator/kargo/pull/798 will address not overwriting exisitng certificates (for etcd)

@lleszczu Is this issue addressed yet? The certs only sync if needed now and new certs are no longer generated for hosts that already have certs.

upgrading/recovering etcd is non trivial. https://groups.google.com/forum/#!topic/kubernetes-users/ErRedBfNpwA
we have tried doing this but borked our cluster more than once. Need clarity on the exact sequence of steps.

Just now I failed to expand my cluster with --limit option, kargo revision: bc3068c2f90d678175ea746a3a7140cc2d7c3593  ansible version: v<IP_ADDRESS>-1 checked out from ansible repository
TASK [kubernetes/preinstall : set_fact] ****************************************
Thursday 04 May 2017  09:07:22 +0800 (0:00:00.058)       0:00:07.910 **********
fatal: [gluster1]: FAILED! => {"failed": true, "msg": "the field 'args' has an invalid value, which appears to include a variable that is undefined. The error was: 'dict object' has no attribute 'ansible_default_ipv4'\n\nThe error appears to have been in '/home/d00413986/webhosting/kargo/roles/kubernetes/preinstall/tasks/set_facts.yml': line 14, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- set_fact:\n  ^ here\n"}
fatal: [gluster2]: FAILED! => {"failed": true, "msg": "the field 'args' has an invalid value, which appears to include a variable that is undefined. The error was: 'dict object' has no attribute 'ansible_default_ipv4'\n\nThe error appears to have been in '/home/d00413986/webhosting/kargo/roles/kubernetes/preinstall/tasks/set_facts.yml': line 14, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- set_fact:\n  ^ here\n"}
fatal: [gluster3]: FAILED! => {"failed": true, "msg": "the field 'args' has an invalid value, which appears to include a variable that is undefined. The error was: 'dict object' has no attribute 'ansible_default_ipv4'\n\nThe error appears to have been in '/home/d00413986/webhosting/kargo/roles/kubernetes/preinstall/tasks/set_facts.yml': line 14, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- set_fact:\n  ^ here\n"}
	to retry, use: --limit @/home/d00413986/webhosting/kargo/cluster.retry

Tracked in the #1122 issue


Dry-run file contains statements with invalid syntax

Which version and edition of Flyway are you using?
Pro 5.2.4
If this is not the latest version, can you reproduce the issue with the latest one as well?
(Many bugs are fixed in newer releases and upgrading will often resolve the issue)
Which client are you using? (Command-line, Java API, Maven plugin, Gradle plugin)
Java API
Which database are you using (type & version)?
PostgeSQL 9.6.8
Which operating system are you using?
Linux,Windows
What did you do?
(Please include the content causing the issue, any relevant configuration settings, the SQL statement that failed (if relevant) and the command you ran.)

Enable dry run mode (I use FlywayConfigurationCustomizer and call FluentConfiguration.dryRunOutput)
Execute migration command

What did you expect to see?
Dry run ready to execute via psql
What did you see instead?
See below, note SELECT set_config('search_path', ?, false); line - this is not a valid syntax - ? is not expected.
---====================================
-- Flyway Dry Run (2019-01-25 19:57:24)
---====================================

SET ROLE 'postgres';
SET ROLE 'postgres';
SET ROLE 'postgres';

-- Executing: validate (with callbacks)
------------------------------------------------------------------------------------------
SET ROLE 'postgres';

-- Executing: migrate (with callbacks)
------------------------------------------------------------------------------------------
SET ROLE 'postgres';
SELECT set_config('search_path', ?, false);

Thanks for the detailed report and analysis. This has now been fixed.


Initial Swagger compatibility proposal

Description
This is an idea to modify the existing go generate process to use more "OS-agnostic" logic by leveraging Go to handle the file downloads, string replacement, and ultimately the execution of Swagger Codegen in response to #13

Hi @psprings, thanks so much for filing this issue and for the fix proposal! The underlying issue here is that OpenAPI used by Swagger and GoogleAPI are structured differently. There has been a lot of work to address these issues, but it's still WIP. I think the best way to address this specific issue is to modify the generated library code. Would you be willing to contribute this fix?

https://github.com/grafeas/client-go/issues/13#issuecomment-534570155
This could really be stored in the https://github.com/grafeas/grafeas repository, and run as part of the CI process when a release is tagged. It could technically accept "language" as one of the -ldflags (or adapted to use environment variables, args, etc) and be used to generate clients for any language.
Details

Downloads the Swagger Codegen CLI via http.Get instead of wget
Downloads the Swagger spec file(s) via http.Get instead of wget

Also pulling in project.swagger.json since the "project client" was missing

Does string replacement on each Swagger spec file to convert from the GoogleAPI format to OpenAPI Swagger compatible format to fix #13
Executes the the Swagger Codegen CLI for each spec file

Will wait to generate and submit the updated client after an approach can be agreed upon

@googlebot I signed it!

Thanks for this PR. I think it's a strict improvement over the current state of things with Swagger client generation, and I'm open to merging it once the PR is finalized and comments are addressed.

Just thought of one more missing piece, which would be updating the config.go.json prior to the codegen command.

@aysylu any feedback on the review comments/replies above before I start making some changes?

Hi @psprings: sorry for the delay on the next round of review. I have an outstanding review draft to send it to you, will be ready by EOD today. Thanks for your patience!

@aysylu no problem -- I know you're juggling a number of other issues across the Grafeas repos. I'll keep an eye out for your forthcoming review.
I think there are a few people that have a vested interest in this, so I just wanted to make sure I gave this some attention while I still can remember some of the assumptions I made.

Hi @psprings: we'd love to merge your contribution into the repository. If you don't have time to address the final clarification, could you please let us know and we'd be happy to follow up with the fix.

Hi @psprings: we'd love to merge your contribution into the repository. If you don't have time to address the final clarification, could you please let us know and we'd be happy to follow up with the fix. If you could please sign the CLA, then we can merge the PR as is, to ensure credit goes where credit's due.:)

@aysylu sorry, I've been heads down on some work on a few COVID-focused projects in my spare time since all of this craziness started. I'll try to get that CLA addressed and if I have a few moments today see how much effort it would take to get that spec merge sorted out.

Hi @psprings: we'd love to merge your contribution into the repository. If you don't have time to address the final clarification, could you please let us know and we'd be happy to follow up with the fix. If you could please sign the CLA, then we can merge the PR as is, to ensure credit goes where credit's due.:)

@aysylu sorry, I've been heads down on some work on a few COVID-focused projects in my spare time since all of this craziness started. I'll try to get that CLA addressed and if I have a few moments today see how much effort it would take to get that spec merge sorted out.

All good and understandable! I'll keep this PR open for when you get a chance. And as I mentioned earlier, the final clarification can be addressed by one of us in a follow-up PR, no problem. Hope you're staying healthy and safe!

All good and understandable! I'll keep this PR open for when you get a chance. And as I mentioned earlier, the final clarification can be addressed by one of us in a follow-up PR, no problem. Hope you're staying healthy and safe!

Thanks, hope all is well on your end as well! I had a few minutes today and took a really rough pass at the merged client concept. Just need to do some cleanup and a few more tests then it should be good to go.

All good and understandable! I'll keep this PR open for when you get a chance. And as I mentioned earlier, the final clarification can be addressed by one of us in a follow-up PR, no problem. Hope you're staying healthy and safe!

@aysylu thanks, hope all is well on your end as well! I had a few minutes today and took a really rough pass at the merged client concept. Just need to do some cleanup and a few more tests then it should be good to go.

Sounds great, thank you! Looking forward to this.

All good and understandable! I'll keep this PR open for when you get a chance. And as I mentioned earlier, the final clarification can be addressed by one of us in a follow-up PR, no problem. Hope you're staying healthy and safe!

@aysylu thanks, hope all is well on your end as well! I had a few minutes today and took a really rough pass at the merged client concept. Just need to do some cleanup and a few more tests then it should be good to go.

Sounds great, thank you! Looking forward to this.

Hi @psprings - is this something you are still considering moving forward with?

All good and understandable! I'll keep this PR open for when you get a chance. And as I mentioned earlier, the final clarification can be addressed by one of us in a follow-up PR, no problem. Hope you're staying healthy and safe!

@aysylu thanks, hope all is well on your end as well! I had a few minutes today and took a really rough pass at the merged client concept. Just need to do some cleanup and a few more tests then it should be good to go.

Sounds great, thank you! Looking forward to this.

Hi @psprings - is this something you are still considering moving forward with?

I have raised a PR that will fix the openapi paths and not require the regex bit in this PR: https://github.com/grafeas/grafeas/pull/532/files
@psprings are you ok with me taking the work you've done here and re-raising a change?


Solargraph crashes on Ruby file open

Problem description
Opening a Ruby file causes an error message:

2022-07-28T21:17:01  WARN Client 3 quit with exit code 1 and signal 0

Why do you think this is an issue with mason-lspconfig.nvim?
LSP functionality works correctly using Nvim Lsp Install
Neovim version (>= 0.7)
NVIM v0.8.0-dev-nightly-221-g1a07044c1
Build type: Release
LuaJIT 2.1.0-beta3
Operating system/version
Darwin M1MacBookPro.local 21.5.0 Darwin Kernel Version 21.5.0: Tue Apr 26 21:08:29 PDT 2022; root:xnu-8020.121.3~4/RELEASE_ARM64_T8101 arm64
I've manually reviewed the Nvim LPS client log (:LspLog) to find potential errors

[X] Yes

I've recently downloaded the latest plugin version of mason.nvim, mason-lspconfig.nvim, and nvim-lspconfig

[X] Yes

Affected language servers
Solargraph 0.45.0
Steps to reproduce
Install via Mason
Open Ruby file
Actual behavior
No LSP for Ruby files
Expected behavior
LSP for Ruby files
LspInfo
Language client log: /Users/paul/.local/state/nvim/lsp.log
 Detected filetype:   ruby

 0 client(s) attached to this buffer:

 1 active client(s) not attached to this buffer:

 Client: sumneko_lua (id: 1, pid: 8360, bufnr: [6])
 	filetypes:       lua
 	autostart:       true
 	root directory:  /Users/paul/Personal/Repos/dotfiles
 	cmd:             lua-language-server

 Other clients that match the filetype: ruby

 Config: solargraph
 	filetypes:         ruby
 	root directory:    /Users/paul/Dev/api
 	cmd:               solargraph stdio
 	cmd is executable: true
 	autostart:         true
 	custom handlers:

 Configured servers list: tsserver, sqlls, lemminx, html, dockerls, cssls, bashls, jsonls, solargraph, sumneko_lua, yamlls

LspLog
[START][2022-07-28 21:19:24] LSP logging initiated
[ERROR][2022-07-28 21:19:24] .../vim/lsp/rpc.lua:439	"rpc"	"solargraph"	"stderr"	"/Users/paul/.asdf/installs/ruby/3.1.1/lib/ruby/site_ruby/3.1.0/rubygems.rb:265:in `find_spec_for_exe': can't find gem solargraph (>= 0.a) with executable solargraph (Gem::GemNotFoundException)\n\tfrom /Users/paul/.asdf/installs/ruby/3.1.1/lib/ruby/site_ruby/3.1.0/rubygems.rb:284:in `activate_bin_path'\n\tfrom /Users/paul/.local/share/nvim/mason/bin/solargraph:25:in `<main>'\n"
[ERROR][2022-07-28 21:19:24] .../vim/lsp/rpc.lua:439	"rpc"	"solargraph"	"stderr"	"/Users/paul/.asdf/installs/ruby/3.1.1/lib/ruby/site_ruby/3.1.0/rubygems.rb:265:in `find_spec_for_exe': can't find gem solargraph (>= 0.a) with executable solargraph (Gem::GemNotFoundException"
[ERROR][2022-07-28 21:19:24] .../vim/lsp/rpc.lua:439	"rpc"	"solargraph"	"stderr"	")\n\tfrom /Users/paul/.asdf/installs/ruby/3.1.1/lib/ruby/site_ruby/3.1.0/rubygems.rb:284:in `activate_bin_path'\n\tfrom /Users/paul/.local/share/nvim/mason/bin/solargraph:25:in `<main>'\n"

### Healthcheck

```Text
## mason.nvim report
  - OK: neovim version >= 0.7.0
  - WARNING: **Go**: not available
  - WARNING: **cargo**: not available
  - OK: **luarocks**: `/opt/homebrew/bin/luarocks 3.9.1`
  - OK: **Ruby**: `ruby 3.1.1p18 (2022-02-18 revision 53f5fc4236) [arm64-darwin21]`
  - OK: **RubyGem**: `3.3.10`
  - WARNING: **Composer**: not available
  - WARNING: **PHP**: not available
  - OK: **npm**: `6.14.15`
  - OK: **node**: `v14.18.3`
  - OK: **python3**: `Python 3.9.13`
  - OK: **pip3**: `pip 22.1.1 from /opt/homebrew/lib/python3.9/site-packages/pip (python 3.9)`
  - WARNING: **javac**: not available
  - WARNING: **java**: not available
  - WARNING: **julia**: not available
  - OK: **wget**: `GNU Wget 1.21.3 built on darwin21.3.0.`
  - OK: **curl**: `curl 7.79.1 (x86_64-apple-darwin21.0) libcurl/7.79.1 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.45.1`
  - OK: **gzip**: `Apple gzip 353.100.22`
  - OK: **tar**: `bsdtar 3.5.1 - libarchive 3.5.1 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.8 `
  - OK: **bash**: `GNU bash, version 3.2.57(1)-release (arm64-apple-darwin21)`
  - OK: **sh**: `Ok`
  - OK: GitHub API rate limit. Used: 6. Remaining: 54. Limit: 60. Reset: Thu 28 Jul 21:26:47 2022.

### Screenshots or recordings

_No response_

Hey! This is due to https://github.com/williamboman/mason.nvim/issues/152. Unfortunately all gem-based packages (three of them in total) are not functional yet with Mason. I've been reading up and experimenting with different solutions, will hopefully land something today

Thank you for confirming. I look forward to any updates you're able to
make.
Thank you for the time you've put into this project.
On Fri, 29 Jul 2022, 13:00 William Boman, @.***> wrote:

Hey! This is due to williamboman/mason.nvim#152
https://github.com/williamboman/mason.nvim/issues/152. Unfortunately
all gem-based packages (three of them in total) are not functional yet with
Mason. I've been reading up and experimenting with different solutions,
will hopefully land something today
—
Reply to this email directly, view it on GitHub
https://github.com/williamboman/mason-lspconfig.nvim/issues/14#issuecomment-1199194772,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJE62PQ2O3GLGPDAJGH4C3VWPBUHANCNFSM546RCRNA
.
You are receiving this because you authored the thread.Message ID:
@.***>

Hey this should be fixed now. Let's reopen if you're still experiencing issues (you'll need to reinstall affected packages)

Hey this should be fixed now. Let's reopen if you're still experiencing issues (you'll need to reinstall affected packages)

Unfortunately, using the same config as LspInstaller (but following the instructions to switch to Mason LSP Installer), i'm getting the same issue with the Solargraph LSP. Lua's LSP works perfectly.

Unfortunately, using the same config as LspInstaller (but following the instructions to switch to Mason LSP Installer), i'm getting the same issue with the Solargraph LSP. Lua's LSP works perfectly.

Hmm.. Are you getting any errors? Can you run $ solargraph stdio in the terminal (:term)?

I am able to run solargraph stdio (once I manually install the gem).
When I open a Ruby file in Nvim with Mason installed, I get the following:
Error executing luv callback:
vim/shared.lua:0: attempt to index a nil value
stack traceback:
        vim/shared.lua: in function 'tbl_get'
        ...neovim/HEAD-3ee6c05_1/share/nvim/runtime/lua/vim/lsp.lua:403: in function 'get_group'
        ...neovim/HEAD-3ee6c05_1/share/nvim/runtime/lua/vim/lsp.lua:525: in function 'reset'
        ...neovim/HEAD-3ee6c05_1/share/nvim/runtime/lua/vim/lsp.lua:1151: in function 'on_exit'
        ...im/HEAD-3ee6c05_1/share/nvim/runtime/lua/vim/lsp/rpc.lua:329: in function <...im/HEAD-3ee6c05_1/s
hare/nvim/runtime/lua/vim/lsp/rpc.lua:321>
        [C]: in function '__newindex'
        ...te/pack/packer/start/filetype.nvim/lua/filetype/init.lua:8: in function 'setf'
        ...te/pack/packer/start/filetype.nvim/lua/filetype/init.lua:14: in function 'set_filetype'
        ...te/pack/packer/start/filetype.nvim/lua/filetype/init.lua:65: in function 'try_lookup'
        ...te/pack/packer/start/filetype.nvim/lua/filetype/init.lua:158: in function 'resolve'
        [string ":lua"]:1: in main chunk
        [C]: at 0x010239abb0
        [C]: in function 'pcall'
        ...site/pack/packer/start/auto-session/lua/auto-session.lua:480: in function 'restore'
        ...site/pack/packer/start/auto-session/lua/auto-session.lua:519: in function <...site/pack/packer/st
art/auto-session/lua/auto-session.lua:471>
        [C]: in function 'cmd'
        ...m/site/pack/packer/start/packer.nvim/lua/packer/load.lua:110: in function 'apply_cause_side_effct
s'
        ...m/site/pack/packer/start/packer.nvim/lua/packer/load.lua:158: in function <...m/site/pack/packer/
start/packer.nvim/lua/packer/load.lua:118>
        [C]: in function 'pcall'
        ...m/site/pack/packer/start/packer.nvim/lua/packer/load.lua:162: in function <...m/site/pack/packer/
start/packer.nvim/lua/packer/load.lua:161>
        [string ":lua"]:1: in main chunk

Have the same trouble with solargraph.
From :term it looks fine:
solargraph stdio          ✔  3.0.2 
Solargraph is listening on stdio PID=3661

But in LspLog:
[ERROR][2022-08-12 03:06:54] .../vim/lsp/rpc.lua:420	"rpc"	"solargraph"	"stderr"	"Solargraph is listening on stdio PID=3753\n"
[ERROR][2022-08-12 03:06:55] .../vim/lsp/rpc.lua:420	"rpc"	"solargraph"	"stderr"	"[WARN] /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/bundler-2.3.20/lib/bundler/definition.rb:514:in `materialize': Could not find racc-1.6.0 in locally installed gems (Bundler::GemNotFound)\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/bundler-2.3.20/lib/bundler/definition.rb:257:in `specs_for'\n\tfrom -e:1:in `block in <main>'\n\tfrom -e:1:in `chdir'\n\tfrom -e:1:in `<main>'\n\n"
[ERROR][2022-08-12 03:06:55] .../vim/lsp/rpc.lua:420	"rpc"	"solargraph"	"stderr"	"[WARN] Failed to load gems from bundle at /Users/mario/work/this_moment\n"
[ERROR][2022-08-12 03:06:57] .../vim/lsp/rpc.lua:420	"rpc"	"solargraph"	"stderr"	"#<Thread:0x0000000112edddf8 /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/solargraph-0.45.0/lib/solargraph/language_server/host/diagnoser.rb:45 run> terminated with exception (report_on_exception is true):\n"
[ERROR][2022-08-12 03:06:57] .../vim/lsp/rpc.lua:420	"rpc"	"solargraph"	"stderr"	"<internal:/Users/mario/.rbenv/versions/3.1.2/lib/ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require': cannot load such file -- rubocop-rails (LoadError)\n"
[ERROR][2022-08-12 03:06:57] .../vim/lsp/rpc.lua:420	"rpc"	"solargraph"	"stderr"	"\tfrom <internal:/Users/mario/.rbenv/versions/3.1.2/lib/ruby/3.1.0/rubygems/core_ext/kernel_require.rb>:85:in `require'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/feature_loader.rb:35:in `load'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/feature_loader.rb:21:in `load'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/config_loader_resolver.rb:14:in `block (2 levels) in resolve_requires'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/config_loader_resolver.rb:13:in `each'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/config_loader_resolver.rb:13:in `block in resolve_requires'\n\tfrom <internal:kernel>:90:in `tap'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/config_loader_resolver.rb:12:in `resolve_requires'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/config_loader.rb:46:in `load_file'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/config_loader.rb:104:in `configuration_from_file'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/config_store.rb:68:in `for_dir'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/config_store.rb:58:in `for'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/target_finder.rb:190:in `block in process_explicit_path'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/target_finder.rb:189:in `reject'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/target_finder.rb:189:in `process_explicit_path'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/target_finder.rb:40:in `block in find'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/target_finder.rb:36:in `each'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/target_finder.rb:36:in `find'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/runner.rb:81:in `find_target_files'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/rubocop-1.34.1/lib/rubocop/runner.rb:42:in `run'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/solargraph-0.45.0/lib/solargraph/diagnostics/rubocop.rb:29:in `block in diagnose'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/solargraph-0.45.0/lib/solargraph/diagnostics/rubocop_helpers.rb:57:in `redirect_stdout'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/solargraph-0.45.0/lib/solargraph/diagnostics/rubocop.rb:29:in `diagnose'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/solargraph-0.45.0/lib/solargraph/library.rb:363:in `block in diagnose'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/solargraph-0.45.0/lib/solargraph/library.rb:362:in `each_pair'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/solargraph-0.45.0/lib/solargraph/library.rb:362:in `diagnose'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/solargraph-0.45.0/lib/solargraph/language_server/host.rb:211:in `diagnose'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/solargraph-0.45.0/lib/solargraph/language_server/host/diagnoser.rb:66:in `tick'\n\tfrom /Users/mario/.local/share/nvim/mason/packages/solargraph/gems/solargraph-0.45.0/lib/solargraph/language_server/host/diagnoser.rb:47:in `block in start'\n"

@mario-amazing your issue is due to missing gems in gem path that mason sets up. See https://github.com/williamboman/nvim-lsp-installer/issues/187 for reference.
You’ll need to periodically run bundle install with GEM_PATH and GEM_HOME set to mason’s solargraph install path.

I did manage to ~gut~ modify gem manager to work with system with there two diffs
mason.nvim:
diff --git a/lua/mason-core/managers/system-gem/init.lua b/lua/mason-core/managers/system-gem/init.lua
new file mode 100644
index 0000000..72b4529
--- /dev/null
+++ b/lua/mason-core/managers/system-gem/init.lua
@@ -0,0 +1,131 @@
+local _ = require "mason-core.functional"
+local Result = require "mason-core.result"
+local spawn = require "mason-core.spawn"
+local Optional = require "mason-core.optional"
+local installer = require "mason-core.installer"
+
+local M = {}
+
+---@param packages string[]
+local function with_receipt(packages)
+    return function()
+        local ctx = installer.context()
+        ctx.receipt:with_primary_source(ctx.receipt.gem(packages[1]))
+        for i = 2, #packages do
+            ctx.receipt:with_secondary_source(ctx.receipt.gem(packages[i]))
+        end
+    end
+end
+
+---@async
+---@param packages { [number]: string, bin: string[]? } The Gem packages to install. The first item in this list will be the recipient of the requested version, if set.
+function M.packages(packages)
+    return function()
+        return M.install(packages).with_receipt()
+    end
+end
+
+---@async
+---@param packages { [number]: string, bin: string[]? } The Gem packages to install. The first item in this list will be the recipient of the requested version, if set.
+function M.install(packages)
+    local ctx = installer.context()
+    local pkgs = _.list_copy(packages or {})
+
+    ctx.requested_version:if_present(function(version)
+        pkgs[1] = ("%s:%s"):format(pkgs[1], version)
+    end)
+
+    ctx.spawn.gem {
+        "install",
+        pkgs,
+    }
+
+    return {
+        with_receipt = with_receipt(packages),
+    }
+end
+
+---@alias GemOutdatedPackage {name:string, current_version: string, latest_version: string}
+
+---Parses a string input like "package (0.1.0 < 0.2.0)" into its components
+---@param outdated_gem string
+---@return GemOutdatedPackage
+function M.parse_outdated_gem(outdated_gem)
+    local package_name, version_expression = outdated_gem:match "^(.+) %((.+)%)"
+    if not package_name or not version_expression then
+        -- unparsable
+        return nil
+    end
+    local current_version, latest_version = unpack(vim.split(version_expression, "<"))
+
+    ---@type GemOutdatedPackage
+    local outdated_package = {
+        name = vim.trim(package_name),
+        current_version = vim.trim(current_version),
+        latest_version = vim.trim(latest_version),
+    }
+    return outdated_package
+end
+
+---Parses the stdout of the `gem list` command into a table<package_name, version>
+---@param output string
+function M.parse_gem_list_output(output)
+    ---@type table<string, string>
+    local gem_versions = {}
+    for _, line in ipairs(vim.split(output, "\n")) do
+        local gem_package, version = line:match "^(%S+) %((%S+)%)$"
+        if gem_package and version then
+            gem_versions[gem_package] = version
+        end
+    end
+    return gem_versions
+end
+
+local function not_empty(s)
+    return s ~= nil and s ~= ""
+end
+
+---@async
+---@param receipt InstallReceipt<InstallReceiptPackageSource>
+---@param _install_dir string
+---@diagnostic disable-next-line: unused-local
+function M.check_outdated_primary_package(receipt, _install_dir)
+    if receipt.primary_source.type ~= "gem" then
+        return Result.failure "Receipt does not have a primary source of type gem"
+    end
+    return spawn.gem({ "outdated" }):map_catching(function(result)
+        ---@type string[]
+        local lines = vim.split(result.stdout, "\n")
+        local outdated_gems = vim.tbl_map(M.parse_outdated_gem, vim.tbl_filter(not_empty, lines))
+
+        local outdated_gem = _.find_first(function(gem)
+            return gem.name == receipt.primary_source.package and gem.current_version ~= gem.latest_version
+        end, outdated_gems)
+
+        return Optional.of_nilable(outdated_gem)
+            :map(function(gem)
+                return {
+                    name = receipt.primary_source.package,
+                    current_version = assert(gem.current_version, "current_version missing in gem"),
+                    latest_version = assert(gem.latest_version, "latest_version missing in gem"),
+                }
+            end)
+            :or_else_throw "Primary package is not outdated."
+    end)
+end
+
+---@async
+---@param receipt InstallReceipt<InstallReceiptPackageSource>
+---@param _install_dir string
+---@diagnostic disable-next-line: unused-local
+function M.get_installed_primary_package_version(receipt, _install_dir)
+    return spawn
+        .gem({ "list" })
+        :map_catching(function(result)
+            local gems = M.parse_gem_list_output(result.stdout)
+            return Optional.of_nilable(gems[receipt.primary_source.package])
+                :or_else_throw "Failed to find gem package version."
+        end)
+end
+
+return M
diff --git a/lua/mason-registry/index.lua b/lua/mason-registry/index.lua
index 469f92d..0f95727 100644
--- a/lua/mason-registry/index.lua
+++ b/lua/mason-registry/index.lua
@@ -182,6 +182,7 @@ return {
   ["slint-lsp"] = "mason-registry.slint-lsp",
   solang = "mason-registry.solang",
   solargraph = "mason-registry.solargraph",
+  ["solargraph-system"] = "mason-registry.solargraph-system",
   solhint = "mason-registry.solhint",
   solidity = "mason-registry.solidity",
   ["solidity-ls"] = "mason-registry.solidity-ls",
diff --git a/lua/mason-registry/solargraph-system/init.lua b/lua/mason-registry/solargraph-system/init.lua
new file mode 100644
index 0000000..7f6386b
--- /dev/null
+++ b/lua/mason-registry/solargraph-system/init.lua
@@ -0,0 +1,11 @@
+local Pkg = require "mason-core.package"
+local gem = require "mason-core.managers.system-gem"
+
+return Pkg.new {
+    name = "solargraph-system",
+    desc = [[Solargraph is a Ruby gem that provides intellisense features through the language server protocol. Installed via a system provided `gem` command.]],
+    homepage = "https://solargraph.org",
+    languages = { Pkg.Lang.Ruby },
+    categories = { Pkg.Cat.LSP },
+    install = gem.packages { "solargraph" },
+}
diff --git a/lua/mason/mappings/language.lua b/lua/mason/mappings/language.lua
index 4b9c8e0..0e40dd5 100644
--- a/lua/mason/mappings/language.lua
+++ b/lua/mason/mappings/language.lua
@@ -92,7 +92,7 @@ return {
   reason = { "reason-language-server" },
   rescript = { "rescript-lsp" },
   ["robot framework"] = { "robotframework-lsp" },
-  ruby = { "erb-lint", "rubocop", "ruby-lsp", "solargraph", "sorbet", "standardrb" },
+  ruby = { "erb-lint", "rubocop", "ruby-lsp", "solargraph", "solargraph-system", "sorbet", "standardrb" },
   rust = { "codelldb", "cpptools", "rust-analyzer" },
   salt = { "salt-lsp" },
   scss = { "css-lsp", "prettier", "prettierd" },

mason-lspconfig.nvim:
diff --git a/lua/mason-lspconfig/mappings/filetype.lua b/lua/mason-lspconfig/mappings/filetype.lua
index b80f8eb..88d2210 100644
--- a/lua/mason-lspconfig/mappings/filetype.lua
+++ b/lua/mason-lspconfig/mappings/filetype.lua
@@ -124,7 +124,7 @@ return {
   rnoweb = { "ltex" },
   robot = { "robotframework_ls" },
   rst = { "esbonio", "ltex" },
-  ruby = { "ruby_ls", "solargraph", "sorbet" },
+  ruby = { "ruby_ls", "solargraph", "sorbet", "solargraph-system" },
   rust = { "rust_analyzer" },
   sass = { "emmet_ls", "tailwindcss" },
   scss = { "cssls", "emmet_ls", "stylelint_lsp", "tailwindcss" },
@@ -166,4 +166,4 @@ return {
   ["yaml.docker-compose"] = { "yamlls" },
   zig = { "zls" },
   zir = { "zls" }
-}
\ No newline at end of file
+}
diff --git a/lua/mason-lspconfig/mappings/server.lua b/lua/mason-lspconfig/mappings/server.lua
index 6936aa1..9f49485 100644
--- a/lua/mason-lspconfig/mappings/server.lua
+++ b/lua/mason-lspconfig/mappings/server.lua
@@ -97,7 +97,7 @@ M.lspconfig_to_package = {
     ["serve_d"] = "serve-d",
     ["slint_lsp"] = "slint-lsp",
     ["solang"] = "solang",
-    ["solargraph"] = "solargraph",
+    ["solargraph"] = "solargraph-system",
     ["solc"] = "solidity",
     ["solidity"] = "solidity-ls",
     ["sorbet"] = "sorbet",

The problem, however, is that resulting system-gem doesn't report version information. Also, with mason-lspconfig mapping servers to installs 1-1, I need to modify things further to allow for multiple versions of the same LSP installs.
But overall, resulting "solargraph-system" package works exactly how I need it to work when it comes to loading gems.

I can't install any ruby lsp.


AssertionError: Error loading BVH: framenum - Animation Issue

I'm having trouble using my own animation with any of the example drawings.
I've gone through the steps of creating an Animation in Rokoko.
Exported with the Mixamo preset - tried various settings within that.
I've made a new motion config with the correct path to the bvh file and the same end frame count.
I've tried using the mixamo_fff & fair1_ppf retarget files.
I have tried using the character shown in the example and the garlic drawing as well.
I feel like i've exhausted every possible solution and I still get this same error...
Traceback (most recent call last):
File "", line 1, in
File "C:\Users\IKONIX-Desktop-2\AnimatedDrawings\animated_drawings\render.py", line 21, in start
scene = Scene(cfg.scene)
File "C:\Users\IKONIX-Desktop-2\AnimatedDrawings\animated_drawings\model\scene.py", line 30, in init
ad = AnimatedDrawing(*each)
File "C:\Users\IKONIX-Desktop-2\AnimatedDrawings\animated_drawings\model\animated_drawing.py", line 255, in init
self._initialize_retargeter_bvh(motion_cfg, retarget_cfg)
File "C:\Users\IKONIX-Desktop-2\AnimatedDrawings\animated_drawings\model\animated_drawing.py", line 317, in _initialize_retargeter_bvh
self.retargeter = Retargeter(motion_cfg, retarget_cfg)
File "C:\Users\IKONIX-Desktop-2\AnimatedDrawings\animated_drawings\model\retargeter.py", line 38, in init
assert False, msg
AssertionError: Error loading BVH: framenum specified (559) and found (560) do not match
I noticed that in the example bvh files the Frame Time = 0.0333333 whereas my export = 0.011111
Is this possible the issue or have I missed something else??
Thank you

Could you plz post the bvh?

test.zip

I modified the Frames of the rokokoDance.bvh: 559 -> 560

It works:

I have no idea why it was happening, please check the export settings of rokoko.

Lol... I tried 559, 558, 560 and none worked :o

Should i be running the render script from the animated drawings root folder?
Where the other files in the zip all correct?

from animated_drawings import render
render.start('./examples/config/mvc/test_mvc.yaml')
Is this the right command?

Also remove LeftInHandIndex and RightInHandIndex from mixamo_fff.xml

Yeah, now i get this:
AnimatedDrawings\animated_drawings\model\quaternions.py:61: RuntimeWarning: invalid value encountered in divide
self.qs = self.qs / np.expand_dims(np.sum(self.qs ** 2.0, axis=-1) ** 0.5, axis=-1)

Yeah, now i get this:
AnimatedDrawings\animated_drawings\model\quaternions.py:61: RuntimeWarning: invalid value encountered in divide self.qs = self.qs / np.expand_dims(np.sum(self.qs ** 2.0, axis=-1) ** 0.5, axis=-1)

Use up: +y instead of up: +z, because the BVH doesn't need to be rotated, See also: Motion Config File
filepath: examples/bvh/rokoko/rokokoDance.bvh
start_frame_idx: 0
end_frame_idx: 559
groundplane_joint: LeftFoot
forward_perp_joint_vectors:
  - - LeftShoulder
    - RightShoulder
  - - LeftUpLeg
    - RightUpLeg
scale: 0.025
up: +y

Thank you for that, it fixed it :)

Your original error message was caused because, depending upon the export options chosen, Rokoko will insert a frame at the beginning of the motion clip with the skeleton's default pose. But it doesn't increment the Frames: count, resulting in an invalid BVH. By manually incrementing the Frames: value, as you did, you can restore it to a valid BVH.

@SchmittFazed @hjessmith How did you fix the Frames issue? What kind of export settings of Rokoko did you use? I tried many export option combinations and manually increment the Frames number in bvh file, but non works for me. Many Thanks!


Update metadata cleanup to delete only expired files non needed to time travel for non expired versions

This PR updates the metadata cleanup behavior to delete only expired files non needed to time travel to non expired version.
Current behavior:
A Delta log is deleted when it's older than the retention period and there's a checkpoint file after it. The problem with such logic is that it can lead to situations where time travel is not available for non expired versions. this issue shows an example of that.
Proposed behavior:
when an expired file is needed to time travel for a non expired version, we keep it in the transaction log. We only cleanup expired logs when they are no longer needed to time travel to any non expired version.

closes issues #255 and #616

Hi @JassAbidi. Thanks for this PR. As of now we do not consider this issue to be a bug, though we may consider in the future revisiting this and implementing something similar to your solution here.
In Delta Lake 1.1 docs here, we've added a note explaining that this can happen and that increasing delta.logRetentionDuration can help avoid these situations.


[Dropdown Modal] using ItemIndicator inside SubTrigger causes flickering of sub menu

Bug report
Current Behavior
Using ItemIndicator inside SubTrigger causes flickering of sub menu
https://github.com/user-attachments/assets/5fc8c0ed-4d39-48de-8f98-a1e5952c97ec
       <DropdownMenuSub>           <DropdownMenuSubTrigger>             <CheckboxItem option={option} />               </DropdownMenuSubTrigger>           <DropdownMenuPortal>             <DropdownMenuSubContent>               {option?.children?.map((child) =>
{child.name}
)}             </DropdownMenuSubContent>           </DropdownMenuPortal>         </DropdownMenuSub>
Expected behavior
No flickering when drag cursor.
Your environment

Software
Name(s)
Version

Radix Package(s)
"@radix-ui/react-dropdown-menu"
"^2.1.1"

React
n/a

Browser

Assistive tech

Node
n/a

npm/yarn

Operating System

Same here, and same as production bundle.


Add a license

This repo seems to be unmaintained. The current code (without #4) cannot work. Still, I think there is some value in the code base.
In order to be able to reuse and fork what is currently there, a license file would help very much.
I think MIT is a good choice if you want to allow people to freely reuse the code. If you're willing to license the repo as MIT, you can copy a version from Github including line breaks and change the copyright date and name.

Yeah, I used this for a project over a year ago and haven't revisited since. I'm happy to merge things in, but I do not have the context set up to test them right now. Open a PR and I'll merge so you can make a valid fork :+1:

https://github.com/ssalinas/facebook_posts/commit/1eb543aa13ace7e060070646bb96cf407244f230

Great, thank you! I guess it is easier for you when I maintain my fork, right?


Use DEL for backspace

Description
Use DEL (0x7F) instead of BS (0x08) for backspace/erase. This is the
default for most Linux terminals (and works on Windows too).
See also:

https://www.asciihex.com/character/control/127/0x7F/del-delete-character
https://vi.stackexchange.com/a/3120

Fixes #178
Type of change
Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?
Confirmed that backspace key works as expected with:

zsh on Linux using both my personal config which previous failed due to ^H binding
zsh on Linux using stock config (zsh -f)
bash on Linux using stock config
Windows with cmd.exe
Windows with powershell

Test Configuration:

OS: See above
Go version: 1.11.5

Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules

Not sure what happened with travis, reopened this here: https://github.com/liamg/aminal/pull/231


Append always .title to navi i18n keys

With that change we avoid the conflict with our branding branch for the future.

+1 (We just have to make sure to fix the branding patch once more when merging this)

+1

The branding branch is totally fine (https://github.com/SUSE-Cloud/crowbar-core/blob/master-branding/crowbar_framework/config/locales/crowbar/en.yml#L82-L86). Who wants to update the patch? I would suggest @rsalevsky :)
Than we can merge this.

Merging, packages will be rebuilt now by @rsalevsky


Inventory Charger Crash

What happens:
It crashes when I activate the inventory charger and open the inventory. (Sometimes it crashes just by activating it.)
And I can't enter the world.
Only if Baubles is installed ?
Steps to reproduce:

activate any inventory charger
open the inventory

Affected Versions (Do not use "latest"):
-EnderIO: 5.3.67
-EnderCore: 0.5.76
-Baubles: 1.5.2
-Minecraft: 1.12.2
-Forge: <IP_ADDRESS>55
-SpongeForge? no
-Optifine? no
-Single Player
(Sorry for poor English.)
crash-2021-05-26_19.46.17-server.txt

Fixed successfully in Ender IO - 5.3.68
Thank you XD


Add Expose Port

Need add Expose 8080 for use over different proxy without external forwarding. Rancher for example mean that host inactive. EXPOSE in config must resolve this issue

Hi,
Exposing the ports should be done in the docker-compose file. Is there some other issue with the configuration? Where are you suggesting to add an expose? The Dockerfile?


[Security] Potential Secret Leak

It has been noticed that while using chromaui/action@v1 your projectToken t00yilwkcv is present in plaintext. Please ensure that secrets are encrypted or not passed as plain text in github workflows.

Thanks @raima-zachariah for the notice! I created a PR fixing this and the Chromatic token was regenerated so it is no longer the one leaked.


Add sort panel

Q
A

Bug fix?
no

New feature?
yes

New sample?
no

Related issues?
/

What's in this Pull Request?
An extra panel so the user can apply sorting to the list.
Guidance

Changing the properties of the webpart and setting SortList still has the same behaviour. (Sorting the list when entering the page).
When changing the properties of the webpart (screen 2 of 3) an extra field is available to set the list of fields available to the user for sorting the search results (format is the same as the format for adding refinement fields)
When sortable fields are available, an extra button will appear on the results webpart (next to the filter icon, there now should be a sort icon)
The user can click the sort icon to popup the new sort panel
The user can now select the field to sort the list on and the sort order (ascending/descending)

Thank you for this PR @stijnbrouwers! This is a great feature. Few things I see at first glance:

The initial WP instanciation fails (local/hosted):

README documentation is missing
Scenario when a managed property is not sortable not supported. Try with "FileType", the WP fails silently and get stuck forever.

Please fix these issues first and let me know.

@FranckyC thanks for the quick feedback. I fixed the 2 issues, I only need to change the readme file. I will do that later, but what exactly are you expecting in the README file?

Change the screenshots of the property pane
Add the extra fields to the 'Search Settings' table
Is there anything else I'm missing that you would expect?

@stijnbrouwers Yes, just fill the parameter table accordingly and provide hints about how this option works.

@stijnbrouwers Thanks for updates. Would it be possible for you to merge your things with the latest version of this WP. I've made some updates today that have been merged in the dev branch already. This way, the PR review will be easier to review.
Thanks!

@FranckyC Working on it right now :-) Am testing the merge but had some trouble...  hope to finish it today!

@FranckyC I'm putting this on hold for now...
For Some reason when merged, I can't have 2 panels.
One I add even an empty panel for the sort, the one for the filters won't open anymore...

@stijnbrouwers no worries. Just let us know when it will be ready

@FranckyC Allright, it should be OK now!

@stijnbrouwers seems ok except:

Missing localizations in SortPanel.tsx
Please reset the hasError state in componentReceiveProps in SearchResultsContainer.tsx. When there is an error on sortable fields, the user can't revert back easily otherwise.

    public async componentWillReceiveProps(nextProps: ISearchContainerProps) {

        let query = nextProps.queryKeywords + nextProps.searchService.queryTemplate + nextProps.selectedProperties.join(',');

        // New props are passed to the component when the search query has been changed
        if (JSON.stringify(this.props.refiners) !== JSON.stringify(nextProps.refiners)
            || JSON.stringify(this.props.sortableFields) !== JSON.stringify(nextProps.sortableFields)
            || this.props.sortList !== nextProps.sortList
...

I would rename the SortOrder class to SortDirection because it is pretty misleading in the code (this is not really an "order"). You have a SortDirection class already available form PnP, maybe you can reuse this one at some point.

You have a typo in _onUpdateSort preventing sort direction to work. Use lower case sortOrder instead.

this.props.searchService.sortList = `${sortField}:${SortOrder}`;

@FranckyC OK the changes should be implemented. I just wasn't sure what to do for the second remark (componentReceiveProps) but I did what I think you requested.

Thanks @stijnbrouwers. @wobba I think it is ok, you can review it if you want and merge it works for you.

@stijnbrouwers  Looking at the PR it seems my last commit is not included (checked the readme) Could you do a last merge with the dev branch, and I’ll review and merge most likely on Monday.

@wobba I just merged it, thanks for reviewing and have a nice weekend!


E2E tests added

Fixes: https://github.com/ppc64le-cloud/powervs-csi-driver/issues/3

/approve
/hold

test is working fine :P
/approve cancel

can this be closed?

This PR can be closed as it is not suitable for merging.


fix: failure when uncommitted git changes

:tada: This PR is included in version 1.2.3 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Typing of canvas from CanvasRenderingContext2D is too restrictive when extending HTMLCanvasElement

Bug Report

🔎 Search Terms

htmlcanvaselement getcontext canvasrenderingcontext2d canvas this
🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about canvas.

⏯ Playground Link

Playground link with relevant code
💻 Code

class MyCustomCanvas extends HTMLCanvasElement {
    myCustomProp: number;

    constructor(value?: number) {
        super();
        this.myCustomProp = value || 42;
    }
}

customElements.define('custom-canvas', MyCustomCanvas, { extends: 'canvas' });

const canvas = new MyCustomCanvas(22);
const context = canvas.getContext('2d');
if (context) {
    // Property 'myCustomProp' does not exist on type 'HTMLCanvasElement'.(2339)
    console.log(context.canvas.myCustomProp); // Output: 22.
    console.log(context.canvas instanceof MyCustomCanvas); // Output: true.
}

🙁 Actual behavior
The back reference canvas of CanvasRenderingContext2D is wrongly typed to HTMLCanvasElement rather than the actual class that created it.
🙂 Expected behavior
I suggest adding a generic type to CanvasRenderingContext2D like this :
interface CanvasRenderingContext2D<T extends HTMLCanvasElement> extends ... {
    readonly canvas: T;
}

Then update the defintion of getContext of  HTMLCanvasElement:
// From :
getContext('2d'): CanvasRenderingContext2D | null;
// To :
getContext('2d'): CanvasRenderingContext2D<this> | null;

Wouldn't that raise an compilation error ? Since your overload of getContext is returning a CanvasRenderingContext2D<HTMLCanvasElement> instead of CanvasRenderingContext2D<MyCustomCanvas>.

Wouldn't that raise an compilation error ? Since your overload of getContext is returning a CanvasRenderingContext2D<HTMLCanvasElement> instead of CanvasRenderingContext2D<MyCustomCanvas>.

Well, the issue "has seen no recent activity" because I got no reply to my question... ^^'

Well, the issue "has seen no recent activity" because I got no reply to my question... ^^'

I guess the proposal (this was confusing since you used the bug template instead of the DOM change template) is to change the DOM definition to make this scenario work out of the box? That would not meet our complexity bar IMO

I guess the proposal (this was confusing since you used the bug template instead of the DOM change template) is to change the DOM definition to make this scenario work out of the box? That would not meet our complexity bar IMO

My suggestion was indeed to change the typing of the DOM in Typescript itself, sorry for the mistake. What do you mean by "complexity bar" ?

My suggestion was indeed to change the typing of the DOM in Typescript itself, sorry for the mistake. What do you mean by "complexity bar" ?


How to use

Refer to "Option 1 – Using with browser's devtools" and can't get expected result.

@lxfu1 Make sure the following conditions are met:

a <script> with correct url to react-render-tracker.js is injected to the page (its HTML)
check on the Network tab in devtools, if this script is downloading with no errors (may to be rejected for some reasons)
a page with injected <script> is not in a <iframe>
there are no CSP related error on console
there are no any other error related to the react-render-tracker.js

There were some issues that may caused such a problem. Please, try latest version 0.4 which just published. I rewrite readme, now it also has an option to open UI right in the page  (Option #0 in the readme). You can try it if option 1 is still not working for you.
I'm closing the issue since no additional details or comments on the issue. Feel free to reopen it if the problem is still here.


PR: Improve performance of workspace watcher (Projects)

Description of Changes

Switch from the Watchdog OS-based observer to the polling one because it emits less events on Linux and behaves better on Windows (it doesn't seem to be problems on Mac, but we prefer to have a single solution for all OSes).
Exclude binary files and hidden directories from the watcher.
Exclude directories such as __pycache__ and build from the watcher too.
Throttle changes reported by the watcher to avoid sending too many events to LSP servers.

Issue(s) Resolved
Part of #10664.
Affirmation
By submitting this Pull Request or typing my (user)name below,
I affirm the Developer Certificate of Origin
with respect to all commits and content included in this PR,
and understand I am releasing the same under Spyder's MIT (Expat) license.

I certify the above statement is true and correct:

Hello @ccordoba12! Thanks for opening this PR. We checked the lines you've touched for PEP 8 issues, and found:

In the file spyder/plugins/projects/utils/watcher.py:

Line 120:21: E251 unexpected spaces around keyword / parameter equals
Line 120:23: E251 unexpected spaces around keyword / parameter equals


Hardcoded Chart Labels

When I create a full tearsheet using a different benchmark, I am unable to change the benchmark label for the stress test charts to reflect my benchmark (Not the SPY), and I also don't want the algorithm to be labeled "algo" because it looks unprofessional.

This can easily be fixed by changing the following lines of code in this file to inherit column names from the objects being passed into the function:

https://github.com/quantopian/pyfolio/blob/master/pyfolio/tears.py

Yes, great points. Want to submit a PR?


finished quiz

Score 3.5/5
Good job. I can see from your comment that you knew what you had to do, but jQuery wasnt cooperating. Just remember that when dealing with inputs with names, you target them with $('input[name="temp-c"') syntax, and to get at the data inside of the boxes you need to use .val()


button colors are off.

button color is wrong, see design below

button design:
https://www.figma.com/file/bZh7tOiLm6Ls9Hl4RL6qMC5X/Augur-Redesign?node-id=7833%3A196490

@JohnDanz  Close this along with the other colors please.

This looks like it was fixed already, closing


Configuration for Whoops error handler

When going through the docs I've come up with a basic configuration. The 404 pages do render as expected but the error/error is empty.
return [
    'dependencies' => [
        'invokables' => [
            'Zend\Expressive\Whoops' => Whoops\Run::class,
            'Zend\Expressive\WhoopsPageHandler' => Whoops\Handler\PrettyPageHandler::class,
        ],
        'factories' => [
            'Zend\Expressive\FinalHandler' => Zend\Expressive\Container\WhoopsErrorHandlerFactory::class,
        ],
    ],

    'whoops' => [
        'json_exceptions' => [
            'display'    => true,
            'show_trace' => true,
            'ajax_only'  => true,
        ],
    ],

    'zend-expressive' => [
        'error_handler' => [
            'template_404'   => 'error::404',
            'template_error' => 'error::error',
        ],
    ],
];

When using the TemplatedErrorHandlerFactory it does work as expected (in combination with Twig):
'Zend\Expressive\FinalHandler' => Zend\Expressive\Container\TemplatedErrorHandlerFactory::class,

This is how the error is triggered inside middleware:
return $next($request, $response, new \Exception('Oh no!'));

Did I miss something in the configuration?

There is no error handler pushed. That's why the pages are empty on errors. I've created a pull request for this: #125


Why are these types not in the standard library?

I'm asking myself, if these are faster why aren't they in libstd? I think read something about platform limitations, but it's not really clear why the standard library has to use platform-specific types. I also saw other people wondering about this, might be worth adding it to the README.

See rust-lang/rfcs#1632.

Great, thanks! I think I'll be using this crate only then. :+1:

@alexcrichton mentioned getting this in the nursery. Is that a possibility?

In https://github.com/rust-lang/rust/issues/53127#issuecomment-417032962 it is mentioned that Rust might be more likely to accept parking_lot into the standard library (even rustc uses parking_lot).
It's probably needed to write another RFC to make that change though. I don't think I have the necessary expertise to write it. If someone were interested in this and had some time, it would be nice if they could write it. :)
One more possible concern that didn't get mentioned in the original RFC thread would be whether the code size of parking_lot is bigger than the one of the synchronization primitives in libstd.


Docs: Adds metrics guide

Hi @dcfidalgo and @frascuchon. It would be great to be to visualize Plotly plots in the docs. However, there seems to be a long pending issue with the interplay between rtd theme/sphinx and the plotly.js bundle. You can see the console error here:
https://rubrix.readthedocs.io/en/docs-metrics_guide/guides/metrics.html

The main resources that I found for trying to solve this issue are (I've tried two things with no luck, see commits):
https://github.com/readthedocs/sphinx_rtd_theme/issues/788
https://stackoverflow.com/questions/46269345/embed-plotly-graph-in-a-sphinx-doc
@dcfidalgo could you take a quick look when you have some free slot?

@frascuchon I see some new commits, did you manage to solve this issue?

All related work will be done in #544


[APM Onboarding] Set defaults resources for injected init-containers

-->
What does this PR do?
Adds default CPU and memory resources for init containers injected during APM Instrumentation. Init-containers only do a basic cp, so limiting defaults to  10m CPU and 20Mi memory.
Motivation
Some Kubernetes environments/distributions it is mandatory to provide CPU/Memory Request/Limit and missing defaults leads to application pod creation errors.
Additional Notes
Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Reviewer's Checklist

[x] If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
[x] Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
[x] A release note has been added or the changelog/no-changelog label has been applied.
[x] Changed code has automated tests for its functionality.
[x] Adequate QA/testing plan information is provided. Except if the qa/skip-qa label, with required either qa/done or qa/no-code-change labels, are applied.
[x] At least one team/.. label has been applied, indicating the team(s) that should QA this change.
[x] If applicable, docs team has been notified or an issue has been opened on the documentation repo.
[x] If applicable, the need-change/operator and need-change/helm labels have been applied.
[x] If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
[x] If applicable, the config template has been updated.

/merge


Ionide locks DLLs even with shadowcopyreferences

Describe the bug
Using the --shadowcopyreferences+ should stop locking DLLs when #r is used. However, it appears to still lock them regardless.
Steps to reproduce

Create a .NET DLL.
Reference it from a script.
Rebuild that DLL.

If you do the same directly with dotnet fsi, the DLL is not locked.
Note, I have indeed added the --shadowcopyreferences+ argument to FSI in VS Code settings and confirmed that it is getting "read" because I also used --nologo and that has taken effect.

Do you have FSI Watcher enabled (FSharp.addFsiWatcher)? I can imagine that it can be locking all the assemblies.

might also just be an artifact of longer-lived FSI sessions - does it reproduce if you close the FSI session or start a new one before sending the changed file?

@Krzysztof-Cieslak just checked, no.


Rename Application to "Notify"

When I launch Spotify from Spotlight, more often than not the first suggestion for "Spotify" is "Spotify Notifications". As soon as I see the Spotify icon appear for "Spotify Notifications", I usually press enter, and the "Spotify Notifications" application launches. In my opinion this is slightly more user hostile than it needs to be. Obviously, this is a case of me being too quick to pull the trigger on the wrong application, and perhaps I need to slow down.
A workaround that I have used so far has been to rename the Application "Notify", but thought I'd open it up for suggestion here too.

+1 on renaming the application to something that doesn't start with the characters "Spotify" for the stated reason.

Another workaround is:

Open Spotlight Preferences on the Privacy tab
Drag the Spotify Notifications app to the Privacy pane
Spotify Notifications should no longer appear in the suggestions list

Note: If using Alfred, type reload into Alfred and select Reload Alfred cache


folder demo_paper

Is this folder still needed/used ? I don't see where in the files.
If not, it can be removed.

This folder is /was a case study to explain PBxplore functionalities in the research paper we are going to publish.
I have to update it with all the modifications we made.
Le 16 octobre 2015 10:03:05 GMT+01:00, Hub<EMAIL_ADDRESS>a écrit :

Is this folder still needed/used ? I don't see where in the files.
If not, it can be removed.

Reply to this email directly or view it on GitHub:
https://github.com/pierrepo/PBxplore/issues/95

--
Pierre Poulain
http://cupnet.net

Okay. I was cleaning the depot for the packaging and I was wondering.

However, the demo_paper folder should be outside the package.

The question is answered so I close the issue.


Add option to disable animation

Adding a bool "Animated" BindableProperty to enable or disable animation.
Having option to show the animation or not would be nice to have.
If implemented, the SKCanvasView have to be invalidated animated or not after IsCheckedChanged event to redraw the canvas.
In rare instances, spamming the Checkbox will throw a InvalidOperationException due to the animation Task index getting mixed up.

That's a valid request. Will get that in in coming release 👍


Provide links to older OC server versions (archive)

Similar to https://github.com/owncloud/owncloud.org/issues/395 but for the server version.
It was requested here for people who wanted to test upgrading to an older version: https://github.com/owncloud/core/issues/12801#issuecomment-72591111

We already link to older versions at https://owncloud.org/changelog – RCs are however not linked.

I think there's little point in linking to old RC's, sorry... In the thread the old tarball was found and indeed, a google search can find it too as it's announced on the ML's too. I would keep it at that.

From my perspective, it would be really nice, if there was a hint on the download page that changelog == download links (just add it in the modal here: https://owncloud.org/install/).
Reason is, I literally found out by using Google and clicking on one of the first hits, that brought me straight to this issue page. Could be a lead I'm not the only one? 😄

@te-online https://owncloud.org/install/#instructions-server -> Looking for older versions or major releases? -> https://owncloud.org/changelog -> Profit :-)

@RealRancor Oh, wow, embarrassing! 😳
But honestly, maybe it's me or maybe it's the layout suggesting, that below a screenshot there will be no interesting information other than a caption. I've spent more than a few seconds on the screen and even desperately clicked on ”release channels“ before changing my strategy to using Google.
Anyways, it's there and that's a plus 👍

@te-online I think improvement suggestions for a better visible placement are always welcome in a new created issue.


TypeError when deserializing keys named "infinity"

$python3
Python 3.6.7 (default, Oct 22 2018, 11:32:17)
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import luadata
>>> data={'infinity':'string'}
int(dat>>> print(data)
{'infinity': 'string'}
>>> ser=luadata.serialize(data, form=False)
rint(ser)
deser=luadat>>> print(ser)
{infinity="string"}
a.unseri>>> deser=luadata.unserialize(ser)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/ivan/.local/lib/python3.6/site-packages/luadata/io/read.py", line 159, in unserialize
    return StreamData(src_data, 0).read_item()
  File "/home/ivan/.local/lib/python3.6/site-packages/luadata/io/read.py", line 140, in read_item
    return self.read_table()
  File "/home/ivan/.local/lib/python3.6/site-packages/luadata/io/read.py", line 99, in read_table
    item = self.read_item()
  File "/home/ivan/.local/lib/python3.6/site-packages/luadata/io/read.py", line 140, in read_item
    return self.read_table()
  File "/home/ivan/.local/lib/python3.6/site-packages/luadata/io/read.py", line 104, in read_table
    table[StreamData.format_key(item)] = self.read_item()
  File "/home/ivan/.local/lib/python3.6/site-packages/luadata/io/read.py", line 33, in format_key
    if key[0] == '[':
TypeError: 'float' object is not subscriptable
>>>

$ python3 -m pip show luadata
Name: luadata
Version: 0.2.1
Summary: Serialize and unserialize Python list & dictionary between Lua table.
Home-page: https://github.com/leafvmaple/luadata
Author: Zohar Lee
Author-email<EMAIL_ADDRESS>License: BSD License
Location: /home/ivan/.local/lib/python3.6/site-packages
Requires:

The string value "infinity" appears to being recognized as a float by python.
https://github.com/leafvmaple/luadata/blob/v0.2.1/luadata/io/read.py#L14-L19
My local fix was to explicitly detect and avoid this explicit case.
     @staticmethod
     def isfloat(string):
+        if string == "infinity":
+            return False
         try:
             float(string)
         except ValueError:
             return False
         return True

This is also true for "inf", and also applies when prefixed with "+" or "-":
>>> float("+infinity")
inf
>>> float("-infinity")
-inf
>>> float("inf")
inf
>>> float("+inf")
inf
>>> float("-inf")
-inf

There may be other cases that need to be taken into account as well - these are just the ones that occurred to me off the top of my head.

Also the same for "NaN":
>>> float("NaN")
nan
>>> float("+NaN")
nan
>>> float("-NaN")
nan
>>> float("-nan")
nan
>>> float("nan")
nan


StoreFront, Director and NetScaler Checks Over SSL

Been reported that these checks are not working correctly when using SSL

By changing to the correct port and protocol, it has worked for me.  Perhaps these are self-signed certs?

This is probably due to the TLS and self signed certs.  Probably need to put in a check for HTTPS and set PowerShell to use TLS 1.1 or 1.2 and ignore selfsigned.

Still getting errors with Storefront checks. Errors: HTTPSUrl failed
It passes HTTPURL which means URL is correct. Also passing Valid-Cert.
Certificate is wildcard certificate issued by Thawte
anytheaks required in *.json file ?
VERBOSE: Starting Test-Series on Storefront.
VERBOSE: Initializing Results...
VERBOSE: Loading config from euc-monitoring.json
VERBOSE: Loading the configuration for the Storefront series
VERBOSE: Connecting to Server: ctxsfp01.corp.ad
VERBOSE: Connection to ctxsfp01.corp.ad successful
VERBOSE: Series Storefront - Connection Successful to ctxsfp01.corp.ad
VERBOSE: Testing ctxsfp01.corp.ad - Port 80
VERBOSE: Success ctxsfp01.corp.ad - Port 80
VERBOSE: Testing ctxsfp01.corp.ad - Port 443
VERBOSE: Success ctxsfp01.corp.ad - Port 443
VERBOSE: ctxsfp01.corp.ad performing HTTPUrl
VERBOSE: Testing URL: http://ctxsfp01.corp.ad:80/Citrix/PnOGRThinStoreWeb
VERBOSE: Connecting to URL: http://ctxsfp01.corp.ad:80/Citrix/PnOGRThinStoreWeb
VERBOSE: ctxsfp01.corp.ad performing HTTPSUrl
VERBOSE: Testing URL: https://ctxsfp01.corp.ad:443/Citrix/PnOGRThinStoreWeb
VERBOSE: Connecting to URL: https://ctxsfp01.corp.ad:443/Citrix/PnOGRThinStoreWeb
VERBOSE: ctxsfp01.corp.ad performing ValidCert
VERBOSE: Testing Valid Cert on ctxsfp01.corp.ad Port: 443
VERBOSE: ComputerName: ctxsfp01.corp.ad
VERBOSE: State: DEGRADED
VERBOSE: Ports Up: 80 443
VERBOSE: PortsDown:
VERBOSE: ServicesUp:
VERBOSE: ServicesDown:
VERBOSE: ChecksUp: HTTPUrl ValidCert
VERBOSE: ChecksDown: HTTPSUrl
VERBOSE: CheckData:
VERBOSE: Errors: HTTPSUrl failed

Issue was that certs were issued with different fqdn for subject name.
Exception calling "GetResponse" with "0" argument(s): "The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel."

If we temporarily trust all ssl/tls connections for the session, we could get around it, but that's a different can of worms.

Issued confirmed resolved


[Node.js Tools 1.2 Alpha] Automatic Typing from TSD

Is there a setting where i can turn off auto install typings ?
When I opened the solution, I found tsd installing typescript definitions for all my packages based on package.json file. It's a good feature. But I am trying to understand the user experience aspect of this.
Most of my team members are mac users, and do not use visual studio. Should the newly added typings files  be included to version control,  So that everyone can leverage type definitions ?
On a side note, I observed, tsd installed several type definitions based on the package.json, only the first typedefinition, and it's respective folder was included to my nodejs project file.

Thanks for the feedback. Checkout this wiki page for some more background on the typings aquisition: https://github.com/Microsoft/nodejstools/wiki/Automatic-Typings-Acquisition
There is no way to disable this feature on its own, but switching off of 'ES6 Intellisense' to will stop automatic typing acquisition (although there's a bug in the current alpha where that is not actually the case).
For working cross platform, I suggest treading the typings files like the node_modules directory and updating your .gitignore to ignore both typings and tsd.json. These file will be recreated automatically for any users on NTVS, so I do not think including them in source control is necessary.


IndexedDB fails to open

I don't have steps to reproduce, but it happens often enough that it's a problem for us. Somehow indexedDB gets into a state where it doesn't respond. Even if I try indexedDB.open('dbName') it never calls the onsuccess callback. The only way around it for me is if I either restart my browser or go into dev tools and click Clear site data in chrome. Safari, I've had to clear all history. Any ideas on what might be causing it? It also might be happening with webSQL as well.

I'm also having this issue. For whatever reason IndexedDB just hangs and stops responding completely. I tried to clear via Dev Tools > Application > Clear Storage > Clear Site Data, it seems to not respond to being cleared. Hard to tell if it's a bug in chrome or if it's localForage that's causing it? For now, I've switched to the WebSQL driver; you can do the same like so :
localforage.createInstance({
	name:"forage_name",
	storeName:"store_name",
	description:"...",
	driver:[localforage.WEBSQL,localforage.INDEXEDDB],
}),

The IndexedDb driver is still used as a fallback, but Web SQL will be used by default.

Is this happening only in Safari and Chrome? Or is it reproducible in other, non-WebKit-based browsers? It would be helpful to have more info here as this is not very easily reproducible from the issue so far, but is obviously a pretty severe bug that would be great to fix 🙂