Homematic HM-CC-TC not recognized

Home Assistant release with the issue:
0.96.4
Last working Home Assistant release (if known):
0.95.x
Operating environment (Hass.io/Docker/Windows/etc.):
Hass.io
Component/platform:
Homematic
Description of problem:
Since Update to HA 0.96 my old Homematic Thermostat HM-CC-TC is not found as a climate-entity anymore. The device is only recognized as a temperature and humidity sensor. With HA 0.95 is worked perfect!
Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
homematic:
  interfaces:
    rf:
      host: <IP_ADDRESS>
      resolvenames: json

Traceback (if applicable):
Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 365, in _async_add_entity
    await entity.async_update_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 226, in async_update_ha_state
    self._async_write_ha_state()
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 256, in _async_write_ha_state
    attr.update(self.state_attributes or {})
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 213, in state_attributes
    data[ATTR_PRESET_MODE] = self.preset_mode
  File "/usr/src/homeassistant/homeassistant/components/homematic/climate.py", line 98, in preset_mode
    mode = HM_ATTRIBUTE_SUPPORT[HM_CONTROL_MODE][1][self._hm_controll_mode]
  File "/usr/src/homeassistant/homeassistant/components/homematic/climate.py", line 181, in _hm_controll_mode
    return self._data['CONTROL_MODE']
KeyError: 'CONTROL_MODE'

Additional information:

+1
I also encounter that issue.

+1
Same problem here. Generation 2 (HM-CC-RT-DN) gets recognised correctly.

+1
At least this happened during a heat wave ;-)

+1 same here

+1
I believe it is related to pyhomematic/device_types/thermostats.py...
All thermostats except the HM-CC-TC got a CONTROL_MODE or SET_POINT_MODE key with the update of the new climate component.
It seems HM-CC-TC's operating modes "Manu", Auto, Cent and Prog are all internal and cannot
be accessed.

Was using FHEM long time ago. With FHEM I‘ve set the modes, that you are talking about. FHEM wiki states, that „manu“, „auto“ and „cent“ can be set. I personally am in no need for those modes, as I use HA to control the heating...

