From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Authentication-Results: plum.tunbury.org; dkim=pass (1024-bit key; unprotected) header.d=inria.fr header.i=@inria.fr header.a=rsa-sha256 header.s=dc header.b=EdnhsyDj; dkim=fail reason="signature verification failed" (1024-bit key; secure) header.d=polytechnique.org header.i=@polytechnique.org header.a=rsa-sha256 header.s=svoboda header.b=BPkRvt3t; dkim-atps=neutral Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=192.134.164.83; helo=mail2-relais-roc.national.inria.fr; envelope-from=caml-list-owner@inria.fr; receiver=tunbury.org Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by plum.tunbury.org (Postfix) with ESMTPS id 35FC0401BB for ; Tue, 25 Feb 2025 10:36:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inria.fr; s=dc; h=from:to:date:message-id:mime-version:subject:reply-to: sender:list-id:list-help:list-subscribe:list-unsubscribe: list-post:list-owner:list-archive; bh=k9a4ibXBlK6+OCv2fxAy1Bw5+FHBM/D07jHi2pLmT7I=; b=EdnhsyDjhNiYENsD7GJud6saybPfMNJXnRc1jGDOWIVK28YV+8oZwKzR ZQJHlvY4RJklgH+2VRHr/KXtVvL46oXQx6Nm4oaF2MsxPiU/fpslw5FB2 tKkUBVf4jdQFuUuAlq0wZPksi5pdzrMJuSUwG2cAUDk6BcD8t/qv18ucG Y=; Received-SPF: Pass (mail2-relais-roc.national.inria.fr: domain of caml-list-owner@inria.fr designates 128.93.162.160 as permitted sender) identity=mailfrom; client-ip=128.93.162.160; receiver=mail2-relais-roc.national.inria.fr; envelope-from="caml-list-owner@inria.fr"; x-sender="caml-list-owner@inria.fr"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 include:mailout.safebrands.com a:basic-mail.safebrands.com a:basic-mail01.safebrands.com a:basic-mail02.safebrands.com ip4:128.93.142.0/24 ip4:192.134.164.0/24 ip4:128.93.162.160 ip4:128.93.162.3 ip4:128.93.162.88 ip4:89.107.174.7 mx ~all" Received-SPF: None (mail2-relais-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@sympa.inria.fr) identity=helo; client-ip=128.93.162.160; receiver=mail2-relais-roc.national.inria.fr; envelope-from="caml-list-owner@inria.fr"; x-sender="postmaster@sympa.inria.fr"; x-conformance=spf_only Authentication-Results: mail2-relais-roc.national.inria.fr; spf=Pass smtp.mailfrom=caml-list-owner@inria.fr; spf=None smtp.helo=postmaster@sympa.inria.fr; dkim=hardfail (body hash did not verify [final]) header.i=@polytechnique.org X-IronPort-AV: E=Sophos;i="6.13,314,1732575600"; d="scan'208,217";a="209929158" Received: from prod-listesu18.inria.fr (HELO sympa.inria.fr) ([128.93.162.160]) by mail2-relais-roc.national.inria.fr with ESMTP; 25 Feb 2025 11:36:22 +0100 Received: by sympa.inria.fr (Postfix, from userid 20132) id 0E4B6E0D21; Tue, 25 Feb 2025 11:36:22 +0100 (CET) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id CB748E0260 for ; Tue, 25 Feb 2025 11:36:18 +0100 (CET) IronPort-SDR: 67bd9d20_y7gm4Lx9k9x/wB+0dTnfIf9BlJjaOAqPRPMCd70f3lk71l1 HIUARQ1PibR6cEEG4GF8whff/S532weoMDFeJAQ== X-IPAS-Result: =?us-ascii?q?A0ElDABAnL1ndyIeaIFQCoJcAoE/gQMZAWNVBTMHCEhhg?= =?us-ascii?q?zk8g0+OIYEWmyuBVoFWIxQBAwENLgEMBgECBAEBAwECAYIMgi5GAosRAh8GA?= =?us-ascii?q?QQwCQ4BAgQBAQEBAwIDAQEBAQEBEAEBBQEBAQIBAQIEBgECEAFDSYVBAQEEA?= =?us-ascii?q?jINSQEBAQMBCgGBahk4cYElAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAgsBAQwXOzIOAQgKEwEBKgENGCMDFAEGAwIRATUXA?= =?us-ascii?q?RIUBoJpgh9FAwUMBpJUm0t6gTKBATuBUQEBBoEIPgIBAgkCBQEOCSbaB4FlC?= =?us-ascii?q?YFIhWyCSRoBKkhqAoRICYM4excQD4FVRIEVNYFzSgdvgVBvCxcBAQEBGERVB?= =?us-ascii?q?AcBAQJLCYMlgmmCM0p2ggJegQyGP2aBQYIPgTiCOoF9hE6BVoNfgneJbYFHS?= =?us-ascii?q?zMsAVUTFwsHBWGBEAMqNDGBRno5ggxpSToCDQI1gh4kWIIrgxqBPIRDhEKFU?= =?us-ascii?q?oIRgguJL4NIHUADC209NxQboFsJNjYBPIM/Lw44BhcnDwwMFwkFBQEHDAgOA?= =?us-ascii?q?iACDSABCA4qAQoFFBkECQUBCAICCAoFAS4LCwItA5JSJQMrAXWOU44Tk1OBC?= =?us-ascii?q?jQHhB6BXQYMiQWBJJV9hAOBV4swhwCSSyKYWyKFL4QtgSUJglmVVQQchTaBZ?= =?us-ascii?q?zqBKzEzGjBDDQYIghgBMwlGHA9XhnWBLoMXghwWg1iBPoEmgSMYOTvGZEI1A?= =?us-ascii?q?gEBOAIHAQoBAQMJhWIBAYMEghdug3sCJgcFgUsBAQ?= IronPort-PHdr: A9a23:MqdycRNrbk7Fc0RUPqEl6nb8AhdPi9zP1u491JMrhvp0f7i5+Ny6Z QqDvq8r1AeCDdyHtbptsKn/jePJYS863d65qncMcZhBBVcuqP49uEgeOvODElDxN/XwbiY3T 4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6JvjvGo7Vks+7y/2+94fcbghGmjaxe69+I Am5oQjSq8UbjopvIbstxxXUpXdFZ+tZyWR0KFyJmBry+tm+94N5/SRKvPIh+c9AUaHkcKk9U LdVEjcoPX0r6cPyrRXMQheB6XUaUmUNjxpHGBPF4w3gXpfwqST1qOxw0zSHMMLsTLA0XTOi7 7p3SBLtlSwKOSI1/H3Rh8dtjK5VoxShpwJ+w47PYYGaL/5+cb3AdtIUQmpBRNteVzdcCY+4Y YYDE+8NMOBFpIf/ulQOtwOzCwmyCu3yxDFGhXD50rEh3us7DQ3LxhYtE84SvHnWqtj+KaccU fqyzKnN1TjOc/dW1i376IPVbx4uvfGMXbdxccrN1UkkCgTIgU+UqYP/OTOZzP8NvHSb7+plV OKvl3InphppojiowsctipXJiZwJxVDE8yV5wZ81JcCmR0JhZt6kCpRQujicOoBrTcwsX3tmt zwmyr0ap5G7Zi4KxYw6yhPed/CLbpWE7Bz9WOqMPzp1hnJodrK+ihu2/kat1OLyW8e63VtJr iRIjNnCuHAM2hHN98SJSvtw8Eeh1zuL0Q3Y9+9KIUcxlaXBKp4hxKY9loINvkTfHy/2hFv5j LeRdkUh/+in9f7rYrP4qZ+AL4N0jR3xPb4rmsy7G+g4NRIOX2eD9eSmyb3j+k34QKhRjv0rl KnVqozVJcMepqKhDA9V05oj6xaiDzi9ytgXgX4HLFdddBKAkojpJ0vOL+7iAvijg1StkC1nx /fcPr3uGpnNMmLMkK3gfblg9UFc0xA/wsxY55JREr0BIuj8Wknvu9zDEh85KRK7zPj7CNlny oweXmePDreDMKzMq1CH+/4vI+mSa4AIvzbyN+Ml6+TvjX8+gVMSYamp0oERaHC3APtmOF+VY X/xjdsZFWcFpA8+Q/f3h1KYXz5TYHGyU7gg6TE8DYKqFYnDRpuxgLObxie3B5lWaXpAClCDC 3vocJ+EW/gUZCOTP89hlj0EVaC9RI8hzx6uqBX2xKZgLurR4iEYso7s28Jw5+3Xjx0+7zt0D 96S022VU250nmQIRyIz3Kxlp0xy1EuD3bB5g/xeD9xT5ulGXh00NZ7GyeFxFtP8WhrZc9uUV lqrRs+qDSwtQt8+2dMDbVpxF8+sgx3MxyamHrEYm6GRCJAq8q/R0GL9K9hgx3rcyqUsgF0rT 81SPmC4gq5/6hPTB5LXnEWDiqiqdKUd0zDV+Wufy2eFoVtWXxRqUarfWHASfkvWosr95kPFV 7KuDLsmPhZbxc6aLatKbt3ojUlYS/j/ONTeZWOxm36tBRmW3L+Ma5Dqe2oF0CXcDkgLjRwT8 G6bOQQgAiqtuX/SACBhGF71bU7g7fNypX20Q0MsygGFdUxh1767+h4PgvycTuse0K8Ytik8t zl5BEiy3tPXCtWdvwduc75SbMsl4FdA0WLYtxB9MYK8IKBigF4ech13v17w2BltDYVAi8cqo Wswwwp2M62Y1klNdyiE0pDwP73XK3Xy/Ay0ZqHN3VHezdCW9bsR5/QjsVnjuQ6kF0U4/3Vgy dlV3GOQ5pPRAwUKS5L+Tl439wRmp7HdeiQx+pvY1WdwPqmsrj/Cx9UpCfM5xRm6etdfNLqIF AvzE80BG8ijM/cqmlisbhIcJu9e7q80P8W8d/uHwqGnJuhgnCj1xVhAtcp5zUTGv354Vejg2 4kDhfeVwl3DHzz1iVPktsHshahFYysTFyyx03vKHolUM4R2dIBDMmyuJsyr2p0qjprkXThD/ 16mBk8a8NeufQuOYlf92wxJyElRpmaoz3jrhwdomi0k+/LMlBfFxP7vIUFfUoYqbGxrjFO3Z JOxk8hfR0+wKQ4giBqi40/+galdvqV2aWfJEg9TZyajCWZkX+Ors6aaJdZV4cYhtSxRFv+3Y VWbVqLVuxwewj/uFGtYxSkmenetoJqq1wdihjelJW1o5GHcZdk2wB7e4NLGQvsE5QA9HHx1m yvbU2aFasGu+cSImpzDtOGnSm/nUYdcJCDvxIXGryC74Gx2HTW1mO21kdD8Vw1mwWn8zdY5H T7QokPEa5Lwn7+/LfohfkRsAwrk7NFmH4hljoYqrJQAgD4CgZGE4XcMkWHyKMhWn6XkYxLhX BYtxNjYqEjg0UxndTeSwp7hE26a2o1nbsW7ZWUf3mQ86dpLAeGa9u4Mmyw9uVe+oQ/LBJo11 j4A1fsj7mIbiOAVqUIsyCuaGLUbAUhfO2TliR2J69m0qKgfanyodPC80093nNbpC7/nwEkUU XLwfNE5Fi9179ljGErL1Gzv54rkftjJcN9VsQeb0l/Bg+VTNJMth68SnyM0XAC19XYhyuM9k VlvxcTj5tnBcj0xuvnhREUEZViXL4sJ9zrgjLhThJOT1oGrRdB6HykTGYDvVbSuGS4TsvLuM 0CPFic9ozGVA+m6f0fX5UF4onbIC53uOWuQISxT9u9ZHEyQNl5T1T4tCS09mo8lGwuqws34b Uo/4Soes1f8ox0K0eloMhjjTk/VoxquYTovDp3DPFxR9A4ItCK3eYSOq/l+GS1V5MjrpQiEL CqAbARNDH0VclSDA0H/M7Ku49jZ7uXeAfCxZairA/3GualVUPGGwoiq241t8mOXN8mBCXJlC uUyxktJWX0R993xozwUUGRXkivMa5XevxKg4mhsqdj59v33WQXp7I/JCr1IMNwp9QrkyauEM ueRgm5+J1M6nts3/0SQnbUNzlJHtRg7bz6pAKgNvi7LTbvNl+lQFRFOYid6Mo1T5KI53xVRE cTcl9X+26U+i6IlTVBfWjmD0omlaNcLLGe0KF7cTB/RZfLffWGNmJmxOv/0QKYYlOhOshysp TuXW1TuODiOjXiMNVjnMO1Bij2aIA0LvYi8dhh3Dm2wBNniaxC9LJp2lWhvm+xy3yuWczVEd 2MgICYv5vWK4ChVg+tyATlE53thdqyfnjqBqvLfMtAQuOdqBSJ9k6Rb5m47wv1b9nIhJrQ9l S3Mo9ppu1zjnPOIz28tayB18mNGlpCH6HtbbL3e8ohcVH3E+hMU8GjWDA4F8tJhA9upoKtQz 9nTiIr5LypE+N/Pu85AF47TMs3NYx9DeVL5XSXZCgcIV2vhDlvk3xlQguOeo0Os+4A9ronwl ZEOTL5CSVFzEekVX01hFdpEO5x3WzI4jZaRi9MO7nel6hyNVINdpJ+NBZfwSb3/bT2ei7dDf R4Bx7j1eJ8SOoPM0EtnclBmnY7OFhmYTZVXryZmdANxvFRV/S00UDgow0y8IFDIgjdbBbuuk xUxkAc7fek96GKm/QIsPlST7GgxiBVjwI+0x2nJLHiqdOHrAckVCjKo5RFrY9WiG1ozNlX0x hEBVn+MBLNJ0+kxLCYy0laa58EJQKYDBe5FeEFCn6nPPqd0iFgE+Cz1mkZKuLmXV5c9xFlxK vvO5zoD2ho9PoRtffWCePNFlgoJ1PPSsiL6hL9qngNMeBpSqCvXcSoM8iTkL5EeLjGztqxp4 A2GwH5YfXQUEuEturRs/188POKJy2Th1aRCIwa/Lb7XI6ScsmnG3cmGJzF4nlsPjFVA9KNq3 N0LdlrNEVgoyKqNGh8JM8vbNAwTaNBdvHTeZieBt+zRzIk9Zt/sULmwEanV7OBP3gqtB2NLV 8wU494EH4Ww3U2QNsrhILMfiF0s6AntOFSZHaFJdRaMw38Mp8CyyoMy3JEIf2tMRzwlbWPsv vCM+lxP4rLLRto9b3YEU5FRM3s3XJb/gCtFpzFbCyHx1OsFyQ+E5ju6pyLKDTC6YcAwAZXcL R5qFtyy/i0ytqasjluCuK7kHDmvOMZwtorx0LYCoJKWF/5fTb98qlrR3Y5CSCmjV2fJV8W+J 53xd5UEZ9vpDH23SRq61yJzSN3+doXITODAkUTzSIBYvZPOligkLtO4HyoCFg1YovFaorp7Y RwfbpE7Zx/xqgl4MLawalT9sJ3mUyOmLj1YSONaxOOxaulMziYiWeS9zWMpUpAwy+TkuV5IX pwBiQvSgOqyf4QLGzamAWRTIk+cwEhx33gkLOs5xf0zhQ/FoUVJeS7eb/RnMSRN95Q1AVfYS Z2TInI/Q06AgIHD5A+1wr1U+DFSzY48OQJtun/juJTSe3SpBLztro/a4XNIhTkOpr0od5TkJ tqauZjemD3GUZSWtReKAnfSKg== IronPort-Data: A9a23:NedZAKJRzu+o8ghhFE+RdpElxSXFcZb7ZxGr2PjKsXjdYENS0mYFx zEYD2GDaKnca2SgeYwja4yx8EJX78CEyYQySAQd+CA2RRqmi+KVXIXDdh+Y0wC6d5CYEho/t 63yTvGacajYm1eF/k/F3oDJ9CU6j+fSLlbFILasEjhrQgN5QzsWhxtmmuoo6qZlmtHR7zml4 LsemOWBfgb+s9JIGjhMsf/b8kky5K6aVA4w5zTSW9gb5DcyqFFOVPrzFYnpR1PkT49dGPKNR uqr5NlVKUuEl/uFIorNfofTKiXmcJaKVeS9oiY+t5yZv/R3jndaPpDXmxYrQRw/Zz2hx7idw TjW3HC6YV9B0qbkwIzxX/TEes3X0GIvFLLveBCCXcKvI0LuVTjj+OU1DEUNZa4ZpNtGW2pU6 /w/N2VYBvyDr7reLLOTT/k1wNwkKNj3MYgfvHB50DyfCuwpKXzBa/yQtJkBhGt23ZgIRqq2i 8kxMVKDaDz7WSYXb1oFGp5rot79nn77YiFVo1KTpLMq7i7U1gMk2bzkNpzOcdyPRNlJtkyfu 2TN8n+/B00KctuFxlJp91r13r6ezH+nBNN6+LuQ+9swuQLO+jUoOgw6SQrhvOaeth7mRIcKQ 6AT0nFz8fZpqxTDosPGdxaxpXrBuh8HR/JLAugi4UeMzLDV6kCXHAA5oiVpbcx/8tcxQS022 1SJmdLwGDEpt6eaIZ6AyluKhRXxNhMFdm8GXncnTFU40oPoup8zqQ2aG76PD5WJptHyHDjxx RWDoy4/m6gfgKY3O0OToQivb9WE+sChc+Il2jg7SF5J+StXXuaYi2GA7EiCq+5HKJeFQ1KBu nkdhsXY6/oBZX1sqMBvaLtXdF1Kz6/bWNE5vbKJN8Nxn9hK0yTyFb28GBkkeC9U3j8sIFcFm nP7twJL/4N0N3C3d6JxaI/ZI511kfC8SYu/CqmJP4Qmjn1NmOmvoHsGiam4gz+FraTQufpX1 WqzL5vxVihy5VpPl2TqHY/xLoPHNghlmD+NHs+jp/hW+beVY3qYAa8CNEqSY+s56qKdvQid/ s5EPNPi9vmseLCWX8UjyqZKdQpiBSFiVfjLRzl/L7/rzvxOQTB5U6e5LHJIU9ANopm5Yc+Vo ijnAR4JkQqXaL+uAVziV02PoYjHBf5XxU/X9wRxVbpx8ylyOdSc/+0EeoEpfLIq0uVmwLQmB 7MGYsiMSLAHADjO5z1XP9G3oZ1AZSabo1uEHxOkRzwjIL9mZQjCoeH/ciXVqSIhMyuQtOkFm YOG6D/1e5Q5elldPJ7kU873l1KVlloBqd12RHrNc4Vyel2z0Y1EKB7Rr/4QIuMNI0792wrA6 RSyBE9AqMKQvYQw+9jtroKHprePDOFRMBd7HW7azLDuLgjc3DOp7rFhWdayXwL2dT3L6oT7Q ssN1ND6EvkMvGgSgrpGC7wxkJ4PvYr+lYFV3iFPPSvtbW3yLphCP3Pf/81ElpMV949joQHsB 36+oIhLC46oZvHgPkUafjc+T+K50voRpDnewNI1LGj+5w515LC3alpTDTbdlB1iKKZJD619z dcDoMI27ymNuiguOPuCjQFW8D2oBV4EWKMFqJobIdHKjiwG91J8WqHfWxTGuMy3V9ZxM0cRM mC1gojGjO9i3UbsSSc4OkXM+ut/vq4wni524mUMHHm3v+bUp+QW2URR+AsnTw4OwRRg1flyC 1dRNEZ0BPuv+m40ofMeQGr2C1xNKyOb82Os01A5qmn9Shi5ZH3sN0w4A/6Gp2oCwlJffx9a3 bCW83nkWjDUZ/PM3jM+dEpmiv77R/lj31TmtOH+OOrdBLg8Qz7uopH2VFoysxG9XP8A3hzWl 9dl7MNbSPPdNxdJh4YZFoPD97AbaC7cFVx4Wfs7oZ84RzDNSgqThwqLBVu6IP5WBvrw9kS9N cxiC+RPWzm61weMtjorPrENEZAlgM8W4Mc+RZ2zKV4kq7e/qh9bgKDU/AX6h04pRIxKuuQ5I YXzaTmDMzKxgV15pmzzl/RHa1GIOYQ8WA7B3e6O4LooEbAHu7pSak0c6Oa/kEiUFwpFxCiqm j3/SZXY9MFY8rQ0rbDQSv1CIy6WNeLMUP+59VHvktZWMvLKH8T8lyIUjVjFIA4MLeYddOp1n JvQqNXH4kfhuecnYXH4gLiELbFCvu+pbdpUM+X2DXhUpjSDU8nS+Ck++3i0BJhKsdFF7Oyle leIU9SxftsrRNtt/n1ZRCxAGRI7Ca6sTKPfiQ6ijvaLUD4x7BfmKY65yHrXcm1rTC8EFJngA AvSufz1xNR5rpxJNSAUFcNdHJ50D1/ya5QIL+Srm2GjMVCppVeetp/Jtxkqs2jLA0bZNvfK2 8vOQxymeSmivK3N8spijLVzmR8qF1d4v/g7exMM2txxig3iNlU8E8YmDcwkBK1XwwvI77OpV AGVOSFmQW/4UC9feBrx3MX7U03NTqYSM9P+PXoy81nSdy6yA5iaDaB88jt7pU17YSbn0PrtP OR2Fqcc5fRt6soBqScvCv2HbSNPw+ODgGoP/VHhnsfyBRcHHLhM02ZudOaIfTKSCNnDzS0nO kBsLV2ogmniIaIyLSqkU3RSBRcSsSipymk4KyCVz74zfq2FmfZYxqSX1/7bi9U+gQdjGFLKb WvwQ3qR7muW3H0KpKZvvMgm6UOx5TRnAeDiRJLeqcYuc21cJ4jp0w7uXcbCcS36xDNiLg== IronPort-HdrOrdr: A9a23:/B/jYKuSLbC5i3U0QBPPpfFN7skDS9V00zEX/kB9WHVpm62j5q OTdZEgvyMc5wx+ZJhNo7290cq7IU80l6QV3WB5B97LNzUO01HGEGgN1+ff6gylMxK73O9Q36 VtfsFFeb/NJGk/q931pC2xE9NI+qjizElEv5a680tQ X-Talos-CUID: =?us-ascii?q?9a23=3A7tzUSGvPTTM7IxnfFipcx9NY6IsDMXLm3CzQJ3T?= =?us-ascii?q?gKmc3dYzPQkWO+IR7xp8=3D?= X-Talos-MUID: 9a23:mlwBuwUSVwQVLJTq/DLJ3gg9afsx2Ja/JFxcy4gZnPXUbTMlbg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="6.13,314,1732575600"; d="scan'208,217";a="109994449" X-MGA-submission: =?us-ascii?q?MDH/KTaTnkUtzrQ03h4G/y+SOQAgH0Y10xHyjI?= =?us-ascii?q?PwPj6gWazt3Ze8Sc+xhpga0SJw7sJJvUJT5XcwXEv9yCKGmFsDDDZ0vt?= =?us-ascii?q?8vRbJsFI/MmPUUkZeukafxvOWJPc1xc8mL1D38vwcLHkymsFP9crci5C?= =?us-ascii?q?yJBs1DRk9J6rkLd4zBjQwg+g=3D=3D?= Received: from mx1.polytechnique.org ([129.104.30.34]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 25 Feb 2025 11:36:17 +0100 Received: from mac-03220211.irisa.fr (mac-03220211.irisa.fr [131.254.21.249]) (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 0DCF0564B99; Tue, 25 Feb 2025 11:36:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=polytechnique.org; s=svoboda; t=1740479775; bh=GpoI2Qo3TD0AKX2LkCXMDTEOdJfo8Td4KulHRsLnrTs=; h=From:To:Subject:Date:Message-ID; b=BPkRvt3tkYNdWIruWc4sRWm3yVSyQ21lLtynYmLz2PtmSbEdNtX5lOMJA62X3FQbW 4+d2KPOaGqwDMG3x8WfQzHETo9VrZnwGIJsPTIqm2uoEDtn8EibNwKsATX4/CuRYrS 8cIi9kuAFmamJwgxiLfwdfFo+x+nijRcy6xwZGnE= From: Alan Schmitt To: "lwn" , caml-list@inria.fr Date: Tue, 25 Feb 2025 11:36:13 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-=-=" X-AV-Checked: ClamAV using ClamSMTP at svoboda.polytechnique.org (Tue Feb 25 11:36:15 2025 +0100 (CET)) X-Spam-Flag: Unsure, tests=bogofilter, spamicity=0.469084, queueID=7C73B564B9B X-Org-Mail: alan.schmitt.1995@polytechnique.org Subject: [Caml-list] Attn: Development Editor, Latest OCaml Weekly News Reply-To: Alan Schmitt X-Loop: caml-list@inria.fr X-Sequence: 19274 Errors-To: caml-list-owner@inria.fr Precedence: list Precedence: bulk Sender: caml-list-request@inria.fr X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Here is the latest OCaml Weekly News, for the week of February 18 to 25, 2025. 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 Early work experimenting with zig as a cross-compiler for OCaml Dune dev meeting Outreachy June 2025 Js_of_ocaml 6.0.1 / Wasm_of_ocaml Bytecode debugging in OCaml 5.3 New F* release on opam (2025.02.17) Other OCaml News Old CWN Early work experimenting with zig as a cross-compiler for OCaml =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: Chris Armstrong 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 This is some early work [using zig as a cross-compiler] for building OCaml cross-compilation systems: [opam-cross-lambda] *Status*: It is currently severely untested but the aim is to be able to cross-compile to Linux from Windows/Mac/Linux for aarch64 and x86_64 CPU architectures simply by adding an opam repository, and without the need for nix. *Why:* The novel aspect is zig, which allows you to cross-compile C code without needing to install or set up a cross-compilation sysroot i.e. glibc, gcc, binutils, kernel headers etc. as zig packages much of the needed headers and symbol information internally. *Next steps:* start importing packages (including those with native binaries) into the opam repository overlay, validate them in CI/CD This approach has led me down some rabbit-holes with a bunch of learning - some interesting points: =E2=80=A2 zig uses clang internally, so its effectively testing clang compatibility with OCaml's autoconf + Makefile assumptions about the C compiler =E2=80=A2 targeting windows isn't possible with this setup at this time, because flexdll hardcodes mingw binary names (e.g. x86_64-w64-mingw32-gcc) in its Makefile and the flexlink binary (it assumes these exist because targeting mingw32 is always a cross-compilation, even on Windows). It also depends on binutils' windres, which zig does not provide a wrapper for. =E2=80=A2 targeting macos x is untested =E2=80=A2 as you can see in the CI/CD scripts, setting the ZIG cache dire= ctory environment variables is crucial for MacOS because of opam's sandboxing (zig builds its cache in the user's home directory, which is outside the default sandbox) =E2=80=A2 although ocamlfind and dune have some cross-compilation support= with "toolchains", there are gaps and undocumented assumption =E2=80=A2 opam doesn't really support cross-compilation environments well= - packages often don't require much change, but you do need to create a `-cross-' version of every single package - this could be a lot more straightforward and less work with a more cohesive platform strategy for cross-compilation *Alternatives*: I'm aware of alternatives in the ecosystem (and indeed have benefitted from): =E2=80=A2 [ocaml nix overlays] - these offer a far better tested and reproducible cross-compilation environment, mostly for systems that can run nix =E2=80=A2 [opam-cross-windows] - lots of little nuggets of build-time information found in here [using zig as a cross-compiler] [opam-cross-lambda] [ocaml nix overlays] [opam-cross-windows] Dune dev meeting =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: Continuing this thread, art-w 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=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 Thanks everyone for joining! The meetings notes are here: Outreachy June 2025 =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 Hi everyone! Once again, the OCaml community has signed up to Outreachy (see [past] [posts])! [past] [posts] What is Outreachy? =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 Outreachy is a paid, remote internship program. Outreachy promotes diversity in open source and open science. Our internships are for people who face under-representation, and discrimination or systemic bias in the technology industry of their country. The current round is still ongoing with an intern making great progress on [ocaml-api-watch] with @NathanReb and @panglesd. [ocaml-api-watch] Important Dates =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=E2=95=8C=E2=95=8C For this next round, the important dates are as follows (these are always subject to some change): =E2=80=A2 Feb 26 - Community sign up deadline :white_check_mark: =E2=80=A2 Mar 7 - [Mentor project description deadline] =E2=80=A2 Mar 10 to Apr 8 - Contribution period =E2=80=A2 Jun 2 to Aug 29 - Internship period Our next deadline is for mentors to sign up to the OCaml community with a project idea. Please do consider being an Outreachy mentor. If you have any questions or ideas you can always reach out to me directly. If you need a refresher of past projects, there's a dedicated page on the OCaml website: . The OCaml community is currently able to financially support Outreachy internships thanks to the generous support of [Tarides] and [Janestreet]. Thanks! :camel: [Mentor project description deadline] [Tarides] [Janestreet] Js_of_ocaml 6.0.1 / Wasm_of_ocaml =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: J=C3=A9r=C3=B4me Vouillon 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 I=E2=80=99m pleased to announce the joint release of js_of_ocaml 6.0.1 and wasm_of_ocaml. Js_of_ocaml is a compiler from OCaml bytecode to JavaScript. It makes it possible to run pure OCaml programs in JavaScript environment like browsers and Node.js. [Wasm_of_ocaml] is a compiler from OCaml bytecode to WebAssembly. It is highly compatible with Js_of_ocaml, so you can compile your programs with wasm_of_ocaml instead of js_of_ocaml and experience overall better performance. It is [supported by Dune 3.17], making the switch very easy. Most significant changes in js_of_ocaml: =E2=80=A2 The conversion between Javascript numbers and OCaml floats is n= ow explicit, using functions `Js.float' and `Js.to_float' (this is necessary for wasm_of_ocaml which does not use the same representation for JS numbers and OCaml floats) =E2=80=A2 `Dom_html' has been modernized, removing some no longer relevant `Js.optdef' type annotations =E2=80=A2 Effects: =E2=80=A3 add an optional feature of "dynamic switching" between CPS and direct style, resulting in better performance when no effect handler is installed =E2=80=A3 make resuming a continuation more efficient See the [Changelog] for other changes. [Wasm_of_ocaml] [supported by Dune 3.17] [Changelog] Olivier Nicole then added =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 Regarding wasm_of_ocaml, Tarides also just posted [a blog post] with some more details about its recent developments, and what kind of performance gains have been observed with it. I want to insist that building your project to Wasm can be as simple as enabling the `wasm' mode in dune. To quote the documentation page cited by J=C3=A9r=C3=B4me: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 (executable (name foo) (modes wasm)) =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 And then request the .wasm.js target: =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 $ dune build ./foo.bc.wasm.js =E2=94=82 $ node _build/default/foo.bc.wasm.js =E2=94=82 hello from wasm =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 [a blog post] Bytecode debugging in OCaml 5.3 =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: gasche 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 Today I conducted a small experiment of using a debugger on a small OCaml program (built using `dune'). The program is not written by me, does non-trivial things, and is written in such a way that my usual approaches to understand what is going on would require more work than I want to pour in it. I took notes on this experience, in the hope that it could be of interest to others =E2=80=93 maybe I'm doing things wrong and people will= let me know, maybe this can help identify potential tooling improvements. Disclaimer: I am a complete beginner as far as running OCaml debuggers goes. (I have used `ocamldebug' and `gdb' irregularly in the past, never heaily, and long forgotten how to use them.) TL;DR: =E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C=E2=95=8C Bytecode debugging with OCaml 5.3 and dune: =E2=80=A2 works fine in Emacs/Tuareg, as it did in the past =E2=80=A2 works okay in vscode using ocamlearlybird =E2=80=A2 could be improved with a bit more targeted work, some of it pro= bably easy (and some of it hard) If I understand correctly, no one is specifically working on this right now. Let me take this occasion to thank the people who contributed to all these tools (Tuareg, ocamldebug, ocamlearlybird, vscode+ocaml integration, dune, etc.). Why a debugger? =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=E2=95=8C=E2=95=8C I am looking at an OCaml program that I did not write, and does interesting and complex things. I would like to build my understanding of how it works by observing the flow of values in some parts of the program, on concrete examples of interest. I am unfamiliar with debuggers and tried other things first: 1. I considered modifying the code to print the values it encouters at runtime. But the program does not define pretty-printers for its values, and writing them is cumbersome. (I could probably use `deriving' to produce debuggers more easily.) 2. My next move is usually `dune utop': instead of running the program, I can call its library functions via the toplevel on small examples. But this particular program is only a binary, it was not split as a library and a binary, and splitting it would be non-trivial. When "printf debugging" and "play in the toplevel" are not immediately within reach, it may be time to try a debugger. They should let us stop at a given point in the program, print values, and move around in the execution trace to better understand what is going on. Running a debugger in general =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=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=E2=95=8C=E2=95=8C=E2=95=8C To run a debugger on OCaml programs, one has to choose between a bytecode debugger, `ocamldebug', and native debuggers such as `gdb' and `lldb'. Native debuggers are not OCaml-specific and likely to be better documented, have more integrated tooling etc., but they are more low-level and don't know as much about OCaml programs; in particular they're not so good at printing values. On the other hand `ocamldebug' can print OCaml values, and it is a time-travel debugger that supports going backward in time; but it relies on running the bytecode executable that is probably 10x slower than the native executable. It is also probably worse when debugging cross-language programs, for example using the FFI. I would not try `ocamldebug' to debug performance-sensitive programs, programs in production, and in particular to debug anything resembling a segmentation fault. But it should offer a nice experience for pure-OCaml programs during their development. The Coq/Rocq maintainers have long been using `ocamldebug' to understand their software, a large OCaml program with tricky bugs and non-trivial performance requirements. They rely on specific tooling to make it nicer =E2=80=93 autoloaded scripts, customized pretty-printers. So there is evidence that `ocamldebug' can work well when integrated inside a project development workflow. (Here the program I want to debug has /not/ had any such written, so it will be more barebones.) Getting a bytecode executable from Dune =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=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=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 Before going any further, you need to ask `dune' to generate bytecode executables, by adding =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 (modes byte exe) =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80 to the `executable' stanza. Then you run `dune build', and when invoking the debugger you will need to manually pass the path to the bytecode program, for example `_build/default/bin/main.bc'. IDE integration =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=E2=95=8C=E2=95=8C Running `ocamldebug' directly is doable but not great. Just like it's nice when IDEs let you jump to the location of a compilation error, you really want the debugger to show you "where" it is in the program execution by showing you a program point in your programming editor. (`ocamldebug' will print the source line where it is at, so it's not too bad, but still noticeably less pleasant, and typing movement commands one by one gets old fast.) I considered two approaches to running a bytecode debugger for OCaml programs: =E2=80=A2 run `ocamldebug' from Emacs/Tuareg =E2=80=A2 run `ocamlearlybird' from VsCode =E2=97=8A ocamlearlybird in vscode I first decided to use ocamlearlybird from vscode. I opened vscode (which is not my usual editor) and tried to use `Run > start debugging' directly=E2=80=A6 and it didn't work well. You need to configure things manually, and the vscode interface did not tell me that, it would show nothing and appear not to work as expected but without much help. The better way to configure vscode+earlybird is to=E2=80=A6 read the documentation first. I recommend: 1. Read the [vscode-ocaml-platform README.md] about how to setup things. 2. then read the [ocamlearlybird README] (which also links to the README above), in particular watch the short demo, to know what to expect when the interface works. The README documents the field of the `launch.json' file that you have to write to describe how to invoke the debugger, and this is helpful. After reading this, I knew how to tweak the `launch.json' file so that the debugger would pass command-line arguments to the program, and it started working correctly. Unfortunately `ocamlearlybird' does not current support time-travel ([issue]), so it is only possible to stop at breakpoints and move forward in time, while I was expecting to run until a failure and then go backward in time, as I usually do with `ocamldebug'. At this point I decided to go back to my familiar Emacs. [vscode-ocaml-platform README.md] [ocamlearlybird README] [issue] =E2=97=8A Points to improve When trying to "run the debugger" without having configured a specific bytecode program, the vscode UI appears to work but does nothing. For example it is possible to add breakpoints, etc., and then clicking "run" does nothing that I can see. I wish there was clearer feedback when things are not setup and there is no chance that it will work. This would also be a good time to point me to the online documentation =E2=80=93 from within the IDE = =E2=80=93 so that the process is more discoverable. =E2=97=8A ocamldebug in Emacs At this point I had already set things up to build a bytecode executable in Dune, so things were easy: `M-x ocamldebug' and there you go. There is [documentation in the user manual], which was probably written more than a decade ago, and it mostly reads just fine today. (Note: some of the documented keybindings do not work: `C-c C-k' is documented as stepping back in the manual, but it is not supported by Tuareg ([issue]).) Moving around program execution is fun, printing values works okay =E2=80= =93 the next step for convenience would be to install custom printers to get nice output. [documentation in the user manual] [issue] =E2=97=8A Points to improve 1. Emacs jumps to source code to follow the program execution in the debugger; but on every movement in the execution trace it asks me again whether I want `src/foo.ml' instead of `_build/default/src/foo.ml', and this is annoying. (Sometimes I did not observe this behavior, not sure why.) 2. Dune includes various wrapping/mangling of module names that show up in the `ocamldebug' printing, and can be annoying at time. For example some module names show up as `Dune__exe.Foo', and I would prefer to see just `Foo'. I think it should be possible to hard-code some more de-Dune-mangling logic in the debugger's pretty-printer, and ideally we could even make them user-configurable or dune-configurable a bit. 3. If I print an AST from an execution point that does not have `open Ast' in its typing environment, the AST is printed like `Dune__exe.Ast.Let (Dune__exe.Ast.Var "x", ...)'. It would be nice to omit the `Dunne__exe' part, but ideally I should also be able to tell the debugger: "let's open `Ast' locally from now on when you print values", so that it prints in a more readable way by default. Vincent Laviron 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 Nice post, thanks ! A few things I would like to add: =E2=80=A2 Time travelling is possible for the native debuggers with `rr'.= At some point it was Linux-only, it might still be the case, but it's /very/ nice to use. I have on some occasions debugged bytecode programs by using `rr' on it, and with the appropriate gdb/lldb macros to print OCaml values it can be useful (but mostly for debugging the C parts; for problems purely on the OCaml side `ocamldebug' is still better suited). I use it regularly for native debugging and it's very convenient (it can even help with debugging eisenbugs in parallel programs ! Just run `rr record ./my_program' several times until the bug triggers, and then `rr replay' will always replay the same run, including thread interleavings, consistently reproducing the bug). =E2=80=A2 I have tried time travelling with `ocamldebug' in the past and I have hit some serious issues: limited history means that you cannot go very far in the past, and the way it works (by setting checkpoints and replaying from the checkpoint to the required instruction) means that you can often see weird artifacts due to C calls being replayed each time you step back, sometimes breaking the program completely. I'm curious to know if this is just bad luck (or me doing weird things), or if you had similar issues too. =E2=80=A2 The `Dune__exe' stuff is, I believe, `dune''s misguided attempt= to shield users from potential conflicts between files linked in the executable and modules with the same name present in non-wrapped libraries required as dependencies. I suspect that `(wrapped false)' or something like that in the section of the dune file corresponding to the executable will get rid of it. Tim McGilchrist also 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 It is possible to use `ocamlearlybird' with `dap-mode' in Emacs [link]. The setup uses the same json config file as VSCode. I'm putting my effort into DAP support since that gets cross editor support and I can switch between LLDB/ocamlearlybird. For Emacs the two main options for DAP support are: =E2=80=A3 dap-mode, which ties into lsp-mode and follows that style of things. Uses JSON configuration based off VSCode configuration. The UI elements depend on lsp-mode, so it's a heavier setup and might not play as well with eglot. =E2=80=A3 dape, standalone DAP mode with a more minimal approach. I didn'= t get it working satisfactorily but it seems closer to eglot in philosophy For both I see the challenges are: 1. Setting up DAP itself reliably and with less fuss. It could be smoother and better documented. 2. Setting up dune builds to generate the right artifacts. Having a direct LSP code action to run a debugger against a particular executable like Rust does would be ideal. 3. Bugs in ocamlearlybird and lack of maintainer time. It's interesting to hear about users of bytecode debugging, I thought there wouldn't be many people using that. [link] Nicolas Ojeda Bar also 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 For example some module names show up as `Dune__exe.Foo', and I would prefer to see just `Foo'. This is controlled by `(wrapped_executables )' in `dune-project': New F* release on opam (2025.02.17) =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: Chandradeep Dey 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 Hello! It is my pleasure to announce that F* is once again available on opam for direct installation after a long time. This probably does not mean much to regular users, as there were regular releases on GitHub for some time now. However, the opam release offers a convenient alternative by eliminating the need to separately set up OCaml to compile extracted OCaml code. From the [website] - F* is a general-purpose proof-oriented programming language, supporting both purely functional and effectful programming. It combines the expressive power of dependent types with proof automation based on SMT solving and tactic-based interactive theorem proving. The biggest new thing worth mentioning is perhaps the Pulse DSL for programming with concurrent separation logic. A tutorial is available in the F* book, Proof-oriented Programming in F*. A comprehensive overview of various projects that have utilized F* over the years can also be found on the website. Feel free to join the [Zulip forum] for discussions with the developers, researchers, and casual users. Happy writing provably correct programs! [website] [Zulip forum] 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 [How I fixed Slipshow's worst flaw using OCaml and a monad] =E2=80=A2 [The First Wasm_of_ocaml Release is Out!] [the ocaml.org blog] [How I fixed Slipshow's worst flaw using OCaml and a monad] [The First Wasm_of_ocaml Release is Out!] 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'll 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 to the [caml-list]. [Alan Schmitt] [send me a message] [the archive] [RSS feed of the archives] [caml-list] [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 February 18 to 25, 20= 25.

