[Bug]: Websockets upgrade request: HTTP 431: Request Header Fields Too Large with big cookies

Environment

VerneMQ Version: vernemq/vernemq:latest
OS: docker debian:11-slim
Erlang/OTP version (if building from source):
Cluster size/standalone: standalone

Current Behavior
I am trying to connect to verne broker from the browser via websocket using mqtt.js. Cookies are added to the Upgrade request by the browser, and these cookies are large. Connection attempt is refused with HTTP error 431. Once I delete the cookies via browser dev tools, connection succeeds.
Expected behaviour

Connection succeeds regardless of the cookie size, OR
Behavior and limit configuration is documented here

Configuration, logs, error output, etc.
verne config:

services:
  vernemq:
    image: vernemq/vernemq
    container_name: vernemq
    environment:
      - DOCKER_VERNEMQ_ACCEPT_EULA=yes
      - DOCKER_VERNEMQ_ALLOW_ANONYMOUS=on
    ports:
      - "1883:1883"
      - "8080:8080"
    restart: unless-stopped

request:

curl "ws://localhost:8080/mqtt" -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:123.0) Gecko/20100101 Firefox/123.0" -H "Accept: */*" -H "Accept-Language: en-US,en;q=0.5" -H "Accept-Encoding: gzip, deflate, br" -H "Sec-WebSocket-Version: 13" -H "Origin: http://localhost:5173" -H "Sec-WebSocket-Protocol: mqtt" -H "Sec-WebSocket-Extensions: permessage-deflate" -H "Sec-WebSocket-Key: sVLbEJyDhg7SuzDBjLWksQ==" -H "Connection: keep-alive, Upgrade" -H "Cookie: .AspNetCore.Cookies=chunks-2; .AspNetCore.CookiesC1=CfDJ8GvEDUoW6SJBqGmcn6iBgKXnzqDL03AnFNEfL7kbI_zuDmOi_0QTknU3zqBmN4wFoWFhoFS2T9SvqdSBlkgLLZaCVHPeqvu_aTjZORkuRNV79wb2jOGw0E3Cdj9xEzN_lrkqzQFuywX1rKxgdW7YAJyxqjqZ1IX1Ugn53z2NeB9C4nnsFSGSHQ-_s7eqtoJ7uZIL4bNJZu87DKg9ul5wNPGGbWXjOWM2TI8A0QC31bobmySUcRDFuvBiLCJ4VjjEQ5s5AB2L_Kg7nHbXNpjz1ArTEmarC6HcuZWNVVWWqks9flHKYTIxOOVr10BsLCRUaRVF5qyu9XZyeKgNffsu0X89nR1hHqbBEP-yKkbI61n-H4oB5LZko_juWOpz0npwE51s1IOpLRzTjdXHByoi3pRBcTAmOdh8Macb-mYQbNLPzF6cW_upl6QU07MhowBbJ5VmbRPK9W5Qp23M8af0_js9yK1oMaATMFFL-6TIWeqO0ewi0Wc9lW2mmJEY31bvov9XyD9lX3YZgBNARnwf1N4RH7nkD52aJ_Va7XSXq1751rX0cFQPzSh2ejMBq_3qEbb4zYyysebuoylx-9EhLpywRiyqMa88fcKE4P4s5ODlNpwekGov_CGsNmLHZTE2eZc4NGtaaj2aZsuzLEM62oaHFIFTdj2t4aop5fzJellwJW7yZh2QcRyUthCSARdpjjxk7wgvPcF0IPihZ3kbFs74-AWOzFdRL-Qb2agifDCsy0fcdFoLFwWjre8aYxVgCdgitwIdFf4wYxbC2mMqOEhDYYY57dizckdYV3wZ06xv1fRgX1qpdgWXctuPbFZpy3wmpeGNDIQqYxlOxyWb3vJfIAp2T4Buz0kIfeblsVI7p7zyBaWarkLxyPhEYfFgUyG0Dc_YT7yUW5N-ZKrg46wcSsdfyt2npAMfPv0aL2Go4Ds9eGOlyvaw-ERtrk8Kphs4RPaOAgNCh-kHa_fpTDk5SBuFMIczh5MIB8r5kYspXdtocLhrfEFCRbTToaRIWiJ4JaSOsZsjAMMAEnIh6Ixc3o6JhBNt4yxkuAFlHs0h-ShFfOe7Fhs3NHeoL5w8htev6MsC5ogMFBak-zoErlFh7WohQF2HCrQJvgFoD7V1_qXPAlvoZ5jDmXAdvMjMoA59Mn-J7ijcsK06EpdEewwUEp9G0g3xpqD5YTpZGWzqnNYJ9SLehznKSmhBWdTnbbSHTIrwobVN3IcEPRQYGIRJY9w-BtfPPhag6_nqHc6mzamdacbHhD7vk-DLFvWNRMZkoyu3TM06YoME3zIzka8qX5kHRtZ35jpLaqsOGvPlw3VLVV5vqTm6AyLb1fHKC09Y5-E03GEIHtx1TnBIw3CkANLNrymxqIjuP50RiMEFDLppOMsga0Jk_SOufrz493HoFRQ6-keAgC32NvvrevQmeSbos2rK4zi7z-8gNDyABEV9yXWo-TDyZp-wq7p-8aJjAKAViDtE3inD2hEBeneCUA42rMiBYeEKWH5a7wQRS99oJRzxShXPwN6zhlwL6b6UboJbnlqSlRVbd2WutSA3jgfwjfOdrHvLuA7lh7F3XrlT9phcLJPXjEgMdwmC7a23UvZfXohPPc8mrENc5mZw94g49XdtV8EL4rd5IjQTCJ88tA7B_stkAM2_apN5xcjcxHgUIZvsQt8l0qjoG9cBmeqiKrjoeRwVpk0jLrP0kbkuuypr59z9sIneTrX6oWlLfyJPh_e0haXFvCqJNjr7BAuKRH1Gje3pfP71jQb2HqIeT8zB8DufXFPUofWGq1_G2pkcVuVrSRiNNolzkeHkSGsohv_jJCqdelJ0H7UFl5KcFmsoddblMDA4sflYdqwMw64GavnywxCiE8-X1FMyPV_R8hSr6Bfl1VCHOhVaiHp4mJbvmixofjRSYyRA8OcW73BlCszJ6HxEj_NOqtU-eOhW98SwFm8XE1-BZYHQZIekNl3omlX_NvxCYiotqYPiclFsJenpkBBD3ibqNf_yUOlGSV6dqGCS6D2ml0yC8xk6P6nQ9_UmBvRoGlyiZUpVL13pyVNIIS-uerw9Mq4Kj63gcOFTwzCqBrOsX-SaYhDUtkj-v9Fp8h3oFMGmYa0F9GtcKrkuD5yGEGMQIcHKl9EtK8uiOAojAG1g-bSGfWoyyL1SLdfomVhQHXEcmf2zRiTOoTCSHrInPj3ijHDFqhX_5oXkZj42--pd4TxpwEtsupmLPBLaf3xsiUDWgdZgjm74FvYCQhN2zA39bWxBeO468ST8lk8f0xPoxOX9KjnNMs44wpByPWlHqvPjGGGpxiW33tA3hPr13LXQsGEPeUa0-fqYLxmIfMguEAXQQVmzxlPq-GxuRmzZDc6_IqR0_T-5nhx6vqRveY5STJmfMdDZcgwzKuAnvk6be2Uz4T-Olq-GdVZ9FLatHg_8EuM3PIjKvu1JC3aEH9bUhWp8qjicwlODdK__SeWl4YGqW3VtA05ST64ZdJjdh8oHH719pBzoWCOLPvnZPN1DrTWdax6_4UCddAJAEoL_8BKkuE5V1RFJ8TZmAPu6zophtg9KGs4Js_gl6rxjd9PG-mdPqjENikfdISCY3RdguagTgQIUvgb2kDAmw8p0l815Qd073wwltDa4sQD_0ihr02mOY3RXdX0wFCiOFyCHqeMhXIUIOwTvgvc1_kOcVAjX-IbF8UG_Gxed9uiJsV5i3kGPQNF0eKDrBj0Oys_czXP1GNwT-Px6KIquCM6BIE85Q_Q8Z0t6WcUZ4gw6lYsTccrwX0YG8fw8JsFV-9ajYPUWo5L3gkU6HHs6CzTXTXQJFkZj594VOr0NKN7S4apCMwcups4lLIvbaWddxcws-zqZwVK3CHbB7GFwif8bvrRD6SGvDe5yh3_KFxf8sly1JlFI43fcy8xVwfnMDuKhZKDD5ns_iZsP-n_6kPK2aEnQzNa0qWtSOovSH4wQU3pakEB4bo5U6vsk-B7wqynN9WFO-KA5x6jDAxmjvcoVYWKC2dg8vhomrryUy_FfnEz15ZkLGFILeR3WxkRKuGBGd3p2Ho3mA7xNpqSb9U0INP1qoNXFwngGqUumrD4bXp9nR3W3wTT7Bre4YyuNZzbExE5gTMt9Ip2osOiQ38ACfpakA45ZrPtsPUfMDT0EnaaNMdeky69v6OaUqrCBzZAn289mG3gXt4rQiIJkm5mxTqG8-uO3GdqjWGRxG21nUDHWMKCWFgGutG2eLD3XyuqyjE1M2BpA4GgAe8VWYVAQsuwdi13w535TClw6fq5hjkBFYVBAPrpT7HZb2l-06UN_8PzJwhA_muqb99zr5EpPcMxQzQftQ5I83VHXHl3pTSogaRoxjNKS0V-ob-usRyf9E0uE7oxa8-SqMFw3nvB4PzQskr0LcnDct3zVg9Qjd0tfUeoGTEQBKUA9wtsFjaaQSsbY9fTB1ZNV7wXwB2R0wAplGLt67y31e3atJpCDmfUp9IFakXhCgXEd4W7cUXcXGtOjhGhzH67U2W9YrmUff5SSLQpkXIxcC3z4oBjdQlnWToDgf5oDsKIxHlE0LTRj5qdXHyfBQbjMSZwGjXttmLK9JJsaNOuvZV67DNAqQcsrf2iq9S0NavnfpyBd3cyBLsw4oaOPOck8LHoiKGGpnZN23Koiu-br7oKDUue5tWh6wN5gEYavWhH6Gn5XgiCDiRytQzd-8HyD541umUsxw-dt73TqrbrmKx9fcZ9dmMN9Ae5AAuM3Z2SV0m033IttNw_rDBXdtMGc7IQhoFlKNgRJv8UBV5SMDGPJUQtxRTV5Fl2RaBqjIVxOoe6ufL2BJGMzzvDl56rwxf1M5eNfMcac60N8QlGgFk0M-gtxdAJ8we3Zi6EeuvTVGs7LQxee3_s9baF1Gtap8mEvw-PfhRbX8nOOxGVRDzVcq-mTtsxySdZnk4r5fK1nwdoexOHIIxb5yi4TxIP7dKLy7l86y_om1XpyqTA2qhlFOrr; .AspNetCore.CookiesC2=8v8Xq1izSq4MftPulKW7f_y1pQfsh01YXl3FyIqgrlM_ltwr4PrW5u9Fg81En7nlRJBNHJQ7q6IDQUDLJI0Cme7pM3SyKkZhuBs2K2SKXwqCyILhmfrInOnbxcRTSW-yc668iNE4IHdJPsJRpH8lViCr70JRMiPwlWT3UuxMp2Yh-ksHmfmxLXV86r-Rrp0865O3ms8OlrZe62Z9A8B1DunPXPQEvxd1Wp9g3fzJic3WK3PTFQUKPeG-3u3LEckgEbeaRXBzRrRRzx-mZhWMhxScJwqrc92HtSuXGXTvbG6NkWvngn0T0DKUWv16DSSrjwJDbwxoNVaP3-r17qa5OeziSsOGSCmB-F4h1ekROf9B6gRcpa_GhhU4ypRCzQupESDMr17M-pGQjIg06iVYS5RE1ccC_DRQhyxUGZ2Ydsz4uSsgSOui_Xc13XrleC8tbfEv8knEG54LbBivf6ZKZSD1ejdfsGYiYbwXUH4GP4af4WtwEUUpTpvOvckquoWLAIDOx6fKQfD4DHOpULvDSPrVv7zHtvxzUF18Et4XzdO01BDHXHudlexZbGU9AbvpJsXp7XKGuoRIPXUub_Be70do9EFw0Rqw1l7xVweSraMdU3YBqEanWwsG1kHKjgY4R0062qs26k9NFgbFB8XDzlZwS5XP-EE98JhL5qcWVdCofZJ1F11vsz1INVdQm1GQfWhWC7MBpUr3atKwhsnHcJtQkTn422_Ms3Ta4zbmzUVTxd5sgMqtyk0eC4zBcXI76VPzVIDx4uW-BY7NOloAdN9iWWfMheodWmovzs3ta9mihRw4hwwUNGseIUNMfQbH-CahPAaZgfM7DoZjAhSyEnAmZ6ztyDy8rbrmnhT30exzyAyUMSMiaHqy28CWmpbLUFD8vDmp8geztPY0LJ3g0CjKp8hij7Nzw-UVvfnoByfsQX29r8h4Wn9kExRzzwsUZ3rvVpW728nAyfQvnExcz5QuHAg505b7RTVx5E7GuO94NTIHv0os8aYZMDuj1i0G8lvNIo6fuHjYUZWJJ_ub7woam4-eDtUv_gxuKM_EV_UN5sAj5FUuHOcsglC44rRT959-mYsmWHtrZ65XvIai3CBX86kx7ZVqlxDIM9Puer4zzUOA0r7bDBhGcuMQ_JbLnXh4b2Jt14QDqeKhj3tljx0cE0rTW_uHZNtdNmLGBJ5IknKAV9X-urguH9CKN7cvOiPNz3gswx5a0YX0Mj9AxXyFwE-1n6q7iEQHDgjG0rhzGhfxCtVQtzY3ogRFoKoOTHZhjqOgmkcHONpSTMDijVU3ZcMWh8BWwT_KNd1DcOww0RmPK5cFwyIjQ4rwhlPd4hnEpZmfACyPjFCNnsc-2U0fINMjfEnAtXmZ_pYU7G_6XKpfqhy_ozrda7ovCFP4upZ0n2_azttAZVggsqd5dOcCOn4VcNpLUnjI9NQKBLo2oXDh9ZelNa-reSXBgAy7VJJBvfFQECO-rIAD28F3D21ZkyEbj2-eq6WQaQjf8ZRYJNWimsJl-PS5VwiHHeyfDm5CcZCzCKiEo8lUyngU1DKUzbuj0F347CYtfk0bD73f-9BQBLxb018Sx2fjVkrKi3Ytn3sQDKV7pMpshHp6XIeknCAvjOj4XGRCihee-jFXz-a12YfEL9lvGjf0ZXLYdrpZhTt8OncOrHGMukVWgDDXH6b7rbiSyQ6GZPYCJyz8wuJ0JKoYkHq7Rn4gZysV9-cZMXkwphSuoCHXjl5huXQFBJZA4iI8Yy6vilmZkC0DKBe9MG6RbOXS5OcltfPUXvEU1ZQF02d9ZEiNkJO3ZHhZENYQpOuFgZc6l7xiJcQsoI6LBWN7jLYuIVtzdddIoEk8m7avQqSpP24YvYa7ClHF9nzYTXj6ha2sjrfMkmgcohYXHPmf18mMVBsiOaVEM8VJsvA440lTj_dHPNnY4WpdAIMnKlyKkPss_E5m07xhsmrdo7APR996el1GBLYeufgSiITfWgM7gOTLxhKeqewboFFnwmxUy7qSmDo98ozZQ1ZW-ZDEDGhWyAYxlHf8zj8aYPUACiqimjaU1TiSvav084u5_Pbf-G4f5RRDHJR_3ja9ZV_4sOTTbcjjQUB9YKMiptynm2fIjqEETgq_tGKg36J8w--Op3IePMIGJ_-znMuhiFu_O2RvPR1LxZ_oPSbXfn0ZY6sahNjfhVZrLG8mEt1jOc6oTuy7s7KQfdHh0F0pARJDd2wcCwffe34rxcLrh97_NnzGpWC7vUu0vZxask9gJgagFsLAiJWfvaDDNtDZka58gAT2ZMay1j0opwnViM98UfbYtdCxTK3mkMkajmywip47WZzUzH4chqAj1Kgj2ze7RneXXnICt63hfOjsLI-v18E_jDQRAPnvuZYlMSZaAbUhl_MYLfIGdiItFiiEL9egxQoCSVqzfba5wLaJXaW5DmmUWV-ETxx5oSYOd2gQ9lhRZJRdo9grOIq0kpGk8T23V1l4vjmIWgv-qX2fnHbh5zB_oP43v1P2zW2ZY4ugsdc3Fpct0CJ1KWi5DNawmQuAVrKdACtGWzoOzQ_zDZq_OivMspvUtyA5xfwMau5MpGoM2s6zoHgZDWOE31Xi2lxnD4vDTxGVpbGyLdZravqQHzYewjYmLkWoWJp6bS3wpqfyL3TcLJuesXR9mEilLCv0dtpV_rkS_-WPVStVUuALeuS71JnMbRZZWuPtTYL4I27syLcZv48Jwyi16keWlfvQfS1g5ePLxhm2aI-Wi5FWK9yp2HMab2B8b5uExQ3Omr1vDPatEY0aUQZKaRhrQYg" -H "Sec-Fetch-Dest: empty" -H "Sec-Fetch-Mode: websocket" -H "Sec-Fetch-Site: same-site" -H "Pragma: no-cache" -H "Cache-Control: no-cache" -H "Upgrade: websocket"

response:

HTTP/1.1 431 Request Header Fields Too Large
connection: close
content-length: 0

Code of Conduct

[X] I agree to follow the VerneMQ's Code of Conduct

@DomasM Thanks. Can you try setting max_request_line_length in vernemq.conf?
listener.tcp.default.max_request_line_length=16500 (whatever length you might seem to need)
Set this for your named listener where you'll need it. (adapt default to your listener name)

👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

@ioolkos Thank you for help. I'm not sure what's my listener name, but anyway vernemq would not start with such setting, saying that it does not exist and suggesting listener.http.default.max_request_line_length, which I tried but it seems that did not change anything in actual behaviour, i.e. still 431.
vernemq  | 2024-03-15T11:42:36.795012+00:00 [error] You've tried to set listener.tcp.default.max_request_line_length, but there is no setting with that name.
vernemq  | 2024-03-15T11:42:36.795098+00:00 [error] Did you mean one of these?
vernemq  | 2024-03-15T11:42:36.891103+00:00 [error] listener.http.$name.max_request_line_length
vernemq  | 2024-03-15T11:42:36.891199+00:00 [error] listener.https.$name.max_request_line_length
vernemq  | 2024-03-15T11:42:36.891270+00:00 [error] listener.tcp.$name.max_connection_lifetime
vernemq  | 2024-03-15T11:42:36.893026+00:00 [error] Error generating configuration in phase transform_datatypes
vernemq  | 2024-03-15T11:42:36.893124+00:00 [error] Conf file attempted to set unknown variable: listener.tcp.default.max_request_line_length
vernemq exited with code 0

@DomasM Thanks a lot for testing!
The config is obviously only for HTTP listeners, sorry about that.
There's additional options for Cowboy/Ranch connections:
https://github.com/ninenines/cowboy/blob/3ea8395eb8f53a57acb5d3c00b99c70296e7cdbd/doc/src/manual/cowboy_http.asciidoc#L31
Those are currently not exposed in the vernemq.conf file like max_request_line_length.
A workaround is to update the max_header_value_length option dynamically in a VerneMQ shell.
Example for a HTTP listener running on <IP_ADDRESS>:8888. The listener does not have to be restarted, it is updated live:
Opts = ranch:get_protocol_options({{127,0,0,1}, 8888}).
NewOpts = maps:put(max_header_value_length, 8192, Opts).
ranch:set_protocol_options({{127,0,0,1}, 8888}, NewOpts).

You could at least use this to test whether this really is about that specific setting. The default value for max_header_value_length is 4096.

👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

@ioolkos Thank you again. I tried as suggested and while setting cowboy options seems to work, further requests still end with 431.
Additionally, as you can see initial max_header_value_length is 8192, while my cookie size is about 6700, so it should still pass?
https://github.com/ninenines/cowboy/blob/3ea8395eb8f53a57acb5d3c00b99c70296e7cdbd/src/cowboy_http.erl#L677
Opts = ranch:get_protocol_options({{127,0,0,1}, 8888}).
#{connection_type => supervisor,
  env =>
      #{dispatch =>
            [{'_',[],
                  [{[<<"metrics">>],[],vmq_metrics_http,[]},
                   {[<<"api">>,<<"v1">>,'...'],[],vmq_http_mgmt_api,[]},
                   {[<<"status.json">>],[],vmq_status_http,[]},
                   {[<<"status">>],
                    [],cowboy_static,
                    {priv_file,vmq_server,"static/index.html"}},
                   {[<<"status">>,'...'],
                    [],cowboy_static,
                    {priv_dir,vmq_server,"static"}},
                   {[<<"health">>],[],vmq_health_http,[]},
                   {[<<"api">>,<<"v2">>,command],[],vmq_http_v2_api,[]},
                   {[<<"restmqtt">>,<<"api">>,<<"v1">>,<<"publish">>],
                    [],vmq_http_pub,
                    [{publish_fun,#Fun<vmq_reg.17.40855500>}]}]}]},
  max_header_value_length => 8192,
  opts =>
      [{max_connections,10000},
       {nr_of_acceptors,10},
       {config_mod,vmq_http_config},
       {config_fun,config},
       {max_request_line_length,63000},
       {http_modules,"[]"},
       {listener_name,"default"},
       {proxy_protocol,false}]}
(VerneMQ@<IP_ADDRESS>)2> NewOpts = maps:put(max_header_value_length, 62999, Opts).
#{connection_type => supervisor,
  env =>
      #{dispatch =>
            [{'_',[],
                  [{[<<"metrics">>],[],vmq_metrics_http,[]},
                   {[<<"api">>,<<"v1">>,'...'],[],vmq_http_mgmt_api,[]},
                   {[<<"status.json">>],[],vmq_status_http,[]},
                   {[<<"status">>],
                    [],cowboy_static,
                    {priv_file,vmq_server,"static/index.html"}},
                   {[<<"status">>,'...'],
                    [],cowboy_static,
                    {priv_dir,vmq_server,"static"}},
                   {[<<"health">>],[],vmq_health_http,[]},
                   {[<<"api">>,<<"v2">>,command],[],vmq_http_v2_api,[]},
                   {[<<"restmqtt">>,<<"api">>,<<"v1">>,<<"publish">>],
                    [],vmq_http_pub,
                    [{publish_fun,#Fun<vmq_reg.17.40855500>}]}]}]},
  max_header_value_length => 62999,
  opts =>
      [{max_connections,10000},
       {nr_of_acceptors,10},
       {config_mod,vmq_http_config},
       {config_fun,config},
       {max_request_line_length,63000},
       {http_modules,"[]"},
       {listener_name,"default"},
       {proxy_protocol,false}]}
(VerneMQ@<IP_ADDRESS>)3> ranch:set_protocol_options({{127,0,0,1}, 8888}, NewOpts).
ok
Opts2 = ranch:get_protocol_options({{127,0,0,1}, 8888}).
#{connection_type => supervisor,
  env =>
      #{dispatch =>
            [{'_',[],
                  [{[<<"metrics">>],[],vmq_metrics_http,[]},
                   {[<<"api">>,<<"v1">>,'...'],[],vmq_http_mgmt_api,[]},
                   {[<<"status.json">>],[],vmq_status_http,[]},
                   {[<<"status">>],
                    [],cowboy_static,
                    {priv_file,vmq_server,"static/index.html"}},
                   {[<<"status">>,'...'],
                    [],cowboy_static,
                    {priv_dir,vmq_server,"static"}},
                   {[<<"health">>],[],vmq_health_http,[]},
                   {[<<"api">>,<<"v2">>,command],[],vmq_http_v2_api,[]},
                   {[<<"restmqtt">>,<<"api">>,<<"v1">>,<<"publish">>],
                    [],vmq_http_pub,
                    [{publish_fun,#Fun<vmq_reg.17.40855500>}]}]}]},
  max_header_value_length => 62999,
  opts =>
      [{max_connections,10000},
       {nr_of_acceptors,10},
       {config_mod,vmq_http_config},
       {config_fun,config},
       {max_request_line_length,63000},
       {http_modules,"[]"},
       {listener_name,"default"},
       {proxy_protocol,false}]}

Hm, okay. What listeners do you have running (vmq-admin listener show), and is port 8888 really where you have that listener running?

👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

I suppose. Tried setting cowboy options for 8080, but it complained.
Opts = ranch:get_protocol_options({{127,0,0,1}, 8080}).
** exception error: bad argument
     in function  ets:lookup_element/3
        called as ets:lookup_element(ranch_server,{proto_opts,{{127,0,0,1},8080}},2)
        *** argument 2: not a key that exists in the table
     in call from ranch_server:get_protocol_options/1 (/opt/vernemq/_build/default/lib/ranch/src/ranch_server.erl, line 168)

$ vmq-admin listener show
+--------+---------+--------------+-------+------------+-----------+--------------+-----------+
| type   | status  | address      | port  | mountpoint | max_conns | active_conns | all_conns |
+--------+---------+--------------+-------+------------+-----------+--------------+-----------+
| http   | running | <IP_ADDRESS>    | 8888  |            | 10000     | 0            | 0         |
+--------+---------+--------------+-------+------------+-----------+--------------+-----------+
| mqtt   | running | <IP_ADDRESS> | 1883  |            | 10000     | 4            | 4         |
+--------+---------+--------------+-------+------------+-----------+--------------+-----------+
| mqttws | running | <IP_ADDRESS> | 8080  |            | 10000     | 0            | 0         |
+--------+---------+--------------+-------+------------+-----------+--------------+-----------+
| http   | running | <IP_ADDRESS> | 8888  |            | 10000     | 0            | 0         |
+--------+---------+--------------+-------+------------+-----------+--------------+-----------+
| vmq    | running | <IP_ADDRESS> | 44053 |            | 10000     | 0            | 0         |
+--------+---------+--------------+-------+------------+-----------+--------------+-----------+

@DomasM were you able to make this work?
Do you think we should expose the max_header_value_length in vernemq.conf? or to re-word the question: do you think the cookie size you used here should be within a "normal" size window?

👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.

Hi, I will be back to work tomorrow. Good catch regarding ip, I saw that
setting from vernrmq.conf has been applied to cowboy, so didn't check any
further.
Rrgarding header size - I think this propery should be exposed, and
possibly different default vale used, as there is very little value added
by broker by limiting cookie size. Cookie might easily come from quite a
different part of the application than mqqt connection initialization, and
cookie size might differ from one user to another, or as time passes, thus
causing seemingly unrelated issues for connection via  websocket.
On Mon, Mar 18, 2024, 15:28 ioolkos @.***> wrote:

@DomasM https://github.com/DomasM were you able to make this work?
Do you think we should expose the max_header_value_length in vernemq.conf?
or to re-word the question: do you think the cookie size you used here
should be within a "normal" size window?
👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker)
requires a paid subscription.
—
Reply to this email directly, view it on GitHub
https://github.com/vernemq/vernemq/issues/2267#issuecomment-2003905579,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADG3FPVOIZUBN32G7XYGHNDYY3TX5AVCNFSM6AAAAABEWSFNFOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBTHEYDKNJXHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@ioolkos I finally got it working by setting max_header_value_length for the correct listener. IP address of the listener changes from run to run, so the steps current solution is:

Modify vernemq.conf file with listener.http.default.max_request_line_length=63000
Run vernemq
Run vmq-admin listener show and notice which ip address and port is used for mqttws listener
Set options for cowboy/ranch with these IP address and port values.

Address = {192,168,32,2}.
Port = 8080.
Opts = ranch:get_protocol_options({Address, Port}).
NewOpts = maps:put(max_header_value_length, 62999, Opts).
ranch:set_protocol_options({Address, Port}, NewOpts).

To have this working more properly maybe some copy-paste from https://github.com/vernemq/vernemq/pull/2161 would be enough to map max_header_value_length property too?

@DomasM yes, same approach. In addition, we'd likely need to grab and apply the setting in vmq_ranch_config module where we set the protocol_opts.

👉 Thank you for supporting VerneMQ: https://github.com/sponsors/vernemq
👉 Using the binary VerneMQ packages commercially (.deb/.rpm/Docker) requires a paid subscription.


Problem

Uhh App expired so please try to give a new one!

Here click to download!

THANKSSSSSSSSSSSSSSSSSSS
I LOVE YOUUUUUUU
I FINALLY DOWNLOADED IT
AND IT'S WORKINGGGGGG
THANKS FOR THE DOWNLOAD LINK!

Message ID: @.***>


Reliable RPCs executed multiple times

Issue
Reliable RPCs may be executed multiple times on the receiving worker.
Workaround
Do not rely on reliable RPCs being executed only once.
Internal Ticket
UNR-1267

This is now fixed in the latest release (0.6.0)


Dev

Merging v006 into main branch

Codecov Report

Merging #58 (1de05f8) into master (4ec59b4) will increase coverage by 12.98%.
The diff coverage is 39.97%.

:exclamation: Current head 1de05f8 differs from pull request most recent head 1a073a2. Consider uploading reports for the commit 1a073a2 to get more accurate results

@@             Coverage Diff             @@
##           master      #58       +/-   ##
===========================================
+ Coverage   22.94%   35.93%   +12.98%
===========================================
  Files          55       57        +2
  Lines       10903    11306      +403
===========================================
+ Hits         2502     4063     +1561
+ Misses       8401     7243     -1158

Impacted Files
Coverage Δ

R/add_biodiversity.R
30.80% <ø> (-0.43%)
:arrow_down:

R/add_constraint_MigClim.R
0.00% <ø> (ø)

R/add_control_bias.R
78.26% <ø> (+78.26%)
:arrow_up:

R/add_latent.R
0.00% <ø> (ø)

R/add_log.R
0.00% <ø> (ø)

R/add_offset.R
0.00% <0.00%> (ø)

R/add_predictors.R
44.22% <ø> (+29.08%)
:arrow_up:

R/add_predictors_globiom.R
0.00% <0.00%> (ø)

R/add_priors.R
0.00% <0.00%> (ø)

R/bdproto.R
95.00% <ø> (ø)

... and 45 more

... and 1 file with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Restli compatibility checks warn in cases where backwards compatibility is not a concern.

Describe the bug
Rest.li compatibility check warns when extending enums, which shouldn't be a backwards incompatible case: https://linkedin.github.io/rest.li/modeling/compatibility_check
To Reproduce
Steps to reproduce the behavior:

extend an enum
run :gms:impl:checkRestModel

Expected behavior
This should not cause an issue.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

I think this can be forwards incompatible, wherein old readers cannot read data written by new writers

Closing- with the move to MCP we no longer need to build aspect and entity unions in pdl


(PUP-8977) Merge 'apply' grammar

Updates the parser's task-mode with an apply keyword for use in a task plan. The apply keyword expects tools using Puppet as a library to declare an apply_executor that it calls #apply on when evaluated in a plan, passing the AST of the block following apply.

CLA signed by all contributors.

The tricky part is that we want the AST in the block rather than evaluating it. Henrik probably has more context. I can also share a doc about what ‘apply’ does in Bolt tomorrow, and I suppose take on getting the spec up against puppet-specifications.

Ah, re-reading that I might still have something to explore. But we also didn’t really want the|args|, because they don’t serve a purpose.

For background, we have a rationale for how it should behave at https://docs.google.com/document/d/1BflcENVA1hVfJU55gofxNA4YnZsQNlf6NjKixIj_HM8/edit?usp=sharing. Not sure all of that will make it into the specification.


Update README to explain usage with HTML formatter (and other minor changes)

Hi there!
Just got this plugin installed following your announcement on Elixir Forum! Great work -- I'm excited to not have to think about this stuff myself anymore 😄
I had a bit of trouble following the README when I was first getting it set up. It didn't take long, but I thought I'd take a crack at re-writing the setup instructions to be more explicit about how it should be used with the Phoenix LiveView HTML Formatter depending on the version of Elixir you're running. While I was at it, I also did some minor copy editing that I think makes things more clear.
Please feel free to push to/edit this branch if you want to undo any of the changes I made. (Though I'm also happy to adjust things based on your feedback!)

Thanks for the PR! This is a lot clearer than what I previously had
W.r.t. #12, that also makes sense. I can implement that change after we merge this PR or you can implement that change along with this PR if you'd like :)
I think it'd just require moving the multi_formatter.ex under tailwind_formatter/ to reflect the name change to TailwindFormatter.MultiFormatter

Awesome! I pushed the change to the deps example. I'm not going to add the TailwindFormatter.MultiFormatter bit at the moment, but can do so later today if you haven't gotten to it!

I'll handle it and bump the release (and probably update the forum post) - thank you for the suggestion, as it is confusing for it to be only MultiFormatter
Thanks again for the PR!


Make SequentialDict return outputs from all modules as DotDict

What does this PR do?
Right now SequentialDict only returns the output module. This requires hardcoding a module with that name and often makes configuration more verbose than necessary. This PR removes that requirement and simplifies configuration by returning all outputs in the form of a DotDict. This is a breaking change and also removes ReturnKwargs since it is unnecessary.
This PR depends upon the following:

[x] #168
[x] #169
[ ] #170

Type of change
Please check all relevant options.

[ ] Improvement (non-breaking)
[ ] Bug fix (non-breaking)
[ ] New feature (non-breaking)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Testing
Please describe the tests that you ran to verify your changes. Consider listing any relevant details of your test configuration.

[x] pytest
[x] CUDA_VISIBLE_DEVICES=0 python -m mart experiment=CIFAR10_CNN_Adv trainer=gpu trainer.precision=16 reports 70% (21 sec/epoch).
[x] CUDA_VISIBLE_DEVICES=0,1 python -m mart experiment=CIFAR10_CNN_Adv trainer=ddp trainer.precision=16 trainer.devices=2 model.optimizer.lr=0.2 trainer.max_steps=2925 datamodule.ims_per_batch=256 datamodule.world_size=2 reports 70% (14 sec/epoch).

Before submitting

[x] The title is self-explanatory and the description concisely explains the PR
[x] My PR does only one thing, instead of bundling different changes together
[x] I list all the breaking changes introduced by this pull request
[x] I have commented my code
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[x] I have run pre-commit hooks with pre-commit run -a command without errors

Did you have fun?
Make sure you had fun coding 🙃

It looks like there're merged changes in mart/models/modular.py. I will review again after you merge main into this.

Should be good to review.


Implement User Agent string to provide environment info and reduce data blindness

Remove hard coded user_agent from api
Add dynamic user agent handling to optimizer class
Populate ua platform of servo and namespace if available
connector.py add missing import servo.configuration
set api_client_options to use optimizer user agent
populate/remove k8s user agent info on attach/detach

Closing in favor of refactor


Extend summary to support list of objects / Better describe summary values

In the Collection "summaries" property, a summary for a field can be specified in two ways - either 1) an array of "all distinct values in an array", or 2) "a Stats Object".
With this definition, the summary for the platform field with two platforms (sentinel-2a and sentinel-2b) would be:
"platform": [
"sentinel-2a",
"sentinel-2b"
]
In resto, we have additional statistical information for each fields (including platform). In particular, the number of items for each platforms can be provided to the user. It sounds natural to provide this information through the "summaries" property. As a consequence in resto, the previous example is written this way:
"platform": [
{
"id": "sentinel-2a",
"name": "Sentinel - 2A",
"parentId": "root",
"count": 211199
},
{
"id": "sentinel-2b",
"name": "Sentinel - 2B",
"parentId": "root",
"count": 208632
}
]
Does the "all distinct values in an array" mean that the "value" is a string or a number or does it also mean that the "value" can be any object ? In the latter case, the resto approach is valid against the specification. Otherwise, could we update the specification to allow this approach ?

The values in the summary array can be objects, but the summary values need to be compliant with the original types as defined by STAC. So your platform example is invalid, it can only be an array of strings. But a field that defines an object could be summarized with an array of objects, of course.
That Stats Object for summaries allows objects, but in this case it's a single object per field and it must contain minimum and maximum values. So that's not so helpful for your use case.
Now that 1.0.0 RC1 has been released, we also can't really change the summaries anymore. So you need to put your additional details somewhere else to be STAC-compliant. That could be a new extension or maybe for APIs it would be covered by the queryables endpoint from OGC APIs?

Ok but in this example (https://github.com/radiantearth/stac-spec/blob/master/examples/collection-only/collection.json), the summaries property contains a "eo:bands" entry that does not fulfill the Stats Object

eo:bands is contained in an array there. I don't understand the issue?

Sorry I misunderstood the first explanation, i.e. that the properties in the summaries "must be compliant with the original types as defined by STAC". This is not clear from the specification (https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md#summaries). Perhaps this should be explicitly added in the summary chapter ?
To conclude and check your explanation, if i name the property in the first example "dummy_platform" instead of "platform" then this would be valid since "a field that defines an object could be summarized with an array of objects" ?

Okay, I've planned this to be improved for RC2.
Of course, you can come up with your own field specifications, but then tooling will likely not understand it. It's probably better to figure out a way to make this work in a general-purpose extension. Although I'm not sure myself where this could be placed best.

I do think we should have some mechanism to report 'counts' - a couple catalogs do it, and it's definitely a valuable thing to see.
I'm very open as to how we do it, and seems to make sense to start in an extension, though I'm potentially open to an optional field as we are going to do RC2 so can put in minor changes.

@jjrom - can you describe the use case for needing this? Counts make sense to me, and I could see an extension just for that, but want to understand your parentId and name bits, so we're sure to suggestion a mechanism that can fully meet your needs.

To clarify my initial requirement, forget the other properties in my example (parentId, etc.) and just keep the count property. The use case is to provide the count of the number of items in a stac catalog for each property value.
For instance I want to provide the number of items for platform "sentinel-2a" and for "sentinel-2b".  With the constraint that the "summaries must be compliant with the original types as defined by STAC", it will never be possible to add this information within the summary property, because under "platform" only an array of string is allowed i.e. ["sentinel-2a", "sentinel-2b"]. The additional count information for  "sentinel-2a" and "sentinel-2b" should then be provided in another property (e.g. "summary_extension" - forget the dummy name :).
This extension would complexify the implementation both server side and client side.
Server side, we need to duplicate platform information: the "STAC core" compliant "summary" property with an array of platform name; and an additional "summary_extension" property with an array of platform objects indicating the count attached to each platform value.
Client side, the platform information can be retrieved in two places: the core "summary" with limited information (i.e. the array of string) or the "summary_extension" property with richer information.
So I propose to make the summary property a bit more generic in the core specification as follows (wording to be refined) :
Summaries must be compliant with the original types as defined by STAC. In the case of a basic data type (i.e. string or number), summaries can be expressed either 1) with the type value or 2) with an object where the type value is provided within a "value" property.
For instance the summary "platform" could be expressed either as
[
"sentinel-2a",
"sentinel-2b"
]
or as
[
{
"value":"sentinel-2a"
},
{
"value":"sentinel-2b"
}
]
From an implementation point of view this is not a big deal - just add a if/else case on the summary type. But with a huge advantage that we can add additional fields to the object structure through extension directly within the summaries property.
For instance, adding a "count" extension as discussed previously, or even a "title" extension to provide a human readable name to the value (for instance a human readalbe title could be added to each EPSG code defined here https://github.com/radiantearth/stac-spec/blob/rc.2/examples/collection-only/collection.json#L89-L150)

I'm opposed to change this for 1.0 as this is a rather huge breaking change (at least for my implementations), which we shouldn't do any more in a release candidate phase (rc should be feature freeze).
There are numerous implementations that depend on the existing behavior, which would likely all break (e.g., STAC Browser, STAC Index, stac-fields).
Also, there should be one way of doing things, not two. So if we'd break things, then we could simply forbid the array completely. On the other hand, the summaries were meant to be just a small/light construct to give potential values, not give whatever additional information. (Leaving the option open in the Stats Object to add more fields was not very consistent though.)
I understand that there is a use case for it, but it seems that right now the only non-breaking option is a new extension, unfortunately.

I understand your view but before rc2, the "summaries must be compliant with the original types as defined by STAC" was an implicit constraint...so until making it explicit in rc2, at least my implementations were perfectly valid from the specification. And now they are broken :)
However, my main concern is not to update my code - but that the summary as it is expressed cannot be extended. A new property must be defined as an extension. And this property will basically duplicate summary values with additional fields.
So we will end up with two fields for the same information.
ps: I completely agree to remove the array completely. My proposal to keep both is to limit breaking changes in the implementation - current server implementations would not be affected by this update since they can follow the existing array specification

No, sorry, but although the written documentation was incomplete, the schemas were already enforcing the arrays so your implementation would not have been reported as valid in previous versions if you'd have used any of the validation tools to validate your implementation.
Yes, currently we would end up with two fields, which is unfortunate, I agree. On the other hand at some point we need to stop introducing breaking changes (in this case only for clients, indeed). For me that is the RC stage, but there are other opinions out there.

@m-mohr "No, sorry, that is not correct. Although the written documentation was incomplete, the schemas (which are part of the spec) were already enforcing the arrays so your implementation would have been reported as invalid in previous versions already"
My implementation is correct from the definition (
https://github.com/radiantearth/stac-spec/blob/dev/catalog-spec/json-schema/catalog-core.json#L127-L134) the content of an array is "Any data type":
      {
        "title": "Set of values",
        "type": "array",
        "minItems": 1,
        "items": {
          "description": "Any data type could occur."
        }
      }

Since an object is "Any data type", I have the right to write the platform values as an array of objects:
"platform": [
{
"value":"sentinel-2a"
},
{
"value":"sentinel-2b"
}
]
Only the "summaries must be compliant with the original types as defined by STAC" sentence enforce that in the case of "platform" the array must be an array of string and not an array of object. Nowhere in the schema this is specified

Yes, sorry, I missed that you had encapsulated things in an array. I thought somehow it's an array similar to the Stats Object. I guess it would have been helpful to use markdown code formatting above that makes it easier to read. Indeed, we can't enforce the "same datatype" thing in JSON Schema without a huge amount of additional/duplicated code. Still, I'd argue several things in the spec at least strongly imply that you would need to specify just the values, e.g.

"Collections are strongly recommended to provide summaries of the values of fields that they can expect from the properties of STAC Items contained in this Collection. [...] A set of all distinct values in an array...." -> the values in item properties are clearly defined and they should be listed as a set.
The examples all follow that rule, it says: "See the examples folder for Collections with summaries to get a sense of how to use them."
There's no actual hint how you'd get the actual values if you'd put it into an object, but that you can get those values is described in the spec.

Anyway, I'm against yet another breaking change in the RC stage of the spec. But that is just my opinion and others may vote for it. ;-)

The funny thing is that i exactly did what was written in the specification i.e. "See the examples folder for Collections with summaries to get a sense of how to use them"...and I found the "eo:bands" property which is an array of objects (with the value being in a property called "name" :) So i generalized that to all my properties to be able to add the "count" property.
I'm deeply sorry to raise this issue so lately in the process, but I think that is worth a larger discussion. I understand that this would have an impact on client implementation but it would provide a huge benefit to make the summary property easily extendable in the future.

Hmm, eo:bands follows the specified data type (an array of objects that is merged), of course. So that is to be expected that it contains a name for example.
If we'd have got the feedback earlier, I guess I could have been talked into the object approach although I still like that the arrays as they are are more compact for most use cases.

This is definitely another tough one. We should probably have a specific meeting on it with everyone involved. My initial thoughts:

I do think it is really important we have an answer for how to do 'counts'. Summaries feel like a sensible place to do them, but we should think if there's another route that could make sense and would not be too painful to implement.
To me this is exactly the type of feedback the release candidates are supposed to get, and to me it's at least on the table to discuss breaking changes. And practically I'm not sure if there are lots of implementations of summaries? So the impact may be less.
Introducing #1067 was actually a breaking change to @jjrom's implementations. The spec allowed for the structure he's using, both in schema and in words, even if that wasn't the intent.
I think I'm of two minds of making summaries extensible. I tend to like extensibility, and allowing innovation. But I also find the summaries already a bit hard to understand, and to me a key feature of them is that they are simple - not on some slippery slope where they become a full schema language on their own.
I am compelled by what the rocket/resto combo enables in browsing, so I go back to my first point, that I do want us to find some good alternative if it's not making stats a bit more extensible.

We have at least 8 implementations in openEO, there are some implementations out in the wild, we have deeply integrated the summaries in the openEO API and it is implemented in stac-fields, browser, index and openEO clients...

@m-mohr - do you have a clean alternative idea for the 'counts' use case?

What is clean? I only have the solution to add a new field, there's no other solution I think.
But I haven't fully understood the use case yet. Ehaz are the counts used for?

@m-mohr My implementation is a valid interpretation of what is written in the specification an it conforms to the json schema. It does not add random object but gives context to the summaries values.
My proposal does not break any existing server implementations or any validation tools. It only impacts client to check if the values in an array are a list of basic types or a list of objects. And in the the latter case, converts the list of objects to a list of basic types values using the "value" property of that object (i.e. in javascript var platformAsList = platformAsObject.map(x => x.value);)
Let me explain the "count" use case more specifically. I want to provide users a summary of what is stored in my catalogs - not only how many items are stored, but how many items per platform, per location, per date, etc. For instance, this allows to display  on the landing page of the catalog a comprehensive set of statistics to indicates the repartition of the items per property.
Another example of the array of basic type limitation is that it supposed an implicit understanding of the values provided. The platform property contains obvious values (i.e. "sentinel-2a" and "sentinel-2b"). But this is not the case for proj:epsg property. For instance it is far more convenient to work with named projection (e.g. for France, I use the "Lambert-93" projection - i never remember its epsg code). So I see a strong interest to be able to provide a human readable title to be used in rendered displays of the property. This would be possible with an array of object instead of an array of basic types.
As @cholmes proposes, we should discuss this with everyone involved.

My proposal does not break any existing server implementations nor any validation tools

But a lot of clients.

and in the the latter case, if the client only supports a list of basic types, it can easily convert the list of objects to a list of basic types values using the "value" property of that object (i.e. in javascript var propertyAsList = propertyAsObject.map(x => x.value);)

No, because the value property is not defined anywhere yet. And thus a client currently can't find any of the values. The sprc says you should provide a set of values from the item properties, but you don't provide a set of values from properties.

But several clients.
I don't know how many clients are in the field. And I don't either know how many of them support the optional summaries option. I don't know how many client could be affected.

This is why we need a larger discussion with other implementors.

The following clients and libraries implement summaries as defined in RC2 and are affected:

STAC Browser (lead: Radiant Earth)
STAC Index (lead: me)
stac-fields (lead: Radiant Earth)
openEO JS Client (lead: WWU)
openEO R Client (lead: EFTAS/WWU)
openEO Python Client (lead: VITO)
openEO Web Editor (lead: WWU)
openEO Vue Components (lead: WWU)

Plus:

openEO has the whole (stable) API specification that depends on this
GEE implements summaries and I'm not sure how many clients read their collections
EODAG looks like it uses it too, but not sure

To give an example, I've migrated the collection-only example given above (https://github.com/radiantearth/stac-spec/blob/master/examples/collection-only/collection.json) to the proposed API with consistently all objects.
While making this, I realized that depending on the specification, it may not work this way to get counts per values in arrays, see eo:bands and instruments.
Before:
{
  "datetime": {
    "minimum": "2015-06-23T00:00:00Z",
    "maximum": "2019-07-10T13:44:56Z"
  },
  "platform": [
    "sentinel-2a",
    "sentinel-2b"
  ],
  "constellation": [
    "sentinel-2"
  ],
  "instruments": [
    "msi"
  ],
  "view:off_nadir": {
    "minimum": 0,
    "maximum": 100
  },
  "view:sun_elevation": {
    "minimum": 6.78,
    "maximum": 89.9
  },
  "sci:citation": [
    "Copernicus Sentinel data [Year]"
  ],
  "gsd": [
    10,
    30,
    60
  ],
  "proj:epsg": [
    32601,
    32602,
    32603,
    32604,
    32605,
    32606,
    32607,
    32608,
    32609,
    32610,
    32611,
    32612,
    32613,
    32614,
    32615,
    32616,
    32617,
    32618,
    32619,
    32620,
    32621,
    32622,
    32623,
    32624,
    32625,
    32626,
    32627,
    32628,
    32629,
    32630,
    32631,
    32632,
    32633,
    32634,
    32635,
    32636,
    32637,
    32638,
    32639,
    32640,
    32641,
    32642,
    32643,
    32644,
    32645,
    32646,
    32647,
    32648,
    32649,
    32650,
    32651,
    32652,
    32653,
    32654,
    32655,
    32656,
    32657,
    32658,
    32659,
    32660
  ],
  "eo:bands": [
    {
      "name": "B1",
      "common_name": "coastal",
      "center_wavelength": 4.439
    },
    {
      "name": "B2",
      "common_name": "blue",
      "center_wavelength": 4.966
    },
    {
      "name": "B3",
      "common_name": "green",
      "center_wavelength": 5.6
    },
    {
      "name": "B4",
      "common_name": "red",
      "center_wavelength": 6.645
    },
    {
      "name": "B5",
      "center_wavelength": 7.039
    },
    {
      "name": "B6",
      "center_wavelength": 7.402
    },
    {
      "name": "B7",
      "center_wavelength": 7.825
    },
    {
      "name": "B8",
      "common_name": "nir",
      "center_wavelength": 8.351
    },
    {
      "name": "B8A",
      "center_wavelength": 8.648
    },
    {
      "name": "B9",
      "center_wavelength": 9.45
    },
    {
      "name": "B10",
      "center_wavelength": 1.3735
    },
    {
      "name": "B11",
      "common_name": "swir16",
      "center_wavelength": 1.6137
    },
    {
      "name": "B12",
      "common_name": "swir22",
      "center_wavelength": 2.2024
    }
  ]
}

After:
{
  "datetime": {
    "minimum": "2015-06-23T00:00:00Z",
    "maximum": "2019-07-10T13:44:56Z"
  },
  "platform": [
    {
      "value": "sentinel-2a"
    },
    {
      "value": "sentinel-2b"
    }
  ],
  "constellation": [
    {
      "value": "sentinel-2"
    }
  ],
  "instruments": [
    {
      "value": [
        "msi"
      ]
    }
  ],
  "view:off_nadir": {
    "minimum": 0,
    "maximum": 100
  },
  "view:sun_elevation": {
    "minimum": 6.78,
    "maximum": 89.9
  },
  "sci:citation": [
    {
      "value": "Copernicus Sentinel data [Year]"
    }
  ],
  "gsd": [
    {
      "value": 10
    },
    {
      "value": 30
    },
    {
      "value": 60
    }
  ],
  "proj:epsg": [
    {
      "value": 32601
    },
    {
      "value": 32602
    },
    {
      "value": 32603
    },
    {
      "value": 32604
    },
    {
      "value": 32605
    },
    {
      "value": 32606
    },
    {
      "value": 32607
    },
    {
      "value": 32608
    },
    {
      "value": 32609
    },
    {
      "value": 32610
    },
    {
      "value": 32611
    },
    {
      "value": 32612
    },
    {
      "value": 32613
    },
    {
      "value": 32614
    },
    {
      "value": 32615
    },
    {
      "value": 32616
    },
    {
      "value": 32617
    },
    {
      "value": 32618
    },
    {
      "value": 32619
    },
    {
      "value": 32620
    },
    {
      "value": 32621
    },
    {
      "value": 32622
    },
    {
      "value": 32623
    },
    {
      "value": 32624
    },
    {
      "value": 32625
    },
    {
      "value": 32626
    },
    {
      "value": 32627
    },
    {
      "value": 32628
    },
    {
      "value": 32629
    },
    {
      "value": 32630
    },
    {
      "value": 32631
    },
    {
      "value": 32632
    },
    {
      "value": 32633
    },
    {
      "value": 32634
    },
    {
      "value": 32635
    },
    {
      "value": 32636
    },
    {
      "value": 32637
    },
    {
      "value": 32638
    },
    {
      "value": 32639
    },
    {
      "value": 32640
    },
    {
      "value": 32641
    },
    {
      "value": 32642
    },
    {
      "value": 32643
    },
    {
      "value": 32644
    },
    {
      "value": 32645
    },
    {
      "value": 32646
    },
    {
      "value": 32647
    },
    {
      "value": 32648
    },
    {
      "value": 32649
    },
    {
      "value": 32650
    },
    {
      "value": 32651
    },
    {
      "value": 32652
    },
    {
      "value": 32653
    },
    {
      "value": 32654
    },
    {
      "value": 32655
    },
    {
      "value": 32656
    },
    {
      "value": 32657
    },
    {
      "value": 32658
    },
    {
      "value": 32659
    },
    {
      "value": 32660
    }
  ],
  "eo:bands": [
    {
      "value": [
        {
          "name": "B1",
          "common_name": "coastal",
          "center_wavelength": 4.439
        },
        {
          "name": "B2",
          "common_name": "blue",
          "center_wavelength": 4.966
        },
        {
          "name": "B3",
          "common_name": "green",
          "center_wavelength": 5.6
        },
        {
          "name": "B4",
          "common_name": "red",
          "center_wavelength": 6.645
        },
        {
          "name": "B5",
          "center_wavelength": 7.039
        },
        {
          "name": "B6",
          "center_wavelength": 7.402
        },
        {
          "name": "B7",
          "center_wavelength": 7.825
        },
        {
          "name": "B8",
          "common_name": "nir",
          "center_wavelength": 8.351
        },
        {
          "name": "B8A",
          "center_wavelength": 8.648
        },
        {
          "name": "B9",
          "center_wavelength": 9.45
        },
        {
          "name": "B10",
          "center_wavelength": 1.3735
        },
        {
          "name": "B11",
          "common_name": "swir16",
          "center_wavelength": 1.6137
        },
        {
          "name": "B12",
          "common_name": "swir22",
          "center_wavelength": 2.2024
        }
      ]
    }
  ]
}

Matthias would you be available for a meeting in the next days ? I'm sure that this will allow us to reach a mutual understanding that we obviously are unable to achieve here.

Yes, sure. Monday is a public holiday for us, Wednesday has some meetings, but otherwise, I'm pretty flexible.

After a nice discussion with @jjrom this morning, we have come up with a potential solution that at least in my STAC implementations and openEO would be the least breaking.
It basically leaves the array structure as it is and only allows native data types, but instead it uses the extensible structure of the Stats Object and evolves it a bit further. We could make it a Schema Object instead of a Stats Object and align it with JSON Schema. As JSON Schema allows new keywords to be defined, we'd define a new keyword "values", which is an array of objects with details about every value, see variant 3. The breaking change would be that the Stats Object, would either require "minimum" and "maximum" (to specify an extent) or allow the "values", which is similar to the array, but can only be an array of objects with a "value" and probably at least one additional property (we have not discussed this requirement yet, Jerome, but I think that would help to distinguish it from the array of native typed values).
Example:
{
  "summaries": {
    // variant 1: Array with Stac-native data types, including array merging - no change to rc2
    "platform": [
      "Sentinel-1A",
      "Sentinel-1B",
      "Sentinel-1C"
    ],
    // variant 2: Schema Object - formerly known as the "Stats" Object (not very meaningful example)
    "platform": {
      "minimum": "Sentinel-1A",
      "maxmimum": "Sentinel-1C"
    }
    // variant 3: Schema Object - addition in rc3 is that either "values" (array of objects) or "minimum" and "maximum" are required
    "platform": {
      "type": "string",
      "values": [ // New JSON Schema keyword
        {
          "value": "Sentinel-1A",
          "count": 321
        },
        {
          "value": "Sentinel-1B",
          "count": 123
        },
        {
          "value": "Sentinel-1C",
          "count": 222
        }
      ]
    }
  }
}

One thing to keep in mind is that this would be yet another breaking change in RC stage of the specification with potential to break things and have side effects that we are not aware of yet. The clean alternative without breaking things (but requiring a bit of duplication in collections) is to define a separate "schema" extension, e.g.
{
  "summaries": {
  // variant 4: new extension to specify JSON Schema per field
  "schemas": {
    "platform": {
      "type": "string",
      "values": [
        {
          "value": "Sentinel-1A",
          "count": 321
        },
        {
          "value": "Sentinel-1B",
          "count": 123
        },
        {
          "value": "Sentinel-1C",
          "count": 222
        }
      ]
    }
  }
}

So we need feedback on whether another breaking change by adding in Alternativ 3 would be worth it and supported by the STAC community or whether we should be conservative and evolve new things in STAC extensions first (Alternative 4).

Thanks you again @m-mohr for the great discussion this morning !
It's true that variant 3 introduces a breaking change which is not exactly what we want in a RC release. However this change should have zero to a a limited impact to existing implementations and it will allow future extension to the "summaries" property which brings a huge benefit to the specification.

Glad you guys had a good discussion and got to some solid ideas. I can get behind option 3 and doing a breaking change, as it is nicely minimized to just the stats object. I do hear you on it potentially introducing things we're not yet sure of. But it does feel a bit duplicative to have to list all the fields twice.
Using JSON Schema I do think is fairly elegant. Though also ironic in light of the comment I made when we first added summaries - https://github.com/radiantearth/stac-spec/issues/413#issuecomment-472565303 But I think I actually like this approach, of using a subset of JSON Schema. It seems to let us pick which parts of JSON Schema to use, instead of us re-inventing something that people want JSON Schema for.
I'm +1 on either option, and I think overall I do like option 3 better than 4, since I feel like a new field called 'schema' that is a json schema could lead to confusion and people trying to fully implement the JSON schema for their collection there. So I like that it's in a 'summary', but we're reusing JSON schema to describe a summary.

Using JSON Schema I do think is fairly elegant. Though also ironic in light of the comment I made when we first added summaries - #413 (comment)

I actually quoted you in the call with Jeroen. You said in the SF sprint at Planet that you don't want yet another schema language in summaries... ;-)

But I think I actually like this approach, of using a subset of JSON Schema. It seems to let us pick which parts of JSON Schema to use, instead of us re-inventing something that people want JSON Schema for.

Limiting JSON Schema to a subset was not discussed yet by @jjrom and me, but probably makes sense. On the other hand, we discussed requiring (minimum and maximum) OR (values), but on the other hand, people then may say they only want to specify other things, e.g. type. I also see use cases where you only want to specify a minimum as a maximum is not defined (or vice-versa)? Then there's also minimumExclusive and maximumExclusive. So getting this right may take a couple of iterations. That's why it may not be a bad idea to evolve it in an extension despite the duplication. Also, there might be duplication, but right now we say that some values like "datetime" don't make much sense to be summarized, but someone may want to specify a "schema" for it. Lastly, we may introduce a second place where schemas can be defined for fields. There's "stac_extensions" with schemas (that currently can't really validate summaries, but that's not the point) and there's then schemas in summaries (or the extension). Those are all things that came to my mind after the call and I doubt it's easy to get this right just in a couple of days until RC3 (or even 1.0). If we don't feel confident enough, there's maybe a compromise to weaken the Stats Object a bit and evolve the semantics in there in an extension?
Anyway, I was just typing out more thoughts here and we clearly need to think more about getting this to a solid state, I think.

I'm +1 on either option, and I think overall I do like option 3 better than 4, since I feel like a new field called 'schema' that is a json schema could lead to confusion and people trying to fully implement the JSON schema for their collection there.

Of course, the name was just an example. We can name it whatever we like to avoid confusion.

Limiting JSON Schema to a subset was not discussed yet by @jjrom and me, but probably makes sense.

I'm also ok to just have it evolve through use, and just have the recommended fields to use in the spec, with examples. Key to me would just be not expecting tooling to have to fully support JSON schema parsing to be 'compliant' with the spec.

If we don't feel confident enough, there's maybe a compromise to weaken the Stats Object a bit and evolve the semantics in there in an extension?

I'm not sure exactly what you mean but I think I had a similar thought, but was hesitant to suggest it. My thought was to do something like make the stats object an extension, and have the 'core' for now just be the array, and evolve the object option in an extension. I think maybe you're saying to keep an object in core, but it minimal and extensible, and evolve the semantics in an extension? Whatever the exact path is I think I do like it. A more extreme option would be to move summaries as a whole to be an extension, in line with the same instinct to push all the extensions out of core, so the core spec is as slim and extensible as possible. But I don't need to push for it, just throwing it out there.

tbh I don't really understand what was wrong with the original implementation. "Any data type" means any data type, so in stac4s we just model summaries as a JsonObject since that's all that we definitely know about it (we don't know anything about its keys or the kinds of values they should contain). The summaries object having a shape depending on the items in the catalog is still true in all of the proposals above, so I don't expect that to change much. Clients who know / need something specific are responsible for narrowing that json object on their own.
Re:breaking changes, I agree with @cholmes that this is the kind of feedback that RCs are for -- the spec was unclear, which made an apparently innocuous change actually a breaking change, so that should be resolved. Refining the type of summaries to me seems like the right direction for resolving it.

My intention was not to move summaries to an extension! Also, it still needs a way to specify ranges, but we could loosen the requirement for having minimum and maximum as required properties and simply allow JSON Schema in there with a recommendation to use minimum/maximum for ranges? Not sure.
Anyway, if most people are fine with breaking changes, then we can simply PR variant 3 IMHO.

While writing up the JSON Schema for this, I realized that we have an inconsistency with JSON Schema in our spec:
We allow minimum and maximum to be strings (mostly for temporal fields). This is not supported by JSON Schema and thus not all variants can actually be compliant with JSON Schema, which makes the description of the change much harder...

On the other hand, we may get away without defining our own keyword. We can use "oneOf" (or "anyOf") and "const" instead of from JSON Schema. Example:
    // variant 3: Schema Object - addition in rc3 is that either "values" (array of objects) or "minimum" and "maximum" are required
    "platform": {
      "type": "string",
      "oneOf": [
        {
          "const": "Sentinel-1A",
          "count": 321
        },
        {
          "const": "Sentinel-1B",
          "count": 123
        },
        {
          "const": "Sentinel-1C",
          "count": 222
        }
      ]
    }


Twitter login

Enable to call _linkWith('twitter', authData)
As I'm receiving the following error: authenticate.provider is not an object
Is Twitter login still supported? (consumer key has been added to my parse dashboard correctly)

Twitter login has never been supported by the JS SDK -- Twitter only provides login libraries for iOS and Android. It does not provide a client-side web popup in the style that FB does, so we can't do login from JavaScript clients.


Add support for pip==22.1

Prepare pip-tools for the upcoming pip-22.1 release, see https://github.com/pypa/pip/issues/10991.
Add main to the matrix so that we could see the changes pass tests. There is fail-fast: false on CI so the workflow shouldn't be failed if main fails. It would be nice to have some kind of allow-failure, but it's not yet implemented, see: https://github.com/actions/toolkit/issues/399.

Contributor checklist

[x] Provided the tests for the changes.
[x] Assure PR title is short, clear, and good to be included in the user-oriented changelog

Maintainer checklist

[x] Assure one of these labels is present: backwards incompatible, feature, enhancement, deprecation, bug, dependency, docs or skip-changelog as they determine changelog listing.
[x] Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

I requests @pradyunsg to update its review so I will wait for his comment or approval before merging. That is a very welcomed addition.

Please feel free to merge this without waiting on my review. If I have time to do a review, I’ll do one. :)


Adds banner component

Summary of changes

Adds Banner component to libs/webb-ui-components.
Adds Banner component in Bridge dApp.

Proposed area of change

[x] apps/bridge-dapp
[ ] apps/stats-dapp
[ ] apps/webbsite
[x] libs/webb-ui-components

Reference issue to close (if applicable)

Closes #928
Closes #989

Screen Recording
https://user-images.githubusercontent.com/53374218/217037806-74f4ae10-ca8a-4e9c-a3e2-542547cf0816.mov
Screenshot

Code Checklist

[x] I have added tests that prove my fix is effective or that my feature works.
[x] I have added necessary documentation - .stories documentation for Banner component is added in libs/webb-ui-components.

Changes overview

Updates Banner component props.
Privacy policy and terms & conditions links now opens in a new tab.
Fixes Bridge and Stats image rendering issue in mobile view.

@monaiuu
Image rendering issue video
https://user-images.githubusercontent.com/53374218/217111065-1e845218-08ee-47d7-8cd7-d22e6369cc84.mov

Looks good thanks @devpavan04 !

✅ Deploy Preview for bridge-dapp development is ready! Thanks for the contribution @devpavan04
Name	Link
🔨 Latest commit	d0e2e34b8494431d1ed0aefd8a27446f71d8500b
🔍 Latest deploy log	https://app.netlify.com/sites/development-hubble-bridge/deploys/63e1919ea02d9d261f5e5bfd
😎 Deploy Preview	https://63e1919ea02d9d261f5e5bfd--development-hubble-bridge.netlify.app
To edit notification comments on pull requests, go to your Netlify site settings.

In the design system the banner button is using the small-size utility button, which I could not locate in the Webb Storybook—wondering if the button on the banner would look less protrusive if we use body 04 in BOLD instead? Let me know your thoughts/ if it is too small!

@monaiuu My bad, button was not utility variant and size wasn't sm before. That's the reason button is bigger and protrusive. I've updated the button to use utility variant and size sm and it should match the design now. I'll push the changes and you can check using the preview link. Let me know.
Before:

After:

@monaiuu My bad, button was not utility variant and size wasn't sm before. That's the reason button is bigger and protrusive. I've updated the button to use utility variant and size sm and it should match the design now. I'll push the changes and you can check using the preview link. Let me know.
Before:

After:

Looks good! Thanks for the quick update @devpavan04


0 kts in the Web UI

I don’t know it this is unique to me or not, but I have been testing my system since building and installing the Malcolm Robb dump1090 branch and I have been seeing aircraft reported in the Web UI with 0 kts groundspeed.  It does not seem to impact the traffic seen on my App.
In the attached screenshot there are a number of aircraft with 0 kts.   The one of interest is FDX3629 / N682FE / A90B27.  It is unique because there is a Message 4 (DF17 Airborne Velocity) in the log that reports everything except the groundspeed.  The other 0 kt aircraft are not reporting Message 4.  I am not sure if Stratux isn’t receiving this message for those aircraft, or they are not transmitting Message 4.
Here are two examples from the dump1090.log.  FDX3629 never shows Ground Speed and is marked as “Unavailable” whereas FDX3654 is marked “valid” and shows the Groundspeed.
FDX3629 from dump1090.log:
*8da90b27990000001008002f8bb2;
CRC: 000000 (ok)
DF 17: ADS-B message.
Capability     : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne))
ICAO Addres
40865262857726,s   : a90b27
Extended Squitter  Type: 19
Extended Squitter  Sub : 1
Extended Squitter  Name: Airborne Velocity
EW status         : Unavailable
EW velocity       : 515
NS status         : Unavailable
NS velocity       : 79
Vertical status   : Valid
Vertical rate src : 1
Vertical rate     : 64
FDX3654 from the dump1090.log:
*8da8a73d9902250a680b0a2cf483;
CRC: 000000 (ok)
DF 17: ADS-B message.
Capability     : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne))
ICAO Address   : a8a73d
Extended Squitter  Type: 19
Extended Squitter  Sub : 1
Extended Squitter  Name: Airborne Velocity
EW status         : Valid
EW velocity       : 548
NS status         : Valid
NS velocity       : 82
Vertical status   : Va
41788836485997,lid
Vertical rate src : 0
Vertical rate     : -64
0069-es.zip
0069-dump1090.zip

This one looks like an aircraft problem. Mostly. :-)
Here's that ES message from FDX3629 with a little annotation.
     [8bit] [24 bits] [ES register - 56 bit]  [24 bits]
Desc: DF/CA  ICAO ID   TC   ----PAYLOAD-----   CHECKSUM
Byte:     0  1  2  3    4   5  6  7  8  9 10   11 12 13
Msg:     8d a9 0b 27   99  00 00 00 10 08 00   2f 8b b2

Byte 0 tells us that this is a Type 17 downlink (ADS-B), Capability 5. (0x8d = 10001101. Split after the first five bits, and we get 17 and 5)
Bytes 1-3 are the ICAO hex code, A90B27.
Byte 4 gets us into the ES message, and tells us what format type and subtype we're looking at. Like byte 0, this is a 5+3 message. 0x99 = 10011 001, or type = 19 and subtype = 1.  Looking at the spec for this message, the next 3.5 bytes should contain velocity / integrity flags and the EW and NS components of ground speeds.

But they don't. These 3.5 bytes are empty (zero) -- in fact, all that's left in the rest of the ES message is baro vertical speed.
Nulls are passed to the dump1090 output. We're apparently interpreting those as zero in the web UI -- and that might be something that we could fix.
So, why is there an EW / NS velocity report in the verbose log? Because those are the values parsed from the last aircraft, and while dump1090 doesn't parse / update velocity if it sees an "invalid" flag, it uses the most recent values when it makes the log file. The 515 and 79 knot components actually belong to A46CE1.
*8da46ce19912040a00048f152229;
CRC: 000000 (ok)
DF 17: ADS-B message.
  Capability     : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne))
  ICAO Address   : a46ce1
  Extended Squitter  Type: 19
  Extended Squitter  Sub : 1
  Extended Squitter  Name: Airborne Velocity
    EW status         : Valid
    EW velocity       : 515
    NS status         : Valid
    NS velocity       : 79
    Vertical status   : Valid
    Vertical rate src : 0
    Vertical rate     : 0

*8da90b27990000001008002f8bb2;
CRC: 000000 (ok)
DF 17: ADS-B message.
  Capability     : 5 (Level 2+3+4 (DF0,4,5,11,20,21,24,code7 - is airborne))
  ICAO Address   : a90b27
  Extended Squitter  Type: 19
  Extended Squitter  Sub : 1
  Extended Squitter  Name: Airborne Velocity
    EW status         : Unavailable
    EW velocity       : 515
    NS status         : Unavailable
    NS velocity       : 79
    Vertical status   : Valid
    Vertical rate src : 1
    Vertical rate     : 64

This one looks like an aircraft problem. Mostly. :-)
Here's that ES message from FDX3629 with a little annotation.

Wow.  Nice sleuthing there, Mr. @AvSquirrel

I don't mean to clutter up the github with jokes, but @AvSquirrel, you can quit your day job. :-)
My airplane partner used to attend ARINC meetings when she was designing the FMC for the B-767. (I used to help a bit.) We got to fly around the country in the Glasiar attending meetings. Seeing ARINC documents in the post brings back good memories.

I updated with the fix to the 0 kts GS issue and observed an additional anomaly.  While watching traffic on my app, I saw a traffic target with GS --- in the Web UI.  I located that target on my app and observed the Heading arrow of the target did not correlate with the ground track of the target.  Typically the Heading arrow is within a few degrees of the ground track (depending on cross wind correction).  In this instance, the Heading arrow pointed to 0 degrees while the target tracked from NW to SE with a delta of approximately 150 degrees between the Heading arrow and the ground track.  Switching back to the Web UI showed the traffic heading as 0 deg in addition to having the invalid GS.  My next step is to capture more data and figure out how to use the replay logs to see if this is unique to a particulate app.

Check out this transponder:
329265088747,MSG,3,,,A346D0,,,,,,,45000,,,42.45012,-84.54754,,,0,0,0,0
329657950001,MSG,3,,,A346D0,,,,,,,0,,,72.93750,42.35294,,,0,0,0,0
329784067551,MSG,5,,,A346D0,,,,,,,45000,,,,,,,,,,
330243978866,MSG,3,,,A346D0,,,,,,,45000,,,72.95913,42.78728,,,0,0,0,0
331623499784,MSG,3,,,A346D0,,,,,,,30225,,,72.93750,42.35294,,,0,0,0,0
333523429737,MSG,5,,,A346D0,,,,,,,45000,,,,,,,,,,
333524109349,MSG,5,,,A346D0,,,,,,,45000,,,,,,,,,,
333785523599,MSG,3,,,A346D0,,,,,,,30325,,,72.93750,42.35294,,,0,0,0,0
337322839815,MSG,5,,,A346D0,,,,,,,45000,,,,,,,,,,
337915310573,MSG,5,,,A346D0,,,,,,,45000,,,,,,,0,0,0,0
338564169912,MSG,5,,,A346D0,,,,,,,45000,,,,,,,,,,
339748053003,MSG,5,,,A346D0,,,,,,,45000,,,,,,,,,,
340334368834,MSG,3,,,A346D0,,,,,,,45000,,,72.96221,42.87775,,,0,0,0,0

Saw it flipping from FL300 to FL450.
http://flightaware.com/live/flight/WWI31/history/20160103/1645Z/KEGE/KHPN/tracklog

Fixed via pull request #173.


Bevy logo is not necessarily CC-0 licensed

As far as I can tell, the Bevy logo does not have an explicit license. Please see https://github.com/bevyengine/bevy_github_ci_template/issues/45 for the reason it was removed from bevy_ci_template.
In this scenario, @cart will either have to sign-off that all people who use this template may use the logo in the splash screen, or it should unfortunately be removed.

@alice-i-cecile I think we talked about its usage being fine for a splash screen as long as it's properly credited, but @BD103 is right, it's probably not CC0. Which license do we use?


Const(obj, shape) should use RFC 9 to cast obj to shape

There was previous discussion of this feature.

@zyp has mentioned they will write the RFC unless someone else picks it up.

This has an RFC now: amaranth-lang/rfcs#42


Use the remaining half bit in the refcount to bypass ObjC deallocation overhead

We can use the new setAssociatedObject interposition function to make this safe. 1.1-1.5x win on a huge variety of benchmarks.
#ifdef'd out for platforms that don't have the new interposition function
Fixes rdar://36825362

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - bda608fe7ebfd04c65328a2a118f249bf613077b

Sigh, looks like I broke something in one of the recent tweaks
17:11:40 Fatal error: Object was retained too many timesCurrent stack trace:
17:11:40 0    libswiftCore.dylib                 0x0000000104acc000 swift::fatalError(unsigned int, char const*, ...) + 144
17:11:40 1    libswiftCore.dylib                 0x0000000104acc1f0 swift::swift_abortRetainOverflow() + 23
17:11:40 2    libswiftCore.dylib                 0x0000000104af6e00 swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::incrementSlow(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 172
17:11:40 3    libswiftCore.dylib                 0x0000000104acd0a0 swift_retain_n(swift::HeapObject*, unsigned int) + 103
17:11:40 4    libswiftCore.dylib                 0x00000001047d7b50 Dictionary.init() + 57
17:11:40 5    swift-build-stage1                 0x000000010401c5d0 ArgumentParser.Result.init(parser:parent:) + 106
17:11:40 6    swift-build-stage1                 0x000000010401c580 ArgumentParser.Result.__allocating_init(parser:parent:) + 71
17:11:40 7    swift-build-stage1                 0x00000001040219f0 ArgumentParser.parse(:parent:) + 309
17:11:40 8    swift-build-stage1                 0x0000000104021970 ArgumentParser.parse(:) + 48
17:11:40 9    swift-build-stage1                 0x0000000103d723b0 SwiftTool.init(toolName:usage:overview:args:seeAlso:) + 16800
17:11:40 10   swift-build-stage1                 0x0000000103d34760 SwiftBuildTool.init(toolName:usage:overview:args:seeAlso:) + 320
17:11:40 11   swift-build-stage1                 0x0000000103d346b0 SwiftBuildTool.__allocating_init(toolName:usage:overview:args:seeAlso:) + 157
17:11:40 12   swift-build-stage1                 0x0000000103d32190 SwiftBuildTool.__allocating_init(args:) + 256
17:11:40 13   swift-build-stage1                 0x0000000103d1fc20 main + 264
17:11:40 14   libdyld.dylib                      0x00007fff5d506ed8 start + 1
17:11:40
--- bootstrap: error: build failed with exit status -6

Build failed
Swift Test Linux Platform
Git Sha - bda608fe7ebfd04c65328a2a118f249bf613077b

I think I see the problem, but if I'm right, I'm baffled as to why it isn't failing locally

@swift-ci please test

@swift-ci please benchmark

Build failed
Swift Test Linux Platform
Git Sha - bda608fe7ebfd04c65328a2a118f249bf613077b

Build failed
Swift Test OS X Platform
Git Sha - bda608fe7ebfd04c65328a2a118f249bf613077b

We'll see if I got this attempted fix remotely close to right heh

Performance: -O

Regression
OLD
NEW
DELTA
RATIO

ObjectiveCBridgeFromNSSetAnyObjectToString
70500
80500
+14.2%
0.88x (?)

Improvement
OLD
NEW
DELTA
RATIO

FlattenListLoop
4337
3970
-8.5%
1.09x

RemoveWhereMoveInts
37
34
-8.1%
1.09x (?)

Array2D
7520
6912
-8.1%
1.09x (?)

RemoveWhereSwapInts
65
60
-7.7%
1.08x

FlattenListFlatMap
6533
6071
-7.1%
1.08x (?)

MapReduce
397
369
-7.1%
1.08x

MapReduceAnyCollection
397
369
-7.1%
1.08x (?)

Code size: -O
Performance: -Osize

Regression
OLD
NEW
DELTA
RATIO

ObjectiveCBridgeFromNSSetAnyObjectToString
71500
82000
+14.7%
0.87x (?)

Improvement
OLD
NEW
DELTA
RATIO

EqualSubstringString
44
40
-9.1%
1.10x (?)

FlattenListLoop
4430
4053
-8.5%
1.09x (?)

RemoveWhereMoveInts
37
34
-8.1%
1.09x

Array2D
7520
6912
-8.1%
1.09x (?)

RemoveWhereSwapInts
67
62
-7.5%
1.08x

MapReduce
433
404
-6.7%
1.07x (?)

Code size: -Osize
Performance: -Onone

Regression
OLD
NEW
DELTA
RATIO

ObjectiveCBridgeFromNSSetAnyObjectToString
75500
85000
+12.6%
0.89x (?)

DictionaryBridgeToObjC_Access
1018
1134
+11.4%
0.90x (?)

ArrayOfPOD
774
853
+10.2%
0.91x (?)

SubstringFromLongString
11
12
+9.1%
0.92x

Improvement
OLD
NEW
DELTA
RATIO

DataCreateSmallArray
205150
186050
-9.3%
1.10x (?)

ParseFloat.Float80.Exp
95
87
-8.4%
1.09x (?)

EqualStringSubstring
49
45
-8.2%
1.09x (?)

RomanNumbers2
11794
10904
-7.5%
1.08x (?)

Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

@swift-ci please smoke benchmark

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - e447787e980f90866e736e2a4be0358a22c6e39a

Build failed
Swift Test OS X Platform
Git Sha - e447787e980f90866e736e2a4be0358a22c6e39a

Performance: -O

Improvement
OLD
NEW
DELTA
RATIO

NSStringConversion
570
531
-6.8%
1.07x (?)

Code size: -O
Performance: -Osize
Code size: -Osize
Performance: -Onone

Regression
OLD
NEW
DELTA
RATIO

DictionaryOfAnyHashableStrings_lookup
4344
4680
+7.7%
0.93x (?)

Improvement
OLD
NEW
DELTA
RATIO

SubstringFromLongString
12
11
-8.3%
1.09x (?)

Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

????
I hand-verified that the optimization was working before pushing this one. What is going on here >.<

The CI Macs don't have a libobjc with that hook, right?

oh! Right. Yes, ok.

Unfortunately we're still hitting that failure, so that's interesting

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - 6d1a062cb0efa7e5545cb720b8d7ea448474ccfb

Build failed
Swift Test OS X Platform
Git Sha - 6d1a062cb0efa7e5545cb720b8d7ea448474ccfb

Still no idea why this isn't reproducing locally, but it wasn't the 32 bit mistake I found.

@swift-ci please test

Build failed
Swift Test OS X Platform
Git Sha - 6dfa1a5639ad950340387c70781c1ec9375d5479

Build failed
Swift Test Linux Platform
Git Sha - 6dfa1a5639ad950340387c70781c1ec9375d5479

@swift-ci please test

@swift-ci please benchmark

Build failed
Swift Test OS X Platform
Git Sha - 663f829c9253f5057e63194269c6566b2b7ded40

Build failed
Swift Test Linux Platform
Git Sha - 663f829c9253f5057e63194269c6566b2b7ded40

Performance: -O

Regression
OLD
NEW
DELTA
RATIO

UTF8Decode_InitFromBytes
126
140
+11.1%
0.90x

UTF8Decode_InitFromData
118
131
+11.0%
0.90x (?)

Improvement
OLD
NEW
DELTA
RATIO

LessSubstringSubstringGenericComparable
28
21
-25.0%
1.33x (?)

EqualSubstringSubstring
27
21
-22.2%
1.29x

LessSubstringSubstring
27
21
-22.2%
1.29x

EqualStringSubstring
27
21
-22.2%
1.29x

EqualSubstringSubstringGenericEquatable
27
21
-22.2%
1.29x

EqualSubstringString
27
21
-22.2%
1.29x

Calculator
153
131
-14.4%
1.17x (?)

ArrayLiteral2
91
78
-14.3%
1.17x

Chars2
3450
3000
-13.0%
1.15x (?)

Set.isSubset.Int.Empty
53
47
-11.3%
1.13x

DataCreateEmptyArray
1800
1600
-11.1%
1.12x (?)

StringComparison_longSharedPrefix
354
319
-9.9%
1.11x

OpenClose
61
56
-8.2%
1.09x (?)

Set.isDisjoint.Int.Empty
58
54
-6.9%
1.07x (?)

Code size: -O
Performance: -Osize

Regression
OLD
NEW
DELTA
RATIO

UTF8Decode_InitFromData
115
131
+13.9%
0.88x (?)

ArrayInClass
825
935
+13.3%
0.88x

UTF8Decode_InitFromBytes
125
141
+12.8%
0.89x (?)

Improvement
OLD
NEW
DELTA
RATIO

EqualSubstringSubstringGenericEquatable
28
21
-25.0%
1.33x

EqualSubstringString
28
21
-25.0%
1.33x

EqualStringSubstring
27
21
-22.2%
1.29x

LessSubstringSubstringGenericComparable
27
21
-22.2%
1.29x (?)

LessSubstringSubstring
28
22
-21.4%
1.27x (?)

EqualSubstringSubstring
27
22
-18.5%
1.23x

ArrayLiteral2
126
111
-11.9%
1.14x (?)

Calculator
154
137
-11.0%
1.12x (?)

StringComparison_longSharedPrefix
356
319
-10.4%
1.12x (?)

Chars2
3500
3150
-10.0%
1.11x (?)

MapReduce
237
216
-8.9%
1.10x (?)

DataCreateEmptyArray
1750
1600
-8.6%
1.09x (?)

Set.isStrictSuperset.Seq.Empty.Int
177
165
-6.8%
1.07x (?)

Code size: -Osize
Performance: -Onone

Regression
OLD
NEW
DELTA
RATIO

UTF8Decode_InitFromData
116
133
+14.7%
0.87x (?)

UTF8Decode_InitFromBytes
125
143
+14.4%
0.87x

ExclusivityGlobal
108
117
+8.3%
0.92x (?)

StringWalk
7320
7880
+7.7%
0.93x (?)

Improvement
OLD
NEW
DELTA
RATIO

EqualSubstringSubstringGenericEquatable
30
24
-20.0%
1.25x (?)

LessSubstringSubstringGenericComparable
30
24
-20.0%
1.25x

EqualSubstringSubstring
31
25
-19.4%
1.24x

LessSubstringSubstring
30
25
-16.7%
1.20x (?)

EqualStringSubstring
31
26
-16.1%
1.19x (?)

EqualSubstringString
31
26
-16.1%
1.19x (?)

SubstringFromLongString
10
9
-10.0%
1.11x (?)

Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac mini
  Model Identifier: Macmini8,1
  Processor Name: Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

Huh. Might have accidentally improved refcounting codegen?? Neat

Good news: I fixed the problem! (at least on linux, but I'm pretty sure OSX will get the same result)
Bad news: my fix for the race condition earlier broke the unowned refcount overflow tests.
Still, progress. I have some ideas for the unowned issue.

@swift-ci please test

Might have figured it out. Will see once the test completes if the failure mode is what I expect.

Build failed
Swift Test Linux Platform
Git Sha - 3d47feb020a2a12e3ebf23c57979c63962cdd3ca

@swift-ci please test

Build failed
Swift Test Linux Platform
Git Sha - 3d47feb020a2a12e3ebf23c57979c63962cdd3ca

Build failed
Swift Test OS X Platform
Git Sha - 3d47feb020a2a12e3ebf23c57979c63962cdd3ca

@swift-ci please test

@swift-ci please benchmark

Build failed
Swift Test OS X Platform
Git Sha - 812ab5c3bf3c34d52cd3a2b8a5b86dde0f6f4f24

Build failed
Swift Test Linux Platform
Git Sha - 812ab5c3bf3c34d52cd3a2b8a5b86dde0f6f4f24

I'm 90% certain this will fix it, the question is whether the performance cost to unowned refcounting will be too severe. I think it'll be fine, but I want to see what benchmarking says.

Performance: -O

Regression
OLD
NEW
DELTA
RATIO

EqualSubstringSubstring
21
27
+28.6%
0.78x

LessSubstringSubstring
21
27
+28.6%
0.78x

EqualSubstringSubstringGenericEquatable
21
27
+28.6%
0.78x

EqualSubstringString
21
27
+28.6%
0.78x

LessSubstringSubstringGenericComparable
21
27
+28.6%
0.78x (?)

EqualStringSubstring
22
27
+22.7%
0.81x (?)

StringComparison_longSharedPrefix
320
355
+10.9%
0.90x

ParseInt.Small.Decimal
179
197
+10.1%
0.91x (?)

Chars2
3250
3500
+7.7%
0.93x (?)

Improvement
OLD
NEW
DELTA
RATIO

UTF8Decode_InitDecoding
129
113
-12.4%
1.14x

ArrayInClass
960
855
-10.9%
1.12x (?)

MapReduceAnyCollection
216
194
-10.2%
1.11x (?)

Code size: -O
Performance: -Osize

Regression
OLD
NEW
DELTA
RATIO

EqualSubstringSubstringGenericEquatable
21
28
+33.3%
0.75x

EqualSubstringString
21
28
+33.3%
0.75x

EqualSubstringSubstring
21
27
+28.6%
0.78x

EqualStringSubstring
21
27
+28.6%
0.78x (?)

LessSubstringSubstring
22
28
+27.3%
0.79x

LessSubstringSubstringGenericComparable
22
27
+22.7%
0.81x

StringComparison_longSharedPrefix
321
355
+10.6%
0.90x (?)

Chars2
3200
3500
+9.4%
0.91x (?)

Set.isDisjoint.Seq.Int.Empty
51
55
+7.8%
0.93x (?)

ParseInt.Small.Decimal
199
214
+7.5%
0.93x (?)

Improvement
OLD
NEW
DELTA
RATIO

UTF8Decode_InitDecoding
130
112
-13.8%
1.16x

Code size: -Osize
Performance: -Onone

Regression
OLD
NEW
DELTA
RATIO

LessSubstringSubstring
24
31
+29.2%
0.77x

EqualSubstringSubstringGenericEquatable
24
30
+25.0%
0.80x

LessSubstringSubstringGenericComparable
24
30
+25.0%
0.80x

EqualSubstringSubstring
25
31
+24.0%
0.81x

EqualStringSubstring
25
31
+24.0%
0.81x

EqualSubstringString
26
31
+19.2%
0.84x (?)

Improvement
OLD
NEW
DELTA
RATIO

ArrayOfPOD
529
466
-11.9%
1.14x (?)

UTF8Decode_InitDecoding
149
132
-11.4%
1.13x

DropWhileSequence
9628
8829
-8.3%
1.09x (?)

Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac mini
  Model Identifier: Macmini8,1
  Processor Name: Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

Wow. One completely predictable branch in unowned retain did that??
Back to the drawing board I guess

@swift-ci please test

@swift-ci please benchmark

Build failed
Swift Test Linux Platform
Git Sha - 4e4c853dde3518d489ac9c52072babe8d8b1aa92

Performance: -O

Regression
OLD
NEW
DELTA
RATIO

Set.subtracting.Empty.Box
8
9
+12.5%
0.89x

Improvement
OLD
NEW
DELTA
RATIO

ArrayInClass
975
850
-12.8%
1.15x

UTF8Decode_InitDecoding
127
115
-9.4%
1.10x

OpenClose
61
56
-8.2%
1.09x (?)

LazilyFilteredArrayContains
24800
23000
-7.3%
1.08x (?)

Code size: -O
Performance: -Osize

Regression
OLD
NEW
DELTA
RATIO

DistinctClassFieldAccesses
181
209
+15.5%
0.87x

ArrayInClass
915
1000
+9.3%
0.92x (?)

Set.isDisjoint.Seq.Box.Empty
91
99
+8.8%
0.92x

Improvement
OLD
NEW
DELTA
RATIO

OpenClose
65
58
-10.8%
1.12x (?)

UTF8Decode_InitDecoding
129
116
-10.1%
1.11x

NSStringConversion.Long
506
469
-7.3%
1.08x (?)

Code size: -Osize
Performance: -Onone

Regression
OLD
NEW
DELTA
RATIO

NopDeinit
115800
126500
+9.2%
0.92x (?)

UTF8Decode_InitFromData_ascii
164
178
+8.5%
0.92x (?)

Improvement
OLD
NEW
DELTA
RATIO

UTF8Decode_InitDecoding
147
127
-13.6%
1.16x

SubstringFromLongString
10
9
-10.0%
1.11x (?)

ArrayOfGenericPOD2
617
575
-6.8%
1.07x (?)

Code size: -swiftlibs

How to read the data
The tables contain differences in performance which are larger than 8% and
differences in code size which are larger than 1%.
If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.
Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview
  Model Name: Mac mini
  Model Identifier: Macmini8,1
  Processor Name: Intel Core i7
  Processor Speed: 3.2 GHz
  Number of Processors: 1
  Total Number of Cores: 6
  L2 Cache (per Core): 256 KB
  L3 Cache: 12 MB
  Memory: 64 GB

Ok, fixed the perf regression! Let's see how the tests do

Yaaaaaaaay :D

Mike re-reviewed this in person

@swift-ci please test and merge

@swift-ci please test and merge


Add keyboardShouldPersistTaps to screen

Exposes ScrollView's keyboardShouldPersistTaps prop on Screen component. Sets "handled" as a reasonable default.

Not sure why CI failed, as it shouldn't make much difference to this. I'll re-run it.

I couldn't understand why it was failing but could not re-run the test. I'm glad it passed finally. Thanks!

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[aes] Add support for multi-cycle S-Box implementations

This PR lays the ground work for multi-cycle S-Boxes required for SCA hardening.
This is achieved by adding input enable signals as well as output req/ack handshake signals between the cipher core controller and the SubBytes and KeyExpand blocks (both contain several S-Boxes). For the currently implemented single-cycle S-Boxes nothing changes, the newly added signals have static values in this case.
Note: this PR contains quite some whitespace changes. For the review, I recommend to hide these in the GitHub interface.

Note, I have successfully tested the changes with variable latency S-Boxes.

Thanks for your review and feedback @cdgori!


Update preparation.md

reflect the fact that requirements.txt was unzipped to a code/ directory

Yes, this is correct! Thanks  @lion19 🎉


npm install reinstalls even if the package exists

If I have a module (say yui3) installed in ./node_modules, then I issue an npm i yui3 again. It appears that it re-unzips the package again. Shouldn't it just skip modules that it knows about unless the -f flag was passed? Is there any reason that a "reinstall" is required if the versions match? I can understand if the package is an upgrade, but if the versions match shouldn't it just skip it all together?
Example:
mkdir test
npm i yui3
npm i yui3
Note that it will download and install it the first time, but it will unzip it again the second time. I only noticed this while I was working on a cli tool and needed to globally install it to test it after each change. Each install takes a while because it needs to unzip all the files that are actually already there.
npm output:
https://gist.github.com/957748

+1
Besides unzipping the package, it will recompile any C++ node extensions included with it.
I've found it to be a good practice to keep all developers in sync with regard to 3rd party packages by maintaining a simple script in the project's repository that goes like this:
npm install \
<EMAIL_ADDRESS>\
<EMAIL_ADDRESS>\
    ...

Since this list is getting bigger and bigger and many packages have C++ components, the time required to execute the "./update-dependecies" script is getting bigger too even though usually only a single package is introduced(updated).
There used to be a "must-install" config option. What happened to it?


9rOfvQoc: bump request-promise-native dependency

This is an attempt to remove two vulnerabilities in lodash, reported by Snyk.
https://trello.com/c/9rOfvQoc/123-passport-verify-update-some-compromised-dependencies

Think you'll need to run npm install or npm update or something to bump the package-lock.json file too.


Blacken code

As discussed with @anthrotype for #2923.

this PR touches almost every line in the codebase and will inevitably make all outstanding PRs in a merge conflict state. We have been delaying this for years (see #2233) but I think it's time we bite the bullet. Some fastidious merge conflicts are unavoidable, but should be relatively easily fixed when rebasing one's PR branch on the updated main by running black on the code.
As for the git blame noise, we added the .git-blame-ignore-revs file that automatically hides the 'blacken code' commit when doing git blame.
If anybody has any strong objections to this move please speak up now, or else I will merge this, sooner than later otherwise new PRs may start piling up and the window of opportunity will close again

I'd really be sad to redo https://github.com/fonttools/fonttools/pull/2678

I'd really be sad to redo https://github.com/fonttools/fonttools/pull/2678

actually that PR already has merge conflicts with current main branch. You should fix those first, then you can merge the blackened main branch into your PR branch and any merge conflicts that may arise from that will be exclusively due to black, which means you can reset the conficted files to your copy, run black on those, and finish the git merge (or rebase).


Cannot authenticate with extension github.vscode-pull-request-github

Hi,
Authentification for the extension is failling with this message:
Oh no! An error occurred!
Please restart the sign in process from the editor.

Forbidden

Any idea why ?

Web Browser: Version 75.0.3770.142 (Build officiel) (64 bits)
Local OS:  Windows 10 Pro 64bits
Remote OS: Ubuntu 18.04
Remote Architecture: x86_64
code-server --version: 3.6.1 62735da69466a444561ab9b1115dc7c4d496d455

There are some issues with authenticating with the built-in GitHub extension which probably are affecting the pull request extension as well (https://github.com/cdr/code-server/issues/1883). Hopefully I will be able to find the time to fix them soon.

Thank you. I didn't find the issue (#1883) while opening this one.

Closing as duplicate of #1883 then!


interface with buttons

Add 2x buttons maybe? Consider what space is available...

http://softsolder.com/2012/07/13/contact-bounce-why-capacitors-dont-fix-it/
I'll do software filtering; in practice, this means that I can't rely on interrupts for UI.

2.2k resistors, heat-shrink leads to pins.


raft: don't ack MsgPreVotes when it cannot succeed

replace https://github.com/coreos/etcd/pull/8517.
i added a test, which illustrate what problem this pr tries to address.
/cc @bdarnell @javaforfun

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@bcbf184). Click here to learn what that means.
The diff coverage is 33.33%.

@@            Coverage Diff            @@
##             master    #8571   +/-   ##
=========================================
  Coverage          ?   75.68%
=========================================
  Files             ?      357
  Lines             ?    29295
  Branches          ?        0
=========================================
  Hits              ?    22173
  Misses            ?     5563
  Partials          ?     1559

Impacted Files
Coverage Δ

raft/raft.go
92.01% <33.33%> (ø)

Continue to review full report at Codecov.

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

the test success even without the change in raft.go

@javaforfun The test case is added for ensuring the correctness (I can add a test to make the previous case not passing though). The current code is added for clarity.
The next improvement should be changing the condition to something like
((m.Type == pb.MsgVote && (r.Vote == None || r.Vote == m.From)) ||
			(m.Type == pb.MsgPreVote && m.Term > r.Term)) &&
			r.raftLog.isUpToDate(m.Index, m.LogTerm)

This change requires more test changes.

i am trying to merge in the change #8517 made first.


refactor: replace chalk and fs-extra

optimizes deps in here too :rocket:
node-fetch and https-proxy-agent should be easy to replace once node16 gets dropped
wanted to replace yargs with minimist (already used in pkg) but i'm not familiar with either of the apis
note: i had to use a fs api that was added in node 16 so i bumped @types/node

disabled colors in tests, should fix ci


Suspicious results

Questions about suspicious results ❓
I've trained MaskRCNN with a pre-trained ResNet50 to segment nuclei in immunofluorescence images. The results are really good, so thanks again for this terrific implementation.
However, I've noticed in some cases that an object (here a nucleus) might be cut in multiple small parts (see bottom right part of the attached image).

We can observe that the nucleus labeled 247 is cut in multiple parts.
I get that in most detection/segmentation applications, an object can partially obfuscate another one that is further in a scene. But, is it a normal behavior for this implementation?

Hi,
This could happen with Mask R-CNN (and other detection) models. What probably happened is that the object was split in multiple detections at the box prediction step, and the segmentation head did it's best given the splitted boxes. But I might be wrong :-)
Given that there is nothing actionable that we can do here, I'm closing the issue, but let us know if you have further questions

Thank you for your answer.
I have single bounding box as a result, not multiple, this is why I was surprised.

So, each segmentation mask is associated with a single bounding box, so it would be good to visualize the boxes individually to try to understand what is going on

I didn't save the bounding boxes for this example :-(
But the three pieces that represent object 147 were all in the same box.


Support dual subtitles

Have you read the FAQ and checked for duplicate open issues?
Is your feature request related to a problem? Please describe.
Support dual subtitles.
This is useful for language learning to show subtitles for both the source and target language at the same time.
Describe the solution you'd like
Show one subtitle at the bottom and a second one at the top.
Describe alternatives you've considered

Additional context
https://github.com/TeamPiped/Piped/issues/2768

@joeyparrish can you review it? Thanks!

Duplicate of https://github.com/shaka-project/shaka-player/issues/3436


ResultTable on protobuf metadata

ResultTable will use protobuf metadata if available and fallback to json otherwise.
Most of the work happens in resultUtils.ts specifically in getTypeDefFromProtobuf
All standard types, specialization on all standard types, all standard types in a value type are covered with integration tests. See tests.ts

🎉