fhem - I remember, long time ago...
But I found where it is. Many HM devices have a VALUES and a MASTER param set.
Channel :2 of a HM-CC-TC also has a MASTER param set.
getParamset("GEQ0004703:2", "MASTER", 0) returns
{   "DECALCIFICATION_DAY": 0,   "DECALCIFICATION_HOUR": 11,   "DECALCIFICATION_MINUTE": 0,   "DISPLAY_TEMPERATUR_HUMIDITY_CHANGE": 1,   "DISPLAY_TEMPERATUR_INFORMATION": 0,   "DISPLAY_TEMPERATUR_UNIT": 0,   "MODE_TEMPERATUR_REGULATOR": 0,   "MODE_TEMPERATUR_VALVE": 0,   "PARTY_END_TIME": 0,   "TEMPERATUR_COMFORT_VALUE": 21,   "TEMPERATUR_FRIDAY_1": 17,   "TEMPERATUR_FRIDAY_10": 20,   "TEMPERATUR_FRIDAY_11": 20,   "TEMPERATUR_FRIDAY_12": 20,   "TEMPERATUR_FRIDAY_13": 20,   "TEMPERATUR_FRIDAY_14": 20,   "TEMPERATUR_FRIDAY_15": 20,   "TEMPERATUR_FRIDAY_16": 20,   "TEMPERATUR_FRIDAY_17": 20,   "TEMPERATUR_FRIDAY_18": 20,   "TEMPERATUR_FRIDAY_19": 20,   "TEMPERATUR_FRIDAY_2": 21,   "TEMPERATUR_FRIDAY_20": 20,   "TEMPERATUR_FRIDAY_21": 20,   "TEMPERATUR_FRIDAY_22": 20,   "TEMPERATUR_FRIDAY_23": 20,   "TEMPERATUR_FRIDAY_24": 20,   "TEMPERATUR_FRIDAY_3": 21,   "TEMPERATUR_FRIDAY_4": 17,   "TEMPERATUR_FRIDAY_5": 20,   "TEMPERATUR_FRIDAY_6": 20,   "TEMPERATUR_FRIDAY_7": 20,   "TEMPERATUR_FRIDAY_8": 20,   "TEMPERATUR_FRIDAY_9": 20,   "TEMPERATUR_LOWERING_VALUE": 17,   "TEMPERATUR_MONDAY_1": 17,   "TEMPERATUR_MONDAY_10": 20,   "TEMPERATUR_MONDAY_11": 20,   "TEMPERATUR_MONDAY_12": 20,   "TEMPERATUR_MONDAY_13": 20,   "TEMPERATUR_MONDAY_14": 20,   "TEMPERATUR_MONDAY_15": 20,   "TEMPERATUR_MONDAY_16": 20,   "TEMPERATUR_MONDAY_17": 20,   "TEMPERATUR_MONDAY_18": 20,   "TEMPERATUR_MONDAY_19": 20,   "TEMPERATUR_MONDAY_2": 21,   "TEMPERATUR_MONDAY_20": 20,   "TEMPERATUR_MONDAY_21": 20,   "TEMPERATUR_MONDAY_22": 20,   "TEMPERATUR_MONDAY_23": 20,   "TEMPERATUR_MONDAY_24": 20,   "TEMPERATUR_MONDAY_3": 21,   "TEMPERATUR_MONDAY_4": 17,   "TEMPERATUR_MONDAY_5": 20,   "TEMPERATUR_MONDAY_6": 20,   "TEMPERATUR_MONDAY_7": 20,   "TEMPERATUR_MONDAY_8": 20,   "TEMPERATUR_MONDAY_9": 20,   "TEMPERATUR_PARTY_VALUE": 20,   "TEMPERATUR_SATURDAY_1": 17,   "TEMPERATUR_SATURDAY_10": 20,   "TEMPERATUR_SATURDAY_11": 20,   "TEMPERATUR_SATURDAY_12": 20,   "TEMPERATUR_SATURDAY_13": 20,   "TEMPERATUR_SATURDAY_14": 20,   "TEMPERATUR_SATURDAY_15": 20,   "TEMPERATUR_SATURDAY_16": 20,   "TEMPERATUR_SATURDAY_17": 20,   "TEMPERATUR_SATURDAY_18": 20,   "TEMPERATUR_SATURDAY_19": 20,   "TEMPERATUR_SATURDAY_2": 21,   "TEMPERATUR_SATURDAY_20": 20,   "TEMPERATUR_SATURDAY_21": 20,   "TEMPERATUR_SATURDAY_22": 20,   "TEMPERATUR_SATURDAY_23": 20,   "TEMPERATUR_SATURDAY_24": 20,   "TEMPERATUR_SATURDAY_3": 21,   "TEMPERATUR_SATURDAY_4": 17,   "TEMPERATUR_SATURDAY_5": 20,   "TEMPERATUR_SATURDAY_6": 20,   "TEMPERATUR_SATURDAY_7": 20,   "TEMPERATUR_SATURDAY_8": 20,   "TEMPERATUR_SATURDAY_9": 20,   "TEMPERATUR_SUNDAY_1": 17,   "TEMPERATUR_SUNDAY_10": 20,   "TEMPERATUR_SUNDAY_11": 20,   "TEMPERATUR_SUNDAY_12": 20,   "TEMPERATUR_SUNDAY_13": 20,   "TEMPERATUR_SUNDAY_14": 20,   "TEMPERATUR_SUNDAY_15": 20,   "TEMPERATUR_SUNDAY_16": 20,   "TEMPERATUR_SUNDAY_17": 20,   "TEMPERATUR_SUNDAY_18": 20,   "TEMPERATUR_SUNDAY_19": 20,   "TEMPERATUR_SUNDAY_2": 21,   "TEMPERATUR_SUNDAY_20": 20,   "TEMPERATUR_SUNDAY_21": 20,   "TEMPERATUR_SUNDAY_22": 20,   "TEMPERATUR_SUNDAY_23": 20,   "TEMPERATUR_SUNDAY_24": 20,   "TEMPERATUR_SUNDAY_3": 21,   "TEMPERATUR_SUNDAY_4": 17,   "TEMPERATUR_SUNDAY_5": 20,   "TEMPERATUR_SUNDAY_6": 20,   "TEMPERATUR_SUNDAY_7": 20,   "TEMPERATUR_SUNDAY_8": 20,   "TEMPERATUR_SUNDAY_9": 20,   "TEMPERATUR_THURSDAY_1": 17,   "TEMPERATUR_THURSDAY_10": 20,   "TEMPERATUR_THURSDAY_11": 20,   "TEMPERATUR_THURSDAY_12": 20,   "TEMPERATUR_THURSDAY_13": 20,   "TEMPERATUR_THURSDAY_14": 20,   "TEMPERATUR_THURSDAY_15": 20,   "TEMPERATUR_THURSDAY_16": 20,   "TEMPERATUR_THURSDAY_17": 20,   "TEMPERATUR_THURSDAY_18": 20,   "TEMPERATUR_THURSDAY_19": 20,   "TEMPERATUR_THURSDAY_2": 21,   "TEMPERATUR_THURSDAY_20": 20,   "TEMPERATUR_THURSDAY_21": 20,   "TEMPERATUR_THURSDAY_22": 20,   "TEMPERATUR_THURSDAY_23": 20,   "TEMPERATUR_THURSDAY_24": 20,   "TEMPERATUR_THURSDAY_3": 21,   "TEMPERATUR_THURSDAY_4": 17,   "TEMPERATUR_THURSDAY_5": 20,   "TEMPERATUR_THURSDAY_6": 20,   "TEMPERATUR_THURSDAY_7": 20,   "TEMPERATUR_THURSDAY_8": 20,   "TEMPERATUR_THURSDAY_9": 20,   "TEMPERATUR_TUESDAY_1": 17,   "TEMPERATUR_TUESDAY_10": 20,   "TEMPERATUR_TUESDAY_11": 20,   "TEMPERATUR_TUESDAY_12": 20,   "TEMPERATUR_TUESDAY_13": 20,   "TEMPERATUR_TUESDAY_14": 20,   "TEMPERATUR_TUESDAY_15": 20,   "TEMPERATUR_TUESDAY_16": 20,   "TEMPERATUR_TUESDAY_17": 20,   "TEMPERATUR_TUESDAY_18": 20,   "TEMPERATUR_TUESDAY_19": 20,   "TEMPERATUR_TUESDAY_2": 21,   "TEMPERATUR_TUESDAY_20": 20,   "TEMPERATUR_TUESDAY_21": 20,   "TEMPERATUR_TUESDAY_22": 20,   "TEMPERATUR_TUESDAY_23": 20,   "TEMPERATUR_TUESDAY_24": 20,   "TEMPERATUR_TUESDAY_3": 21,   "TEMPERATUR_TUESDAY_4": 17,   "TEMPERATUR_TUESDAY_5": 20,   "TEMPERATUR_TUESDAY_6": 20,   "TEMPERATUR_TUESDAY_7": 20,   "TEMPERATUR_TUESDAY_8": 20,   "TEMPERATUR_TUESDAY_9": 20,   "TEMPERATUR_WEDNESDAY_1": 17,   "TEMPERATUR_WEDNESDAY_10": 20,   "TEMPERATUR_WEDNESDAY_11": 20,   "TEMPERATUR_WEDNESDAY_12": 20,   "TEMPERATUR_WEDNESDAY_13": 20,   "TEMPERATUR_WEDNESDAY_14": 20,   "TEMPERATUR_WEDNESDAY_15": 20,   "TEMPERATUR_WEDNESDAY_16": 20,   "TEMPERATUR_WEDNESDAY_17": 20,   "TEMPERATUR_WEDNESDAY_18": 20,   "TEMPERATUR_WEDNESDAY_19": 20,   "TEMPERATUR_WEDNESDAY_2": 21,   "TEMPERATUR_WEDNESDAY_20": 20,   "TEMPERATUR_WEDNESDAY_21": 20,   "TEMPERATUR_WEDNESDAY_22": 20,   "TEMPERATUR_WEDNESDAY_23": 20,   "TEMPERATUR_WEDNESDAY_24": 20,   "TEMPERATUR_WEDNESDAY_3": 21,   "TEMPERATUR_WEDNESDAY_4": 17,   "TEMPERATUR_WEDNESDAY_5": 20,   "TEMPERATUR_WEDNESDAY_6": 20,   "TEMPERATUR_WEDNESDAY_7": 20,   "TEMPERATUR_WEDNESDAY_8": 20,   "TEMPERATUR_WEDNESDAY_9": 20,   "TIMEOUT_FRIDAY_1": 360,   "TIMEOUT_FRIDAY_10": 1440,   "TIMEOUT_FRIDAY_11": 1440,   "TIMEOUT_FRIDAY_12": 1440,   "TIMEOUT_FRIDAY_13": 1440,   "TIMEOUT_FRIDAY_14": 1440,   "TIMEOUT_FRIDAY_15": 1440,   "TIMEOUT_FRIDAY_16": 1440,   "TIMEOUT_FRIDAY_17": 1440,   "TIMEOUT_FRIDAY_18": 1440,   "TIMEOUT_FRIDAY_19": 1440,   "TIMEOUT_FRIDAY_2": 720,   "TIMEOUT_FRIDAY_20": 1440,   "TIMEOUT_FRIDAY_21": 1440,   "TIMEOUT_FRIDAY_22": 1440,   "TIMEOUT_FRIDAY_23": 1440,   "TIMEOUT_FRIDAY_24": 1440,   "TIMEOUT_FRIDAY_3": 1380,   "TIMEOUT_FRIDAY_4": 1440,   "TIMEOUT_FRIDAY_5": 1440,   "TIMEOUT_FRIDAY_6": 1440,   "TIMEOUT_FRIDAY_7": 1440,   "TIMEOUT_FRIDAY_8": 1440,   "TIMEOUT_FRIDAY_9": 1440,   "TIMEOUT_MONDAY_1": 360,   "TIMEOUT_MONDAY_10": 1440,   "TIMEOUT_MONDAY_11": 1440,   "TIMEOUT_MONDAY_12": 1440,   "TIMEOUT_MONDAY_13": 1440,   "TIMEOUT_MONDAY_14": 1440,   "TIMEOUT_MONDAY_15": 1440,   "TIMEOUT_MONDAY_16": 1440,   "TIMEOUT_MONDAY_17": 1440,   "TIMEOUT_MONDAY_18": 1440,   "TIMEOUT_MONDAY_19": 1440,   "TIMEOUT_MONDAY_2": 720,   "TIMEOUT_MONDAY_20": 1440,   "TIMEOUT_MONDAY_21": 1440,   "TIMEOUT_MONDAY_22": 1440,   "TIMEOUT_MONDAY_23": 1440,   "TIMEOUT_MONDAY_24": 1440,   "TIMEOUT_MONDAY_3": 1380,   "TIMEOUT_MONDAY_4": 1440,   "TIMEOUT_MONDAY_5": 1440,   "TIMEOUT_MONDAY_6": 1440,   "TIMEOUT_MONDAY_7": 1440,   "TIMEOUT_MONDAY_8": 1440,   "TIMEOUT_MONDAY_9": 1440,   "TIMEOUT_SATURDAY_1": 360,   "TIMEOUT_SATURDAY_10": 1440,   "TIMEOUT_SATURDAY_11": 1440,   "TIMEOUT_SATURDAY_12": 1440,   "TIMEOUT_SATURDAY_13": 1440,   "TIMEOUT_SATURDAY_14": 1440,   "TIMEOUT_SATURDAY_15": 1440,   "TIMEOUT_SATURDAY_16": 1440,   "TIMEOUT_SATURDAY_17": 1440,   "TIMEOUT_SATURDAY_18": 1440,   "TIMEOUT_SATURDAY_19": 1440,   "TIMEOUT_SATURDAY_2": 720,   "TIMEOUT_SATURDAY_20": 1440,   "TIMEOUT_SATURDAY_21": 1440,   "TIMEOUT_SATURDAY_22": 1440,   "TIMEOUT_SATURDAY_23": 1440,   "TIMEOUT_SATURDAY_24": 1440,   "TIMEOUT_SATURDAY_3": 1380,   "TIMEOUT_SATURDAY_4": 1440,   "TIMEOUT_SATURDAY_5": 1440,   "TIMEOUT_SATURDAY_6": 1440,   "TIMEOUT_SATURDAY_7": 1440,   "TIMEOUT_SATURDAY_8": 1440,   "TIMEOUT_SATURDAY_9": 1440,   "TIMEOUT_SUNDAY_1": 360,   "TIMEOUT_SUNDAY_10": 1440,   "TIMEOUT_SUNDAY_11": 1440,   "TIMEOUT_SUNDAY_12": 1440,   "TIMEOUT_SUNDAY_13": 1440,   "TIMEOUT_SUNDAY_14": 1440,   "TIMEOUT_SUNDAY_15": 1440,   "TIMEOUT_SUNDAY_16": 1440,   "TIMEOUT_SUNDAY_17": 1440,   "TIMEOUT_SUNDAY_18": 1440,   "TIMEOUT_SUNDAY_19": 1440,   "TIMEOUT_SUNDAY_2": 720,   "TIMEOUT_SUNDAY_20": 1440,   "TIMEOUT_SUNDAY_21": 1440,   "TIMEOUT_SUNDAY_22": 1440,   "TIMEOUT_SUNDAY_23": 1440,   "TIMEOUT_SUNDAY_24": 1440,   "TIMEOUT_SUNDAY_3": 1380,   "TIMEOUT_SUNDAY_4": 1440,   "TIMEOUT_SUNDAY_5": 1440,   "TIMEOUT_SUNDAY_6": 1440,   "TIMEOUT_SUNDAY_7": 1440,   "TIMEOUT_SUNDAY_8": 1440,   "TIMEOUT_SUNDAY_9": 1440,   "TIMEOUT_THURSDAY_1": 360,   "TIMEOUT_THURSDAY_10": 1440,   "TIMEOUT_THURSDAY_11": 1440,   "TIMEOUT_THURSDAY_12": 1440,   "TIMEOUT_THURSDAY_13": 1440,   "TIMEOUT_THURSDAY_14": 1440,   "TIMEOUT_THURSDAY_15": 1440,   "TIMEOUT_THURSDAY_16": 1440,   "TIMEOUT_THURSDAY_17": 1440,   "TIMEOUT_THURSDAY_18": 1440,   "TIMEOUT_THURSDAY_19": 1440,   "TIMEOUT_THURSDAY_2": 720,   "TIMEOUT_THURSDAY_20": 1440,   "TIMEOUT_THURSDAY_21": 1440,   "TIMEOUT_THURSDAY_22": 1440,   "TIMEOUT_THURSDAY_23": 1440,   "TIMEOUT_THURSDAY_24": 1440,   "TIMEOUT_THURSDAY_3": 1380,   "TIMEOUT_THURSDAY_4": 1440,   "TIMEOUT_THURSDAY_5": 1440,   "TIMEOUT_THURSDAY_6": 1440,   "TIMEOUT_THURSDAY_7": 1440,   "TIMEOUT_THURSDAY_8": 1440,   "TIMEOUT_THURSDAY_9": 1440,   "TIMEOUT_TUESDAY_1": 360,   "TIMEOUT_TUESDAY_10": 1440,   "TIMEOUT_TUESDAY_11": 1440,   "TIMEOUT_TUESDAY_12": 1440,   "TIMEOUT_TUESDAY_13": 1440,   "TIMEOUT_TUESDAY_14": 1440,   "TIMEOUT_TUESDAY_15": 1440,   "TIMEOUT_TUESDAY_16": 1440,   "TIMEOUT_TUESDAY_17": 1440,   "TIMEOUT_TUESDAY_18": 1440,   "TIMEOUT_TUESDAY_19": 1440,   "TIMEOUT_TUESDAY_2": 720,   "TIMEOUT_TUESDAY_20": 1440,   "TIMEOUT_TUESDAY_21": 1440,   "TIMEOUT_TUESDAY_22": 1440,   "TIMEOUT_TUESDAY_23": 1440,   "TIMEOUT_TUESDAY_24": 1440,   "TIMEOUT_TUESDAY_3": 1380,   "TIMEOUT_TUESDAY_4": 1440,   "TIMEOUT_TUESDAY_5": 1440,   "TIMEOUT_TUESDAY_6": 1440,   "TIMEOUT_TUESDAY_7": 1440,   "TIMEOUT_TUESDAY_8": 1440,   "TIMEOUT_TUESDAY_9": 1440,   "TIMEOUT_WEDNESDAY_1": 360,   "TIMEOUT_WEDNESDAY_10": 1440,   "TIMEOUT_WEDNESDAY_11": 1440,   "TIMEOUT_WEDNESDAY_12": 1440,   "TIMEOUT_WEDNESDAY_13": 1440,   "TIMEOUT_WEDNESDAY_14": 1440,   "TIMEOUT_WEDNESDAY_15": 1440,   "TIMEOUT_WEDNESDAY_16": 1440,   "TIMEOUT_WEDNESDAY_17": 1440,   "TIMEOUT_WEDNESDAY_18": 1440,   "TIMEOUT_WEDNESDAY_19": 1440,   "TIMEOUT_WEDNESDAY_2": 720,   "TIMEOUT_WEDNESDAY_20": 1440,   "TIMEOUT_WEDNESDAY_21": 1440,   "TIMEOUT_WEDNESDAY_22": 1440,   "TIMEOUT_WEDNESDAY_23": 1440,   "TIMEOUT_WEDNESDAY_24": 1440,   "TIMEOUT_WEDNESDAY_3": 1380,   "TIMEOUT_WEDNESDAY_4": 1440,   "TIMEOUT_WEDNESDAY_5": 1440,   "TIMEOUT_WEDNESDAY_6": 1440,   "TIMEOUT_WEDNESDAY_7": 1440,   "TIMEOUT_WEDNESDAY_8": 1440,   "TIMEOUT_WEDNESDAY_9": 1440 }
And "MODE_TEMPERATUR_REGULATOR" is the key where 0=Manu, 1=Auto, 2=Cent
Eventually these are equivalent to the CONTROL_MODE values here?