Early work experimenting with zig as a cross-compiler for OCam= l

Archive: https://discuss.ocaml.org/t/e= arly-work-experimenting-with-zig-as-a-cross-compiler-for-ocaml/16151/1

Chris Armstrong announced

This is some early work using zig as a cross-compiler for building OCaml cross-compilation= systems:

opam-cross= -lambda

Status: It is currently severely untested but the aim is to be able = to cross-compile to Linux from Windows/Mac/Linux for aarch64 and x86_64 CPU= architectures simply by adding an opam repository, and without the need fo= r nix.

Why: The novel aspect is zig, which allows you to cross-compile C co= de without needing to install or set up a cross-compilation sysroot i.e. gl= ibc, gcc, binutils, kernel headers etc. as zig packages much of the needed = headers and symbol information internally.

Next steps: start importing packages (including those with native bi= naries) into the opam repository overlay, validate them in CI/CD

This approach has led me down some rabbit-holes with a bunch of learning - = some interesting points:

  • zig uses clang internally, so its effectively testing clang compatibili= ty with OCaml's autoconf + Makefile assumptions about the C compiler
  • targeting windows isn't possible with this setup at this time, because = flexdll hardcodes mingw binary names (e.g. x86_64-w64-mingw32-gcc) in its M= akefile and the flexlink binary (it assumes these exist because targeting m= ingw32 is always a cross-compilation, even on Windows). It also depends on = binutils' windres, which zig does not provide a wrapper for.
  • targeting macos x is untested
  • as you can see in the CI/CD scripts, setting the ZIG cache directory en= vironment variables is crucial for MacOS because of opam's sandboxing (zig = builds its cache in the user's home directory, which is outside the default= sandbox)
  • although ocamlfind and dune have some cross-compilation support with "t= oolchains", there are gaps and undocumented assumption
  • opam doesn't really support cross-compilation environments well - packa= ges often don't require much change, but you do need to create a <= package>-cross-<cross-name> version of every single package= - this could be a lot more straightforward and less work with a more cohes= ive platform strategy for cross-compilation

