text:
IKEA ICTC-G-1 flood Hass.io so it looses connection with UI

zigbee2mqtt add-on version (if edge, please report commit hash):
1.7.0
Operating environment (HassOS, Virtual Machine, Device/platform running Hass.io):

Hass.io on Orange Pi Plus 2 V:0.101.3
Description of problem:
If I turn knob few times Hass.io UI looses connection with the server for about 1 minute. Also I noticed that brightness numbers do not changes evenly. There are stutters, skips in value change responce delays on the /states page.
There are no huge automations or something that may put a load on CPU of my old Orange Pi 2. Usual CPU load is around few %.
Your entire configuration from the frontend (with sensitive fields redacted):
{
  "data_path": "/share/zigbee2mqtt",
  "devices": "devices.yaml",
  "groups": "groups.yaml",
  "homeassistant": true,
  "permit_join": false,
  "mqtt": {
    "base_topic": "zigbee2mqtt",
    "server": "mqtt://192.168.1.XX",
    "user": "XXXXXX",
    "password": "XXXXXXXXXXX"
  },
  "serial": {
    "port": "/dev/serial/by-id/usb-Texas_Instruments_TI_CC2531_USB_CDC___0X00124B0019430C17-if00"
  },
  "advanced": {
    "pan_id": 6754,
    "channel": 15,
    "network_key": [
      1,
      3,
      5,
      7,
      9,
      11,
      13,
      15,
      0,
      2,
      4,
      6,
      8,
      10,
      12,
      13
    ],
    "availability_blacklist": []
  },
  "ban": [],
  "whitelist": [],
  "queue": {},
  "socat": {
    "enabled": false,
    "master": "pty,raw,echo=0,link=/dev/ttyZ2M,mode=777",
    "slave": "tcp-listen:8485,keepalive,nodelay,reuseaddr,keepidle=1,keepintvl=1,keepcnt=5",
    "restartdelay": 1,
    "initialdelay": 1,
    "options": "-d -d",
    "log": false
  }
}

Your logs from Hass.io
Nothing interesting in Hass.io log:
2019-11-12 19:27:04 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.2935093776] Client exceeded max pending messages [2]: 512 ... 2019-11-12 19:27:04 ERROR (MainThread) [homeassistant.components.websocket_api.http.connection.2935093776] Client exceeded max pending messages [2]: 512
Zigbee2mqtt log is flooded as well. You can notice ~30s hang in the end. More than 20 messages per second but brightness does not change every time.
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":173,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":173,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":39,"rate":195,"brightness":173,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":39,"rate":195,"brightness":173,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":172,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":172,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":172,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":172,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":39,"rate":195,"brightness":172,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":39,"rate":195,"brightness":172,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":171,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":171,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":170,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":170,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":169,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":169,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":168,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":168,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":167,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:46: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":167,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":166,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":166,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":165,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":165,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":164,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":164,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":163,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":163,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":162,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":162,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":161,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":161,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":160,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":160,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":159,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":159,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":158,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":158,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":157,"level":0,"battery":87,"action":"rotate_left"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":157,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":156,"level":0,"battery":87,"action":"rotate_stop"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":156,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":36,"rate":195,"brightness":156,"level":0,"battery":87,"action":"rotate_stop"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":36,"rate":195,"brightness":156,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":154,"level":0,"battery":87,"action":"rotate_stop"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":154,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":36,"rate":195,"brightness":154,"level":0,"battery":87,"action":"rotate_stop"}'
zigbee2mqtt:info  2019-11-12T17:27:47: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":36,"rate":195,"brightness":154,"level":0,"battery":87,"action":""}'
zigbee2mqtt:info  2019-11-12T17:28:21: MQTT publish: topic 'zigbee2mqtt/0x14b457fffe46a74e', payload '{"occupancy":false,"tamper":false,"battery_low":false,"linkquality":84,"battery":"100.00","voltage":3000}'

One quick rotation for about 180 degrees makes 92 messages per second and almost no change in brightness, stutter in UI with lost connection message:
zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":232,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":232,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":39,"rate":195,"brightness":232,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":39,"rate":195,"brightness":232,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":233,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":233,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":233,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":233,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":42,"rate":195,"brightness":233,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":42,"rate":195,"brightness":233,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":234,"level":0,"battery":87,"action":"rotate_stop"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":234,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":42,"rate":195,"brightness":234,"level":0,"battery":87,"action":"rotate_stop"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":42,"rate":195,"brightness":234,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":236,"level":0,"battery":87,"action":"rotate_stop"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":236,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":44,"rate":195,"brightness":236,"level":0,"battery":87,"action":"rotate_stop"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":44,"rate":195,"brightness":236,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":236,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":236,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":39,"rate":195,"brightness":236,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":39,"rate":195,"brightness":236,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":235,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":235,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":235,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":235,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":39,"rate":195,"brightness":235,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":39,"rate":195,"brightness":235,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":234,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":234,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":233,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":233,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":232,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":232,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":231,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":231,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":230,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":230,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":229,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":229,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":228,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":228,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":227,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":227,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":226,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":226,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":225,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":225,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":224,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":224,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":223,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":223,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":222,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":222,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":221,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":221,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":220,"level":0,"battery":87,"action":"rotate_left"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":220,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":219,"level":0,"battery":87,"action":"rotate_stop"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":219,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":26,"rate":195,"brightness":219,"level":0,"battery":87,"action":"rotate_stop"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":26,"rate":195,"brightness":219,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":217,"level":0,"battery":87,"action":"rotate_stop"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":217,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":26,"rate":195,"brightness":217,"level":0,"battery":87,"action":"rotate_stop"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":26,"rate":195,"brightness":217,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":217,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":217,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":28,"rate":195,"brightness":217,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":28,"rate":195,"brightness":217,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":217,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":217,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":28,"rate":195,"brightness":217,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":28,"rate":195,"brightness":217,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":218,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":218,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":219,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":219,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":220,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":220,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":221,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":221,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":222,"level":0,"battery":87,"action":"rotate_right"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":222,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":223,"level":0,"battery":87,"action":"rotate_stop"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":223,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":36,"rate":195,"brightness":223,"level":0,"battery":87,"action":"rotate_stop"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":36,"rate":195,"brightness":223,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":225,"level":0,"battery":87,"action":"rotate_stop"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":84,"rate":195,"brightness":225,"level":0,"battery":87,"action":""}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":36,"rate":195,"brightness":225,"level":0,"battery":87,"action":"rotate_stop"}' zigbee2mqtt:info  2019-11-12T17:49:41: MQTT publish: topic 'zigbee2mqtt/0x000b57fffe13cba9', payload '{"linkquality":36,"rate":195,"brightness":225,"level":0,"battery":87,"action":""}'

I have the same problem on Hassio @RPi4. One thing is disconnected UI, the second is lagging simple automation:
`

alias: 'Oknyo/Symfonisk volume up'
trigger:
platform: state
entity_id: sensor.symfonisk_sound_black_action
to: rotate_right
action:
service: media_player.volume_up
entity_id: media_player.onkyo_tn_8270
`

regardless good link quality (>60)

This should be posted in the zigbee2mqtt issue tracker if it hasn't been already, as the issue template suggests.

I posted it and later created PR with workaround to fix this problem, already merged to dev branch.
https://github.com/Koenkk/zigbee2mqtt/issues/2354

Noice!

authors: DimsterTim danielwelch frontend89


text:
Refactor code from init.py

YAS3FS is an impressive piece of work so I hate to suggest something that might come across as something less than praise but... having almost the entire codebase inside a 3k line __init__.py file seems a little ... unusual.
Have you given any thought to breaking that out into separate files? Would you be open to folks working on something like that?

Hi Perry,
I think you're right and it is due to poor planning on my side.
The project started as a proof of concept to test the advantages of caching
compared to the more traditional s3fs approach.
Then I kept it as a single file to make it easier to share with a single
link, but since it was packaged to be distributed via pip that doesn't make
sense anymore.
I have no time to invest on this project, but I am more than happy to add
contributors to enhance and refactor it.
On Wed, Mar 30, 2016 at 3:24 AM, Perry Stoll notifications@github.com
wrote:

YAS3FS is an impressive piece of work so I hate to suggest something that
might come across as something less than praise but... having almost the
entire codebase inside a 3k line init.py file seems a little ...
unusual.
Have you given any thought to breaking that out into separate files? Would
you be open to folks working on something like that?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
https://github.com/danilop/yas3fs/issues/123

source: gharchive/issue

authors: danilop pstoll

license: mit

license_type: permissive

license_source: bigquery


text:
UserChange event doesn't fire if the value exists multiple times on the slider

Hi, I have a slider that contains (possibly duplicate) timestamps. Whenever I change from a tick on the slider to another one with the same timestamp, I expect the UserChange event to be emitted but this doesn't seem to be the case. In all the other cases (when the timestamps differ) the event is correctly emitted.
Is there any known workaround or is it planned to fix that?

Hello,
Could be because both ticks have the same value (It may think it is the same tick). I don't know any fix or workaround, if possible it would be best to not have duplicates in the slider.

Copied to main repo

license: MIT

license_source: github-api


text:
Proxy score integration and checker

Hello, this script seems to be working well since I tested it for 6 hours.
It could be a great idea to add a proxy score checker, and remove any proxy from the list if it has a low score.
I sent 4 proxies on my list, and only 2 are working properly, while the others keep sending pings even though they’re disconnected from Getgrass.

Hello, this script seems to be working well since I tested it for 6 hours.
It could be a great idea to add a proxy score checker, and remove any proxy from the list if it has a low score.
I sent 4 proxies on my list, and only 2 are working properly, while the others keep sending pings even though they’re disconnected from Getgrass.