Are there any news or workarounds for this problem?

Since I don't have the device I can't test it. But a possible workaround could be to change return self._data['CONTROL_MODE'] to return self._data.get('CONTROL_MODE') in line 181 of homeassistant/components/homematic/climate.py. That would bypass the exception reported in the opening post. But I can't estimate which effect this will have. Feel free to give it a try and report what your results are. 👍

Hi, thanks for replying.
I tried the above mentioned code. Now the log says:
  File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/homematic/climate.py", line 181     return self._data.get('CONTROL_MODE')
I could do any testings that may help - just tell me what to do ;-)

Addition:
I tried changing the code again and now the log says:
Traceback (most recent call last):   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 402, in _async_add_entity     await entity.async_update_ha_state()   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 254, in async_update_ha_state     self._async_write_ha_state()   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 285, in _async_write_ha_state     attr.update(self.state_attributes or {})   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/climate/__init__.py", line 246, in state_attributes     data[ATTR_PRESET_MODE] = self.preset_mode   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/homematic/climate.py", line 98, in preset_mode     mode = HM_ATTRIBUTE_SUPPORT[HM_CONTROL_MODE][1][self._hm_control_mode] KeyError: None 2019-08-13 19:48:16 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved Traceback (most recent call last):   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 402, in _async_add_entity     await entity.async_update_ha_state()   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 254, in async_update_ha_state     self._async_write_ha_state()   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 285, in _async_write_ha_state     attr.update(self.state_attributes or {})   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/climate/__init__.py", line 246, in state_attributes     data[ATTR_PRESET_MODE] = self.preset_mode   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/homematic/climate.py", line 98, in preset_mode     mode = HM_ATTRIBUTE_SUPPORT[HM_CONTROL_MODE][1][self._hm_control_mode] KeyError: None 2019-08-13 19:48:16 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved Traceback (most recent call last):   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 402, in _async_add_entity     await entity.async_update_ha_state()   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 254, in async_update_ha_state     self._async_write_ha_state()   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 285, in _async_write_ha_state     attr.update(self.state_attributes or {})   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/climate/__init__.py", line 246, in state_attributes     data[ATTR_PRESET_MODE] = self.preset_mode   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/homematic/climate.py", line 98, in preset_mode     mode = HM_ATTRIBUTE_SUPPORT[HM_CONTROL_MODE][1][self._hm_control_mode] KeyError: None 2019-08-13 19:48:16 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved Traceback (most recent call last):   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 402, in _async_add_entity     await entity.async_update_ha_state()   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 254, in async_update_ha_state     self._async_write_ha_state()   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 285, in _async_write_ha_state     attr.update(self.state_attributes or {})   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/climate/__init__.py", line 246, in state_attributes     data[ATTR_PRESET_MODE] = self.preset_mode   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/homematic/climate.py", line 98, in preset_mode     mode = HM_ATTRIBUTE_SUPPORT[HM_CONTROL_MODE][1][self._hm_control_mode] KeyError: None

You messed up the whitespace. In Python a tab is different from 2 blanks. It has to be consistent within the file.
Apparently a corret mode needs to be returned. With the solution I have posted None is being returned. Change the code to this (at the same place I have talked about before): return self._data.get('CONTROL_MODE', HVAC_MODE_HEAT).
That way it will always be in heating mode. I don't know what an appropriate solution would look like. But I assume what corresponds to the heating mode form Home Assistant is a device that's turned on. If you set a low target temperature that should't be an issue while it's still warm outside.

That is correct, this kind of device are HVAC_MODE_HEAT all time. That is the mode of climate device and not the current action.

Hey there,
i changed the code and now i get the following error:
raceback (most recent call last):   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 402, in _async_add_entity     await entity.async_update_ha_state()   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 254, in async_update_ha_state     self._async_write_ha_state()   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 285, in _async_write_ha_state     attr.update(self.state_attributes or {})   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/climate/__init__.py", line 246, in state_attributes     data[ATTR_PRESET_MODE] = self.preset_mode   File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/homematic/climate.py", line 98, in preset_mode     mode = HM_ATTRIBUTE_SUPPORT[HM_CONTROL_MODE][1][self._hm_control_mode] KeyError: 'heat' 2019-08-14 04:02:23 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved

first of all - I am not a programmer.
I tried to copy some codelines from an older version of climate.py but this also does not work.
I tried
        # Get the name of the mode         code = self._data['CONTROL_MODE']         mode = HM_ATTRIBUTE_SUPPORT[HM_CONTROL_MODE][1][code]         mode = mode.lower()
And the log says:
  File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/homematic/climate.py", line 98, in preset_mode     code = self._data['CONTROL_MODE'] KeyError: 'CONTROL_MODE'
does this help anyway?

@danielperna84 and @pvizeli :
Is there a chance how i could get this damned thermostat working?

Would really love, if this can be fixed, as I own five of this thermostats and definitely prefer continue using them. Think for the environment, the trees ;-)

Unfortunately I don't see how I can be of further help. Without being able to test this my guidance here in the form of "try this, try that" would take ages to make usable progress. So we probably have to wait until someone with the same device and Python knowledge takes the time to research and fix the problem.

As i got a few of them. If you got some spare time and are willing to fix this (no offense): I can send a pair HM-CC-TC and HM-CC-VD over to you...

Maybe we should propose the broken Homematic Integration as Homeassistant Alert?
Soon the heating season will begin in europe and these thermostats are pretty common.

I could set up a dev system and provide remote access to someone who has the knowledge to debug this. I have a few HM-CC-TC.

Sorry for not being active in this issue, but I currently don't have the capacity in spare time to get deeper into this.
That being said, I do understand the desire to get the device working again. But realistically the device itself is not broken. You still can automate it via the CCU, or improve the internal programming to be at least somewhat more efficient compared to a fully manual thermostat. Or at the very least: walk straight to the device and turn the heat up. It's just the integration into HA that's broken. Which should be fixed, no doubt. But nobody will freeze to death. Which gives any of the victims of this bug the opportunity to get started with Python to fix this issue. I promise, this problem shouldn't be too difficult to solve. It just requires some time, basic Python knowledge and access to the hardware. 👍

I did a quick test on my system and a try-except could fix the issue for now. I don't want to commit this fix as I'm not sure, if that has any side effects, but look at the patch which is attached.
patch.txt

Sound great. For me as a noob - how could i apply this change to my installation?
Do I simply have to add the "+" lines - what about the lines without a "-" or a "+".
Sorry for this silly question - but i am really far away from being a programmer

@danielperna84 Could you have a look at the patch? I know, that this should not be the final solution, but this would help a lot of people. I might dig deeper into the issue. I"m a developer, but I don't have much python knowledge yet. So this will take some time.

@MajestyIV  I found out - how to apply the patch.
The log says:
Traceback (most recent call last):
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity_platform.py", line 408, in _async_add_entity
await entity.async_update_ha_state()
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 266, in async_update_ha_state
self._async_write_ha_state()
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/helpers/entity.py", line 307, in _async_write_ha_state
attr.update(self.state_attributes or {})
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/climate/init.py", line 245, in state_attributes
data[ATTR_PRESET_MODE] = self.preset_mode
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/homematic/climate.py", line 98, in preset_mode
mode = HM_ATTRIBUTE_SUPPORT[HM_CONTROL_MODE][1][self._hm_control_mode]
File "/srv/homeassistant/lib/python3.7/site-packages/homeassistant/components/homematic/climate.py", line 181, in _hm_control_mode
return self._data["CONTROL_MODE"]
KeyError: 'CONTROL_MODE'
2

You probably did something wrong while applying the patch.
If you want to do it manually, you have to remove the lines with the leading - and apply the lines with the leading +. Keep everything else as it is.

Hmmm. Same error again.
Could you Upload the patched climate.py?

I did some more testing and my patch is not working 100%. There are 2 icons under the climate control which are causing a exception.

I think, they should be disabled but I don't have a clue how to do that.

@danielperna84 @pvizeli - Fix is not sufficient as only the sensors "temp" and "humidity" work. The original "climate function" - the ability to set target temperature and switch thermostat profiles (eg automatic, manual, holiday) still do not work.

@pvizeli @danielperna84: I was wrong. Fix effective per version 0.99.3. Looking good!
Thanks,
Jakob


update ProcessedOutput struct

type ProcessedOutput struct {
    FundType       types.Specifier   `json:"fundtype"`
    MaturityHeight types.BlockHeight `json:"maturityheight"`
    WalletAddress  bool              `json:"walletaddress"`
    RelatedAddress types.UnlockHash  `json:"relatedaddress"`
    Value          types.Currency    `json:"value"`
}

Currently still contains RelatedAddress, while in reality this should probably be a condition.

Same goes for ProcessedInput.

To recap, we have 2 places where we want to decode outputs on their own. One of them is in the explorer, where we store outputs directly in a bucket. Another such place is in the consensus, where it is stored as part of a processedBlock, as part of a diff structure. This latter place is where the earlier mentioned panic came from. And than we have places like the ProcessedOutput, already reported in this issue, where might want to  change some things, as to reflect the fact that a condition is not always an unlock hash.
These (2) places are much harder to deal with, as there is no (direct) relationship with a transaction version. Hence we would basically have to guess.
That is probably possible, but expensive, by trying to decode the condition part of an output as a pure unlock hash, should the other one fail. This does require some roll-back in the reader, and is not ideal. If that's something we want to go for anyway, we could do it automatically, as part of the normal decoding. The biggest reason that this dynamic decoding gets difficulty here, is because we would have no context to gain knowledge from. The binary encoding format is very minimalistic, and is stripped down as much as it can, serializing only, and really only, the bytes it has to serialize. But there is no type information or any thing in the bytes that would tell you where a certain object-value stops. The only way to decode, if you know for sure what the format is. Hence, in this guessing scenario you would basically have to guess.
Another option could be to provide a migration tool, for people to update all outputs that are stored as persistent data (by the consensus and explorer modules), to the new format.
There might be other options, I would be all ears for it, but those are the only ones I can think of at the moment.
We could also upgrade the persistence version of those modules, such that if the version is lower than the new one we could update all those stored outputs at startup. Might be the sweet middle road.