Alternatives: I'm aware of alternatives in the ecosystem (and indeed= have benefitted from):

  • ocaml nix overlay= s - these offer a far better tested and reproducible cross-compilation = environment, mostly for systems that can run nix
  • opam-cross-windows - lots of little nuggets of build-time inf= ormation found in here

Dune dev meeting

Archive: https://discuss.ocaml.org/t/ann-dune-dev-meeting/14994/24

Continuing this thread, art-w announced

Thanks everyone for joining! The meetings notes are here: https://github.com/oca= ml/dune/wiki/dev-meeting-2025-02-19

Outreachy June 2025

Archive: https://discuss.ocaml.org/t/outreachy-june-2025/16154/1

Patrick Ferris announced

Hi everyone!

Once again, the OCaml community has signed up to Outreachy (see past posts<= /a>)!

What is Outreachy?

Outreachy is a paid, remote internship program. Outreachy promotes diversit= y in open source and open science. Our internships are for people who face = under-representation, and discrimination or systemic bias in the technology= industry of their country.

The current round is still ongoing with an intern making great progress on = ocaml-api-watch= with @NathanReb and @panglesd.=20

Important Dates

For this next round, the important dates are as follows (these are always s= ubject to some change):

Our next deadline is for mentors to sign up to the OCaml community with a p= roject idea. Please do consider being an Outreachy mentor. If you have any = questions or ideas you can always reach out to me directly. If you need a r= efresher of past projects, there's a dedicated page on the OCaml website: <= a href=3D"https://ocaml.org/outreachy">https://ocaml.org/outreachy.=20

