[stable/airflow] proper initializatons of variables for airflow chart

What this PR does / why we need it:

ingress.web.annotations and ingress.flower.annotations should be initialized as maps
dags.git.secret should be initialized as empty string

Checklist

[x] DCO signed
[x] Chart Version bumped
[x] Title of the PR starts with chart name (e.g. [stable/chart])

good catch
/lgtm


API with unkown path should return an error

Currently lakeFS register openapi handlers and handle all specific routes.
In case of a call to /api/v1/test, the unknown path under the API prefix, the mux will serve the request by the UI handler and return a valid HTML (UI) page.
The expected behaviour is to return a non-2xx status code with JSON error - prefered the internal error format, so the developer will handle an error and not fail to parse the response in case of a bad API call.

The above bug also affects hadoop-lakefs when the lakefs api endpoint is configured currently.
Example: https://prod.lakefs.dev/api/v/
No handler registered to handle this call and it falls to the default, which is UI handler that returns html with 2xx.

Hey @nopcoder I haven't dug into the code specifics yet but I am hoping to take this up if that is fine, ok? Thanks in advance!
Best,
David D

sure, thanks!

@DataDavD let me know if you have any questions or need help in this one.

Ok great, thank you @nopcoder. I'll take a close look this weekend and return with any questions I'll probably have.
Thanks again!!!!
David

hey @nopcoder just wanted to give you an update. I was able to take a look at the code and believe I understand the specific issue at hand. I intend to look much more closely tomorrow or the following day now that I pinpointed the code at issue; I will most likely send you some clarifying questions then.
Thank you,
dd

thanks for the updates, here for anything that will help you get this one moving.

hey @nopcoder I am assuming the issue is centered around this line of code. I've been having a little trouble reading through the code because a number of objects/types like HandlerFromMuxWithBaseURL show as unresolved refs and I believe are causing my make build to fail with error error generating code: error generating Go handlers for Paths: error generating inlined spec: template: inline.tmpl:5:8: executing "inline.tmpl" at <.>: range can't iterate over . Do you know what the issue is or does this even prevent correcting it, or is just an annoyance for now?
Also to clarify, for any route past /api/v1 return json 401 error instead of UIHandler, correct?

Ahh ok that makes sense; maybe my issue was maybe go 1.15 related, not totally sure though.
Thanks for confirming the issue; I thought that was it but want to verify before I start writing code to handle that. Thank you!!!!