Updating the Metadata versions of all modules that affect, would allow our code to auto-update all values that have to be updated. This could help us auto-upgrade all these out-dated values, such that we can decode them into our in-memory models. Once they can be decoded, all is good.

Related to https://github.com/rivine/rivine/issues/301.

This is part of #275, nothing to do with things described earlier in this issue.


feat(helm): reintroduce name flag

These changes reintroduce --name as an accepted long flag.
Fixes https://github.com/helm/helm/issues/7345

LGTM pending @marckhouzam's comment

@bacongobbler / @marckhouzam
Thanks for the review. Let me know if you'd like me to rebase.

I expressed a concern in the corresponding issue.

Agreed. @desimone can you please mark the flag as hidden? Once that's done this should be good to go.

A deprecation notice when the --name flag is used would be great as well. Good point @mattfarina.

I just started to move to helm3 and stumbled upon this.. my feedback on it: it is a easy change to accommodate in scripts and even if the flag had been maintained in many cases I would have to update automation scripts to use new uninstall option to delete a release.
This was in a way useful as I was following the install guide for a new chart which was updated for helm3 which I didn't notice and running it with helm2 the command failed so I realized should use helm3.
On my shell PATH at least I am currently keeping the helm binary at 2.16.x level since have a bunch of envs on helm2 yet to upgrade, and call helm 3 just helm3 while I work on migrating charts.. the different install syntax in a way prevents me from calling helm 2 instead of helm3 by mistake.

@desimone any progress on this issue? We were planning to cut the first release candidate of Helm 3.2.0 within the next week or so (before KubeCon EU). Any idea if you'll have the time to work on this? If not, we should remove this from the 3.2.0 milestone. Thanks.

Unfortunately, I wont have time to work on this in the next week or two.

On Mar 2, 2020, at 12:02 PM, Matthew Fisher<EMAIL_ADDRESS>wrote:
@desimone https://github.com/desimone any progress on this issue? We were planning to cut the first release candidate of Helm 3.2.0 within the next week or so (before KubeCon EU). Any idea if you'll have the time to work on this? If not, we should remove this from the 3.2.0 milestone. Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/helm/helm/pull/7380?email_source=notifications&email_token=AALZFMLGVALX7Q5CSEXOJA3RFQGG5A5CNFSM4KFPZYK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENQXUXQ#issuecomment-593590878, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALZFMMVUVOBIWGH6PCHKF3RFQGG5ANCNFSM4KFPZYKQ.

thansk for the update. Removing from the 3.2 milestone.

closing for now due to inactivity over the past 7 months. When you have the time to work on this again, please open a new PR and link back to this one for background history. Thanks!


Cold storage pricing

What is the basis of pricing of the cold storage? Does Azure Data Explorer use something like Standard LRS storage account to store the ingested (cold) data? Then the customer gets billed the standard rates (capacity+transactions) for the storage account?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: e6bba86f-f473-368c-e517-c02e4635119c
Version Independent ID: 00679fb8-21d3-ff84-3301-9e2bc16cbb53
Content: What is Azure Data Explorer?
Content Source: articles/data-explorer/data-explorer-overview.md
Service: data-explorer
GitHub Login: @orspod
Microsoft Alias: v-orspod

@juho-hanhimaki Thank you for bringing this question to our attention. It appears there isn't much in the way of documentation to explain the associated costs. There is an Azure Data Explorer Cost Estimator, which might be useful to see how costs are calculated. In the meantime, I am going to reach out to find more information.

