From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 85102E0241 for ; Tue, 27 Sep 2022 09:17:24 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=Pass smtp.pra=alan.schmitt@polytechnique.org; spf=Pass smtp.mailfrom=SRS0=wKHr=Z6=polytechnique.org=alan.schmitt@bounces.m4x.org; spf=Pass smtp.helo=postmaster@mx1.polytechnique.org Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of alan.schmitt@polytechnique.org designates 129.104.30.34 as permitted sender) identity=pra; client-ip=129.104.30.34; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="SRS0=wKHr=Z6=polytechnique.org=alan.schmitt@bounces.m4x.org"; x-sender="alan.schmitt@polytechnique.org"; x-conformance=sidf_compatible; x-record-type="spf2.0"; x-record-text="spf2.0/pra,mfrom +a:mx1.polytechnique.org +a:mx2.polytechnique.org +a:mx3.polytechnique.org +ip6:2001:41d0:1:94de::736d:7470 -all" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of SRS0=wKHr=Z6=polytechnique.org=alan.schmitt@bounces.m4x.org designates 129.104.30.34 as permitted sender) identity=mailfrom; client-ip=129.104.30.34; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="SRS0=wKHr=Z6=polytechnique.org=alan.schmitt@bounces.m4x.org"; x-sender="SRS0=wKHr=Z6=polytechnique.org=alan.schmitt@bounces.m4x.org"; x-conformance=sidf_compatible; x-record-type="spf2.0"; x-record-text="spf2.0/pra,mfrom +a:mx1.polytechnique.org +a:mx2.polytechnique.org +a:mx3.polytechnique.org +ip6:2001:41d0:1:94de::736d:7470 -all" Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of postmaster@mx1.polytechnique.org designates 129.104.30.34 as permitted sender) identity=helo; client-ip=129.104.30.34; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="SRS0=wKHr=Z6=polytechnique.org=alan.schmitt@bounces.m4x.org"; x-sender="postmaster@mx1.polytechnique.org"; x-conformance=sidf_compatible; x-record-type="v=spf1"; x-record-text="v=spf1 a -all" IronPort-SDR: 6332a383_3oKFCCo8ojjvm5eClC87Z62T3IU1l1WFFmZHEEGFD+Lt087 oyFwYNjdYa3GWOacWEBOEorJAxdV1d5ygzwtqBw== X-IPAS-Result: =?us-ascii?q?A0DplgAXojJjhyIeaIFaARWDY1soGQFnVi4HCEWEET2RF?= =?us-ascii?q?IEWiEqHC41PBE4QAQMBDSwBDAYBAgQBAYISgnMChGwCHgYBBTMTAQIEAQEBA?= =?us-ascii?q?QMCAwEBAQEBAQMBAQUBAQECAQECBAQBEwEBAQEYCRcHEA4FIoU7ByYNgjUMD?= =?us-ascii?q?AODdwMBCg4BCAQGEwEBKwcGGCMDFAEGAwIRARcBHgMBEwESFAYBgmIBgyADB?= =?us-ascii?q?QuOM5pOGjV6fzOBAYIIAQEGgUABAwIBCwICAw8uAYN2gVwJJIECF4cGbkUQA?= =?us-ascii?q?YM3CYQdAicQgVVEgRWCKRI4B26BUHAXCwEBAQEBgTQHAQEIRQmDIBiCToUhh?= =?us-ascii?q?GGPJwc3A0QdQQMLdwMVAxQDBSQHAxkPIw0NBB0MAwMFJQMCAhsHAgIDAgYTB?= =?us-ascii?q?QICFzY2CAQIBCskDwUCBy8FBC8CHgQFBhEIAhYCBgQEBAQVAhAIAggmFwcTM?= =?us-ascii?q?xkBBVkQCSEWBigNBQYTAyBJJgVEDygxaysdGwqBDCoJHxUDBAQDAgYTAwMiA?= =?us-ascii?q?hAqMRQEKRMSLQcrcwkCAyJsAwMEKCwDCSEfBygmPAdYEigFAwIQIj0GAwkDA?= =?us-ascii?q?iRbgQMsKAUDDRkmCAU6HgQIPAIFBlcTAgoSAxMPlyOBT4EWLw4HMQYBFhcQD?= =?us-ascii?q?gwJAwEDDQcTAQcMCA4BARQNAQ0gAQQECBsVAQcDAgIBEBUIBAkECgMBGAEOD?= =?us-ascii?q?BMIAxEYEQOERI1XEykDb40Sim2UU4EBNAeDXIFDBgyIQ4EjjQOIK4N2gVCLA?= =?us-ascii?q?IZlkVkhljA6IIIrhwICgRkJgkuIQA2LeiYDIBmFBIFOKiOBKhsPBzMaMEMNG?= =?us-ascii?q?YJBCUUcD4MoilABMxaBBAEHghwoQX2BJnspGDk7WieESz80AgEBNwIGAQoBA?= =?us-ascii?q?QMJhWMBAQUTCwGBf4JIAQE?= IronPort-PHdr: A9a23:iZT9LhJir+1STAMus9mcuJVoWUAX0o4c3iYr45Yqw4hDbr6kt8y7e hCFvrM20ASCBNyKo9t/yMPu+5j6XmIB5ZvT+FsjS7drEyE/tMMNggY7C9SEA0CoZNTjbig9A dgQHAQ9pyLzPkdaAtvxaEPPqXOu8zESBg//NQ1oLejpB4Lelcu62/689pHJbQhFizSwbbxvI BmrqQjaq9Ubj5ZlJqst0BXCv2FGe/5RxWNmJFKTmwjz68Kt95N98Cpepuws+ddYXar1Y6o3Q 7pYDC87M28u/83kqQPDTQqU6XQCVGgdjwdFDBLE7BH+WZfxrzf6u+9g0ySUIcH6UbY5Uiml4 Kl2VR/okz8HOCAl/2HLicJwia1brhympxx62YHUYYeVP+d6cq7TYd8WQGxMUsZSWSxHHIO8b pAPD+saMuZcsYb2ulUPrRykBQaxH+Pk1ztEi3Hq0aE/1ekqDAPI0xE6H98WsHrassj7OqkRX ++60KbF1i/MY+9M1Drn9ITEbhIsrPeRVrxwa8rRzkwvGhvZg1WUs4PlOS6e2PkRvGib6upgV P6vi3I6oAx2uDevwt0jio/TioIO1l/E9SB5wIcpJd2kU0N7edmkEJ9QtiGGKYR5XsMiQ2dpu CYj170Jp4S3fC8QyJQo3hPSbeGMfIeU7Bz5TumRPSt4i2x/eLK5nxu//kiux/P+W8e6zVpHs ipLn8TDu30C1RHd6sqKR+Zz80muxTuDyh3f5+FKLE07m6fWK50sz7oym5cTrEjPAzL7lUPrh 6GYcUUk//Kn6+XhYrj+vp+TKZN0igDiMqswgsy/BuE4Mg0QUGSB/+SzyqHj8VX+QLpWlPI2l 63ZvIrdJcQBqa61Gw1V0ps46xajDjem1soXkWMDLFJCfBKLl5LpNE/TL//jE/iwmVKsnC12y P/YIL3tGpHNLnnYn7j9Z7p97FRcyAUrwdBQ5pJUFrEBIO/oVUPrqNPYCRo5PxSzw+b8Etp9y 5kSWXiRDaOBKqPStkSH5v81I+WWZY8Vvy7xJOY/5/70l3A5hV4dfbC03ZQJcny3AvRmL12CY XXymNcODHkFshAkTOzxkFGCUyVTZ3G0X64m4TE7Eo2mAZ/fSY+2h7yBxj23HpxRZmxeEV+ME GvoeJ6ZW/gQayKdPNNhniYDVbi7RI8tzQ2htA/gxLphIerb5DYYuYjm1Ndo/+HTlA899SB6D 8iH1GGNVW50knsJRz8wxqB/oFZyxk2N0ahim/BXCcZc5/ZNUggmNJ7c0+x7B8r1WgLbcdeFU FGmTcm8DjE0StI92cUCY0FnG9WtlhzDwzClA6UUl7OWGpM06bjQ0GT2J8Z403rG1bQujlkiQ stLL2GmgbR/9wfVCoXUkEuZj76nebkC0CPJ7muP0HaCsU5CXAN+TanJR34Sa0TOodjk6E7OU qWiBaonPwZO08KONKtHZsPzgVlbWfvvJtLTaH+rlWiqHxaH3LaMYZLqe2oD2CXdD1AJkwUc/ HqbLwQ+HiCho2beDTxyC13gf0Ps8e9/qHOiU0870RuGb0p717q64hIVhPqcRO0P3r8cpSstt TF5EEyg097KBNeMvQRscLlGbd4z71pLzWfZuBZ8PpykIaBinFkecwFvsk3zyxt5F5lMnNAkr X0vzgRyM7qV31BAej6AxZDwPbnXK2nu/B+xd6HW2lfe0NeP+qcS9vs0sVLjvBumFkc66Xpn1 8Na032G6pXREAUSUZfxUkcr9xhmvLzVeS49557S1XJwL6a0qSXO29cmCeoq0BqgeM1fMKycG A/0CMIVH9KuJ/Aym1i1chIEO/hf+LMsM8O8a/SGwLKrPPpnnD++kWtI+oV90kaV+yp4S+7Ix IoFzuqD3gqHUjf8lE2uvtr2mYBCfzESH3CwxTLqBI5LNeVOetNBDXioaYXjwsp4r5ryXThe+ UL1QxtM09CvM1LaO1fi2yVU1F8LujqmlTq8y3pziT5/6uKU1SnKhuDjbwYvO2hRRWAkg02/D 5KzioUzWEGuJzMilB6k+Vqyk6FfraI5NGLTREZUYwDuKGVzTqa7tryDetNCrpQyvnMEA6yHf VmGR+ul8FMh2CT5Ej4AnFjTFhmvs5T9xVlhjX6FaWx0pzzfcN1xwhHW4JrdQ+RQ13wIXnowk iHZU2C1JMLh5tCIj9HbqOnrXmaoUNtIeinuzJ+cnDO84Xx2DBa/mfGqh9ChFhI1gmfgz9c/b SzTt17nZ5XzkaGzMOZpZE5tUWTG0JIvBaJeiN4C2sQI3nwLmpie/XwGiHr+d9JB1vf3aHMLA yUAw9vU/BTN0kp+KHmE3MT8CmXbxdFuNJGhem1D4ism9IhRDbuMqrxJmSwgul2jsQfYeuRwh B8Y2aJo8Hkekv0EsworzzyAD/YVB0Yw0TXErx2T9Jj+qaxWYDzqar2szA9kmtvnCrieowZaU XK/e5E4HCY24N8teF7L1XTy7MnjdryyJZoashSS1QzLj+1UNI4Zjv0OlDZqMmL7vGQ4xqg8l xMm0ZyhvYeBInlg5+rgWE8eb2WpIZhLvGqxxa9F+6Tel5iiBJBgBikGUNPzQPSkHShT/fXrO gCSESEt/2+BEOmXFgue5UF66nPXRsnxZjfOfCVflo0kH0XOQS4XyBoZVzg7gJMjQwWjxci7N Vx8+ihU/Fnz7B1F1uNvMRD7FGbZvgahLDkuG/39ZFJb6B9P40DNPImQ9OV2SmtjxKb5+ROuC nbOVVodFWYNS1CJDFDlP6Cz6J/H6efND+63Kb3VarWLqPBCf/2P2JSk35Ag+mqccMKVMTMxa p9zkloGRn1/F8nDzn8GTyUR0TnGb8uauAuU4ipzv9yy+/TtWRvy6M2IEbQYYrANs1imxKyEM eCXniNwLz1Vg4gNyXH/w78axFcOiitqemrlAfEauCXKVq6Vhr5PAktRcDt9bo0QpfFZvEEFK YvBh9jyzLI9kvMlFwIPTkTvwIfxItQQKiW4OknAAQ7IPeaDNWSN28bzcL+xQr1WjfxJulu3o zn+cQerfT3RkimzEQioNfBQgSqbOh1HpYz7dQxiQSvqHtf2MVujN9tmkTA9wbs1n27Hc2kGP l0eOwsOr6XOv3kA2qwtRzVNtig8f7jYlyvLvbaDdJpE7qc0WmwxnuZeqhzW0pNt5TpfDLxwk SrW9Jt1pk2+1/OIwXxhWQZPrTBCgMSKu19jMOPX7MsIVXHB9RMLpWKebnZC7+BfMYW6pINw0 I39yvfrLzNT79/f/c0dHtXZbsWdPy8oNRPvXiXfDA4EUSKDP2bCgUdQi7eXqm3TqYI1z/qk0 JYDUb5UUlUpG+hSUx40WoVafNEsBnV/zfaSl4YQ6GC7rQXNSckSpZ3BWv+IQJCNYH6YgbRCe xoU0Ob9JIUXOJf83h8qYV17kYLWXkvICIkX82s4NlNy+x0LqyQtKw97k1joYQ6s/nIJQPu9n xpszxB7ffxo7jDnpVE+OlvNoiI01kg3g9Tsxz6LI1uTZO+9W59bDy3sug0/KJT+FkxOVzbqy FNHFC2RdewEl7xkZHxmgw/auIJSFLhbV6IRaRsZw7eMbPUt0EhAgi+g2ElM6PCDDMdy0gwwf tT/yhAIkxImd9MzKaHKceBy9GMI072tnjX95L5k2AgaNloA+2OUeTcVtQoPLLZzLi6h+Kp34 gyHmidfUGILSvwhr+ks8x8tfeOawGizttwLYlD0POuZIaSDvmHGnsPdWVI82HQDkExd9KR32 8MuIAKEEloix7yLG1EVJNLPfEtOd8QIsiCZLkPs+a3dhIh4NIKnGqX0QP+S4ewPmkz+Wl5uB 54FqsEPBJ6pmALRf8L3dfgdzhE8+AngJFOEFelEPhWRn1Jl64n8xc1yzdMbPjYZEHlwOiWx5 6/Kq0ktmvXLH95kZ2dBGJMDMmMqVca6nS9AonkGCyO4t4BRgEuD92Gu/HyIVWugNtY7Nq7GN E9gBYPkpm5h//rp1QGPutDXI2WwXTh7kufG8vhS55OOCvcOCKJ4r1+ZgY5TAXqjT2/IF9exY Zn2cYglK9LuWD62VVm2ijR9SMmUXp7lNq+TnQThXppZqqGezGllLci5By0TEBd2pvge6eR7f wJLb5cgYBHuvhgzLOTmelbei43yBT31b2AKB/BEqIfyL6Ra1S8tcvO3xDM7Q5c2wvP2uU8BS ZcWjw3PkPauY44NGSP3G3FbZ0DOvX9gzTknb75uhLxnhkiU4jx+e3iReedkaXJJpYQ5DFKWe zBtD3YgAkWbhszF6xKt2LYb+21cmcxV2KtLqiub3NeXbTSyVaissZiQvTAnaI1smJdKadn8A euc4aGAyyTYSIjMvwaFVi+jCvccncJfdStcSf8OgmolPM0apaJL7lc3XcolYbkTGO8rvL/gO l8GRWYCiDQUUY+NxmlImuCnx77TjQudarwnIEVCqJJGk8cQWC5wYzoDqemkTYqcxArmAiAbZ QwU6wpL/gcJkIR9K/vk7IT/R5hJ0zdKovhwX3iDBtxy+lD8UG3TnUngRaDrjbmyxQwLhqGJs JFTSFtlBENa3eoTikY4NOQ9NfwLpoCT+jbAMEr+uCiFIA6OPF5V2NHZfF3+DZPYuCz7SCJOo BX8qqdFz2zZHpkJ1Q8leOAsvloeeehOm27792Vi34NtDqW1XsCtxk84oDABXSj4SrJ8 IronPort-Data: A9a23:SH/wx6uICoVI9xWqw/SvL/Zuz+fnVNhaMUV32f8akzHdYApBsoF/q tZmKW+GM/3cazGkKtp0a9my9EIF6pPUydJnHlA4q3hgRX8RgMeUXt7xwmXYb3rDdJWbJK5Ex 5xDMYeYdJhcolv0/ErF3m3J9CEkvU2wbuOgTrSCYkidfCc8IA85kxVvhuUltYBhhNm9Emult Mj7yyHlEAbNNwVcbyRFsMpvlDs15K6o4GJC4QRnDRx2lAa2e0c9XMp3yZ6ZdCOQrrl8RoaSW +vFxbelyWLVlz9F5gSNz94X2mVTKlLjFVDmZkh+A8BOsTAezsAG6ZvXAdJHAathZ5plqPgqo DlFncTYpQ7EpcQgksxFO/VTO3kW0aGrZNYrLFDn2fF/wXEqfFP26fkpK2s1GLQq3d5xX2IJ6 P4jKgE0O0Xra+KemNpXS8Fplp1lNM7vLZ8SsXFmzCjEALAhW5+rr6fivIUJmm5o2oYVRbCFO 6L1ahI3BPjESyZ1AQ9CF7EehrKa2CzndDlJtF+epaw2+nXeigtr3+3kNNPTPMeBRcBUglqwr GXb+W/0GVcfaMzZziCKmp6prrKTw3yhBdlPfFG+3qNY30XC6GUyMTobUxiqmNSQ03Wzdd0Kf iT4/QJ38fljqxz0JjXnZDWzqXuA+xodQMZ4CPw/8AjLy6zO4g/fCHJsc9JaQNk27YkuQjg7y lKCn9XoHCFi9rqPRhpx64t4sxuoEyRSCkUBQBY2ajMDvdqkvYMIjCP2G4ML/LGOsvX5HjT5w javpSc4hqkOgcNj65hX7WwrkBrw9siQFVZdChH/BDn7slsRiJuNPdTA1LTN0RpXBKijJrVrl FwJ0+uE4eUKDJfIvi2GTfkXEdlFDN7UbGeD2TaD87GKETCgvnKuOK5K6Td1KS9U3issfC+wJ lfUvRJN6ZRTOnqzcKIxZJi+YyjL8UQCPYm0Phw3RoMQCnSUSONh1Hs1DaJ39zu1+HXAaYllZ f+mnT+EVB7285hPwjusXPs62rQ23C04zm67bcmlkUj9iOXGPyLNFe1t3L6yggYRsvzsTOL9r Yg3Cid2408BAYUSnwGLod5Ndw9QRZTFLc+v+50/mhG/zvpOQT1wWqCBntvNiqR/kqJciurSl kxRqWcGoGcTcUbvcF3QAlg6MO2Hdc8m/RoTYHJwVX71hSlLSdj0ts83KcBoFYTLAcQ4kJaYu dFeJ57fahmOIxybkwkggW7V99UyLUX22V7TYkJIolEXJvZdeuAAwfe8FiOHycXEJnPfWRIW8 +z8hDDIC4EOXRpjB8vwYfeihQH593sEle44GwOCLtBPcQ++uMJnOg7gvM8ResssEBTkwifF9 gC0BRxDm/LBjbVo+/b0hIeFjbyTLc1AImRgEVL2142GbRvhwjL7wKtrcvq5QjTGZWalpISgf bp0yt//At0mnXFLkZV2SaY2wY0A5dLA+qdR/jpgOHCafma6K6hBJ0Oe1pJlrZx9xb5+uCq3V HmQ+9JcB667BcP9HHMVJysndu6m18xIqgLN7P8wHlr21BV38JWDT09WGRuG0w5ZE5dYL6Inx r0HlPMNygnilCcvDMmKvhpU+0uIMHYEdact7bMeIY3zjzsU2kNwWoPdBgD28aOwRY11aGdyG QCthY3Gm7h47WjBeSBqFXHygMxsta5XsxVOlFI/N1CFn+TevcAO3TpTz2UTbh9UxRB5we5MK jBVF0lqF56voRZspuZ+Bl6JJS8QKiGdyELLz3kxqFb4VGitD2zEE308M72C/Wcf6GNtQQJY9 7C5lkfgcyjmQ5zz7BsXRERZkaDHSI1gxBzjg+GiJdyORLMhUArmg4ivRGsGkATmCsUPn3/6p fFm0eJzSK/jPwsSnvELMJab3rEuVxy0HmxObvV/9qcvH2uHWjWN9RWRCkK2IOVhGufr9BKmN slQOc5/bRSy+yKQpDQ9B6RXAbtVnuYs1eUSaIHQOm8KnLuOnAVH6KuK2HDFu1YqZNFyneIWC IDbLWuCG1PNo0pkoTbGqc0cN1eoZdUBWhbH49m01+c3RrYjq+BndH8g3oSk50u1NBRVxDPKn QfhSZKP8clc59VNpbb8KoRCGAS+Fv3rXsuq7g2YkopDfPHPA+j0piIXrVjtDwtGGb07Rd5Xk ey/j/jw1kbBrLoJbn3TwLuHNqhW5PedWPhcHdL3IUJ7wwqDep7IyDkS91+oLadmlItm2fCmY A+jeu6cSMUwWeoB9EZKaiNbLQkRO573Yojkuym5ifaGUToZ7iDqM/Kl8iXPQVxAVypVJaD7N BD4i8yu6v9cso5IIh0OXNNiIp1gJW7cSbkUTMLwuRaYH1uXrAu74JW6riUZ6BbPFnWgO+T56 8icRhHBKTKDiJuRx9Rd64FPrhkbCUhmutYJf2UfxY9Gu2jvRipOZ+EQKo4PBZxogzT/nsOwL i3EaGw5Tz7xR3JYeBH7+87uRRqbGvdIANriOzg15AmBXk9a3m9b7GdJrU+MIkuaewcPCMmiO YhY4nr0LwS8yZFvRP8O67q8m+gPKjby2CcT4U6k+yDtK092PFnI/CUJ8MlxuejvGcbQkk7GP i4wGXACR1u0IaI0Od14dSQTQHn1oxu2pwjFrk6zLBL3o4Kf3fFNw/35Ovju3/sEdstiyHsmX mv5HS3Vi4yJ8iV7hJbFcO7FTUO55Txn0yR6wGLeqdUuopyN IronPort-HdrOrdr: A9a23:j5Kik6xOultIALqd54kAKrPwEb1zdoMgy1knxilNoH1uA6+lfq WV9sjzuiWbtN98YhwdcLO7WJVoI0m8yXcd2+B4VotKNzOIhILHFu1fxLqn6wKlMSzz/OxQ2M 5bAspDIey1K0N1yeLz4AzQKadF/DBrytHMudvj X-IronPort-Anti-Spam-Filtered: true X-Spam-Status: Yes X-IronPort-AV: E=Sophos;i="5.93,348,1654552800"; d="scan'208,217";a="54672535" X-MGA-submission: =?us-ascii?q?MDFfUUo75xMvMA4RPqjiZSzVmfwLh/CzCr8nN3?= =?us-ascii?q?JWVv5yWYHS6QGnC5ZWRlwoymw3I+iQ4AygLd5Ax8kYdtLVG+9w6BUZTe?= =?us-ascii?q?gOQdWqLHc0Njxa58QVQOYQ1aOu3jJam97TEYnEUBFzLk/ewRj0YsuRs/?= =?us-ascii?q?nLjHWSJ+t3CuJipawwLUQfEw=3D=3D?= Received: from mx1.polytechnique.org ([129.104.30.34]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Sep 2022 09:17:23 +0200 Received: from set (unknown [131.254.252.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ssl.polytechnique.org (Postfix) with ESMTPSA id 40605565D5D; Tue, 27 Sep 2022 09:17:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=polytechnique.org; s=svoboda; t=1664263042; bh=JaH82cRTRgykxqWwUOyB+9maDkML8dg6nmhe/avzzbU=; h=From:To:Subject:Date:Message-ID; b=uMMBObB0BlcksnE09GmHzP7Bk7qycjIWyQntKvdp+QGMwdNvB/6DUfj5YFKBwGxbg 2VSTn2IBUfDYWBx0AeHmRRyJOs9VLHNdtwGYSPe/OPyvyaDzmGCwtEnLlssN8ldN7q OgrSQef/crO6J6qM5fOBiyLtrmTwG0LiO3BeD55Y= From: Alan Schmitt To: "lwn" , "cwn" , caml-list@inria.fr Date: Tue, 27 Sep 2022 09:17:14 +0200 Message-ID: <87v8p9nv5x.fsf@m4x.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-=-=" X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Sep 27 09:17:22 2022 +0200 (CEST)) X-Spam-Flag: Unsure, tests=bogofilter, spamicity=0.499997, queueID=9102D565D5F X-Org-Mail: alan.schmitt.1995@polytechnique.org Subject: [Caml-list] Attn: Development Editor, Latest OCaml Weekly News --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Here is the latest OCaml Weekly News, for the week of September 20 to 27, 2022. Table of Contents =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80 Esperanto, when OCaml meets Cosmopolitan OBazl Toolsuite - tools for building OCaml with Bazel Orsetto: structured data interchange languages (release 1.1.2) Interest in a Http_sig library? Outreachy summer =E2=80=9922 closing commemoration session on 23rd Sept findlib-1.9.6 Interesting OCaml Articles Other OCaml News Old CWN Esperanto, when OCaml meets Cosmopolitan =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: Calascibetta Romain announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80 I am delighted to present the first *experimental* release of Esperanto. This project is a new OCaml _toolchain_ that creates binaries compiled with the [Cosmopolitan C library] and linked with the [=CE=B1c=CF=84=C2=B5=CE=B1lly p=CE=B4r=CF=84=CE=B1bl=CE=B5 =CE=B5x=CE= =B5c=C2=B5=CF=84=CE=B1bl=CE=B5] link script. The binary produced is then portable to different platforms: The main objective of Esperanto is to provide a toolchain capable of producing a portable binary from an existing project. This would allow to finally be able to distribute software for all these platforms without having to: 1) manage multiple platforms orthogonally, the Cosmopolitan C library offers you the POSIX API for all platforms (including Windows) 2) Produce several versions of the same software for each platform. Only the binary is needed to run on all platforms Cosmopolitan *does not* however produce a binary with a multi-platform assembler. At this stage, our distribution only supports the `x86_64' assembler (the most common one) but we are working on the possibility to produce a binary with different assemblers. I would like to give special thanks to Justine, the author of the Cosmopolitan project (to develop [redbean], a small portable HTTP server) for her excellent work. [Cosmopolitan C library] [=CE=B1c=CF=84=C2=B5=CE=B1lly p=CE=B4r=CF=84=CE=B1bl=CE=B5 =CE=B5x=CE=B5c= =C2=B5=CF=84=CE=B1bl=CE=B5] [redbean] A _toolchain_ =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C In OCaml, the =E2=80=9Ctoolchain=E2=80=9D principle allows the existence = of several compilers within an OPAM switch and to choose one of them when it comes to cross-compiling a project. This principle, even though it is not clearly defined and even though its use remains very limited, exists through the `ocamlfind` tool. You can find these toolchains in your switch: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ ls $(opam var lib)/findlib.conf.d/ =E2=94=82 esperanto.conf solo5.conf =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 From our experience with Mirage as well as the work done in `dune' regarding cross-compilation, the choice to propose a new _toolchain_ in order to allow cross-compilation of projects with OPAM is both a historical choice but also the most relevant one in our opinion [1]. =E2=97=8A Why we need to cross-compile? The term cross-compilation can be misunderstood if we only consider the question of the assembler issued by the compiler (does it match the host assembler or not). In our case, cross-compilation is a broader term that implies the use of external artefacts to the compiler that are different from the default and the use of compiler options that must be used throughout the production of the final binary. In other words, even though we are emitting the same assembler, we are doing so in a different =E2=80=9Ccontext=E2=80=9D which requires the defi= nition of a new _toolchain_ which includes our artefacts and compiler options. One of these artefacts is of course the C library used by the compiler which will then be systematically used by the _runtime caml_, the well named `libasmrun.a'. This is why, for example, there is a version of OCaml with [musl]. So there must be a version of OCaml with Cosmopolitan. This new _toolchain_ also allows you to include the necessary options for compiling C files because, yes, you can compile a C file with `ocamlopt'. In order to provide a coherent _workflow_ for a project, we need to provide not only a `libasmrun.a' compiled with our Cosmopolitan C library but also an OCaml compiler capable of invoking the C compiler with the right options required by Cosmopolitan. Finally, we also need to describe in this _toolchain_ how to link the object files together to actually produce a portable binary using the APE script. [musl] =E2=97=8A A simple example with this new _toolchain_ Installing Esperanto is very easy with OPAM. It will install the cross-compiler and the necessary files so that `ocamlfind~/~dune' can recognise this new _toolchain_: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ opam install esperanto =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Finally, let=E2=80=99s try to produce a simple binary that displays =E2= =80=9CHello World!=E2=80=9D: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ cat >main.ml < =E2=97=8A Execution & Assimilation If you are not concerned by the above problems, you can simply run the program: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ ./a.out =E2=94=82 Hello World! =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 There is a final solution that requires a little explanation of what =CE=B1c=CF=84=C2=B5=CE=B1lly p=CE=B4r=CF=84=CE=B1bl=CE=B5 =CE=B5x=CE=B5= c=C2=B5=CF=84=CE=B1bl=CE=B5 is. Indeed, the latter makes it possible to create a polyglot binary whose first point of entry is not your program but a small program which tries to recognize on which platform the binary tries to run. After this recognition, this little program will =E2=80=9Cinject=E2=80= =9D values corresponding to the platform in which you try to run your program in order to finally let Cosmopolitan manage the translation between its interface and the real POSIX interface that your system offers. Of course, this step has a cost as it adds an indirection between what your program wants to do and what is available on the system running your program. However, APE offers a very special option that allows the program to be assimilated to the platform in which it wants to run. =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ file a.out =E2=94=82 a.out: DOS/MBR boot sector =E2=94=82 $ sh -c "./a.out --assimilate" =E2=94=82 $ file a.out =E2=94=82 a.out: ELF 64-bit LSB executable, x86-64 =E2=94=82 $ ./a.out =E2=94=82 Hello World! =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 This option makes your application truly native to the platform in which you run it. This means above all that the program is *no longer* portable. =E2=97=8A Esperanto, `dune' & `opam monorepo' The `dune' software also incorporates this toolchain idea using the `-x' option. More pragmatically, it is possible to define a new dune context to use Esperanto as a compilation toolchain. However, the original aim of Esperanto is to produce a portable binary. This implies, among other things, that it should not depend on remaining artefacts in order to run and, in this sense, the compilation of your project should be a static compilation. This means that all dependencies of your project must be available to compile in the same context as your project. Again, this is particularly necessary if any of your dependencies include C files, so they need to be compiled in some way. This is where `opam monorepo' comes in, it will simply =E2=80=9Cvendor= =E2=80=9D your dependencies into a =E2=80=9Cduniverse=E2=80=9D folder. Here are the st= eps needed to compile a project with Esperanto. We=E2=80=99ll take [`decompress'] as = an example which produces a binary that can compress/decompress documents: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ git clone https://github.com/mirage/decompress =E2=94=82 $ cd decompress =E2=94=82 $ cat >>bin/dune <dune-workspace < Issues =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C Apart from the outcomes described above, however, the Esperanto toolchain is not complete. Indeed, the OCaml distribution gives several libraries such as `unix.cmxa' and `threads.cmxa'. A little work has been done to make the former available. The second one is however unavailable for the moment since Cosmopolitan only partially implements `pthread'. However, it seems that the author of Cosmopolotian wants to implement the rest of the `pthread' API which will then allow us to provide support for `threads.cmxa' and OCaml 5. This of course makes support for the projects more limited than we imagined (and that=E2=80=99s why this release is experimental) however, an effort has already been made to lwt into Cosmopolitan=E2=80=99s hypotheti= cal future support for `pthread'. Future =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C As explained above, support for `threads.cmxa' and OCaml 5 remains the priority. however, an effort has already been made to support [Lwt] via Cosmopolitan=E2=80=99s hypothetical future support for `pthread'. However, it is possible that Cosmopolitan could become a target for the MirageOS project in the same way as Solo5 (or our recent experiment on Raspberry Pi 4). In this sense, we will surely propose an integration in MirageOS so that projects can both produce unikernels with Solo5 or portable binaries with Cosmopolitan. [1] However, the question remains open at several levels, that of the compiler, that of OPAM and of course that of `dune'. It is clear that the current situation is not the best in terms of what we need to do to produce such a cross-compiler. Only the feedback from Solo5 (which requires cross-compilation) allows us to say that it is surely the right choice for what we want to offer. [Lwt] Conclusion =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2= =95=8C=E2=95=8C We hope that this project will facilitate the distribution of software. You can read a more technical article about our work [here]. Finally, I would like to thank [robur.io] (an association you [can help]) for allowing me to do this project. *EDIT*: The author of Cosmopolitan just released Cosmopolitan with `pthread' support. So we will definitely try to improve our distribution to include OCaml with `threads.cmxa' support and move forward with OCaml 5! [here] [robur.io] [can help] OBazl Toolsuite - tools for building OCaml with Bazel =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90 Archive: Deep into this thread, Yawar Amin asked and Gregg Reynolds replied =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Doesn=E2=80=99t dune get advertised as being able to handle multiple programming languages, including C/C++? There=E2=80=99s really no comparison. Dune evidently can use the (C ABI) outputs of a =E2=80=9Cforeign=E2=80=9D build (if you write the glue code = needed to make this work) but there=E2=80=99s no real /build/ integration, and no hermeticity guarantees. Under Bazel different languages use different rulesets but they=E2=80=99re all Bazel rulesets, so you get one dependency graph across all languages, and if the rulesets are hermetic you get a hermetic build. Without ABI restrictions. For example if your build needs to run a Python (or Javascript, Ruby, whatever) tool, Bazel will build the tool and run it for you. Even for C I think Bazel has much better integration. The rules in rules_cc (e.g. cc_library producing a .a file) deliver a CcInfo provider (a provider is a kind of struct whose fields contain the artifacts delivered by a build action). The rules in rules_ocaml (e.g. ocaml_module) understand CcInfo dependencies and pass them around using OcamlProvider (a provider specific to the ocaml rules). Bazel supports a merge operation for CcInfo, and the ocaml rules always merge their CcInfo deps and pass them on. So every build target delivers the merge of all its CcInfo deps. The ocaml_binary rule that links its dependencies into an executable merges its CcInfo deps (which include merged CcInfo from their deps, recursively) and ends up with a single CcInfo containing every cc dependency in the dep graph, in the right order, with no duplicates. Then its simply a matter of constructing the link command with the appropriate =E2=80=93ccopt options. More succinctly: you can add a C dep directly to the module that needs it, and Bazel it pass it up the dependency chain, ensuring that it ends up on the command line when needed - building archives or executables. You don=E2=80=99t need to add a C dep to an archive target w= hen only one of n modules in the archive actually depends on it. I=E2=80=99ve just started working on rules_jsoo, which I think will nicely demonstrate the virtues of Bazel integration. The Bazel ecosystem includes a bunch of tools for working with Javascript; for example rules_js and rules_nodejs make it easy to control which node toolchain version to use, integrate npm stuff, etc. Wouldn=E2=80=99t it be nice to = be able to use such tools directly, without writing a bunch of glue code? Now a key element of Bazel integration is the use of providers. Rules deliver providers, and since providers act as a kind of rudimentary type system, I can use the JsInfo provider (defined by rules_js) to integrate rules_jsoo with the larger Bazel js ecoystem. For example, the jsoo_library rule takes the OcamlProvider provider delivered by ocaml_module rules, which contains the .cmo file. So jsoo_library runs those .cmo files through the jsoo compiler and delivers the resulting js files in a JsInfo provider. That provider is suitable as input to the rules in rules_js, which gives us seamless integration. So we can use the js_binary rule of rules_js to run code produced by jsoo_library under node. All that=E2=80=99s needed is to list the latter = as a dependency of the former. That=E2=80=99s the plan, anyway. Isn=E2=80=99t = that nice? Gregg Reynolds said and Daniel B=C3=BCnzli replied =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80 Ideally somebody learning a new language should not need to spend any time (at first) dealing with a build language too. This doesn=E2=80=99t only apply to learning. It also applies to prototypi= ng, hypothesis generation and testing. That=E2=80=99s the reason why I built [`brzo'] which I hope I=E2=80=99ll = be able to release at some point (still needs a good design review and changes to the OCaml strategy since it assumed we were moving towards a model that didn=E2=80=99t happen in the end =E2=80=93 namely the [library linki= ng proposal], I=E2=80=99d also like to add more languages to the mix but that could wai= t). None of my projects do not start with ~brzo~ing these days and the hassle free build experience is exhilarating. Build systems often are =E2=80=9Ccomplex and confusing=E2=80=9D, but that=E2=80=99s largely because the problem space itself is complex and confusing. There=E2=80=99s no getting around that. Note however that this is largely /accidental/ complexity due to the fact that compilers work in idiosyncratic ways for what build systems need in order to do their incremental and parallelization business. They are still stuck in a world where people would invoke their compiler manually at the cli level or specify the invocations themselves in a `Makefile'. In fact if it were not for the actual tools and the (lack) of information they give us, build is in fact an excessively simple problem. More specific to OCaml, the compiler clis have an insane amount of quirks and the whole system greatly suffers from an underspecified linking model. Basically it was not a good idea to let that be defined by a third party tool, if only so that you can actually talk about libraries in error messages from the compiler. [`brzo'] [library linking proposal] Orsetto: structured data interchange languages (release 1.1.2) =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90 Archive: james woodyatt announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Announcing the release to OPAM of [Orsetto 1.1.2], an update to a personal project of mine not sponsored by my employer. Licensed with BSD 2-Clause. *Q. What is Orsetto?* Aspires to do eventually for OCaml more or less what [Serde] has done for Rust, i.e. to be a curated and self-contained collection of structured data interchange languages with a cohesive and unified model of serialization and deserialization. Two interchange languages are currently supported: [JSON ] and [CBOR ]. *Q. What is new in this release?* Mostly error corrections, particularly in the CBOR library, produced by improving test coverage. The change log for the release is here: [CHANGES.md ] Highlights: =E2=80=A2 Major improvements in test coverage. =E2=80=A2 Many corrections for logic errors. =E2=80=A2 A few minor usability improvements. Some things have not changed: =E2=80=A2 Still has no Programmer Guide or Tutorial, or really any introduction at all. =E2=80=A2 Still requires *ocamlfind* and builds with *omake*, which is currently not compatible with OCaml 5.0. =E2=80=A2 Still only supports JSON and CBOR. *Q. It looks incomplete. What are your plans for future development?* Yes, it=E2=80=99s a personal project, and yes, I=E2=80=99m aware there ar= e no reverse dependencies on it currently in the public OPAM repository. Still, I=E2= =80=99d welcome opportunities to collaborate with others who share my vision for the project. As long as it=E2=80=99s just me working on this, develop= ment will continue to be somewhat slow, as I=E2=80=99m prone to over-engineer things I care about. I have a lot of projects, and this is the only open source one. =E2=80=A2 *Orsetto 1.0.3* is the previous release. It offered parsers and emitter combinators for JSON and CBOR for OCaml >=3D 4.06.1 (including 4.13~alpha1). The quality of its JSON support is adequate, and it scores well on the >[nst/JSONTestSuite] tests. The quality of its CBOR support is provisional, >and not recommended. =E2=80=A2 *Orsetto 1.1.2* is the current release. It adds generalized and extensible structured data interchange models with specializations for producing emitters and parsers for JSON and CBOR. The quality of the CBOR support is much improved, and I=E2=80=99m using it with go= od results in other projects. Supported on OCaml >=3D 4.08. =E2=80=A2 *Orsetto 1.2* is the next planned release. It will drop interfa= ces marked `@caml.deprecated` in the 1.1 release. It will also drop support for OCaml < 4.10, and it will stop depending on **ocamlfind**. I hope to add a PPX for deriving parsers and emitters from OCaml data type definitions. I might also consider one or more new interchange languages=E2=80=94 suggestions are heartily encouraged. [Orsetto 1.1.2] [Serde] [JSON ] [CBOR ] [CHANGES.md ] [nst/JSONTestSuite] Interest in a Http_sig library? =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: Kiran Gopinathan announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80 Heyo all! I=E2=80=99ve been working on an activitypub server for a while = now, and while it=E2=80=99s still not yet complete, recently I=E2=80=99ve reac= hed a point where I realised that I=E2=80=99ve actually been sitting on some libraries that the community might benefit from, as the current ecosystem doesn=E2=80=99t seem to handle these things. One such component that seemed to be in a state that was suitable to split off from was a small helper module to implement a particular http signature scheme that seems to be rather common in the activitypub scene. In particular, the scheme I=E2=80=99m referring to is defined here: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 Signing HTTP Messages =E2=94=82 draft-cavage-http-signatures-12 =E2=94=82=20 =E2=94=82 Abstract =E2=94=82 When communicating over the Internet using the HTTP protocol= , it can =E2=94=82 be desirable for a server or client to authenticate the send= er of a =E2=94=82 particular message. It can also be desirable to ensure that= the =E2=94=82 message was not tampered with during transit. This document =E2=94=82 describes a way for servers and clients to simultaneously add =E2=94=82 authentication and message integrity to HTTP messages by usi= ng a =E2=94=82 digital signature. =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 I=E2=80=99ve written a small library that glues together some components = in the OCaml ecosystem to somewhat handle the signing (I have been mainly working off an =E2=80=9Cimplement-enough-to-make-the-system-work=E2=80=9D= process rather than directly transcribing the specification above): =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 (** [verify ~signed_string ~signature key] returns true iff =E2=94=82 [signature] over [signed_string] is valid according to [key]= . *) =E2=94=82 val verify: signed_string:string -> signature:string -> X509.Pu= blic_key.t -> bool =E2=94=82=20 =E2=94=82 (** [verify_request ~resolve_public_key req] verifies that a dr= eam =E2=94=82 request has been signed according to the HTTP signature sche= me *) =E2=94=82 val verify_request: =E2=94=82 resolve_public_key:(string -> (X509.Public_key.t, 'a) Lwt_res= ult.t) -> =E2=94=82 Dream.request -> (bool, 'a) result Lwt.t =E2=94=82=20 =E2=94=82 (** [build_signed_headers ~priv_key ~key_id ~headers ~body_str =E2=94=82 ~current_time ~method_ ~uri] returns a list of signed header= s using =E2=94=82 [priv_key] according to the HTTP signature scheme. [key_id] = should =E2=94=82 be a string that can be used to look up the public key assoc= iated =E2=94=82 with [priv_key]. *) =E2=94=82 val build_signed_headers: =E2=94=82 priv_key:X509.Private_key.t -> =E2=94=82 key_id:string -> =E2=94=82 headers:string StringMap.t -> =E2=94=82 body_str:string -> =E2=94=82 current_time:Ptime.t -> method_:string -> uri:Uri.t -> (strin= g * string) list =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 The library is currently published at under the LGPL, but I haven=E2=80=99t released it on opam. Anyway, I was wondering if anyone else had interest in this kind of package, and whether it would be a good candidate for submission to opam - or if there are actually already existing libraries in the OCaml ecosystem that would actually already do this. Outreachy summer =E2=80=9922 closing commemoration session on 23rd Sept =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: Patrick Ferris announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Thank you to everyone that could make it to the presentation today. The presentation is now live: :camel: In particular a massive congratulations and thank you to @moazzammoriani and @IIITM-Jay. Thank you also to @sudha for being the driving force behind making the presentation happen again this round! See you all for the next round! Aside: if anybody has any issues with the live video please do reach out here either publicly or privately, we gave prior warning of our intentions to record and put the video on watch.ocaml.org, but I appreciate some people joined a little later/might have some reservations etc. findlib-1.9.6 =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 Archive: Gerd Stolpmann announced =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 findlib-1.9.6 is out, now supporting OCaml-5.00 (as far as we know it). There are also a few other install-related fixes in it. For manual, download, manuals, etc. see here: An updated OPAM package will follow soon. Interesting OCaml Articles =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95= =90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90= =E2=95=90 Archive: Deep in this thread, alan said =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 An interesting paper that uses OCaml is by Francois Pottier, which gives a declarative DSL for implementing type rules with applicative functors. It has an associated library, . Other OCaml News =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2= =95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 >>From the ocaml.org blog =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 Here are links from many OCaml blogs aggregated at [the ocaml.org blog]. =E2=80=A2 [Tarides Sponsors High School Hackers] [the ocaml.org blog] [Tarides Sponsors High School Hackers] Old CWN =E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90=E2=95=90 If you happen to miss a CWN, you can [send me a message] and I=E2=80=99ll= mail it to you, or go take a look at [the archive] or the [RSS feed of the archives]. If you also wish to receive it every week by mail, you may subscribe [online]. [Alan Schmitt] [send me a message] [the archive] [RSS feed of the archives] [online] [Alan Schmitt] --=-=-= Content-Type: text/html; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable OCaml Weekly News