Great idea, thanks. Will figured out how to implement it.


text:
PHP7 incompatibility

Hi
I tried to run some project on a PHP7 machine, which resulted in the error PHP Fatal error: Cannot use 'String' as class name as it is reserved in /var/www/foobar/vendor/doctrine/phpcr-odm/lib/Doctrine/ODM/PHPCR/Mapping/Annotations/String.php on line 28.
I think the issue is described here: doctrine/phpcr-odm#678. As I see it, the issue should be eliminated by updating this bundle to ~1.3 https://github.com/doctrine/DoctrinePHPCRBundle (you require only version ~1.2 https://github.com/dantleech/glob/blob/master/composer.json)
Thanks in advance for checking (and if it should be the error, fixing it :))

Hi, thanks for reporting this.
This library only provides an adapter for the PHPCR-ODM, it does not use any of the reserved keywords itself, so it is compatible both with PHP 5 and 7, and the PHPCR-ODM dependency is correct.
The issue will be found in another of your liraries which uses the PHP7-reserved PHPCR-ODM annotations.
Please reopen if you disagree.

authors: dantleech pascalwacker

repo: dantleech/glob


text:
Chip suggestion gives error while searching for multiple chip inputs on android.

E/MethodChannel#flutter/textinput(22539): Failed to handle method call
E/MethodChannel#flutter/textinput(22539): java.lang.IndexOutOfBoundsException: invalid composing start: 0
E/MethodChannel#flutter/textinput(22539): 	at io.flutter.embedding.engine.systemchannels.TextInputChannel$TextEditState.(TextInputChannel.java:719)
E/MethodChannel#flutter/textinput(22539): 	at io.flutter.embedding.engine.systemchannels.TextInputChannel$TextEditState.fromJson(TextInputChannel.java:680)
E/MethodChannel#flutter/textinput(22539): 	at io.flutter.embedding.engine.systemchannels.TextInputChannel$1.onMethodCall(TextInputChannel.java:91)
E/MethodChannel#flutter/textinput(22539): 	at io.flutter.plugin.common.MethodChannel$IncomingMethodCallHandler.onMessage(MethodChannel.java:233)
E/MethodChannel#flutter/textinput(22539): 	at io.flutter.embedding.engine.dart.DartMessenger.handleMessageFromDart(DartMessenger.java:85)
E/MethodChannel#flutter/textinput(22539): 	at io.flutter.embedding.engine.FlutterJNI.handlePlatformMessage(FlutterJNI.java:818)
E/MethodChannel#flutter/textinput(22539): 	at android.os.MessageQueue.nativePollOnce(Native Method)
E/MethodChannel#flutter/textinput(22539): 	at android.os.MessageQueue.next(MessageQueue.java:335)
E/MethodChannel#flutter/textinput(22539): 	at android.os.Looper.loop(Looper.java:183)
E/MethodChannel#flutter/textinput(22539): 	at android.app.ActivityThread.main(ActivityThread.java:8010)
E/MethodChannel#flutter/textinput(22539): 	at java.lang.reflect.Method.invoke(Native Method)
E/MethodChannel#flutter/textinput(22539): 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:631)
E/MethodChannel#flutter/textinput(22539): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:978)
E/flutter (22539): [ERROR:flutter/lib/ui/ui_dart_state.cc(186)] Unhandled Exception: PlatformException(error, invalid composing start: 0, null, java.lang.IndexOutOfBoundsException: invalid composing start: 0
E/flutter (22539): 	at io.flutter.embedding.engine.systemchannels.TextInputChannel$TextEditState.(TextInputChannel.java:719)
E/flutter (22539): 	at io.flutter.embedding.engine.systemchannels.TextInputChannel$TextEditState.fromJson(TextInputChannel.java:680)
E/flutter (22539): 	at io.flutter.embedding.engine.systemchannels.TextInputChannel$1.onMethodCall(TextInputChannel.java:91)
E/flutter (22539): 	at io.flutter.plugin.common.MethodChannel$IncomingMethodCallHandler.onMessage(MethodChannel.java:233)
E/flutter (22539): 	at io.flutter.embedding.engine.dart.DartMessenger.handleMessageFromDart(DartMessenger.java:85)
E/flutter (22539): 	at io.flutter.embedding.engine.FlutterJNI.handlePlatformMessage(FlutterJNI.java:818)
E/flutter (22539): 	at android.os.MessageQueue.nativePollOnce(Native Method)
E/flutter (22539): 	at android.os.MessageQueue.next(MessageQueue.java:335)
E/flutter (22539): 	at android.os.Looper.loop(Looper.java:183)
E/flutter (22539): 	at android.app.ActivityThread.main(ActivityThread.java:8010)
E/flutter (22539): 	at java.lang.reflect.Method.invoke(Native Method)
E/flutter (22539): 	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:631)
E/flutter (22539): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:978)
E/flutter (22539): )
E/flutter (22539): #0      JSONMethodCodec.decodeEnvelope (package:flutter/src/services/message_codecs.dart:158:7)
E/flutter (22539): #1      MethodChannel._invokeMethod (package:flutter/src/services/platform_channel.dart:158:18)
E/flutter (22539):

E/flutter (21999): [ERROR:flutter/lib/ui/ui_dart_state.cc(186)] Unhandled Exception: PlatformException(error, invalid composing start: 1, null, java.lang.IndexOutOfBoundsException: invalid composing start: 1
E/flutter (21999):      at io.flutter.embedding.engine.e.x$d.(SourceFile:15)
E/flutter (21999):      at io.flutter.embedding.engine.e.x$d.a(SourceFile:6)
E/flutter (21999):      at io.flutter.embedding.engine.e.w.a(SourceFile:29)
E/flutter (21999):      at f.a.a.a.o$a.a(SourceFile:2)
E/flutter (21999):      at io.flutter.embedding.engine.a.c.a(SourceFile:12)
E/flutter (21999):      at io.flutter.embedding.engine.FlutterJNI.handlePlatformMessage(SourceFile:2)
E/flutter (21999):      at android.os.MessageQueue.nativePollOnce(Native Method)
E/flutter (21999):      at android.os.MessageQueue.next(MessageQueue.java:336)
E/flutter (21999):      at android.os.Looper.loop(Looper.java:197)
E/flutter (21999):      at android.app.ActivityThread.main(ActivityThread.java:7948)
E/flutter (21999):      at java.lang.reflect.Method.invoke(Native Method)
E/flutter (21999):      at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:493)
E/flutter (21999):      at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1075)
E/flutter (21999): )
E/flutter (21999): #0      JSONMethodCodec.decodeEnvelope (package:flutter/src/services/message_codecs.dart:158)
E/flutter (21999): #1      MethodChannel._invokeMethod (package:flutter/src/services/platform_channel.dart:158)
E/flutter (21999):


text:
Remove dependency on Azure namespace for pubsub.azure.eventhubs conformance test

Each time Azure infrastructure namespace changes, like #1620, it will create issues like #1637. This task is to remove that dependency.

in 1 year we have never changed this name, and we generally won't be changing it. The only reason is that we migrated to a new Azure subscription and couldn't reuse existing resource naming.
Unfortunately this part of the test cannot be made dynamic today. https://github.com/dapr/components-contrib/blob/master/tests/config/pubsub/tests.yml allows overloading / injecting constant values only, with the exception of generating UUIDs.
I suppose there is a new syntax that could be introduced which would need to be supported here:
https://github.com/dapr/components-contrib/blob/master/tests/conformance/common.go
Which could then use values provided by environment variables. Today we only have $((uuid)). Maybe we can add $((env:SOMETHING)) which will look for the environment variable SOMETHING and use its value.
Anyways.. this is extremely overkill for something that will not likely change for the next year or more.

repo: dapr/components-contrib


text:
AWS SES components require secretKey and accessKey

Expected Behavior
When I create a component like this:
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: ses
spec:
  type: bindings.aws.ses
  version: v1
  metadata:
  - name: emailFrom
    value: "myacc@myemail.com"

From the documentation if I am using AWS IAM I should not add accessKey and secretKey.
Important
When running the Dapr sidecar (daprd) with your application on EKS (AWS Kubernetes), if you’re using a node/pod that has already been attached to an IAM policy defining access to AWS resources, you must not provide AWS access-key, secret-key, and tokens in the definition of the component spec you’re using.

Actual Behavior
At the moment I am receiving this error
[INIT_COMPONENT_FAILURE]: initialization error occurred for ses (bindings.aws.ses/v1): SES binding error: region, accessKey or secretKey fields are required in metadata"

Steps to Reproduce the Problem

Release Note

RELEASE NOTE:

@cciobanu98 can you please go to the linked docs issue dapr/docs#3292 and comment with /assign so that the issue is assigned to you?
We may choose to revert any pull requests that do not have documentation.


text:
Add support for AAD auth in Azure Storage Queues binding

Description
Adds Azure AD auth support for Azure Storage Queues binding.
Also fixes the test failures in master due to the component, such as: https://github.com/dapr/components-contrib/actions/runs/2599442926
Issue reference
See #1103
Checklist
Please make sure you've completed the relevant tasks for this PR, out of the following list:

[X] Code compiles correctly
[X] Created/updated tests
[ ] Extended the documentation / Created issue in the https://github.com/dapr/docs/ repo: @ItalyPaleAle  TODO

/ok-to-test

/ok-to-test

source: gharchive/pull-request


text:
Implement actor service via fastapi

Describe the proposal
Implement actor service via aiohttp which is similar to flask_dapr extension implementation.

done

while working on hackathon, we found the thread issue in flask implementation. so I need to switch from flask to fastapi which supports async natively.

repo: dapr/python-sdk


