text:
Some MQTT input topics don't get published

I've set up lxp-bridge for the Luxpower Eco-Hybrid SNA5000 inverter. I had to use the dev tag since the latest version (v0.8.0) seems to crash.
It works for the most part, however it only publishes the messages on the .../inputs/all topic, while .../inputs/{1,2,3} are missing. I noticed it through the Home Assistant integration, which received the discovery configurations, but never the actual values. As I understand the configs point to those missing inputs topics.
There are also frequent  ignoring unhandled ReadInput log lines like this:
2022-09-27T10:55:53.867 DEBUG lxp_bridge::lxp::packet_decoder] 19 bytes in: [161, 26, 5, 0, 13, 0, 1, 193, 66, 65, 49, 50, 49, 51, 48, 48, 50, 51, 0]
[2022-09-27T10:55:53.867 DEBUG lxp_bridge::coordinator] RX: Heartbeat(Heartbeat { datalog: redacted })
[2022-09-27T10:55:55.071 DEBUG lxp_bridge::lxp::packet_decoder] 291 bytes in: [161, 26, 5, 0, 29, 1, 1, 194, 66, 65, 49, 50, 49, 51, 48, 48, 50, 51, 15, 1, 1, 4, 50, 50, 55, 51, 48, 53, 48, 50, 51, 51, 0, 0, 254, 20, 0, 4, 9, 54, 7, 92, 16, 15, 2, 100, 0, 0, 0, 99, 0, 54, 0, 0, 0, 0, 0, 0, 0, 30, 9, 0, 0, 0, 0, 142, 19, 95, 0, 0, 0, 210, 0, 0, 0, 44, 9, 212, 1, 193, 124, 141, 19, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 4, 0, 0, 0, 5, 0, 4, 0, 1, 0, 1, 0, 0, 0, 0, 0, 12, 0, 100, 16, 101, 14, 6, 0, 0, 0, 5, 0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 40, 0, 0, 0, 35, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 56, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 41, 0, 33, 0, 50, 0, 41, 0, 0, 0, 209, 52, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 76, 29, 20, 2, 0, 0, 0, 0, 1, 8, 0, 5, 16, 20, 247, 42, 112, 50, 191, 171, 14, 3, 240, 96, 253, 28, 2, 0, 3, 0, 150, 0, 0, 0, 0, 0, 14, 2, 195, 13, 166, 13, 210, 0, 200, 0, 215, 52, 0, 0, 15, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 1, 0, 0, 50, 50, 55, 51, 48, 53, 48, 50, 51, 51, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 253, 98]
[2022-09-27T10:55:55.071 DEBUG lxp_bridge::coordinator] RX: TranslatedData(TranslatedData { datalog: redacted, device_function: ReadInput, inverter: redacted, register: 0, values: [20, 0, 4, 9, 54, 7, 92, 16, 15, 2, 100, 0, 0, 0, 99, 0, 54, 0, 0, 0, 0, 0, 0, 0, 30, 9, 0, 0, 0, 0, 142, 19, 95, 0, 0, 0, 210, 0, 0, 0, 44, 9, 212, 1, 193, 124, 141, 19, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 4, 0, 0, 0, 5, 0, 4, 0, 1, 0, 1, 0, 0, 0, 0, 0, 12, 0, 100, 16, 101, 14, 6, 0, 0, 0, 5, 0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 40, 0, 0, 0, 35, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 56, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 41, 0, 33, 0, 50, 0, 41, 0, 0, 0, 209, 52, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 76, 29, 20, 2, 0, 0, 0, 0, 1, 8, 0, 5, 16, 20, 247, 42, 112, 50, 191, 171, 14, 3, 240, 96, 253, 28, 2, 0, 3, 0, 150, 0, 0, 0, 0, 0, 14, 2, 195, 13, 166, 13, 210, 0, 200, 0, 215, 52, 0, 0, 15, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 1, 0, 0, 50, 50, 55, 51, 48, 53, 48, 50, 51, 51, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] })
[2022-09-27T10:55:55.071 DEBUG lxp_bridge::mqtt] publishing: lxp/redacted/inputs/all = {"status":20,"v_pv":834.2,"v_pv_1":230.8,"v_pv_2":184.6,"v_pv_3":418.8,"v_bat":52.7,"soc":100,"soh":0,"p_pv":153,"p_pv_1":99,"p_pv_2":54,"p_pv_3":0,"p_charge":0,"p_discharge":0,"v_ac_r":233.4,"v_ac_s":0.0,"v_ac_t":0.0,"f_ac":50.06,"p_inv":95,"p_rec":0,"pf":0.0,"v_eps_r":234.8,"v_eps_s":46.8,"v_eps_t":3193.7,"f_eps":50.05,"p_eps":0,"s_eps":0,"p_to_grid":0,"p_to_user":0,"e_pv_day":0.8,"e_pv_day_1":0.4,"e_pv_day_2":0.4,"e_pv_day_3":0.0,"e_inv_day":0.5,"e_rec_day":0.4,"e_chg_day":0.1,"e_dischg_day":0.1,"e_eps_day":0.0,"e_to_grid_day":0.0,"e_to_user_day":1.2,"v_bus_1":419.6,"v_bus_2":368.5,"e_pv_all":1.1,"e_pv_all_1":0.6,"e_pv_all_2":0.5,"e_pv_all_3":0.0,"e_inv_all":0.5,"e_rec_all":4.0,"e_chg_all":3.5,"e_dischg_all":0.2,"e_eps_all":0.0,"e_to_grid_all":0.0,"e_to_user_all":5.6,"t_inner":41,"t_rad_1":33,"t_rad_2":50,"t_bat":41,"runtime":79057,"max_chg_curr":0.0,"max_dischg_curr":75.0,"charge_volt_ref":53.2,"dischg_cut_volt":0.0,"bat_status_0":0,"bat_status_1":2049,"bat_status_2":1280,"bat_status_3":5136,"bat_status_4":10999,"bat_status_5":12912,"bat_status_6":43967,"bat_status_7":782,"bat_status_8":24816,"bat_status_9":7421,"bat_status_inv":2,"bat_count":3,"bat_capacity":150,"bat_current":0.0,"bms_event_1":0,"bms_event_2":526,"max_cell_voltage":35.23,"min_cell_voltage":34.94,"max_cell_temp":2.1,"min_cell_temp":2.0,"bms_fw_update_state":13527,"cycle_count":0,"vbat_inv":52.7,"time":1664276155,"datalog":"redacted"}
[2022-09-27T10:55:55.071 DEBUG rumqttc::state] Publish. Topic = lxp/redacted/inputs/all, Pkid = 78, Payload Size = 1429
[2022-09-27T10:55:56.252 DEBUG lxp_bridge::lxp::packet_decoder] 291 bytes in: [161, 26, 5, 0, 29, 1, 1, 194, 66, 65, 49, 50, 49, 51, 48, 48, 50, 51, 15, 1, 1, 4, 50, 50, 55, 51, 48, 53, 48, 50, 51, 51, 127, 0, 254, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 133, 25]
[2022-09-27T10:55:56.252 DEBUG lxp_bridge::coordinator] RX: TranslatedData(TranslatedData { datalog: redacted, device_function: ReadInput, inverter: redacted, register: 127, values: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] })
[2022-09-27T10:55:56.253 WARN lxp_bridge::coordinator] ignoring unhandled ReadInput register=127 len=254
[2022-09-27T10:55:56.253 WARN lxp_bridge::mqtt] ignoring unhandled ReadInput register=127 len=254
[2022-09-27T10:55:57.432 DEBUG lxp_bridge::lxp::packet_decoder] 291 bytes in: [161, 26, 5, 0, 29, 1, 1, 194, 66, 65, 49, 50, 49, 51, 48, 48, 50, 51, 15, 1, 1, 4, 50, 50, 55, 51, 48, 53, 48, 50, 51, 51, 254, 0, 254, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 217, 87]
[2022-09-27T10:55:57.433 DEBUG lxp_bridge::coordinator] RX: TranslatedData(TranslatedData { datalog: redacted, device_function: ReadInput, inverter: redacted, register: 254, values: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] })
[2022-09-27T10:55:57.433 WARN lxp_bridge::coordinator] ignoring unhandled ReadInput register=254 len=254
[2022-09-27T10:55:57.433 WARN lxp_bridge::mqtt] ignoring unhandled ReadInput register=254 len=254