OCaml Weekly News

Previous Week<= /a> Up Next Week

Hello

Here is the latest OCaml Weekly News, for the week of September 20 to 27, 2= 022.

Esperanto, when OCaml meets Cosmopolitan

Archive: https://discuss.ocaml.org/t/ann-esperanto-when-oc= aml-meets-cosmopolitan/10501/1

Calascibetta Romain announced

I am delighted to present the first experimental release of Esperant= o. This project is a new OCaml toolchain that creates binaries compiled with the Cosmopolitan C library and linked with the =CE=B1c=CF=84=C2=B5=CE=B1lly p=CE=B4r=CF=84=CE=B1bl=CE=B5 =CE=B5x=CE=B5c=C2=B5=CF=84=CE=B1bl=CE=B5 l= ink script. The binary produced is then portable to different platforms:

3D"linux= 3D"w= 3D"msd= 3D"macos= 3D"f= 3D"ope= 3D"net=

The main objective of Esperanto is to provide a toolchain capable of produc= ing a portable binary from an existing project. This would allow to finally be able to distribute software for all= these platforms without having to:

  1. manage multiple platforms orthogonally, the Cosmopolitan C library offe= rs you the POSIX API for all platforms (including Windows)
  2. Produce several versions of the same software for each platform. Only t= he binary is needed to run on all platforms