The cost estimator is the only reference to cold storage being a pricing figure for Azure Data Explorer. The official pricing page (https://azure.microsoft.com/en-us/pricing/details/data-explorer/) has no mention of cold storage. There should be some documentation to explain the pricing breakdown, or include information pertaining to factors that influence pricing.
I have assigned the issue to the content author (@orspod) to evaluate and update as appropriate.

@juho-hanhimaki, thanks for your question. I will check re: documentation to explain the pricing breakdown, or include information pertaining to factors that influence pricing and update accordingly.

Cold Storage is based on compressed data in Azure blob

@TzviaGT, thanks for the answer.
@juho-hanhimaki,  More information re: cold storage and caching (https://docs.microsoft.com/en-us/azure/kusto/concepts/cachepolicy).
Pricing page and cost links above should help as well.

@juho-hanhimaki I believe your query has been answered. We will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.  #please-close


CHEBI:17521 - remove wrong synonyms

Dear Gareth,
CHEBI:17521 has two wrong synonyms coming from HMDB
N-(2-Phenylethyl)-acetamide | SYNONYM | HMDB | English | OK |   | P
N-Acetylphenylethylamine | SYNONYM | HMDB | English | OK |   | P
Cheers, Anne

Hi Anne,
I have marked the 2 synonyms as deleted.
Best Regards,
Adnan


[move-prover] Disable extensionality when array theory is used

Motivation
This PR makes two changes when use_array_theory flag is used.

Disables extensionality reasoning to improve performance
Removes high setting of eager and lazy QI thershold

This PR does not change any behavior when array theory is not used.
The motivation for this change is to provide a feasible path in Move Prover where a high QI threshold can be avoided.  The main reason for the high QI threshold currently is the use of array axioms.  I suspect that the high threshold causes instability in cases when the solver is looking for an error.  Using a low threshold should cause the solver to terminate faster in such cases.  The use of native array theory (without extensionality) allows us to get by with a low threshold without losing completeness (i.e., provability for correct programs).  I have verified this empirically by running the regressions with the array theory turned on.  All tests passed but in very few cases I had to increase the timeout duration.  So, overall I think that once this PR lands, the option -C=backend.use_array_theory=true could be used to trade off robustness for a modest decrease in performance.
Have you read the Contributing Guidelines on pull requests?
Yes
Test Plan
Ran all tests manually with array theory turned on.
Related PRs
None.

/land


Non-selectable / greyed out option?

Is there a way to set X many rows as non-interactive? Or 'force select/unselect'?
I'm using setSelectedRows for passing a few pre-selections I want already ticked. I was wondering if there's a way to make them (or a subset) non-active so the user can't select/unselect them.

Hi @aravasio , disabling options is not supported yet, and will not be added in a short while, you can fork the picker and add it yourself.


Update europe.md

Lots more "http://https://" to fix

Docs Build status updates of commit ab36f61:
:warning: Validation status: warnings

File
Status
Preview URL
Details

BingMaps/coverage/transit-coverage/europe.md
:warning:Warning
View
Details

BingMaps/coverage/transit-coverage/europe.md

Line 574, Column 14: [Warning: file-not-found - See documentation] Invalid file link: 'http://www.Autocars_S.A.S.A.I.B..com'.
Line 2, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit b8ad591:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

BingMaps/coverage/transit-coverage/europe.md
:bulb:Suggestion
View
Details

BingMaps/coverage/transit-coverage/europe.md

Line 2, Column 1: [Suggestion: description-missing - See documentation] Missing required attribute: 'description'.

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Docs Build status updates of commit a9c3cee:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

BingMaps/coverage/transit-coverage/europe.md
:bulb:Suggestion
View
Details

BingMaps/coverage/transit-coverage/europe.md

Line 0, Column 0: [Suggestion: disallowed-domain] Url 'ttps://www.ville-quiberon.fr' references a disallowed domain 'ttps://www.ville-quiberon.fr'. This poses a security risk.

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

Too many issues - @jnwhitbeck to fix


Progress Bars: discrepancy in usage code

Link to the Page
https://www.skeleton.dev/components/progress-bars
Describe the Issue (screenshots encouraged!)
The example code for ProgressBar refers to a "label" prop when in fact no such prop exists.

Closed by  #2545


Regression in 0.34.0, minitest_exploration_helpers.rb:103:in `assertion_method?'

As of rubocop-minitest 0.34.0, Rubocop Minitest produces a large number of errors of the form An error occurred while [cop] cop was inspecting [file] when run against source that uses setter methods. I've seen this with the Minitest/EmptyLineBeforeAssertionMethods and Minitest/MultipleAssertions cops, though it may also happen with others.
When running rubocop with -d, the errors all raise at lib/rubocop/cop/mixin/minitest_exploration_helpers.rb:103:in `assertion_method?'.
I have confirmed the problem doesn't occur with rubocop-minitest 0.33.0, both by uninstalling 0.34.0 and by running rubocop in a bundle that locks rubocop-minitest 0.33.0.

Expected behavior
If RuboCop Minitest 0.33.0 was able to inspect a test file, RuboCop Minitest 0.34.0 should be able to inspect a test file. It might report issues it wasn't able to report before, but it shouldn't fail with apparently spurious errors.
Actual behavior
RuboCop Minitest 0.34.0 fails at class boundaries or individual lines, failing out in RuboCop::Cop::MinitestExplorationHelpers#assertion_method?
Steps to reproduce the problem

Set up project such that it uses rubocop-minitest (which is to say: in the Gemfile and in .rubocop.yml).
Create a test file that uses a setter method.
Run rubocop on that test file.

Below, I've included a test case that always fails for me, as well as the output of such a run.
RuboCop version
$ rubocop -V
1.59.0 (using Parser <IP_ADDRESS>, rubocop-ast 1.30.0, running on ruby 3.2.2) [arm64-darwin23]
  - rubocop-minitest 0.34.0
  - rubocop-performance 1.20.0
  - rubocop-rails 2.23.0

Test case
test/models/example_test.rb:
require "test_helper"

class Stub
  attr_accessor :foo
end

class ExampleTest < ActiveSupport::TestCase
  test "the truth" do
    var = Stub.new
    var.foo = 1

    assert var.foo
  end
end

Running rubocop test/models/example_test.rb -d I get:
For /Users/faisal/rs: configuration from /Users/faisal/rs/.rubocop.yml
configuration from /opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-rails-2.23.0/config/default.yml
configuration from /opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-rails-2.23.0/config/default.yml
Default configuration from /opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/config/default.yml
configuration from /opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/config/default.yml
configuration from /opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/config/default.yml
configuration from /opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-performance-1.20.0/config/default.yml
configuration from /opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-performance-1.20.0/config/default.yml
Use parallel by default.
Skipping parallel inspection: only a single file needs inspection
Inspecting 1 file
Scanning /Users/faisal/rs/test/models/example_test.rb
An error occurred while Minitest/MultipleAssertions cop was inspecting /Users/faisal/rs/test/models/example_test.rb:7:0.
undefined method `expression' for s(:send,
  s(:lvar, :var), :foo=,
  s(:int, 1)):RuboCop::AST::SendNode
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/mixin/minitest_exploration_helpers.rb:103:in `assertion_method?'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/minitest/multiple_assertions.rb:68:in `assertions_count'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/minitest/multiple_assertions.rb:65:in `block in assertions_count'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/node/mixin/descendence.rb:28:in `block in each_child_node'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/node/mixin/descendence.rb:25:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/node/mixin/descendence.rb:25:in `each_child_node'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/minitest/multiple_assertions.rb:65:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/minitest/multiple_assertions.rb:65:in `sum'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/minitest/multiple_assertions.rb:65:in `assertions_count'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/minitest/multiple_assertions.rb:40:in `block in on_class'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/minitest/multiple_assertions.rb:39:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/minitest/multiple_assertions.rb:39:in `on_class'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:107:in `public_send'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:107:in `block (2 levels) in trigger_responding_cops'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:171:in `with_cop_error_handling'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:106:in `block in trigger_responding_cops'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:105:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:105:in `trigger_responding_cops'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:69:in `on_class'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `block in on_dstr'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `on_dstr'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:71:in `on_begin'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:20:in `walk'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:87:in `investigate'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/team.rb:156:in `investigate_partial'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/team.rb:98:in `investigate'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:345:in `block in inspect_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:344:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:344:in `flat_map'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:344:in `inspect_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:287:in `block in do_inspection_loop'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:321:in `block in iterate_until_no_changes'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:314:in `loop'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:314:in `iterate_until_no_changes'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:283:in `do_inspection_loop'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:164:in `block in file_offenses'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:189:in `file_offense_cache'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:163:in `file_offenses'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:154:in `process_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:135:in `block in each_inspected_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:134:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:134:in `reduce'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:134:in `each_inspected_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:120:in `inspect_files'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:73:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command/execute_runner.rb:26:in `block in execute_runner'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command/execute_runner.rb:52:in `with_redirect'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command/execute_runner.rb:25:in `execute_runner'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command/execute_runner.rb:17:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command.rb:11:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/environment.rb:18:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:118:in `run_command'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:125:in `execute_runners'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:51:in `block in run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:77:in `profile_if_needed'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:43:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/exe/rubocop:19:in `block in <top (required)>'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/benchmark-0.3.0/lib/benchmark.rb:313:in `realtime'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/exe/rubocop:19:in `<top (required)>'
/opt/homebrew/lib/ruby/gems/3.2.0/bin/rubocop:25:in `load'
/opt/homebrew/lib/ruby/gems/3.2.0/bin/rubocop:25:in `<main>'
An error occurred while Minitest/EmptyLineBeforeAssertionMethods cop was inspecting /Users/faisal/rs/test/models/example_test.rb:10:4.
undefined method `expression' for s(:send,
  s(:lvar, :var), :foo=,
  s(:int, 1)):RuboCop::AST::SendNode
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/mixin/minitest_exploration_helpers.rb:103:in `assertion_method?'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/minitest/empty_line_before_assertion_methods.rb:44:in `assertion_method'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/minitest/empty_line_before_assertion_methods.rb:28:in `on_send'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:107:in `public_send'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:107:in `block (2 levels) in trigger_responding_cops'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:171:in `with_cop_error_handling'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:106:in `block in trigger_responding_cops'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:105:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:105:in `trigger_responding_cops'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:69:in `on_send'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `block in on_dstr'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `on_dstr'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:71:in `on_begin'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:158:in `on_block'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:71:in `on_block'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:154:in `on_class'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:71:in `on_class'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `block in on_dstr'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `on_dstr'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:71:in `on_begin'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:20:in `walk'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:87:in `investigate'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/team.rb:156:in `investigate_partial'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/team.rb:98:in `investigate'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:345:in `block in inspect_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:344:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:344:in `flat_map'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:344:in `inspect_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:287:in `block in do_inspection_loop'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:321:in `block in iterate_until_no_changes'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:314:in `loop'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:314:in `iterate_until_no_changes'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:283:in `do_inspection_loop'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:164:in `block in file_offenses'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:189:in `file_offense_cache'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:163:in `file_offenses'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:154:in `process_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:135:in `block in each_inspected_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:134:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:134:in `reduce'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:134:in `each_inspected_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:120:in `inspect_files'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:73:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command/execute_runner.rb:26:in `block in execute_runner'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command/execute_runner.rb:52:in `with_redirect'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command/execute_runner.rb:25:in `execute_runner'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command/execute_runner.rb:17:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command.rb:11:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/environment.rb:18:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:118:in `run_command'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:125:in `execute_runners'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:51:in `block in run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:77:in `profile_if_needed'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:43:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/exe/rubocop:19:in `block in <top (required)>'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/benchmark-0.3.0/lib/benchmark.rb:313:in `realtime'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/exe/rubocop:19:in `<top (required)>'
/opt/homebrew/lib/ruby/gems/3.2.0/bin/rubocop:25:in `load'
/opt/homebrew/lib/ruby/gems/3.2.0/bin/rubocop:25:in `<main>'
An error occurred while Minitest/EmptyLineBeforeAssertionMethods cop was inspecting /Users/faisal/rs/test/models/example_test.rb:12:4.
undefined method `expression' for s(:send,
  s(:lvar, :var), :foo=,
  s(:int, 1)):RuboCop::AST::SendNode
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/mixin/minitest_exploration_helpers.rb:103:in `assertion_method?'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/minitest/empty_line_before_assertion_methods.rb:56:in `accept_previous_line?'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-minitest-0.34.0/lib/rubocop/cop/minitest/empty_line_before_assertion_methods.rb:31:in `on_send'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:107:in `public_send'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:107:in `block (2 levels) in trigger_responding_cops'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:171:in `with_cop_error_handling'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:106:in `block in trigger_responding_cops'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:105:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:105:in `trigger_responding_cops'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:69:in `on_send'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `block in on_dstr'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `on_dstr'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:71:in `on_begin'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:158:in `on_block'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:71:in `on_block'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:154:in `on_class'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:71:in `on_class'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `block in on_dstr'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:137:in `on_dstr'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:71:in `on_begin'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-ast-1.30.0/lib/rubocop/ast/traversal.rb:20:in `walk'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/commissioner.rb:87:in `investigate'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/team.rb:156:in `investigate_partial'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cop/team.rb:98:in `investigate'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:345:in `block in inspect_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:344:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:344:in `flat_map'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:344:in `inspect_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:287:in `block in do_inspection_loop'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:321:in `block in iterate_until_no_changes'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:314:in `loop'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:314:in `iterate_until_no_changes'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:283:in `do_inspection_loop'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:164:in `block in file_offenses'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:189:in `file_offense_cache'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:163:in `file_offenses'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:154:in `process_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:135:in `block in each_inspected_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:134:in `each'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:134:in `reduce'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:134:in `each_inspected_file'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:120:in `inspect_files'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/runner.rb:73:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command/execute_runner.rb:26:in `block in execute_runner'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command/execute_runner.rb:52:in `with_redirect'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command/execute_runner.rb:25:in `execute_runner'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command/execute_runner.rb:17:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/command.rb:11:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli/environment.rb:18:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:118:in `run_command'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:125:in `execute_runners'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:51:in `block in run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:77:in `profile_if_needed'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/lib/rubocop/cli.rb:43:in `run'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/exe/rubocop:19:in `block in <top (required)>'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/benchmark-0.3.0/lib/benchmark.rb:313:in `realtime'
/opt/homebrew/lib/ruby/gems/3.2.0/gems/rubocop-1.59.0/exe/rubocop:19:in `<top (required)>'
/opt/homebrew/lib/ruby/gems/3.2.0/bin/rubocop:25:in `load'
/opt/homebrew/lib/ruby/gems/3.2.0/bin/rubocop:25:in `<main>'
.

1 file inspected, no offenses detected

3 errors occurred:
An error occurred while Minitest/MultipleAssertions cop was inspecting /Users/faisal/rs/test/models/example_test.rb:7:0.
An error occurred while Minitest/EmptyLineBeforeAssertionMethods cop was inspecting /Users/faisal/rs/test/models/example_test.rb:10:4.
An error occurred while Minitest/EmptyLineBeforeAssertionMethods cop was inspecting /Users/faisal/rs/test/models/example_test.rb:12:4.
Errors are usually caused by RuboCop bugs.
Please, report your problems to RuboCop's issue tracker.
https://github.com/rubocop/rubocop/issues

Mention the following information in the issue report:
1.59.0 (using Parser <IP_ADDRESS>, rubocop-ast 1.30.0, running on ruby 3.2.2) [arm64-darwin23]
Finished in 0.32425900001544505 seconds

Thank you for your early feedback! This bug was fixed in https://github.com/rubocop/rubocop-minitest/releases/tag/v0.34.1.

Thank you for your early feedback! This bug was fixed in https://github.com/rubocop/rubocop-minitest/releases/tag/v0.34.1.

Fix confirmed. Thank you!


core.st2.CronTimer runs action on every worker instead of only one

SUMMARY

We have a StackStorm installation with 2 controllers and 3 workers, each on a separate machine (AWS EC2 instances).
We have a trigger rule (C.F. below) which should trigger an action at 5AM UTC everyday.
The problem is that this action is triggered 3 times (one time on every worker) instead of one time in total.

---
pack: 'foo'
name: 'health_check_daily'
description: 'Runs foo.wf-health_check daily at 5 AM UTC'
enabled: true

trigger:
  type: 'core.st2.CronTimer'
  parameters:
    timezone: 'UTC'
    hour: '5'
    minute: '0'
    second: '0'

action:
  ref: 'foo.wf-health_check'

ISSUE TYPE
Bug Report
STACKSTORM VERSION
st2 2.9.3, on Python 2.7.12
OS / ENVIRONMENT / INSTALL METHOD

Custom install on Ubuntu 16.04.5 LTS
Deployed on AWS EC2 instances
2 controllers, 3 workers
We're using Mistral + Jinja for our workflows

STEPS TO REPRODUCE
rules/test_rule.yaml
---
pack: 'test-pack'
name: 'test-rule'
description: ''
enabled: true

trigger:
  type: 'core.st2.CronTimer'
  parameters:
    timezone: 'UTC'
    hour: '5'
    minute: '0'
    second: '0'

action:
  ref: 'test-pack.test-action'

actions/test_action.yaml
---
description: "Test Action"
runner_type: "local-shell-cmd"
enabled: true
entry_point: ''
name: "test-action"
pack: "test-pack"
parameters:
  cmd:
    description: ""
    required: true
    type: "string"
    default: 'echo test'
    immutable: true

EXPECTED RESULTS
The action should be executed only one time in total.
ACTUAL RESULTS
The action is executed one time for each worker.

It looks like you are running multiple instances of st2timersengine process.
As per EWC documentation - only a single instance of st2timersengine service can run at once - https://docs.stackstorm.com/install/ewc_ha.html#st2timersengine.
In our Kubernetes HA blueprint automatic failover of st2timersengine service is handled by Kubernetes. If you don't need use Kubernetes you need to take care of failover yourself.
I will also update our non Extreme Workflow Composer documentation and make sure that is explicitly pointed out.

Added documentation change / clarification here - https://github.com/StackStorm/st2docs/pull/894.

Thanks a lot for your quick and relevant reply @Kami! Perfect 👌

You are welcome. I will go ahead and close this issue.


Changelog Entry
version: <log entry>

Checklist:

[ ] I have performed a self-review of my own code
[ ] I have documented my code in accordance with the documentation guidelines
[ ] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have run the unit tests
[ ] I only have one commit (if not, squash them into one commit).
[ ] I have a descriptive commit message that adheres to the commit message guidelines

Please review the CONTRIBUTING.md file for detailed contributing guidelines.

Codecov Report

Merging #684 (f343580) into main (e6d5089) will decrease coverage by 0.08%.
The diff coverage is 0.00%.

Additional details and impacted files

@@             Coverage Diff              @@
##               main     #684      +/-   ##
============================================
- Coverage     69.03%   68.95%   -0.08%
  Complexity      406      406
============================================
  Files           152      152
  Lines         13836    13851      +15
  Branches        290      290
============================================
  Hits           9551     9551
- Misses         4133     4148      +15
  Partials        152      152

Flag
Coverage Δ

rust
66.94% <0.00%> (-0.09%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed
Coverage Δ

...s/cosmwasm-vm/cw-xcall-ibc-connection/src/error.rs
100.00% <ø> (ø)

...asm-vm/cw-xcall-ibc-connection/src/send_message.rs
0.00% <0.00%> (ø)


Скласти таймлайн

E X P E R I E N C E
INTERN QA ENGINEER
SoftServe  | Oct 2022 - now
'GreenCity' social web project (open-source) requirements and user stories testing, writing change requests; creating test documentation (bug reports, test cases)
functional and non-functional testing of mobile  and web apps
working closely with the dev team by SCRUM
QATestLab | Aug 2022 - Sep 2022 creating test documentation (bug reports, check-lists,
test cases, test plans, test result reports) web-sites testing (functional and layout testing) native mobile app testing  (app "Unit converter", "Nova poshta" ), desktop app testing (app "Nodes")
MANAGER OF RETAIL BANKING DIVISION
Bank NDA | Jun 2020 - Jun 2022 managing and supporting the Bank's chat-bot project from 	design 	to 	testing 	(requirements 	gathering, modifications of chat-bot phrases set and UAT) personal managing and monitoring the KPI performance estimating and planning division work, development of internal regulations documentation for the division
MANAGER OF CHAT-ONLINE SECTOR
Bank NDA | Jun 2018 - Jun 2020 planning, organizing the sector's work ensuring effective sales quality control of client consultations
BANK OFFICER, LEAD BANK OFFICER
Bank NDA, UkrSibbank | Mar 2013 - Jun 2018 customer service and consultation  effective sales, telemarketing

Milestone_2

Done


LSP Semantic token modifier for constructor use

CC: @DanTup
I am attempting to make my vs code theme more like android studio. However I cannot customize constructor use of classes. VS Code highlights anything that is a class whereas android studio has different colors for class used as type definition and classes that are used as constructors (initialized).
Proposal: add a modifier to class for constructor use: "class.constructor"
Here is android studio:

Here is VS Code:

Currently the interpreter is assigning any use of a class to the "class" semantic token type:

With the change at https://dart-review.googlesource.com/c/sdk/+/197401/, a custom modifier is added to constructors which would enable customising the colour like this (in VS Code - I'm not familiar with customisations in other LSP clients):
"editor.semanticTokenColorCustomizations": {
	"rules": {
		"class.constructor": "#ffff00", // yellow
	},
},

This results in constructors being coloured differently to other instances of the class name:

Constructor might fit better as a "Type" rather than a "Modifier", but since tokens can only have a single type I'm a little hesitant to add more (except for types that definitely don't fit existing types - like annotations) as there's no way to "extend" other types so LSP clients would not know how to colour them by default (I can compensate for this in the VS Code extension, but not for other LSP clients). Modifiers don't take anything away, so there are no real drawbacks.
If in future LSP does gain the ability to extend existing types, it may make sense to tweak this so should your custom colour stop working in future, it's worth checking (the Inspect Editor Tokens command you're already familiar with should quickly confirm).
(@bwilkerson fyi - in case you have another opinion)


mysql_status: Update CheckMK 2.3 fails

We are trying to update CheckMK from 2.2.0p25.cre to 2.3.
The update fails because of deprecated API calls:
01/06 Legacy check plugins...
Ignoring outdated plugin 'mysql.status': Format no longer supported -- this API is deprecated!

You can abort the update process (A) and try to fix the incompatibilities or continue the update (c).

Is this issue known? Are there any workarounds?
Thanks in advance for your support!

Hello,
There is no workaround, this plugin needs to be rewritten for the new Checkmk 2.3 API.
2.3 removed the 1.x APIs, deprecated the one introduced in 2.0 and introduced a whole new, but better supported Check API.

Hey Bastian,
thanks for your swift reply.
Will you consider the rewrite to the new API in the near future (or ever)?

Hi Tobias,
as soon one of our consumers orders us.
Can't tell you how soon that happens.

Hi everyone - I took the liberty to migrate to the old new API in #80.
@Bastian-Kuhn Please let me know what you need in order to incorporate this from a licensing standpoint. I'm happy to grant all rights.

@moschlar Thank you very much, will look into it. From the Standpoint of License, that is the one we use: https://github.com/kuhn-ruess/Checkmk-Checks?tab=MIT-1-ov-file#readme (MIT)

Hey, thanks for the update. I have tested the new version with CheckMK 2.3.0p13 Enterprise.
The perf o meter shows me an exception: Exception: 'PerfDataTuple' object is not subscriptable

Thanks for your work!

@Tiippex Darn, sorry - I have just tested it with 2.2 since I have a bunch of other plugins preventing the upgrade... Will look into it!

@Tiippex A fix is in #87!


Move the assertions to the beginning of function

It is desirable to have assertions in the beginning of a function because the compiler might be able to improve its optimization, and it is more readable for the users to understand the panic conditions of a function
Originally posted by @bobbinth in https://github.com/maticnetwork/miden/pull/530#discussion_r1028397476

Hey @vlopes11, it looks like this is the only issue in the /miden repo that hasn't been assigned to someone yet. Is there a budget for fixing this issue, and if so, how much? I know some devs who'd be interested in working on this.

I would like to work on this.

Thank you! It is all yours!

Please review PR #707

Closed by #707.


need API control over legend location #1451

legendPosition property was added to XYChart to control legend location.
To define legend location you can use

predefined values - legendPosition: LegendPosition.TOP_LEFT (possible constants TOP_LEFT, TOP_RIGHT, BOTTOM_LEFT, BOTTOM_RIGHT , lower case is acceptable as well)
or top/left coordinates - legendPosition: [top, left]

If  top/left coordinates are used to define legend location and they match plot position legend will be displayed over the plot.
If legend position is TOP_LEFT or  BOTTOM_LEFT plot will be moved to the right to place the legend on the left.
To test the PR please use this brk https://www.dropbox.com/s/22jc5oxxmpvfekw/1451.bkr?dl=0

thanks for those improvements.  there are two problems remaining though.

if you specify the coordinates they should be [x, y] (horizontal first).
if you specify LegendPosition.BOTTOM, BOTTOM_LEFT, BOTTOM_RIGHT, RIGHT
and then drag the legend, the height of it changes and one edge is stuck.

:+1:


Raspberry Pi Zero - Illegal Instruction error when running "./gogs web"

Gogs version (or commit ref): v0.9.48 and above, Linux arm build.
Git version: 2.1.4
Operating system: Raspbian (latest version, installed via NOOBS), Raspberry Pi Zero with camera port
Database (use [x]):

[ x] PostgreSQL
[ ] MySQL
[ ] SQLite

Can you reproduce the bug at https://try.gogs.io:

[ ] Yes
[ x] No
[ ] Not relevant

Log gist:
?? Not sure if this is needed.

Description
Gogs fails to initialise when running ./gogs web for the first time and every subsequent time, making installation impossible unless reverting to v0.9.13 or below. It will always appear with Illegal instruction and immediately quit.
I understand that this may not be the correct hardware to run Gogs on, but it can be done, as seen in v0.9.13.
I do not understand Go well enough to help with this, so I would appreciate any help with this, as I want to use it for university work.
I am using a default Raspbian install from NOOBS.
...

Hi, currently, Gogs is only field tested on raspi2, that is the reason we only provide that binary.
If you want to run on raspi0, you might have to compile yourself from source code.

Please post questions or config/deploy problems on our forum: https://discuss.gogs.io, here are bugs and feature requests only.


Yatin: Watch muscalaw.com

Yatin requests the watch of the watch_keyword muscalaw\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

muscalaw\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Spevacus in Charcoal HQ


[React] Screen shakes on mobile

Check that this is really a bug

[X] I confirm

Reproduction link
https://codesandbox.io/p/github/vicasas/swiper-issue-screen-shakes/main
Bug description
The screen starts shaking when you resize the screen to resolutions between 460 to 476 pixels.
Operating System:
Platform: linux
Arch: x64
Version: #1 SMP Fri Jan 27 02:56:13 UTC 2023
Binaries:
Node: 18.17.1
npm: 9.6.7
Yarn: N/A
pnpm: N/A
Relevant Packages:
next: 13.5.2
swiper: 10.3.1
View Demo, using 480 px: https://hw8xyx-3000.csb.app/
Repository: https://github.com/vicasas/swiper-issue-screen-shakes
Here in the video the problem is shown on a smaller scale, but in person the shaking is stronger.
https://github.com/nolimits4web/swiper/assets/57921784/49fbc0d4-ced9-4ba3-afd1-c29cb9921c6b
Expected Behavior
I would hope that when resizing the graphics window the screen would not shake
Actual Behavior
No response
Swiper version
10.3.1
Platform/Target and Browser Versions
Window 11 with WSL/Chrome
Validations

[X] Follow our Code of Conduct
[X] Read the docs.
[X] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.
[X] Make sure this is a Swiper issue and not a framework-specific issue

Would you like to open a PR for this bug?

[ ] I'm willing to open a PR

That is not related to Swiper

Why is it not related? The problem only occurs when using the Swiper component.


[BUG] multiple screwdrivers can split a single target if the drill is in an enemy.

Description
multiple screwdrivers can split a single target if the drill is in an enemy.
https://github.com/eternalUnion/UltraPain/assets/112786974/a5b4c88b-ab43-42d6-b99a-5325ff6e8fb3

I tested it and it seems correct amount of coins are created but they overlap, creating the illusion of them being split only once

This issue will be closed due to multiple screwdrivers already splitting coins correctly. For a visual enchantment, comment on #3


Error: 'Select a valid choice. That choice is not one of the available choices.'

I have this error when I try to make a post: "Select a valid choice. That choice is not one of the available choices."

Is this some sort of error from my end? Or from django-prose?
here is my model

Hi @hengage,
The model looks OK. Based on the error you receive I speculate there is an issue with how you are rendering a form in your website. Is this correct?
In the admin site it should display a dropdown list for the to pick an ArticleContent, since it's a relation field. Can you confirm this as well?

Hey @parisk, from your explanation it seems like I have to select an already existing article. Am i right?
What I am trying to achieve with it is to make it like a text field so I can write my content and post. Just like RichTextField() does.
I guess I just have to use RichtextField and increase its height with CSS. Which I already did btw.

If you intend to store long-form content (e.g. an article's body) in the database, I suggest you use a separate model and reference it with a ForeignKey. It will result in significantly lighter queries, when you SELECT multiple records.
In that case you would need to create the body model first and then create the post model, so you can reference the body model.
Inline formsets^1 might also be of help here.

Alright @parisk I'll create an issue for it on my project and look into it going forward. Thank you.
If you would like to see the finished work when it's in production I can send you the link.
Thanks for the help.

We could actually add a Real world use cases in the README to indicate products using Django Prose. That would be great.

Great. Absloutely look forward to it when I put the project out live.
It's a blog app I am making to put out contents by me and few friends who are writers.


Mention Jumbo Grove next to Salet

I, too, have an Undum-alike IF game engine. If you don't mind, I'd like to drop a link to it in your readme. Please take a look to see if it's up to your standards. :-)
Thanks for maintaining this repo! I've spent a lot of time poring over the code.

Welcome to the family.


Enable concurrency for commands workflow

- What this PR does and why is it needed

- Special notes for reviewers

- How to verify it

- Description for the changelog

/retest-failed

/retest-failed

/retest-failed

Oops, something went wrong:
This workflow is already running

/retest

/bad-command

/bad-command

/help

Supported operations are /retest, /retest-failed, /cancel

/bad-command

/retest-failed

/retest

Oops, something went wrong:
This workflow is already running


Confused why this hangs ?

Hey,
So, basically, I'm just refactoring some tests and I had something like this:
    let xs : [u32; 3] = __nondet();
    // Ensure element not in array
    for x in xs {
	__VERIFIER_assume(x != 0);
    }
    //
    assert!(indexof(&xs,0) == usize::MAX);

This seems to work fine, and I was writing more tests like this so refactored like so:
#[cfg(rmc)]
#[no_mangle]
fn disjoint(items : &[u32], item: u32) {
    for ith in items {
	__VERIFIER_assume(*ith != item);
    }
}

...

    // Create arbitrary array of size 3
    let xs : [u32; 3] = __nondet();
    // Ensure element not in array
    disjoint(&xs,0);
    //
    assert!(indexof(&xs,0) == usize::MAX);

But, the second version hangs for reasons unknown.  They seem equivalent to me!  (full listing below)
Thoughts appreciated!!
fn indexof(items: &[u32], item: u32) -> usize {
    for i in 0..items.len() {
	if items[i] == item {
            return i;
	}
    }
    //
    return usize::MAX;
}

fn __nondet<T>() -> T {
    unimplemented!()
}
fn __VERIFIER_assume(cond: bool) {
    unimplemented!()
}

/**
 * Ensure that a given item is not in the give array.
 */
#[cfg(rmc)]
#[no_mangle]
fn disjoint(items : &[u32], item: u32) {
    for ith in items {
	__VERIFIER_assume(*ith != item);
    }
}

#[cfg(rmc)]
#[no_mangle]
pub fn test_01() {
    // Create arbitrary array of size 3
    let xs : [u32; 3] = __nondet();
    // Ensure element not in array
    for x in xs {
	__VERIFIER_assume(x != 0);
    }
    //
    assert!(indexof(&xs,0) == usize::MAX);
}

#[cfg(rmc)]
#[no_mangle]
pub fn test_02() {
    // Create arbitrary array of size 3
    let xs : [u32; 3] = __nondet();
    // Ensure element not in array
    disjoint(&xs,0);
    //
    assert!(indexof(&xs,0) == usize::MAX);
}

#[cfg(rmc)]
#[no_mangle]
pub fn main() {
    test_01();
    test_02();
}

And, likewise I'm struggling to get quantified statements through:
#[cfg(rmc)]
#[no_mangle]
pub fn test_02() {
    // Create arbitrary array of size 3
    let xs : [u32; 2] = __nondet();
    // Create arbitrary index within array
    let i : usize = __nondet();
    __VERIFIER_assume(i < xs.len());
    // Ensure known value at that point
    __VERIFIER_assume(xs[i] == 0);
    // Ensure nothing in array below i matches
    for j in 0..2 {
	if j != i {
	    __VERIFIER_assume(xs[j] != 0);
	}
    }
    //
    assert!(indexof(&xs,0) == i);
}

If I manually unroll the loop then its fine.

The non-termination in test_02 is caused by CBMC unwinding forever (because the first parameter in disjoint has an unspecified length). An unwinding depth can be specified by passing --cbmc-args --unwind <value> to RMC. For this example, an unwinding depth of 4 (--cbmc-args --unwind 4) is sufficient. Please refer to the Loops, unwinding, and bounds section of the RMC tutorial for more details.
There is an ongoing discussion  to change the default unwinding depth to 0 to avoid this confusion.

Hey @zhassan-aws,
Ah, thanks --- I should have looked at that.  For some reason I was expecting, since the number of iterations is fixed it would effectively just unroll it.

Hmmm, have made progress but I don't really understand from the tutorial what exactly the "unwinding assertion" is telling me when its failing.  Its somehow telling me that I need to unwind more?  How does RMC / CBMC decide this?

Yes, a failing unwinding assertion indicates that a larger unwinding is needed. The unwinding assertions option adds a check that the unwind + 1 iteration of the loop is unreachable. If the check is proven, then the unwinding depth was sufficient.

Thanks!  I'm making progress on this.  Here's what I have now:
const LIMIT : usize = 6;

#[cfg(rmc)]
#[no_mangle]
pub fn test_01() {
    // Create arbitrary array
    let xs : [u32; LIMIT] = __nondet();
    // Create arbitrary element
    let x : u32 = __nondet();
    // Create arbitrary (valid) length
    let len : usize = __nondet();
    __VERIFIER_assume(len <= LIMIT);
    // Ensure element not in array below len
    for i in 0..len {
	__VERIFIER_assume(xs[i] != x);
    }
    // Check
    assert!(indexof(&xs[..len],x) == usize::MAX);
}

#[cfg(rmc)]
#[no_mangle]
pub fn test_02() {
    // Create arbitrary array
    let xs : [u32; LIMIT] = __nondet();
    // Create arbitrary element
    let x : u32 = __nondet();
    // Create arbitrary (valid) length
    let len : usize = __nondet();
    __VERIFIER_assume(len <= LIMIT);
    // Create arbitrary index within array
    let i : usize = __nondet();
    __VERIFIER_assume(i < len);
    // Ensure known value at index i
    __VERIFIER_assume(xs[i] == x);
    // Ensure nothing in array below i matches
    for j in 0..i {
	__VERIFIER_assume(xs[j] != x);
    }
    // Check find correct one
    assert!(indexof(&xs[..len],x) == i);
}

How does this look in terms of how you would write it?
The performance is interesting as with LIMIT==6 and --unwind 7 it seems to take a very long time, whilst with LIMIT==5 and --unwind 6 it completes pretty quickly.

Looks good to me. By default, CBMC uses MiniSat. You might want to try with more modern SAT solvers, e.g. kissat. To change the SAT solver, use --cbmc-args --external-sat-solver <path-to-sat-solver-executable>.

Ok, will do --- thanks!!


Remove Simulators

This is a bit of a controversial suggestion, so I am creating an issue to track discussion.
Currently, we have SUT components and simulator components. Both are external to the core platform. Messages from the simulators can be overridden using the test_request_setups field defined within a testcase. In extreme circumstances, the original message might not be used at all, with all fields being replaced in the proxy. If this is the case, why do we need the simulator at all?
Instead, my suggestion is that the test platform uses the request field to automatically generate a full request instead of making a callout to an external simulator. We actually already do this in a limited way - when a test case starts with a request from a simulator, the ITP constructs a fake request to initiate the flow when the user clicks the "Execute Test Case" button.

Some food for thought:

What happens if the message does not match with any test case? Today the simulator will still respond with a "correct" message flow.
Current you send the message to a session URL and at the end add the correct endpoint of the API your testing, like /transaction, /quotes, etc. who create those endpoints today? the platform(proxy) or the simulators? Going to s "simulatorless" way how you add the possible endpoints needed?

If an incoming message today doesn't match any test cases, it will not be forwarded to the simulator, so the simulator will not respond with the "correct" message. So it would be the same if we drop the simulators. If an incoming message doesn't match any test cases, the platform will not generate a response.
The endpoints will be read from the test cases, the same way they currently are. The platform sees an incoming message, and extracts the end of the URL. If it finds a test case that matches this url segment, it will generate a response based on the test case definition. It will then move on to the next test step and generate a request according to the request defined there. If the next request is heading for another simulator, this request will be a "self-request" from the ITP and straight back to the ITP (clearly we could optimise this and avoid actually making the request). When this request is received, we repeat the above.

A bigger question is about "logic". If I sent a request with payload: 10, then subsequent requests might need to use the same payload. In which case, we would need to add a way to map values from one request into later ones.
However there's a question mark in my mind over whether this logic is required at all. If the SUT behaves correctly (according to the "script" defined in the test case), then do we need to read any "variable" data? Or is it sufficient to hard-code the value (10 in the example above) into all steps of the test case script?

We could support quite advanced logic, as well as substitution and other things by treating the request and response fields inside a test case definition as twig templates. Twig comes with a security sandbox, which allows us to safely evaluate the template even though it is potentially coming from an untrusted source.

I've been preparing some slides to explain this behaviour, and I thought I would include the important bits here as well.
Here's an overview of the flow without simulators (not too different from the current flow):

Here is additionally a mockup of what a request template might look like using twig templating:
test_steps:
  - # test_step[0]
  - # ...
  - # test_step[n]
    # ... other fields
    request_template:
      source: Mojaloop
      target: DFSP1
      method: PUT
      path: '/quotes/{{ test_steps[2].path_parameters.ID }}'
      headers:
        Content-Type: application/json
        Accept: application/vnd.interoperability.quotes+json;version=1.0
        Date: '{{ "now" | date("D, d M Y H:i:s O") }}'
        FSPIOP-Source: '{{ environment.DFSP2_ID }}'
        FSPIOP-Destionation: '{{ environment.DFSP1_ID }}'
      body: |
        {
            "transferAmount":{
                "amount":"99",
                "currency": "{{ test_steps[0].request.body.amount.currency }}"
            },
            "payeeFspCommission":{
                "amount":"1",
                "currency": "{{ test_steps[0].request.body.amount.currency }}"
            },
            "payeeReceiveAmount":{
                "amount":"100",
                "currency": "{{ test_steps[0].request.body.amount.currency }}"
            }
        }
    response_template: # ...

Hi Christopher, @cjol
Just to clarify, you suggest request_template and response_template as new fields, i.e. addition to existing request and response or we may extend request and response with variables support w/o adding request_template and response_template?
request and response are now used just to show Test Steps examples on UI and generate the first step (if the initiator is not a SUT), so seems like we may just extend them, right?

Yes, I think we can use request and response directly. Sorry for the confusion.

Another example of the kind of functionality I would like to achieve is described here. The Mojaloop Testing Toolkit has some similarities to our platform.
They have opted to define the templates in pure JSON, with string variables embedded within (like @agalaguz's suggestion in https://github.com/gsmainclusivetechlab/interop-test-platform/issues/303#issuecomment-736633601). You can see however that this has resulted in the slightly awkward $function.* syntax for advanced parameters (described under "Advanced parameters for developers"). Additionally, adding new functions requires rebuilding and recompiling the platform, so I'd like to improve on that pattern.


Crush on Samsung Tab A9+ 5G

Hi, i recently compiled and installed the application on a Samsung Tab A9+ 5G with  Android 14 - One UI 6.1 - Security Patch 1/Oct/2024 - Build UP1A.231005.007.
After launching the application, it asks for permissions and I grant them correctly. When trying to register the screen everything goes good until I try to stop the recording, when stopping,  the application crushes, I tried to read the logcat and this is the exception, I am not able to fix it, any ideas?

Hello, I ran some quick tests with the model on Samsung RTL...
It seems that the device original resolution is not supported by, either (or both) the MediaRecorder or the VirtualDisplay... (Again  quick test, didn't do much research)
For now 2 solutions:

You select a specific resolution in the app settings (e.g. 1080p);

As you built from the code instead of installing the apk, you can set a specific resolution inside the code (e.g. 1920 1080, or try one that fits better and works).

I'll add to my todo list to check/validate the supported resolutions inside the code in a future update...

That worked, thanks a lot! Wish you the best, bye!


Feature/fbs 29 incluir info latest

What type of PR is this?
/kind feature
What this PR does / why we need it: Add information on whether the workflow is the latest version
Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Cleanup of duplicated data on payloads

Additional documentation e.g., usage docs, etc.:

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


bfloat16 conv crashing on ampere

import jax
import jax.numpy as jnp
key = jax.random.PRNGKey(42)

inp = jax.random.normal(key, shape=(5,3,16,16), dtype=jnp.bfloat16)
k = jax.random.normal(key, shape=(8,3,4,4), dtype=jnp.bfloat16)
print(jax.lax.conv(inp, k, (1,1), 'same').shape)

should produce the error:
F external/org_tensorflow/tensorflow/stream_executor/cuda/cuda_dnn.cc:1011] Invalid DNN data type: 7

What versions of CUDA, CuDNN, jax, and jaxlib do you have?

CUDA 11.4
CuDNN 8.2
jax: 0.2.20
jaxlib: 0.1.71

card i'm testing on is an rtx 3090

I suspect this is because jaxlib is built against CuDNN 8.1. Things would probably work if you (or we) built a jaxlib from source against CuDNN 8.2.

Jaxlib for Cuda 11.1 is built against CuDNN 8.0.5 AFAIK

There's still a bug here, because it shouldn't crash, but perhaps we should switch our releases to a newer CuDNN across the board.

When I tried to do that (Using a wheel built with Cuda 11.2 and running on Cuda 11.1), the tests started failing saying that Cudnn version does not work for Cuda 11.1 since its 8.1 and Cuda 11.1 expects 8.0.5.xx

@yashk2810 NVidia claim CuDNN 8.2 is compatible with CUDA 11.1+: https://docs.nvidia.com/deeplearning/cudnn/support-matrix/index.html#cudnn-versions-824

CC @cheshire

I think this should be fixed by the updated wheels that @yashk2810 linked to. Please reopen the issue if you are still having problems!


Added 2 additional Weapon Sets in CS: Random Dark, Random Classic

Added a Random Dark and Random Classic weapon set to combat simulator. In Random Dark, it will randomly only pick PD weapons. In Random Classic, it will randomly pick GE weapons + shield.

is this also "True Random" where the game automatically randomizes the weapons for each new match? The vanilla game doesnt randomize the weapons automatically, PDXBLA fixed this if I'm remembering correctly

No, it doesn't include "True Random". It only randomizes the weapons when you select the weapon set.

is this also "True Random" where the game automatically randomizes the weapons for each new match?

Jonaeru has recently added true random in the form of Auto Random in PR #412


unwind: skip FDEs with initial address of 0

The panic example in the app-template can cause a broken backtrace like this:
stack backtrace:
   0: 0x00001450 @ HardFaultTrampoline
      <exception entry>
   1: 0x000008d4 @ lib::inline::__udf
        at ./asm/inline.rs:172:5
   2: 0x000008d4 @ __udf
        at ./asm/lib.rs:49:17
   3: 0x000001ba @ cortex_m::asm::udf
        at [...]/.cargo/registry/src/github.com-1ecc6299db9ec823/cortex-m-0.7.3/src/asm.rs:43:5
   4: 0x000001c4 @ _defmt_panic
        at [...]/src/lib.rs:13:5
   5: 0x000001b0 @ defmt::export::panic
        at [...]/.cargo/registry/src/github.com-1ecc6299db9ec823/defmt-0.3.0/src/export/mod.rs:125:14
   6: 0x000001b0 @ panic::__cortex_m_rt_main
        at [...]/src/bin/panic.rs:10:5
   7: 0x00000168 @ main
        at [...]/src/bin/panic.rs:6:1
   8: 0x00000144 @ Reset
   9: 0x00000100 @ Reset
  10: 0x52205244 @ __sheap

This appeared to have a different cause from https://github.com/knurling-rs/probe-run/issues/277, since the fix for that didn't fix the backtrace here.
After a lot of investigation, it turned out that what was going on is that there are multiple frame description entries (FDEs) in the debuginfo that claim to apply to some addresses, and we happened to pick the wrong one while unwinding from Reset in frame 8, causing us to restore registers incorrectly and then attempting to jump to a nonsense address.
This seems to be limited to FDEs describing presumably dead code, whose base address gets reset to 0 when they're included in the final ELF, so this PR fixes it by ignoring any FDEs that claim to apply to address 0.

bors r+


Great project! Looking forward to examples for transaction history

I know you just started this. Been looking for a python wrapper so thank you. How do I run?
Obviously, this is not the way ...
from provider import Provider
Provider().get_transaction_history(
    address="rdx1...",
    size=1000
)

Hey man, I just saw this. Here is a working example which showcases how you can get the transaction history for a given address:
import Radix

# Creating the provider object which will be talking to the blockchain
provider: Radix.Provider = Radix.Provider(Radix.Network.STOKENET)

# Getting the transaction history for a given address
history: dict = provider.get_transaction_history(
    address = 'tdx1qspqqecwh3tgsgz92l4d4f0e4egmfe86049dj75pgq347fkkfmg84pgx9um0v',
    size = 100
).json()

print(history['result'])

In this case, I'm connecting my provider to the Stokenet and not to the mainnet and I'm asking the provider to get me the transaction history for the stokenet address tdx1qspqqecwh3tgsgz92l4d4f0e4egmfe86049dj75pgq347fkkfmg84pgx9um0v.
You can modify the above code to run on the mainnet by doing the following:
import Radix

# Creating the provider object which will be talking to the blockchain
provider: Radix.Provider = Radix.Provider(Radix.Network.MAINNET)

# Getting the transaction history for a given address
history: dict = provider.get_transaction_history(
    address = 'rdx1...',
    size = 100
).json()

print(history['result'])

Let me know if you need any additional help and I'd be glad to help :)


UPM entry?

I am currently creating a package which includes a set of scenes for other projects to use. Those scenes have lottie animations. Due to Unity's limitation that packages can't have git dependencies (source: https://docs.unity3d.com/Manual/upm-git.html), I really need this in an importable format for that if possible

Hello @gardyna, thank you for your interest in this plugin! Could you please provide additional details on how it would be convenient for you to use the plugin? Are you looking to specify this plugin in the "dependencies" of your package? If possible, could you also share some links where this is discussed?

You know, you can actually declare a dependency on the com.gindemit.rlottie by version, it doesn't really matter if you install it using Git URLs, .tgz files or by downloading the package and extracting it inside the Packages folder.
Now, if you want the dependency to be installed automatically when installing the package that depends on it, you can instruct people to setup the OpenUPM scoped registry. Since this package is registered there (https://openupm.com/packages/com.gindemit.rlottie), it should be downloaded as a transitive dependency by Unity automatically.


Deep-copy in reducer seems inefficient

Was skimming through the codebase trying to get a feel for how this library works.  Saw the use of data[action.name].value[action.key]--; and was at first concerned that the reducer was directly mutating state.  It looks like the line extend(true, {}, state) avoids that, but on the other hand the reducer is always doing a deep copy of state, even if the action gets ignored by the reducer.  That seems like a waste of CPU cycles.  In addition, if everything is always deep copied, then components relying on data that wasn't modified by a given action could think that their data has actually changed because the references are different.

Thanks!

Erm... looking at that diff, it appears that now that reducer really is mutating state, which is definitely not good.

https://github.com/tomat/react-reflorp/blob/master/src/utils/reducer.js

Cool.  Looks like it's now not mutating, and only cloning when it has to.  I suspect you could probably switch it over to do shallow cloning instead if you updated the write logic appropriately, as the deep cloning might still cause components to update too often (see the Redux FAQ question on deep-cloning state for more info: http://redux.js.org/docs/FAQ.html#performance-clone-state).  Does look better, though.