The OCaml community is currently able to financially support Outreachy inte= rnships thanks to the generous support of T= arides and Janestreet.

Thanks! :camel:

Js_of_ocaml 6.0.1 / Wasm_of_ocaml

Archive: https://discuss.ocaml.org/t/ann-js-of-ocaml-6-0-1-wasm-of= -ocaml/16160/1

J=C3=A9r=C3=B4me Vouillon announced

I=E2=80=99m pleased to announce the joint release of js_of_ocaml 6.0.1 and = wasm_of_ocaml.

Js_of_ocaml is a compiler from OCaml bytecode to JavaScript. It makes it po= ssible to run pure OCaml programs in JavaScript environment like browsers a= nd Node.js.

Wasm_of= _ocaml is a compiler from OCaml bytecode to WebAssembly. It is highly c= ompatible with Js_of_ocaml, so you can compile your programs with wasm_of_o= caml instead of js_of_ocaml and experience overall better performance. It i= s supported b= y Dune 3.17, making the switch very easy.

Most significant changes in js_of_ocaml:

  • The conversion between Javascript numbers and OCaml floats is now expli= cit, using functions Js.float and Js.to_float (th= is is necessary for wasm_of_ocaml which does not use the same representatio= n for JS numbers and OCaml floats)
  • Dom_html has been modernized, removing some no longer rele= vant Js.optdef type annotations
  • Effects:
    • add an optional feature of "dynamic switching" between CPS and direct s= tyle, resulting in better performance when no effect handler is installed
    • make resuming a continuation more efficient