Cosmopolitan does not however produce a binary with a multi-platform= assembler. At this stage, our distribution only supports the x86_64 assembler (the most common one) but w= e are working on the possibility to produce a binary with different assemblers.

I would like to give special thanks to Justine, the author of the Cosmopoli= tan project (to develop redbean, a small portable HTTP server)= for her excellent work.

A toolchain

In OCaml, the “toolchain” principle allows the existence of sev= eral compilers within an OPAM switch and to choose one of them when it comes to cross-compiling a project. This principle, eve= n though it is not clearly defined and even though its use remains very limited, exists through the `ocamlfind` to= ol.

You can find these toolchains in your switch: 

$ ls $<=
span style=3D"color: #375cd8;">(opam var lib)/findlib.conf.d/
esperanto.conf solo5.conf

>>From our experience with Mirage as well as the work done in dune regarding cross-compilation, the choice to propose a new toolchain in order to allow = cross-compilation of projects with OPAM is both a historical choice but also the most relevant one in our opinion [1].

  • Why we need to cross-compile?

    The term cross-compilation can be misunderstood if we only consider the que= stion of the assembler issued by the compiler (does it match the host assembler or not). In our case, cross-comp= ilation is a broader term that implies the use of external artefacts to the compiler that are different from the d= efault and the use of compiler options that must be used throughout the production of the final binary.

    In other words, even though we are emitting the same assembler, we are doin= g so in a different “context” which requires the definition of a new toolchain= which includes our artefacts and compiler options.

    One of these artefacts is of course the C library used by the compiler whic= h will then be systematically used by the runtime caml, the well named libasmr= un.a. This is why, for example, there is a version of OCaml with musl. So there must be a version of = OCaml with Cosmopolitan.

    This new toolchain also allows you to incl= ude the necessary options for compiling C files because, yes, you can compile a C file with ocamlopt.

    In order to provide a coherent workflow fo= r a project, we need to provide not only a libasmrun.a compile= d with our Cosmopolitan C library but also an OCaml compiler capable of invoking t= he C compiler with the right options required by Cosmopolitan.

    Finally, we also need to describe in this toolcha= in how to link the object files together to actually produce a portable binary using the APE script.

  • A simple example with this new toolchain

    Installing Esperanto is very easy with OPAM. It will install the cross-comp= iler and the necessary files so that ocamlfind~/~dune can recognise this new toolchain: 

    $ opam install esperanto

    Finally, let’s try to produce a simple binary that displays “He= llo World!”: 

    $ cat &=