text:
YAMDA unable to find CTCF motif in toy dataset that works with HOMER

Hello @daquang,
Thank you for making your code available. We've been experimenting with YAMDA and have been running into some difficulties on relatively straightforward datasets like CTCF. To demonstrate the issues, we prepared a small dataset where the positive set had 5000 regions of length 400bp drawn from IDR optimal CTCF peaks from ENCODE, and the negative set had 5000 regions of length 400bp drawn randomly from the genome. The top discovered HOMER motif on that dataset is shown below, and a Colab notebook running HOMER on the dataset is here:
Homer motif 1:

By contrast, when I run YAMDA on the same dataset (both with or without the -e option, and with and without the negative set), I get highly degenerate motifs as shown below (they are the only entries in the motifs.txt output file). A Colab notebook replicating the results is here:
With the -e option and a negative set (python YAMDA/run_em.py -e -r -i central400_pos_seqs_concat.fa -j central400_neg_seqs_concat.fa -oc yamda_test_e_pos_neg):

Without the -e option and a negative set (python YAMDA/run_em.py -r -i central400_pos_seqs_concat.fa -j central400_neg_seqs_concat.fa -oc yamda_test_no_e_pos_neg):

With the -e option and no negative set (python YAMDA/run_em.py -e -r -i pos_seqs_concat.fa -oc yamda_test_e_posonly):

Without the -e option and no negative set (python YAMDA/run_em.py -r -i pos_seqs_concat.fa -oc yamda_test_no_e_posonly):

Advice on what to do would be appreciated.
Also tagging @jsu27 and @akundaje.

I'm noticing that there are lower case sequences in your FASTA file. I recommend masking lower case letters with capital N's. I also suggest using a dinucleotide shuffled control instead of a random genome control. It's natural to try a random genome control, but I found in practice it does not work well because the binding sites tend to occur in C/G rich regions (e.g. promoters, cpg islands), which will bias motif discovery towards C/G repeats.

Ok, we can try that. When the user does not provide a negative set, what kind of background is assumed?

Also, can you elaborate on what the -e option means? The documentation just says Erase an entire sequence if it contains a discovered motif (default: erase individual motif occurrences). - would you recommend keeping in the -e argument for these datasets?

One more question: why was there only one entry in motifs.txt? Is there some option that can be used to induce YAMDA to search for more than one motif? One would hope that if YAMDA can search for multiple motifs, it would be able to handle the case where the positive and negative sets have different C/G contents.

Update: ok, I see there's an NMOTIFS option that defaults to 1. We can see what happens if that is varied. Do you have a recommended value to set it to? Also, I'm guessing that this interacts with the -e argument, in that a sequence is removed from consideration if a motif hit is found. So if searching for multiple motifs, I assume you'd suggest we leave out -e?

If you think each whole sequence has at most one motif occurrence, use -e. Otherwise, leave it out. Either way, it probably makes little difference and only matters if you intend on discovering multiple motifs. Notice how the output folder has positive and negative FASTA files. After discovering one motif, motif occurrences will be deleted from positive and negative sequences, and upon completion of the program the positive and negative sequences (with motif occurrences deleted) will be outputted. If you use -e, then the whole sequence will be removed if it has even one motif occurrence, otherwise only the individual motif occurrence gets deleted (e.g. ACCCGTGTC becomes ACNNNNGTC).
I usually set NMOTIFS to 1 because most users just use it on ChIP-seq data, which typically only have one major motif anyways. I have been able to grab multiple motifs in DGF data before. Perhaps I should put an example in the README demonstrating how to do this.
If a negative set is not used, then initial probability matrices will be generated by random probabilities, instead of derived from enriched k-mers. I do not recommend this at all. Seeding, and motif discovery in general, is much more of an art than a science. It is an attempt to make a simple story out of complicated data, which is why I typically prefer complex "black box" models these days. Nevertheless, the market demands simple interpretable models, and the market will get simple interpretable models. I was thinking at one point that I may adapt THiCweed's clustering method (https://academic.oup.com/nar/article/46/5/e29/4754463) to generate a set of strong "seed" PWMs, and then use EM to refine these seeds. I have a feeling the two algorithms will make a powerful combination.
As you can probably tell with the original MEME algorithm, MEME has a TON of heuristics. Clearly, with over twenty years of experience, they managed to collect a set of heuristics that works for a lot of users' test cases, although of course MEME will have issues for some datasets too. At this point, MEME has been modified so many times, it's hard to reproduce all of their heuristics, although I tried my best to reproduce the ones that lend themselves to mini batch training. For example, MEME has a -wnsites argument that I cannot find any information on from any of their publications, but the default parameter they chose ends up being very effective for most of the datasets they come across. I tried to implement my own version (facetiously called -fudge), but I doubt it is a perfect copy.

authors: AvantiShri daquang

repo: daquang/YAMDA


text:
Auto complete clears input

Hi,
Not 100% sure if this is an error, or if I'm just doing it incorrectly.  I have the following page:
class TestPage extends Webpage( Finance ) {
    this.require( Autocomplete )
    body.contents += new Autocomplete {
        autocomplete.search := (
            ( query : String ) => Seq( "aaa", "aab" ).map( s => AutocompleteResult( s, s ))
        )
    }
}

If I type "a" in the input, the right options come up.  If I select one the input is filled in.  But if I click anywhere on the page the input is cleared.
The same thing happens on the examples site: http://www.hyperscala.org/example/ui/autocomplete.html
If this is expected behaviour, how do I get it to stay put?
Cheers,
Hugh.

This is expected behavior, but perhaps it shouldn't be.  The reason this happens is because when the field loses focus the visual representation is updated to reflect the currently selected element.  In this case because you haven't typed in anything that matches properly to a option and you haven't selected one, it reverts to null which is represented by default as an empty field.
How would you want this to work differently?

Ah, sorry about that.
So what I was looking for was an input box which could auto complete suggestions but would also allow me to enter new text, too.
BTW, if I click on the "aaa" from the suggestions, it still goes away if I click elsewhere afterwards.
If I then type "a" in the box and click away, it then puts "null" in the box.
If after that I type "a" in the box and click away, it leaves the "a" in the box.

You are correct, there are some serious issues with that component.  You might want to consider http://hyperscala.org/example/ux/singleselectlist.html instead.  It's far more flexible both in style and function.  I'll try to get a look at Autocomplete in the near future though.

Thanks for the amazing quick responses :-)

I don't promote Hyperscala much, but I use it for many of my clients, so I'm constantly working on it.
BTW, how did you come across Hyperscala?

I can't remember where I found it originally.  I first saw it years ago, waiting for a chance to play (I'm a compiler guy so building web stuff is miles off my list).
IMO, you have exactly the right design methodology.  None of the others make sense :-)

It's funny, I've created several web frameworks over the years (http://www.jseamless.org is my previous iteration), but the reason behind it is because I hate web development. It's ironic how much more time I've actually spent doing web development to try to avoid doing web development.
I appreciate the kind words. The goal of Hyperscala is to be clean and focused on Scala development, not some crazy new language you have to learn.  Feel free to offer any pull requests if you have anything additional to offer. Hyperscala is coming along pretty well, but I'm only one person and can always use more help. :)

I would love to.  Gonna take me a while to get into it though - just started looking this morning and an afternoon a year ago.
I do the same thing.  I often spend a month getting a computer to do something automatically that I could probably do manually in 5 minutes :-)
BTW, are you likely to do an integration or release build to maven in the near future?

Yes, I'm wrapping up my FabricJS wrapper and then I'll be doing the 0.10.0 release...if you're running off a previous release I would recommend either updating to the snapshot or building locally as it's a pretty major change.

This has been fixed with the latest commit. Take a look at the updated example to see how it should be utilized: https://github.com/darkfrog26/hyperscala/blob/master/examples/src/main/scala/org/hyperscala/examples/ui/AutoCompleteExample.scala

Thanks Matt!


text:
Text disappears after edit.

As of commit 44200cba I'm seeing what seems to be a regression where text disappears in places like editboxes and spinners after any sort of edit.
From investigation it seems like the fault is with the introduced line
if( !m_overrideSkinColour )
	m_colour = m_stateInformation[m_currentState].defaultColour;

In Colibri::Renderable::setState.
If this line is commented or removed it works as before. It seems m_stateInformation contains a colour value with all 0s for labels, which causes the text to disappear. Colibri::Label does not contain a call to _setSkinPack or anything like that, so I think these values aren't being initialized to anything.
I was going to do a pull request because I found a few solutions (you can just set m_stateInformation.defaultColour in the label constructor), but I felt like I don't know what the solution is from a code architecture perspective, so I'm raising it as an issue instead.

Thanks!
There is a raw memset which was overriding the sane default value with all 0s.

authors: darksylinc edherbert

repo: darksylinc/colibrigui


text:
SDK version check warns about -edge versions needlessly

SDK version 1.12.0-edge.13a372eca09d01941c6c520b3b7ea18200fb5658 is older than the recommended version of 1.12.0. Please visit www.dartlang.org to download a recent SDK.
This was added in #343 (which is awesome!) but it doesn't need to warn me about edge versions.
Maybe the semantic versioning isn't quite right here?  Maybe it needs to be +edge instead of -edge?
http://semver.org/spec/v2.0.0-rc.1.html
I suspect that Dart has some built in ability to compare semantic versions that @devoncarew used here?

Yeah, I'm using a semantic compare, but I think technically 1.12.0-foo < 1.12.0.
If we want to special case edge versions we can.
But you'll probably want to upgrade to 1.12.0 stable, and more likely a 1.13.0 dev release :)