See the Changelog for other changes.

Olivier Nicole then added

Regarding wasm_of_ocaml, Tarides also just posted a blog post with some more details about its recent developments, and what kind of performance gains have been observed with it.

I want to insist that building your project to Wasm can be as simple as ena= bling the wasm mode in dune. To quote the documentation page cited by J=C3=A9r=C3=B4me: 

(executable (name foo) (modes wasm))

And then request the .wasm.js target: 

$ dune build ./foo.bc.wasm.js
$ node _build/default/foo.bc.wasm.js
hello from wasm

Bytecode debugging in OCaml 5.3

Archive: https://discuss.ocaml.org/t/bytecode-debugging-in-ocaml-5-3/1= 6177/1

gasche announced

Today I conducted a small experiment of using a debugger on a small OCaml p= rogram (built using dune). The program is not written by me, d= oes non-trivial things, and is written in such a way that my usual approach= es to understand what is going on would require more work than I want to po= ur in it.

I took notes on this experience, in the hope that it could be of interest t= o others – maybe I'm doing things wrong and people will let me know,= maybe this can help identify potential tooling improvements.

Disclaimer: I am a complete beginner as far as running OCaml debuggers goes= . (I have used ocamldebug and gdb irregularly in = the past, never heaily, and long forgotten how to use them.)