gt;main.ml <<EOF
let () =3D print_endlin=
e "Hello World!"
EOF
$ ocamlfind -toolchain opt main.ml
$ objcopy -S -O binary a.out
$ file a.out
a.out: DOS/MBR boot sector

    The binary produced can already be executed. However, there are still some = issues that have been fixed since then but which are probably not yet integrated in your system. They concern zsh and binfmt_misc in particular.

    The first problem with zsh is that it does not recognise the b= inary correctly. This problem has been fixed in the latest version of zsh.5.9.0. 

    $ zsh --version
zsh 5.8.1
$ zsh
$ ./a.out
zsh: exec format error: ./a.out

    The second problem concerns binfmt_misc which intervenes upstr= eam at the execution of your programs in order to choose how to execute them. In this case, binfmt_misc recognis= es Cosmopolitan binaries as Windows software by default.

    Here too, a solution is available and described by the author of Cosmopolit= an here: APE loader<= /a>

Issues

Apart from the outcomes described above, however, the Esperanto toolchain i= s not complete. Indeed, the OCaml distribution gives several libraries such as unix.cmxa and threads.cmxa. A little work has been done to make the former available. The second one is however unavailable for the moment sinc= e Cosmopolitan only partially implements pthread.

However, it seems that the author of Cosmopolotian wants to implement the r= est of the pthread API which will then allow us to provide support for threads.cmxa and OCaml 5.