I've set up lxp-bridge for the Luxpower Eco-Hybrid SNA5000 inverter. I had to use the dev tag since the latest version (v0.8.0) seems to crash.
It works for the most part, however it only publishes the messages on the .../inputs/all topic, while .../inputs/{1,2,3} are missing. I noticed it through the Home Assistant integration, which received the discovery configurations, but never the actual values. As I understand the configs point to those missing inputs topics.
There are also frequent  ignoring unhandled ReadInput log lines like this:
2022-09-27T10:55:53.867 DEBUG lxp_bridge::lxp::packet_decoder] 19 bytes in: [161, 26, 5, 0, 13, 0, 1, 193, 66, 65, 49, 50, 49, 51, 48, 48, 50, 51, 0]
[2022-09-27T10:55:53.867 DEBUG lxp_bridge::coordinator] RX: Heartbeat(Heartbeat { datalog: redacted })
[2022-09-27T10:55:55.071 DEBUG lxp_bridge::lxp::packet_decoder] 291 bytes in: [161, 26, 5, 0, 29, 1, 1, 194, 66, 65, 49, 50, 49, 51, 48, 48, 50, 51, 15, 1, 1, 4, 50, 50, 55, 51, 48, 53, 48, 50, 51, 51, 0, 0, 254, 20, 0, 4, 9, 54, 7, 92, 16, 15, 2, 100, 0, 0, 0, 99, 0, 54, 0, 0, 0, 0, 0, 0, 0, 30, 9, 0, 0, 0, 0, 142, 19, 95, 0, 0, 0, 210, 0, 0, 0, 44, 9, 212, 1, 193, 124, 141, 19, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 4, 0, 0, 0, 5, 0, 4, 0, 1, 0, 1, 0, 0, 0, 0, 0, 12, 0, 100, 16, 101, 14, 6, 0, 0, 0, 5, 0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 40, 0, 0, 0, 35, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 56, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 41, 0, 33, 0, 50, 0, 41, 0, 0, 0, 209, 52, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 76, 29, 20, 2, 0, 0, 0, 0, 1, 8, 0, 5, 16, 20, 247, 42, 112, 50, 191, 171, 14, 3, 240, 96, 253, 28, 2, 0, 3, 0, 150, 0, 0, 0, 0, 0, 14, 2, 195, 13, 166, 13, 210, 0, 200, 0, 215, 52, 0, 0, 15, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 1, 0, 0, 50, 50, 55, 51, 48, 53, 48, 50, 51, 51, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 253, 98]
[2022-09-27T10:55:55.071 DEBUG lxp_bridge::coordinator] RX: TranslatedData(TranslatedData { datalog: redacted, device_function: ReadInput, inverter: redacted, register: 0, values: [20, 0, 4, 9, 54, 7, 92, 16, 15, 2, 100, 0, 0, 0, 99, 0, 54, 0, 0, 0, 0, 0, 0, 0, 30, 9, 0, 0, 0, 0, 142, 19, 95, 0, 0, 0, 210, 0, 0, 0, 44, 9, 212, 1, 193, 124, 141, 19, 0, 0, 0, 0, 0, 0, 0, 0, 4, 0, 4, 0, 0, 0, 5, 0, 4, 0, 1, 0, 1, 0, 0, 0, 0, 0, 12, 0, 100, 16, 101, 14, 6, 0, 0, 0, 5, 0, 0, 0, 0, 0, 0, 0, 5, 0, 0, 0, 40, 0, 0, 0, 35, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 56, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 41, 0, 33, 0, 50, 0, 41, 0, 0, 0, 209, 52, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 10, 0, 0, 0, 76, 29, 20, 2, 0, 0, 0, 0, 1, 8, 0, 5, 16, 20, 247, 42, 112, 50, 191, 171, 14, 3, 240, 96, 253, 28, 2, 0, 3, 0, 150, 0, 0, 0, 0, 0, 14, 2, 195, 13, 166, 13, 210, 0, 200, 0, 215, 52, 0, 0, 15, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 4, 1, 0, 0, 50, 50, 55, 51, 48, 53, 48, 50, 51, 51, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] })
[2022-09-27T10:55:55.071 DEBUG lxp_bridge::mqtt] publishing: lxp/redacted/inputs/all = {"status":20,"v_pv":834.2,"v_pv_1":230.8,"v_pv_2":184.6,"v_pv_3":418.8,"v_bat":52.7,"soc":100,"soh":0,"p_pv":153,"p_pv_1":99,"p_pv_2":54,"p_pv_3":0,"p_charge":0,"p_discharge":0,"v_ac_r":233.4,"v_ac_s":0.0,"v_ac_t":0.0,"f_ac":50.06,"p_inv":95,"p_rec":0,"pf":0.0,"v_eps_r":234.8,"v_eps_s":46.8,"v_eps_t":3193.7,"f_eps":50.05,"p_eps":0,"s_eps":0,"p_to_grid":0,"p_to_user":0,"e_pv_day":0.8,"e_pv_day_1":0.4,"e_pv_day_2":0.4,"e_pv_day_3":0.0,"e_inv_day":0.5,"e_rec_day":0.4,"e_chg_day":0.1,"e_dischg_day":0.1,"e_eps_day":0.0,"e_to_grid_day":0.0,"e_to_user_day":1.2,"v_bus_1":419.6,"v_bus_2":368.5,"e_pv_all":1.1,"e_pv_all_1":0.6,"e_pv_all_2":0.5,"e_pv_all_3":0.0,"e_inv_all":0.5,"e_rec_all":4.0,"e_chg_all":3.5,"e_dischg_all":0.2,"e_eps_all":0.0,"e_to_grid_all":0.0,"e_to_user_all":5.6,"t_inner":41,"t_rad_1":33,"t_rad_2":50,"t_bat":41,"runtime":79057,"max_chg_curr":0.0,"max_dischg_curr":75.0,"charge_volt_ref":53.2,"dischg_cut_volt":0.0,"bat_status_0":0,"bat_status_1":2049,"bat_status_2":1280,"bat_status_3":5136,"bat_status_4":10999,"bat_status_5":12912,"bat_status_6":43967,"bat_status_7":782,"bat_status_8":24816,"bat_status_9":7421,"bat_status_inv":2,"bat_count":3,"bat_capacity":150,"bat_current":0.0,"bms_event_1":0,"bms_event_2":526,"max_cell_voltage":35.23,"min_cell_voltage":34.94,"max_cell_temp":2.1,"min_cell_temp":2.0,"bms_fw_update_state":13527,"cycle_count":0,"vbat_inv":52.7,"time":1664276155,"datalog":"redacted"}
[2022-09-27T10:55:55.071 DEBUG rumqttc::state] Publish. Topic = lxp/redacted/inputs/all, Pkid = 78, Payload Size = 1429
[2022-09-27T10:55:56.252 DEBUG lxp_bridge::lxp::packet_decoder] 291 bytes in: [161, 26, 5, 0, 29, 1, 1, 194, 66, 65, 49, 50, 49, 51, 48, 48, 50, 51, 15, 1, 1, 4, 50, 50, 55, 51, 48, 53, 48, 50, 51, 51, 127, 0, 254, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 133, 25]
[2022-09-27T10:55:56.252 DEBUG lxp_bridge::coordinator] RX: TranslatedData(TranslatedData { datalog: redacted, device_function: ReadInput, inverter: redacted, register: 127, values: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] })
[2022-09-27T10:55:56.253 WARN lxp_bridge::coordinator] ignoring unhandled ReadInput register=127 len=254
[2022-09-27T10:55:56.253 WARN lxp_bridge::mqtt] ignoring unhandled ReadInput register=127 len=254
[2022-09-27T10:55:57.432 DEBUG lxp_bridge::lxp::packet_decoder] 291 bytes in: [161, 26, 5, 0, 29, 1, 1, 194, 66, 65, 49, 50, 49, 51, 48, 48, 50, 51, 15, 1, 1, 4, 50, 50, 55, 51, 48, 53, 48, 50, 51, 51, 254, 0, 254, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 217, 87]
[2022-09-27T10:55:57.433 DEBUG lxp_bridge::coordinator] RX: TranslatedData(TranslatedData { datalog: redacted, device_function: ReadInput, inverter: redacted, register: 254, values: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] })
[2022-09-27T10:55:57.433 WARN lxp_bridge::coordinator] ignoring unhandled ReadInput register=254 len=254
[2022-09-27T10:55:57.433 WARN lxp_bridge::mqtt] ignoring unhandled ReadInput register=254 len=254

Hello @excieve ,
I believe the ReadInput failures are something new in the SNA range of devices' firmware that sends some empty values for that register. I believe most of these were fixed in 0.9.0-dev that is available on Docker Hub. It does look like register 254 is a new failure though, I have also started receiving these the last week and a bit. I believe these are triggered from the comms to the LuxPower portal. I am working around the current crash by using docker compose with a auto restart in case of a container failure.
As far as your missing ../1 ../2 and ../3 topics go, I am working around this by sending a request via MQTT to the command topic for those 3 topics. I do this using node red as I want to receive the values in HomeAssistant every 5 seconds (I like realtime monitoring). It seems that ../all also gets updated once you request values for ../3 using the command topic.
I could publish that Node-Red flow for you in a gist somewhere if you are interested?
It would be nice to get these fixed so that we do not have to use workarounds, but I believe that @celsworth is running different hardware than we are. I am hoping I can get some time this week to write some quick patches (need to brush up on my Rust skills) that I will send to @celsworth for review.

@jacovt The current dev tag doesn't crash anymore — just ignores those unhandled registers, which might be fine.

I could publish that Node-Red flow for you in a gist somewhere if you are interested?

I'd be very interested, thanks!

It would be nice to get these fixed so that we do not have to use workarounds

I wonder why do we even need those ../1, etc. topics if everything seems to be present in the .../all topic though? Or is relevant when there are multiple parallel invertors connected?

I wonder why do we even need those ../1, etc. topics if everything seems to be present in the .../all topic though? Or is relevant when there are multiple parallel invertors connected?

So I guess this is a bit evolutionary. As has been suggested above, my inverter (a bit older now, an ACS3600, not a hybrid) publishes 3 different packets a second or so apart, each containing different bits of data. Newer ones publish a single larger packet of data that contains all those 3 combined, and perhaps newer ones still publish yet more larger packets although they contain mostly zeroes (as does yours above) so perhaps its not all used yet.
There were two trains of thought behind introducing the /all MQTT message:

unify the different inverter types so even the older ones like mine would lead to lxp-bridge publishing an /all packet, so it doesn't matter which inverter you have, you can always rely on this /all being published with all the data we get. So effectively, ignore the older 1/2/3 and just use /all, no matter which inverter you have
when I added InfluxDB capability, I noticed that it was adding 3 different rows to the database, each with their own timestamp, and each with only a third of the data populated, which led to very odd graphs and gaps in the data etc. So I started forming the idea of this merging the data into one super-packet, which was then sent to InfluxDB in one fell swoop, leading to one row with all the data. Much better graphs as a result.

I left the 1/2/3 messages in for backwards compatibility mostly, as people are probably using them already and I didn't want to break that. It could be an option whether to bother publishing them at all now.

@celsworth Thanks for the clarifications! If /all always has the right set of data regardless of the inverter, then would it make sense to change the HA discovery configs to always point to this topic instead of 1/2/3?

@celsworth I've made a quick PR for this — works fine on my setup.

authors: celsworth excieve jacovt

repo: celsworth/lxp-bridge


text:
Small bugfix in Utils.isNode() and Utils.isElement()

Just to try submitting a bugfix PR
Fixed presence check of Node and HTMLElement: should be checking for "function", not "object".

rather than accept pr, i've changed in my 'new release' branch, as i've been doing open heart surgery and wanna limit merge conflicts. will be in next release. thanks.

source: gharchive/pull-request

authors: Sleepyowl ceolter

repo: ceolter/ag-grid

license: mit

license_type: permissive

license_source: bigquery


text:
deploy: revert deploy template changes for release-3.5

This commit revert the template changes brought in for release-3.5
and making it refer to canary.
Signed-off-by: Humble Chirammal hchiramm@redhat.com

Looks like released helm charts are still pointing to canary version  https://github.com/ceph/ceph-csi/blob/43182b39fee7bb1a6bf408b0be3cc09faa572cd8/charts/ceph-csi-rbd/values.yaml#L111-L113

Looks like released helm charts are still pointing to canary version
https://github.com/ceph/ceph-csi/blob/43182b39fee7bb1a6bf408b0be3cc09faa572cd8/charts/ceph-csi-rbd/values.yaml#L111-L113

Looks like , that commit got dropped somehow, tagging it now.

changes are done for 3.5.0 in helm charts #2784 reverting is missing in this PR. make 3.5.1 release and then revert the changes?

yeah, have to release 3.5.1 and then revert or get this PR refereshed on top of 3.5.1

@Madhu-1 as discussed, considering the chart is auto refreshed, this pr refreshed accordingly and good to go. ptal.

helm chart changes are still missing?

@Madhu-1 forgot to push :) , should be there now.. thanks.. ptal.

changes are not done in minikube.sh https://github.com/ceph/ceph-csi/blob/release-v3.5/scripts/minikube.sh#L286-L287

ptal.

@Mergifyio rebase

@Mergifyio refresh