TL;DR:

Bytecode debugging with OCaml 5.3 and dune:

  • works fine in Emacs/Tuareg, as it did in the past
  • works okay in vscode using ocamlearlybird
  • could be improved with a bit more targeted work, some of it probably easy (and some of it hard)

If I understand correctly, no one is specifically working on this right now. Let me take this occasion to thank the people who contributed to all these = tools (Tuareg, ocamldebug, ocamlearlybird, vscode+ocaml integration, dune, = etc.).

Why a debugger?

I am looking at an OCaml program that I did not write, and does interesting= and complex things. I would like to build my understanding of how it works= by observing the flow of values in some parts of the program, on concrete = examples of interest.

I am unfamiliar with debuggers and tried other things first:

  1. I considered modifying the code to print the values it encouters at run= time. But the program does not define pretty-printers for its values, and w= riting them is cumbersome. (I could probably use deriving to p= roduce debuggers more easily.)
  2. My next move is usually dune utop: instead of running the = program, I can call its library functions via the toplevel on small example= s. But this particular program is only a binary, it was not split as a libr= ary and a binary, and splitting it would be non-trivial.

When "printf debugging" and "play in the toplevel" are not immediately with= in reach, it may be time to try a debugger. They should let us stop at a gi= ven point in the program, print values, and move around in the execution tr= ace to better understand what is going on.