hey @nopcoder took another look/try and still getting the same error for some reason. I'll try and dig in more tomorrow, but in meantime here is the full error
For some reason it freaks out over the swaggerSpec in inline.tmpl. I'll look into why it could be doing this tomorrow as I'm still a bit green with regards to how oapi-codegen is generating the code specifically.
full error:
 error generating code: error generating Go handlers for Paths: error generating inlined spec: templateinline.tmpl:5:8: executing "inline.tmpl" at <.>: range can't iterate over {[H4sIAAAAAAAC/+x9eXPbOLL4V0Hxt1W/ZEu27CRv5q23tl5lnGO8k8PlY2e3xnkqiGxSGJMABwBtazz6 7q9w8BJBUkp0WB7/lVjE0ehudDca3eh7z2dJyihQKbyjey/FHCcggeu/TnFEKJaE0dehBK5+CkD4nKTq N+/I4yAzThGRkAiEVRskJ0SgGxxn4A08ohr9lgGfegOP4gS8I0838wae8CeQYDWmnKbqg5Cc0MibzQbV iROWUdmcecJuUYLp1M4tGTKwtE1qhqnOGkCIs1h6R4cHBwMvwXckyRL9l/qTUPPn3uEgh49QCRHwOQDf QEwS4sROkH9CmYBAwRhxlqXIZ0nCKEo5hOQOBBpPW6AuBlgYXad6zB5C2YkDdEvkpJ9gpnknCLOBx0Gk jArQjHPMaBgTX9PNZ1SCISFO05j4GtDhr0IBdl8Z9C8cQu/I+3/DkiWH5qsYvuWccTNRfWFnIFjGfUD5 lAL9rFZ1gXkE0psNvE9MvmMZDTYIyycmkZlTEYeDz2hAVKN3mMSwAUiqcyI76WzgnQO/AW56rR2GEyqB UxwjMyuyDQfeJcWZnDBOft8EKmqzzQbev3BMAj3DhvBQTpijYJZvJb1XXvs+CPETTI85BEAlwbERxZyl wCUxOwrrVqNrmI5I0Nzf5jO6hik6eaMkjQCJQqYlD8//gwhFWohxA44EIQmN9r2BB3c4SWO1p1//dPL6 5PP5u89vPn36/u2/X388/fDW0wLxA9BITryjUiLm+3/gCfA5yFEJZRNE0wRVIP0WMG//iWP+70tJ3739 eDL86fuPb95+ej8cn96dheT4Pxbun97+pw90Lbl+ywhXvPjLHJpd6/pSDMHGv4KvRcxrXwF6ltEm3cYc U3/ikJkDpXkTIi05G1+BBiNJlAC+90LGEyyVQsAS9vSvDhrADVA5Mj/fe0CV+vpFSe+Rmckb6D8S4BFU llEOwDPaBo2QmMsl4RESy0xUYQmNJNJLT2OQEDjgmKOIBWqQY7IGSxWJNQQUs3eS6wMRskmytNCmfXu+ 1Lue0YBZbMworWf7epdcMyuAxJzjaQMHFYjKaZwry+REiRAjwS7YNThYUuY/z4kQ9M+fL5D+iOQES+Sz LA7QGArrBZejA1LwgZDC6yOgmc4F7Q+aosccCmTXATX2h4sbtZp120LVqfUARXMXCMdmZzSmNmxlrbrm zrUgjxT/NzF5Sckdepsyf6JEmdCqWOGp2DaEyu9eeU3DcuC1bL8EhMARtHyTeMQxjWDU2lviAEutwnBg rAIcn9aZYr5TA1Up5vkpoWDvtl5uNtabNB9mUMFxucB53M4vr52G7WzUh7xvRc3cKvPp2kHdrtixLL8y mbOc2bKxvTS3nHm2qgPWs64tE6yC4HVQTZ2XzrWd85Do12JTLme+zVN9MXPuOONKRl0KI/7rGMnsr10U 0z3nYdMdXdO9IWHo4i7pNhvVh4aVZ1wKo+Kobkd3WXmC/A6j8VSaaebdBCkHodaC5ASQaopYqP+PgwCC oT9RkjgYBqDNNwRUalfBAuScB1kPqLk0YTfGKjSDa9Vg/Qe95qG19jS2qrhpQ/R2t7Im9cr2cHGAbdV3 cyewCeMS2c8I7tIYE0popOkLerA+dHcpt/eYj3EExyyOwbfOKKXtz4yl6MA6hxvCMjEqDx5z7JhRRALF gRjljZHI9O4Nsxi9P0a/snHtXPjdK8D48ODlXvD9i+/2XuGXL/fG/vi/9773D8av8DiEg7+Bc5VLLMc4 uprrifwRDgIOQoAYxcwvGKq+qvyLMqnVcVcde+EuVShGRX+UYv5bBhJJPI4BPUsxl9o6gQCNp8hg7Hlt 6eLl0XCYTPeEZBxHsKesX5FiH4ajGF9DKIYcpJL5jA6LeVwHt8i3J8aFVmHlg2FUxU22L/LFzZqgtzN4 nWfY+dNNRslvGSCi1V5IgKMIKHCsxJgigfaDrpKjnKdYF24HLZyz0CY7y2Joczu06ewCk6MAT6s2bpv1 VA7X6LwwkKINSlhcfrpX3xCog9y5P1p6pS0dByWszgVzlqWOU+Rmz4k9Jm+Lnathbz89LTJT18jbVbiG MH0aNx91UIXLtaIfGbt2uvmwn69lBY68CWPXbVtXf3uQjroqZIMcIeVi5vx2He45i+TtMk5O6ZUZax9Y ROgJNRRx7rT+s9YKTkSLnYA+ah/xNjwpblDONGKbAHEIgQP1W9yEWZJgPnVgWh89HMqgPIO4P1auNZtf 84NMv5JZ8ujT4mjKlzeooMFFzM/6f+dSKc5WMe9PwL8WavevzYGY5FJpZVownUwF8XGcG09uLqidd5f1 GzWmGJSoqo3diXkplsX46nG1Ln/CBohQwbiDHo2zf46+HpJsV8FUeWNlSua0Bnx9YRMsRgnjDq76BHcS pTgCRATCN5jE6tRWkmXMWAxYrzLBd6MU+Ch1Ohg+4juS4BjRLBkDVydDoJITdZoFrmfwKqE1By42pXAn RywMBTiCfvSFVnEdxUGNfQP6+EnzNTgPhSVt5lZeAKoDYAQKWUYDtbfKI63ogXneDMrRPIesQcXKrC7S SUYWE3+69fOEsdIgsbERC7H1edFjptF2YjodLnI1VM7WjpTtblpLmJXt1zMI2+4e22zABc9j1Zvxlpm3 i0q19FXiUbzJkrTdxTDqvybN/TL9LSWO+ps5XSgNQJyDtcHiXnrKBJGMb1Re5G6SjvCWVpGi/Xujwr/X hOsdiUFMhYQEXZ6d6DAhybiR8xkNgMdTQiOkLFIF+DPYj/bRVeFBHGf+NcihYAkMlVEwvPKe9zroHM6S xipdwHeTpN3ebiKw9DgmmFCXGsvjIVIsJXCFqf/9Be/9frD3ty/2370v9y8G372Y/cV9zN8S5uecvPbP vLUx3fIFPRMv/4jEHxMpU/E/fySQ/BEzH8d/SI6pIEDl86PhcP+vf+klaB77sSTFti0Ui828QtkooCM6 ovVcMH8ksCMOGmcDDnU7puumzg3gDfBOCDlQOTJGZZNnbydAEddjKN7ESAe42VuIgWZdM0Julj7TjijV NuQsQYfPEYcYS6IsSYZuJ8SfqP+kwJUgtJagGn7fKQq50eF1oFQnA4GxVFX3AYrIDVA0niKMVK8+jNUX bmZyIfAcpMv7bP1D3SFojtjT2UDfVefSZu4ehVZvUMy9CZjwTSMNfsUU9gMG/SK3mMS5Jqn4O/rQf/+k YEhj7GviU2SGQJorhBkE2djHGlMtcmptiZRjKf4tg2J0GzJnLvMkQzGh1yhLY4YDCFCxbb42Ss5i4mPF B1MHh5RORYTHLJOOydtdD/WxmpdkLMxRasOkEaNojP1rtXSjHZ7JaapwGU/R2wscPfcG3+wA0IcBtewF zhs1PrHMO1pDYFcO0TIeoPPqAartyqA9nK7jADXwIAzB+CKLkIo4ZrfabqFTd4QvLBo6aQevdCl8+u51 ajV7zGhIIocVHjP/WjNLqYhHOjCeyOkZRHDnXL6zW2FNdHfI1VePVT7XoWfOwSIr6cDP5dmJwww3lhZG ShUrswoja7WglLMbEhSy1VpaxnA6NCaWZEMzjbG16nivXt93I6Lz0vkCR0teEBZqcYGDaptauywMTuMr O50LHqn+lZt5foyNLKdZbLxYR5JnsFDAhzvea7t3uI4oti8toK/lClcNvF2T2MTSrcoY/hdwQRhtk1M3 5rMbXU3tIMDPOJHTcwWrlXRYEH+EM2NU60VoF6r6ueQCdbwxLgd2TaBorrPvzG+V1EVzVWcMhBIPKfkJ tBr49VaOCkNlDJgDf5cz3z9/vsjz9jQU+us8GGolyoZw2Fj4Gt6dox8vLk7R69MT1ZFIfZCzX8yPBda8 g/3D/QMFFEuB4pR4R97L/YP9A+ue1xgaqtUOdSakiZoynl5FBk3Bk8A78hTPvTdNBrWk1F/c3FI2GTaS IWeDJfqYRNflupjc0tmXuSTIFwcHK8suK0MpHBlmJqs01l8H3quDw7bRCvCG81lxRTJsX8dqCuGsesfq qflRlNNM4khok0Sx9pfZwEuZcNBZCy0wURpmS4OQP7BgulrMFbJx1sxVfWHwtbrJWkn01dR5dfCqv1OR 57oacmqlA4agTXrOBrV9PLzX/54EMyNEYjC6sk7sN/r3ktg1Irxqih/D13mocRn3GU93CpNmAW2YHLgF 4HuQLYg6eOLWJo4jkO0IntMfWsvaS2OrYy33elWrwtiN7TnvX1r3wDCBZGyfUOjWbh9twycdZy29bhWX QAJj4A9I1aGkoOCDYbvhfSaALy6LLRNOyGJSOSmaPy7RjJIqHjZEzYFzJEO/5dhi4KWZQ9S8DoJeIh92 ElkHq+0uiXEQLEDf9k2Vspj4eYJHpzA/zVs+SfMiVKJNnmusTr9NkG+DmyqSPy3JvX3RnwMzvDeY7ZX+ EvsTQ6J3nCWL2+SWcIEeYLdFv1oBsuvRN4EbNiDdsj+n32qkvyzpfMFaqHzYSmUsd53KZgU5lfMXuDrk f8wiYlyoTn+FjuJfk6eikSHgdFasTkK7HgtxiOpKvmVsVz8BHNjzzTnIvWPjsaxNXMZ8VP2X/8BjP4DD Fy//67u/o1MsJ/8Y/h39KGX6mcZTxx3pbPNGvnXpeke/fKkyUh4NgAskdHAQM3uxlYXUdzdhu1Cvem0T H/d1d/UvX2Y1DMUsEohlEmFk2u1V34sJdIxAB9oWsrOeTKzNmlirspg6baUOx7CNt12PvM2DeeuXSUrV rtNFXJ3VRTBDq4N+lM8/ZLdFGltfcZpTq2+PL2ylqt8rPLCwcfo43BJt+Gx3Gbfh6mDD7LtDXuN2JPdb /Su11S/T4CFJvIMnidfBOZkmVr/EU0ZPt0lzKZ4uABa4ANARpg/ClslEm7+/w5C5FDaCd/Wbuhb7s+b7 bfuwlZM6lW283gd1b8oHdeGBWD49ZxvNMktcyxTc0mfw6F3xWMwdNxLbjR03lg42yOw7ZOa0IbffyPma y6gWzh/69bciO5ViNSXhST3W34Fs05Ilfnf0akULNL9G+Q2xbLf+rjPj2vSr+1XOTkKLXYwq66TwAsJj eI/zzKWFFGon+Rx6tTLVo1GvPbuqTct2om4twu0x8btSvdsQZ+67xcqmWY0+XyCKW6nyp0juzUVyb1d1 d8R/b9TQXOg2SbHm7t0oDRoJ0CSObfUrhOMYBURIQv3y1qW8x5esTNdlHGE6RSxERIqScK4KUCYZkNyA u4BWiGMBzdeCnsKLvmEjfVt00Tq20leGFi3sy3jMkUUbPX1vPK7ITeI/VVhRuwPQ16mGQ5ugWtFHjQJ9 5jEzm1mXZwCb7hnPkxsb9nk983qNErc+kUPodkL+ddSdlSg1w9WRWknXdCJVWd+2jdJzOYCarC5cftAN bI7oOnFZT0Ntx2W+wNVibwI4lhP9iEEr6vRXUwdKWQyvT08s3hARKEsRpgHiGaXmQYQ6Jn/U4x/r8ReR /J/YsUVqMwIrX8CkMqZZBc/fyukz886qDZ/OILVnhtoMqAK5DySAiNdpmHNF7ee+O7jK40oNLpgrXRki rRmRdVdhNMYcUAUpunIqZYhQor2t9q0ftSuKx8JclrQa5yuM6NXfGjreKNtwIFT1rasuBtx4eMCrg7/1 dyoq3K7UL8qrLNrC5POyb3hf9lrAFVrbBf2yucLzj8URugiS2/2hXfg72NLm2CFn6GLI7z8X8ToZljrl tu6eoXnhSAx5Rhe0KaZnqukaId6cV8mpr4qXL3uPm3M9i5qznafL9SU31Gq8uixsZVYYeiNN7p3zE3HD ecWZ0/Bun4ao8fjw3hTsmLUyu5J4GV0zg7sGywuJLOWsWD87uVip5CL7ZPjOSWWsgF8VLw0njF33iM+M /qgb7QJfPYIDX7WkTpssFCn4JCS+5mNDwl0UiRb0lfLy8L5S3Gg2ZJm0XtEOkalQ/tk03BEmdwxUr+m0 LlHMfAlyT0gOOKnzdPGK3phQU+qmkSE4cNSMVGAjS6WdM5Dn4F+ekatV9Vol8A95oyeHmClG0CYbDTZ3 9CpxXFI556KyjuFaz1ndrrgf8mPFOlxbZvBvc2tJuJPDiUzi+rT90qeoxLV5r9WSPLZFN1dxqnQw5WKy bXhv/reAw6vCa33OLrvXH4ujqwvN7Q6uNnytVNq2S9qdU9jdWN6w5TeuCtZvu+PXdSPWKqjrlSkWktNO D7UAWdmrO8VABvgVysOiNnb1YjfloN9gyJmh8SCFVZlFWe2vNQkfauaEXlhr0oS5u4tZtHuhxQXoJs7I MMH+FX1T0PwIcUhj7JvK6zGLLJXVXykWgtDIdkNKhiAsEIfwquoNyllqd+SZ2/TMPdLrkGVm8G3dpdql tTL3Dlijhy/Wnzl6yvX7/LoYCHqna1zbygoYpRz27HbSx28TUAsBwijEJM44PF9xDkzOjs1ttqzMD0gY tp7235AwXL9Np2ZpE7AKPMTCXMxk1KxUmdim7vFueRr1cpay+jZ0gbdWz80biElCcvAeotxfdteYQg6i /wT5Oa+i1G+M2lJJj+UEWRavslye42w3TIGWq2k77gpMiktdaKvgDxdG5ua20bHHuk5ND+x11jrOOAcq 4ykSWZoyLgViNJ6iK++vV54uIBTH7NbW/qoXQ9PtSIgYBRQwEPT/SwR3REg0BVkr0PjXPG7NPPFXwn0S 7n1iFPY+YjkXD1Ap3nh15SzM2BnClmSxJCnmchgynuzlNbsq488Vxy161tHzuV6kTDKLiWotntZbhGZx l7U+o1Gr/d3Ul5ZqRQmzXTHeujtUjS9je32TrGpIpIF3t1c+DbIHd36cBbA31iynoytnLZ6Oc4mjqpBf /emgIHgE2zoiPDaeW4GSE4oepZi88kSx/qKypS3ZOW/tlXpwWavD1AK1dU139ShtSrau2TlYqwr79d5B Nczuugc1s6zEMWjLVw5t7c6u8IVTWxz1ta2Nutasorn6nY5kTgsNsqVa9d7Mi69iDngHw60aa8I00FWB dRZvUVH2lpPCCtcmTVmDO08oK3kjr0/657PNM4c9eBJq+a1s5Zjo1GeF00SZryD0J98Y1PU6vgOEhWA+ wdJUPbe4x7rLFW3QTSeC1CZSK9i/olf0s5wAvyUCBsr2zmeZYIHGABSVThBFezWEAVE1gLtUrX5QpHXr bLqY+PKKqtYTQnWJY64LDmv3bhVayZDkU4QjTOg+Qsc4joEjMWFZHCCfpdP5xmppFG7dbHl6eWGGKher 2tbQto/Qs08MUTBJ5krGIBaGgysqJ0QgIlCQmeLITHucdVFtBbUeWJhHo2lOEeuHK+TS/vOrZu7jB0Kv XYJq9apovgLz4u9ntj3nHU91lehcCj00O6smvYpIgU3J+5zVDbvhspI7nyLF8qvK4S32ec7JjCLNre5N burzOuVttyq2ft3hvfnPSXe0deWWYq23YX2XBTt3C/YwLqxyGq/SdRn5w5RDijmMKre7m4/dOjVAvMd8 rBPB4xh0SGJ5b7yWAp7z01kwzsxcay/p2Tq9mdBpsWI5EUrbWUWmtIaA3dpYAt+AjnoUiIU6UeYGtDlg bRO7NmONRwZJyC+wVMvuUlTQtcVnvYzOs7gjcvU9yAY9znSPdb7Y5J7R9XyTjxT8uxIs6iLQNmJCzzup ugGJUiHoV7gYBEjHBtCcIHbtBmj5PZt7zPR/RhzTCIb35f87bR1lUZ+pVht4t+Ty7MS1ZRWkexpSpFrU ahsVRqrDqxQQbg9P5y8773Fmu+Vv0sfNy7MTfaGEKtgJSVx1NhSO4i3YWCV3rdLKKhjZ8nA/+26ZdZ+4 toVrHxzDrpxXOYRiGGRJuvaDgOu+7E2WpGcQrvUlZDW+mqclyUIgvfo/wy2VwkL16Rm9+meKrQe5DT4o En2eqx1gHXtCMg41OzzsvzfQnMXB9N0Gc52ZuQv+WsfNUpW1vsKPpylQd+YxHDxUZ96K2dHSZwmO1JHJ 38yT5T3WNIkJvd6NG9RGFI8aMX+GVeJxDNo50PJaVJyr8m9ItTs36HpntOHa5HW3qZIvxD6oFezgm/UC WcbThoVAPuOmc2AuQSrRAsbKqj9xUzE/FmH2GEJ5BqEJ7R3ecxJN9N+dUb5unbzBGN8xyFsAqgXC7oX0 Frmboimg1msyzj0nUkKCnvn6zm4MCIicAEc4j6JmvLgaQSdvnucSpA6SZaMtwGO9nynmxR2fG8SctR/o o0ibjqme0wB64V9xja4YetToXOwUT044wChgOvqTZolidXnL7C/l1y+Drzqa3HMlu5qpaI3Es6eUs11P OeN6625UXDoHC1d+vjZMXMkSaPMDteUHbOzNE1aLfa67g+zTuntviNDrI/Nc3IyFzrt8ABrJSQt0hMrv XpXAESohAsMwby9w1DfHByzk3kcWkJAoet0/CF/Uq8MNlC+0xLLXaCvcmQ0u2HTSxtrMGL68ebCa2LJl pcSwp67dZ0uJNSqeSpx3m/axjBLrOiHR7r1qY5FtoiERtqeu1Bhgf262f2hWcd3CXdqYXn4DConbX2ZT u+JrlPX6My02qN2c0ESMAno2ziRKMdcvmheZEAmeKg7GN5jEeByvLA26orIKXDzprC3orDKo/LSWatda d9fVfp11eIv5zM6qzNq/vRCjrqj5XTt12VWVuZAt63raQJvZQIJl3AftoU2ARzC8D0BZU5q/fyifJtsc 5g1E9jjumKeA+NumqSyz+myMe84GTlYTL/ZRYfyESrbWBDQ9izu69GC1k5zZR6Nd0UlcB5UlqX5PYGce FdwEbvzK04QbeT0mrb4eEzZfjzHEWvPjMWaSrquKbvFlGnccUS9Ug0fnju144FXiaEdfd5WGVDn99b/b fNX1AkdrksUXONpemaKwhWuennjteN1Kal6YY81+0TS8lzha4FHXnNX6YrPV5n4sj/E4Udr+jqsTRQcb 2xc7dLhqQeyGr7BkIT2XOKcIkFk6ivG10v3qvNGWYJGl60qO1WMvHkq3mtvVsqT+z0ROzsHn4FTuupay DTpyCIANXPeMcYB4nqq2WgO5dU7NFegWC4RjDjiYIh/H3/rgTr0uZyVRTE9mC5ZiGpRFE0PCbTlrr6US qf7WlQxrEsLdBYZXyE6VaVqYyHUTbrPVW2r/1lF27/16K0c6V14hUMmAMRbEH+nm9hefsWsC5U8Kz5oK riKVtWq2CGiQMqKv/TIee0feEKdkeHPozb7M/i8AAP//8GNnXeXpAAA=] map[]} serve.go:3: running "oapi-codegen": exit status 1

@DataDavD looks from the output that you get a newer version of the oapi-codegen.
As part of the root project we got 'tools.go' that reference the oapi-codegen in order to lock the specific version.

Running make gen on the root project should try to install the specifc versions and generate the code.
I'll check what changed in the oapi-codegen and maybe it is time to update and update the templates.

@DataDavD any luck build the generated code with the specific oapi-codegen library?

hey @nopcoder sorry for the delayed response. Was very busy over weekend so didn't get to touch/look at the code, but I should tonight. I'll let ya know how it goes.
Thanks again for helping me debug!

 Your suggested fixed the issue and now everything appears fine.
I will start working on this issue now that I'm in a non-buggy state in my local repo.
I can't thank you enough for being patient and very helpful. Thanks again for allowing me to contribute.
best,
dd