/retest ci/centos/mini-e2e-helm/k8s-1.21

/retest ci/centos/mini-e2e/k8s-1.23

/retest ci/centos/mini-e2e/k8s-1.22

/retest ci/centos/mini-e2e/k8s-1.21

/retest ci/centos/mini-e2e-helm/k8s-1.23

ci/centos/mini-e2e-helm/k8s-1.22

/retest ci/centos/mini-e2e-helm/k8s-1.22

repo: ceph/ceph-csi

license_source: github-api


text:
Admin role

ATM, ceph-common and /etc/ceph/ceph.client.admin.keyring are installed on all "mons".
Instead, we should have a dedicated "Admin" role, and only install ceph tools on minions that have that role.
Links
https://github.com/ceph/ceph/pull/33793

Please be sure to update https://confluence.suse.com/display/SUSEEnterpriseStorage/How+to+use when this feature is implemented.

The scope of this issue is about to change.
@sebastian-philipp can you please comment on what we are planning to change here?

Per our discussion, ceph-salt should not install ceph-common on "Admin" nodes. This will be tracked on a separate issue: https://github.com/ceph/ceph-salt/issues/120

@ricardoasmarques Will ceph-common be installed on any nodes at all?

@smithfarm https://github.com/ceph/ceph-salt/issues/120 will not install ceph-common at all

Please be sure to update https://confluence.suse.com/display/SUSEEnterpriseStorage/How+to+use when this feature is implemented.

Done

source: gharchive/issue

authors: ricardoasmarques smithfarm

repo: ceph/ceph-salt

license: MIT


text:
[Snyk] Security upgrade ejs from 2.6.2 to 3.1.6

Snyk has created this PR to fix one or more vulnerable packages in the `npm` dependencies of this project.

Changes included in this PR

Changes to the following files to upgrade the vulnerable dependencies to a fixed version:

package.json
package-lock.json

Vulnerabilities that will be fixed
With an upgrade:

Severity
Priority Score (*)
Issue
Breaking Change
Exploit Maturity

598/1000  Why? Proof of Concept exploit, Recently disclosed, Has a fix available, CVSS 4.1
Arbitrary Code Injection SNYK-JS-EJS-1049328
Yes
Proof of Concept

(*) Note that the real score may have changed since the PR was raised.
Check the changes in this PR to ensure they won't cause issues with your project.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.
For more information:
🧐 View latest project report
🛠 Adjust project settings
📚 Read more about Snyk's upgrade and patch logic

Pull Request Test Coverage Report for Build 553264657

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

Totals

Change from base Build 350934710:
0.0%

Covered Lines:
99

Relevant Lines:
104

💛  - Coveralls


text:
[terra-content-container] Fixing the border appearing on click

Summary

What was changed:
Added a condition for not setting the border when setFocusOnContainer is not there
https://github.com/cerner/terra-core/assets/126561169/fe4c0983-e3c5-406d-8b43-a047b6885e51
Why it was changed:
Because of the border appearing on click even though setFocusOnContainer is not there, this is breaking existing workflows and this fix needs to be addressed as soon as possible
Testing

This change was tested using:

[ ] WDIO
[ ] Jest
[ ] Visual testing (please attach a screenshot or recording)
[ ] Other (please describe below)
[X] No tests are needed

Reviews
In addition to engineering reviews, this PR needs:

[ ] UX review
[ ] Accessibility review
[ ] Functional review

Additional Details

This PR resolves:
UXPLATFORM-XXXX

Thank you for contributing to Terra.
@cerner/terra

Is this a bug fix?

repo: cerner/terra-core


text:
Test apply/upgrade with server-side apply

Server-Side Apply in Kubernetes is now in GA and in the future kubectl apply will perform a server-side apply by default which means that more and more cert-manager users who install using static manifests are using server-side apply, also other installation mechanisms are starting to use server-side apply by default.
cert-manager installation contains some resources (CustomResourceDefinitions, MutatingWebhookConfigurations, ValidatingWebhookConfigurations) that are modified by cainjector after installation, which introduces some complexity for server-side apply and we already saw one issue related to this  #4831
It would be good to test basic installation/upgrade via server-side apply.
Possible implementation
We currently have some tests for basic installation and upgrade of via static manifests here using kubectl client side apply. We could also add server side apply to those tests.
/kind cleanup

/remove-lifecycle rotten
This is annoying with fluxCD to manage our config.  It is constantly spamming ValidatingWebhookConfiguration/cert-manager-webhook configured because of (I believe) this annotation:
annotations:
    cert-manager.io/inject-ca-from-secret: "cert-manager/cert-manager-webhook-ca"

/reopen

authors: fawadasaurus irbekrm

repo: cert-manager/cert-manager


text:
Expose metrics for webhook and ca-injector

Is your feature request related to a problem? Please describe.
Currently, for the cert-manager-webhook and cert-manager-cainjector there is no visibility in how the these 2 components are working compared to the controller besides kube metrics. So we are unable to know if they are having any problems or not and know its availability which we can use for SLOs.
Describe the solution you'd like
Have some minimum metrics exposed e.g.
webhook - http_requests (status code, method, path)
ca-injector - injection_status (success, fail etc..), errors
Describe alternatives you've considered
Using kube metrics, but this is very broad and doesn't provide much details on its behavior
Additional context
Similar to how other kube components in the industry exposes metrics for it self for measuring
Environment details (remove if not applicable):

Kubernetes version: 1.25+
Cloud-provider/provisioner: eks
cert-manager version: v1.14.2,
Install method: helm

/kind feature

I will start by adding the standard go runtime metrics to those two components for consistency with the controller:

https://github.com/cert-manager/cert-manager/pull/6966

@nitinatgh
A pre-release is now available containing the fix for this issue. Please test and feedback if you have time.

https://github.com/cert-manager/cert-manager/releases/tag/v1.16.0-alpha.0

A beta-release is now available which contains the fix for this issue. Please test and feedback if you have time.

https://github.com/cert-manager/cert-manager/releases/tag/v1.16.0-beta.0

authors: nitinatgh wallrj


text:
Upgrade golang version to 1.8

Also upgraded:
github.com/cert-manager/cert-manager v1.8.0 => v1.8.1
github.com/container-storage-interface/spec v1.4.0 => v1.6.0
github.com/go-logr/logr v1.2.0 => v1.2.3
github.com/kubernetes-csi/csi-lib-utils v0.9.1 => v0.11.0
golang.org/x/net v0.0.0-20220107192237-5cfca573fb4d => v0.0.0-20220615171555-694bf12d69de
google.golang.org/grpc v1.43.0 => v1.47.0
Signed-off-by: Jing Liu jingliu@apple.com

Thanks!
/approve
/lgtm
/ok-to-test

repo: cert-manager/csi-lib


text:
Add image registry and repository separation

It would be beneficial to add image source options to trust-manager in the same way that cert-manager has them.
For example, in cert-manager, each workload image has the following structure in the template and values file.
Template snippet:
containers:
        - name: {{ .Chart.Name }}-controller
          {{- with .Values.image }}
          image: "{{- if .registry -}}{{ .registry }}/{{- end -}}{{ .repository }}{{- if (.digest) -}} @{{ .digest }}{{- else -}}:{{ default $.Chart.AppVersion .tag }} {{- end -}}"
          {{- end }}

values.yaml snippet:
image:
  repository: quay.io/jetstack/cert-manager-controller
  # You can manage a registry with
  # registry: quay.io
  # repository: jetstack/cert-manager-controller

  # Override the image tag to deploy by setting this variable.
  # If no value is set, the chart's appVersion will be used.
  # tag: canary

  # Setting a digest will override any tag
  # digest: sha256:0e072dddd1f7f8fc8909a2ca6f65e76c5f0d2fcfb8be47935ae3457e8bbceb20

Repository and tag are the only options available on trust-manager.
Motivation
I deploy cert-manager and trust-manager together as sub-charts of a parent chart, and need to serve images from a private registry. Having this feature will allow a single registry to be configured once and declared as a yaml anchor, and referenced as an alias for cert-manager and trust-manager.

/kind feature

repo: cert-manager/trust-manager


text:
🛑 echo-server.madacluster.tech is down