This of course makes support for the projects more limited than we imagined= (and that’s why this release is experimental) however, an effort has already been made to lwt into Cosmopol= itan’s hypothetical future support for pthread.

Future

As explained above, support for threads.cmxa and OCaml 5 remai= ns the priority. however, an effort has already been made to support Lwt via Cos= mopolitan’s hypothetical future support for pthread.

However, it is possible that Cosmopolitan could become a target for the Mir= ageOS project in the same way as Solo5 (or our recent experiment on Raspberry Pi 4).

In this sense, we will surely propose an integration in MirageOS so that pr= ojects can both produce unikernels with Solo5 or portable binaries with Cosmopolitan.

[1] However, the question remains open at several levels, that of the compi= ler, that of OPAM and of course that of dune. It is clear that= the current situation is not the best in terms of what we need to do to pr= oduce such a cross-compiler. Only the feedback from Solo5 (which requires c= ross-compilation) allows us to say that it is surely the right choice for w= hat we want to offer.

Conclusion

We hope that this project will facilitate the distribution of software. You= can read a more technical article about our work here.= Finally, I would like to thank robur.io = (an association you can help) for a= llowing me to do this project.

EDIT: The author of Cosmopolitan just released Cosmopolitan with pthread support. So we will definitely try to improve our distribution to include OCaml with threads.cmxa su= pport and move forward with OCaml 5!