Running a debugger in general

To run a debugger on OCaml programs, one has to choose between a bytecode d= ebugger, ocamldebug, and native debuggers such as gdb and lldb.

Native debuggers are not OCaml-specific and likely to be better documented,= have more integrated tooling etc., but they are more low-level and don't k= now as much about OCaml programs; in particular they're not so good at prin= ting values.

On the other hand ocamldebug can print OCaml values, and it is= a time-travel debugger that supports going backward in time; but it relies= on running the bytecode executable that is probably 10x slower than the na= tive executable. It is also probably worse when debugging cross-language pr= ograms, for example using the FFI.

I would not try ocamldebug to debug performance-sensitive prog= rams, programs in production, and in particular to debug anything resemblin= g a segmentation fault. But it should offer a nice experience for pure-OCam= l programs during their development.

The Coq/Rocq maintainers have long been using ocamldebug to un= derstand their software, a large OCaml program with tricky bugs and non-tri= vial performance requirements. They rely on specific tooling to make it nic= er – autoloaded scripts, customized pretty-printers. So there is evi= dence that ocamldebug can work well when integrated inside a p= roject development workflow. (Here the program I want to debug has not had any such written, so it will be more barebones.)

Getting a bytecode executable from Dune

Before going any further, you need to ask dune to generate byt= ecode executables, by adding 

(modes byte exe)

to the executable stanza. Then you run dune build= , and when invoking the debugger you will need to manually pass the path to= the bytecode program, for example _build/default/bin/main.bc.

IDE integration