Ah.  Atom was pointed at an old Dart. :(

mb.

I would have been slightly less confused if the warning had included the path to the SDK it was using.  But this was also just user error on my part.  Turns out I was pointing at an old SDK.

It's easy enough to show the path as well, and it will help users figure out where the old version is coming from.

authors: devoncarew eseidelGoogle

repo: dart-atom/dartlang


text:
Workflow for prepping to publish multiple independent packages in one commit

In the test repo we have 3 packages, test -> test_core -> test_api. Where a dependency exists between them they pin exact versions. We typically use the pubspec_overrides.yaml file to override the deps so that version solves work
It looks like pub lish --dry-run does not use the pubspec_overrides.yaml overrides though, so the validation step fails when we go to publish the versions (with a bad version solve).

example failure is here https://github.com/dart-lang/test/actions/runs/4177742557/jobs/7235693797

Great, thanks for the info. I imagine - due to the dependencies above - that you publish them in the reverse order? So, test_api, then test_core, then test?

One way I can imagine handling this is to parse the errors and understand when an error is specifically for a missing package which is also one that is marked as publishable in the same action.
I'm not sure if that way would be brittle, but it wouldn't give the full safety that a pub feature like https://github.com/dart-lang/pub/issues/2795 would
If we had the ability to simulate already published packages, we could have a very robust check for packages that are safe to publish by a mono-repo by iteratively running the check and treating publishable packages as published.

authors: devoncarew jakemac53 natebosch

repo: dart-lang/ecosystem


text:
dart2js: useless argument / parameter on generative constructor bodies with initializing formals

This probably won't make a huge difference, but it is an example of where we can remove unused parameters without much analysis.  I think there are 20-30 useless expressions that can be eliminated in swarm.
An initializing formal is not a parameter of a generative constructor body.
-------- example
class A {
  var a,b,c,d;
 A(this.a, b, c, d) : b = b {
    // There are only three parameters: b, c, d.  'a' resolves to this.a
    if (false) throw 123;  // inhibit inlining
    this.c = c;
    a++;b++;c++;
    this.d = [a, b, c, d];
  }
  toString() => 'A($a, $b, $c, $d)';
}
make() => new A(10, 20, 30, 40);
main() {
  print((make)());
}
-------- output
A(11, 20, 30, [11, 21, 31, 40])
-------- generated code
  make: [function() {
    var t1 = new E.A(10, 20, null, null);
    t1.A$4(10, 20, 30, 40);
    return t1;
  }, "call$0", "make$closure", 0, 0, 0],
  main: ...,
  A: {
    ...,
    A$4: function(a, b, c, d) {
      var t1;
      this.c = c;
      t1 = this.a + 1;
      this.a = t1;
      this.d = [t1, b + 1, c + 1, d];
    }
  }

Notice that A$4 has a useless 'a' parameter, and the call is passed a useless argument.

GenerativeConstructorBodies also often have unused type parameters.

This still appears to be unexploited.
Current code:
  B = {
    A$: function(a, b, c, d) {
      var t1 = new B.A(a, b);
      t1.A$4(a, b, c, d);
      return t1;
    },
    make: function() {
      return B.A$(10, 20, 30, 40);
    },
    ...
    A: function A(t0, t1) {
      var _ = this;
      _.a = t0;
      _.b = t1;
      _.d = _.c = null;
    }
  };
  B.A.prototype = {
    A$4: function(a, b, c, d) {
      this.c = c;
      this.d = [++this.a, b + 1, c + 1, d];
    },
    toString$0: function(_) {
      var _this = this;
      return "A(" + _this.a + ", " + _this.b + ", " + H.S(_this.c) + ", " + H.S(_this.d) + ")";
    }
  };

repo: dart-lang/sdk


text:
Time outs in ContentShell trigger RuntimeError

It appears that some tests (see 19726, indexeddb_1_test in html.status) are showing a RuntimeError for a Timeout on content shell but an actual Timeout on dartium.

I'm guessing we no longer care about ContentShell.

authors: matanlurey vsmenon


text:
Analyzer should flag int-double type conversion

This issue was originally filed by jorg....@accorto.com

What steps will reproduce the problem?
bool initial = true;
int active = 5;
:
int ms = initial ? 0 : 1000;
if (active > 10)
  ms += (active/10) * 200;
What is the expected output?
no error/warning that "ms" became a double
Hint that
ms += (active~/10) * 200;
results in the correct type (int)

or better - as ms is defined as int the expected outcome is that it remains an int
so "no surprises" - i.e. the compiler does the ~/ automatically.

What do you see instead?
no warning - surprises at runtime.
What version of the product are you using?
1.9.3
On what operating system?
What browser (if applicable)?
n/a
Please provide any additional information below.

In the latest I get "A value of type 'double' can't be assigned to a variable of type 'int'. [invalid_assignment]"

authors: DartBot natebosch


text:
Please merge revision 206083c8b1520c77e66c2eb138aa88fc45a49321 into dev channel

@ricowind @whesse @kasperl
This fixes a problem in analysis server causing ".packages" files to be prioritized over "package root" settings specified in the user's IDE.  Without this fix, IDE "package root" settings become practically useless, because they will be ignored in favor of the ".packages" file created by "pub get".
Revision to be merged: 206083c8b1520c77e66c2eb138aa88fc45a49321
This merged cleanly.

Merged in 1.12.0-dev.5.2


text:
Disallow user defined classes that implement Future

Motivation: this makes it possible to fully align JS Promise and Dart Future.
In JS, you can create custom Promise classes by subclassing Promise but you cannot just duck type an object to be a Promise (equivalent of implements vs. extends in Dart).
There are only a few existing user defined Dart Future classes and it is not clear all of them really play well with dart:async as it is possible some parts of dart:async depend on future objects being instances of the _Future class.

/cc @nex3

There are several classes in the async package that implement Future: ResultFuture, DelegatingFuture, and TypeSafeFuture. All of these are used in the ecosystem, and the last one in particular is very widely-used since it's the best strong-mode-safe way of casting the generic type of a Future.
Currently the Future class cannot be extended. Even if it could, it's not clear to me how extension would work for these types; they all work by wrapping and forwarding to an inner instance of Future.

Chatted offline with @nex3 to see what the best way to support the functionality provided by these 3 classes.
Preliminary conclusions are it would make the most sense to add the cast functionality provided by TypeSafeFuture and friends directly to Future as the behavior is crucial for strong mode.
ResultFuture on the other hand can be implemented as a user mode Future subclass as long as Future has a constructor with the same behavior of the JavaScript Promise constructor. The behavior provided by this constructor is similar to that of Promise except that it is possible to subclass the type of the resulting Future
Example of the anticipated Future constructor which would be efficient to implement in Dart2JS:
class Future<T> {
  Future<T>(executor(resolve(T value) , reject(reason)));
}

To integrate well with Dart's error-handling, I'd expect that to be:
class Future<T> {
  Future<T>(void executor(void resolve(T value), void reject(error, [StackTrace stackTrace]));
}

cc @floitschG @lrhn @eernstg @munificent
Is this something we should consider?  There are definitely things out there which implement Future, so seems non-trivial.

There are definitely classes implementing Future. Most are wrappers of some sort, like DelegatingFuture, but I'm sure some are being more clever. I've generally tried to avoid classes that extend Future, but I'd be surprised if someone else haven't made one.
I think it's not going to be a viable change to disallow those classes now.

👍  to what @lrhn said. It would be helpful, but the cat's already out of the bag.

If the right solution is to prevent extend but allow implement for this particular class, we could just postpone this issue until we have the right tool for dealing with it, i.e., some general feature that allows us to declare "you can/cannot extend/implement/mix-in/... this class". At that time it may still be too much of a disruption to change class Future to interface Future (or whatever syntax we'll use for that) in ordrer to prevent subclassing, but it's then a library issue, not a language issue.
So I agree that we should not introduce special rules for Future at this point.

We already prevent subclassing of Future because all constructors are factory constructors. That's not sufficient to allow the compiler to assume that all Future instances are JS Promise objects.

Normally, all of dart:async is ok with user-supplied futures. We do have shortcuts, but never rely on them. (If we do, it's a bug).
Can't dart2js/DDC recognize, that a class implements Future and then subclass Promise?

@leafpetersen I presume this can be closed?

No planned.

authors: dgrove eernstg floitschG jacob314 leafpetersen lrhn munificent nex3


text:
Utf8Codec doesn't throw FormatException for single and paired UTF-16 surrogates

Please see https://api.dartlang.org/stable/1.22.0/dart-convert/Utf8Codec/Utf8Codec.html

const Utf8Codec({
bool allowMalformed: false
})
Instantiates a new Utf8Codec.
The optional allowMalformed argument defines how decoder (and decode) deal with invalid or unterminated character sequences.
If it is true (and not overridden at the method invocation) decode and the decoder replace invalid (or unterminated) octet sequences with the Unicode Replacement character U+FFFD (�). Otherwise they throw a FormatException.

For testing I used malformed examples from http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt. All is ok but 5.1 Single UTF-16 surrogates and 5.2 Paired UTF-16 surrogates
  Utf8Codec codec = new Utf8Codec(allowMalformed: false);
  // Single UTF-16 surrogates
  print(codec.decode([0xED, 0xA0, 0x80])); // �
  // Paired UTF-16 surrogates
  print(codec.decode([0xED, 0xA0, 0x80, 0xED, 0xB0, 0x80])); // 𐀀

FormatException be thrown here
Please note, that if allowMalformed is true, then Unicode Replacement character U+FFFD should be used
  Utf8Codec codec = new Utf8Codec(allowMalformed: true);
  // Single UTF-16 surrogates
  print(codec.decode([0xED, 0xA0, 0x80]).codeUnits); // prints [55296] which is U+D800, but should be U+FFFD

We have allowed invalid UTF-8 here because Dart strings can contain unpaired surrogates.
That's inconsistent, and could cause incompatibilities with other decoders.
I think we should transform encoded surrogates to U+FFFD in decoding and unpaired surrogates to U+FFFD in encoding.

This causes our test framework to output invalid utf8, in the case of the test log from the test that checks this property: co19/blob/master/LibTest/convert/Utf8Codec/decode_A03_t02.dart
This test log prints out the actual output of the decoder (an unpaired surrogate), and it gets stored to file, uploaded to cloud storage, and downloaded again as that invalid utf8 encoding of a single surrogate (the bytes [0xED, 0xA0, 0x80]).  Our programs don't have a problem with this, but other external programs like editors do.
I agree that fixing this would be good.

authors: lrhn sgrekhov whesse


text:
Base class type inference is wrong

See this reduced test case:
Simple: https://dartpad.dartlang.org/6ee6ea9b7f00bc1b6c7115a891ba88b8
How it was discovered in OverReact components: https://dartpad.dartlang.org/e5e40dd06c6beee77077773bc5880cc6
This issue was found in OverReact
I would expect classInstance to have a type of AbstractComponent
Only an issue is TypedBase implement Interface or if the generic params are left in.
This is in strong mode.

It appears that simply implementing any class in the example leads to the same analyzer error. They do not need to overlapping symbols or implementations.
I have updated the supplied example to illustrate this https://dartpad.dartlang.org/1c8aff38857a3cb5aa12f142d7b6ce67 .

@leafpetersen @kevmoo Is this expected behaviour? This seems to be an analyzer bug.

@bwilkerson @devoncarew ?

The problem is the definition of LUB, which comes into play with the ternary "?:" operator. I don't know whether inference can / will do better in the future, but for now the only work-around I know of is to explicitly give classInstance a type.

@bwilkerson Why would adding an implements to TypedBase break this? without the implements it works correctly.

Also, if we have to live with this, can I request a lint rule to remind people to specify a type instead of var when assigning using a ternary?

Also, seems like a bug - if for no other reason - its not consistent.
If you remove the generic parameters from the OverReact example linked above - the type inference is suddenly correct: https://dartpad.dartlang.org/36c92bfa01f3903606b7aa4328b2dfcd
For the sake of posterity:
Analyzer Error:
main() {
  // Analyzer thinks this is `Object`, it should be `AbstractComponent`.
  var classInstance = (someCheck() ? new ComponentA() : new ComponentB());

  classInstance.baseMethod();
}

bool someCheck() {
  return false;
}

class AProps {}
class AState {}

class BProps {}
class BState {}

class ComponentA extends AbstractComponent<AProps, AState> {} // DropdownMenuComponent

class ComponentB extends AbstractComponent<BProps, BState> {} // PopoverMenuComponent

class AbstractComponent<T, S> extends HelperTypedStateful<T, S> {} // AbstractDropdownMenuComponent

class HelperTypedStateful<T, S> extends TypedStatefulBase<T, S> with Mixin {} // transformer_helper.UiStatefulComponent

class HelperTypedBased<T> extends TypedBase<T> with Mixin {} // transformer_helper.UiComponent

class TypedStatefulBase<T, S> extends TypedBase<T> {} // component_base.UiStatefulComponent

class TypedBase<T> extends Base implements Interface {} // component_base.UiComponent

class Base { // react.Component
  baseMethod() {}
}

class Interface {} // Disposable

class Mixin {} // GeneratedClass

Analyzer Clean:
main() {
  // Correctly inferred as `AbstractComponent`
  var classInstance = (someCheck() ? new ComponentA() : new ComponentB());

  classInstance.baseMethod();
}

bool someCheck() {
  return false;
}

class ComponentA extends AbstractComponent {} // DropdownMenuComponent

class ComponentB extends AbstractComponent {} // PopoverMenuComponent

class AbstractComponent extends UiStatefulComponentTransformerHelper {} // AbstractDropdownMenuComponent

class UiStatefulComponentTransformerHelper extends UiStatefulComponent with GeneratedClass {} // transformer_helper.UiStatefulComponent

class UiComponentTransformerHelper extends UiComponent with GeneratedClass {} // transformer_helper.UiComponent

class UiStatefulComponent extends UiComponent {} // component_base.UiStatefulComponent

class UiComponent extends Component implements DisposableManagerV3 {} // component_base.UiComponent

class Component { // react.Component
  baseMethod() {}
}

class DisposableManagerV3 {}

class GeneratedClass {}

@bwilkerson Is this related to https://github.com/dart-lang/sdk/issues/27525?

yes this is #27525 and #25821, LUB does not work as expected in Dart for many types, but especially generic types.

Okay, I'm guessing those improvements are not slotted for the near future? Do they have a rough ETA or a hopeful SDK version?

ah, I'm not sure. @leafpetersen might know the status

As others have said, least upper bound is a disaster in Dart, and it's really hard to fix without substantially changing the language.  The smaller reproduction example above is one of the classic examples: you have a hierarchy that looks like:
A -> Sub1 -> Base, Element -> Object
B -> Sub2 -> Base, Element -> Object

There simply is no least upper bound for this hierarchy, period: neither Base nor Element is least.  Object is very much not least, but at least it is unique, and that's what the Dart LUB definition chooses.
The more complex examples above fall down in other corners of the LUB definition around generics, but it's a similar situation, with the addition that you run into decidability issues (if you try to compute an upper bound recursively, there are examples which loop around to the original query, or worse to an infinitely expanding series of queries).
I would still like to improve on this, but it is unlikely to happen soon.

Also, if we have to live with this, can I request a lint rule to remind people to specify a type instead of var when assigning using a ternary?

I would be very happy to see this.  I would suggest including things like a ?? b and a ??= b in there as well, since I believe both of those (or maybe just the former) also have the same problem.  Could you maybe file a separate issue for this?

I'm going to close this, since issues with LUB are well tracked elsewhere.  Feel free to reopen if you feel that there is something particular to track here.

Thanks for the responses everybody 👍

Some related other issues:
https://github.com/dart-lang/sdk/issues/25368
https://github.com/dart-lang/sdk/issues/25821
https://github.com/dart-lang/sdk/issues/27525

@leafpetersen I filed an issue for the requested lint rule here https://github.com/dart-lang/linter/issues/734

authors: aaronlademann-wf bencampbell-wf bwilkerson jacehensley-wf jmesserly kevmoo leafpetersen robbecker-wf


text:
@coq annotations should be objects, not simple values

An annotation is determined by its value, not its syntax. Consequently, the annotations in coq_annot.dart should be instances of some constant class, not just numbers.

The annotations are only used by the coq.dart transformation, which is able to observe the syntax directly, as evidenced in getCoqAnnot.

Any annotation is used by everyone. It'll be included in the binary representation and visible to transformers and mirrors.

authors: peter-ahe-google sjindel-google


text:
Find a replacement for AstRewriteVisitor in LibraryAnalyzer._resolveFile2

The purpose of the AstRewriteVisitor is to rewrite things that look like method calls into things that look like constructor calls (to support implicit constructor calls).  This visitor relies on resolution results, but we're calling it at a time that we haven't received resolution results yet.  I'm hoping that the visitor can eventually go away completely, because in the final design, the front end will know whether we're looking at a constructor call when it calls the factory, and it will call the appropriate factory method.

Mostly done in https://dart-review.googlesource.com/c/sdk/+/68004
There is still a failing test because of using raw element instead of Member.

https://dart-review.googlesource.com/c/sdk/+/68161 will fix the ConstructorMember problem.


text:
BigInt parsing anomaly

Dart SDK Version  - Dart VM version: 2.0.0 (Fri Aug 3 10:53:23 2018 +0200) on "windows_x64
Using Windows, Linux

When trying BigInt.parse("0x0000000000000000000000000000000000000000000000000000000000000000");
I'm getting 'FormatException: Could not parse BigInt 0x'
Shouldn't this just return BigInt.zero?

It should. It does for me on tip-of-tree. The exception printed should come from
throw new FormatException("Could not parse BigInt", source);

so it should include the entire source, not just the first two characters.
Can you check if there is any way that string could be cut short to only two characters in your code?

Yes your right, its being truncated to '0x', I guess this should fail parsing so no problem here now.

closing based on comment above, if it is still a problem please reopen

authors: a-siva lrhn shamblett


text:
Compiler ignores invalid escape sequences

For example 'z' == '\z' is true, and print('\z') outputs z. It looks like the parser/compiler simply ignores the backslash if it does not recognize the escape sequence. I would have expected this to be a compile time error (like in Java strings, for example).

Dart SDK Version (dart --version): 2.1.0 stable
Whether you are using Windows, MacOSX, or Linux (if applicable): n/a
Whether you are using Chrome, Safari, Firefox, Edge (if applicable): n/a

Thank you! I didn't read far enough.
Some typos were exactly our problem. As this is a minor issue and likely a breaking change, I also don't think it's happening. I'll close this issue then.

I created a WIP pull request there: https://github.com/dart-lang/linter/pull/1295
Thank you!


text:
AOT-DET-DebugX64 error: expected: rep != kNoRepresentation

Isolate (/b/s/w/itQwR8HO/dart_fuzzYFVCMD) FP NO-FFI NO-FLAT : KBC-CMP-ReleaseX64 - AOT-DET-DebugX64: !DIVERGENCE! 1.78:2634029975 (0 vs 134)

fail2:
134

../../runtime/vm/compiler/backend/linearscan.cc: 401: error: expected: rep != kNoRepresentation
version=2.8.0-edge.0bc0531e6c577ad398e1122ba47d6481147866d5 (Thu Dec 12 01:56:25 2019 +0000) on "linux_x64"
thread=23618, isolate=isolate(0x55a7ed511800)
  pc 0x000055a7eaf462cc fp 0x00007ffc56f4cc00 dart::Profiler::DumpStackTrace(void*)
  pc 0x000055a7eacbc142 fp 0x00007ffc56f4cce0 dart::Assert::Fail(char const*, ...)
  pc 0x000055a7eb12c116 fp 0x00007ffc56f4cd20 /b/s/w/ir/pkg/vm/tool/../../../out/DebugX64/gen_snapshot+0xa4f116
  pc 0x000055a7eb12caac fp 0x00007ffc56f4cdc0 dart::FlowGraphAllocator::BuildLiveRanges()
  pc 0x000055a7eb136863 fp 0x00007ffc56f4ce10 dart::FlowGraphAllocator::AllocateRegisters()
  pc 0x000055a7eb17ff17 fp 0x00007ffc56f4d240 /b/s/w/ir/pkg/vm/tool/../../../out/DebugX64/gen_snapshot+0xaa2f17
  pc 0x000055a7eb17e994 fp 0x00007ffc56f4d300 dart::CompilerPass::Run(dart::CompilerPassState*) const
  pc 0x000055a7eb17f05e fp 0x00007ffc56f4d330 dart::CompilerPass::RunPipeline(dart::CompilerPass::PipelineMode, dart::CompilerPassState*)
  pc 0x000055a7eb03081f fp 0x00007ffc56f4d990 dart::PrecompileParsedFunctionHelper::Compile(dart::CompilationPipeline*)
  pc 0x000055a7eb032f6f fp 0x00007ffc56f4dba0 /b/s/w/ir/pkg/vm/tool/../../../out/DebugX64/gen_snapshot+0x955f6f
  pc 0x000055a7eb02d684 fp 0x00007ffc56f4dc50 dart::Precompiler::CompileFunction(dart::Precompiler*, dart::Thread*, dart::Zone*, dart::Function const&)
  pc 0x000055a7eb02bf1b fp 0x00007ffc56f4dcc0 dart::Precompiler::ProcessFunction(dart::Function const&)
  pc 0x000055a7eb027873 fp 0x00007ffc56f4dce0 dart::Precompiler::Iterate()
  pc 0x000055a7eb0249ac fp 0x00007ffc56f4dea0 dart::Precompiler::DoCompileAll()
  pc 0x000055a7eb024365 fp 0x00007ffc56f4e290 dart::Precompiler::CompileAll()
  pc 0x000055a7eb4aa03e fp 0x00007ffc56f4e350 Dart_Precompile
  pc 0x000055a7eac91a0a fp 0x00007ffc56f4e4d0 dart::bin::main(int, char**)
-- End of DumpStackTrace
/b/s/w/ir/pkg/vm/tool/precompiler2: line 115: 23618 Aborted                 "$BIN_DIR"/gen_snapshot "$GEN_SNAPSHOT_OPTION" "$GEN_SNAPSHOT_FILENAME" "${OPTIONS[@]}" "$SNAPSHOT_FILE.dill"

-- BEGIN REPRODUCE  --

dartfuzz.dart --fp --no-ffi --no-flat --seed 2634029975 /b/s/w/itQwR8HO/dart_fuzzYFVCMD/fuzz.dart

-- RUN 1 --

/b/s/w/ir/pkg/vm/tool/gen_kernel --gen-bytecode --platform=/b/s/w/ir/out/ReleaseX64/vm_platform_strong.dill -o /b/s/w/itQwR8HO/dart_fuzzYFVCMD/out.dill /b/s/w/itQwR8HO/dart_fuzzYFVCMD/fuzz.dart
/b/s/w/ir/out/ReleaseX64/dart --use-bytecode-compiler --old_gen_heap_size=128 /b/s/w/itQwR8HO/dart_fuzzYFVCMD/out.dill

-- RUN 2 --

DART_CONFIGURATION='DebugX64' DART_VM_FLAGS='--enable-asserts' /b/s/w/ir/pkg/vm/tool/precompiler2 --deterministic /b/s/w/itQwR8HO/dart_fuzzYFVCMD/fuzz.dart /b/s/w/itQwR8HO/dart_fuzzYFVCMD/snapshot
/b/s/w/ir/pkg/vm/tool/dart_precompiled_runtime2 /b/s/w/itQwR8HO/dart_fuzzYFVCMD/snapshot

-- END REPRODUCE  --

Reduced 2634029975 to the following code snippet

import 'dart:typed_data';

Uint32List var7 = Uint32List(40);
Float64x2List var14 = Float64x2List(13);
int var21 = -76;
List<bool> var24 = [false, false, true];
List<double> var25 = List<double>.filled(8, 0);
Map<int, int> var42 = {
  14 : -98
};
Map<Map<bool, bool>, double> var62 = {
};

double foo0(){
    int loc0 = 0;
    do {
      throw var62;
    } while (false);
}

main() {
      int loc0 = 0;
      do {
        switch ((var24[null] ? (DateTime.daysPerWeek as int) : (-(((10 << (var21--)) >> (Int32x4.xyzx as int)))))){
          case 2820262524: {
            break;
          }
          case 2820262533: {
            {
                var25[7] = foo0();
            }

            break;
          }
          default: {
            var14[0] = var14[var7[var42[4]]] + Float64x2.zero();
            break;
          }
        }
      } while (++loc0 < 13);
}

Further reduced 2634029975 to:
List<double> var25 = List<double>.filled(8, 0);

double foo0(){
    do {
      throw {};
    } while (false);
}

main() {
      do {
        switch (1){
          case 1: {
                var25[7] = foo0();
          }
        }
      } while (false);
}

which throws the following error:
../../runtime/vm/compiler/backend/flow_graph_checker.cc: 325: error: expected: def->next() != nullptr
version=2.8.0-edge.5543e5ceb8cc6806d12d9b2534365337fc30f817 (Thu Dec 12 18:38:50 2019 +0000) on "linux_x64"
thread=252809, isolate=isolate(0x5608450df800)
  pc 0x0000560842c624ac fp 0x00007ffcacacc410 dart::Profiler::DumpStackTrace(void*)
  pc 0x00005608429d43b2 fp 0x00007ffcacacc4f0 dart::Assert::Fail(char const*, ...)
  pc 0x0000560842dab2e6 fp 0x00007ffcacacc540 dart::FlowGraphChecker::VisitUseDef(dart::Instruction*, dart::Value*, long, bool)
  pc 0x0000560842daaebe fp 0x00007ffcacacc5a0 dart::FlowGraphChecker::VisitInstruction(dart::Instruction*)
  pc 0x0000560842daaaf5 fp 0x00007ffcacacc610 dart::FlowGraphChecker::VisitInstructions(dart::BlockEntryInstr*)
  pc 0x0000560842daa50c fp 0x00007ffcacacc690 dart::FlowGraphChecker::VisitBlocks()
  pc 0x0000560842e999dd fp 0x00007ffcacacc750 dart::CompilerPass::Run(dart::CompilerPassState*) const
  pc 0x0000560842e99f77 fp 0x00007ffcacacc780 dart::CompilerPass::RunPipeline(dart::CompilerPass::PipelineMode, dart::CompilerPassState*)
  pc 0x0000560842d4ca8f fp 0x00007ffcacaccde0 dart::PrecompileParsedFunctionHelper::Compile(dart::CompilationPipeline*)
  pc 0x0000560842d4f1df fp 0x00007ffcacaccff0 /usr/local/google/home/fizaaluthra/dart-sdk/sdk/pkg/vm/tool/../../../out/DebugX64/gen_snapshot+0x98b1df
  pc 0x0000560842d498f4 fp 0x00007ffcacacd0a0 dart::Precompiler::CompileFunction(dart::Precompiler*, dart::Thread*, dart::Zone*, dart::Function const&)
  pc 0x0000560842d4818b fp 0x00007ffcacacd110 dart::Precompiler::ProcessFunction(dart::Function const&)
  pc 0x0000560842d43ae3 fp 0x00007ffcacacd130 dart::Precompiler::Iterate()
  pc 0x0000560842d40c1c fp 0x00007ffcacacd2f0 dart::Precompiler::DoCompileAll()
  pc 0x0000560842d40555 fp 0x00007ffcacacd6e0 dart::Precompiler::CompileAll()
  pc 0x00005608431c502e fp 0x00007ffcacacd7a0 Dart_Precompile
  pc 0x00005608429a9a5f fp 0x00007ffcacacd920 dart::bin::main(int, char**)
-- End of DumpStackTrace

cc @bkonyi

Working from the reduced test case, moving the checker call to after the post-pass print, and adding a print of the definition index before the assert:
*** BEGIN CFG
After EliminateDeadPhis
==== file:///usr/local/google/home/sstrickl/tmp/fuzz.dart_::_main
B0[graph]:0 {
      v0 <- Constant(#null) T{Null?}
      v1 <- Constant(#<optimized out>) T{_OneByteString}
      v2 <- Constant(#1) [1, 1] T{_Smi}
      v5 <- Constant(#true) T{bool}
      v6 <- Constant(#false) T{bool}
      v9 <- Constant(#7) [7, 7] T{_Smi}
      v19 <- Constant(#Field <::.var25>: static) T{Field}
      v25 <- Constant(#_ImmutableList len:0) T{_ImmutableList}
}
B10[function entry]:2
    CheckStackOverflow:8(stack=0, loop=0)
    CheckStackOverflow:42(stack=0, loop=1)
    InitStaticField:4(v19)
  0:     v17 <- LoadStaticField(v19) T{List<double>?}
    PushArgument(v17 T{List<double>?})
    PushArgument(v9)
    PushArgument(v0)
    PushArgument(v25)
    v23 <- StaticCall:12( Map._fromLiteral@0150898<0> v0, v25) T{*?}
    PushArgument(v23)
    Throw:14()
*** END CFG
*** BEGIN CFG
After DCE
==== file:///usr/local/google/home/sstrickl/tmp/fuzz.dart_::_main
B0[graph]:0 {
      v0 <- Constant(#null) T{Null?}
      v1 <- Constant(#<optimized out>) T{_OneByteString}
      v2 <- Constant(#1) [1, 1] T{_Smi}
      v5 <- Constant(#true) T{bool}
      v6 <- Constant(#false) T{bool}
      v9 <- Constant(#7) [7, 7] T{_Smi}
      v19 <- Constant(#Field <::.var25>: static) T{Field}
      v25 <- Constant(#_ImmutableList len:0) T{_ImmutableList}
}
B10[function entry]:2
    CheckStackOverflow:8(stack=0, loop=0)
    CheckStackOverflow:42(stack=0, loop=1)
    InitStaticField:4(v19)
    PushArgument(v17 T{List<double>?})
    PushArgument(v9)
    PushArgument(v0)
    PushArgument(v25)
    v23 <- StaticCall:12( Map._fromLiteral@0150898<0> v0, v25) T{*?}
    PushArgument(v23)
    Throw:14()
*** END CFG
Definition 17 is not linked into the graph.
../../runtime/vm/compiler/backend/flow_graph_checker.cc: 329: error: expected: def->next() != nullptr
version=2.8.0-edge.6e9d4ea535e25dbdd2a7d9d31e02523ee770b11c (Fri Dec 13 11:16:59 2019 +0100) on "linux_x64"
thread=212526, isolate=isolate(0x562e71d4b800)
...

So we have a push argument whose definition was eliminated as dead code (but there's a push argument that still uses it). The non-push argument use was eliminated in constant propagation:
*** BEGIN CFG
After Canonicalize
==== file:///usr/local/google/home/sstrickl/tmp/fuzz.dart_::_main
B0[graph]:0 {
      v0 <- Constant(#null) T{Null?}
      v1 <- Constant(#<optimized out>)
      v2 <- Constant(#1) T{_Smi}
      v5 <- Constant(#true) T{bool}
      v6 <- Constant(#false) T{bool}
      v9 <- Constant(#7) T{_Smi}
      v19 <- Constant(#Field <::.var25>: static) T{Field}
      v25 <- Constant(#_ImmutableList len:0) T{_ImmutableList}
}
B1[function entry]:2
    CheckStackOverflow:8(stack=0, loop=0)
    goto:48 B6
B6[join]:40 pred(B1, B7)
    CheckStackOverflow:42(stack=0, loop=1)
    v3 <- EqualityCompare(v2 == v2) T{bool}
    Branch if StrictCompare:20(===, v3, v5) goto (3, 4)
B3[target]:24
    InitStaticField:4(v19)
    v17 <- LoadStaticField(v19) T{List<double>?}
    PushArgument(v17 T{List<double>?})
    PushArgument(v9)
    Branch if StrictCompare:14(===, v5, v5) goto (10, 12)
B10[target]:2
    PushArgument(v0)
    PushArgument(v25)
    v23 <- StaticCall:12( Map._fromLiteral@0150898<0> v0, v25) T{*?}
    PushArgument(v23)
    Throw:14()
B12[target]:15
    PushArgument(v0)
    InstanceCall:16( []=<0>, v17 T{List<double>?}, v9, v0 IC[0: ])
    goto:32 B5
B4[target]:26
    goto:30 B5
B5[join]:28 pred(B4, B12)
    Branch if StrictCompare:36(===, v6, v5) goto (7, 8)
B7[target]:44
    goto:46 B6
B8[target]:50
    Return:54(v0)
*** END CFG
*** BEGIN CFG
After ConstantPropagation
==== file:///usr/local/google/home/sstrickl/tmp/fuzz.dart_::_main
B0[graph]:0 {
      v0 <- Constant(#null) T{Null?}
      v1 <- Constant(#<optimized out>)
      v2 <- Constant(#1) T{_Smi}
      v5 <- Constant(#true) T{bool}
      v6 <- Constant(#false) T{bool}
      v9 <- Constant(#7) T{_Smi}
      v19 <- Constant(#Field <::.var25>: static) T{Field}
      v25 <- Constant(#_ImmutableList len:0) T{_ImmutableList}
}
B10[function entry]:2
    CheckStackOverflow:8(stack=0, loop=0)
    CheckStackOverflow:42(stack=0, loop=1)
    InitStaticField:4(v19)
    v17 <- LoadStaticField(v19) T{List<double>?}
    PushArgument(v17 T{List<double>?})
    PushArgument(v9)
    PushArgument(v0)
    PushArgument(v25)
    v23 <- StaticCall:12( Map._fromLiteral@0150898<0> v0, v25) T{*?}
    PushArgument(v23)
    Throw:14()
*** END CFG

So foo gets simplified to throw {} and inlined, and main gets optimized from do { switch(1) { case 1: var25[7] = foo(); } } while (false); => var25[7] = throw {}; => throw {};, but when the basic block including the InstanceCall([]=<0>, ...) gets dropped because it cannot be reached, arguments for that call pushed in previous, still-remaining blocks (v17 and v9) don't get removed.

... and I'm 100% certain (though I forgot to turn on environmental printing above) that it's because these push arguments are in the environment of the throw, so they can't be removed (at least without replacing them appropriately).
... but we have an EliminateEnvironments pass before DCE, so that shouldn't be causing them to stick around. Hmm.

Ah, right. The problem is that the only use of v17 is in the PushArgument, which still existed due to its environmental use after its corresponding InstanceCall was eliminated. Then environments were eliminated, so the PushArgument was no longer live, so to speak. When DCE ran, it didn't see any live uses of v17, so it eliminated the definition, but it skips PushArguments and so didn't remove the (now dead) PushArgument use, and then the checker complained.

Given that, I see two possible solutions:

When removing environments, remove push args if the environmental use is the only remaining use of the push argument.
In DCE, don't skip all PushArguments: if they refer to non-live definitions, then remove them.

/cc @alexmarkov

The code is arguably wrong - I think PushArgument should not stay in the graph if it has no corresponding call. If environment refers to it - then environment needs to be fixed to instead refer to the value itself.

Yeah, I think it's similar to the kind of issues we saw in dart-lang/sdk#38354. It's a little annoying because there's no way to check whether a PushArgument has non-environmental uses, because they aren't normal instruction inputs, but rather passed in PushArgumentArrays, and so only their environmental uses are recorded.
We could add code to the TemplateDartCall constructor which adds input uses to push arguments. We'd also need to check how/when to remove those input uses (when the call is removed from the graph for sure, but perhaps we also alter the PushArgumentArray to add/remove arguments in other situations?). Or just make PushArgumentsArray an actual subclass instead of a typedef on ZoneGrowableArray and have its method overrides also do the use manipulation.
With that, we could find such orphaned push arguments when traversing environments.
A quicker fix for now, though, would be my second suggestion above: just remove PushArguments of non-live definitions in the DeadCodeEliminator. I've already code ready to be reviewed which does this, and then we can just remove that patch when we do the more extensive fix.

Actually, even better is just replacing all PushArgumentArray elements when removing a call instruction with their definition in all environmental uses. If that doesn't change anything semantically (and it shouldn't, since each PA should only be a member of one call's PAA), then that should just solve the issue for cases like this. Will look at doing that quickly, and if it's not quick I'll put the other change up for review instead.

Well, we can't just do that in RemoveFromGraph, because that's also used for reinserting instructions (by removal and insertion), and so we can't know whether the arguments should be considered dead yet. So for now, the quick fix as a CL, then more thought about this later.

Extending DCE to remove these dangling PushArgument instructions lgtm. As a more permanent solution, I'm going to try to remove PushArgument instructions from IL (https://github.com/dart-lang/sdk/issues/39788).

authors: alexmarkov fizaaluthra mraleph sstrickl


text:
unchecked_use_of_nullable_value for a checked nullable callback

When analyzing the following file with NNBD enabled:
int Function()? foo;

int callFoo() => foo != null ? foo() : 0;

I get the following error:
  error • An expression whose value can be 'null' must be null-checked before it can be dereferenced. • test.dart:3:32 • unchecked_use_of_nullable_value

This error seems bogus, since we are specifically are checking foo != null. Note that doing the check in an if statement also exhibits this error.
Tested with 2.12.0-110.0.dev.

Above, foo is a field; unfortunately, those don't type promote. There's a discussion of that here: https://github.com/dart-lang/sdk/issues/35525.
cc @leafpetersen @stereotype441 wrt improving the diagnostics we provide in these cases.


text:
Failures on [cfe] Update the conversion algorithm for checking super-bounded types

I'm working on an update for the instantiate-to-bound algorithm for NNBD, which is specified here.  Doing so, I discovered some co19 tests that I think should be updated.
/cc @eernstg

List of discovered tests (click to expand)
[encoded data, 5007 characters]

Sorry, wrong repository.  Moved it here: https://github.com/dart-lang/co19/issues/979

Sorry, wrong repository.  Moved it here: https://github.com/dart-lang/co19/issues/979


text:
Customer-reported issue with NNBD migration tool: Failed to rerun migration

Failed to rerun migration
Error: Instance of 'MigrationExit'
Please fill in the following:
**Name of package being migrated (if public): private - my our code
What I was doing when this issue occurred: Click the "Rerun with changes" button
Is it possible to work around this issue: Not every time I try, I get this error
Has this issue happened before, and if so, how often: At one point started happening and since then I always get it
Dart SDK version: 2.13.4
Additional details: N/A
Thanks for filing!
Stacktrace: auto populated by migration preview tool.
#0      MigrationCliRunner.onException (package:nnbd_migration/migration_cli.dart:635:9)
#1      NullabilityMigrationAdapter.reportException (package:nnbd_migration/src/front_end/non_nullable_fix.dart:550:21)
#2      PermissiveModeVisitor.reportExceptionsIfPermissive (package:nnbd_migration/src/utilities/permissive_mode.dart:28:18)
#3      CompletenessTracker.visitCompilationUnit (package:nnbd_migration/src/utilities/completeness_tracker.dart:43:5)
#4      CompilationUnitImpl.accept (package:analyzer/src/dart/ast/ast.dart:2105:50)
#5      NullabilityMigrationImpl.processInput (package:nnbd_migration/src/nullability_migration_impl.dart:244:12)
#6      NonNullableFix.processUnit (package:nnbd_migration/src/front_end/non_nullable_fix.dart:164:15)
#7      _FixCodeProcessor.runLaterPhases.<anonymous closure> (package:nnbd_migration/migration_cli.dart:1152:19)
#8      _FixCodeProcessor.runLaterPhases.<anonymous closure> (package:nnbd_migration/migration_cli.dart:1150:28)
#9      _FixCodeProcessor.processResources (package:nnbd_migration/migration_cli.dart:1079:30)
<asynchronous suspension>
#10     _FixCodeProcessor.runLaterPhases (package:nnbd_migration/migration_cli.dart:1150:5)
<asynchronous suspension>
#11     MigrationCliRunner._rerunFunction (package:nnbd_migration/migration_cli.dart:975:14)
<asynchronous suspension>
#12     NonNullableFix.rerun (package:nnbd_migration/src/front_end/non_nullable_fix.dart:169:17)
<asynchronous suspension>
#13     PreviewSite.rerunMigration (package:nnbd_migration/src/preview/preview_site.dart:605:22)
<asynchronous suspension>
#14     PreviewSite.handlePostRequest (package:nnbd_migration/src/preview/preview_site.dart:454:9)
<asynchronous suspension>
#15     HttpPreviewServer._handlePostRequest (package:nnbd_migration/src/preview/http_preview_server.dart:109:5)
<asynchronous suspension>
#16     HttpPreviewServer._handleServer.<anonymous closure> (package:nnbd_migration/src/preview/http_preview_server.dart:119:9)
<asynchronous suspension>

As of 1c7fe7196dd7a542f7f91cd6ea2ac81e1a13146c, the null safety migration tool has been removed from active development and retired. No further work on the tool is planned.
If you still need help, or you believe this issue has been closed in error, please feel free to reopen.


text:
[CP] Fixes for enhanced enum and switch.

Commit(s) to merge
https://dart-review.googlesource.com/c/sdk/+/247332
Target
stable
Issue Description
In implementation of enhanced enums in the analyzer two places should be fixed:

Support for SimpleIdentifier in exhaustiveness checking in switch statements, which were not possible before, but possible now inside the enum itself.
Another switch related hint where an approximation for accessing enum constants was used (static const), but which does not work correctly for enhanced enums because there are non-enum-constant constants possible now.

What is the fix
The CL makes small fixes in the analyzer.
Why cherry-pick
Well, this causes issues for users.
Risk
low
Issue link(s)
https://github.com/dart-lang/sdk/issues/49188
Extra Info
No response

@vsmenon @athomas This is a relatively small change with mostly updates to tests, this seems like a low risk cherry pick.  Do you have an opinion on this?

Based on the low risk and complexity of this cherry-pick, I am going to mark it as approved.

This has been landed in 2.17.4.  2.17.5, with no additional changes, will be published.

authors: itsjustkevin scheglov whesse


text:
StackOverflowError in Parser

StackOverflowError: Stack Overflow
at Parser.parseExpression(parser_impl.dart:5172)
at Parser.parseArgumentsRest(parser_impl.dart:6779)
at Parser.parseSend(parser_impl.dart:6716)
at Parser.parseSendOrFunctionLiteral(parser_impl.dart:6265)
at Parser.parsePrimary(parser_impl.dart:5811)
at Parser._parsePrecedenceExpressionLoop(parser_impl.dart:5340)
at Parser.parsePrecedenceExpression(parser_impl.dart:5277)
at Parser.parseExpression(parser_impl.dart:5200)
at Parser.parseSingleLiteralString(parser_impl.dart:6592)
at Parser.parseLiteralString(parser_impl.dart:6537)
at Parser.parsePrimary(parser_impl.dart:5817)
at Parser.parseUnaryExpression(parser_impl.dart:5711)
at Parser.parsePrecedenceExpression(parser_impl.dart:5259)
at Parser.parseExpression(parser_impl.dart:5200)
at Parser.parseExpressionFunctionBody(parser_impl.dart:4876)
at Parser.parseFunctionBody(parser_impl.dart:4803)
at Parser.parseFunctionExpression(parser_impl.dart:4609)
at Parser.parseParenthesizedExpressionOrFunctionLiteral(parser_impl.dart:5883)
at Parser.parsePrimary(parser_impl.dart:5855)
at Parser.parseUnaryExpression(parser_impl.dart:5711)
at Parser.parsePrecedenceExpression(parser_impl.dart:5259)
at Parser._parsePrecedenceExpressionLoop(parser_impl.dart:5321)
at Parser.parsePrecedenceExpression(parser_impl.dart:5277)
at Parser.parseExpression(parser_impl.dart:5200)
at Parser.parseExpressionStatementOrDeclarationAfterModifiers(parser_impl.dart:7140)
at Parser.parseStatementX(parser_impl.dart:4961)
at Parser.parseBlock(parser_impl.dart:7533)
at Parser.parseStatementX(parser_impl.dart:4972)
at Parser.parseIfStatement(parser_impl.dart:7231)
at Parser.parseStatementX(parser_impl.dart:4988)
at Parser.parseBlock(parser_impl.dart:7533)
at Parser.parseTryStatement(parser_impl.dart:7726)
at Parser.parseStatementX(parser_impl.dart:5001)
at Parser.parseFunctionBody(parser_impl.dart:4856)
at Parser.parseMethod(parser_impl.dart:4364)
at Parser.parseClassOrMixinOrExtensionOrEnumMemberImpl(parser_impl.dart:4162)
at Parser.parseClassOrMixinOrExtensionBody(parser_impl.dart:3807)
at Parser.parseMixin(parser_impl.dart:2461)
at Parser.parseTopLevelKeywordDeclaration(parser_impl.dart:609)
at Parser.parseTopLevelDeclarationImpl(parser_impl.dart:497)
at Parser.parseUnit(parser_impl.dart:377)
at FileState.parse2(file_state.dart:502)
at FileState.parse(file_state.dart:468)
at FileState._getUnlinkedUnit(file_state.dart:631)
at ...(.)
at ...(.)
at LibraryFileStateKind.files(file_state.dart:1632)
at _LibraryWalker.evaluateScc(library_graph.dart:206)
at DependencyWalker.walk.strongConnect(dependency_walker.dart:115)
at DependencyWalker.walk.strongConnect(dependency_walker.dart:68)
at DependencyWalker.walk.strongConnect(dependency_walker.dart:68)
at DependencyWalker.walk.strongConnect(dependency_walker.dart:68)
at DependencyWalker.walk.strongConnect(dependency_walker.dart:68)
at DependencyWalker.walk.strongConnect(dependency_walker.dart:68)
at DependencyWalker.walk.strongConnect(dependency_walker.dart:68)
at DependencyWalker.walk.strongConnect(dependency_walker.dart:68)
at DependencyWalker.walk(dependency_walker.dart:121)
at computeLibraryCycle(library_graph.dart:17)
at LibraryFileStateKind.libraryCycle(file_state.dart:1655)
at AnalysisDriver._getResolvedUnitSignature(driver.dart:1635)
at AnalysisDriver._computeAnalysisResult(driver.dart:1292)
at AnalysisDriver.performWork(driver.dart:1145)
at AnalysisDriverScheduler._run(driver.dart:2109)

Ah, actually it looks an analyzer issue.


text:
Migration tool unnecessarily adds dynamic to some closure parameters

Given this already migrated code:
abstract class C {
  void m<T>(void Function(T) callback);
}

And this code to be migrated:
foo(C c) {
  c.m((_) {});
}

The migration tool produces:
foo(C c) {
  c.m((dynamic _) {});
}

The reason this is happening is because prior to migration, the inferred type of the parameter _ was dynamic, and after migration, the inferred type is Object?.  The migration tool is inserting the explicit type to preserve behavior.  However, in this case, since the parameter isn't used, it's just unnecessary visual clutter.
In other situations, the parameter is used, but it's used in a way that doesn't rely on dynamic dispatch, for example, assuming the same already migrated code, this input:
foo(C c) {
  c.m((x) {
    if (x is String) {
      print(x.length);
    }
  });
}

gets transformed into:
foo(C c) {
  c.m((dynamic x) {
    if (x is String) {
      print(x.length);
    }
  });
}

It would be nice if the tool would only add the type dynamic when it's truly needed.

Possibly related: https://github.com/dart-lang/site-www/issues/4192

As of 1c7fe7196dd7a542f7f91cd6ea2ac81e1a13146c, the null safety migration tool has been removed from active development and retired. No further work on the tool is planned.
If you still need help, or you believe this issue has been closed in error, please feel free to reopen.


text:
Mo completion for the type name in wildcard pattern, in switch

void f(Object? x) {
  switch (x) {
    case StrB^ _:
      break;
  }
}

https://dart-review.googlesource.com/c/sdk/+/365284