OBazl Toolsuite - tools for building OCaml with Bazel

Archive: https://discuss.ocaml.org/t/obazl-toolsu= ite-tools-for-building-ocaml-with-bazel/10021/15

Deep into this thread, Yawar Amin asked and Gregg Rey= nolds replied

Doesn=E2=80=99t dune get advertised as being able to handle multiple progra= mming languages, including C/C++?

There’s really no comparison. Dune evidently can use the (C ABI) outp= uts of a “foreign” build (if you write the glue code needed to make this work) but there’s no real build integ= ration, and no hermeticity guarantees. Under Bazel different languages use different rulesets but they’re all Bazel rule= sets, so you get one dependency graph across all languages, and if the rulesets are hermetic you get a hermetic build. = Without ABI restrictions. For example if your build needs to run a Python (or Javascript, Ruby, whatever) tool, Baze= l will build the tool and run it for you.

Even for C I think Bazel has much better integration. The rules in rules_c= c (e.g. cc_library producing a .a file) deliver a CcInfo provider (a provider is a kind of struct whose fields cont= ain the artifacts delivered by a build action). The rules in rules_ocaml (e.g. ocaml_module) understand CcInfo de= pendencies and pass them around using OcamlProvider (a provider specific to the ocaml rules). Bazel supports a me= rge operation for CcInfo, and the ocaml rules always merge their CcInfo deps and pass them on. So every build targe= t delivers the merge of all its CcInfo deps. The ocaml_binary rule that links its dependencies into an executable = merges its CcInfo deps (which include merged CcInfo from their deps, recursively) and ends up with a single CcInf= o containing every cc dependency in the dep graph, in the right order, with no duplicates. Then its simply a matter= of constructing the link command with the appropriate –ccopt options. More succinctly: you can add a C dep= directly to the module that needs it, and Bazel it pass it up the dependency chain, ensuring that it ends up on the c= ommand line when needed - building archives or executables. You don’t need to add a C dep to an archive= target when only one of n modules in the archive actually depends on it.