Hi dd, did you had any progress with this issue? would like to have this bug fix for the next release if possible. Will it be possible to frame it for the following week or two?

hey @nopcoder sorry for the delayed response. I thought I had messaged you prior about being out of town last week. I actually just got back in so I should be able to get this complete or at least a good place within the next week or two. If I have any further issues or think that it won't be doable by EOD Wednesday I'll let ya know and seek your guidance.
Thanks again for your help; and sorry for the delay.
best,
dd

Appreciate it, thank you! I can post a test code that will break that you can use if it will help.

Yea sure anything will help. Currently, I have something of the sorts, but I'm not too sure the specific place to put it although I believe it should be placed in api.NewHandlerWithDefault
if r.URL.Path != BaseURL + "/" { 			writeError(w, http.StatusInternalServerError, err) 			return 		}

hey @nopcoder I was wondering if you saw my last message. I'm still having a little trouble, but am hoping/wanting to finish this before the end of the weekend although I'm a bit unsure of myself, so if this is holding y'all up please tell me as I don't want to do that. In the meantime I will carry on trying to get something working, properly.
Thank you.
Best,
dd

@DataDavD yea, I missed your previous message - sorry about that.
When we set up the routes we have the API's base URL - if you register a handler on that point it will handle all the calls that are not handled by the registered handlers of the open-api. So without any 'if' it will handle this specific case.
Regarding test code - hope this one helps:
// part of serve_test.go
func TestInvalidRoute(t *testing.T) {
	handler, _ := setupHandler(t, "")
	server := setupServer(t, handler)
	clt := setupClientByEndpoint(t, server.URL, "", "")
	cred := createDefaultAdminUser(t, clt)

	// setup client with invalid endpoint base url
	basicAuthProvider, err := securityprovider.NewSecurityProviderBasicAuth(cred.AccessKeyID, cred.SecretAccessKey)
	if err != nil {
		t.Fatal("basic auth security provider", err)
	}
	clt, err = api.NewClientWithResponses(server.URL+api.BaseURL+"//", api.WithRequestEditorFn(basicAuthProvider.Intercept))
	if err != nil {
		t.Fatal("failed to create api client:", err)
	}

	ctx := context.Background()
	resp, err := clt.ListRepositoriesWithResponse(ctx, &api.ListRepositoriesParams{})
	if err != nil {
		t.Fatalf("failed to get lakefs server version")
	}
	if resp.JSONDefault == nil {
		t.Fatalf("client api call expected default error, got nil")
	}
	expectedErrMsg := api.ErrInvalidAPIEndpoint.Error()
	errMsg := resp.JSONDefault.Message
	if errMsg != expectedErrMsg {
		t.Fatalf("client response error message: %s, expected: %s", errMsg, expectedErrMsg)
	}
}

// part of serve.go
var ErrInvalidAPIEndpoint = errors.New("invalid API endpoint")

Thank you for the info and help @nopcoder !!! I'll try and get this finalized tonight/tomorrow. If I still don't have something PR ready I'll hold off to avoid delaying this getting in the next release.
Thanks again!!
dd

Hey @nopcoder I believe I have (at least close to) what is required for the issue fix, but for some reason I have 2 tests failing. One f the failed tests is TestInvalidRoute you provided me but it is failing on the api client call (i.e. the line with if resp.JSONDefault == nil), and for more details the second failed tests is the TestLocalLoad. Am I forgetting to set some auth configs or something?
Last, here is my existing code for this issue fix https://github.com/DataDavD/lakeFS/commit/dfc3b78bff7b77da2ef9eca2a3a5306f1823f4bd

@nopcoder FYI I submitted a PR (https://github.com/treeverse/lakeFS/pull/2382). The tests passed, but I still had one test, TestLocalLoad that still wouldn't pass for some reason. However, I created the PR so we have a good place to review and maybe can also discuss why I'm getting an issue with that particular "local" test.
Thank you for your patience on this and letting me contribute.
Best,
dd

@DataDavD thanks! looking into the PR and I'll add my comments there.
Regarding the failed test - I wanted the error format to match our current default error format, so when the invalid API route fails, all the clients that use the same definition will parse an error as described in the swagger.


Ensure credential list items don't have their text clipped

Task/Issue URL: https://app.asana.com/0/488551667048375/1203911394442538/f
Description
Steps to test this PR
Feature 1

[ ]
[ ]

UI changes

Before
After

!(Upload before screenshot)
(Upload after screenshot)

Current dependencies on/for this PR:

develop

PR #2825   👈

This comment was auto-generated by Graphite.


[Redis] Option to authenticate using name and password

Hi :wave:
I'm using Stash with the Redis driver. As far as I understood from the docs, only a password option can be set. This will enable access as the default user, with a password.
Redis 6 and 7 (as far as I know) allow fine grained ACL rules. Example: I can disable the default user and use another username to authenticate.
My request is to add one more option, user or username, that can be used together with password to authenticate.
Possibly relevant docs on phpredis repo: link.

I'm working on a PR for this feature.


https://paster.so/

Link
https://paster.so/sV7jU
Version
Manifest-v3
What browser(s) are you using?
Chrome browsers (includes brave, edge, opera, etc)
What platform are you using?
Computer (Windows, Linux, MacOS)
(Optional) Anything else?
No response

(https://codeberg.org/Amm0ni4/bypass-all-shortlinks-debloated) Use this


Ignore failure to import fcntl

This wraps import fcntl into a try - except block. If the module is not present, an attempt to use the Button class will fail anyway, but users will be able to run tests on windows.
Fixes #190

Nice!

@ddemidov can you change the "except:" to "except Exception"....the blanket "except:" will catch things that you do not want to catch such as KeyboardInterrupt

Good catch, done

Looking at this some more....how is this not barfing later on (line 2170, 2603, etc) where fcntl.ioctl() is called?

It does. But the point of this is to make possible to run unit tests on windows (the tests do not touch the buttons).

Do the tests use the framebuffer?  That class uses fcntl too.

If the tests used anything that required fnctl, wouldn't they throw an error anyway because they're accessing ev3dev-specific devices? If the offboard tests require a display to be connected to the PC, something else is probably wrong...

True true

Cool! With this merged, the tests should be completely portable.


502 Bad Gateway

Experiencing the same error right now. Looks like the site is completely down.

looks like #76 crashed iron thread


Wip

not ready for merge
TODO list

[ ] tokio::spawn tasks
[ ] get basic TCP connection working
[ ] dummy commands for testing connection

github why close when rename branch?


Fix ND EnqueueTrace hangs due to CQ_DISPATCH_CMD_WAIT being NOP within Trace and add test back to CI

A fix for the hang in this test for issue #7793  and adding the test back to CI, passing now.
Note: Some other Trace issues/potential issues found through this debug, will open another PR for them (they weren't required for this test to pass).
pytest tests/tt_eager/python_api_testing/trace_testing/misc/test_average_pool.py::test_run_average_pool[BFLOAT16-resnet50_unpadded]

Might be an issue here in the change to add the suite to CI, looking into that. CI was clean...except for the Trace suite (darn). It has passing tests....many of them... but then this ... don't know why this is occuring.
SKIPPED [320] tests/tt_eager/python_api_testing/trace_testing/misc/test_bert_ops.py:190: WH ND hang, see issue #4392
================= 146 passed, 328 skipped in 106.44s (0:01:46) =================
                 Device | INFO     | Closing user mode device drivers
                 Always | FATAL    | Mixing fast and slow dispatch is prohibited!
terminate called after throwing an instance of 'std::runtime_error'
  what():  TT_FATAL @ ./tt_metal/detail/tt_metal.hpp:37: fd == isFastDispatch
info:
Mixing fast and slow dispatch is prohibited!

Also including fixes for #8064 and #6020 in order to be able to add tests to CI.


Check negative evolution until we reach minimum ratio only

Moved from AmadeusITGroup/sonar-stash#110

@kingoleg
Looking at your original request, it seems that your requested behaviour of the combination of sonar-coverage-evolution and the builtin rules will be possible by dropping sonar-coverage evolution.
Truth table:
(X -> create issue, O -> no issue)
         builtin | X      O
s-c-e            |
----------------------------------
X                | X      O
O                | X      O

We can't modify the builtin rule, so the first column is fixed.
When both plugins are happy then we don't want an issue (lower right).
If I interpret your description of AmadeusITGroup/sonar-stash#110 correctly, this corresponds to the upper right.
So s-c-e has no influence in this setting.

Also, I can't find a way to access to parameters of arbitrary rules


insert sequence

Now in the sequence editor, you can easily drag a key frame to change the time, but sometimes I want to drag a frame to make the subsequent frames automatically move back. Is there such a function?
I tried holding down shift to select all the subsequent frames, but it becomes very troublesome when there are a lot of frames, and shift cannot select key frames outside the window.
please help me

It would be good to have a virtual keyframe/marker that selects the whole sequence. Some systems have a different shape symbol in the center of a sequence for this purpose.

When there are a lot of keyframes (hundreds), it becomes extremely difficult to operate the sequence, and dragging these keyframes is very stuck. I hope the author will optimize it.


chore: fix some typos in comments

Please ensure you adhere to every item in this list

[ ] This PR was pre-approved by the project maintainer
[ ] I have self-reviewed the code
[ ] I have added all necessary tests

Describe your changes
fix some typos in comments
Issue number and link
Pull request require a prior issue with discussion.
Include the issue number of link here.

Thanks :)


Pod events tab empty state message

Pod events are not a resource, this message should say No events found.

@showeimer Thanks for reporting the issue!
The content in Events Tab is the execution result of command kubectl get events --field-selector involvedObject.name=... and -o custom-columns.
So, the message No resources found is actually from kubectl. (FYI: I explicitly wrote the stringNo resources found in the events tab implementation code just because the error message is lost when the output format is custom-columns.)
Another concern: Events is actually in Kubernetes resource list, so I'd say the return message is at least not wrong. https://kubernetes.io/docs/reference/kubectl/overview/#resource-types
We could discuss if we want to improve this message from UX standpoint.

@myan9 good find!  I think this behavior is okay then, usually from UI standpoint it is better to be more explicit in what exactly is missing; but for KUI it is probably better to just return the CLI message.  I'll close the issue.


Non-ASCII device names are not handled correctly

Related: dechamps/FlexASIO#73
FlexASIO uses UTF-8 for device names everywhere, on the output of PortAudioDevices and in the configuration file.
However, FlexASIO GUI appears to be using the wrong encoding, as shown below when using the device name "Headéset":

It seems to be interpreting the device name in some kind of local 8-bit encoding (maybe CP 850 or ISO-8859-1) instead of UTF-8. FlexASIO GUI then ends up writing a configuration file with the wrong device name.

This should be fixed with v0.2 now. (had to encode the incoming names from Portaudio to Windows-1252 and back to Unicode...

Thanks. I'm a bit confused as to why you'd need to do any conversions. I certainly don't do any in FlexASIO - PortAudio natively exposes device names as UTF-8 in its API, and I just use them as-is. I'm baffled as to why you'd need to use Windows-1252 anywhere, and I suspect it might cause problems with non-western-European character sets.

Portaudio, at least as implemented in PortaudioSharp, give me the mangled names. But once converted to 1252 and then back to UTF, they appear fine. I don't have any way to configure Portaudio through the abstraction layer of portaudiosharp (don't even remember where I found that....). But it works. So... let's not question it too much :)


RuntimeError: FIND was unable to find an engine to execute this computation

Hi, I'm running python tools/train.py after configuring the environment following these steps：
pip install -r requirements.txt python3 setup.py develop
Then I ran into the following problem:
`2023-03-22 12:38:45 | INFO     | yolox.core.trainer:203 - ---> start train epoch1
2023-03-22 12:38:46 | INFO     | yolox.core.trainer:195 - Training of experiment is done and the best AP is 0.00
2023-03-22 12:38:46 | ERROR    | yolox.core.launch:98 - An error has been caught in function 'launch', process 'MainProcess' (22906), thread 'MainThread'<PHONE_NUMBER>57280):
Traceback (most recent call last):
File "tools/train.py", line 137, in
launch(
└ <function launch at 0x7efc2ede65e0>

File "/home/ding/fyw/YOLOX/yolox/core/launch.py", line 98, in launch
main_func(*args)
│          └ (╒═══════════════════╤═══════════════════════════════════════════════════════════════════════════════════════════════════════...
└ <function main at 0x7efc20e4ee50>

File "tools/train.py", line 118, in main
trainer.train()
│       └ <function Trainer.train at 0x7efc1fcad0d0>
└ <yolox.core.trainer.Trainer object at 0x7efc1fcae1c0>
File "/home/ding/fyw/YOLOX/yolox/core/trainer.py", line 76, in train
self.train_in_epoch()
│    └ <function Trainer.train_in_epoch at 0x7efc1fcad8b0>
└ <yolox.core.trainer.Trainer object at 0x7efc1fcae1c0>
File "/home/ding/fyw/YOLOX/yolox/core/trainer.py", line 85, in train_in_epoch
self.train_in_iter()
│    └ <function Trainer.train_in_iter at 0x7efc1fcad940>
└ <yolox.core.trainer.Trainer object at 0x7efc1fcae1c0>
File "/home/ding/fyw/YOLOX/yolox/core/trainer.py", line 91, in train_in_iter
self.train_one_iter()
│    └ <function Trainer.train_one_iter at 0x7efc1fcad9d0>
└ <yolox.core.trainer.Trainer object at 0x7efc1fcae1c0>
File "/home/ding/fyw/YOLOX/yolox/core/trainer.py", line 110, in train_one_iter
self.scaler.scale(loss).backward()
│    │      │     └ tensor(25.0141, device='cuda:0', grad_fn=)
│    │      └ <function GradScaler.scale at 0x7efc319b9b80>
│    └ <torch.cuda.amp.grad_scaler.GradScaler object at 0x7efc1fcae2b0>
└ <yolox.core.trainer.Trainer object at 0x7efc1fcae1c0>
File "/home/ding/anaconda3/envs/yolox/lib/python3.8/site-packages/torch/_tensor.py", line 487, in backward
torch.autograd.backward(
│     │        └ <function backward at 0x7efc31629160>
│     └ <module 'torch.autograd' from '/home/ding/anaconda3/envs/yolox/lib/python3.8/site-packages/torch/autograd/init.py'>
└ <module 'torch' from '/home/ding/anaconda3/envs/yolox/lib/python3.8/site-packages/torch/init.py'>
File "/home/ding/anaconda3/envs/yolox/lib/python3.8/site-packages/torch/autograd/init.py", line 200, in backward
Variable._execution_engine.run_backward(  # Calls into the C++ engine to run the backward pass
│        │                 └ <method 'run_backward' of 'torch._C._EngineBase' objects>
│        └ <torch._C._EngineBase object at 0x7efc3a354d20>
└ <class 'torch.autograd.variable.Variable'>
RuntimeError: FIND was unable to find an engine to execute this computation
`
Does this mean I failed to compile successfully?

I reinstalled pytorch and the problem was fixed. I think it was caused by the wrong cuda version of pytorch

我也是重新安装了pytorch，是少安装了一些pytorch附加库，重新安装pytorch即可解决

can anyone let me know what version of pytorch and cuda you are using?

can anyone let me know what version of pytorch and cuda you are using?

Yep same. Did you reinstall the same torch version? (in my case, it's 2.2.1).


fix typo in Timex.Comparable doc

fixed typo in Timex.Comparable doc
cooresponding -> corresponding

Coverage decreased (-0.04%) to 72.08% when pulling 22fe8091adc61c168da6b7a1708e11187f2eb518 on daskycodes:master into 45424fa293066b210eaf94dd650707343583d085 on bitwalker:master.


Add build for Rx.DOM.umd.js

Add build target for generating Rx.DOM.umd.js

@randallr , this issue is being tracked by publishing strategy issue https://github.com/ReactiveX/rxjs/issues/1506 - so let me close this one. If there's suggestion, feel freely suggest via #1506. Once it's established, probably there'll be separate npm package supporting rxjs-dom module.


dark mode with white images

Issue transferred from: https://github.com/edrlab/thorium-reader/issues/1605
Originally posted by @civodulab
Why does the sepia theme change the white of my image ?
Tested on a .png and .jpg image.
Sepia theme

Night Theme

CSS reference:
https://github.com/readium/readium-css/blob/583011453612e6f695056ab6c086a2c4f4cac9c0/css/src/modules/ReadiumCSS-night_mode.css#L49-L72

But I need to keep the white of my image in sepia mode. How do I do this?

A workaround that doesn't involve an update of Readium CSS is to use the day mode (appearance 0) and set the text and background colors manually:
  --RS__backgroundColor: #faf4e8;
  --RS__textColor: #121212;

Yeah this is caused by the following in sepia mode:
https://github.com/readium/readium-css/blob/583011453612e6f695056ab6c086a2c4f4cac9c0/css/src/modules/ReadiumCSS-sepia_mode.css#L42-L47
At the time mix-blend-mode was added to keep consistent with other apps doing this in sepia mode as well. Maybe we should revisit this decision if authors prefer to keep the background white.


fix: make selectAccountIdsByAssetId call stable in FoxEthProvider

Description
Currently, selectAccountIdsByAssetId is somehow unstable, despite the output being deeply equal.
https://github.com/shapeshift/web/blob/e69906f95940a3e3b8dffc7831875f4ec15db1e8/src/context/FoxEthProvider/FoxEthProvider.tsx#L89-L91
When called in EthProvider, this invalidated reference on every call causes ethAccountIds to invalidate, and the memoized callback to invalidate as a return in refetchFoxEthLpAccountData deps.
https://github.com/shapeshift/web/blob/e69906f95940a3e3b8dffc7831875f4ec15db1e8/src/context/FoxEthProvider/FoxEthProvider.tsx#L93-L108
Since we have an effect reacting on readyToFetchLpData and refetchFoxEthLpAccountData reference to fire refetch, this causes refetch to fire infinitely, causing an infinite XHR loop and performance issues.
This is a quick fix for it until we actually make the selector stable
Notice

[x] Have you followed the guidelines in our Contributing guide?
[x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

Pull Request Type

[x] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)
N/A
Risk

This makes things more stable, if this breaks somethings, we have bigger problems
Testing

Go to an UTXO asset page
The page should be stable i.e

everything should load
hovering over UI elements/clicking them e.g time frame buttons shouldn't be laggy, which would indicate stuck event loop, and as a result of our logic, congested main thread being extremely slow at painting

Open your console and filter messages by 'message' handler took. There should be a few (~5-15) which is the normal behavior, but you shouldn't see this number increase every second or so infinitely

Engineering
☝🏽
Operations
☝🏽
Screenshots (if applicable)

Current dependencies on/for this PR:

develop

PR #3092   👈

PR #3093

This comment was auto-generated by Graphite.


versions ios

hello can i start to do an ios version :)

it would be fantastic ;)))