Running ocamldebug directly is doable but not great. Just like= it's nice when IDEs let you jump to the location of a compilation error, you really want the debugger to show you "where" it is in the program execution by showing you a program point in your programming editor. (ocamldebug will print the source line where it is at,= so it's not too bad, but still noticeably less pleasant, and typing movement commands one by one gets old fast.)

I considered two approaches to running a bytecode debugger for OCaml progra= ms:

  • run ocamldebug from Emacs/Tuareg
  • run ocamlearlybird from VsCode
  • ocamlearlybird in vscode

    I first decided to use ocamlearlybird from vscode.

    I opened vscode (which is not my usual editor) and tried to use Run &= gt; start debugging directly… and it didn't work well. You ne= ed to configure things manually, and the vscode interface did not tell me t= hat, it would show nothing and appear not to work as expected but without m= uch help.

    The better way to configure vscode+earlybird is to… read the documen= tation first. I recommend:

    1. Read the vscode-ocaml-platform README.md = about how to setup things.
    2. then read the ocamlearlybird README (which also links to the READM= E above), in particular watch the short demo, to know what to expect when t= he interface works. The README documents the field of the launch.json= file that you have to write to describe how to invoke the debugger,= and this is helpful.

    After reading this, I knew how to tweak the launch.json file s= o that the debugger would pass command-line arguments to the program, and i= t started working correctly.

    Unfortunately ocamlearlybird does not current support time-tra= vel (issue= ), so it is only possible to stop at breakpoints and move forward in ti= me, while I was expecting to run until a failure and then go backward in ti= me, as I usually do with ocamldebug. At this point I decided t= o go back to my familiar Emacs.

    • Points to improve

      When trying to "run the debugger" without having configured a specific byte= code program, the vscode UI appears to work but does nothing. For example i= t is possible to add breakpoints, etc., and then clicking "run" does nothin= g that I can see.

      I wish there was clearer feedback when things are not setup and there is no= chance that it will work. This would also be a good time to point me to th= e online documentation – from within the IDE – so that the pr= ocess is more discoverable.

  • ocamldebug in Emacs

    At this point I had already set things up to build a bytecode executable in= Dune, so things were easy: M-x ocamldebug and there you go. T= here is documentatio= n in the user manual, which was probably written more than a decade ago= , and it mostly reads just fine today.

    (Note: some of the documented keybindings do not work: C-c C-k= is documented as stepping back in the manual, but it is not supported by T= uareg (issue).)

    Moving around program execution is fun, printing values works okay –= the next step for convenience would be to install custom printers to get n= ice output.

    • Points to improve
      1. Emacs jumps to source code to follow the program execution in the debug= ger; but on every movement in the execution trace it asks me again whether = I want src/foo.ml instead of _build/default/src/foo.ml, and this is annoying. (Sometimes I did not observe this behavior, no= t sure why.)
      2. Dune includes various wrapping/mangling of module names that show up in= the ocamldebug printing, and can be annoying at time. For exa= mple some module names show up as Dune__exe.Foo, and I would p= refer to see just Foo. I think it should be possible to hard-c= ode some more de-Dune-mangling logic in the debugger's pretty-printer, and = ideally we could even make them user-configurable or dune-configurable a bi= t.
      3. If I print an AST from an execution point that does not have open= Ast in its typing environment, the AST is printed like Dune__= exe.Ast.Let (Dune__exe.Ast.Var "x", ...). It would be nice to omit t= he Dunne__exe part, but ideally I should also be able to tell = the debugger: "let's open Ast locally from now on when you pri= nt values", so that it prints in a more readable way by default.

Vincent Laviron replied

Nice post, thanks !

A few things I would like to add:

  • Time travelling is possible for the native debuggers with rr. At some point it was Linux-only, it might still be the case, but it's <= i>very nice to use. I have on some occasions debugged bytecode programs= by using rr on it, and with the appropriate gdb/lldb macros t= o print OCaml values it can be useful (but mostly for debugging the C parts= ; for problems purely on the OCaml side ocamldebug is still be= tter suited). I use it regularly for native debugging and it's very conveni= ent (it can even help with debugging eisenbugs in parallel programs ! Just = run rr record ./my_program several times until the bug trigger= s, and then rr replay will always replay the same run, includi= ng thread interleavings, consistently reproducing the bug).
  • I have tried time travelling with ocamldebug in the past a= nd I have hit some serious issues: limited history means that you cannot go= very far in the past, and the way it works (by setting checkpoints and rep= laying from the checkpoint to the required instruction) means that you can = often see weird artifacts due to C calls being replayed each time you step = back, sometimes breaking the program completely. I'm curious to know if thi= s is just bad luck (or me doing weird things), or if you had similar issues= too.
  • The Dune__exe stuff is, I believe, dune's mis= guided attempt to shield users from potential conflicts between files linke= d in the executable and modules with the same name present in non-wrapped l= ibraries required as dependencies. I suspect that (wrapped false) or something like that in the section of the dune file corresponding to= the executable will get rid of it.

Tim McGilchrist also replied

It is possible to use ocamlearlybird with dap-mode in Emacs link. The setup uses the same json config file as VS= Code. I'm putting my effort into DAP support since that gets cross editor s= upport and I can switch between LLDB/ocamlearlybird.=20

For Emacs the two main options for DAP support are:

  • dap-mode, which ties into lsp-mode and follows that style of things. Us= es JSON configuration based off VSCode configuration. The UI elements depen= d on lsp-mode, so it's a heavier setup and might not play as well with eglo= t.
  • dape, standalone DAP mode with a more minimal approach. I didn't get it= working satisfactorily but it seems closer to eglot in philosophy https://github.com/svaante/dape

For both I see the challenges are:

  1. Setting up DAP itself reliably and with less fuss. It could be smoother= and better documented.
  2. Setting up dune builds to generate the right artifacts. Having a direct= LSP code action to run a debugger against a particular executable like Rus= t does would be ideal.
  3. Bugs in ocamlearlybird and lack of maintainer time.

It's interesting to hear about users of bytecode debugging, I thought there= wouldn't be many people using that.

Nicolas Ojeda Bar also replied

For example some module names show up as Dune__exe.Foo, and I = would prefer to see just Foo.

This is controlled by (wrapped_executables <bool>) in dune-project: https://dune.readthedocs.io= /en/latest/reference/dune-project/wrapped_executables.html

New F* release on opam (2025.02.17)

Archive: https://discuss.ocaml.org/t/ann-new-f-release-on-opam-20= 25-02-17/16179/1

Chandradeep Dey announced

Hello! It is my pleasure to announce that F* is once again available on opa= m for direct installation after a long time. This probably does not mean mu= ch to regular users, as there were regular releases on GitHub for some time= now. However, the opam release offers a convenient alternative by eliminat= ing the need to separately set up OCaml to compile extracted OCaml code.

>>From the website - F* is a general-purpose proof-oriented programming language, supporting bot= h purely functional and effectful programming. It combines the expressive p= ower of dependent types with proof automation based on SMT solving and tact= ic-based interactive theorem proving.

The biggest new thing worth mentioning is perhaps the Pulse DSL for program= ming with concurrent separation logic. A tutorial is available in the F* bo= ok, Proof-oriented Programming in F*. A comprehensive overview of various p= rojects that have utilized F* over the years can also be found on the websi= te.

Feel free to join the Zulip forum<= /a> for discussions with the developers, researchers, and casual users. Hap= py writing provably correct programs!

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 loo= k at the archive or the <= a href=3D"https://alan.petitepomme.net/cwn/cwn.rss">RSS feed of the archive= s.

If you also wish to receive it every week by mail, you may subscribe to the= caml-list.

--=-=-=--