I’ve just started working on rules_jsoo, which I think will nicely de= monstrate the virtues of Bazel integration. The Bazel ecosystem includes a bunch of tools for working with Javascript; = for example rules_js and rules_nodejs make it easy to control which node toolchain version to use, integrate npm = stuff, etc. Wouldn’t it be nice to be able to use such tools directly, without writing a bunch of glue code? Now= a key element of Bazel integration is the use of providers. Rules deliver providers, and since providers act as = a kind of rudimentary type system, I can use the JsInfo provider (defined by rules_js) to integrate rules_jsoo with = the larger Bazel js ecoystem. For example, the jsoo_library rule takes the OcamlProvider provider delivered b= y ocaml_module rules, which contains the .cmo file. So jsoo_library runs those .cmo files through the jsoo compiler= and delivers the resulting js files in a JsInfo provider. That provider is suitable as input to the rules in rules_j= s, which gives us seamless integration. So we can use the js_binary rule of rules_js to run code produced by jsoo_l= ibrary under node. All that’s needed is to list the latter as a dependency of the former. That’s the plan, a= nyway. Isn’t that nice?

Gregg Reynolds said and Daniel B=C3=BCnzli replied

Ideally somebody learning a new language should not need to spend any time = (at first) dealing with a build language too.

This doesn’t only apply to learning. It also applies to prototyping, = hypothesis generation and testing.

That’s the reason why I built brzo which I hope I’ll be able to release at some point (still needs a good design review and changes to the OCaml strat= egy since it assumed we were moving towards a model that didn’t happen in the end =E2=80=93 namely the library linking proposal, I’d also like to add more languages to the mix but that= could wait).

None of my projects do not start with ~brzo~ing these days and the hassle f= ree build experience is exhilarating.

Build systems often are =E2=80=9Ccomplex and confusing=E2=80=9D, but that= =E2=80=99s largely because the problem space itself is complex and confusing. There=E2=80=99s no getting around that.