Perhaps a great reason to mention I am considering porting this to Unity


OSError: [Errno 24] Too many open files

It seems that moving to POSIX shared memory may have added limitations to pshmem.  One of my workflows is failing with
Process 0: MPIShared_e5ec3957d523 failed MMap of 115168 bytes (14396 elements of 8 bytes each): [Errno 24] Too many open files
TOAST ERROR: Proc 0: Traceback (most recent call last):
Proc 0:   File "/home/reijo/.conda/envs/toastdev/lib/python3.11/site-packages/toast/mpi.py", line 509, in exception_guard
    yield
Proc 0:   File "/home/reijo/.conda/envs/toastdev/bin/toast_so_sim.py", line 934, in <module>
    main()
Proc 0:   File "/home/reijo/.conda/envs/toastdev/bin/toast_so_sim.py", line 913, in main
    data = simulate_data(job, args, toast_comm, telescope, schedule)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Proc 0:   File "/home/reijo/.conda/envs/toastdev/bin/toast_so_sim.py", line 327, in simulate_data
    ops.sim_ground.apply(data)
Proc 0:   File "/home/reijo/.conda/envs/toastdev/lib/python3.11/site-packages/toast/timing.py", line 107, in df
    return f(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^
Proc 0:   File "/home/reijo/.conda/envs/toastdev/lib/python3.11/site-packages/toast/ops/operator.py", line 107, in apply
    self.exec(data, detectors, use_accel=use_accel, **kwargs)
Proc 0:   File "/home/reijo/.conda/envs/toastdev/lib/python3.11/site-packages/toast/timing.py", line 107, in df
    return f(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^
Proc 0:   File "/home/reijo/.conda/envs/toastdev/lib/python3.11/site-packages/toast/ops/operator.py", line 47, in exec
    self._exec(
Proc 0:   File "/home/reijo/.conda/envs/toastdev/lib/python3.11/site-packages/toast/timing.py", line 81, in df
    return f(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^
Proc 0:   File "/home/reijo/.conda/envs/toastdev/lib/python3.11/site-packages/toast/ops/sim_ground.py", line 597, in _exec
    ob.shared.create_column(
Proc 0:   File "/home/reijo/.conda/envs/toastdev/lib/python3.11/site-packages/toast/observation_data.py", line 1352, in create_column
    MPIShared(
Proc 0:   File "/home/reijo/.conda/envs/toastdev/lib/python3.11/site-packages/pshmem/shmem.py", line 195, in __init__
    self._shmap = mmap.mmap(
                  ^^^^^^^^^^
Proc 0: OSError: [Errno 24] Too many open files

When I run against pshem version right before the merge of the POSIX branch, there is no problem.

I guess it is not surprising that the OS limit for shared memory segments (i.e. open files) gets hit eventually.  This is set by a kernel config parameter for the whole node and the per-user limit is shown with ulimit -Sn.  Here is a page with more discussion.
The surprising thing is that this per user/process limit is (apparently) smaller than the limit on MPI shared memory windows, which is globally across the system.

Is this at NERSC or on the simons1 machine?
Can you try increasing the limit in the same shell where you running the workflow?  Something like ulimit -n 8192 before mpirun / srun.

I tried ulimit -n 8192 but the workflow still failed. I had issues on simons1 and on my laptop running Fedora.


Sort exclusions for data tables

Summary
Sort exclusions allow specific rows to be excluded from a sort so that they appear at the top or bottom of a sorted list.
💰 User value
This allows specific data to be pinned to top or bottom and be excluded from sort. This could be useful when certain values don't have content within a sortabel column.
📚 User Stories
If relevant, describe the high-level functionality as user stories.
As an ICDS developer
I need to be able to specify rows to be excluded from a sort
So that they can be positioned to top or bottom of a table regardless of sort.
📝 Acceptance Criteria
If relevant, describe in full detail the different interactions and edge cases that the component or patterns needs to fulfil.
Given that a data table exists with a column that is sortable,
When setting the data table column sort properties
Then specific rows can be excluded,
and the position of the excluded rows can be set to either 'top'(default) or 'bottom'.
✏ Designs
If there's a Figma design file (or other mock-up), include it here.
## 🧾 Guidance
If there's written guidance or documentation, include it here.

Extends functionality applied in ticket https://github.com/mi6/ic-ui-kit/issues/790 . Ticket is dependent on 790.
Relates to ticket #76 .


No need to check "Windows Technical Preview 2"

No need to check "Windows Technical Preview 2" for Definiton Updates
Summarize the change in the pull request title
Describe your change, specifically why you think it's needed.
Fixes #Issue_Number (if necessary)
@Article_Author please review (look at the author metadata tag)

Thanks @Rei-Ikei for your contribution! That text is likely a hold-over from the early days of Windows 10. Looks good, #sign-off
Once merged, this should be live with the next daily publishing process. Right now that should be tomorrow (Friday, 19 October) around 11:00 Pacific time. No further action needed from you.


feat: require golang 1.20 or later

Can you update the Go versions used in CI? https://github.com/googleapis/api-linter/tree/main/.github/workflows

done!


Simplified reource deployment

Is your feature request related to a problem? Please describe.
Deploying resources using the hardcoded GUID is inefficient and is not scalable. Propose how the robot can request the specific resource to be deployed.
In the future, the request can include the semantic specification of the task that will be planned for the robot.

Please, refer to the new document created: https://github.com/5G-ERA/middleware/blob/main/docs/Proposals/Feature79Proposal.md


Chrome extension privacy permissions too broad?

Is "Read and change all your data on the websites you visit" really necessary?

Visual History's popup is just html injected into the page, which Google views as "reading and changing all the data on websites you visit". That warning is even triggered whenever there's a content script that matches all all urls, regardless of whether the extension actually uses it or not.
I agree that it's misleadingly broad, which is one of the reasons this is open-source.
A possible alternative would be using the activeTabs permissions, but I think that wouldn't let the extension track tab info unless the user generate some request on that page. I'll look into it.

This would great to have.
Would it be possible to get all the required tab info by just requesting permissions on history ?

Unfortunately, history doesn't provide enough information to provide a tree structure of a user's browsing history. For a given page, the extension needs to know the parent page (that is, which site the user was on when they went to the next page). Because a history only provides a chronologically linear list of sites (which this extension aims to enhance), there's no way to gather that information from history alone.

Thanks for the prompt response.
Looking at chrome.history API the VisitItem object has the property referringVisitId which is "The visit ID of the referrer.". Coupling this with TransitionType wouldn't it be possible to get info on the parent page.

So there are three possible ways to update internal state with the Chrome extension API, each of which have pros and cons, particularly relating to a few key edge cases.
Relevant APIs

history: tracking history.onVisited events
webNavigation: tracking webNavigation.onCommitted events
tabs: listening for updates to tab.url in tabs.onUpdated

Edge cases

Server redirects (eg auto-corrected Wikipedia links or Google search results)

only webNavigation does this right

Instant tabs (where the content is loaded in a shadow tab with no 'referrer', and then replaced)

history can't track onTabReplaced events

Custom history state manipulation (eg React Router or the Issues/PR tabs on GitHub repos)

history misses this, but tabs does it naturally and webNavigation has an onHistoryStateUpdated event that catches it

Since the tabs permission was already necessary for injecting the html for the overlay, and since the tabs.onUpdated was by far the cleanest to implement, I decided to prioritize simplicity by keeping it.
Personally, I'd love to ditch the html injection altogether and have the whole interface in a popup from the browser item, at which point we could move state to the history or webNavigation API to get rid of the "read and change all websites" warning, but until this feature get added in Chrome we're stuck with html injection via tabs, and since we're already declaring tabs it seems best to also use that for tracking history, as opposed to adding another permission for that.
However, if there is a compelling case as to why history (or webNavigation) would be better, I'd love to hear it (or review pull requests!).


function calling documentation

While searching the web I couldn't yet find a resource except function callilng through mistral_inference package.
I am curious whether anyone wrote a raw prompt in which function calling is working?

Maybe you should try it：
https://github.com/812781385/ollama-webUI

An example of function calling documentation is https://docs.mistral.ai/capabilities/function_calling/
If you want to do function calling without using an LLM specific package, it can be done with direct HTTP calls, for example with the python requests package or using shell tools.  For instance, if we take the mistral document from above, we can transpose it into a shell script.
First we set the model.  This can be any tool-supporting model, but you asked about mistral-nemo so we'll use that:
model="mistral-nemo"

Then we create the tool list.  This is copied from the mistral doc with some syntax changes to account for the difference between python and JSON structures:
tools='[
  {
        "type": "function",
        "function": {
            "name": "retrieve_payment_status",
            "description": "Get payment status of a transaction",
            "parameters": {
                "type": "object",
                "properties": {
                    "transaction_id": {
                        "type": "string",
                        "description": "The transaction id."
                    }
                },
                "required": ["transaction_id"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "retrieve_payment_date",
            "description": "Get payment date of a transaction",
            "parameters": {
                "type": "object",
                "properties": {
                    "transaction_id": {
                        "type": "string",
                        "description": "The transaction id."
                    }
                },
                "required": ["transaction_id"]
            }
        }
    }
]
'

Next we construct the message that will be answered by the LLM using the tools:
messages='[
        {
            "content": "What'\''s the status of my transaction T1001?",
            "role": "user"
        }
    ]
'

Now we create the data that is sent to the LLM:
data='
  {
    "messages": '"$messages"',
    "tools": '"$tools"',
    "model": "'$model'",
    "temperature": 0.3
  }
'

Finally, send the query to ollama:
curl -s --location --request POST 'http://localhost:11434/v1/chat/completions' \
--header 'Content-Type: application/json' \
--data "$data"

The result is:
{
  "id": "chatcmpl-956",
  "object": "chat.completion",
  "created":<PHONE_NUMBER>,
  "model": "mistral-nemo",
  "system_fingerprint": "fp_ollama",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "",
        "tool_calls": [
          {
            "id": "call_bst9zzpx",
            "type": "function",
            "function": {
              "name": "retrieve_payment_status",
              "arguments": "{\"transaction_id\":\"T1001\"}"
            }
          }
        ]
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 125,
    "completion_tokens": 27,
    "total_tokens": 152
  }
}

The script then needs to iterate over the tools calls and make the actual function call to retrieve the data:
$ resp=$(./function-call)
$ echo "$resp" | jq -c .choices[].message.tool_calls[]
{"id":"call_t6chpn4u","type":"function","function":{"name":"retrieve_payment_status","arguments":"{\"transaction_id\":\"T1001\"}"}}
$ for tool_call in $(echo "$resp" | jq -c .choices[].message.tool_calls[]) ; do
  function=$(echo "$tool_call" | jq -r .function.name)
  _=$(which $function) || { echo "function $function not found" ; break ; }
  args=$(echo "$tool_call" | jq -r .function.arguments)
  $function $args    # do the function
done

The python equivalent using requests is:
#!/usr/bin/env python3

import requests

model="mistral-nemo"

tools = [
  {
        "type": "function",
        "function": {
            "name": "retrieve_payment_status",
            "description": "Get payment status of a transaction",
            "parameters": {
                "type": "object",
                "properties": {
                    "transaction_id": {
                        "type": "string",
                        "description": "The transaction id."
                    }
                },
                "required": ["transaction_id"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "retrieve_payment_date",
            "description": "Get payment date of a transaction",
            "parameters": {
                "type": "object",
                "properties": {
                    "transaction_id": {
                        "type": "string",
                        "description": "The transaction id."
                    }
                },
                "required": ["transaction_id"]
            }
        }
    }
]

messages = [
    {
        "content": "What'\''s the status of my transaction T1001?",
        "role": "user"
    }
]

data={
    "messages": messages,
    "tools": tools,
    "model": model,
    "temperature": 0.3
}

response = requests.post('http://localhost:11434/v1/chat/completions',
    headers={"Content-Type": "application/json"},
    json=data)

print(response.text)

An example of function calling documentation is https://docs.mistral.ai/capabilities/function_calling/
If you want to do function calling without using an LLM specific package, it can be done with direct HTTP calls, for example with the python requests package or using shell tools.  For instance, if we take the mistral document from above, we can transpose it into a shell script.
First we set the model.  This can be any tool-supporting model, but you asked about mistral-nemo so we'll use that:
model="mistral-nemo"

Then we create the tool list.  This is copied from the mistral doc with some syntax changes to account for the difference between python and JSON structures:
tools='[
  {
        "type": "function",
        "function": {
            "name": "retrieve_payment_status",
            "description": "Get payment status of a transaction",
            "parameters": {
                "type": "object",
                "properties": {
                    "transaction_id": {
                        "type": "string",
                        "description": "The transaction id."
                    }
                },
                "required": ["transaction_id"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "retrieve_payment_date",
            "description": "Get payment date of a transaction",
            "parameters": {
                "type": "object",
                "properties": {
                    "transaction_id": {
                        "type": "string",
                        "description": "The transaction id."
                    }
                },
                "required": ["transaction_id"]
            }
        }
    }
]
'

Next we construct the message that will be answered by the LLM using the tools:
messages='[
        {
            "content": "What'\''s the status of my transaction T1001?",
            "role": "user"
        }
    ]
'

Now we create the data that is sent to the LLM:
data='
  {
    "messages": '"$messages"',
    "tools": '"$tools"',
    "model": "'$model'",
    "temperature": 0.3
  }
'

Finally, send the query to ollama:
curl -s --location --request POST 'http://localhost:11434/v1/chat/completions' \
--header 'Content-Type: application/json' \
--data "$data"

The result is:
{
  "id": "chatcmpl-956",
  "object": "chat.completion",
  "created":<PHONE_NUMBER>,
  "model": "mistral-nemo",
  "system_fingerprint": "fp_ollama",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "",
        "tool_calls": [
          {
            "id": "call_bst9zzpx",
            "type": "function",
            "function": {
              "name": "retrieve_payment_status",
              "arguments": "{\"transaction_id\":\"T1001\"}"
            }
          }
        ]
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 125,
    "completion_tokens": 27,
    "total_tokens": 152
  }
}

The script then needs to iterate over the tools calls and make the actual function call to retrieve the data:
$ resp=$(./function-call)
$ echo "$resp" | jq -c .choices[].message.tool_calls[]
{"id":"call_t6chpn4u","type":"function","function":{"name":"retrieve_payment_status","arguments":"{\"transaction_id\":\"T1001\"}"}}
$ for tool_call in $(echo "$resp" | jq -c .choices[].message.tool_calls[]) ; do
  function=$(echo "$tool_call" | jq -r .function.name)
  _=$(which $function) || { echo "function $function not found" ; break ; }
  args=$(echo "$tool_call" | jq -r .function.arguments)
  $function $args    # do the function
done

The python equivalent using requests is:
#!/usr/bin/env python3

import requests

model="mistral-nemo"

tools = [
  {
        "type": "function",
        "function": {
            "name": "retrieve_payment_status",
            "description": "Get payment status of a transaction",
            "parameters": {
                "type": "object",
                "properties": {
                    "transaction_id": {
                        "type": "string",
                        "description": "The transaction id."
                    }
                },
                "required": ["transaction_id"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "retrieve_payment_date",
            "description": "Get payment date of a transaction",
            "parameters": {
                "type": "object",
                "properties": {
                    "transaction_id": {
                        "type": "string",
                        "description": "The transaction id."
                    }
                },
                "required": ["transaction_id"]
            }
        }
    }
]

messages = [
    {
        "content": "What'\''s the status of my transaction T1001?",
        "role": "user"
    }
]

data={
    "messages": messages,
    "tools": tools,
    "model": model,
    "temperature": 0.3
}

response = requests.post('http://localhost:11434/v1/chat/completions',
    headers={"Content-Type": "application/json"},
    json=data)

print(response.text)

wow thank you for comprehensive answer, I will try it asap when I get back to mt pc
cheers

An example of function calling documentation is https://docs.mistral.ai/capabilities/function_calling/
If you want to do function calling without using an LLM specific package, it can be done with direct HTTP calls, for example with the python requests package or using shell tools. For instance, if we take the mistral document from above, we can transpose it into a shell script.
First we set the model. This can be any tool-supporting model, but you asked about mistral-nemo so we'll use that:
model="mistral-nemo"

Then we create the tool list. This is copied from the mistral doc with some syntax changes to account for the difference between python and JSON structures:
tools='[
  {
        "type": "function",
        "function": {
            "name": "retrieve_payment_status",
            "description": "Get payment status of a transaction",
            "parameters": {
                "type": "object",
                "properties": {
                    "transaction_id": {
                        "type": "string",
                        "description": "The transaction id."
                    }
                },
                "required": ["transaction_id"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "retrieve_payment_date",
            "description": "Get payment date of a transaction",
            "parameters": {
                "type": "object",
                "properties": {
                    "transaction_id": {
                        "type": "string",
                        "description": "The transaction id."
                    }
                },
                "required": ["transaction_id"]
            }
        }
    }
]
'

Next we construct the message that will be answered by the LLM using the tools:
messages='[
        {
            "content": "What'\''s the status of my transaction T1001?",
            "role": "user"
        }
    ]
'

Now we create the data that is sent to the LLM:
data='
  {
    "messages": '"$messages"',
    "tools": '"$tools"',
    "model": "'$model'",
    "temperature": 0.3
  }
'

Finally, send the query to ollama:
curl -s --location --request POST 'http://localhost:11434/v1/chat/completions' \
--header 'Content-Type: application/json' \
--data "$data"

The result is:
{
  "id": "chatcmpl-956",
  "object": "chat.completion",
  "created":<PHONE_NUMBER>,
  "model": "mistral-nemo",
  "system_fingerprint": "fp_ollama",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "",
        "tool_calls": [
          {
            "id": "call_bst9zzpx",
            "type": "function",
            "function": {
              "name": "retrieve_payment_status",
              "arguments": "{\"transaction_id\":\"T1001\"}"
            }
          }
        ]
      },
      "finish_reason": "stop"
    }
  ],
  "usage": {
    "prompt_tokens": 125,
    "completion_tokens": 27,
    "total_tokens": 152
  }
}

The script then needs to iterate over the tools calls and make the actual function call to retrieve the data:
$ resp=$(./function-call)
$ echo "$resp" | jq -c .choices[].message.tool_calls[]
{"id":"call_t6chpn4u","type":"function","function":{"name":"retrieve_payment_status","arguments":"{\"transaction_id\":\"T1001\"}"}}
$ for tool_call in $(echo "$resp" | jq -c .choices[].message.tool_calls[]) ; do
  function=$(echo "$tool_call" | jq -r .function.name)
  _=$(which $function) || { echo "function $function not found" ; break ; }
  args=$(echo "$tool_call" | jq -r .function.arguments)
  $function $args    # do the function
done

The python equivalent using requests is:
#!/usr/bin/env python3

import requests

model="mistral-nemo"

tools = [
  {
        "type": "function",
        "function": {
            "name": "retrieve_payment_status",
            "description": "Get payment status of a transaction",
            "parameters": {
                "type": "object",
                "properties": {
                    "transaction_id": {
                        "type": "string",
                        "description": "The transaction id."
                    }
                },
                "required": ["transaction_id"]
            }
        }
    },
    {
        "type": "function",
        "function": {
            "name": "retrieve_payment_date",
            "description": "Get payment date of a transaction",
            "parameters": {
                "type": "object",
                "properties": {
                    "transaction_id": {
                        "type": "string",
                        "description": "The transaction id."
                    }
                },
                "required": ["transaction_id"]
            }
        }
    }
]

messages = [
    {
        "content": "What'\''s the status of my transaction T1001?",
        "role": "user"
    }
]

data={
    "messages": messages,
    "tools": tools,
    "model": model,
    "temperature": 0.3
}

response = requests.post('http://localhost:11434/v1/chat/completions',
    headers={"Content-Type": "application/json"},
    json=data)

print(response.text)

@rick-github This example uses the mistral client and not ollama. Ollama does not have native support for tool use as of yet.

@ronneldavis Tool support is evolving but ollama supports tool use with tool supporting models since https://github.com/ollama/ollama/pull/5284.  This example code does not use the mistral client.

@rick-github Oh that's awesome! I believe the documentation hasn't been updated with the new addition so my apologies

Hi there! Function calling is now supported in Ollama. See https://ollama.com/blog/tool-support or the api documentation: https://github.com/ollama/ollama/blob/main/docs/api.md#chat-request-with-tools

thank you thank you thank you


"Speak Text with Eleven Labs" has a secret stored in it

You left your API key in the shortcut, I am able to generate TTS and do other API calls. Im not sure if that was intentional or not because the account has no custom voices so maybe its some limited key

Oops! It has no billing setup for it so it caps at four hours if dictation per month.
Thanks for letting me know. I’ll push a new version and cancel that key.


CXXCBC-58: do not use nodes ejected during rebalance

@jrawsthorne To be fair, I think this change makes sense generally speaking, even if we don't yet have a fix for the issue you were seeing.


Update vc and group experience for user

Coverage decreased (-0.1%) to 34.226% when pulling 55126a97afe3b192f4f0b3c27b35e7539ea500f0 on yiyi/vc_and_group_experience_for_user into 59e661e7406b564d3772ec1d986739803275c413 on master.

@yiyione may you book a quick demo with us? cc @qfyin @yangou1988


Account register implementation

This only fixes the params.. however I just figured the code does not even create a player yet.

Created a account registration implementation

Looks good to me


Fix typo > Asyncronous > Asynchronous

Just wanted to create a new release, and found this typo 😅  Lets fix this first, and then release :)
Release notes:
* Change type to symfony-bundle for Symfony Flex #14
* Add `AsynchronousCommandBus and AsynchronousEventBus classes to support Symfony Autowiring #15 #18
* AutoRegister all public methods #16

Done!

Thanks, tagged https://github.com/SimpleBus/AsynchronousBundle/releases/tag/v3.0.1


[release/1.6 backport] [CRI] fix additionalGids: it should fallback to imageConfig.User when securityContext.RunAsUser,RunAsUsername are empty

(partial) backport of:

https://github.com/containerd/containerd/pull/8136
https://github.com/containerd/containerd/pull/8370

:warning: conflict due to sbserver not being in this branch, so ignore those files
Also removed https://github.com/containerd/containerd/commit/50740a1a0ce283888853155272c5962e1d2e7076 from the backport, as it requires go1.18 (and we still verify on go1.17)

What is the issue
I found a bug in setting runtime.Spec.Process.User.additionalGids in CRI server/sbserver.
If LinuxContainerSecurityContext.{RunAsUser,RunAsUsername} are empty, contained should fallback to the container image's Config.User for resolving the primary user and use it to inspect /etc/group in the container image for resolving additionalGids. But containerd always fallback to 0.
Fortunately, in the use of Kubernetes+containerd, the bug does NOT happen because kubelet always fills out LinuxContainerSecurityContext.RunAsUser from the image status (code) when image's Config.User is not empty. So ontainer_create_linux.go#L369-L370 can grab the correct user from the SecurityContext.
However, because the cri-api spec does not assume the behavior, which fills out LinuxContainerSecurityContext.RunAsUser from the image's Config.User, I think the code should be fixed.
CRI-O seems to handle this correctly. See here.
Reproduction
Version
root@primary:~# crictl version
Version:  0.1.0
RuntimeName:  containerd
RuntimeVersion:  1.6.16
RuntimeApiVersion:  v1

Image and Container Spec
The image everpeace/test:containerd-image-config is used.
# the image has alice(uid=1000)
root@primary:~# docker run -it --rm everpeace/test:containerd-image-config cat /etc/passwd | grep alice
alice:x:1000:1000::/home/alice:/bin/sh

# In the image
# - root belongs to an additional-group-for-root
# - alice belongs to an additiona-group-for-alice
root@primary:~# docker run -it --rm everpeace/test:containerd-image-config cat /etc/group | grep -e root -e alice
root:x:0:
Alice:x:1000:
additional-group-for-alice:x:10000:alice
additional-group-for-root:x:20000:root

# image specifies "config.user: 1000" (alice)
root@primary:~# crictl inspecti everpeace/test:containerd-image-config
...
  "info": {
    "chainID": "sha256:140469df148ed27972d663207bf92e11d6d11b046647532811ab0f7a297c0cb0",
    "imageSpec": {
      "config": {
        "User": "1000",
...

root@primary:~# cat pod-config.json
{
    "metadata": {
        "name": "test-sandbox",
        "namespace": "default",
        "attempt": 1,
        "uid": "hdishd83djaidwnduwk28bcsx"
    },
    "log_directory": "/tmp/tmp.AqRbZ4eV2s",
    "linux": {
    }
}

root@primary:~# cat container-config.json
{
    "metadata": {
        "name": "test"
    },
    "image": {
        "image": "everpeace/test:containerd-image-config"
    },
    "command": [
        "id"
    ],
    "log_path": "test.0.log",
    "linux": {}
}

The output
# Run the container
root@primary:~# crictl runp pod-config.json
3323c5e01e65ae0a4663b6e7391eb1e81a6fccb9a6cda07b639e792798cdb11e
root@primary:~# crictl create 3323c5e01e65ae0a4663b6e7391eb1e81a6fccb9a6cda07b639e792798cdb11e container-config.json pod-config.json
6fa373a9292d86f3cdc43e63feeb298c622a0f092ba3204ac04a541a9ca56cc4
root@primary:~# crictl start 6fa373a9292d86f3cdc43e63feeb298c622a0f092ba3204ac04a541a9ca56cc4
6fa373a9292d86f3cdc43e63feeb298c622a0f092ba3204ac04a541a9ca56cc4

# 'additional-group-for-alice' expects to be attached because imageConfig.User=1000(alice).
# However, 'additional-group-gor-root' is attached instead.
root@primary:~# crictl logs 6fa373a9292d86f3cdc43e63feeb298c622a0f092ba3204ac04a541a9ca56cc4
uid=1000(alice) gid=1000(alice) groups=1000(alice),20000(additional-group-for-root)

Notes for reviewers
The current containerd's CRI implementation doesn't follow the conversion spec config.User to spec.Process.User. The containerd's CRI impl

doesn't support to specify group in config.User in the image, and
ALWAYS attach groups from the image(/etc/group) when setting RunAsGroup in SecurityContext

The issue will be handled in https://github.com/kubernetes/enhancements/issues/3619 separately to avoid breaking changes to the users.

Doh! This would need go1.17 to be removed from the builds;
Error: pkg/cri/server/container_create_linux.go:350:19: undefined: strings.Cut
note: module requires Go 1.18
make: *** [Makefile:202: build] Error 2
Error: Process completed with exit code 2.

removed cherry-pick of https://github.com/containerd/containerd/commit/50740a1a0ce283888853155272c5962e1d2e7076


Unknown blueprint: authorizer

<EMAIL_ADDRESS><EMAIL_ADDRESS>> ember generate authenticator custom
Unknown blueprint: authenticator

> ember generate authorizer custom
Unknown blueprint: authorizer

This isn't released yet.

It is in the README instructions, though. Just sayin'.


"in" guards are not visualized at all

Description
Unlike SCXML, XState distinguishes between cond (condition) and in (query (parallel) state). While xstate-viz shows the names of cond guards, in guards are not visualized at all. In combination with always events, this leads to the weird impression that any of two transitions could be triggered.
As a workaround, if you examine closely, you'll notice that when hovering over the transitions, the follow-up is only highlighted if their guard is fulfilled, but I still miss any hint that there is a guard in the first place.
See also #265.
Expected Result
in guards should be visualized in a similar fashion as cond guards.
Actual Result
in guards are not visualized at all.
Reproduction
check it out in viz
For comparison, I specified the START transition twice, one via in, the other via cond. The cond-based transition is labelled intuitively, but the in-based transition looks like it has no guard at all.
Additional context
N/A

Hmm. Is this project dead?


MONAI Label tutorials minor changes to the doc

Hi @yiheng-wang-nv @mingxin-zheng ,
I think we don't need to introduce the different download sources and how to set them and set the authentication token in these MONAI Label tutorials, that's what the download API doc-string should describe clearly:
https://github.com/Project-MONAI/MONAI/blob/dev/monai/bundle/scripts.py#L220
You can refer to other bundle related tutorials, for example:
https://github.com/Project-MONAI/tutorials/tree/main/model_zoo/adapt_bundle_to_another_dataset
If you want to introduce more, just: "for more advanced options of download API, please refer to: https://docs.monai.io/en/stable/bundle.html#monai.bundle.download".
What do you think?
Thanks.

Hi @Nic-Ma , agree as users may only be interested in models themselves and do not care about the source thing.

Hi @Nic-Ma @yiheng-wang-nv , thanks, that makes sense, removed the description of the environment.

Hi @yiheng-wang-nv @mingxin-zheng , I should remove all descriptions about model-zoo, ngc, auth token, download source,etc in monailabel tutorials. You could help modify other tutorials about the bundle sources.
Thank you!

are we clear about all the zoo/ngc/auth token descriptions? @yiheng-wang-nv  . Let's double-confirm within three of us, then we can merge. Thank you!

HI @tangy5 , I checked one more time and I think it's all clear.


Support for GCM chiper transformation

While using this class, if Android <4.4 is not on plate, would it be a legit (and sensible) choice to replace AES/CBC/PKCS5Padding with AES/GCM/NoPadding? Is it a redundant option, due to the integrity checking you added?
If it makes sense, are there other changes required in order to optimize the class, aside from reducing the IV length to 12 bytes?
Any suggestion is welcome
Thanks

Yes, that's legitimate and sensible.
You will likely want to change a lot:

Many of the crypto RNG "fix" functions will also be redundant

You also wouldn't need the verification hash since GCM already supports
verification. In short, if you're not worried about compatibility, your can
eliminate most of the code.

Some parameters to GCM mode may be different because it can include
non-encrypted but verified data as well.

Be aware that GCM has rather catastrophic consequences if you reuse the
IV, so be careful about generating unique ones.

you might get surprised about what platforms have what cipher suites at
what strength. Be sure to test every platform of interest.

Ok all clear, thanks a lot for the explanation!

No problem!

News...
Electronic Codebook (ECB) mode: Under a given key, any given plaintext block always gets encrypted to the same ciphertext block. Thus, it does not hide data patterns well. In some senses, it doesn't provide serious message confidentiality, and it is not recommended for use in cryptographic protocols at all.
Cipher Block Chaining (CBC) with PKCS#5 padding (or PKCS#7) is susceptible to padding oracle attacks.
In both cases, Galois/Counter Mode (GCM) with no padding should be preferred.
This rule raises an issue when a Cipher instance is created with either ECB or CBC/PKCS5Padding mode.
find-sec-bugs

@diyfr , Thanks for the note. Have you evaluated our library as to whether it is vulnerable to the attacks you mention?
This library does not use ECB mode at all.
We do use CBC mode for backward compatibility; GCM is not available on all Android platforms, and a significant number of users are still on platforms where CBC is the best available cipher (see below).
With regard to padding oracle; We add MAC integrity checking before decryption. Further, this is primarily a local/password-derived function (ie what's the oracle?).
So I'm not clear how padding oracle could be accomplished here, although I could definitely be wrong about that! Do you have any specific insights?
For reference, I believe GCM was added in API level 22 / Android 5.1, and here's the current distribution adoption rates:

Android 9.0 Pie (August 2018): 10.4%
Android 8.0/8.1 Oreo (August 2017, December 2017): Up 6.8 points to 28.3%
Android 7.0/7.1 Nougat (August 2016, October 2016): Down 9.9 points 19.2%
Android 6.0 Marshmallow (October 2015): Down 4.4 points to 16.9%
Android 5.0/5.1 Lollipop (November 2014, March 2015): Down 3.4 points to 14.5%
Android 4.4 KitKat (October 2013): Down 0.7 points to 6.9%
Android 4.1/4.2/4.3 Jelly Bean (July 2012, November 2012, and July 2013): Down 1.8 points to 3.0%
Android 4.0 Ice Cream Sandwich (December 2011): Flat at 0.3%
Android 2.3 Gingerbread (December 2010): Up 0.1 points to 0.3%


clean up Coveralls handling

Let's see whether everything looks good.

Codecov Report

Merging #2 (33a2562) into main (e13d96c) will decrease coverage by 19.04%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##             main       #2       +/-   ##
===========================================
- Coverage   71.42%   52.38%   -19.05%
===========================================
  Files           1        1
  Lines          21       21
===========================================
- Hits           15       11        -4
- Misses          6       10        +4

Flag
Coverage Δ

unittests
52.38% <ø> (-19.05%)
:arrow_down:

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

Impacted Files
Coverage Δ

src/ParallelCoverallsSetup.jl
52.38% <0.00%> (-19.05%)
:arrow_down:

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 e13d96c...33a2562. Read the comment docs.


Forbid returning and passing tuples to FFI functions

Passing complex objects by value in C is hard: there are many different calling conventions depending on the platform. For example, a C compiler is allowed to split the members of an object into different parameters, or to change the return value into an out parameter.
The Pony compiler currently uses a naive implementation to pass objects to FFI functions and isn't able to use the correct calling convention for every call. Ideally, we'd want to rely on a C compiler API (like LibClang) to generate the correct signatures and calls.
This change is a temporary measure to avoid spurious FFI bugs until we have the interoperability detailed above. LLVM intrinsics are still allowed to return and be passed tuples since their signatures are defined by LLVM.

After fiddling with the Clang API, I realised that setting up the interoperability might be easier than I initially thought. I'll probably have a basic implementation soon, so I'll mark this PR as DO NOT MERGE. If I encounter a major difficulty with Clang, then we can unblock this PR until it is sorted out.

Actually, the interoperability won't be easy to implement because an important functionality (converting Clang types to LLVM types) is only part of Clang's internals and wouldn't be practical to replicate in ponyc. I'm going to submit a patch to Clang to expose that interface.

@aturley does this impact on any of our sendence language binding code?

As discussed on sync, this is ready to merge, but we wanted to give @SeanTAllen and/or @aturley a chance to object first.

@aturley is really the one who needs to weigh in...

@SeanTAllen @jemc this doesn't impact us.

Okay, then this is good to merge once @Praetonus resolves the merge conflicts.

Conficts fixed, CI is passing, merging.


GO:0061246 establishment or maintenance of bipolar cell polarity regulating cell shape

GO:0061246 establishment or maintenance of bipolar cell polarity regulating cell shape
This term, and regulation terms are only used by PomBase. I think they are unnecessary  (I requested them years ago).
Can they merge up to
GO:0061246 establishment or maintenance of bipolar cell polarity

Is there a difference between

GO:0061245 establishment or maintenance of bipolar cell polarity and its child class:
GO:0035088 establishment or maintenance of apical/basal cell polarity?

according to PMID:31213986 it's the same: "There are two type of polarity: the cell intrinsic apical–basal polarity and the tissue wide polarity known as planar cell polarity."
Looks like we can merge those as well?

Also - looks like  ' GO:0035089 establishment of apical/basal cell polarity' is incorrectly under both ' GO:0061162 establishment of monopolar cell polarity' and  GO:0061245 establishment or maintenance of bipolar cell polarity

Is this right?

@mah11  may know.....

The terms might mean the same but in fission yeast we never use apical/basal because uni-cellular organismal cells don't have a 'base'

I cannot comment on why GO:0035089 is under both GO:0061162 and GO:0061245, nor which parent is correct.
The difference between GO:0061245 and GO:0035088 is that a cell may be bipolar without the poles corresponding to apical and basal (this is the case for fission yeast). Whether GO needs to preserve that distinction is another thing I can't help with.

GO:0061246 seems to have disappeared without notice?
At least, I get a message
"Session can't be approved as a term ID is not in the database: GO:0061246
"
in a session with this term.
(I Can still see it in QuickGO, so tagging @kimrutherford in case it is a PomBase issue)

It looks like the term is going missing when we process go-plus.owl with OWLTools to apply the taxon constraints.  We only do that for loading GO into Canto.  So it's not a general PomBase problem or a GO-wide problem.  It's strange because there are no taxon constraints on GO:0061246 or its parents, that I can see. The direct parent term GO:0071963 is going missing too but the other ancestor terms get through.
Is there any way this could be a problem with the ontology or the taxon constraints is it more likely to be an OWLTools problem?

I'm not sure  so tagging @balhoff  & @pgaudet

I dont see any changes in the editors' version of the ontology - this is a question for @balhoff

Also this term:
GO:0060624    JSON
regulation of ascospore wall (1->3)-beta-D-glucan biosynthetic process
I see this  in Canto:

The owltools taxon subset command is more aggressive than normal taxon constraint reasoning. In this case there is a pretty large reasoner explanation, but it includes the relation that anatomical structures start existing during or after zygote stage, zygote stage is part of embryo stage, and then embryo stage relates to all sorts of stuff that is not in yeast.
We could either do a lot of work in Uberon to make all these relationships more taxon-specific, or provide you with a different script that only removes terms over the standard taxon constraint propagation rules.

I think the definition of anatomical structure related terms needs to be fixed.
Many, many anatomical structures apply to yeast.
For example
GO:0005622   intracellular anatomical structure
4778/5050 fission yeast proteins are annotated to this team.
I don't think you can restrict anatomical structure to be part of an 'embryo stage' it isn't correct for many  many species?

it's probably best to make new high priority issues for things like this, it takes a while to scroll down and realize the high priority thing has nothing to do with the issue title,
I made a separate issue:

#23012

any news on this? I am still unable to approve curation session switch some terms. We can keep these back for a while  but I don't  want to gett too huge of a build up.
Please let us know what we need to do at our end...

@cmungall what needs to be done? Is this a change in Uberon?

@ValWood  is this still causing problems?

We have a temporary fix while @balhoff is organizing a general fix.


BREAKING: Change CommandSpec to Command.

Move some interfaces into Command namespace.

Coverage remained the same at 93.218% when pulling 2afefdb633c0ee293639fbfb06267f462a3d8968 on clean-api into ffb64478a71147fe88b5d9734dfeb4a8303137d5 on master.

Coverage remained the same at 93.218% when pulling 1dc196457944405adf842b12d4b42796832b7589 on clean-api into ffb64478a71147fe88b5d9734dfeb4a8303137d5 on master.


fix a typo in the README file.

This change is

I signed it!

/ok-to-test

/retest

/test kubeflow-tf-operator-presubmit

@ChanYiLin Thanks for your PR, and I think our prow fails because of #388
Maybe we could wait until the issue is solved and rerun the test.

Oh! I see.
Thanks for your help!

No need to wait for tests just for a README.


ERROR when installing tiny-coda-nn

When I install tiny-coda-nn on my remote server,
pip install git+https://github.com/NVlabs/tiny-cuda-nn/#subdirectory=bindings/torch
but I got this

Here is the version of my pip

Any help would be highly appreciated, thanks in advance.

It looks like your server isn't able to access github.com/NVlabs/tiny-cuda-nn
Do you by anychance have a firewall that would prevent github access?

Thanks for your reply, I solve this problem by resetting the proxy.


chore(demo): show github star in runtime

It doesn't fit on mobile. Also let's round it to 3.2k

@waterplea fixed


Every attempt with mysql just hangs forever

npm outdated returns nothing
example code below.  you can see querying mysql2 works fine, but using same pool kysely just hangs when query is executed.
function myCreatePool(): mysql.Pool {
  const poolOpts = {
    uri: process.env.DATABASE_URL,
  }
  let pool = mysql.createPool(poolOpts)
  return pool
}

async function main() {

  // mysql2 driver works
  const [rows] = await myCreatePool().query("select id from users")
  console.log(rows) //=> success

  // kysely fail section with same pool
  const kysely = new Kysely<DB>({
    dialect: new MysqlDialect({
      pool: myCreatePool()
    })
  })

  let pendingQuery = kysely.selectFrom("users").select("id")
  console.log(pendingQuery.compile().sql) //=> success: "select `id` from `users`"
  console.log(await pendingQuery.execute()) //=> HANGS FOREVER

  console.log("done")

}

main()

Hey 👋
Are you, by any chance, importing mysql2 from its 'mysql2/promise' subdirectory?

I'm not sure how you got all of that from

example code below. you can see querying mysql2 works fine, but using same pool kysely just hangs when query is executed.

If I were you I'd see this as something that might be a common mistake since anybody adopting kysely from an existing project would already have a mysql2/promises pool setup somewhere in their code.
Also, as a minor point, that information that is "clearly shown" only exists in the API reference for Class MysqlDialect, not in the github README or the top page of the website.

might be a common mistake since anybody adopting kysely from an existing project would already have a mysql2/promises pool setup somewhere in their code.

This makes sense. Will emphasize this in new "Getting started" page.

I'm not sure how you got all of that from

I got it more from Every attempt with mysql just hangs forever. If you were not angry and blaming us (for your own mistake) would you have used the words "every" and "just" in there? Your attitude comes through from the text you know.

Also, as a minor point, that information that is "clearly shown" only exists in the API reference for Class MysqlDialect, not in the github README or the top page of the website.

So everything YOU need should be clearly in the README and at the top of the website? If we added everyones personal needs at the top, we'd have everything at the "top".

I got it more from Every attempt with mysql just hangs forever.

I should been more clear, but I was keeping it short because its a title.  What I meant is that every variation I tried hangs.  In other words, I made an effort, not just came here after giving up right away.  I even ran it through a debugger but apparently the node debugger just mysteriously quits when it runs into this situation.

Also there's no "Hello" at the top.

This is just getting weird.  I don't see any other issues with 'Hello' at the top.  If that's a policy maybe you should make an issue template for it.

So everything YOU need should be clearly in the README and at the top of the website? If we added everyones personal needs at the top, we'd have everything at the "top".

README are often used to common guidance to using the software.  I don't see how using the more modern variation of a lib accidentally would be that uncommon.  Everything I need isn't about me.  Where do you think FAQs come from?

This is just getting weird. I don't see any other issues with 'Hello' at the top. If that's a policy maybe you should make an issue template for it.

Jesus christ, this isn't rocket science. I just mean being polite and nice, like a normal person in a normal conversation. You an choose your own words, no need to say hello 😄 I mean have you ever had a discussion with a person? Have you ever asked for help from someone before?

Jesus christ, this isn't rocket science. I just mean being polite and nice, like a normal person in a normal conversation.

^!

I mean that's what you are doing here. You are asking for our help with your problem. You are not entitled to our time and help. You haven't paid anything. You're not a customer.

I thought there was a bug.  I followed everything properly except importing the wrong variation of a external requirement (which was inside the API documentation).  If you look at my code, its not something I needed help with, its my attempt at making the problem reproducible.


Updating the oldbranches.pl script

Minor updates/fixes to make the half-yearly or yearly checks easier.

@psiroky Would you mind looking at this?

yay, Perl stuff :) I will take a look (and test locally).

O, hold on, I need to add a die/fail message for the -r option.

Okay, fixed!
@psiroky Please review!

+1. Merged into master.
One thing I noticed is that the script excludes some branches which probably should not be excluded, like uf_0.5.x or lienzo-core-2.0.x. I think we could check if the branch starts with number and ends with x (this the pattern that we follow for long-running branches). But this really is just minor thing. Thanks @mrietveld for the changes, this script is very useful!


Create debugHandler

With turned on debug it prints everything out directly. Implement custom debugHandler which will be called.
It can check if debugHandler is (bool) true and do like now.

Add info to wiki

Because it's meant to be low level wrapper, propably everyone will be creating layer above this library. That means, everybody can implement own debug handler in it. Like I did in my projects. Also I mentioned one implementation here #14 .
Internal debug for this library should stay how it is, with direct debug of binary socket communication.


Adding wrapper for send methods

Summary
Adding wrapper for send_events():

send_message()
join_channel()
leave_channel()

Furthermore there was a duplicating '#' in the fetched channel name.

Looks good! 👍


Missing necessary parentheses in logic expressions

See the right pane:

Many necessary parentheses are missing. With parentheses it ought to be (r < B ∨ r ≥ B) ∧ (r < B ⇒ ...) ∧ (r ≥ B ⇒ ...).

(In ver. 0.2.3) We do not need parentheses around multiplication below, since (*) binds tighter than (+)"

Meanwhile, we do need parentheses around (∨):

(v0.3.9) Given the sample program below, the InvBase now read as:
A = (q * B) + r ∧ 0 ≤ r ∧ ¬ r ≥ 2 * B
⇒ r < B ∨ r ≥ B ∧
(r < B ⇒ A = (q * B) + r ∧ 0 ≤ r < B) ∧
(r ≥ B ⇒ A = ((q + 1) * B) + (r - B) ∧ 0 ≤ r - B < B)

It is an improvement that we now have parentheses around ⇒ when it is next to ∧ (that is, (r < B ⇒ ...) ∧ (r ≥ B ⇒ ...). However, we still need parentheses around r < B ∨ r ≥ B.
The parentheses in (q * B) + r are not necessary.
Use the following as the sample program.
con A, B : Int { A ≥ 0 ∧ B > 0 }
var q, r : Int

q, r := 0, A
{ A = q * B + r ∧ 0 ≤ r, bnd: r}
do r ≥ 2 * B →
   q := q + 2
   r := r - 2 * B
od
if r < B → skip
 | r ≥ B → q := q + 1
           r := r - B
fi
{ A = q * B + r ∧ 0 ≤ r < B }

Some issues with the prefix operator (¬).
InvBase is currently a ∧ b ∧ (¬ a = b). The expression intended should be a ∧ b ∧ ¬ (a = b): since ¬ binds stronger than =, we need brackets around a = b. Meanwhile we do not need brackets around ¬ (a = b).

The current code does correctly put brackets around a ∧ b, though. I wonder why. Givnen that both = and ∧ are weaker than ¬, why are they treated differently?

Various oddities with this one. Note that with a ∧ b ≡ b ∧ a the intended meaning is (a ∧ b) ≡ (b ∧ a) --- ≡ is weaker than ∧, therefore we do not need brackets.

In the consequent of InvBase, it is correct to print a ∧ b ≡ b ∧ a. But why do we have (a ∧ b) ≡ (b ∧ a) in the antecedent?
In TermBase, x ≤ y ∧ a ∧ b ≡ b ∧ a is wrong. It has to be x ≤ y ∧ (a ∧ b ≡ b ∧ a).

Appears fixed for now.


japanese word KAZE in Palauan

japanese word KAZE in Palauan created by<EMAIL_ADDRESS>on 2016-12-23 15:14:51

<EMAIL_ADDRESS>replied, I've encountered in a medical booklet the next:Bo blechoel melatech er a telemall e bilii er a kaze.what is KAZE?

<EMAIL_ADDRESS>replied, In Japanese KAZE means "wind" (i think everybody heard about kamikaze, lit. "holly wind"), another meaning of KAZE in Japanese is "cold" (= rakt el tereter). but none of two meanings fits the example above...

<EMAIL_ADDRESS>replied, Gauze bandage is kaze.

<EMAIL_ADDRESS>replied, It's not Japanese, it's English 'gauze'

<EMAIL_ADDRESS>replied, Aleks, can you send me the medical booklet please? Or do we already have it?

Correct. Kaze is En for gauze.
souang

On Oct 16, 2022, at 20:48, John Bent @.***> wrote:

@.*** replied,
Aleks, can you send me the medical booklet please? Or do we already have it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.


Regarding changing of vector lengths for gem5 with RISC-V Vector

I am using gem5 for RISC-V Vector and want to do the experimentation with different vector lengths. I am using se.py for running my experiments. But I could not find the option to change vector lengths. I also tried to look at the --param parameters but could not find any option in that too. Can you please guide me on this?

We don't support changing VLEN yet, it's hardcoded now.

Can you please direct me to the files where I can change that hard-coded value for vector lengths and rebuild Gem5?

It's in here, however, we haven't tested it under other VLENs yet, change VLEN may causing a segfault.
Btw Hoa is adding configurable VLEN in https://github.com/plctlab/plct-gem5/pull/21.

Thank you very much. I will try to do experiments by changing the vector length.

If you have further discussion, please open a new issue.


error: ‘remove_cv_t’ is not a member of ‘std’; did you mean ‘remove_cv’?

when I run npm in Manjaro Linux, npm ERR!
In file included from /home/csg/.cache/node-gyp/17.7.1/include/node/v8-local-handle.h:12,
npm ERR!                  from /home/csg/.cache/node-gyp/17.7.1/include/node/v8-array-buffer.h:12,
npm ERR!                  from /home/csg/.cache/node-gyp/17.7.1/include/node/v8.h:25,
npm ERR!                  from /home/csg/.cache/node-gyp/17.7.1/include/node/node.h:63,
npm ERR!                  from ../src/common.cc:22:
npm ERR! /home/csg/.cache/node-gyp/17.7.1/include/node/v8-internal.h: in function ‘void v8::internal::PerformCastCheck(T*)’:
npm ERR! /home/csg/.cache/node-gyp/17.7.1/include/node/v8-internal.h:563:38: error：‘remove_cv_t’ is not a member of ‘std’; did you mean ‘remove_cv’?
npm ERR!   563 |             !std::is_same<Data, std::remove_cv_t<T>>::value>::Perform(data);
npm ERR!       |                                      ^~~~~~~~~~~
npm ERR!       |                                      remove_cv
npm ERR! /home/csg/.cache/node-gyp/17.7.1/include/node/v8-internal.h:563:38: error：‘remove_cv_t’ is not a member of ‘std’; did you mean ‘remove_cv’?
npm ERR!   563 |             !std::is_same<Data, std::remove_cv_t<T>>::value>::Perform(data);
npm ERR!       |                                      ^~~~~~~~~~~
npm ERR!       |                                      remove_cv
npm ERR! /home/csg/.cache/node-gyp/17.7.1/include/node/v8-internal.h:563:50: error：param invalid
npm ERR!   563 |             !std::is_same<Data, std::remove_cv_t<T>>::value>::Perform(data);
npm ERR!       |                                                  ^
npm ERR! /home/csg/.cache/node-gyp/17.7.1/include/node/v8-internal.h:563:63: error：‘::Perform’
npm ERR!   563 |             !std::is_same<Data, std::remove_cv_t<T>>::value>::Perform(data);

This error also happened in node version 16.14.2
 /home/csg/.cache/node-gyp/16.14.2/include/node/v8-internal.h: in function ‘void v8::internal::PerformCastCheck(T*)’中:
npm ERR! /home/csg/.cache/node-gyp/16.14.2/include/node/v8-internal.h:492:38: error：‘remove_cv_t’ is not a member of ‘std’; did you mean ‘remove_cv’?
npm ERR!   492 |             !std::is_same<Data, std::remove_cv_t<T>>::value>::Perform(data);
npm ERR!       |                                      ^~~~~~~~~~~
npm ERR!       |                                      remove_cv
npm ERR! /home/csg/.cache/node-gyp/16.14.2/include/node/v8-internal.h:492:38: 错误：‘remove_cv_t’ is not a member of ‘std’; did you mean ‘remove_cv’?
npm ERR!   492 |             !std::is_same<Data, std::remove_cv_t<T>>::value>::Perform(data);
npm ERR!       |                                      ^~~~~~~~~~~

https://stackoverflow.com/questions/67241196

What command was typed?
Please provide the full error log.

What command was typed? Please provide the full error log.
https://stackoverflow.com/questions/67241196 https://github.com/nodejs/node-gyp/search?q=remove_cv_t&type=issues

npm run build

Please provide the full error log.

It seems nault is just a problem code base in general.
when I run env CXXFLAGS="-std=c++17" npm i
I now get the following error
2022-06-07T21_55_12_247Z-debug-0.log

This (env CXXFLAGS="-std=c++17" npm i) worked for me on an Archlinux system with gcc v12.1.0.

Full compile log when install failed.
npm_install_full_compile.log


Use T: ToString for thread::Builder::name

Rendered
First RFC. Probably missed something.

In guide level explanation you could put some example usage, also this will require a new allocation if i pass a String directly, that should be listed under drawbacks.

In guide level explanation you could put some example usage.

Will do.

Also, this will require a new allocation if i pass a String directly, that should be listed under drawbacks.

If you pass a String directly, the function will take ownership of it (existing code no longer needs to do mystr.clone() if they can pass ownership down). Passing a reference requires a new allocation as-is already (on the caller-side), but no longer needs to be explicit as the callee will do it if necessary. Or am I missing something?

Oh, I somehow have missed that ToString is a clone for String all this time. I guess it'd be better as Into<String> then rather than ToString.

Yes, that would probably be better, the only problem is that it doesn't solve putting .to_string() everywhere. So I would list it under alternatives, and add the drawback of the extra allocation due to the clone, and see if that matters. I don't think it matters that much, because the thread::Builder is only going to be constructed and given a name a small number of times in general, so the extra allocation won't do to much, but that is speculation. I think that a crater run will tell how much it is used in the wild, then a decision can be made on whether the extra allocation is worth it.

Actually, i just remembered, String has a From<&str> impl, so you don't have to put .to_string() everywhere. This could solve the ergonomics problem you have.

I definitely think ToString is way too broad here.  It makes no sense to me for .name(3.14) to work.
Taking impl Into<String> might be ok, but I still find this a bit of a weird thing.  Why not just have people do .name(foo.into()) manually?  It's not like it's that uncommon...
As a higher-level note, the motivation says

Avoid having to use ToString on arguments passed to the function when the implementation can do it itself.

That's true for literally every possible function that takes a String.  Should every function in the standard library change this way?  Should the language start automatically .to_string()ing things?  If not, what's special about this particular method that this change is good here but the others aren't?

This is going to be problematic because I'm sure there is code calling Builder::name as .name(name.into()) to create the String, which becomes ambiguous if the argument of name is a generic type parameter.
error[E0283]: type annotations needed
  --> src/main.rs:10:6
   |
10 |     .name(name.into());
   |      ^^^^ ----------- this method call resolves to `T`
   |      |
   |      cannot infer type for type parameter `T`
   |
   = note: cannot resolve `_: std::convert::Into<std::string::String>`

But in general I don't mind that a function which needs an owned String takes String as an argument.
Thanks anyway for the RFC!

I agree that ToString was based on ignorance on my part of just how broad it was (Into<String> is better in most cases). Looking into things more deeply (with my newer knowledge of this kind of API design), there's a better solution. The thread name ends up copied inside std::Thread into a CString, so I think that the real solution would have been to have a &str parameter here if the goal is really to avoid unnecessary allocations. However, adding a lifetime parameter to std::thread::Builder for that is probably way too far for a non-breaking change.

@mathstuf actually, std::Thread does not copy the string - the conversion from String to CString is in-place (it simply validates that there are no null bytes and then appends a null terminator). If the API were to switch to &str then a copy would be necessary for two reasons:

thread::Builder needs to take ownership of the name, or else its lifetime will be constrained by the borrow of name.

&str (unlike String) cannot be modified in-place to add the required null terminator so it would need to be copied into a new buffer.

Ah, that is subtle on CString's part (but documented). I guess you only lose if appending the NUL needs a reallocation. Seems rare enough.


End-of-line comments are ignored when breaking long lines in the formatter

For example, we treat this as stable formatting:
def get_recent_deployments(threshold_days: int) -> Set[str]:
    # Returns a list of deployments not older than threshold days
    # including `/root/zulip` directory if it exists.
    recent = set()
    threshold_date = (
        datetime.datetime.now() - datetime.timedelta(days=threshold_days)  # noqa: DTZ005
    )

Whereas we should be formatting it as:
def get_recent_deployments(threshold_days: int) -> Set[str]:
    # Returns a list of deployments not older than threshold days
    # including `/root/zulip` directory if it exists.
    recent = set()
    threshold_date = datetime.datetime.now() - datetime.timedelta(
        days=threshold_days
    )  # noqa: DTZ005

Since the # noqa: DTZ005 causes the accompanying line to exceed the line length.

I haven't looked into this at all, but @MichaReiser has mentioned that this is hard (for line suffixes to be included in the break length).

Thanks for the detailed report. I don't know if we want to change this. I think you can argue both ways and it adds a fair amount of complexity. See https://github.com/astral-sh/ruff/issues/5630 for the details

Thanks, missed that this was a dupe.