In 204f353, echo-server.madacluster.tech (https://echo-server.madacluster.tech) was down:

HTTP code: 0
Response time: 0 ms

Resolved: echo-server.madacluster.tech is back up in 0726d37 after 4 minutes.

repo: cesarempathy/upptime


text:
Gradle Kotlin-DSL has double quotes and parenthesis

Can you add an option --format=[kotlin|groovy]  to generate the dependency information compatible with build.gradle for groovy and build.gradle.kts for kotlin?
Ideally calling with no format argument should use the previous value
--format=kotlin would be like this:
dependencies {
  implementation("com.squareup.picaso:picaso:2.5.2")
}

it doesn't work without () anymore?

Correct,

in kotlin build.gradle.kts, it doesn't work without () (implementation is a normal extension method)
in kotlin build.gradle.kts, it doesn't work with simple quotes (like in java)
in groovy build.gradle, implementation("com.squareup.picaso:picaso:2.5.2")` with parenthesis and double quotes is actually an accepted syntax.

So actually, instead of having an option --format=kotlin|groovy, we could just change the dependency format to implementation("com.squareup.picaso:picaso:2.5.2") and be compatible with both!

@cesarferreira would you be interested by a pull-request where I change the output so that it works both in a build.gradle and a build.gradle.kts file?
dependencies {
-  implementation 'com.squareup.picaso:picaso:2.5.2'
+  implementation("com.squareup.picaso:picaso:2.5.2")
}

Yes please @jmfayard

@cesarferreira done! The first line of ruby I ever wrote, hopefully not wrong :)

It works, thanks for the PR

btw @jmfayard love the idea on your lib https://github.com/jmfayard/gradle-kotlin-dsl-libs

authors: cesarferreira jmfayard

repo: cesarferreira/alfi


text:
🛑 Website is down

In fa6714a, Website (https://www.fortifymail.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Website is back up in 59f5b94 after 17 minutes.

repo: cetana-solutions/Fortifymail-Status


text:
Set up "Bleeding Edge" Ionian Repos

The Ionian OS will need frequent updates for security and package updates.

Will update iso/usb raspian images and put them in a weekly update directory.  I can keep up with 1 or 2 per day,  I will do the updates manually in a queue fashion ie day 1 amd64 iso day 2 i386 iso day 3 amd64 usb etc and start back at the beginning again once all the OS images have been updated.

Will start with updating raspian

have update raspian and am now uploading updated version

Have now updated 1386 ISO...to make things easier, I will put the previous versions in a subdirectory on the web page keeping the two previous images.

Ubuntu LTS 18.04 is being released next month.  Will have to update ionian to use this new version

i386 ISO updated and uploaded.  amd64 will be coming tomorrow

amd64 ISO being uploaded now

amd64 ISO is uploaded now.

Uploading i386 and amd64 vdi images

Will continue to up[date Ionian OS images with most recent packages and newest ioncore version

repo: cevap/ion


text:
Impossible to give a Java class to an annotation

It's quite common for Java frameworks to have annotations that expect a Java java.lang.Class<?> as a parameter. These annotations are impossible to be used in Ceylon because only literals can be passed to annotations.
Example:
autoService(javaClass<Runnable>()) class XXX() {}

Causes an error:
Illegal annotation argument: must be a literal value, metamodel reference, annotation instantiation, or parameter reference

I cannot confirm either doing:
autoService(`interface Runnable`) class XXX() {}

actually works (ie. the Java annotation processor does get the right type java.lang.Class<Runnable>... but if it does, then it must be because the Ceylon compiler goes and replaces the Type<Runnable> with the expected Class<Runnable>... but then why can't the Ceylon compiler simply be consistent and forget about the javaClass<>() function entirely and ALWAYS do this everywhere, not only in some kind of special-cases that no ones knows of and seem totally arbitrary?

Counter-question. Why should Ceylon add this ugly special case for one function that isn’t even in the language module (i. e., we have no guarantees for its behavior) when the alternative `class X` syntax, which is more consistent (Ceylon annotations also take Declarations, not Java Classes) and doesn’t require extra modules or helper functions is already available?
I also fail to see why no one should know of this when it’s perfectly well documented in the Calling Java From Ceylon reference, which I really think we can expect people who want to use such annotations to have read or at least consult when encountering questions, or how this is arbitrary when it is in fact consistent with the fact that Ceylon annotations use the same `class X` syntax.
(This would of course be even more obvious – and better supported in the IDE – if the model loader didn’t map the Class parameter to Anything, in other words, if #5918 was fixed.)

Ceylon's metamodel types are much more useful than Class<T>, so I don't know why we'd change metamodel expressions to return Class<T>. And, Class<T> is only available on the JVM.
You can't use a runtime expression for an argument to an annotation, so using the javaClass<>() function is out of the question. And, as @lucaswerkmeister points out, the current syntax for Java annotation arguments is consistent with those of Ceylon annotations.

then it must be because the Ceylon compiler goes and replaces the Type with the expected Class

Although that seems like useful functionality, replacing class X with the java class type when passed to a parameter of type Class<X> I don't think we normally allow things to mean two different things in two different places depending on the expected type.
So we'd need something that can be treated as a "literal", because even something as `class X`.javaClass probably isn't allowed.
But perhaps @gavinking or @tombentley have some idea on how to handle this.

@lucaswerkmeister  either you misunderstand my point or you're so used to this horrible quirk that you can't see past it anymore.

@quintesse

I don't think we normally allow things to mean two different things in two different places depending on the expected type.

But that's my complaint, it looks like you're treating annotation arguments specially and trying to make it work when I pass a metamodel literal to it. My proposal is to either:

allow this automatic conversion of Java literal types everywhere, not only in annotation arguments.
allow javaClass<>() as an argument to annotations to make it consistent with everywhere else.

Of course, I prefer the first option above.

But that's my complaint, it looks like you're treating annotation arguments specially and trying to make it work

I don't understand why you say this. Didn't you say before that you don't know if it works because you didn't try? "I cannot confirm either doing ... actually works"

allow javaClass<>() as an argument to annotations to make it consistent with everywhere else.

Well like was explained above this is just impossible because the JVM makes this impossible, so I don't understand why you keep on mentioning this.

allow this automatic conversion of Java literal types everywhere, not only in annotation arguments.

Well if this conversion is done for annotation arguments then it would indeed be logical to do so everywhere. But only if that's what's happening. Although I would find it surprising if that's really what's happening.

I think it's that there needs to be some syntax for Java annotation arguments of type Class, so why not use what we already have, rather than inventing something new or borrowing the less Ceylonic C.class literal syntax from Java?
FTR, the `class C` syntax has worked perfectly fine for me. I don't see evidence of an actual bug in this issue. But perhaps @renatoathaydes could compile with --verbose=code to see exactly what annotation is being generated.

so why not use what we already have

@jvasileff but wouldn't this be the only place where the same expression gives two different results depending on the expected type? I always thought it was something against @gavinking 's "rules".

I don't know*. Is there some technical explanation that makes it clear one way or the other if this is an implicit conversion? It's so specific (and backend specific), that I'm willing to say it isn't. And, it's not like you'll ever have an actual instance of ClassOrInterface<> implicitly converted to a Class<>.
* Let's ignore the implicit Integer -> Float widening :)

Is there some technical explanation that makes it clear one way or the other if this is an implicit conversion?

The best way to do this, in my opinion, would be in the model loader. In annotation constructor parameters, Class<?> should map to ClassOrInterfaceDeclaration, just like we already map boolean to Boolean, and beans to properties, etc. I guess this would also be my solution to #5918.

It probably already does it that way, doesn't it?
I suppose that provides the technical explanation too. To the typechecker, there is no conversion, of course.

No, it currently maps to Anything, see #5918. You just get a javac error if you put in a String.

Oh, right.

Alright, I had a look at the bytecode (with IntelliJ so it looks just like plain Java).
Here's my Ceylon code:
import com.google.auto.service {
	autoService
}

import java.lang {
	Runnable
}

autoService(`Runnable`) shared class MyRunnable()
	satisfies Runnable {

	shared actual void run() {
		print("Running MyRunnable");
	}

}

And this is the bytecode:
@Ceylon(
    major = 8
)
@
@SatisfiedTypes({"java.lang::Runnable"})
@AutoService(Runnable.class)
public class MyRunnable implements ReifiedType, Runnable, Serializable {
    @Ignore
    public static final TypeDescriptor $TypeDescriptor$ = TypeDescriptor.klass(MyRunnable.class, new TypeDescriptor[0]);

    public MyRunnable() {
    }

    @
    @ceylon.language.ActualAnnotation.annotation.
    @TypeInfo("ceylon.language::Anything")
    public final void run() {
        print_.print(String.instance("Running MyRunnable"));
    }

    @Ignore
    public static void main(java.lang.String[] args) {
        process_.get_().setupArguments(args);
        new MyRunnable();
    }

    @Ignore
    public TypeDescriptor $getType$() {
        return $TypeDescriptor$;
    }
}

So indeed, there's some kind of transformation from autoService(`Runnable`) to @AutoService(Runnable.class) going on (which means the ceylon runtime does not process annotation-processors exported via ServiceLoader because this code still won't work).
@quintesse

Well like was explained above this is just impossible because the JVM makes this impossible, so I don't understand why you keep on mentioning this.

The javaClass function returns a Java Class which is a literal for the JVM, so there's no reason it cannot work on the JVM at all. In fact, I would find surprising if you guys actually had this function exist at all at runtime, why not just replace it at compile time with the class literal??

BTW WTF is that main function doing there in my runnable class? Do you guys generate a main function for every run method??

I think what @quintesse was referring to is that this is illegal in Java:
@AutoService(javaClass_.javaClass(…))
public class …

since annotation arguments can’t be function calls. So we would have to translate javaClass<X> to class.X at compile time, which is conceptionally ugly because javaClass isn’t even in the language module.
And yes, we actually even generate a main method for every nullary toplevel function or class. You can ceylon run --run=your.package::MyRunnable, which will run its initializer.

@renatoathaydes every no-argument class or toplevel method is "runnable", that's what the main is for.

Ok, so now that we know the bytecode generated for the annotation works, let's see what's the bytecode generated for the actual code, for example:
import com.google.auto.service {
	autoService
}

import java.lang {
	Runnable,
	JClass = Class
}
import ceylon.language.meta.model {
	ClassOrInterface
}

autoService(`Runnable`) shared class MyRunnable()
	satisfies Runnable {

	shared actual void run() {
		value runnableClass = `Runnable`;

		ClassOrInterface<Runnable> theRunnableType = `Runnable`;

		//JClass<Runnable> theJavaType = `Runnable`;

		print("Running MyRunnable: ``runnableClass``");
	}

}

The bytecode (only of the run function as the rest is the same):
    @
    @ceylon.language.ActualAnnotation.annotation.
    @TypeInfo("ceylon.language::Anything")
    public final void run() {
        Interface runnableClass = (Interface)typeLiteral_.typeLiteral(TypeDescriptor.klass(Runnable.class, new TypeDescriptor[0]));
        Interface theRunnableType = (Interface)typeLiteral_.typeLiteral(TypeDescriptor.klass(Runnable.class, new TypeDescriptor[0]));
        print_.print(String.instance("Running MyRunnable: " + runnableClass.toString()));
    }
}

You see... you said you don't want two behaviours for the same syntax, but that's exactly what you have right now.

The commented out JClass<Runnable> theJavaType = `Runnable`; obviously won't compile... but that's pretty much what you would expect if you knew that you can do, with an annotation that expects a java Class: autoService(Runnable)

I disagree. It’s true that the same Ceylon expression can, depending on context, produce different Java expressions, but that’s not exclusive to annotations:
@noanno String  s = "";
@noanno String? t = "";

// heavily abridged
final class s_ {
    private static final .java.lang.String value;
    static {
        value = "";
    }
final class t_ {
    private static final .ceylon.language.String value;
    static {
        value = .ceylon.language.String.instance("");
    }
}

String erases to java.lang.String, String? to ceylon.language.String. I don’t think there’s anything especially outrageous about this.
However, we don’t have two different behaviors. Passing a Ceylon Declaration or Class to a Java annotation would simply result in a type error, so there’s no point in doing it.

@lucaswerkmeister

we would have to translate javaClass to class.X at compile time, which is conceptionally ugly because javaClass isn’t even in the language module.

I disagree with this statement.

any code calling javaClass() has to be native("jvm") code, so there's no problem handling this especially for the Java backend.
nothing is uglier than having to use a function to get a literal.
this kind of wrapper function makes interop very painful.

If the Ceylon team wants to treat Java as just another backend instead of giving it VIP treatment, I understand these choices... Otherwise, this needs to be greatly improved.
Every time I have a Java project and I am able to introduce a new language, I will always pick Groovy and Kotlin over Ceylon without second-thought... even though Ceylon is by far my favourite language.
In fact, we're starting to introduce Kotlin at our production code (and I have already introduced Groovy tests with Spock and everyone loves that... also did Groovy UI previously, which was moderately successful)... I would think my case is quite typical so Ceylon can expect this kind of thing will happen with many others... which means the language will only be chosen for projects that don't depend at all on any existing code (including Java libs), which makes it a extremely rare choice.
This must explain why so far my Ceylon projects are many orders of magnitude less popular than my Java/Groovy ones. What a pitty.

@renatoathaydes what on earth are you talking about?

nothing is uglier than having to use a function to get a literal

And your proposal is to use a function for annotation arguments rather than the current literals? And replace the current approach that makes perfect sense from a type system perspective, as @lucaswerkmeister pointed out?

I think we have to clarify what this issue is about.
As far as I read @renatoathaydes’ latest comment, you want this to work:
import java.lang {
    JClass=Class
}

JClass<MyClass> klass = `MyClass`; // instead of having to use the ugly function javaClass

// this function is defined in some Java library
void someFunction(JClass<out Object> klass) {
    // …
}

// and we want to call it from Ceylon as
someFunction(`MyClass`);
// or
someFunction(`class MyClass`);
// after all, if `MyClass` works in annotation arguments, why not allow it here too?

Is that right @renatoathaydes? Because that has nothing to do with the issue title, and only little with the issue description.
I wouldn’t be opposed to it, though. If we can make it work in a consistent way, this would probably improve Java interop, though I don’t know how commonly you need Class objects.

@jvasileff

And your proposal is to use a function for annotation arguments rather than the current literals?

No. I don't know how to make myself clearer than what I already have.
@lucaswerkmeister got it right.
This needs to work (where MyClass is a Java class, at least):
JClass<MyClass> klass = `MyClass`;

If this works:
myJavaAnnotationThatTakesAJavaClass(`MyClass`) class X() {}

If you can't see why this should be the case, then I give up.
@lucaswerkmeister

Because that has nothing to do with the issue title

Right, and that's what happens when we discuss things... I didn't know exactly what the issue was in the beginning, now it should be clear to everyone. Let's create a new ticket if you prefer...

@renatoathaydes you're right, I misinterpreted your latest post. But I get a free pass when your position evolves so rapidly:

My proposal is to either:

....
allow javaClass<>() as an argument to annotations to make it consistent with everywhere else

to

nothing is uglier than having to use a function to get a literal

But anyway... we are now focussed on just one idea. Good.

allow this automatic conversion of Java literal types everywhere, not only in annotation arguments

There is a problem with the premise. There is no conversion for annotation arguments! From the view of Ceylon, the myJavaAnnotationThatTakesAJavaClass doesn't actually take a Java Class<>. It takes a Ceylon ClassOrInterfaceDeclaration.
As explained above, this is a standard pattern in Ceylon-Java iterop. For example, Java methods that return java.lang.String in Java may actually return ceylon.language::String from the Ceylon perspective. There is no conversion in the Ceylon type system. JString s = "".string; produces a type error, because string (toString() in Java) returns ceylon.language::String, which is not assignable to java.lang.String.
And this is good. It provides interop convenience while not introducing problems and complexities with implicit conversions.
Now, I think what may be confusing is that from Ceylon, annotations that take a Class<> in Java look like they take a ClassOrInterfaceDeclaration, but nowhere else does this mapping occur. So this has to be learned.
Should this mapping occur everywhere possible? Probably not. First, the types are quite different (unlike String vs. JString), and second, the mapping doesn't work in generic contexts. So it would be pretty confusing to work with JList<Class<>> sometimes, but then ClassOrInterfaceDeclaration for non-generic parameters and returns. It's better to just always work with Class<>.
Finally, that leaves us with the idea of introducing an implicit conversion for certain metadata literals. This is something that actually would be inconsistent with the rest of the language. Implicit conversions do not currently occur anywhere in Ceylon.
FWIW, my opinion on implicit conversions of literals is:

They can be really cool! See Swift's "convertible" protocols, allowing various types of literals to be used for any conforming type, even user defined.
Swift's approach probably wouldn't map to Ceylon. But if it did, we'd first need type classes! (Or at least the ability for interfaces to require certain constructors or static factory methods.)
Special casing just metadata literals, to avoid having to use javaClass, would be way too much of a special case for so little gain, and would cause code readability problems (people aren't used to seeing implicit conversions in Ceylon code)
Trying to do something more general, like what Swift has, IMO wouldn't be worth it without identifying significantly greater benefits than getting rid of javaClass. Perhaps @sadmac7000's desire to support literals for 32 bit integers.

If you can't see why this should be the case, then I give up

Sure, the ability to use the same syntax for obtaining Class<?> instances for what in Java's view of an api is the same thing certainly appears to be reasonable and consistent. But for the reasons explained, the issue is more complicated (actually, much simpler from the Ceylon perspective!), and the current approach when viewed from Ceylon's mapping of the apis is very clean and consistent.

@lucaswerkmeister

this would probably improve Java interop, though I don’t know how commonly you need Class objects.

I need Class objects all the time. Strings also. And lambdas, numbers, arrays... which is why these need to work if you have proper Java interop:
JClass<Runnable> runnable = `Runnable`;
JString myString = "ceylon string but for fucken sake make it a Java String";
JLong myLong = 10;

javaObject.thatTakesALong(myLong);

javaMethodExpectingSupplierOfString(() => "hello Java!");
Thread(() => print("hi!")).start();

for (item in someJavaIterable) {
   print(item);
}

And so on... do you know which cases above work? Without trying or reading the documentation?
The String and Long cases I think actually work... not even sure (what about parameter types, or annotation arguments which seem to be treated differently??) but the others definitely won't work.
AFAIK these are all 100% type-safe because all of the Ceylon literals can safely be converted to the respective Java literals, even if the opposite is obviously not true.
Want an example of what using a Java lib looks like in Ceylon, currently?
shared void run() {
    object hello satisfies Route {
        shared actual Object handle (Request request, Response response) {
            for (header in CeylonIterable(request.headers())) {
                // BROKEN: the below does not even compile!
                print("Header ``header``: ``request.headers(header)``");
            }
            return "Hello Ceylon!";
        }
    }

    object bye satisfies Route {
        object stop satisfies Runnable {
            shared actual void run() {
                Thread.sleep(250); // so the server responds to the request before dying!
                print("Stopping Server");
                Spark.stop();
            }
        }

        shared actual JString handle (Request request, Response response) {
            Thread(stop).start();
            return javaString("Bye!");
        }
    }

    Spark.get("hello", hello);
    Spark.get("bye", bye);
}

Compared to this equivalent Kotlin:
fun main(args: Array<String>) {
    Spark.get("hello", { request, response ->
        request.headers().forEach { println("Header: $it: ${request.headers(it)}") }
        "Hello Kotlin"
    })
    Spark.get("bye", { request, response ->
        Thread {
            Thread.sleep(250)
            Spark.stop()
        }.start()
        "Bye!"
    })
}

This is pretty close to Groovy, but with the same type-safety as Ceylon (and took me literally 5 minutes to write and run with almost no experience in Kotlin, compared to the nightmare it is to get this code running in Ceylon - try it for yourself - and you need to use the Gradle plugin I wrote to get the loads of transitive deps if you don't want to spend your day hunting jars). To find out I can loop over a Java Iterable only after I wrap it using CeylonIterable() actually blocked me for hours and I couldn't find this in the docs and only learned about it when @gavinking told me on Gitter.
Which one would you choose, honestly, if you knew you had to deal with Java code a lot in your project?
NOTE: the line that does not compile in Ceylon in the above example has this error in the call to headers(String? name):
Ambiguous invocation of overloaded method or class: there must be exactly one overloaded declaration of headers that accepts the given argument types JString

Is this a bug or I'm again failing to read the docs, and this obviously shouldn't work?

Is this a bug

Try using request.headers(header.string) to convert the JString (due to it's generic origins) to String.
BTW, nice writeup of interop challenges.

@jvasileff do you know if this bug has already been reported?
Thanks... I love Ceylon, but these issues (many times related to the poor Java interop) are getting really annoying.

@renatoathaydes unfortunately that's not a bug (assuming adding .string fixed the problem.)
You wound up with a JString because that's what the generic Java based request.headers() provided, and there is no JString -> String mapping for generic types. But the request.headers() method needs a Ceylon String even though it is also a Java api, because in that case, the type is not generic and therefore is mapped.
Since iterating a collection of JStrings is such a common thing, perhaps it would be worth opening a feature request for a CeylonStringIterator that would automatically perform the conversion. I added something similar in 1.2.0 for Maps - https://modules.ceylon-lang.org/repo/1/ceylon/interop/java/1.2.0/module-doc/api/CeylonStringMap.type.html.

@jvasileff Using header.string worked... so I guess I should've read the docs more closely after all :)

@gavinking how about a pair of fancy built in type functions (like in https://github.com/ceylon/ceylon/issues/5838) in the interop package that map between Java and Ceylon types, leaving others alone, that could be used to write some really nice interop wrappers for generic classes?

renatoathaydes I see you're frustrated but the above code comparison is amazingly unfair to Ceylon, and I'm disappointed that you would tweet something so misleading to the world.

So, @renatoathaydes, my very first attempt to improve your code yielded this:
shared void run() {

    Spark.get("hello",
        SparkRoute((request, response) {
            for (header in CeylonIterable(request.headers())) {
                print("Header ``header``: ``request.headers(header.string)``");
            }
            return "Hello Ceylon!";
        }));

    Spark.get("bye",
        SparkRoute((request, response) {
            JavaThread(() {
                Thread.sleep(250); // so the server responds to the request before dying!
                print("Stopping Server");
                Spark.stop();
            }).start();
            return "Bye!";
        }));
}

Given the following two totally trivial library functions:
class JavaThread(shared actual void run()) extends Thread() {}

class SparkRoute(handle) satisfies Route {
    shared actual Object handle(Request request, Response response);
}

This is hardly the catastrophe you make it out to be, and can be improved further, for example using a CeylonStringIterable.
For the record it took me about 50 minutes to get that code working, most of which time was spent figuring out how to make Spark work on JBoss Modules. (I've never used Spark before.)

JavaThread (and JavaRunnable) should probably be in ceylon.interop.java.

@lucaswerkmeister Well, sure, I agree with that, but the correct way to solve that problem is to send a pull request to ceylon-sdk. I don't see where anyone here has considered that approach to the problem.

@renatoathaydes

To find out I can loop over a Java Iterable only after I wrap it using CeylonIterable() actually blocked me for hours and I couldn't find this in the docs and only learned about it when @gavinking told me on Gitter.

Well that's weird, since it's mentioned here:
http://ceylon-lang.org/documentation/1.2/tour/interop/#utility_functions_and_classes
Right in the "Interoperation with Java" chapter of the tour.

OK, now to the original problem in the issue description. Following the documentation here, I just tried writing this:
import javax.annotation {
    resource
}

...

resource { type = `class Foo`; }

Which resulted in the following Java annotation:
javax.annotation.Resource(type = .sparky.Foo.class)

So the original issue description is quite plainly incorrect.
It's true that there is a bug in the model loader, which causes type to be assigned the type Anything instead of ClassOrInterfaceDeclaration, as you have reported in #5918.
But otherwise I think this issue report is incorrect and should be closed.

Finally, there is a proposal by @renatoathaydes that a regular Java method with this signature:
void whatever(java.lang.Class<?> clazz)

Should be invokable like this:
whatever(`class Foo`);

Instead of:
whatever(javaClass<Foo>());

Or:
whatever(javaClassFromDeclaration(`class Foo`));

I have to say I really don't know what the big deal here is, and I frankly disagree with Renato's reasoning.

java.lang::Class and ceylon.language.meta.declaration::ClassOrInterface are two quite different types in Ceylon and it's quite impossible to make them exactly the same.
FTR, the same problem arises in both Scala and Kotlin, which also each have their own reflection API. See here and here for example. In none of these three languages is the syntax for getting a java.lang.Class the same as the syntax for getting an instance of the language's own metamodel object.

I have in the past proposed that we could start using the model loader more aggressively for cases similar to this one, but that suggestion has never gained any traction due to the difficulties associated with generics, return types, etc. It would only ever be a partial solution.
Another complication, which Renato hasn't considered at all, is that you have very interesting operations with signatures like this:
T find(java.lang.Class<T> clazz, Object id)

Today, such operations are smoothly callable like this:
Foo foo = find(javaClass<Foo>(), id);

But if we wanted to transform this to Ceylon metamodel types, the equivalent thing would be:
Foo foo = find(`Foo`, id);

i.e. I would need a ceylon.language.meta.model::Class<Foo>, not a ceylon.language.meta.declaration::ClassDeclaration.

JavaThread (and JavaRunnable) should probably be in ceylon.interop.java.

See https://github.com/ceylon/ceylon-sdk/commit/9905eed8e864b4f7e26da9c2ccbbc138b32ddf9c and https://github.com/ceylon/ceylon-sdk/commit/5dab789f442c263090febd884acddfd7125b8d5d.

@gavinking I think people should know what the experience of using Java interop really is like. You may think it is pretty good. I completely disagree. I'm trying to write a Ceylon library for the JVM that depends heavily on Java interop. It's taken me so much time trying to figure out how to make interop things work that I just can't focus on the actual functionality of what I'm doing. There's nothing fair to my comparison. I have been doing Ceylon for years now, and have 0 experience in Kotlin. The Kotlin interop is just immensely better and more pleasant to work with. Don't try to cover the sun with a sieve.

But otherwise I think this issue report is incorrect and should be closed.

Sorry if I wasted your time. I certainly did not enjoy wasting mine.

@renatoathaydes I think people should know what the experience of using Java interop really is like. You may think it is pretty good. I completely disagree.
Fine. Actual experience is very useful and interesting. And yet the fact remains that several things you've asserted here in this thread are simply mistaken. And the comparison you showed to Kotlin was utterly misleading. To be clear, it took me literally 5 minutes to halve the amount of Ceylon code you exhibited, and arrive at something that was only barely different to your Kotlin code. And I didn't have to use any strange or obscure or undocumented techniques to do that. All I did was like ... write two trivial utility functions.

It's taken me so much time trying to figure out how to make interop things work that I just can't focus on the actual functionality of what I'm doing.

Well then I simply don't understand why, instead of catastrophizing, which is what you're doing now, you didn't show your code on gitter, or on the mailing list, and ask for advice on improving it.
Of course, we're very interested in specific concrete issues, like #5918, which was a good catch, and is easy to fix. I can see how that bug could have caused some wasted time, but, again, it would not have needed to if you had asked how to do this on Gitter or the mailing list a little sooner.
Instead of that, I wake up to a bashing tweet on a Sunday morning, which doesn't put me in a good mood, frankly.

Well that's weird, since it's explicitly mentioned here:
http://ceylon-lang.org/documentation/1.2/tour/interop/#utility_functions_and_classes

Well, it's not mentioned in the interop reference page (which I had thought would've covered that), is it?
http://ceylon-lang.org/documentation/1.2/reference/interoperability/java-from-ceylon/

And yet the fact remains that several things you've asserted here in this thread are simply mistaken.

Are you somehow accusing me of making intentional misleading statements of just of being ignorant?

And the comparison you showed to Kotlin was utterly misleading. To be clear, it took me literally 5 minutes to halve the amount of Ceylon code you exhibited...

No, it's not misleading in any way, and I have no idea why you'd think a Ceylon-community participant of years would have any reason to try to mislead anyone.
Of course, there's always a way to improve the code by using external functions, libraries or whatever... but all I wanted was to make a quick and simple demo that works, which in Ceylon takes hours if you're a first-timer, in Kotlin takes 5 minutes (I just proved it). Did you try to improve the Kotlin code as well? If not, then your quote is misleading... I'm sure it could down to around 2 lines with a little effort (+ some helper functions like you did in Ceylon).

Well then I simply don't understand why, instead of catastrophizing, which is what you're doing now, you didn't show your code on gitter

Are you serious? I've been on Gitter so much that people are probably thinking I have nothing better to do with my time than discuss Ceylon stuff with them... I am not catastrophizing anything, really, just trying to show the world (including the Ceylon team) that Ceylon is not a good option if you need to interop with Java. May be a catastrophe for you.... but for me is just a matter of using the best tool, be it Groovy, Kotlin, Scala or any other option.

Instead of that, I wake up to a bashing tweet on a Sunday morning, which doesn't put me in a good mood, frankly.

And you think I'm in a good mood after battling these huge amounts of bugs and quirks when I just want to write a tiny simple library for Ceylon (which I am hoping to contribute to the community soon)?? You have no right to expect community members to tell you how lovely your language is, which I did in numerous occasions, but being disappointed when they tell you how bad the Java interop really is. This also does not make me feel any better.

return "Hello Ceylon!";

That's unsafe to do if the Java method has an Object return-type (as does the Spark code), because as you know well (and I filled a bug about this a long time ago) this will actually give a Ceylon String to the Java code... so if the Java code does instanceof on the value (for example, like some Swing classes do, remember?) then this may cause an error in the Java code. Luckily, looks like Spark reacts to an unknown type by simply calling toString() on it, so it just so happens that with Spark, this does work.... but I wouldn't do this (by mistake, I forgot to wrap the String in one of the handlers).

Guys, please everyone calm down.
@renatoathaydes thanks for your feedback. Correct me if I'm missing anything from what I should take from your comments:

Support auto-convertion from Java box types to Ceylon types (java.lang.Long to ceylon.language.Integer and similar)
Issue with boxed Ceylon String (ceylon.language.String) used for Object return types/parameters with interop, leading to type not handled by interop lib (expecting java.lang.String)
Easier/more intuitive way to convert Ceylon/Java String (without ceylon.interop.java module?)
Easier/more intuitive way to convert Ceylon/Java metamodel/Class (without ceylon.interop.java module?)
Iteration of Java java.util.Iterable in for
Auto-convertion from/to Java SAM types to Ceylon Callable

Anything else? I think it'd be useful to open an issue with this list (and anything else your or I may have forgotten) so we can track this. Some of those points have existing workarounds, perhaps that we can/should improve. Some others are already planned, and yet others may be impossible, but if we discuss them perhaps we'll figure something, OK?

@FroMage I should've compiled this list myself :) thanks for that. I don't know which of these issues already have a ticket... do you want just one ticket with this list? Should I create it? I don't mind if you do it...
One more item:

document in the annotations page (and java interop reference, maybe) how Java annotations expecting a Class<?> can be called with Ceylon literals (eg. javaAnnotation(`SomeType`), but when a method expecting a Java Class is used in normal code, the javaClass<SomeType>() function must be used.

Iteration of Java java.util.Iterable in for

This one is #4389

Auto-conversion from/to Java SAM types to Ceylon Callable

I think that's #1617

authors: FroMage gavinking jvasileff lucaswerkmeister quintesse renatoathaydes tombentley

repo: ceylon/ceylon


text:
object is inferred to be type Basic

If the following is not a bug according to the Ceylon spec, then it should be considered a bug in the spec.
At least it is very counter-intuitive.
    object x{}
    String | \Ix m(){return x;}

    value a = m(); // a inferred to be String|Basic here instead of String|\Ix
    if (is \Ix a) {
        return;
    }
    String s = a; // leads to error here: String|Basic is not assignable to String

@dlkw I don't know what all of the arguments for this are/were, but one tradeoff is that you often don't want or expect the more precise type:
variable value b = true;
b = false; // ok, but if \Itrue were inferred:
// error: specified expression must be assignable to declared type of 'b':
// 'false' is not assignable to 'true'

variable value bools = ArrayList { true };
bools.add(false); // ok, but if \Itrue were inferred:
// error: argument must be assignable to parameter 'element' of 'add' in 'ArrayList<true>':
// 'false' is not assignable to 'true'

It appears this is explicitly covered by the specification:

§3.2.9. Type inference
…
An inferred type never involves an anonymous class, as defined in §4.5.7 Anonymous classes. When an inferred type would involve an anonymous class type, the anonymous class is replaced by the intersection of the class type it extends with all interface types it satisfies.

Ah, I see. My example comes from the usage as signalling an error condition.
I thought it would be more "economic" to use an object without specific class, but it seems it'd be better to write
abstract class Error() of error{}
object error extends Error(){}

String | Error m(){return error;}

    value a = m(); // a inferred to be String|Error now
    if (is Error a) {
        return;
    }
    String s = a;

Thanks for the clarifcation/rationale not inferring the "object class".

authors: dlkw jvasileff lucaswerkmeister


text:
Default Nginx configuration

Checks:
https://www.ssllabs.com/ssltest/
https://securityheaders.io/?q=https%3A%2F%2Flodash.com%2F
https://letsecure.me/secure-web-deployment-with-lets-encrypt-and-nginx/
With https://letsencrypt.org/

I need project structure

repo: cezerin/cezerin


text:
ENV_DIR requires an absolute path

I ran the script with ENV_DIR=env1 and was greeted with:
~/gcp-pcf-quickstart/src/omg-tf ~/gcp-pcf-quickstart
loading environment config: open env1/config.json: no such file or directory

I am certain that the env1/config.json file exists at this relative path.
If I rerun with ENV_DIR=/Users/me/gcp-pcf-quickstart/env1 everything works.

Looks like this happens because the deploy script changes into the ENV_DIR's terraform directory and then runs omg-cli commands.
Might be best just to add a note to the help message and/or README, as checking for relative paths in bash in a portable manner is somewhat nasty.

repo: cf-platform-eng/gcp-pcf-quickstart


text:
03-bootsector-memory - Why does 0x58 of "X" corresponds to 0x2d in the boot sector?

Why does 0x58 of "X" corresponds to 0x2d in the boot sector?
I don't see why 2d is the actual position of the 'X' byte in the binary. 2d is 45 in dec.
this is my result of xxd:
00000000: b40e b033 cd10 bb13 0081 c300 7c8a 07cd  ...3........|...
00000010: 10eb fe58 0000 0000 0000 0000 0000 0000  ...X............
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000130: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000140: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000150: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000160: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000170: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000180: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000190: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001a0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001b0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001c0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001e0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.

Nobody answers. Closed

Why I can't close this issue? It always says 'You can't comment at this time — your comment cannot be blank.' when I tap close & comment.

repo: cfenollosa/os-tutorial


text:
Config 2.0

This is for any suggestions and discussion regarding new and/or breaking changes for CFLint's configuration in v2.0. Most of this is copied from Issue #352. All of my suggestions were taken from other popular linters. Many of these suggestions exceed the scope of just the configuration file, especially Engine, and at least one might even call for a separate file, but I wanted this to be a jumping off point for discussion.

Remove support for the XML format config file. See Issue #354.

Add Engine/Language with version. I believe that CFLint only officially supports ACF currently. I think that having the ability to define the version of ACF might be useful for some cases. Also, Lucee has become very popular in the CFML community so that could also be an option. Each rule would then need to have engine support notated/integrated, though perhaps with a default. I think most (all?) of the current rules would apply to all of the modern engines, but this could be a way to have rules that suggest using newer language features (e.g. the ModernSyntax rule group). And let's face it, there are still people who are not running on a modern engine.

Allow include/exclude of the severity level instead of just individual rules.

Do rules have an inherent associated group/category? The Rule Groups and Built In Rules pages appear to have them grouped in some way. Also, some output formats have category, though I'm not sure it's used for anything. That could be another way to pre-filter.

An ignore pattern would be useful when linting directories. Some other linters have this in a separate file (e.g. .cflintignore) as the *lintrc is generally used for rule configuration.

I am told that there's some degree of support for the below already, but I'll leave it here as I'm not sure of the extent of the support.

Allow additional configuration for particular rules. For example, VAR_TOO_LONG should be able to take a maxLength that overrides the default. I think TSLint does this well.

Change the severity of a particular rule.

Per comment on Issue #352, change excludes to only include code.

Re configuration and exceptions just wondering if there a way to globally mark as exception to a rule?
A use case would be to globally ignore something like “#request.datasource#” rather that add 100's of ignore annotations or disabling the rule.

authors: KamasamaK justinmclean

repo: cflint/CFLint


text:
This is too meta

I'm not a fan of the fact that the gh-pages branch of this repo is housing both the docs site and the master capital-framework component itself.
You get weirdness like:

it depending on itself

an unhelpful description in the Bower registry:

and the README being all about the site, not the master component.

Perhaps we should move the component stuff to the (currently non-existent) master and build the docs site separately in gh-pages?

Would this mean we'd change the default branch of this repo to master? Any ramifications of that?
BTW, good to have you back, @Scotchester. :smiley:

Yes I think we would. I don't foresee any major ramifications.
Good to be back :) Though I've got to go back into my non-CF-projects hole for the rest of the day.

Also: This repo should not list itself as a dep. That's a bug that needs to be fixed ASAP.

I'm way late to this game, but this is very off to me too. I never had considered that this would be used as a dependency and the fact that it's published to Bower at all seems like an accident/holdover from when this repo housed a component.
When this repo is being used as a dependency,  it's primarily for the CFPB specific theme which is also housed in the generator. My suggestion is that we split that off into it's own repo, so that it's not maintained in two places.
This repo does house the "compiled" version of CF, which is difficult to keep up to date. I'm all ears if anyone has a suggestion for how to handle that better.
I'm tagging @cfarm, because she brought this to my attention.
Thoughts @Scotchester @contolini @cfarm?

I wonder if we set up the repo more like Bootstrap's where they have the docs in a sub directory on master and push only docs to gh-pages.
https://gist.github.com/cobyism/4730490
git subtree push --prefix docs origin gh-pages

This repo does house the "compiled" version of CF, which is difficult to keep up to date. I'm all ears if anyone has a suggestion for how to handle that better.

Greenkeeper.io can be used to do automatic PRs when things get out of date.
Although I've just been re-thinking the benefits of having all these modular repos versus one clearly maintained Capital Framework repo with the modules broken up into multiple, modular, clearly labeled LESS/JS files that can be commented out. That's probably throwing out the baby with the bathwater. 🛁

Closed with the completion of Voltrazord.

authors: KimberlyMunoz Scotchester ascott1 contolini himedlooff

repo: cfpb/capital-framework


text:
Multiselect: drop-down arrow is not clickable to close drop-down when max selections is showing

To Reproduce
Steps to reproduce the behavior:

Go to https://www.consumerfinance.gov/about-us/blog/
Click on five items in the "topics" drop-down so the "Reached the maximum of five selections" message.
Click the down arrow icon and see that the drop-down is not closed, as it is before the max is reached.

We talked about making the multiselect a web component, this could be addressed as part of that work

authors: anselmbradford sonnakim

repo: cfpb/design-system


text:
Form explainer copy and link fixes

Changes

Homeownership becomes two words
Other costs changed to Other Costs
Added a little title/caption above the image on Pg 2 of Closing Disclosure

Added in the askCFPB links to CD pgs 4,5 and LE pg 3 (demand feature, security interest, and total interest percentage)
Updated closing services askCFPB link

Review
@cfarm

:+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1: :+1:

authors: cfarm stephanieosan

repo: cfpb/owning-a-home


text:
Address a couple of TODOs in tests

Short description explaining the high-level reason for the pull request
Changes

updated several tests in loan-comparison-api_test.js

Testing

grunt test

Review

@amymok

Checklist

[x] Changes are limited to a single goal (no scope creep)
[x] Code can be automatically merged (no conflicts)
[x] Code follows the standards laid out in the front end playbook
[x] Passes all existing automated tests

Looks good to me!

authors: amymok fna


text:
TMD 2.5 to TMD 3.0 question

This is part of JOSS review and related to Issue 11.
This is testing a function call (tmd_extract_HC()) used in a common tidal preparation for ROMS (otps2frc_v5.m). I get that u_phase and uPh are not pseudo-equivalent. Is there a units mismatch going on?
filename='/Users/lnferris/TMD_Matlab_Toolbox_v2.5-master/TMD/DATA/Model_tpxo7.2';
[z_amp,z_phase,Depth,conList]=tmd_extract_HC(filename,lat,lon,'z',[]);
[u_amp,u_phase,~,~]=tmd_extract_HC(filename,lat,lon,'u',[]);

con = 1; % m2 from conList
figure
subplot(3,2,1)
pcolor(lon,lat,squeeze(z_amp(con,:,:)));
shading flat
colorbar
subplot(3,2,2)
pcolor(lon,lat,squeeze(z_phase(con,:,:)));
shading flat
colorbar
subplot(3,2,3)
pcolor(lon,lat,Depth);
shading flat
colorbar
subplot(3,2,4)
pcolor(lon,lat,squeeze(u_amp(con,:,:))./100);  %cm/s to m/s
shading flat
colorbar
subplot(3,2,5)
pcolor(lon,lat,squeeze(u_phase(con,:,:)));
shading flat
colorbar

%% TMD 3.0

addpath(genpath('/Users/lnferris/Desktop/Tide-Model-Driver-main'));
filename = '/Users/lnferris/Desktop/TPXO9_atlas_v5.nc';
conList = tmd_conlist(filename);
hAm = tmd_interp(filename,'hAm',lat,lon);
hPh = tmd_interp(filename,'hPh',lat,lon);
uAm = tmd_interp(filename,'uAm',lat,lon);
uPh = tmd_interp(filename,'uPh',lat,lon);
wct = tmd_interp(filename,'wct',lat,lon);

con = 4; % m2 from conList
figure
subplot(3,2,1)
pcolor(lon,lat,squeeze(hAm(:,:,con)));
shading flat
colorbar
subplot(3,2,2)
pcolor(lon,lat,squeeze(hPh(:,:,con)));
shading flat
colorbar
subplot(3,2,3)
pcolor(lon,lat,wct);
shading flat
colorbar
subplot(3,2,4)
pcolor(lon,lat,squeeze(uAm(:,:,con)));
shading flat
colorbar
subplot(3,2,5)
pcolor(lon,lat,squeeze(uPh(:,:,con)));
shading flat
colorbar

Also this isn't an issue, but the TMD 3.0 code block is 3x faster; nice job.

@lnferris I don't have quite enough to replicate your code, and I'm not sure what difference you're seeing between the two results. Can you please upload the resulting figures or describe the differences you're seeing?

@lnferris Can you respond here?

lat.csv
lon.csv

Ahh, okay, so it's just a matter of radians vs degrees. I see now that I hadn't included the angle units in the documentation.
I've just updated all the documentation to be clear that the angle units are radians. Thanks for catching this.

Can you mention this in your table because a subtle units change has the potential to break people's tools? I agree that radians is better but had to dig to find this difference.

@chadagreene you can close this issue after editing the table, I have nothing more on this issue.

Done.

authors: chadagreene kthyng lnferris

repo: chadagreene/Tide-Model-Driver


text:
fix: typo

提示：解决了什么问题，也可以讲下理由。

thx


text:
Add pLDDT to pdb files

Description
This PR adds per-atom pLDDT scores to B-factor column in output PDB files.
pLDDT scores are in [0,100] range, with 100 indicating perfect predicted LDDT (high model confidence).

looks great, thx @jacquesboitreaud

authors: arogozhnikov jacquesboitreaud

repo: chaidiscovery/chai-lab


text:
v4.0.5 contains pure ES2015 modules

$ grep version packages/postcss-tone-vars/node_modules/type-detect/package.json
  "version": "4.0.5"
$ grep export packages/postcss-tone-vars/node_modules/type-detect/index.js
export default function typeDetect(obj) {

Feels like it requires rebuild ;-(

Looks like it was already fixed in 7900eaf5c8568edf2557810355544f49a064dd65
My bad, I'll reinstall all the things. Thank you!

Btw yes index.js contains export default... but if you run the main of package.json is not index.js
Look at print:

authors: vieiralucas zxqfox

repo: chaijs/type-detect


text:
MultiprocessingIterator Deadlock

I am new to chainer and trying to do a custom loop with MultiprocessingIterator.
Reproduce on Ubuntu 16.04 and Chainer version 2.0
import chainer
import numpy as np

dataset = np.ones((10000, 1000))
loader = chainer.iterators.MultiprocessIterator(
                dataset, 32, n_processes=6,
                shuffle=True, repeat=True)

while loader.epoch < 1:
    x = loader.next()
print('test')
loader.finalize() # hang at worker.join() (randomly, very frequently)

Thank you for reporting!

@niboshi Could you try CuPy 1.0.1 as well to see if this problem is related to #3075?

@delta2323 I tested in these combinations. This problem is reproduced in both conditions.

Chainer v2.0.2 (v2) - CuPy v1.0.2 (v1)
Chainer v3.0.0b1 (master) - CuPy v2.0.0b1 (master)

Thank you. The deadlock of #3075 occurred with the combination of v2.0.1 and v2.0.0b1 though. Could you try that if you can afford to do that?

Thank you. I will ask them to try master branches for both modules.

@thuyen I tested your code with Chainer v3.0.0rc1. The deadlock does not occur.
Maybe, This bug was fixed by #3076.
Cloud you check on your environment?

@okuta
Ah yes, this must have been solved, because #3076 includes a test case to check for this issue.
(https://github.com/chainer/chainer/pull/3076/files#diff-f4b0901816a48909da3e084290dbb1fcR394)

OK, I close this Issue.

authors: delta2323 niboshi okuta thuyen

repo: chainer/chainer


text:
[backport] test: Skip multiprocess interrupt tests

This PR is a backport of #3393

LGTM!

authors: niboshi okuta


text:
[backport] adjust tolerance for F.linear_interpolate double_backward tests

Backport of #3944

LGTM!

authors: hvy kmaehashi


text:
Rewrite ChainerX math tests

Part of #6401.

jenkins, test this please.

@niboshi do you have comments on this PR?

Jenkins CI test (for commit 247b2f947f30b0751ede4f1103039b0c50d42179, target branch master) failed with status FAILURE.
(For contributors, please wait until the reviewer confirms the details of the error.)

CI failures seem unrelated. LGTM!

authors: asi1024 chainer-ci hvy


text:
Add ChainerX build option to use cuDNN from CuPy installation

Fixes #7408
Requires ~#7441~ and ~https://github.com/cupy/cupy/pull/2245~
If CHAINERX_CUDNN_USE_CUPY (either environment variable or cmake -D option) is set, cmake script tries to find installed cupy package and use cudnn.h and libcudnn.so.<ver> in its installation.

Just leaving a record that I updated the title to reflect PR dependencies.

PTAL

PTAL

LGTM. Jenkins, test this please.

Jenkins CI test (for commit 5e3453f0f8e974aba7c976b4f83394016b7b6da8, target branch master) failed with status FAILURE.

Jenkins failure seems unrelated to this PR. LGTM.

authors: asi1024 chainer-ci hvy niboshi


text:
metallb setup fails in Kind action

See here. This probably started failing on ubuntu-latest (there is a runner image update happening) due to some docker upgrade?
Error from server (parsing address pool config: invalid CIDR "fc00:f853:ccd:e793::/64.255.1-fc00:f853:ccd:e793::/64.255.250" in pool "config": invalid IP range "fc00:f853:ccd:e793::/64.255.1-fc00:f853:ccd:e793::/64.255.250": invalid start IP "fc00:f853:ccd:e793::/64.255.1"): error when creating "./metallb-crds.yaml": admission webhook "ipaddresspoolvalidationwebhook.metallb.io" denied the request: parsing address pool config: invalid CIDR "fc00:f853:ccd:e793::/64.255.1-fc00:f853:ccd:e793::/64.255.250" in pool "config": invalid IP range "fc00:f853:ccd:e793::/64.255.1-fc00:f853:ccd:e793::/64.255.250": invalid start IP "fc00:f853:ccd:e793::/64.255.1"

Getting the net config is not valid anymore as it needs to use the second index.
The following should do the trick (tested locally), not sure about compatibility across envs:
"$(docker network inspect kind -f '{{.IPAM.Config}}' |  grep -Po '(\d+\.){3}\d+' | head -n 1 | cut -d '.' -f1,2)"

@skonto tested on MacOS, does not work there:
grep: invalid option -- P

But should not be relevant, as this is only used on GH actions anyway. Alternative could be to use jq (which is included in the GH runner images)
network=$(docker network inspect kind | jq -r '.[0].IPAM.Config[] | select(.Subnet | test("^[0-9]+\\.")) | .Subnet' | cut -d '.' -f1,2)

Tested here.
@skonto do you want to PR your changes to fix this?

-P is for gnu grep. Yeah I thought about jq bu wast not sure if all runner images have it, as probably the repo is used elsewhere, besides Serving. It seems they have it with some version diff.

Also this should work:
docker network inspect kind -f '{{json .}}' | jq '.IPAM.Config.[].Subnet | select(. | contains("::") | not)' |  cut -d '.' -f1,2

authors: ReToCode skonto

repo: chainguard-dev/actions


text:
无法运行，提示：Error: probe docker rootfs: stat /host/var/lib/docker: no such file or directory

按照教程，下载run.sh，然后 ./run.sh scan image dockerd:nginx:latest
Error: probe docker rootfs: stat /host/var/lib/docker: no such file or directory
/var/lib/docker 目录是存在的，只不过是软连接

新版本针对这种情况做了一定的修复，会尝试解析 /data2/docker 这个路径，可以用新版本试试

新版本针对这种情况做了一定的修复，会尝试解析 /data2/docker 这个路径，可以用新版本试试

docker 镜像没改吧？我按照readme里的方法运行run.sh，还是一样的错误。

需要更新一下镜像，版本是 v2.1.0

原来的参数  --docker-data-root 不支持了吗？

这个问题应该修复了，请确认一下你使用的镜像是不是最新版本。(registry.veinmind.tech镜像同步暂时有些问题，以dockerhub镜像为主）。 @sevck

authors: DVKunion d1nfinite sevck wangdawai

repo: chaitin/veinmind-tools


text:
Usage example code execution error

Hi Everyone,
I was trying to execute this 2nd code in usage section on my local after installing chalk, just to check the use cases:
// ES2015 tagged template literal
log(chalk`
CPU: {red ${cpu.totalPercent}%}
RAM: {green ${ram.used / ram.total * 100}%}
DISK: {rgb(255,131,0) ${disk.used / disk.total * 100}%}
`);

and got an error in cli like:
ReferenceError: cpu is not defined

Though its a minor issue, but I think example codes should have been error free. I hope you will agree with me.
Regards!

F.Y.I.
I fixed this issue on my local like:
// ES2015 tagged template literal
const totalPercent = 95;
const ramPercent = 60;
const diskPercent = 80;
log(chalk`
CPU: {red ${totalPercent}%}
RAM: {green ${ramPercent}%}
DISK: {rgb(255,131,0) ${diskPercent}%}
`);

Hi - we expect the average user can deduce the usage of the library via the examples. I don't think it's fair to expect a copy-paste-able example that is only a few lines long, especially when it's clear cpu doesn't exist in the scope of the example.

authors: Qix- palashmon

repo: chalk/chalk


text:
Incorrect types for chalk in tagged template literal form

I am using chalk to do some logging and I noticed this issue.
chalk`{black.bold  Worker:${process.pid}: } {blue.bold job received}: ${job.id}`

In this case I am giving chalk two numbers instead of strings.
Typescript complains about this because chalk's tagged template literal form is defined as
(text: TemplateStringsArray, ...placeholders: string[]): string;

In my case placeholders contains numbers.
Now I could fix this by doing
chalk`{black.bold  Worker:${`${process.pid}`}: } {blue.bold job received}: ${`${job.id}`}`

but that feels wrong.
Ideally it would be some type union of things easily parsed to string (||etc etc)
(text: TemplateStringsArray, ...placeholders: ParseableToString[]): string;

Yeah agreed, this is wrong. Can someone from the typescript community submit a fix? I don't know enough of it.

The types you can interpolate are any type. We don't enforce anything.

The typing enforces that the values you interpolate are strings.
index.d.ts:30 as seen above:
(text: TemplateStringsArray, ...placeholders: string[]): string;
Unless I am mistaken this line defines the tagged template literal.
where text will be your broken up input string around each ${} and placeholders is an array of inputs that the user is trying to interpolate.
ie:
chalk`part1 ${foo} part2`

Would be chalk( ["part1 ", " part2"], [foo] )
If foo was anything other than a string, Typescript will complain saying "Argument  is not assignable to type string".

And what I'm saying is we don't care what the placeholder types are...

Shall I submit a fix then with type any?

Sure, but I'd like to get a confirmation that any is the correct thing to do here. Like I said, I have no idea how Typescript types work.

Yes, it should be any or rather unknown would be even better.

Ohh, sorry, reference from 317 is invalid (should be to 318 not to this 314). I fixed it but reference will stay :-\

authors: Qix- langpavel sindresorhus vanbujm


text:
Doesn't Identify Calls Through Actix Route

Neat extension, I went to test it on some stuff I had lying around and noticed that it didn't identify functions that were called as routes for Actix. I have a repo that I was using while working through Zero to Production in Rust that I used to test.
I found that when looking at the graph for the entire src folder, it shows that my functions for routes are never called:

When checking the call hierarchy in VS Code, it correctly shows that this health_check function is called by run, which is called by spawn_app and main:

Source is here for reference: https://github.com/Torsitano/zero-to-rust/blob/main/src/routes/health_check.rs

Thank you for providing such a detailed report. I use the vscode.provideOutgoingCalls command to get the outgoing calls, and it seems it's because health_check is not directly called by run, so it's not included. I don't know how VS Code gets that, will need some time to figure out how to fix it.

This is fixed in v0.1.2, please update the extension and check it out.

authors: Torsitano chanhx

repo: chanhx/crabviz


text:
Wait with push to master until PR is updated

After force pushing to the PR branch we wait until we receive the GitHub event that the commit for the PR has changed before pushing to master. If this event takes too long to arrive we push to master anyway.
Resolves #196

I take it #245 did not solve the problem then?

@OpsBotPrime merge

Pull request approved for merge by @musicismyalibi, rebasing now.

Rebased as e0c169e7992c3304912a85ea341e08cf184356b8, waiting for CI …

CI job :yellow_circle: started.

authors: OpsBotPrime musicismyalibi ruuda

repo: channable/hoff


text:
feat(forms): export form-related hook

Summary

외부에서 커스텀한 폼을 만들 때, FormControlContext 에 접근할 수 있도록 관련된 hook들을 export 합니다.
Details

없음
Browser Compatibility
OS / Engine 호환성을 반드시 확인해주세요.
Windows

[ ] Chrome - Blink
[ ] Edge - Blink
[ ] Firefox - Gecko (Option)

macOS

[ ] Chrome - Blink
[ ] Edge - Blink
[ ] Safari - WebKit
[ ] Firefox - Gecko (Option)

References

없음

:tada: This PR is included in version 1.0.0-next-v1.89 :tada:
The release is available on:

npm package (@next-v1 dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

authors: ch-builder sungik-choi

repo: channel-io/bezier-react


text:
[Spike] Investigate authorization roles in auth0

Need

Stanford curators need to revise/reupload datasets they dont own

Approach
A.)

DB snapshot
update owner of all datasets (to be stanford)
revise dataset
transfer ownership back based on db snapshot

B.)

Create superusers via auth0
create for superuser status when checking dataset owner

@ebezzi fixed smoke tests!

The spike has been implemented as part of this ticket: https://app.zenhub.com/workspaces/single-cell-5e2a191dad828d52cc78b028/issues/chanzuckerberg/single-cell-data-portal/1368. Moving this to Done.

authors: MDunitz ebezzi tihuan

repo: chanzuckerberg/single-cell-data-portal