Note however that this is largely accidental complexity due to the f= act that compilers work in idiosyncratic ways for what build systems need in order to do their incremental and paralleliz= ation business.

They are still stuck in a world where people would invoke their compiler ma= nually at the cli level or specify the invocations themselves in a Makefile.

In fact if it were not for the actual tools and the (lack) of information t= hey give us, build is in fact an excessively simple problem.

More specific to OCaml, the compiler clis have an insane amount of quirks a= nd the whole system greatly suffers from an underspecified linking model. Basically it was not a good idea to let th= at be defined by a third party tool, if only so that you can actually talk about libraries in error messages from t= he compiler.

Orsetto: structured data interchange languages (release 1.1.2)=

Archive: https://discuss.ocaml.org/t/a= nn-orsetto-structured-data-interchange-languages-release-1-1-2/10506/1

james woodyatt announced

Announcing the release to OPAM of Orsetto 1.1.2, an update to a personal project of mine not sponsored by my employer. Licensed with BSD 2-Clause.

Q. What is Orsetto?

Aspires to do eventually for OCaml more or less what Serde has done for Rust, i.e. to be a curated and self-contained collection of structured data interchange langua= ges with a cohesive and unified model of serialization and deserialization.

Two interchange languages are currently supported: JSON and CBOR .

Q. What is new in this release?

Mostly error corrections, particularly in the CBOR library, produced by imp= roving test coverage.

The change log for the release is here: CHANGES.md

Highlights:

  • Major improvements in test coverage.
  • Many corrections for logic errors.
  • A few minor usability improvements.

Some things have not changed:

  • Still has no Programmer Guide or Tutorial, or really any introduction a= t all.
  • Still requires ocamlfind and builds with omake, which is = currently not compatible with OCaml 5.0.
  • Still only supports JSON and CBOR.

Q. It looks incomplete. What are your plans for future development?

Yes, it=E2=80=99s a personal project, and yes, I’m aware there are no= reverse dependencies on it currently in the public OPAM repository. Still, I=E2=80=99d welcome opportunities to collaborate wi= th others who share my vision for the project. As long as it=E2=80=99s just me working on this, development will continue to = be somewhat slow, as I’m prone to over-engineer things I care about. I have a lot of projects, and this is the only open so= urce one.

  • Orsetto 1.0.3 is the previous release. It offered parsers and em= itter combinators for JSON and CBOR for OCaml >=3D 4.06.1 (including 4.1= 3~alpha1). The quality of its JSON support is adequate, and it scores well = on the >nst/JSONTestSui= te tests. The quality of its CBOR support is provisional, >and not r= ecommended.
  • Orsetto 1.1.2 is the current release. It adds generalized and ex= tensible structured data interchange models with specializations for produc= ing emitters and parsers for JSON and CBOR. The quality of the CBOR support= is much improved, and I’m using it with good results in other projec= ts. Supported on OCaml >=3D 4.08.
  • Orsetto 1.2 is the next planned release. It will drop interfaces= marked `@caml.deprecated` in the 1.1 release. It will also drop support fo= r OCaml < 4.10, and it will stop depending on ocamlfind. I= hope to add a PPX for deriving parsers and emitters from OCaml data type d= efinitions. I might also consider one or more new interchange languages=E2= =80=94 suggestions are heartily encouraged.

Interest in a Http_sig library?

Archive: https://discuss.ocaml.org/t/interest-in-a-http-sig-library/105= 18/1

Kiran Gopinathan announced

Heyo all! I’ve been working on an activitypub server for a while now,= and while it’s still not yet complete, recently I’ve reached a point where I realised that I’ve actual= ly been sitting on some libraries that the community might benefit from, as the current ecosystem doesn’t seem to handle t= hese things.

One such component that seemed to be in a state that was suitable to split = off from was a small helper module to implement a particular http signature scheme that seems to be rather common= in the activitypub scene.

In particular, the scheme I’m referring to is defined here: https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-1= 2 

                         Signing HTTP Messages
                    draft-cavage-http-signatures-12

Abstract
   When communicating over the Internet using the HTTP protocol, it can
   be desirable for a server or client to authenticate the sender of a
   particular message.  It can also be desirable to ensure that the
   message was not tampered with during transit.  This document
   describes a way for servers and clients to simultaneously add
   authentication and message integrity to HTTP messages by using a
   digital signature.

I’ve written a small library that glues together some components in t= he OCaml ecosystem to somewhat handle the signing (I have been mainly working off an “implement-enough-to-make-= the-system-work” process rather than directly transcribing the specification above): 

(** [verify ~signed_str=
ing ~signature key] returns true iff
   [signature] over [signed_string] is valid ac=
cording to [key]. *)
val verify: signed_=
string:string -> signature=
:string -> X509.Public_key.t ->=
; bool

(** [verify_request ~resolve_public_key req] verifies that a dream
   request has been sig=
ned according to the HTTP signature scheme *)
val verify_request:
  resolve_public_key:(string -> (=
X509.Public_key.t, 'a) Lwt_result.t) ->
  Dream.request -> (bool, 'a) res=
ult Lwt.t

(** [build_signed_headers ~priv_key ~key_id ~header=
s ~body_str
   ~current_time ~method_ ~uri] returns a list of signed he=
aders using
   [priv_key] according to the HTT=
P signature scheme. [key_id] should
   be a string that can=
 be used to look up the public key associated
   with [priv_key]. *)
val build_signed_headers:
  priv_key:X509.Private_key.t ->
  key_id:string ->
  headers:string StringMap.t ->
  body_str:string ->
  current_time:Ptime.t -> method_:string -> uri:Uri.t -> (string * string) list

The library is currently published at https://github.com/Gopiandcode/http_sig_ocaml unde= r the LGPL, but I haven’t released it on opam.

Anyway, I was wondering if anyone else had interest in this kind of package= , and whether it would be a good candidate for submission to opam - or if there are actually already existin= g libraries in the OCaml ecosystem that would actually already do this.

Outreachy summer ’22 closing commemoration session on 23= rd Sept

Archive: https://discuss.ocaml.org/t/ou= treachy-summer-22-closing-commemoration-session-on-23rd-sept/10450/5

Patrick Ferris announced

Thank you to everyone that could make it to the presentation today. The pre= sentation is now live: https://watch.ocaml.org/videos/watch/dc5bbf5b-3dd9-4c8d-b26a-71e= 730a67788 :camel:

In particular a massive congratulations and thank you to @moazzammoriani an= d @IIITM-Jay. Thank you also to @sudha for being the driving force behind making the presentation happen again thi= s round! See you all for the next round!

Aside: if anybody has any issues with the live video please do reach out he= re either publicly or privately, we gave prior warning of our intentions to record and put the video on watch.ocaml.= org, but I appreciate some people joined a little later/might have some reservations etc.

findlib-1.9.6

Archive: https://sympa.inria.fr/sympa/arc/caml-list/2022-09/msg00007.html=

Gerd Stolpmann announced

findlib-1.9.6 is out, now supporting OCaml-5.00 (as far as we know it). There are also a few other install-related fixes in it.

For manual, download, manuals, etc. see here:

http://proje= cts.camlcity.org/projects/findlib.html

An updated OPAM package will follow soon.

Interesting OCaml Articles

Archive: https://discuss.ocaml.org/t/interesting-ocaml-articles/1867/100

Deep in this thread, alan said

An interesting paper that uses OCaml is http://gallium.inria.fr/~fpottie= r/publis/fpottier-elaboration.pdf by Francois Pottier, which gives a declarative DSL for implementing type rules= with applicative functors. It has an associated library, ht= tps://opam.ocaml.org/packages/inferno/.

Other OCaml News

From the ocaml.org blog

Here are links from many OCaml blogs aggregated at the ocaml.org blog.

Old CWN

If you happen to miss a CWN, you can send me a message and I’ll mail it to you, or go take= a look at the archive or= the RSS feed of the a= rchives.

If you also wish to receive it every week by mail, you may subscribe online.

--=-=-=--